From ghc-devs at haskell.org Fri Mar 1 09:28:13 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 09:28:13 -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.fcab2e278a0c919635a6260a013783be@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: | -------------------------------------+------------------------------------- Comment (by sgraf): That patch doesn't help at all. It seems we really depend on the libffi bundled with boot GHC(?). The problem is probably with my Nix shell and this recent change https://github.com/NixOS/nixpkgs/commit/a7c774300b7eab779afb9a81b3f02f3bed69c943. So, Nix provides a boot GHC that is built and bundled with the system libffi. I still have to figure out where it stores libffi's headers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 09:42:33 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 09:42:33 -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.6fcdd6b3018122555ed28f32183e29ac@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: | -------------------------------------+------------------------------------- Comment (by sgraf): Nix stores headers in /nix/store/xxx-libffi-3.2.1-dev/include, so it separates build artifacts from headers. So the problem is with the wrong setting [https://github.com/NixOS/nixpkgs/commit/a7c774300b7eab779afb9a81b3f02f3bed69c943 #diff-50972848d68a2300257f35df16c0fd3aR156 here]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 10:05:20 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 10:05:20 -0000 Subject: [GHC] #16020: Hadrian: correctly Install libffi shared object files In-Reply-To: <045.7cb46e35f781e91fb607edbacacf8fcc@haskell.org> References: <045.7cb46e35f781e91fb607edbacacf8fcc@haskell.org> Message-ID: <060.76208fab8974b3a41daca292d6f1c2ec@haskell.org> #16020: Hadrian: correctly Install libffi shared object files -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: task | Status: closed Priority: high | Milestone: Component: Build System | Version: 8.6.2 (Hadrian) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by davide): * status: new => closed * resolution: => fixed Comment: Fixed with https://gitlab.haskell.org/ghc/ghc/merge_requests/174 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 10:59:34 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 10:59:34 -0000 Subject: [GHC] #16374: Cannot deduce constraint from itself with poly-kinded type family Message-ID: <045.9902b332efcda928f7c92c9ed54e9ea9@haskell.org> #16374: Cannot deduce constraint from itself with poly-kinded type family -------------------------------------+------------------------------------- Reporter: roland | 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: -------------------------------------+------------------------------------- Compiling {{{#!hs {-# LANGUAGE PolyKinds, TypeFamilies #-} module Eq where type family F a :: k where withEq :: F Int ~ F Bool => a withEq = undefined }}} gives an arguably confusing error message: {{{ Eq.hs:7:11: error: • Could not deduce: F Int ~ F Bool from the context: F Int ~ F Bool bound by the type signature for: withEq :: forall k a. (F Int ~ F Bool) => a at Eq.hs:7:11-29 NB: ‘F’ is a non-injective type family The type variable ‘k0’ is ambiguous • In the ambiguity check for ‘withEq’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature: withEq :: F Int ~ F Bool => a }}} I'm not claiming this program should necessarily typecheck, but "Cannot deduce X from the context X" induces head-scratching. Replacing `k` with `*` in the definition of `F` makes the error go away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 11:00:17 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 11:00:17 -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.2d4fe4750d35576213606e5bae8c2589@haskell.org> #14069: RTS linker maps code as writable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4817 Wiki Page: | -------------------------------------+------------------------------------- Changes (by watashi): * cc: watashi (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 11:11:13 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 11:11:13 -0000 Subject: [GHC] #16375: TypeApplications obscure "Variable not in scope" error message Message-ID: <045.c11c8d6eda096d5d92407c35292c3e2f@haskell.org> #16375: TypeApplications obscure "Variable not in scope" error message -------------------------------------+------------------------------------- Reporter: roland | 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: -------------------------------------+------------------------------------- Compiling {{{#!hs {-# LANGUAGE TypeApplications #-} module Foo where foo = bar @Int }}} gives {{{ Foo.hs:5:7: error: • Cannot apply expression of type ‘t1’ to a visible type argument ‘Int’ • In the expression: bar @Int In an equation for ‘foo’: foo = bar @Int }}} instead of: {{{ Foo.hs:5:7: error: Variable not in scope: bar }}} This makes a potential typo appear like a typing error (no pun intended). If we delete `@Int`, the second message is given. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 11:13:43 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 11:13:43 -0000 Subject: [GHC] #15800: Overlapping instances error with single instance In-Reply-To: <045.2e1fce9b901f82fa18c2e6cad6f62eea@haskell.org> References: <045.2e1fce9b901f82fa18c2e6cad6f62eea@haskell.org> Message-ID: <060.5964a8107bc2b329949c986761035177@haskell.org> #15800: Overlapping instances error with single instance -------------------------------------+------------------------------------- Reporter: roland | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by roland): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 12:52:39 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 12:52:39 -0000 Subject: [GHC] #16370: Hadrian: test T3807 failure In-Reply-To: <045.e450a30493d0d646dc7fd35562073ab1@haskell.org> References: <045.e450a30493d0d646dc7fd35562073ab1@haskell.org> Message-ID: <060.a1c2a21a3db0e1a25791d0b3cc146266@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: | -------------------------------------+------------------------------------- Comment (by davide): I've created an MR for option 2: https://gitlab.haskell.org/ghc/ghc/merge_requests/471. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 13:01:34 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 13:01:34 -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.f1721f80ed22ad24f5aec13d0261ae70@haskell.org> #16368: Boot GHC's libffi installation path leaks into stage1 build -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: ⊥ Component: Build System | Version: 8.6.3 (Hadrian) | 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 sgraf): * status: new => closed * resolution: => invalid Comment: Fixed in https://github.com/NixOS/nixpkgs/pull/56573. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 13:51:16 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 13:51:16 -0000 Subject: [GHC] #16375: TypeApplications obscure "Variable not in scope" error message In-Reply-To: <045.c11c8d6eda096d5d92407c35292c3e2f@haskell.org> References: <045.c11c8d6eda096d5d92407c35292c3e2f@haskell.org> Message-ID: <060.d326b80a2c5b26c25fc50f51e45f04a7@haskell.org> #16375: TypeApplications obscure "Variable not in scope" error message -------------------------------------+------------------------------------- Reporter: roland | 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: #13834 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13834 Comment: Closing as a duplicate of #13834. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 13:59:30 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 13:59:30 -0000 Subject: [GHC] #16374: Cannot deduce constraint from itself with poly-kinded type family In-Reply-To: <045.9902b332efcda928f7c92c9ed54e9ea9@haskell.org> References: <045.9902b332efcda928f7c92c9ed54e9ea9@haskell.org> Message-ID: <060.711497164950c7c5526f576ec17234bf@haskell.org> #16374: Cannot deduce constraint from itself with poly-kinded type family -------------------------------------+------------------------------------- Reporter: roland | 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): Enabling `-fprint-explicit-kinds` reveals in greater detail what is happening here: {{{ $ ~/Software/ghc-gitlab/inplace/bin/ghc-stage2 --interactive Bug.hs -fprint-explicit-kinds GHCi, version 8.9.20190227: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Eq ( Bug.hs, interpreted ) Bug.hs:7:11: error: • Could not deduce: (F @{*} @k0 Int :: k0) ~ (F @{*} @k0 Bool :: k0) from the context: (F @{*} @k Int :: k) ~ (F @{*} @k Bool :: k) bound by the type signature for: withEq :: forall k a. ((F @{*} @k Int :: k) ~ (F @{*} @k Bool :: k)) => a at Bug.hs:7:11-29 NB: ‘F’ is a non-injective type family The type variable ‘k0’ is ambiguous • In the ambiguity check for ‘withEq’ To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the type signature: withEq :: F Int ~ F Bool => a | 7 | withEq :: F Int ~ F Bool => a | ^^^^^^^^^^^^^^^^^^^ }}} Here, we can see exactly where the ambiguous kind variable `k0` occurs. It might be helpful to have GHC automatically enable `-fprint-explicit- kinds` is an ambiguous type variable occurs in a kind position, such as in this program. We already do this in a number of places, such as when [https://gitlab.haskell.org/ghc/ghc/blob/2e8f664957dc3763dc4375894b8dc4d046d2e95b/compiler/typecheck/TcErrors.hs#L1931 a type mismatch occurs due to kind arguments]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 15:09:51 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 15:09:51 -0000 Subject: [GHC] #16015: git notes logic breaks CircleCI validation of pull requests In-Reply-To: <046.a4af4e013a0542f24ebc756d5b0a7b75@haskell.org> References: <046.a4af4e013a0542f24ebc756d5b0a7b75@haskell.org> Message-ID: <061.049cd9db1703d23b60ed161eb55b556c@haskell.org> #16015: git notes logic breaks CircleCI validation of pull requests -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 15:11:53 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 15:11:53 -0000 Subject: [GHC] #15641: Git repositories have several problems In-Reply-To: <046.cc1f52463775afa374d2adbd9385be70@haskell.org> References: <046.cc1f52463775afa374d2adbd9385be70@haskell.org> Message-ID: <061.09f30a8c334263f6fd8f18d4300a013d@haskell.org> #15641: Git repositories have several problems -------------------------------------+------------------------------------- Reporter: flip101 | Owner: hvr Type: bug | Status: closed Priority: high | 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 bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 18:14:32 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 18:14:32 -0000 Subject: [GHC] #16376: GHCi HEAD silently accepts ill-kinded visible type applications with :type Message-ID: <050.2844026e72998c0da21d307d0ec6cfc6@haskell.org> #16376: GHCi HEAD silently accepts ill-kinded visible type applications with :type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: GHCi | Version: 8.9 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you try something nonsensical like `id @Maybe` in GHCi 8.6.3, it will be properly rejected: {{{ $ ghci -XTypeApplications GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :t id @Maybe :1:5: error: • Expecting one more argument to ‘Maybe’ Expected a type, but ‘Maybe’ has kind ‘* -> *’ • In the type ‘Maybe’ In the expression: id @Maybe }}} On GHC HEAD, however, this is seemingly accepted! {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 --interactive -XTypeApplications GHCi, version 8.9.20190224: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :t id @Maybe λ> }}} No error message, just... a newline. Quite bizarre. Even more bizarrely, this phenomenon doesn't appear to happen with `:kind`: {{{ λ> :set -XDataKinds -XPolyKinds λ> type Id (a :: k) = a λ> :k Id @Maybe :1:5: error: • Expecting one more argument to ‘Maybe’ Expected a type, but ‘Maybe’ has kind ‘* -> *’ • In the first argument of ‘Id’, namely ‘Maybe’ In the type ‘Id @Maybe’ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 18:37:54 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 18:37:54 -0000 Subject: [GHC] #16376: GHCi HEAD silently accepts ill-kinded visible type applications with :type In-Reply-To: <050.2844026e72998c0da21d307d0ec6cfc6@haskell.org> References: <050.2844026e72998c0da21d307d0ec6cfc6@haskell.org> Message-ID: <065.64573abd2ea0032e0316ce362fcb6438@haskell.org> #16376: GHCi HEAD silently accepts ill-kinded visible type applications with :type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: GHCi | Version: 8.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: int-index (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 19:02:35 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 19:02:35 -0000 Subject: [GHC] #16376: GHCi HEAD silently accepts ill-kinded visible type applications with :type In-Reply-To: <050.2844026e72998c0da21d307d0ec6cfc6@haskell.org> References: <050.2844026e72998c0da21d307d0ec6cfc6@haskell.org> Message-ID: <065.3046efaccda46cd7134980322309c744@haskell.org> #16376: GHCi HEAD silently accepts ill-kinded visible type applications with :type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: GHCi | Version: 8.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) Comment: This regression was introduced in commit [https://gitlab.haskell.org/ghc/ghc/commit/5c1f268e2744fab2d36e64c163858995451d7095 5c1f268e2744fab2d36e64c163858995451d7095] (`Fail fast in solveLocalEqualities`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 19:42:31 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 19:42:31 -0000 Subject: [GHC] #15799: GHC panic (and warnings) In-Reply-To: <051.9f403c90f37670c8d3e47780b16a76ec@haskell.org> References: <051.9f403c90f37670c8d3e47780b16a76ec@haskell.org> Message-ID: <066.4b9469ef63fe0e4ddb5bba22f1e3e38e@haskell.org> #15799: GHC panic (and warnings) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.1 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed * milestone: => 8.10.1 Comment: Replying to [comment:9 RyanGlScott]: > Did that commit fix this ticket? Someone should check. I checked. It is fixed. Luckily, a test case already exists, so I'm going to just close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 19:43:58 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 19:43:58 -0000 Subject: [GHC] #15918: GHC panic from QuantifiedConstraints(?) In-Reply-To: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> References: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> Message-ID: <066.09ad9c680004f08765dd0aaac2e3462f@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 RyanGlScott): This appears to no longer happen on a recent `devel2`-flavoured GHC HEAD: {{{ GHCi, version 8.9.20190227: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( ../Bug.hs, interpreted ) ../Bug.hs:18:19: error: • Expected kind ‘(k0 -> *) -> Constraint’, but ‘[]’ has kind ‘* -> *’ • In the first argument of ‘Build’, namely ‘[]’ In an expression type signature: Build [] a In the expression: rev :: Build [] a | 18 | uu = rev :: Build [] a | ^^ }}} Should we add a test case for this and call it fixed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 22:20:56 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 22:20:56 -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.fc7f3c76c1ffd14a73d0ee0c3edd1832@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 -------------------------------------+------------------------------------- Comment (by jrp): It would be great to get 8.6.4 out, if only to fix this bug, which is a real productivity killer as I seem to need to empty my `.ghc` and `.cabal` directories and reinstall the libraries needed for whatever my project using to get going. Unless someone knows of a better workaround. {{{ Resolving dependencies... cabal: Could not resolve dependencies: [__0] trying: directory-1.3.3.2 (user goal) [__1] next goal: ghc (user goal) [__1] rejecting: ghc-8.6.3/installed-8.6... (conflict: directory==1.3.3.2, ghc => directory==1.3.3.0/installed-1.3...) [__1] rejecting: ghc-8.6.1, ghc-8.4.3, ghc-8.4.1, ghc-8.2.2, ghc-8.2.1 (constraint from user target requires ==8.6.3) [__1] fail (backjumping, conflict set: directory, ghc) After searching the rest of the dependency tree exhaustively, these were the goals I've had most trouble fulfilling: directory, ghc }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 22:33:50 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 22:33:50 -0000 Subject: [GHC] #16377: `TypeError` in a pattern should flag inaccessible code Message-ID: <047.8761a604a9aec4f3a9fe5445b08a550c@haskell.org> #16377: `TypeError` in a pattern should flag inaccessible code -------------------------------------+------------------------------------- Reporter: diatchki | 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: -------------------------------------+------------------------------------- When we pattern match, if the context ends up having a custom `TypeError`, we should probably report it, as we've essentially found some inaccessible code. At present this doesn't happen and the custom error is only triggered if the function is applied to an invalid argument. Here is an example to illustrate the issue: {{{ {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE GADTs #-} module Test where import GHC.TypeLits import Data.Kind(Constraint) type family F a :: Constraint type instance F Int = () type instance F Char = TypeError ('Text "Nope") type instance F Bool = (Int ~ Char) data T where A :: F Int => T B :: F Char => T C :: F Bool => T exhaustive :: T -> () exhaustive A = () exhaustive B = () -- this is not flagged as inaccessible, but it should -- exhaustive C = () -- this is flagged as inaccessible, as expected }}} If the match with constructor `C` is added to the program, GHC detects that this equation is inaccessible because `Int` will never match `Char`. I think that we'd like the same to happen in the second equation when we match on `B`, except we should report the custom type error, instead of GHC's message about unreachable code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 22:43:29 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 22:43:29 -0000 Subject: [GHC] #15658: strange inferred kind with TypeInType In-Reply-To: <044.5c56e4e9c5ca25f242e17058c46d6daa@haskell.org> References: <044.5c56e4e9c5ca25f242e17058c46d6daa@haskell.org> Message-ID: <059.d2cee5d309beb1cabe38fdefd6c49556@haskell.org> #15658: strange inferred kind with TypeInType -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.2 Resolution: fixed | 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): * status: patch => closed * resolution: => fixed Comment: Landed in [https://gitlab.haskell.org/ghc/ghc/commit/c26d299dc422f43b8c37da4b26da2067eedcbae8 c26d299dc422f43b8c37da4b26da2067eedcbae8]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 22:45:36 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 22:45:36 -0000 Subject: [GHC] #16326: Implement visible dependent quantification In-Reply-To: <050.f131455e14d32ddc45fc2fafca130412@haskell.org> References: <050.f131455e14d32ddc45fc2fafca130412@haskell.org> Message-ID: <065.fc6fb3ec8f8d7e85acb09a91afabcd97@haskell.org> #16326: Implement visible dependent quantification -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: GHCProposal, | VisibleDependentQuantification Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/T16326_Compile{1,2}, | dependent/should_fail/T16326_Fail{1,2,3,4,5,6,7,8,9,10,11,12}, | th/T16326_TH Blocked By: | Blocking: Related Tickets: #15658 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/378 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => dependent/should_compile/T16326_Compile{1,2}, dependent/should_fail/T16326_Fail{1,2,3,4,5,6,7,8,9,10,11,12}, th/T16326_TH * resolution: => fixed Comment: Landed in [https://gitlab.haskell.org/ghc/ghc/commit/c26d299dc422f43b8c37da4b26da2067eedcbae8 c26d299dc422f43b8c37da4b26da2067eedcbae8]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 22:47:45 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 22:47:45 -0000 Subject: [GHC] #16377: `TypeError` in a pattern should flag inaccessible code In-Reply-To: <047.8761a604a9aec4f3a9fe5445b08a550c@haskell.org> References: <047.8761a604a9aec4f3a9fe5445b08a550c@haskell.org> Message-ID: <062.ba87ec5074203c38746a7ea13459cc0a@haskell.org> #16377: `TypeError` in a pattern should flag inaccessible code -------------------------------------+------------------------------------- Reporter: diatchki | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.3 checker) | Keywords: Resolution: | PatternMatchWarnings, | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11503 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => PatternMatchWarnings, CustomTypeErrors * related: => #11503 Comment: Is this the same issue as in #11503? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 22:48:01 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 22:48:01 -0000 Subject: [GHC] #11503: TypeError woes (incl. pattern match checker) In-Reply-To: <047.92c703997fce99f046395b5c889b1ab4@haskell.org> References: <047.92c703997fce99f046395b5c889b1ab4@haskell.org> Message-ID: <062.0e8fab08dcae5bcfba864702a7875020@haskell.org> #11503: TypeError woes (incl. pattern match checker) -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternMatchWarnings, | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #14141, #16377 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #14141 => #14141, #16377 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 22:55:36 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 22:55:36 -0000 Subject: [GHC] #16377: `TypeError` in a pattern should flag inaccessible code In-Reply-To: <047.8761a604a9aec4f3a9fe5445b08a550c@haskell.org> References: <047.8761a604a9aec4f3a9fe5445b08a550c@haskell.org> Message-ID: <062.3fe7ff940319a2eeaf9d8e9e74b8b896@haskell.org> #16377: `TypeError` in a pattern should flag inaccessible code -------------------------------------+------------------------------------- Reporter: diatchki | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.3 checker) | Keywords: Resolution: duplicate | PatternMatchWarnings, | CustomTypeErrors Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11503 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by diatchki): * status: new => closed * resolution: => duplicate Comment: Ah, yes. I am marking it as a duplicate of #11503. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 23:46:07 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 23:46:07 -0000 Subject: [GHC] #15658: strange inferred kind with TypeInType In-Reply-To: <044.5c56e4e9c5ca25f242e17058c46d6daa@haskell.org> References: <044.5c56e4e9c5ca25f242e17058c46d6daa@haskell.org> Message-ID: <059.b0c4a373311c34c6356a57f87a84ccf5@haskell.org> #15658: strange inferred kind with TypeInType -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.2 Resolution: fixed | 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 -------------------------------------+------------------------------------- Comment (by simonpj): Should we have a regression test here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 1 23:47:43 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 01 Mar 2019 23:47:43 -0000 Subject: [GHC] #15658: strange inferred kind with TypeInType In-Reply-To: <044.5c56e4e9c5ca25f242e17058c46d6daa@haskell.org> References: <044.5c56e4e9c5ca25f242e17058c46d6daa@haskell.org> Message-ID: <059.80f437670db04691f1e1ad6cf54d5980@haskell.org> #15658: strange inferred kind with TypeInType -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.2 Resolution: fixed | 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 -------------------------------------+------------------------------------- Comment (by RyanGlScott): No. This ticket is specifically about the users' guide. #16326 tracks the actual implementation side of things, and makes mention of the relevant regression tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 2 02:04:02 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Mar 2019 02:04:02 -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.236ce006c41e10f8266ffd00f2848a11@haskell.org> #14069: RTS linker maps code as writable -------------------------------------+------------------------------------- Reporter: bgamari | Owner: rockbmb Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Runtime System | Version: 8.0.1 (Linker) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4817 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rockbmb): * owner: (none) => rockbmb -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 2 02:09:14 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Mar 2019 02:09:14 -0000 Subject: [GHC] #16378: bkpcabal01 fails with recent Cabal Message-ID: <046.6dbe508947082fe98f8d1db57ed7604b@haskell.org> #16378: bkpcabal01 fails with recent Cabal -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 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: -------------------------------------+------------------------------------- After bumping `Cabal` on the `ghc-8.8` branch `bkpcabal01` fails: {{{ =====> bkpcabal01(normal) 85 of 6807 [0, 0, 0] cd "backpack/cabal/bkpcabal01/bkpcabal01.run" && $MAKE -s --no-print- directory bkpcabal01 CLEANUP=1 Wrong exit code for bkpcabal01()(expected 0 , actual 2 ) Stdout ( bkpcabal01 ): Makefile:9: recipe for target 'bkpcabal01' failed Stderr ( bkpcabal01 ): Error: The following packages are broken because other packages they depend on are missing. These broken packages must be rebuilt before they can be used. planned package bkpcabal01-0.1.0.0 is broken due to missing package p-0.1+FBOSaiWyMx9DR2UZVI6wQJ }}} Anyone know what is going on here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 2 04:01:42 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Mar 2019 04:01:42 -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.d3f92f86a5c84170a46a49f5ebdcd7c9@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: | -------------------------------------+----------------------------------- Comment (by bgamari): I have also seen it fail in a similarly-looking mode on x86-64 when building GHC with LLVM: {{{ Wrong exit code for heapprof001(prof_hc_hb)(expected 0 , actual 134 ) Stdout ( heapprof001 ): a <= a <= a <= a <= a <= a <= a <= Stderr ( heapprof001 ): heapprof001: internal error: LDV_recordDead: Failed to find counter for closure 0x42000af050 (GHC version 8.9.20190225 for x86_64_unknown_linux) Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug Aborted (core dumped) *** unexpected failure for heapprof001(prof_hc_hb) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 2 07:22:19 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Mar 2019 07:22:19 -0000 Subject: [GHC] #15857: Need for better warnings arising from StarIsType extension In-Reply-To: <042.ac2cb7754b32f4dedfcfabfb3e5b7bb2@haskell.org> References: <042.ac2cb7754b32f4dedfcfabfb3e5b7bb2@haskell.org> Message-ID: <057.dfc459793a4c0894acf28bf38119d66a@haskell.org> #15857: Need for better warnings arising from StarIsType extension -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: StarIsType | NoStarIsType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): I designed `-Wstar-binder` specifically for this purpose, and it is enabled by default. {{{ Prelude> :set -XTypeOperators Prelude> type (*) = (,) :2:7: warning: [-Wstar-binder] Found binding occurrence of ‘*’ yet StarIsType is enabled. NB. To use (or export) this operator in modules with StarIsType, including the definition module, you must qualify it. }}} Are you not seeing it for some reason or do you think the wording needs improvement? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 2 10:40:38 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Mar 2019 10:40:38 -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.04676b2ee0051a2665c5a8ad5cc210aa@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: | -------------------------------------+----------------------------------- Comment (by RyanGlScott): I believe the failure in comment:11 has been previously reported as #16100. It's worth noting that two other tests besides `heapprof001` (`T11627a` and `T949`) have also been observed to exhibit this `LDV_recordDead` panic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 2 13:57:28 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Mar 2019 13:57:28 -0000 Subject: [GHC] #16379: JuicyPixels build panics on s390x ghc-8.4.4 Message-ID: <050.2346d71c3b0efe4bb40361f2c870b04a@haskell.org> #16379: JuicyPixels build panics on s390x ghc-8.4.4 -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Keywords: | Operating System: Linux Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I try to build JuicyPixels on Fedora s390x Linux with ghc-8.4.4 I get a compiler panic: {{{ [ 9 of 30] Compiling Codec.Picture.ColorQuant ( src/Codec/Picture/ColorQuant.hs, dist/build/Codec/Picture/ColorQuant.o ) BUILDSTDERR: src/Codec/Picture/ColorQuant.hs:123:26: warning: [-Woverflowed-literals] BUILDSTDERR: Literal 256 is out of the GHC.Word.Word8 range 0..255 BUILDSTDERR: | BUILDSTDERR: 123 | (PixelRGB8 (r .&. (256 - dr)) (g .&. (256 - dg)) (b .&. (256 - db))) BUILDSTDERR: | ^^^ BUILDSTDERR: src/Codec/Picture/ColorQuant.hs:123:45: warning: [-Woverflowed-literals] BUILDSTDERR: Literal 256 is out of the GHC.Word.Word8 range 0..255 BUILDSTDERR: | BUILDSTDERR: 123 | (PixelRGB8 (r .&. (256 - dr)) (g .&. (256 - dg)) (b .&. (256 - db))) BUILDSTDERR: | ^^^ BUILDSTDERR: src/Codec/Picture/ColorQuant.hs:123:64: warning: [-Woverflowed-literals] BUILDSTDERR: Literal 256 is out of the GHC.Word.Word8 range 0..255 BUILDSTDERR: | BUILDSTDERR: 123 | (PixelRGB8 (r .&. (256 - dr)) (g .&. (256 - dg)) (b .&. (256 - db))) BUILDSTDERR: | ^^^ BUILDSTDERR: ghc: panic! (the 'impossible' happened) BUILDSTDERR: (GHC version 8.4.4 for s390x-ibm-linux): BUILDSTDERR: pprStatics: float BUILDSTDERR: F32 BUILDSTDERR: F32 BUILDSTDERR: I32 BUILDSTDERR: Call stack: BUILDSTDERR: CallStack (from HasCallStack): BUILDSTDERR: callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable BUILDSTDERR: pprPanic, called at compiler/cmm/PprC.hs:525:5 in ghc:PprC BUILDSTDERR: Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I would test on ghc-8.6.3 too, but I haven't been able to build ghc-8.6 yet on s390x (unregisterized on unregisterized): see issue 15913. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 2 13:58:20 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Mar 2019 13:58:20 -0000 Subject: [GHC] #16379: JuicyPixels build panics on s390x ghc-8.4.4 In-Reply-To: <050.2346d71c3b0efe4bb40361f2c870b04a@haskell.org> References: <050.2346d71c3b0efe4bb40361f2c870b04a@haskell.org> Message-ID: <065.c03e5e4cffab9b0b8a5819040707f295@haskell.org> #16379: JuicyPixels build panics on s390x ghc-8.4.4 -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by juhpetersen): * architecture: Unknown/Multiple => Other -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 2 13:59:27 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Mar 2019 13:59:27 -0000 Subject: [GHC] #16379: JuicyPixels build panics on s390x ghc-8.4.4 In-Reply-To: <050.2346d71c3b0efe4bb40361f2c870b04a@haskell.org> References: <050.2346d71c3b0efe4bb40361f2c870b04a@haskell.org> Message-ID: <065.01546b7f7773aa0282a57fde16050395@haskell.org> #16379: JuicyPixels build panics on s390x ghc-8.4.4 -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by juhpetersen: Old description: > When I try to build JuicyPixels on Fedora s390x Linux with ghc-8.4.4 > I get a compiler panic: > > {{{ > [ 9 of 30] Compiling Codec.Picture.ColorQuant ( > src/Codec/Picture/ColorQuant.hs, dist/build/Codec/Picture/ColorQuant.o ) > BUILDSTDERR: src/Codec/Picture/ColorQuant.hs:123:26: warning: > [-Woverflowed-literals] > BUILDSTDERR: Literal 256 is out of the GHC.Word.Word8 range 0..255 > BUILDSTDERR: | > BUILDSTDERR: 123 | (PixelRGB8 (r .&. (256 - dr)) (g .&. (256 - dg)) > (b .&. (256 - db))) > BUILDSTDERR: | ^^^ > BUILDSTDERR: src/Codec/Picture/ColorQuant.hs:123:45: warning: > [-Woverflowed-literals] > BUILDSTDERR: Literal 256 is out of the GHC.Word.Word8 range 0..255 > BUILDSTDERR: | > BUILDSTDERR: 123 | (PixelRGB8 (r .&. (256 - dr)) (g .&. (256 - dg)) > (b .&. (256 - db))) > BUILDSTDERR: | ^^^ > BUILDSTDERR: src/Codec/Picture/ColorQuant.hs:123:64: warning: > [-Woverflowed-literals] > BUILDSTDERR: Literal 256 is out of the GHC.Word.Word8 range 0..255 > BUILDSTDERR: | > BUILDSTDERR: 123 | (PixelRGB8 (r .&. (256 - dr)) (g .&. (256 - dg)) > (b .&. (256 - db))) > BUILDSTDERR: | > ^^^ > BUILDSTDERR: ghc: panic! (the 'impossible' happened) > BUILDSTDERR: (GHC version 8.4.4 for s390x-ibm-linux): > BUILDSTDERR: pprStatics: float > BUILDSTDERR: F32 > BUILDSTDERR: F32 > BUILDSTDERR: I32 > BUILDSTDERR: Call stack: > BUILDSTDERR: CallStack (from HasCallStack): > BUILDSTDERR: callStackDoc, called at > compiler/utils/Outputable.hs:1150:37 in ghc:Outputable > BUILDSTDERR: pprPanic, called at compiler/cmm/PprC.hs:525:5 in > ghc:PprC > BUILDSTDERR: Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > }}} > > I would test on ghc-8.6.3 too, but I haven't been able to build ghc-8.6 > yet on s390x (unregisterized on unregisterized): see issue 15913. New description: When I try to build JuicyPixels on Fedora s390x Linux, ghc-8.4.4 panics: {{{ [ 9 of 30] Compiling Codec.Picture.ColorQuant ( src/Codec/Picture/ColorQuant.hs, dist/build/Codec/Picture/ColorQuant.o ) BUILDSTDERR: src/Codec/Picture/ColorQuant.hs:123:26: warning: [-Woverflowed-literals] BUILDSTDERR: Literal 256 is out of the GHC.Word.Word8 range 0..255 BUILDSTDERR: | BUILDSTDERR: 123 | (PixelRGB8 (r .&. (256 - dr)) (g .&. (256 - dg)) (b .&. (256 - db))) BUILDSTDERR: | ^^^ BUILDSTDERR: src/Codec/Picture/ColorQuant.hs:123:45: warning: [-Woverflowed-literals] BUILDSTDERR: Literal 256 is out of the GHC.Word.Word8 range 0..255 BUILDSTDERR: | BUILDSTDERR: 123 | (PixelRGB8 (r .&. (256 - dr)) (g .&. (256 - dg)) (b .&. (256 - db))) BUILDSTDERR: | ^^^ BUILDSTDERR: src/Codec/Picture/ColorQuant.hs:123:64: warning: [-Woverflowed-literals] BUILDSTDERR: Literal 256 is out of the GHC.Word.Word8 range 0..255 BUILDSTDERR: | BUILDSTDERR: 123 | (PixelRGB8 (r .&. (256 - dr)) (g .&. (256 - dg)) (b .&. (256 - db))) BUILDSTDERR: | ^^^ BUILDSTDERR: ghc: panic! (the 'impossible' happened) BUILDSTDERR: (GHC version 8.4.4 for s390x-ibm-linux): BUILDSTDERR: pprStatics: float BUILDSTDERR: F32 BUILDSTDERR: F32 BUILDSTDERR: I32 BUILDSTDERR: Call stack: BUILDSTDERR: CallStack (from HasCallStack): BUILDSTDERR: callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable BUILDSTDERR: pprPanic, called at compiler/cmm/PprC.hs:525:5 in ghc:PprC BUILDSTDERR: Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I would test on ghc-8.6.3 too, but I haven't been able to build ghc-8.6 yet on s390x (unregisterized on unregisterized): see issue 15913. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 2 14:00:15 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Mar 2019 14:00:15 -0000 Subject: [GHC] #16379: JuicyPixels build panics on s390x ghc-8.4.4 In-Reply-To: <050.2346d71c3b0efe4bb40361f2c870b04a@haskell.org> References: <050.2346d71c3b0efe4bb40361f2c870b04a@haskell.org> Message-ID: <065.e89125ac50f1cc237cf0e6db244e9e9f@haskell.org> #16379: JuicyPixels build panics on s390x ghc-8.4.4 -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by juhpetersen: Old description: > When I try to build JuicyPixels on Fedora s390x Linux, ghc-8.4.4 panics: > > {{{ > [ 9 of 30] Compiling Codec.Picture.ColorQuant ( > src/Codec/Picture/ColorQuant.hs, dist/build/Codec/Picture/ColorQuant.o ) > BUILDSTDERR: src/Codec/Picture/ColorQuant.hs:123:26: warning: > [-Woverflowed-literals] > BUILDSTDERR: Literal 256 is out of the GHC.Word.Word8 range 0..255 > BUILDSTDERR: | > BUILDSTDERR: 123 | (PixelRGB8 (r .&. (256 - dr)) (g .&. (256 - dg)) > (b .&. (256 - db))) > BUILDSTDERR: | ^^^ > BUILDSTDERR: src/Codec/Picture/ColorQuant.hs:123:45: warning: > [-Woverflowed-literals] > BUILDSTDERR: Literal 256 is out of the GHC.Word.Word8 range 0..255 > BUILDSTDERR: | > BUILDSTDERR: 123 | (PixelRGB8 (r .&. (256 - dr)) (g .&. (256 - dg)) > (b .&. (256 - db))) > BUILDSTDERR: | ^^^ > BUILDSTDERR: src/Codec/Picture/ColorQuant.hs:123:64: warning: > [-Woverflowed-literals] > BUILDSTDERR: Literal 256 is out of the GHC.Word.Word8 range 0..255 > BUILDSTDERR: | > BUILDSTDERR: 123 | (PixelRGB8 (r .&. (256 - dr)) (g .&. (256 - dg)) > (b .&. (256 - db))) > BUILDSTDERR: | > ^^^ > BUILDSTDERR: ghc: panic! (the 'impossible' happened) > BUILDSTDERR: (GHC version 8.4.4 for s390x-ibm-linux): > BUILDSTDERR: pprStatics: float > BUILDSTDERR: F32 > BUILDSTDERR: F32 > BUILDSTDERR: I32 > BUILDSTDERR: Call stack: > BUILDSTDERR: CallStack (from HasCallStack): > BUILDSTDERR: callStackDoc, called at > compiler/utils/Outputable.hs:1150:37 in ghc:Outputable > BUILDSTDERR: pprPanic, called at compiler/cmm/PprC.hs:525:5 in > ghc:PprC > BUILDSTDERR: Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > }}} > > I would test on ghc-8.6.3 too, but I haven't been able to build ghc-8.6 > yet on s390x (unregisterized on unregisterized): see issue 15913. New description: When I try to build JuicyPixels-3.2.9.5 on Fedora s390x Linux, ghc-8.4.4 panics: {{{ [ 9 of 30] Compiling Codec.Picture.ColorQuant ( src/Codec/Picture/ColorQuant.hs, dist/build/Codec/Picture/ColorQuant.o ) BUILDSTDERR: src/Codec/Picture/ColorQuant.hs:123:26: warning: [-Woverflowed-literals] BUILDSTDERR: Literal 256 is out of the GHC.Word.Word8 range 0..255 BUILDSTDERR: | BUILDSTDERR: 123 | (PixelRGB8 (r .&. (256 - dr)) (g .&. (256 - dg)) (b .&. (256 - db))) BUILDSTDERR: | ^^^ BUILDSTDERR: src/Codec/Picture/ColorQuant.hs:123:45: warning: [-Woverflowed-literals] BUILDSTDERR: Literal 256 is out of the GHC.Word.Word8 range 0..255 BUILDSTDERR: | BUILDSTDERR: 123 | (PixelRGB8 (r .&. (256 - dr)) (g .&. (256 - dg)) (b .&. (256 - db))) BUILDSTDERR: | ^^^ BUILDSTDERR: src/Codec/Picture/ColorQuant.hs:123:64: warning: [-Woverflowed-literals] BUILDSTDERR: Literal 256 is out of the GHC.Word.Word8 range 0..255 BUILDSTDERR: | BUILDSTDERR: 123 | (PixelRGB8 (r .&. (256 - dr)) (g .&. (256 - dg)) (b .&. (256 - db))) BUILDSTDERR: | ^^^ BUILDSTDERR: ghc: panic! (the 'impossible' happened) BUILDSTDERR: (GHC version 8.4.4 for s390x-ibm-linux): BUILDSTDERR: pprStatics: float BUILDSTDERR: F32 BUILDSTDERR: F32 BUILDSTDERR: I32 BUILDSTDERR: Call stack: BUILDSTDERR: CallStack (from HasCallStack): BUILDSTDERR: callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable BUILDSTDERR: pprPanic, called at compiler/cmm/PprC.hs:525:5 in ghc:PprC BUILDSTDERR: Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I would test on ghc-8.6.3 too, but I haven't been able to build ghc-8.6 yet on s390x (unregisterized on unregisterized): see issue 15913. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 2 14:15:14 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Mar 2019 14:15:14 -0000 Subject: [GHC] #16379: JuicyPixels build panics on s390x ghc-8.4.4 In-Reply-To: <050.2346d71c3b0efe4bb40361f2c870b04a@haskell.org> References: <050.2346d71c3b0efe4bb40361f2c870b04a@haskell.org> Message-ID: <065.16fd92e68b953857f7988a3563bb2078@haskell.org> #16379: JuicyPixels build panics on s390x ghc-8.4.4 -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by juhpetersen): Apparently Debian Haskell worked around this with -O0 on unregisterized builds... https://packages.debian.org/sid/libghc-juicypixels-dev {{{ haskell-juicypixels (3.2.9.5-4) unstable; urgency=medium * Compile with --ghc-options="-O0" on unregisterised 64-bit arches to work-around a GHC bug. -- Ilias Tsitsimpis Wed, 07 Nov 2018 11:36:59 +0200 }}} So assuming this was already reported this is probably duplicate bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 2 15:58:10 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Mar 2019 15:58:10 -0000 Subject: [GHC] #16379: JuicyPixels build panics on s390x ghc-8.4.4 In-Reply-To: <050.2346d71c3b0efe4bb40361f2c870b04a@haskell.org> References: <050.2346d71c3b0efe4bb40361f2c870b04a@haskell.org> Message-ID: <065.ea593f2a59d4ac3887762f5ad4f98f59@haskell.org> #16379: JuicyPixels build panics on s390x ghc-8.4.4 -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: Linux | Architecture: Other Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): This is most likely #15853. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 2 16:07:22 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Mar 2019 16:07:22 -0000 Subject: [GHC] #16303: checkStack sanity check fails In-Reply-To: <043.5c62864ddc74f11e27dba9e7181f6bec@haskell.org> References: <043.5c62864ddc74f11e27dba9e7181f6bec@haskell.org> Message-ID: <058.80c0fdc15a9c8085330c5527d2942695@haskell.org> #16303: checkStack sanity check fails -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: merge 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 monoidal): * status: patch => merge Comment: I think this can be merged to 8.8 (commit 6b890d76). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 2 16:50:32 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Mar 2019 16:50:32 -0000 Subject: [GHC] #16380: HPC's CLI is awkward Message-ID: <049.74166a81015a8b834ea1591f0de5eab6@haskell.org> #16380: HPC's CLI is awkward -------------------------------------+------------------------------------- Reporter: MaxGabriel | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Code Coverage | 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: -------------------------------------+------------------------------------- hpc's command line interface could be brought more in line with other Haskell tools (and most CLIs I've used). I would expect all of the following commands to work: {{{ hpc --version hpc --help hpc markup --help }}} Currently these commands are: {{{ hpc version hpc help hpc help markup }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 2 18:39:24 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 02 Mar 2019 18:39:24 -0000 Subject: [GHC] #16303: checkStack sanity check fails In-Reply-To: <043.5c62864ddc74f11e27dba9e7181f6bec@haskell.org> References: <043.5c62864ddc74f11e27dba9e7181f6bec@haskell.org> Message-ID: <058.9209fee11c5587692ea381b60b1c18f4@haskell.org> #16303: checkStack sanity check fails -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 3 10:52:41 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Mar 2019 10:52: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.f51a0c049b18f88df6562d370f123f89@haskell.org> #13002: :set -O does not work in .ghci file -------------------------------------+------------------------------------- Reporter: George | Owner: RolandSenn Type: bug | Status: patch 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: T13002 Blocked By: | Blocking: Related Tickets: #8635 #9370 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/480 -------------------------------------+------------------------------------- Changes (by RolandSenn): * status: new => patch * testcase: => T13002 * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/480 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 3 11:00:52 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Mar 2019 11:00:52 -0000 Subject: [GHC] #12847: ghci -fobject-code -O2 doesn't do the same optimisations as ghc --make -O2 In-Reply-To: <042.ae1a4a171fe54fc9b54d80da6024e345@haskell.org> References: <042.ae1a4a171fe54fc9b54d80da6024e345@haskell.org> Message-ID: <057.dc8d96e6c417ab5ecbf89dea7d91fee0@haskell.org> #12847: ghci -fobject-code -O2 doesn't do the same optimisations as ghc --make -O2 -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: duplicate | Keywords: Operating System: Other | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * status: new => closed * resolution: => duplicate Comment: This is the same bug as in #13002. During startup without a -O flag on the command line, GHCi misses to store optimization data (like inline pragmas and rewrite rules). After a :set -O2 this optimization data is missing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 3 13:26:04 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Mar 2019 13:26:04 -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.869fd67355612753f031ec2d012713b9@haskell.org> #13002: :set -O does not work in .ghci file -------------------------------------+------------------------------------- Reporter: George | Owner: RolandSenn Type: bug | Status: patch 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: T13002 Blocked By: | Blocking: Related Tickets: #8635 #9370 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/480 -------------------------------------+------------------------------------- Changes (by nh2): * cc: nh2 (added) Comment: Subscribing since #12847 was marked as a duplicate of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 3 13:31:02 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Mar 2019 13:31:02 -0000 Subject: [GHC] #16363: Modular constant folding In-Reply-To: <045.a4a4cac9ce41785be0aa7ca965d6a043@haskell.org> References: <045.a4a4cac9ce41785be0aa7ca965d6a043@haskell.org> Message-ID: <060.4d587e518f345f94edb689fdc6272e25@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 hsyl20: 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. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 3 13:37:00 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Mar 2019 13:37:00 -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.8c0d696ec2d4ca00def69dca09e3bdc1@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): > 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. Hmm in fact it won't work for non integral `Num` types (e.g., Double)... Maybe we could add another function (`ipow`?) to `Integral` instead and add rules to convert `(^)` into `ipow` for known cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 3 15:16:28 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Mar 2019 15:16:28 -0000 Subject: [GHC] #16380: HPC's CLI is awkward In-Reply-To: <049.74166a81015a8b834ea1591f0de5eab6@haskell.org> References: <049.74166a81015a8b834ea1591f0de5eab6@haskell.org> Message-ID: <064.b340b63466048db530be7450b11d2b09@haskell.org> #16380: HPC's CLI is awkward -------------------------------------+------------------------------------- Reporter: MaxGabriel | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Code Coverage | 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): Indeed HPC could use some love. It would be great if someone could offer to look after it. It's just a standard (albeit a bit dated) Haskell executable so anyone able to use GHC should be able pick it up without any trouble. Alternatively, I have long wondered whether GHC should even be in the business of offering tools like `hpc` and `hp2ps`. I rather wonder whether we might not be better off simply doing a better job of documenting the formats and interfaces exposed by GHC and leave the tooling to be provided by Hackage packages. In the case of `hp2ps`, this may already be the case: I nearly always use `hp2pretty` instead of `hp2ps` and I suspect I'm not the only one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 3 19:26:25 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Mar 2019 19:26:25 -0000 Subject: [GHC] #16381: Regression: Implicitly kind variables not in scope Message-ID: <046.395d0c5be64b4d957cb5bc8ed0f28f37@haskell.org> #16381: Regression: Implicitly kind variables not in scope -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.10.1 Component: Compiler | Version: 8.9 (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: -------------------------------------+------------------------------------- Our new `head.hackage` CI infrastructure has caught its first regression, it seems. A number of packages now fail to build due to out-of-scope kind variables. For instance, `singleton-bool`: {{{ [1 of 1] Compiling Data.Singletons.Bool ( src/Data/Singletons/Bool.hs, dist/build/Data/Singletons/Bool.o ) *** Parser [Data.Singletons.Bool]: Parser [Data.Singletons.Bool]: alloc=4264704 time=6.901 *** Renamer/typechecker [Data.Singletons.Bool]: Renamer/typechecker [Data.Singletons.Bool]: alloc=17554720 time=92.794 src/Data/Singletons/Bool.hs:119:29: error: Not in scope: type variable ‘k’ | 119 | sboolEqRefl :: forall (a :: k) (b :: k). SBoolI (a == b) => Maybe (a :~: b) | ^ src/Data/Singletons/Bool.hs:119:38: error: Not in scope: type variable ‘k’ | 119 | sboolEqRefl :: forall (a :: k) (b :: k). SBoolI (a == b) => Maybe (a :~: b) | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 3 19:39:46 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Mar 2019 19:39:46 -0000 Subject: [GHC] #16381: Regression: Implicitly kind variables not in scope In-Reply-To: <046.395d0c5be64b4d957cb5bc8ed0f28f37@haskell.org> References: <046.395d0c5be64b4d957cb5bc8ed0f28f37@haskell.org> Message-ID: <061.30599f0d1cec013cee9e6e78e0c731ba@haskell.org> #16381: Regression: Implicitly kind variables not in scope -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.9 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid Comment: Ahh, of course. This is actually expected as fall-out from [[https://github.com/ghc-proposals/ghc- proposals/blob/master/proposals/0024-no-kind-vars.rst|Proposal 0024]] (#15264). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 3 20:05:09 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Mar 2019 20:05:09 -0000 Subject: [GHC] #16320: Clean up printing of foralls In-Reply-To: <047.409f8fb8202cb591e7e03bb215b26444@haskell.org> References: <047.409f8fb8202cb591e7e03bb215b26444@haskell.org> Message-ID: <062.ca40f8792e845aa7d7dc46c0d37494c8@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 bgamari: 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. 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`. 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 Sun Mar 3 20:32:56 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Mar 2019 20:32:56 -0000 Subject: [GHC] #16381: Regression: Implicitly kind variables not in scope In-Reply-To: <046.395d0c5be64b4d957cb5bc8ed0f28f37@haskell.org> References: <046.395d0c5be64b4d957cb5bc8ed0f28f37@haskell.org> Message-ID: <061.c624da576a712cba5da5197795b69b60@haskell.org> #16381: Regression: Implicitly kind variables not in scope -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.9 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): See also https://github.com/hvr/head.hackage/commit/8db44df47e6ca07ea2f8140dfa672d0f9f542ac7, which patches `singleton-bool` in the upstream `head.hackage` repo. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 3 20:34:26 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Mar 2019 20:34:26 -0000 Subject: [GHC] #10841: Run handler on STM retry In-Reply-To: <045.10ea2aa941550aac6248eb677ce6a5a6@haskell.org> References: <045.10ea2aa941550aac6248eb677ce6a5a6@haskell.org> Message-ID: <060.3d5763ef0e3f8b2dfdcc5ac18bf7b6c5@haskell.org> #10841: Run handler on STM retry -------------------------------------+------------------------------------- Reporter: shlevy | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/stm | Version: 7.10.2 Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * component: libraries (other) => libraries/stm -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 3 20:34:35 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Mar 2019 20:34:35 -0000 Subject: [GHC] #14494: TBQueue leaks space under certain workloads In-Reply-To: <047.f58f0c7c928ab79f4f0451929939d250@haskell.org> References: <047.f58f0c7c928ab79f4f0451929939d250@haskell.org> Message-ID: <062.539b04284454e55dd998b70a5fbb1bc0@haskell.org> #14494: TBQueue leaks space under certain workloads -------------------------------------+------------------------------------- Reporter: arybczak | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/stm | Version: 8.2.1 Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * component: libraries (other) => libraries/stm -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 3 20:35:51 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Mar 2019 20:35:51 -0000 Subject: [GHC] #3094: Some GHC.* module should export word size and heap object header size In-Reply-To: <045.907bdf02870cf9d7a457cb5fba873bca@haskell.org> References: <045.907bdf02870cf9d7a457cb5fba873bca@haskell.org> Message-ID: <060.aa4553d61bb059d43f61063c57594483@haskell.org> #3094: Some GHC.* module should export word size and heap object header size -------------------------------------+------------------------------------- Reporter: duncan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 6.10.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It seems to me like the new `ghc-heap` package would be a good place for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 3 21:25:45 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Mar 2019 21:25:45 -0000 Subject: [GHC] #16382: Lifting a function from where clause to top level causes compilation time to triple Message-ID: <047.f115fde4abf47851af1284e52faf12ea@haskell.org> #16382: Lifting a function from where clause to top level causes compilation time to triple -------------------------------------+------------------------------------- Reporter: danidiaz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have this program that depends on the library "red-black-record" version 2.0.2.2 on Hackage: {{{#!hs {-# LANGUAGE DataKinds, TypeApplications #-} module Main where import Data.RBR (FromList,Delete,Variant,I,injectI,winnowI,match) import GHC.TypeLits type Phase01 = FromList '[ '("ctor1",Int), '("ctor2",Bool), '("ctor4",Char), '("ctor3",Char), '("ctor6",Char), '("ctor5",Char), '("ctor10",Char), '("ctor11",Char), '("ctor13",Char), '("ctor14",Char), '("ctor39",Char), '("ctor46",Char), '("ctor47",Char), '("ctor44",Char), '("ctor43",Char), '("ctor7",Char), '("ctor9",Char), '("ctor20",Char), '("ctor45",Char), '("ctor21",Char), '("ctor48",Char), '("ctor49",Char), '("ctor50",Char), '("ctor41",Char), '("ctor33",Char), '("ctor32",Char), '("ctor42",Char), '("ctor22",Char), '("ctor23",Char), '("ctor8",Char), '("ctor40",Char), '("ctor29",Char), '("ctor24",Char), '("ctor38",Char), '("ctor25",Char), '("ctor26",Char), '("ctor27",Char), '("ctor28",Char), '("ctor36",Char), '("ctor52",Char), '("ctor51",Char), '("ctor53",Char), '("ctor12",Char), '("ctor54",Char), '("ctor15",Char), '("ctor31",Char), '("ctor30",Char), '("ctor34",Char), '("ctor35",Char), '("ctor17",Char), '("ctor16",Char), '("ctor18",Char), '("ctor19",Char), '("ctor37",Char) ] type Phase02 = Delete "ctor1" Int Phase01 main :: IO () main = print (match @"ctor17" (fromPhase1ToPhase2 (injectI @"ctor1" 2))) where fromPhase1ToPhase2 :: Variant I Phase01 -> Variant I Phase02 fromPhase1ToPhase2 v = case winnowI @"ctor1" @Int v of Right z -> injectI @"ctor2" False Left l -> l }}} "red-black-record" provides extensible variants; the code is basically removing a branch from a variant with 50-plus branches, and then trying to match another branch. It is type family-heavy code. The code as it is takes **~9 seconds** to compile on my machine. But when I move the `fromPhase1ToPhase2` function to the top level (including the signature) compilation time balloons to **~29 seconds**. Is there a reason it should be so? As another datapoint, moving the function to the top level but omitting the complex type-level map parameters (`Phase01`, `Phase02`) using partial type signatures (also requires a new type application) compiles in **~9 seconds** again. {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} {-# OPTIONS_GHC -Wno-partial-type-signatures #-} -- ... type Phase02 = Delete "ctor1" Int Phase01 fromPhase1ToPhase2 :: Variant I _ -> Variant I _ fromPhase1ToPhase2 v = case winnowI @"ctor1" @Int @Phase01 v of Right z -> injectI @"ctor2" False Left l -> l main :: IO () main = print (match @"ctor17" (fromPhase1ToPhase2 (injectI @"ctor1" 2))) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 3 22:17:29 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Mar 2019 22:17:29 -0000 Subject: [GHC] #16382: Lifting a function from where clause to top level causes compilation time to triple In-Reply-To: <047.f115fde4abf47851af1284e52faf12ea@haskell.org> References: <047.f115fde4abf47851af1284e52faf12ea@haskell.org> Message-ID: <062.a69795e9b09374882899ae867f4dc83f@haskell.org> #16382: Lifting a function from where clause to top level causes compilation time to triple -------------------------------------+------------------------------------- Reporter: danidiaz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by danidiaz): * Attachment "Main.hs" added. A self-contained example with no dependencies, that includes the relevant portions of the library. The code for reproducing the bug is at the end of the file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 3 22:54:22 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 03 Mar 2019 22:54:22 -0000 Subject: [GHC] #14494: TBQueue leaks space under certain workloads In-Reply-To: <047.f58f0c7c928ab79f4f0451929939d250@haskell.org> References: <047.f58f0c7c928ab79f4f0451929939d250@haskell.org> Message-ID: <062.dd448519d16cc20891caa84a05ed9846@haskell.org> #14494: TBQueue leaks space under certain workloads -------------------------------------+------------------------------------- Reporter: arybczak | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/stm | Version: 8.2.1 Resolution: fixed | Keywords: stm Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by arybczak): * status: patch => closed * resolution: => fixed Comment: It was fixed by https://github.com/haskell/stm/pull/2 some time ago. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 01:09:07 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 01:09:07 -0000 Subject: [GHC] #15461: Machine accessible interface to GHCi In-Reply-To: <046.c2d301970bbdff7b63fe4e2523868200@haskell.org> References: <046.c2d301970bbdff7b63fe4e2523868200@haskell.org> Message-ID: <061.9c80ecb0d9f5066178c3463a3f2acd9a@haskell.org> #15461: Machine accessible interface to GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.10.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by redneb): * cc: redneb (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 02:46:29 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 02:46:29 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.1fc37bdcdaa7ea74cf7fd82fffdfeca5@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: fixed | Keywords: DWARF Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => DWARF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 02:46:41 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 02:46:41 -0000 Subject: [GHC] #15960: Using -g causes differences in generated core. In-Reply-To: <047.b0af08dc8e4461a81e2c6c6cbd0feffe@haskell.org> References: <047.b0af08dc8e4461a81e2c6c6cbd0feffe@haskell.org> Message-ID: <062.58c53619e28f6ac149377c534b760f4a@haskell.org> #15960: Using -g causes differences in generated core. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: DWARF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => DWARF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 02:47:51 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 02:47:51 -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.94a63a1e2866c2153e49904a53281ae9@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: DWARF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => DWARF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 02:47:58 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 02:47:58 -0000 Subject: [GHC] #15967: can't build ghc on Mac with any level of dwarf for base library In-Reply-To: <045.1f8e3d51a3d6115f41b9b4a7e03b9050@haskell.org> References: <045.1f8e3d51a3d6115f41b9b4a7e03b9050@haskell.org> Message-ID: <060.558cfaef264e47fba05206b0bb1d4592@haskell.org> #15967: can't build ghc on Mac with any level of dwarf for base library -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.6.2 (CodeGen) | Resolution: | Keywords: DWARF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => DWARF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 02:48:24 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 02:48:24 -0000 Subject: [GHC] #16045: improve dwarf support on OSX In-Reply-To: <045.be17bf532e4b53e661b034b9d4ca26bb@haskell.org> References: <045.be17bf532e4b53e661b034b9d4ca26bb@haskell.org> Message-ID: <060.c3a9a345d0a56306e94d543f776ab2c5@haskell.org> #16045: improve dwarf support on OSX ---------------------------------+-------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: DWARF Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * keywords: => DWARF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 02:48:42 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 02:48:42 -0000 Subject: [GHC] #15889: ghc documentation doesn't explain difference between dwarf levels 1 2 and 3 In-Reply-To: <045.ab3fe7a26edf38924c1d1e51505427fa@haskell.org> References: <045.ab3fe7a26edf38924c1d1e51505427fa@haskell.org> Message-ID: <060.4017406655fc5e1e6c51cc6729dd2512@haskell.org> #15889: ghc documentation doesn't explain difference between dwarf levels 1 2 and 3 -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.2 Resolution: | Keywords: DWARF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => DWARF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 02:49:45 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 02:49:45 -0000 Subject: [GHC] #15179: Unwinding info for stg_ap_v_info is wrong In-Reply-To: <046.8fd4224ffbd164208a65672323b41cb5@haskell.org> References: <046.8fd4224ffbd164208a65672323b41cb5@haskell.org> Message-ID: <061.d9b82deedac1d29efe610c51090c505a@haskell.org> #15179: Unwinding info for stg_ap_v_info is wrong -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 (Debugging) | Resolution: | Keywords: DWARF Operating System: Linux | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => DWARF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 02:49:54 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 02:49:54 -0000 Subject: [GHC] #15117: Add linting checks for DWARF unwind information In-Reply-To: <046.99e1d9bddf61dd7d8326fcca5a52c63d@haskell.org> References: <046.99e1d9bddf61dd7d8326fcca5a52c63d@haskell.org> Message-ID: <061.3f28255b9e5552bb4cf300344e1dbc4f@haskell.org> #15117: Add linting checks for DWARF unwind information -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: DWARF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4559 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => DWARF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 02:50:05 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 02:50:05 -0000 Subject: [GHC] #14834: Executable have problems with DWARF debug information In-Reply-To: <045.869f13e723668fe5f6114e93abdf8ce6@haskell.org> References: <045.869f13e723668fe5f6114e93abdf8ce6@haskell.org> Message-ID: <060.1579f741b73c77454dea340af63ed9f3@haskell.org> #14834: Executable have problems with DWARF debug information -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (Debugging) | Resolution: | Keywords: DWARF Operating System: Windows | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => DWARF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 02:50:15 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 02:50:15 -0000 Subject: [GHC] #14894: HEAD fails to build with -g1 In-Reply-To: <046.3db25c336062f0dea40eba4721995b57@haskell.org> References: <046.3db25c336062f0dea40eba4721995b57@haskell.org> Message-ID: <061.15c66d137c5b0906f51485421130f728@haskell.org> #14894: HEAD fails to build with -g1 -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.2 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: DWARF Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => DWARF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 02:50:29 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 02:50:29 -0000 Subject: [GHC] #14999: unwinding info for stg_catch_frame is wrong In-Reply-To: <046.c494a9ab46975a6daa3e5202496c7b13@haskell.org> References: <046.c494a9ab46975a6daa3e5202496c7b13@haskell.org> Message-ID: <061.c3f5e0cdfa0aa3853e2c45c7a0e2a515@haskell.org> #14999: unwinding info for stg_catch_frame is wrong -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: closed Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.4.2 Resolution: fixed | Keywords: DWARF Operating System: Linux | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D4606 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => DWARF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 02:50:39 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 02:50:39 -0000 Subject: [GHC] #14510: GHC.ExecutionStack.showStackTrace broken In-Reply-To: <043.9685830b69e2246f2b96ccff19455218@haskell.org> References: <043.9685830b69e2246f2b96ccff19455218@haskell.org> Message-ID: <058.a7925060c34b2a5b0aea10130217d276@haskell.org> #14510: GHC.ExecutionStack.showStackTrace broken ---------------------------------+-------------------------------------- Reporter: duog | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: DWARF Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * keywords: => DWARF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 02:51:49 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 02:51:49 -0000 Subject: [GHC] #14221: yaml-0.8.23.3 fails to build with -g In-Reply-To: <046.9dadad43b611bdb3c19cc87ee92d4f08@haskell.org> References: <046.9dadad43b611bdb3c19cc87ee92d4f08@haskell.org> Message-ID: <061.64273bb86c3e4badc58244d17cc62827@haskell.org> #14221: yaml-0.8.23.3 fails to build with -g -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler (NCG) | Version: 8.2.1 Resolution: fixed | Keywords: DWARF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3977 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => DWARF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 02:51:56 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 02:51:56 -0000 Subject: [GHC] #13866: -g doesn't work with -pgma=clang++ In-Reply-To: <046.0cc5ec25fa742bf402aa06da26adeede@haskell.org> References: <046.0cc5ec25fa742bf402aa06da26adeede@haskell.org> Message-ID: <061.155b12c897412d0364db83806ae17127@haskell.org> #13866: -g doesn't work with -pgma=clang++ ---------------------------------+---------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: DWARF Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3667 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * keywords: => DWARF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 02:52:05 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 02:52:05 -0000 Subject: [GHC] #12948: Implement unwind rules for non-Intel architectures In-Reply-To: <046.8f503227fa066851e13a6dcbab195691@haskell.org> References: <046.8f503227fa066851e13a6dcbab195691@haskell.org> Message-ID: <061.a5d49c1f07a9ab5b7b1991923e20e653@haskell.org> #12948: Implement unwind rules for non-Intel architectures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: DWARF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11261 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => DWARF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 02:52:16 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 02:52:16 -0000 Subject: [GHC] #12397: Support for PDB debug information generation In-Reply-To: <045.7bf08882b414350a48568f9ca1e85e23@haskell.org> References: <045.7bf08882b414350a48568f9ca1e85e23@haskell.org> Message-ID: <060.a242c58bdd090b30de2453a67d395934@haskell.org> #12397: Support for PDB debug information generation -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (Debugging) | Resolution: | Keywords: DWARF Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => DWARF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 02:52:25 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 02:52:25 -0000 Subject: [GHC] #11353: DWARF call frame information incorrect in the presence of unsafe foreign calls In-Reply-To: <046.efcbbd9d5b0e08d5344da072b37de7a3@haskell.org> References: <046.efcbbd9d5b0e08d5344da072b37de7a3@haskell.org> Message-ID: <061.8d03789fd1ed82f31def1570a9c3a390@haskell.org> #11353: DWARF call frame information incorrect in the presence of unsafe foreign calls -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (NCG) | Version: 7.10.3 Resolution: fixed | Keywords: DWARF Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #11338, #11337 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => DWARF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 02:52:40 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 02:52:40 -0000 Subject: [GHC] #11338: Unwind information is incorrect in region surrounding a safe foreign call In-Reply-To: <046.63160c8569d055bb9627f95207d1d3a0@haskell.org> References: <046.63160c8569d055bb9627f95207d1d3a0@haskell.org> Message-ID: <061.f91a1ff6e8da3bf37428d51f3574325b@haskell.org> #11338: Unwind information is incorrect in region surrounding a safe foreign call -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 (CodeGen) | Resolution: invalid | Keywords: DWARF Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: #11337, #11353 | Differential Rev(s): Phab:D2743 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => DWARF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 02:52:58 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 02:52:58 -0000 Subject: [GHC] #11337: Unwind information incorrect between Sp adjustment and end of block In-Reply-To: <046.ad6cfe437905abbd08df71a5221c1d83@haskell.org> References: <046.ad6cfe437905abbd08df71a5221c1d83@haskell.org> Message-ID: <061.d6348d7215d64e8b79d2f3411a82207c@haskell.org> #11337: Unwind information incorrect between Sp adjustment and end of block -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 (CodeGen) | Resolution: fixed | Keywords: DWARF Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => DWARF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 02:53:07 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 02:53:07 -0000 Subject: [GHC] #11261: Implement DWARF debugging on powerpc64 In-Reply-To: <047.fcb308b656617448e39264eeafa29658@haskell.org> References: <047.fcb308b656617448e39264eeafa29658@haskell.org> Message-ID: <062.d42949d762ac2fab79653f333c6f1d36@haskell.org> #11261: Implement DWARF debugging on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: DWARF Operating System: Linux | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: debug, at runtime | T10667, | simplCore/should_compile/T13658 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => DWARF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 02:53:16 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 02:53:16 -0000 Subject: [GHC] #10915: Statistical profiling support in the RTS In-Reply-To: <046.7220ccda33e87c4faaaf43cf13abd1b6@haskell.org> References: <046.7220ccda33e87c4faaaf43cf13abd1b6@haskell.org> Message-ID: <061.41561fa4b1f7ac8352ef674908a6d8bb@haskell.org> #10915: Statistical profiling support in the RTS -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: DWARF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1215, Wiki Page: | Phab:D1214 -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => DWARF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 02:54:08 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 02:54:08 -0000 Subject: [GHC] #10236: DWARF unwind info is broken In-Reply-To: <052.423eb6b33b554d26dbce2d20e8e80a98@haskell.org> References: <052.423eb6b33b554d26dbce2d20e8e80a98@haskell.org> Message-ID: <067.fa89b005b644d8e6a42be5d05ec9c010@haskell.org> #10236: DWARF unwind info is broken -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Debugging) | Resolution: fixed | Keywords: DWARF Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D792 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: dwarf => DWARF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 02:54:20 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 02:54:20 -0000 Subject: [GHC] #9910: ghc's dwarf (-g) output does not like Unicode (Char.intToDigit: not a digit 136) In-Reply-To: <045.2bab4361f44b745c3385fb704805cc5b@haskell.org> References: <045.2bab4361f44b745c3385fb704805cc5b@haskell.org> Message-ID: <060.7fdcea66a019a315db4c96b1a01ea175@haskell.org> #9910: ghc's dwarf (-g) output does not like Unicode (Char.intToDigit: not a digit 136) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: DWARF Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => DWARF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 02:54:31 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 02:54:31 -0000 Subject: [GHC] #9894: Presence of DWARF debug symbols doesn't result in working backtraces in GDB In-Reply-To: <044.2b175213c6f45c4fd4087c47df418ce5@haskell.org> References: <044.2b175213c6f45c4fd4087c47df418ce5@haskell.org> Message-ID: <059.57d0198b55097488faa00ef7622997e6@haskell.org> #9894: Presence of DWARF debug symbols doesn't result in working backtraces in GDB ---------------------------------+-------------------------------------- Reporter: tibbe | Owner: scpmw Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: duplicate | Keywords: DWARF Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10601 | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * keywords: => DWARF -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 02:57:24 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 02:57:24 -0000 Subject: [GHC] #15960: Using -g causes differences in generated core. In-Reply-To: <047.b0af08dc8e4461a81e2c6c6cbd0feffe@haskell.org> References: <047.b0af08dc8e4461a81e2c6c6cbd0feffe@haskell.org> Message-ID: <062.fb4d072aa3a29684a332bc61b616ce48@haskell.org> #15960: Using -g causes differences in generated core. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: | Keywords: DWARF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For what it's worth I also saw several validation issues when enabling the DWARF CI rule. I believe at least some of them are due to a PrelRule note firing due to the presence of a source tick. I'm not sure if this covers all of the failures, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 05:27:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 05:27:02 -0000 Subject: [GHC] #16383: ghc: internal error: getMBlock: mmap: Invalid argument (gi-gtk on armv7) Message-ID: <050.254a4fc1ec874cced54084d97af02960@haskell.org> #16383: ghc: internal error: getMBlock: mmap: Invalid argument (gi-gtk on armv7) -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Compile-time | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When trying to build gi-gtk-3.0.26 with ghc-8.4.4 on Fedora 30 armv7hl, ghc crashes like this: {{{ [484 of 498] Compiling GI.Gtk.Functions ( GI/Gtk/Functions.hs, dist/build/GI/Gtk/Functions.o ) BUILDSTDERR: ghc: internal error: getMBlock: mmap: Invalid argument BUILDSTDERR: (GHC version 8.4.4 for arm_unknown_linux) BUILDSTDERR: Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug BUILDSTDERR: /var/tmp/rpm-tmp.McmHQu: line 52: 5271 Aborted (core dumped) ./Setup build }}} https://koji.fedoraproject.org/koji/taskinfo?taskID=33138502 gi-gtk built fine before on ghc-8.2.2 armv7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 05:45:33 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 05:45:33 -0000 Subject: [GHC] #16379: JuicyPixels build panics on s390x ghc-8.4.4 In-Reply-To: <050.2346d71c3b0efe4bb40361f2c870b04a@haskell.org> References: <050.2346d71c3b0efe4bb40361f2c870b04a@haskell.org> Message-ID: <065.e109c043d0c14356f3a438aa83f553e8@haskell.org> #16379: JuicyPixels build panics on s390x ghc-8.4.4 -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: Other Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by juhpetersen): * status: new => closed * resolution: => duplicate Comment: Thanks, @monoidal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 05:51:11 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 05:51:11 -0000 Subject: [GHC] #15853: Unregisterised GHC panics when building test cgrun018 In-Reply-To: <047.a568cb0e736c463bce20c7d17a5e90c5@haskell.org> References: <047.a568cb0e736c463bce20c7d17a5e90c5@haskell.org> Message-ID: <062.1cf0396cc4b0663ebc6d96f02bc142d0@haskell.org> #15853: Unregisterised GHC panics when building test cgrun018 -------------------------------------+------------------------------------- Reporter: iliastsi | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: cgrun018 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by juhpetersen): * cc: juhpetersen (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 13:34:20 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 13:34:20 -0000 Subject: [GHC] #16318: Explicitly passing -package-env causes "Loaded package environment from .ghc.environment" message to be printed twice In-Reply-To: <050.1473c530d0a90fae443e0e00872a0b4e@haskell.org> References: <050.1473c530d0a90fae443e0e00872a0b4e@haskell.org> Message-ID: <065.3bc93ceb7f2a95709b798ff52176faf6@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 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Actually, the window of time in which this regression was introduced can be narrowed down even further, since this does not occur in GHC 8.6.2: {{{ $ /opt/ghc/8.6.2/bin/ghc -package-env .ghc.environment.x86_64-linux-8.6.2 -e "putStrLn \"Hello\"" Loaded package environment from .ghc.environment.x86_64-linux-8.6.2 Hello }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 13:46:30 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 13:46:30 -0000 Subject: [GHC] #16318: Explicitly passing -package-env causes "Loaded package environment from .ghc.environment" message to be printed twice In-Reply-To: <050.1473c530d0a90fae443e0e00872a0b4e@haskell.org> References: <050.1473c530d0a90fae443e0e00872a0b4e@haskell.org> Message-ID: <065.a09d2c02df18f1f91f0b577e04878e7e@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 Resolution: | Keywords: Operating System: 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 reasonably confident that commit e67bebbf735db498c2cbf191d1878644ca5ed5cc (`Load plugins in interactive session`) is the culprit: {{{#!diff -ghciUI :: [(FilePath, Maybe Phase)] -> Maybe [String] -> Ghc () +ghciUI :: HscEnv -> DynFlags -> [(FilePath, Maybe Phase)] -> Maybe [String] + -> Ghc () #if !defined(GHCI) -ghciUI _ _ = throwGhcException (CmdLineError "not built for interactive use") +ghciUI _ _ _ _ = + throwGhcException (CmdLineError "not built for interactive use") #else -ghciUI = interactiveUI defaultGhciSettings +ghciUI hsc_env dflags0 srcs maybe_expr = do + dflags1 <- liftIO (initializePlugins hsc_env dflags0) + _ <- GHC.setSessionDynFlags dflags1 + interactiveUI defaultGhciSettings srcs maybe_expr #endif }}} This inserts a call to `setSessionDynFlags`, which transitively invokes `initPackages`, which is the function that logs the "`Loaded package environment from ...`" message. But if you look at the source code for `interactiveUI`, you'll see that it invokes `setProgramDynFlags`, which //itself// transitively invokes `initPackages`! It seems like we might want to decouple the action of logging package environments from `initPackages`. Thoughts, hvr? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 13:50:59 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 13:50:59 -0000 Subject: [GHC] #15593: QuantifiedConstraints: trouble with type family In-Reply-To: <051.75163c16ae56c0dd5a46403a0d1e4aaa@haskell.org> References: <051.75163c16ae56c0dd5a46403a0d1e4aaa@haskell.org> Message-ID: <066.1f2e99d814e828ff8c9c22cb4345ff6d@haskell.org> #15593: QuantifiedConstraints: trouble with type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: duplicate | Keywords: | QuantifiedConstraints, | ConstraintKinds Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14860 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #14860 Comment: Update: GHC HEAD now //does// allow quantified constraints to be headed by `(~)`. Unfortunately, the original example still won't compile due to the fact that the quantified constraint's head mentions a type family: {{{ Bug.hs:11:1: error: • Illegal type synonym family application ‘DeRef (tree xx)’ in instance: DeRef (tree xx) ~ TreeF xx • In the quantified constraint ‘forall xx. DeRef (tree xx) ~ TreeF xx’ In the context: forall xx. DeRef (tree xx) ~ TreeF xx While checking the super-classes of class ‘MuRef1’ In the class declaration for ‘MuRef1’ | 11 | class (forall xx. DeRef (tree xx) ~ TreeF xx) => MuRef1 tree | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Bug.hs:12:10: error: • Illegal type synonym family application ‘DeRef (tree xx)’ in instance: DeRef (tree xx) ~ TreeF xx • In the quantified constraint ‘forall xx. DeRef (tree xx) ~ TreeF xx’ In the instance declaration for ‘MuRef1 tree’ | 12 | instance (forall xx. DeRef (tree xx) ~ TreeF xx) => MuRef1 tree | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} This is the subject of # , so I'm going to close this ticket in favor of that one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 13:59:08 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 13:59:08 -0000 Subject: [GHC] #16384: GHC infers ill-kinded type for typed TH splice with unlifted values Message-ID: <049.204094150d2dd49ce6dfbaa5f785ab8c@haskell.org> #16384: GHC infers ill-kinded type for typed TH splice with unlifted values -------------------------------------+------------------------------------- Reporter: gridaphobe | 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 noted in the [https://github.com/ghc-proposals/ghc-proposals/pull/209 Levity Polymorphic Lift proposal], GHC infers an ill-kinded type for typed splices with unlifted values. For example, in GHC 8.6.3 {{{ ghci> :t [|| 1# ||] [|| 1# ||] :: Q (TExp Int#) }}} `TExp Int#` is ill-kinded, so this type makes no sense. And GHC knows it's ill-kinded, because it will actually reject the program if you supply the type yourself. {{{ ghci> [|| 1# ||] :: Q (TExp Int#) :12:23: error: • Expecting a lifted type, but ‘Int#’ is unlifted • In the first argument of ‘TExp’, namely ‘Int#’ In the first argument of ‘Q’, namely ‘(TExp Int#)’ In an expression type signature: Q (TExp Int#) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 14:42:19 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 14:42:19 -0000 Subject: [GHC] #16385: Lousy error message for `instance forall c. c` Message-ID: <050.5577675c68c6eb87c39c68c755f609c4@haskell.org> #16385: Lousy error message for `instance forall c. c` -------------------------------------+------------------------------------- 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: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This erroneous program is rejected with a rather strange error message: {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} module Bug where instance forall c. c }}} {{{ $ /opt/ghc/8.6.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:4:20: error: Not in scope: type variable ‘c’ | 4 | instance forall c. c | ^ }}} This error message is hogwash, since `c` is absolutely in scope. The reason GHC believes that `c` is out of scope is because before GHC renamed the type signature in the instance, it performs a pass over all top-level binders in `RnNames.getLocalNonValBinders` to obtain their `Name`s. In particular, [https://gitlab.haskell.org/ghc/ghc/blob/473632d7671619ee08a2a0025aa22bd4f79eca2d/compiler/rename/RnNames.hs#L734-743 this] is the culprit: {{{#!hs new_assoc overload_ok (L _ (ClsInstD _ (ClsInstDecl { cid_poly_ty = inst_ty , cid_datafam_insts = adts }))) | Just (L loc cls_rdr) <- getLHsInstDeclClass_maybe inst_ty = do { cls_nm <- setSrcSpan loc $ lookupGlobalOccRn cls_rdr ; (avails, fldss) <- mapAndUnzipM (new_loc_di overload_ok (Just cls_nm)) adts ; return (avails, concat fldss) } | otherwise = return ([], []) -- Do not crash on ill-formed instances -- Eg instance !Show Int Trac #3811c }}} Notice the use of `lookupGlobalOccRn` there. Since this code just tunnels into the instance type signature (using `getLHsInstDeclClass_maybe`) without binding any type variables, this calls `lookupGlobalOcc` on an unbound type variable `c`. Eek. I believe the fix would be to use `lookupGlobalOccRn_maybe` instead and simply default to `return ([], [])` in the event that `lookupGlobalOccRn_maybe` returns Nothing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 14:54:52 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 14:54:52 -0000 Subject: [GHC] #16385: Lousy error message for `instance forall c. c` In-Reply-To: <050.5577675c68c6eb87c39c68c755f609c4@haskell.org> References: <050.5577675c68c6eb87c39c68c755f609c4@haskell.org> Message-ID: <065.9f74af01352a4496199e86d9525f409e@haskell.org> #16385: Lousy error message for `instance forall c. c` -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | 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: | https://gitlab.haskell.org/ghc/ghc/merge_requests/483 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/483 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 16:26:22 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 16:26:22 -0000 Subject: [GHC] #16384: GHC infers ill-kinded type for typed TH splice with unlifted values In-Reply-To: <049.204094150d2dd49ce6dfbaa5f785ab8c@haskell.org> References: <049.204094150d2dd49ce6dfbaa5f785ab8c@haskell.org> Message-ID: <064.106c41e78adf8a3fa6cfda2b5e95f60e@haskell.org> #16384: GHC infers ill-kinded type for typed TH splice with unlifted values -------------------------------------+------------------------------------- Reporter: gridaphobe | 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): Core Lint will complain about it as well: {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -dcore-lint #-} module Bug where import GHC.Exts wat :: () -> Int# wat _ = $$([|| 1# ||]) }}} {{{ $ /opt/ghc/8.6.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint errors : in result of hscCompileExpr *** : warning: In the expression: unsafeTExpCoerce @ Int# sat_s3Mx Kinds don't match in type application: Type variable: a_a3mR :: * Arg type: Int# :: TYPE 'IntRep Linted Arg kind: TYPE 'IntRep *** Offending Program *** let { sat_s3Mx :: Q Exp [LclId] sat_s3Mx = let { sat_s3Mw :: Lit [LclId] sat_s3Mw = let { sat_s3M1 :: Integer [LclId] sat_s3M1 = S# 1# } in intPrimL sat_s3M1 } in litE sat_s3Mw } in unsafeTExpCoerce @ Int# sat_s3Mx *** End of Offense *** : error: Compilation had errors }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 17:48:20 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 17:48:20 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.8d7f1d6a2467b1f1fa45511038d484fa@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 danidiaz): * cc: danidiaz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:42:14 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:42:14 -0000 Subject: [GHC] #14828: panic! when using :print on some functions with class constraints? In-Reply-To: <042.277052228000c219ea7b7bc26108babf@haskell.org> References: <042.277052228000c219ea7b7bc26108babf@haskell.org> Message-ID: <057.a3e95d3dc2081fbaa4afc624d46184d5@haskell.org> #14828: panic! when using :print on some functions with class constraints? -------------------------------------+------------------------------------- Reporter: jol | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Resolution: | Keywords: debugger Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I spent some time today digging into why exactly this panic happens. The immediate issue appears to be a hiccup in how the interactive debugger handles higher-rank types, which is surprising, considering that none of the types in the original description appear to be higher-rank. For the time being, just take my word for it that this is true—I'll return to this point later. Here is an example showing that `:print` chokes on a term with a higher- rank type: {{{ GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> f :: (forall a. a -> a) -> b -> b; f g x = g x λ> :print f ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t1_a1tY[rt] :: TYPE t_a1tX[rt] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type }}} The fact that the panic mentions `t1_a1tY` is a bit curious... I wonder what happens if we try an older version of GHC? {{{ GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> f :: (forall a. a -> a) -> b -> b; f g x = g x λ> :print f f = (_t1::t1) }}} Ah, this //doesn't// panic on GHC 8.0, so this must be a regression introduced between 8.0 and 8.2. Moreover, note that even in 8.0, `:print f`'s behavior is strange: it prints out a thunk of type `t1` instead of, say, `(forall a. a -> a) -> b -> b`. This must explain where the `t1_a1tY` in the 8.2 panic comes from, since that is the type of `_t1` (with its unique explicitly printed). What changed between GHC 8.0 and 8.2 that would trigger this panic? As it turns out, it's commit e7985ed23ddc68b6a2e4af753578dc1d9e8ab4c9 (` Update levity polymorphism`). Specifically, [https://gitlab.haskell.org/ghc/ghc/commit/e7985ed23dd#7cf100051b3d8b0e1a0d4f723a9675e6c1540405 this change]: {{{#!diff diff --git a/compiler/ghci/Debugger.hs b/compiler/ghci/Debugger.hs index 64ac1540aa..4d7f8e3ef0 100644 --- a/compiler/ghci/Debugger.hs +++ b/compiler/ghci/Debugger.hs @@ -28,7 +28,6 @@ import Var hiding ( varName ) import VarSet import UniqFM import Type -import Kind import GHC import Outputable import PprTyThing @@ -78,7 +77,7 @@ pprintClosureCommand bindThings force str = do term_ <- GHC.obtainTermFromId maxBound force id' term <- tidyTermTyVars term_ term' <- if bindThings && - False == isUnliftedTypeKind (termType term) + (not (isUnliftedType (termType term))) then bindSuspensions term else return term -- Before leaving, we compare the type obtained to see if it's more specific }}} I'm not sure if this was Richard's intention, but this patch actually changes the behavior of `:print`. Unlike `isUnlifedTypeKind`, `isUnliftedType` is a partial function. If `isUnliftedType` cannot ascertain with 100% confidence that a type is unlifted, then it throws the `isUnliftedType` panic we saw above. Evidently, GHC isn't 100% confident that `t1_a1tY` is unlifted. This proposes one possible patch. Instead of checking if `not (isUnliftedType (termType term))` returns `True`, we could check is `isLiftedType_maybe (termType term)` returns `Just True`. This "inverts" the check by querying if GHC is 100% certain that `termType term` is //lifted//, and moreover, `isLiftedType_maybe` won't panic if that isn't the case. ----- So why are functions like `fmap`, which appear not to be higher-rank, trigger this panic? `-ddump-rtti` reveals the answer: {{{ GHCi, version 8.2.2: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -ddump-rtti λ> :print fmap Term reconstruction started with initial type forall (f :: * -> *). GHC.Base.Functor f => forall a b. (a -> b) -> f a -> f b Unknown closure: Fun check2 passed add constraint: t1_a1sK[tau:1] = GHC.Base.Functor f0_a1sI[tau:1] => forall a b. (a -> b) -> f0_a1sI[tau:1] a -> f0_a1sI[tau:1] b Term reconstruction completed. Term obtained: _ Type obtained: t1_a1sK[rt] ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-unknown-linux): isUnliftedType t1_a1sK[rt] :: TYPE t_a1sJ[rt] Call stack: CallStack (from HasCallStack): prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1133:58 in ghc:Outputable callStackDoc, called at compiler/utils/Outputable.hs:1137:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1952:10 in ghc:Type }}} In particular, take special notice of these parts: {{{ Term reconstruction started with initial type forall (f :: * -> *). GHC.Base.Functor f => forall a b. (a -> b) -> f a -> f b }}} {{{ add constraint: t1_a1sK[tau:1] = GHC.Base.Functor f0_a1sI[tau:1] => forall a b. (a -> b) -> f0_a1sI[tau:1] a -> f0_a1sI[tau:1] b }}} `:print` starts with the type `forall f. Functor f => forall a b. (a -> b) -> f a -> f b` which, strictly speaking, is higher-rank, as there is a nested use of `forall a b`. Normally, we don't think of `forall`s to the right of `=>` as higher-rank, since we can "float" them out to the front of the type, but `:print` doesn't appear to be doing this, since the `add constraint` logging message says that `t1_a1sK` is equal to `Functor f0 => forall a b. (a -> b) -> f0 a -> f0 b`, where `f0` is a metavariable. Note that `:print` seems to have instantiated `f` with a metavariable, but not `a` or `b`! If `:print` had done that, then `t1_a1sK` would not be higher- rank at all, avoiding this panic in the first place. Of course, even if we did this smarter metavariable instantiation, the problem of higher-rank types crashing `:print` would still linger. This suggests that we should fix the `isUnliftedType` panic first, and then we can worry about future steps like making the type of `fmap` render correctly with `:print`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:50:59 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:50:59 -0000 Subject: [GHC] #16214: Hadrian prof flavour doesn't build a compiler which you can profile In-Reply-To: <049.05a4a05b525aa81d9340796c8a077c69@haskell.org> References: <049.05a4a05b525aa81d9340796c8a077c69@haskell.org> Message-ID: <064.e3f58f8b195d4675240cf7253680f936@haskell.org> #16214: Hadrian prof flavour doesn't build a compiler which you can profile -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | 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: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"cfe64019a70acc1bae76f2fa580d6654f8eb5bc4/ghc" cfe6401/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cfe64019a70acc1bae76f2fa580d6654f8eb5bc4" Fix hadrian prof flavour so that it builds a profiled version of GHC In Alp's refactoring of `getProgramContexts` he removed a call to `getProgramContext` which was where the logic for this used to be implemented. Fixes #16214 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:50:59 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:50:59 -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.73aa798727b19317f9e311d3927042d9@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 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d26869ac83935432e0dcea1ff591268232daef32/ghc" d26869ac/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d26869ac83935432e0dcea1ff591268232daef32" Hadrian: install patches 'haddock-{html,interface}' Since the `$(docdir)` can be picked independently from the `$(libdir)`, we need to make sure that that the `haddock-html` and `haddock-interface` fields in the package DB (which is in the `$(libdir)`) get updated to point to the appropriate places in the `$(docdir)`. NB: in the make system, `ghc-cabal` would cover this sort of thing by re-running `configure` on installation, but here we get away with a couple lines of `sed` and a call to `ghc-pkg recache`. Fixes #16202. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:50:59 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:50:59 -0000 Subject: [GHC] #16201: ghci063 failing on Darwin In-Reply-To: <046.5e984b197caa806ce5eae32ad316f9a0@haskell.org> References: <046.5e984b197caa806ce5eae32ad316f9a0@haskell.org> Message-ID: <061.4a309621849357bb49d3705f05d98968@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 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0b705fadf936eaf48aaca26d2f7c8c9ae9158c66/ghc" 0b705fad/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0b705fadf936eaf48aaca26d2f7c8c9ae9158c66" testsuite: Mark ghci063 as broken on Darwin This is the last failing test on Darwin preventing us from disallowing CI failures. See #16201. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:50:59 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:50:59 -0000 Subject: [GHC] #16218: T16180 is broken on Darwin In-Reply-To: <046.aa96ca3ae65b0b9e6401b05f1cbb2a7d@haskell.org> References: <046.aa96ca3ae65b0b9e6401b05f1cbb2a7d@haskell.org> Message-ID: <061.1f43f9386ecf06a1c90dd087d0afab52@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 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"57142eb92bf74d4b5daf316b73b9c2fc39ce0b16/ghc" 57142eb9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="57142eb92bf74d4b5daf316b73b9c2fc39ce0b16" testsuite: Mark T16180 as broken on Darwin See #16218. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:50:59 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:50:59 -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.483cde556c7ce45a51755cd6ecf25061@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 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"efc95841503a78504c0aa00925fb22c4ec4627af/ghc" efc95841/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="efc95841503a78504c0aa00925fb22c4ec4627af" Hadrian: support in-tree GMP Summary: This adds top-level configure flags '--with-intree-gmp' and '--with-framework-preferred', both of which are especially relevant on MacOS. Besides gaining two new flags, Hadrian also had to be taught what to do with the 'framework' in .cabal files. Test Plan: ./boot && ./configure --with-intree-gmp && ./hadrian/build.sh ./boot && ./configure --with-gmp-framework-preferred && ./hadrian/build.sh # on macos Reviewers: carter, snowleopard, alpmestan, hvr, goldfire, bgamari Subscribers: rwbarton, erikd GHC Trac Issues: #16001 Differential Revision: https://phabricator.haskell.org/D5417 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51: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.d475499df54563253ee9cba47fb62632@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 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5341edf3635f2875271acc469570481c52000374/ghc" 5341edf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5341edf3635f2875271acc469570481c52000374" Error out of invalid Int/Word bit shifts Although the Haddock's for `shiftL` and `shiftR` do require the number of bits to be non-negative, we should still check this before calling out to primitives (which also have undefined behaviour for negative bit shifts). If a user _really_ wants to bypass checks that the number of bits is sensible, they already have the aptly-named `unsafeShiftL`/`unsafeShiftR` at their disposal. See #16111. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -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.c4653ae60825eb745e3c2ea06385599f@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: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"372b5d1b4543334d9b446dc897227b838e40cf4e/ghc" 372b5d1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="372b5d1b4543334d9b446dc897227b838e40cf4e" testsuite: Add test for #16104 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -0000 Subject: [GHC] #16085: ffi018_ghci fails when unregisterised In-Reply-To: <046.08016c835b725498a58c6f31e9385947@haskell.org> References: <046.08016c835b725498a58c6f31e9385947@haskell.org> Message-ID: <061.fae1509da1531e20c1f6241ac4c3adaa@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: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"022a71761a84aec2a2e62e18bd481ac057b5b8a0/ghc" 022a7176/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="022a71761a84aec2a2e62e18bd481ac057b5b8a0" testsuite: Skip T1288_ghci in unregisterised As pointed out in #16085, these ghci tests are fragile in the unregisterised way. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -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.c0bcb7f146cc1245227048ddcd8bd69e@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: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0d9f105ba423af4f2ca215a18d04d4c8e2c372a8/ghc" 0d9f105b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0d9f105ba423af4f2ca215a18d04d4c8e2c372a8" GhcPlugins: Fix lookup of TH names Previously `thNameToGhcName` was calling `lookupOrigNameCache` directly, which failed to handle the case that the name wasn't already in the name cache. This happens, for instance, when the name was in scope in a plugin being used during compilation but not in scope in the module being compiled. In this case we the interface file containing the name won't be loaded and `lookupOrigNameCache` fails. This was the cause of #16104. The solution is simple: use the nicely packaged `lookupOrigIO` instead. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -0000 Subject: [GHC] #16085: ffi018_ghci fails when unregisterised In-Reply-To: <046.08016c835b725498a58c6f31e9385947@haskell.org> References: <046.08016c835b725498a58c6f31e9385947@haskell.org> Message-ID: <061.5043e32d3dd4a93266cdd47b4549d804@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: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"35c58c33344b17469466e0e85324c9b02ac1af46/ghc" 35c58c33/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="35c58c33344b17469466e0e85324c9b02ac1af46" testsuite: Skip ghcilink002 when unregisterised See #16085. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -0000 Subject: [GHC] #15467: unregisterised validation failures In-Reply-To: <048.3355061b396ea4e51fa8e18011bf957e@haskell.org> References: <048.3355061b396ea4e51fa8e18011bf957e@haskell.org> Message-ID: <063.3af54f8bf2af6b7789972df24c0e2bdd@haskell.org> #15467: unregisterised validation failures ---------------------------------+-------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: T7040_ghci Blocked By: | Blocking: Related Tickets: #16085 | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"dc6fd390c64a2ee7c3df1da116504a5faf0afea5/ghc" dc6fd390/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dc6fd390c64a2ee7c3df1da116504a5faf0afea5" testsuite: Skip foreignInterruptible in unregisterised way See #15467. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -0000 Subject: [GHC] #16217: check-api-annotations should check that an annotation does not precede its span In-Reply-To: <044.be6fe9649ca788572188dbb4a1a174e7@haskell.org> References: <044.be6fe9649ca788572188dbb4a1a174e7@haskell.org> Message-ID: <059.d869f61f451b4fdc19956271ea0b7925@haskell.org> #16217: check-api-annotations should check that an annotation does not precede its span -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Test Suite | Version: 8.6.3 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 Ben Gamari ): In [changeset:"3cf12e6081e7a9f0c3d515de52ffd079186816a5/ghc" 3cf12e60/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3cf12e6081e7a9f0c3d515de52ffd079186816a5" check-api-annotations checks for annotation preceding its span For an API annotation to be useful, it must not occur before the span it is enclosed in. So, for check-api-annotation output, a line such as ((Test16212.hs:3:22-36,AnnOpenP), [Test16212.hs:3:21]), should be flagged as an error, as the AnnOpenP location of 3:21 precedes its enclosing span of 3:22-26. This patch does this. Closes #16217 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -0000 Subject: [GHC] #14078: -ddump-json doesn't work well with GHCi In-Reply-To: <050.a3c1661fff8336ca3c521994e1a88d18@haskell.org> References: <050.a3c1661fff8336ca3c521994e1a88d18@haskell.org> Message-ID: <065.a90bec61c30c5bc4c11789fe0386afc9@haskell.org> #14078: -ddump-json doesn't work well with GHCi -------------------------------------+------------------------------------- Reporter: dramforever | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.2.1 Resolution: fixed | Keywords: JSON Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"10faf44d97095b2f8516b6d449d266f6889dcd70/ghc" 10faf44d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="10faf44d97095b2f8516b6d449d266f6889dcd70" Don't overwrite the set log_action when using --interactive -ddump-json didn't work with --interactive as --interactive overwrote the log_action in terms of defaultLogAction. Reviewers: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #14078 Differential Revision: https://phabricator.haskell.org/D4533 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -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.fd600d04c81719112786f035e14c9347@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 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5cb071af5b02b7433b2bb4d06062ac8b6fb387e8/ghc" 5cb071af/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5cb071af5b02b7433b2bb4d06062ac8b6fb387e8" hadrian: use new-exec to make sure alex & happy are in PATH (#16120) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -0000 Subject: [GHC] #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) In-Reply-To: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> References: <046.cb35ad4ec343f26e487f6feef0b37095@haskell.org> Message-ID: <061.532eafaec10bf9a40187b4609c4dced3@haskell.org> #11982: Typechecking fails for parallel monad comprehensions with polymorphic let (GHC 7.10.3 through 8.6.3) -------------------------------------+------------------------------------- Reporter: simonpj | Owner: josefs Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: ApplicativeDo 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 Ben Gamari ): In [changeset:"def84a10dd9db34d86284cb0b8358261034eecc4/ghc" def84a1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="def84a10dd9db34d86284cb0b8358261034eecc4" testsuite: Add tests from #11982 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -0000 Subject: [GHC] #16183: GHC HEAD regression: -ddump-splices incorrectly parenthesizes HsKindSig applications In-Reply-To: <050.b073edeafb8ce0a0d0cbf99ceea13585@haskell.org> References: <050.b073edeafb8ce0a0d0cbf99ceea13585@haskell.org> Message-ID: <065.eee7347a900fa49b168ba155193c4726@haskell.org> #16183: GHC HEAD regression: -ddump-splices incorrectly parenthesizes HsKindSig applications -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: th/T16183 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/121 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"b1e569a54085bf1093b4f858f8c7c739e3be769b/ghc" b1e569a5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b1e569a54085bf1093b4f858f8c7c739e3be769b" Use sigPrec in more places in Convert and HsUtils Trac #16183 was caused by TH conversion (in `Convert`) not properly inserting parentheses around occurrences of explicit signatures where appropriate, such as in applications, function types, and type family equations. Solution: use `parenthesizeHsType sigPrec` in these places. While I was in town, I also updated `nlHsFunTy` to do the same thing. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -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.5cddfda037c0778278981ab30fcd47e0@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"7cdcd3e12a5c3a337e36fa80c64bd72e5ef79b24/ghc" 7cdcd3e1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7cdcd3e12a5c3a337e36fa80c64bd72e5ef79b24" Fix #12509: ghci -XSafe fails in an inscrutable way }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -0000 Subject: [GHC] #16210: Hadrian devel2 flavour builds profiling way In-Reply-To: <049.3cb854d79d59d174586568a12c4e09ce@haskell.org> References: <049.3cb854d79d59d174586568a12c4e09ce@haskell.org> Message-ID: <064.3249dc697d842525cb4dadb223e1eb64@haskell.org> #16210: Hadrian devel2 flavour builds profiling way -------------------------------------+------------------------------------- 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 Ben Gamari ): In [changeset:"e7e5f4aebec2f095071a1949bb4595744754ee04/ghc" e7e5f4ae/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e7e5f4aebec2f095071a1949bb4595744754ee04" Only build vanilla way in devel2 flavour Fixes #16210 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -0000 Subject: [GHC] #16086: Compile countLeadingZeros to lzcnt if -mbmi2 is set In-Reply-To: <048.90f296282d8c0fc96bfca7b8261d2cfd@haskell.org> References: <048.90f296282d8c0fc96bfca7b8261d2cfd@haskell.org> Message-ID: <063.843ae4dcbc7c8851933cbd860ac1b9e7@haskell.org> #16086: Compile countLeadingZeros to lzcnt if -mbmi2 is set -------------------------------------+------------------------------------- Reporter: ethercrow | Owner: ethercrow Type: feature request | Status: patch Priority: low | Milestone: Component: Compiler | Version: 8.6.3 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c1d9416f2672b8d844141c0393fe773676749777/ghc" c1d9416f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c1d9416f2672b8d844141c0393fe773676749777" Compile count{Leading,Trailing}Zeros to corresponding x86_64 instructions under -mbmi2 This works similarly to existing implementation for popCount. Trac ticket: #16086. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -0000 Subject: [GHC] #1: Implicit parameters cause strange behavi In-Reply-To: <045.dd635ef62f3ce1d5e8bfe2b4cd36b0de@haskell.org> References: <045.dd635ef62f3ce1d5e8bfe2b4cd36b0de@haskell.org> Message-ID: <060.a8b829d5b0d1e1ac28bf48fb4c7d5e83@haskell.org> #1: Implicit parameters cause strange behavi --------------------------------+-------------------- Reporter: nobody | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 5.0 Resolution: Fixed | Keywords: Type of failure: None/Unknown | --------------------------------+-------------------- Comment (by Ben Gamari ): In [changeset:"e29b1ee72d77d5a06ac949f9dcc80108243a25c0/ghc" e29b1ee7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e29b1ee72d77d5a06ac949f9dcc80108243a25c0" Add a RTS option -xp to load PIC object anywhere in address space Summary: This re-applies {D5195} with fixes for i386: * Fix unused label warnings, see {D5230} or {D5273} * Fix a silly bug introduced by moving `#if` {P190} Add a RTS option -xp to load PIC object anywhere in address space. We do this by relaxing the requirement of <0x80000000 result of `mmapForLinker` and implying USE_CONTIGUOUS_MMAP. We also need to change calls to `ocInit` and `ocGetNames` to avoid dangling pointers when the address of `oc->image` is changed by `ocAllocateSymbolExtra`. Test Plan: See {D5195}, also test under i386: ``` $ uname -a Linux watashi-arch32 4.18.5-arch1-1.0-ARCH #1 SMP PREEMPT Tue Aug 28 20:45:30 CEST 2018 i686 GNU/Linux $ cd testsuite/tests/th/ && make test ... ``` will run `./validate` on stacked diff. Reviewers: simonmar, bgamari, alpmestan, trommler, hvr, erikd Reviewed By: simonmar Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5289 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -0000 Subject: [GHC] #16233: HIE file generation is inefficient In-Reply-To: <050.9a8af98be708c8bc79f0ecd2c361995e@haskell.org> References: <050.9a8af98be708c8bc79f0ecd2c361995e@haskell.org> Message-ID: <065.4ce25185940bf814c96238b1cb1cb132@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 Ben Gamari ): In [changeset:"5ed48d25decc9dec29659482644b136cff91606e/ghc" 5ed48d25/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5ed48d25decc9dec29659482644b136cff91606e" Include type info for only some exprs in HIE files This commit relinquishes some some type information in `.hie` files in exchange for better performance. See #16233 for more on this. Using `.hie` files to generate hyperlinked sources is a crucial milestone towards Hi Haddock (the initiative to move Haddock to work over `.hi` files and embed docstrings in those). Unfortunately, even after much optimization on the Haddock side, the `.hie` based solution is still considerably slower and more memory hungry than the existing implementation - and the @.hie@ code is to blame. This changes `.hie` file generation to track type information for only a limited subset of expressions (specifically, those that might eventually turn into hyperlinks in the Haddock's hyperlinker backend). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -0000 Subject: [GHC] #16212: API Annotations: Parens not attached correctly for ClassDecl In-Reply-To: <044.f7f6c7035ce5e7ae3d246fa7bb51c85f@haskell.org> References: <044.f7f6c7035ce5e7ae3d246fa7bb51c85f@haskell.org> Message-ID: <059.d9eb258a0cba0361313204e49995c816@haskell.org> #16212: API Annotations: Parens not attached correctly for ClassDecl -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.3 (Parser) | Resolution: fixed | 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 Ben Gamari ): In [changeset:"4bf35da4fccd2a21153a1c19bfa80006e99e02a1/ghc" 4bf35da4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4bf35da4fccd2a21153a1c19bfa80006e99e02a1" API Annotations: Parens not attached correctly for ClassDecl The parens around the kinded tyvars should be attached to the class declaration as a whole, they are attached to the tyvar instead, outside the span. An annotation must always be within or after the span it is contained in. Closes #16212 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -0000 Subject: [GHC] #15729: Static GHCi can segfault when accessing .bss section in C In-Reply-To: <046.01f3ec3cee991a7182d3dc45051c529d@haskell.org> References: <046.01f3ec3cee991a7182d3dc45051c529d@haskell.org> Message-ID: <061.59ae2d431272a81ac1779a3f852530b2@haskell.org> #15729: Static GHCi can segfault when accessing .bss section in C -------------------------------+-------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #781 | Differential Rev(s): Phab:D5219 Wiki Page: | -------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"740534d43cf9f1635c60f6311b7e0d89af962617/ghc" 740534d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="740534d43cf9f1635c60f6311b7e0d89af962617" Allocate bss section within proper range of other sections Summary: This re-applies {D5195} and {D5235}, they were reverted as part of diff stack to unbreak i386. The proper fix is done in {D5289}. Allocate bss section within proper range of other sections: * when `+RTS -xp` is passed, allocate it contiguously as we did for jump islands * when we mmap the code to lower 2Gb, we should allocate bss section there too Test Plan: 1. `./validate` 2. with ``` DYNAMIC_GHC_PROGRAMS = NO DYNAMIC_BY_DEFAULT = NO ``` `TEST="T15729" make test` passed in both linux (both i386 and x86_64) and macos. 3. Also test in a use case where we used to encouter error like: ``` ghc-iserv-prof: R_X86_64_PC32 relocation out of range: (noname) = b90282ba ``` and now, everything works fine. Reviewers: simonmar, bgamari, angerman, erikd Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15729 Differential Revision: https://phabricator.haskell.org/D5290 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -0000 Subject: [GHC] #15729: Static GHCi can segfault when accessing .bss section in C In-Reply-To: <046.01f3ec3cee991a7182d3dc45051c529d@haskell.org> References: <046.01f3ec3cee991a7182d3dc45051c529d@haskell.org> Message-ID: <061.b3b62a3312bc5b9491119aa1c9a13a1c@haskell.org> #15729: Static GHCi can segfault when accessing .bss section in C -------------------------------+-------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #781 | Differential Rev(s): Phab:D5219 Wiki Page: | -------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"6e96aa2d503ddeeef1fa1f37b45d5c744522b64d/ghc" 6e96aa2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6e96aa2d503ddeeef1fa1f37b45d5c744522b64d" Don't use X86_64_ELF_NONPIC_HACK for +RTS -xp Summary: When `+RTS -xp` is passed, when don't need the X86_64_ELF_NONPIC_HACK, becasue the relocation offset should only be out of range if * the object file was not compiled with `-fPIC -fexternal-dynamic-refs`; * ghc generates non-pic code while it should (e.g. #15723) In either case, we should print an error message rather that silently attempt to use a hacky workaround that may not work. This could have made debugging #15723 and #15729 much easier. Test Plan: Run this in a case where ghci used to crash becasue of T15723. Now we see helpful message like: ``` ghc-iserv-prof: R_X86_64_PC32 relocation out of range: stmzm2zi4zi4zi1zmJQn4hNPyYjP5m9AcbI88Ve_ControlziConcurrentziSTMziTMVar_readTMVar_C61n_cc = 9b95ffac ``` Reviewers: simonmar, bgamari, erikd Reviewed By: simonmar, bgamari Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5233 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -0000 Subject: [GHC] #15723: -prof -fPIC -fexternal-dynamic-refs generates non-PIC relocations for external symbol In-Reply-To: <046.1c3e8598c6f9064f6c1ee4be47cb671b@haskell.org> References: <046.1c3e8598c6f9064f6c1ee4be47cb671b@haskell.org> Message-ID: <061.f5f98482f2542935b63e7a826c101e91@haskell.org> #15723: -prof -fPIC -fexternal-dynamic-refs generates non-PIC relocations for external symbol -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5214 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6e96aa2d503ddeeef1fa1f37b45d5c744522b64d/ghc" 6e96aa2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6e96aa2d503ddeeef1fa1f37b45d5c744522b64d" Don't use X86_64_ELF_NONPIC_HACK for +RTS -xp Summary: When `+RTS -xp` is passed, when don't need the X86_64_ELF_NONPIC_HACK, becasue the relocation offset should only be out of range if * the object file was not compiled with `-fPIC -fexternal-dynamic-refs`; * ghc generates non-pic code while it should (e.g. #15723) In either case, we should print an error message rather that silently attempt to use a hacky workaround that may not work. This could have made debugging #15723 and #15729 much easier. Test Plan: Run this in a case where ghci used to crash becasue of T15723. Now we see helpful message like: ``` ghc-iserv-prof: R_X86_64_PC32 relocation out of range: stmzm2zi4zi4zi1zmJQn4hNPyYjP5m9AcbI88Ve_ControlziConcurrentziSTMziTMVar_readTMVar_C61n_cc = 9b95ffac ``` Reviewers: simonmar, bgamari, erikd Reviewed By: simonmar, bgamari Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5233 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -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.d6034836e51699b3861bacec95fe88ca@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: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4fa32293c9d2658ce504b8fe6d909db2acf59983/ghc" 4fa32293/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4fa32293c9d2658ce504b8fe6d909db2acf59983" Use ByteString to represent Cmm string literals (#16198) Also used ByteString in some other relevant places }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -0000 Subject: [GHC] #14828: panic! when using :print on some functions with class constraints? In-Reply-To: <042.277052228000c219ea7b7bc26108babf@haskell.org> References: <042.277052228000c219ea7b7bc26108babf@haskell.org> Message-ID: <057.8c4066f7bb2756e3c4362b6ec2587c62@haskell.org> #14828: panic! when using :print on some functions with class constraints? -------------------------------------+------------------------------------- Reporter: jol | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Resolution: | Keywords: debugger Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5b970d8e06c1433066a8c587116f0b22c0f30e22/ghc" 5b970d8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5b970d8e06c1433066a8c587116f0b22c0f30e22" testsuite: Add test for #14828 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -0000 Subject: [GHC] #16222: PPC NCG: C calling convention violated for integers smaller than word size In-Reply-To: <047.18307dffe0017b3a8a2b889928c2572e@haskell.org> References: <047.18307dffe0017b3a8a2b889928c2572e@haskell.org> Message-ID: <062.1b225ae7e583861173af83a084156c82@haskell.org> #16222: PPC NCG: C calling convention violated for integers smaller than word size -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 Component: Compiler (FFI) | 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/PrimFFIInt8 | primops/should_run/PrimFFIInt16 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/220 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4376d8811418d91bb4d19d61801e95a449b98378/ghc" 4376d88/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4376d8811418d91bb4d19d61801e95a449b98378" PPC NCG: Promote integers to word size in C calls Fixes #16222 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -0000 Subject: [GHC] #16219: Backpack - TH+indefinite module interface file error In-Reply-To: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> References: <052.416215f0cd57a5ce79683aa1210d8fb8@haskell.org> Message-ID: <067.71d8e26a036bf8461e730197c4fb5996@haskell.org> #16219: Backpack - TH+indefinite module interface file error -------------------------------------+------------------------------------- Reporter: lightandlight | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5475 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d6d735c1114082b9e9cc1ba7da87c49f52891320/ghc" d6d735c1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d6d735c1114082b9e9cc1ba7da87c49f52891320" Fix #16219: TemplateHaskell causes indefinite package build error It should work to write an indefinite package using TemplateHaskell, so long as all of the actual TH code lives outside of the package. However, cleverness we had to build TH code even when building with -fno-code meant that we attempted to build object code for modules in an indefinite package, even when the signatures were not instantiated. This patch disables said logic in the event that an indefinite package is being typechecked. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #16219 Differential Revision: https://phabricator.haskell.org/D5475 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -0000 Subject: [GHC] #15467: unregisterised validation failures In-Reply-To: <048.3355061b396ea4e51fa8e18011bf957e@haskell.org> References: <048.3355061b396ea4e51fa8e18011bf957e@haskell.org> Message-ID: <063.f3951729685f86a428a39a13639ed589@haskell.org> #15467: unregisterised validation failures ---------------------------------+-------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: T7040_ghci Blocked By: | Blocking: Related Tickets: #16085 | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by Marge Bot ): In [changeset:"461c447db50ba3f7ded59f73e3b5342212089fb2/ghc" 461c447d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="461c447db50ba3f7ded59f73e3b5342212089fb2" testsuite: Skip T15897 in unregisterised way As noted in #16227 this test routinely times out when run in the unregisterised way. See also #15467. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -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.76265c948ad03a58c5680cf4ec910add@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 Marge Bot ): In [changeset:"626b63b28a91b26b51ad47e56fdd7bcfd61e7327/ghc" 626b63b2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="626b63b28a91b26b51ad47e56fdd7bcfd61e7327" testsuite: Mark print037 as broken when GHC is built with LLVM As noted in #16205 this configuration reliably segfaults. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -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.fd0786c1c2e18dc3677185db6dca01ec@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: | -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"461c447db50ba3f7ded59f73e3b5342212089fb2/ghc" 461c447d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="461c447db50ba3f7ded59f73e3b5342212089fb2" testsuite: Skip T15897 in unregisterised way As noted in #16227 this test routinely times out when run in the unregisterised way. See also #15467. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -0000 Subject: [GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code In-Reply-To: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> References: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> Message-ID: <065.8a29e4ddbabf4b0a098cbe6e033e50ff@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 -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"e88e083d62389d5c8d082a25395a3d933ab2f03b/ghc" e88e083/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e88e083d62389d5c8d082a25395a3d933ab2f03b" Fix #14579 by defining tyConAppNeedsKindSig, and using it }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:00 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:00 -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.17821ec4a3cfaf1f4a63777128ff1c97@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: | -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"406e43af2f12756c80d583b86326f760f2f584cc/ghc" 406e43a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="406e43af2f12756c80d583b86326f760f2f584cc" Add `-fplugin-trustworthy` to avoid marking modules as unsafe By default, when a module is compiled with plugins, it will be marked as unsafe. With this flag passed, all plugins are treated as trustworthy and the safety inference will no longer be affected. This fixes Trac #16260. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -0000 Subject: [GHC] #16287: :kind accepts bogus type In-Reply-To: <046.2d74c48b8d1e89592a078a196c553359@haskell.org> References: <046.2d74c48b8d1e89592a078a196c553359@haskell.org> Message-ID: <061.4ede5340463e01e34d1f1925669f51a1@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"c07e7ecbdfc05429fb6ce84c547c0365d2754db7/ghc" c07e7ec/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c07e7ecbdfc05429fb6ce84c547c0365d2754db7" Fix #16287 by checking for more unsaturated synonym arguments Trac #16287 shows that we were checking for unsaturated type synonym arguments (in `:kind`) when the argument was to a type synonym, but _not_ when the argument was to some other form of type constructor, such as a data type. The solution is to use the machinery that rejects unsaturated type synonym arguments (previously confined to `check_syn_tc_app`) to `check_arg_type`, which checks these other forms of arguments. While I was in town, I cleaned up `check_syn_tc_app` a bit to only invoke `check_arg_type` so as to minimize the number of different code paths that that function could go down. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -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.264359af98a7a9e701240b28cafa74a2@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"606db8c2580d40157e0aa6a9352b3d2e18ab6bc6/ghc" 606db8c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="606db8c2580d40157e0aa6a9352b3d2e18ab6bc6" testsuite: Mark T11334b as broken in debugged compiler As noted in #16112. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -0000 Subject: [GHC] #14759: ListSetOps WARNING causes tests to fail In-Reply-To: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> References: <045.a3d44c4c76e1fc42f26bbcbe8a0b0377@haskell.org> Message-ID: <060.2dde1c62af5eda5b7656556304a013b2@haskell.org> #14759: ListSetOps WARNING causes tests to fail -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4628 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"7e495b402f8350a856abcb2a8a58d694c03c5367/ghc" 7e495b4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7e495b402f8350a856abcb2a8a58d694c03c5367" testsuite: Mark recomp007 as broken in debugged compiler As noted in #14759, this triggers a warning in ListSetOps. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -0000 Subject: [GHC] #16113: T14740 fails in debugged compiler In-Reply-To: <046.c9b4ae7f3e4977e264b15bebaf299066@haskell.org> References: <046.c9b4ae7f3e4977e264b15bebaf299066@haskell.org> Message-ID: <061.27028fcd603da54e804f745503c3d90a@haskell.org> #16113: T14740 fails in debugged compiler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 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 Marge Bot ): In [changeset:"71d5ab07fe413fb0d9b04b6b55abc6055c1f0a2e/ghc" 71d5ab07/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="71d5ab07fe413fb0d9b04b6b55abc6055c1f0a2e" testsuite: Mark T14740 and tcfail159 as broken in debugged compiler As noted in #16113, these trigger an assertion in isUnliftedRuntimeRep. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -0000 Subject: [GHC] #16251: T5515 broken in devel2 flavour In-Reply-To: <046.ba26575c5471a49d616aae74eb31e3bc@haskell.org> References: <046.ba26575c5471a49d616aae74eb31e3bc@haskell.org> Message-ID: <061.cbd7a420a128b5aeb836f94746f84677@haskell.org> #16251: T5515 broken in devel2 flavour -------------------------------------+------------------------------------- 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 Marge Bot ): In [changeset:"aad05fb3b36b93b919622f8a6dc032109d040d16/ghc" aad05fb3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="aad05fb3b36b93b919622f8a6dc032109d040d16" testsuite: Mark T5515 as broken with debugged compiler As noted in #16251. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -0000 Subject: [GHC] #14729: normaliseType is not well-kinded In-Reply-To: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> References: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> Message-ID: <062.2aa76531e15e66c5c7fa57673975a993@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"2b90356d26b4699227816ad9424e766eccdb6c36/ghc" 2b90356d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2b90356d26b4699227816ad9424e766eccdb6c36" Fix #14729 by making the normaliser homogeneous This ports the fix to #12919 to the normaliser. (#12919 was about the flattener.) Because the fix is involved, this is done by moving the critical piece of code to Coercion, and then calling this from both the flattener and the normaliser. The key bit is: simplifying type families in a type is always a *homogeneous* operation. See #12919 for a discussion of why this is the Right Way to simplify type families. Also fixes #15549. test case: dependent/should_compile/T14729{,kind} typecheck/should_compile/T15549[ab] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -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.a03b5700e9c55a6864c7650bcbaf20f2@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"03b7abc19c8b0ec5c606cc2da208d2d004807fe9/ghc" 03b7abc1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="03b7abc19c8b0ec5c606cc2da208d2d004807fe9" Allow resizing the stack for the graph allocator. The graph allocator now dynamically resizes the number of stack slots when running into the limit. This fixes #8657. Also loop membership of basic blocks is now available in the register allocator for cost heuristics. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -0000 Subject: [GHC] #15549: Core Lint error with EmptyCase In-Reply-To: <050.9a179952570cbedc58a57ced12c92bb9@haskell.org> References: <050.9a179952570cbedc58a57ced12c92bb9@haskell.org> Message-ID: <065.a543878fb187f3b0776e33f4d8b7cc91@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 Marge Bot ): In [changeset:"2b90356d26b4699227816ad9424e766eccdb6c36/ghc" 2b90356d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2b90356d26b4699227816ad9424e766eccdb6c36" Fix #14729 by making the normaliser homogeneous This ports the fix to #12919 to the normaliser. (#12919 was about the flattener.) Because the fix is involved, this is done by moving the critical piece of code to Coercion, and then calling this from both the flattener and the normaliser. The key bit is: simplifying type families in a type is always a *homogeneous* operation. See #12919 for a discussion of why this is the Right Way to simplify type families. Also fixes #15549. test case: dependent/should_compile/T14729{,kind} typecheck/should_compile/T15549[ab] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -0000 Subject: [GHC] #12919: Equality not used for substitution In-Reply-To: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> References: <048.c4e450c7b401a6295cbd8b394ff2a079@haskell.org> Message-ID: <063.0df3637562efb6579bcb6860efeb3c0a@haskell.org> #12919: Equality not used for substitution -------------------------------------+------------------------------------- Reporter: int-index | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T12919 Blocked By: | Blocking: 14441 Related Tickets: #13643 | Differential Rev(s): Phab:D3848 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"2b90356d26b4699227816ad9424e766eccdb6c36/ghc" 2b90356d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2b90356d26b4699227816ad9424e766eccdb6c36" Fix #14729 by making the normaliser homogeneous This ports the fix to #12919 to the normaliser. (#12919 was about the flattener.) Because the fix is involved, this is done by moving the critical piece of code to Coercion, and then calling this from both the flattener and the normaliser. The key bit is: simplifying type families in a type is always a *homogeneous* operation. See #12919 for a discussion of why this is the Right Way to simplify type families. Also fixes #15549. test case: dependent/should_compile/T14729{,kind} typecheck/should_compile/T15549[ab] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -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.3b2c0fba5a97c570f7c1794e79cea246@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: | -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"f17a5765075631b7057aba7c582ea72b28c42d9a/ghc" f17a576/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f17a5765075631b7057aba7c582ea72b28c42d9a" ImplicitParams does not imply FlexibleContexts or FlexibleInstances, fixes #16248 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -0000 Subject: [GHC] #16128: Pattern match checker should shortcut on simple cases In-Reply-To: <043.0e1826f4368f9063454ace8cf25bfbf0@haskell.org> References: <043.0e1826f4368f9063454ace8cf25bfbf0@haskell.org> Message-ID: <058.40cdee5d9c14396dc04977cf77325fa0@haskell.org> #16128: Pattern match checker should shortcut on simple cases -------------------------------------+------------------------------------- Reporter: gbaz | Owner: (none) Type: feature request | 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 Marge Bot ): In [changeset:"d97f0db8fa6c5d9a4c90c6096b01a76da07cfb2b/ghc" d97f0db/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d97f0db8fa6c5d9a4c90c6096b01a76da07cfb2b" Fix test for T16180 on Darwin (fix #16128) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -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.71964e71d2c6645aaa1b87d8c0b0b75a@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"cbfc9fcaa33c3b341830962906543dfca1dfedd7/ghc" cbfc9fca/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cbfc9fcaa33c3b341830962906543dfca1dfedd7" API Annotations: AnnAt disconnected for TYPEAPP For the code type family F1 (a :: k) (f :: k -> Type) :: Type where F1 @Peano a f = T @Peano f a the API annotation for the first @ is not attached to a SourceSpan in the ParsedSource Closes #16236 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -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.67c99ec3809c35e04bf9d6a7493f564b@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"be15f7457b98fa0378de7e8146c122757f03c4e9/ghc" be15f74/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="be15f7457b98fa0378de7e8146c122757f03c4e9" API Annotations: more explicit foralls fixup The AnnForall annotations introduced via Phab:D4894 are not always attached to the correct SourceSpan. Closes #16230 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -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.93c5830125c2bb89f7acc2ec38b46c21@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"c1cf2693d6efddeeeb813cd8995a1be136800d17/ghc" c1cf2693/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c1cf2693d6efddeeeb813cd8995a1be136800d17" Lexer: Alternate Layout Rule injects actual not virtual braces 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. Likewise, any injected ITsemi should have a zero-width SrcSpan. Test case (the existing T13087.hs) {-# LANGUAGE AlternativeLayoutRule #-} {-# LANGUAGE LambdaCase #-} isOne :: Int -> Bool isOne = \case 1 -> True _ -> False main = return () Closes #16279 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -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.787e305178db17ff6f8b29e5e0bee35c@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: | -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"5e9888bd9c22a1315a703f638591b50e657317c4/ghc" 5e9888b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5e9888bd9c22a1315a703f638591b50e657317c4" API Annotations: parens anns discarded for `(*)` operator The patch from https://phabricator.haskell.org/D4865 introduces go _ (HsParTy _ (dL->L l (HsStarTy _ isUni))) acc ann fix = do { warnStarBndr l ; let name = mkOccName tcClsName (if isUni then "★" else "*") ; return (cL l (Unqual name), acc, fix, ann) } which discards the parens annotations belonging to the HsParTy. Updates haddock submodule Closes #16265 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -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.aa3c5a8e6538a3987d21503b24ceb84f@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"3fcf79a47138661bb01276a94e3b6d934ba92d4d/ghc" 3fcf79a4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3fcf79a47138661bb01276a94e3b6d934ba92d4d" Fix inverted position pragma flag in parser API The behviour of `lexTokenStream` around position pragma was accidentally inverted in 469fe6133646df5568c9486de2202124cb734242. This fixes that bug. This also unbreaks #16239. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -0000 Subject: [GHC] #16274: Remove ghctags In-Reply-To: <051.60fcdc3e4ceedcac5234a746e3c693c6@haskell.org> References: <051.60fcdc3e4ceedcac5234a746e3c693c6@haskell.org> Message-ID: <066.1f379c5b42a6be9908d33c7fb2b0665d@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"027017fb33923b106765f5a0a6fc000ebe421d40/ghc" 027017f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="027017fb33923b106765f5a0a6fc000ebe421d40" Remove ghctags (#16274) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -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.8d356ed799797fce9ffe3a7e29e527ea@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: | -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"a48753bdbc99cda36890e851950f5b79e1c3b2b2/ghc" a48753b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a48753bdbc99cda36890e851950f5b79e1c3b2b2" Capture and simplify constraints arising from running typed splices This fixes a regression caused by #15471 where splicing in a trivial program such as `[|| return () ||]` would fail as the dictionary for `return` would never get bound in the module containing the splice. Arguably this is symptomatic of a major problem affecting TTH where we serialise renamed asts and then retype check them. The reference to the dictionary should be fully determined at the quote site so that splicing doesn't have to solve any implicits at all. It's a coincidence this works due to coherence but see #15863 and #15865 for examples where things do go very wrong. Fixes #16195 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -0000 Subject: [GHC] #15865: Typed template haskell and implicit parameters lead to incorrect results In-Reply-To: <049.50989e98ce3c53add7b90ce8ecb60b22@haskell.org> References: <049.50989e98ce3c53add7b90ce8ecb60b22@haskell.org> Message-ID: <064.622faab2efbd1d6139f0d41d62678b24@haskell.org> #15865: Typed template haskell and implicit parameters lead to incorrect results -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: 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 Marge Bot ): In [changeset:"a48753bdbc99cda36890e851950f5b79e1c3b2b2/ghc" a48753b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a48753bdbc99cda36890e851950f5b79e1c3b2b2" Capture and simplify constraints arising from running typed splices This fixes a regression caused by #15471 where splicing in a trivial program such as `[|| return () ||]` would fail as the dictionary for `return` would never get bound in the module containing the splice. Arguably this is symptomatic of a major problem affecting TTH where we serialise renamed asts and then retype check them. The reference to the dictionary should be fully determined at the quote site so that splicing doesn't have to solve any implicits at all. It's a coincidence this works due to coherence but see #15863 and #15865 for examples where things do go very wrong. Fixes #16195 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -0000 Subject: [GHC] #15863: Splcing a type class method selects the wrong instance In-Reply-To: <049.3c21fc110d711ef2aacc94971be8c9ed@haskell.org> References: <049.3c21fc110d711ef2aacc94971be8c9ed@haskell.org> Message-ID: <064.0ad98fd6ec742f58e5fa454f296709c6@haskell.org> #15863: Splcing a type class method selects the wrong instance -------------------------------------+------------------------------------- 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 Marge Bot ): In [changeset:"a48753bdbc99cda36890e851950f5b79e1c3b2b2/ghc" a48753b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a48753bdbc99cda36890e851950f5b79e1c3b2b2" Capture and simplify constraints arising from running typed splices This fixes a regression caused by #15471 where splicing in a trivial program such as `[|| return () ||]` would fail as the dictionary for `return` would never get bound in the module containing the splice. Arguably this is symptomatic of a major problem affecting TTH where we serialise renamed asts and then retype check them. The reference to the dictionary should be fully determined at the quote site so that splicing doesn't have to solve any implicits at all. It's a coincidence this works due to coherence but see #15863 and #15865 for examples where things do go very wrong. Fixes #16195 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -0000 Subject: [GHC] #15471: Polymorphism, typed splices and type inference don't mix In-Reply-To: <049.084aa260e703fc9ae584d3d54f195e8c@haskell.org> References: <049.084aa260e703fc9ae584d3d54f195e8c@haskell.org> Message-ID: <064.27f0620ff4a5abfbb028b732a84a1bba@haskell.org> #15471: Polymorphism, typed splices and type inference don't mix -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: fixed | Keywords: | TypedTemplateHaskell Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: th/T15471 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5286, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/106 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"a48753bdbc99cda36890e851950f5b79e1c3b2b2/ghc" a48753b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a48753bdbc99cda36890e851950f5b79e1c3b2b2" Capture and simplify constraints arising from running typed splices This fixes a regression caused by #15471 where splicing in a trivial program such as `[|| return () ||]` would fail as the dictionary for `return` would never get bound in the module containing the splice. Arguably this is symptomatic of a major problem affecting TTH where we serialise renamed asts and then retype check them. The reference to the dictionary should be fully determined at the quote site so that splicing doesn't have to solve any implicits at all. It's a coincidence this works due to coherence but see #15863 and #15865 for examples where things do go very wrong. Fixes #16195 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -0000 Subject: [GHC] #16293: Inconsistencies and oddities of Proxy# In-Reply-To: <050.2f25f16e44a73b8047b8a62971a2da19@haskell.org> References: <050.2f25f16e44a73b8047b8a62971a2da19@haskell.org> Message-ID: <065.caa736a2d0a91c13646923c71606e98d@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"012257c15f584069500af2953ab70856f9a1470e/ghc" 012257c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="012257c15f584069500af2953ab70856f9a1470e" Fix #16293 by cleaning up Proxy# infelicities This bug fixes three problems related to `Proxy#`/`proxy#`: 1. Reifying it with TH claims that the `Proxy#` type constructor has two arguments, but that ought to be one for consistency with TH's treatment for other primitive type constructors like `(->)`. This was fixed by just returning the number of `tyConVisibleTyVars` instead of using `tyConArity` (which includes invisible arguments). 2. The role of `Proxy#`'s visible argument was hard-coded as nominal. Easily fixed by changing it to phantom. 3. The visibility of `proxy#`'s kind argument was specified, which is different from the `Proxy` constructor (which treats it as inferred). Some minor refactoring in `proxyHashId` fixed ths up. Along the way, I had to introduce a `mkSpecForAllTy` function, so I did some related Haddock cleanup in `Type`, where that function lives. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -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.84b72741ebd45bf2c33d79c52a4728bd@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"4a4ae70f09009c5d32696445a06eacb273f364b5/ghc" 4a4ae70/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4a4ae70f09009c5d32696445a06eacb273f364b5" Fix #16188 There was an awful lot of zipping going on in canDecomposableTyConAppOK, and one of the lists being zipped was too short, causing the result to be too short. Easily fixed. Also fixes #16204 and #16225 test case: typecheck/should_compile/T16188 typecheck/should_compile/T16204[ab] typecheck/should_fail/T16204c typecheck/should_compile/T16225 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -0000 Subject: [GHC] #16193: Nondeterministic T15897 timeout failures In-Reply-To: <050.6b50375f06c0c1355a5fdb64d26cefc5@haskell.org> References: <050.6b50375f06c0c1355a5fdb64d26cefc5@haskell.org> Message-ID: <065.7092eb2ee5366536f956b646eb337928@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"f53ef1a72fdebeff19d4a4bd5552d25101c85147/ghc" f53ef1a7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f53ef1a72fdebeff19d4a4bd5552d25101c85147" testsuite: Always skip T15897 See #16193. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -0000 Subject: [GHC] #16188: GHC HEAD-only panic (buildKindCoercion) In-Reply-To: <050.c1e2a5597ec56ace62b7c3a9590a59aa@haskell.org> References: <050.c1e2a5597ec56ace62b7c3a9590a59aa@haskell.org> Message-ID: <065.3914cf96ae13a1013c2e2bda9859a203@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"4a4ae70f09009c5d32696445a06eacb273f364b5/ghc" 4a4ae70/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4a4ae70f09009c5d32696445a06eacb273f364b5" Fix #16188 There was an awful lot of zipping going on in canDecomposableTyConAppOK, and one of the lists being zipped was too short, causing the result to be too short. Easily fixed. Also fixes #16204 and #16225 test case: typecheck/should_compile/T16188 typecheck/should_compile/T16204[ab] typecheck/should_fail/T16204c typecheck/should_compile/T16225 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -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.e3f09a3a78894c4a0da6f0524eaf45b1@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"4a4ae70f09009c5d32696445a06eacb273f364b5/ghc" 4a4ae70/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4a4ae70f09009c5d32696445a06eacb273f364b5" Fix #16188 There was an awful lot of zipping going on in canDecomposableTyConAppOK, and one of the lists being zipped was too short, causing the result to be too short. Easily fixed. Also fixes #16204 and #16225 test case: typecheck/should_compile/T16188 typecheck/should_compile/T16204[ab] typecheck/should_fail/T16204c typecheck/should_compile/T16225 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:02 -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.168b215153851a1b4a2a3984a4816127@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"7f26b74e409d058005909fc2b2ed2e6027d49365/ghc" 7f26b74/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7f26b74e409d058005909fc2b2ed2e6027d49365" Add `liftedTyped` to `Lift` class Implements GHC proposal 43, adding a `liftTyped` method to the `Lift` typeclass. This also adds some documentation to `TExp`, describing typed splices and their advantages over their untyped counterparts. Resolves #14671. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -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.25328c2d45eed1ea840ce97135229f61@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"a08f463bcc9727d91cec4c6e952ad0f5bbc3fbf9/ghc" a08f463b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a08f463bcc9727d91cec4c6e952ad0f5bbc3fbf9" Fix #15849 by checking whether there's a do block }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:02 -0000 Subject: [GHC] #16303: checkStack sanity check fails In-Reply-To: <043.5c62864ddc74f11e27dba9e7181f6bec@haskell.org> References: <043.5c62864ddc74f11e27dba9e7181f6bec@haskell.org> Message-ID: <058.794df846ffbb091889bae5bd7c706bd6@haskell.org> #16303: checkStack sanity check fails -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"6b890d76a252259843a6e87043f8f12e6a8a0aae/ghc" 6b890d76/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6b890d76a252259843a6e87043f8f12e6a8a0aae" Fix checkStackChunk() call in Interepter.c, enable an assertion Fixes #16303 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:02 -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.ffa789bf00331881d791f6f971ce1949@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"1d9a1d9fb8fe0a1fea2c44c4246f102ff3e1f3a3/ghc" 1d9a1d9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1d9a1d9fb8fe0a1fea2c44c4246f102ff3e1f3a3" NCG: fast compilation of very large strings (#16190) This patch adds an optimization into the NCG: for large strings (threshold configurable via -fbinary-blob-threshold=NNN flag), instead of printing `.asciz "..."` in the generated ASM source, we print `.incbin "tmpXXX.dat"` and we dump the contents of the string into a temporary "tmpXXX.dat" file. See the note for more details. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:01 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:01 -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.d900d74d1245927f9c588eb1a9176b98@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"8b476d822e97cfe4cebe6e74924d9a79148d608c/ghc" 8b476d82/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8b476d822e97cfe4cebe6e74924d9a79148d608c" Fix #16299 by deleting incorrect code from IfaceSyn GHCi's `:info` command was pretty-printing Haskell98-style data types with explicit return kinds if the return kind wasn't `Type`. This leads to bizarre output like this: ``` λ> :i (##) data (##) :: TYPE ('GHC.Types.TupleRep '[]) = (##) -- Defined in ‘GHC.Prim’ ``` Or, with unlifted newtypes: ``` λ> newtype T = MkT Int# λ> :i T newtype T :: TYPE 'IntRep = MkT Int# -- Defined at :5:1 ``` The solution is simple: just delete one part from `IfaceSyn` where GHC mistakenly pretty-prints the return kinds for non-GADTs. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:02 -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.9d6b13a2e2a13ad7b88f369b871a9a28@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"0f1eb88c93143359fa671bb72aceebc299c87a95/ghc" 0f1eb88c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0f1eb88c93143359fa671bb72aceebc299c87a95" Add perf test for #16190 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:02 -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.e1175c2b70742e417ffb7c7a93049441@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 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"682783828275cca5fd8bf5be5b52054c75e0e22c/ghc" 6827838/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="682783828275cca5fd8bf5be5b52054c75e0e22c" Make a smart mkAppTyM This patch finally delivers on Trac #15952. Specifically * Completely remove Note [The tcType invariant], along with its complicated consequences (IT1-IT6). * Replace Note [The well-kinded type invariant] with: Note [The Purely Kinded Type Invariant (PKTI)] * Instead, establish the (PKTI) in TcHsType.tcInferApps, by using a new function mkAppTyM when building a type application. See Note [mkAppTyM]. * As a result we can remove the delicate mkNakedXX functions entirely. Specifically, mkNakedCastTy retained lots of extremly delicate Refl coercions which just cluttered everything up, and(worse) were very vulnerable to being silently eliminated by (say) substTy. This led to a succession of bug reports. The result is noticeably simpler to explain, simpler to code, and Richard and I are much more confident that it is correct. It does not actually fix any bugs, but it brings us closer. E.g. I hoped it'd fix #15918 and #15799, but it doesn't quite do so. However, it makes it much easier to fix. I also did a raft of other minor refactorings: * Use tcTypeKind consistently in the type checker * Rename tcInstTyBinders to tcInvisibleTyBinders, and refactor it a bit * Refactor tcEqType, pickyEqType, tcEqTypeVis Simpler, probably more efficient. * Make zonkTcType zonk TcTyCons, at least if they have any free unification variables -- see zonk_tc_tycon in TcMType.zonkTcTypeMapper. Not zonking these TcTyCons was actually a bug before. * Simplify try_to_reduce_no_cache in TcFlatten (a lot) * Combine checkExpectedKind and checkExpectedKindX. And then combine the invisible-binder instantation code Much simpler now. * Fix a little bug in TcMType.skolemiseQuantifiedTyVar. I'm not sure how I came across this originally. * Fix a little bug in TyCoRep.isUnliftedRuntimeRep (the ASSERT was over-zealous). Again I'm not certain how I encountered this. * Add a missing solveLocalEqualities in TcHsType.tcHsPartialSigType. I came across this when trying to get level numbers right. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:02 -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.567e787ab5d13fc01e5efd3816944b81@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"9b39597b66b6a46c1af2bb939dd77d01544ab7be/ghc" 9b39597b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9b39597b66b6a46c1af2bb939dd77d01544ab7be" Fix tests which were made to pass by "Make a smart mkAppTyM" For some reason gitlab is not reporting these as failures in CI. It's not clear to me why as the junit output looks fine. Fixes #16112 and #16113 They were fixed by 682783828275cca5fd8bf5be5b52054c75e0e22c }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:02 -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.50dd35043be1a41f57621afc2a719972@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"af7b0fdb64ad1c57f5829e8bd89e8e0fa96b11d2/ghc" af7b0fdb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="af7b0fdb64ad1c57f5829e8bd89e8e0fa96b11d2" Cmm: Promote stack arguments to word size Smaller than word size integers must be promoted to word size when passed on the stack. While on little endian systems we can get away with writing a small integer to a word size stack slot and read it as a word ignoring the upper bits, on big endian systems a small integer write ends up in the most significant bits and a word size read that ignores the upper bits delivers a random value. On little endian systems a smaller than word size write to the stack might be more efficient but that decision is system specific and should be done as an optimization in the respective backends. Fixes #16258 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:02 -0000 Subject: [GHC] #15918: GHC panic from QuantifiedConstraints(?) In-Reply-To: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> References: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> Message-ID: <066.74aae786a59e8d85da70b569afbaeb02@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 Simon Peyton Jones ): In [changeset:"682783828275cca5fd8bf5be5b52054c75e0e22c/ghc" 6827838/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="682783828275cca5fd8bf5be5b52054c75e0e22c" Make a smart mkAppTyM This patch finally delivers on Trac #15952. Specifically * Completely remove Note [The tcType invariant], along with its complicated consequences (IT1-IT6). * Replace Note [The well-kinded type invariant] with: Note [The Purely Kinded Type Invariant (PKTI)] * Instead, establish the (PKTI) in TcHsType.tcInferApps, by using a new function mkAppTyM when building a type application. See Note [mkAppTyM]. * As a result we can remove the delicate mkNakedXX functions entirely. Specifically, mkNakedCastTy retained lots of extremly delicate Refl coercions which just cluttered everything up, and(worse) were very vulnerable to being silently eliminated by (say) substTy. This led to a succession of bug reports. The result is noticeably simpler to explain, simpler to code, and Richard and I are much more confident that it is correct. It does not actually fix any bugs, but it brings us closer. E.g. I hoped it'd fix #15918 and #15799, but it doesn't quite do so. However, it makes it much easier to fix. I also did a raft of other minor refactorings: * Use tcTypeKind consistently in the type checker * Rename tcInstTyBinders to tcInvisibleTyBinders, and refactor it a bit * Refactor tcEqType, pickyEqType, tcEqTypeVis Simpler, probably more efficient. * Make zonkTcType zonk TcTyCons, at least if they have any free unification variables -- see zonk_tc_tycon in TcMType.zonkTcTypeMapper. Not zonking these TcTyCons was actually a bug before. * Simplify try_to_reduce_no_cache in TcFlatten (a lot) * Combine checkExpectedKind and checkExpectedKindX. And then combine the invisible-binder instantation code Much simpler now. * Fix a little bug in TcMType.skolemiseQuantifiedTyVar. I'm not sure how I came across this originally. * Fix a little bug in TyCoRep.isUnliftedRuntimeRep (the ASSERT was over-zealous). Again I'm not certain how I encountered this. * Add a missing solveLocalEqualities in TcHsType.tcHsPartialSigType. I came across this when trying to get level numbers right. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:02 -0000 Subject: [GHC] #16113: T14740 fails in debugged compiler In-Reply-To: <046.c9b4ae7f3e4977e264b15bebaf299066@haskell.org> References: <046.c9b4ae7f3e4977e264b15bebaf299066@haskell.org> Message-ID: <061.8bc9a7e4aed8f9b8f2d284731245d941@haskell.org> #16113: T14740 fails in debugged compiler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 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 Marge Bot ): In [changeset:"9b39597b66b6a46c1af2bb939dd77d01544ab7be/ghc" 9b39597b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9b39597b66b6a46c1af2bb939dd77d01544ab7be" Fix tests which were made to pass by "Make a smart mkAppTyM" For some reason gitlab is not reporting these as failures in CI. It's not clear to me why as the junit output looks fine. Fixes #16112 and #16113 They were fixed by 682783828275cca5fd8bf5be5b52054c75e0e22c }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:02 -0000 Subject: [GHC] #15799: GHC panic (and warnings) In-Reply-To: <051.9f403c90f37670c8d3e47780b16a76ec@haskell.org> References: <051.9f403c90f37670c8d3e47780b16a76ec@haskell.org> Message-ID: <066.b9b95ab9f4f73c587b60493c9e1ae8f2@haskell.org> #15799: GHC panic (and warnings) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.1 Resolution: fixed | 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 Simon Peyton Jones ): In [changeset:"682783828275cca5fd8bf5be5b52054c75e0e22c/ghc" 6827838/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="682783828275cca5fd8bf5be5b52054c75e0e22c" Make a smart mkAppTyM This patch finally delivers on Trac #15952. Specifically * Completely remove Note [The tcType invariant], along with its complicated consequences (IT1-IT6). * Replace Note [The well-kinded type invariant] with: Note [The Purely Kinded Type Invariant (PKTI)] * Instead, establish the (PKTI) in TcHsType.tcInferApps, by using a new function mkAppTyM when building a type application. See Note [mkAppTyM]. * As a result we can remove the delicate mkNakedXX functions entirely. Specifically, mkNakedCastTy retained lots of extremly delicate Refl coercions which just cluttered everything up, and(worse) were very vulnerable to being silently eliminated by (say) substTy. This led to a succession of bug reports. The result is noticeably simpler to explain, simpler to code, and Richard and I are much more confident that it is correct. It does not actually fix any bugs, but it brings us closer. E.g. I hoped it'd fix #15918 and #15799, but it doesn't quite do so. However, it makes it much easier to fix. I also did a raft of other minor refactorings: * Use tcTypeKind consistently in the type checker * Rename tcInstTyBinders to tcInvisibleTyBinders, and refactor it a bit * Refactor tcEqType, pickyEqType, tcEqTypeVis Simpler, probably more efficient. * Make zonkTcType zonk TcTyCons, at least if they have any free unification variables -- see zonk_tc_tycon in TcMType.zonkTcTypeMapper. Not zonking these TcTyCons was actually a bug before. * Simplify try_to_reduce_no_cache in TcFlatten (a lot) * Combine checkExpectedKind and checkExpectedKindX. And then combine the invisible-binder instantation code Much simpler now. * Fix a little bug in TcMType.skolemiseQuantifiedTyVar. I'm not sure how I came across this originally. * Fix a little bug in TyCoRep.isUnliftedRuntimeRep (the ASSERT was over-zealous). Again I'm not certain how I encountered this. * Add a missing solveLocalEqualities in TcHsType.tcHsPartialSigType. I came across this when trying to get level numbers right. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:02 -0000 Subject: [GHC] #16077: AvailTC Invariant being violated In-Reply-To: <050.e27325be4d9bf8b20310c66c423e8dec@haskell.org> References: <050.e27325be4d9bf8b20310c66c423e8dec@haskell.org> Message-ID: <065.0ecf5f2ef1575f1dfff4eed5eb3bb7f4@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 -------------------------------------+------------------------------------- Comment (by Alec Theriault ): In [changeset:"2a431640d199b164ca5d233684d4f4bdaf5ca021/ghc" 2a43164/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2a431640d199b164ca5d233684d4f4bdaf5ca021" Uphold AvailTC Invariant for associated data fams The AvailTC was not be upheld for explicit export module export lists when the module contains associated data families. module A (module A) where class C a where { data T a } instance C () where { data T () = D } Used to (incorrectly) report avails as `[C{C, T;}, T{D;}]`. Note that although `T` is exported, the avail where it is the parent does _not_ list it as its first element. This avail is now correctly listed as `[C{C, T;}, T{T, D;}]`. This was induces a [crash in Haddock][0]. See #16077. [0]: https://github.com/haskell/haddock/issues/979 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51: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.48057e415e25f3c963f79df97ec30061@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"9049bfb1773cf114fd4e2d2d6daed46af2b73093/ghc" 9049bfb1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9049bfb1773cf114fd4e2d2d6daed46af2b73093" Disable binder swap in OccurAnal (Trac #16288) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:02 -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.cce8a7a32f212c60357c89b0a38be8ce@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/ -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"b78cc64e923716ac0512c299f42d4d0012306c05/ghc" b78cc64/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b78cc64e923716ac0512c299f42d4d0012306c05" Make constructor wrappers inline only during the final phase For case-of-known constructor to continue triggering early, exprIsConApp_maybe is now capable of looking through lets and cases. See #15840 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:02 -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.daf9b888cc487d439f15329d345bf642@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/ -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"7833cf407d1f608bebb1d38bb99d3035d8d735e6/ghc" 7833cf40/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7833cf407d1f608bebb1d38bb99d3035d8d735e6" Look through newtype wrappers (Trac #16254) exprIsConApp_maybe could detect that I# 10 is a constructor application, but not that Size (I# 10) is, because it was an application with a nontrivial argument. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:02 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.6f8d0fa04506efe750304d6a0a2c6cd3@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 Marge Bot ): In [changeset:"908b4b8659713f0b7a1704ce33c7fa30e3e0ffc3/ghc" 908b4b86/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="908b4b8659713f0b7a1704ce33c7fa30e3e0ffc3" Fix two bugs in stg_ap_0_fast in profiling runtime This includes two bug fixes in profiling version of stg_ap_0_fast: - PAPs allocated by stg_ap_0_fast are now correctly tagged. This invariant is checked in Sanity.c:checkPAP. (This was originally implemented in 2693eb11f5, later reverted with ab55b4ddb7 because it revealed the bug below, but it wasn't clear at the time whether the bug was the one below or something in the commit) - The local variable `untaggedfun` is now marked as a pointer so it survives GC. With this we finally fix all known bugs caught in #15508. `concprog001` now works reliably with prof+threaded and prof runtimes (with and without -debug). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:02 -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.735a5a5311fd2dfb977c167f1e0bdcc7@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: | -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"1dad4fc27ea128a11ba0077f459494c2a1ca0d5c/ghc" 1dad4fc2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1dad4fc27ea128a11ba0077f459494c2a1ca0d5c" Hadrian: Fix untracked dependencies This is a preparation for #16295: https://ghc.haskell.org/trac/ghc/ticket/16295 This commit mostly focuses on getting rid of untracked dependencies, which prevent Shake's new `--shared` feature from appropriately caching build rules. There are three different solutions to untracked dependencies: * Track them! This is the obvious and the best approach, but in some situations we cannot use it, for example, because a build rule creates files whose names are not known statically and hence cannot be specified as the rule's outputs. * Use Shake's `produces` to record outputs dynamically, within the rule. * Use Shake's `historyDisable` to disable caching for a particular build rule. We currently use this approach only for `ghc-pkg` which mutates the package database and the file `package.cache`. These two tickets are fixed as the result: Ticket #16271: ​https://ghc.haskell.org/trac/ghc/ticket/16271 Ticket #16272: ​https://ghc.haskell.org/trac/ghc/ticket/16272 (this one is fixed only partially: we correctly record the dependency, but we still copy files into the RTS build tree). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:02 -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.aa69c52ea1f6b99e2e829fb5824c0cb4@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: | -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"1dad4fc27ea128a11ba0077f459494c2a1ca0d5c/ghc" 1dad4fc2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1dad4fc27ea128a11ba0077f459494c2a1ca0d5c" Hadrian: Fix untracked dependencies This is a preparation for #16295: https://ghc.haskell.org/trac/ghc/ticket/16295 This commit mostly focuses on getting rid of untracked dependencies, which prevent Shake's new `--shared` feature from appropriately caching build rules. There are three different solutions to untracked dependencies: * Track them! This is the obvious and the best approach, but in some situations we cannot use it, for example, because a build rule creates files whose names are not known statically and hence cannot be specified as the rule's outputs. * Use Shake's `produces` to record outputs dynamically, within the rule. * Use Shake's `historyDisable` to disable caching for a particular build rule. We currently use this approach only for `ghc-pkg` which mutates the package database and the file `package.cache`. These two tickets are fixed as the result: Ticket #16271: ​https://ghc.haskell.org/trac/ghc/ticket/16271 Ticket #16272: ​https://ghc.haskell.org/trac/ghc/ticket/16272 (this one is fixed only partially: we correctly record the dependency, but we still copy files into the RTS build tree). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:02 -0000 Subject: [GHC] #16295: Enable cached builds with Hadrian In-Reply-To: <050.90024ab429dfe175278d9c32201a7dda@haskell.org> References: <050.90024ab429dfe175278d9c32201a7dda@haskell.org> Message-ID: <065.5b53ab215c3148f55110cf04af18ca9c@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: | -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"1dad4fc27ea128a11ba0077f459494c2a1ca0d5c/ghc" 1dad4fc2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1dad4fc27ea128a11ba0077f459494c2a1ca0d5c" Hadrian: Fix untracked dependencies This is a preparation for #16295: https://ghc.haskell.org/trac/ghc/ticket/16295 This commit mostly focuses on getting rid of untracked dependencies, which prevent Shake's new `--shared` feature from appropriately caching build rules. There are three different solutions to untracked dependencies: * Track them! This is the obvious and the best approach, but in some situations we cannot use it, for example, because a build rule creates files whose names are not known statically and hence cannot be specified as the rule's outputs. * Use Shake's `produces` to record outputs dynamically, within the rule. * Use Shake's `historyDisable` to disable caching for a particular build rule. We currently use this approach only for `ghc-pkg` which mutates the package database and the file `package.cache`. These two tickets are fixed as the result: Ticket #16271: ​https://ghc.haskell.org/trac/ghc/ticket/16271 Ticket #16272: ​https://ghc.haskell.org/trac/ghc/ticket/16272 (this one is fixed only partially: we correctly record the dependency, but we still copy files into the RTS build tree). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:02 -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.3814de0cbc304c449f79d9409c117d90@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 Matthew Pickering ): In [changeset:"0eb7cf03da3783ca887d5de44d312cf6f3a4113c/ghc" 0eb7cf03/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0eb7cf03da3783ca887d5de44d312cf6f3a4113c" Don't do binder-swap for GlobalIds This patch disables the binder-swap transformation in the (relatively rare) case when the scrutinee is a GlobalId. Reason: we are getting Lint errors so that GHC doesn't even validate. Trac #16346. This is NOT the final solution -- it's just a stop-gap to get us running again. The final solution is in Trac #16296 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:02 -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.52c386c39fb91f473385f158f2ea052a@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 Marge Bot ): In [changeset:"0e2d300a59b1b5c167d2e7d99a448c8663ba6d7d/ghc" 0e2d300a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0e2d300a59b1b5c167d2e7d99a448c8663ba6d7d" compiler: Write .o files atomically. See #14533 This issue was reproduced with, and the fix confirmed with, the `hatrace` tool for syscall-based fault injection: https://github.com/nh2/hatrace The concrete test case for GHC is at https://github.com/nh2/hatrace/blob/e23d35a2d2c79e8bf49e9e2266b3ff7094267f29/test/HatraceSpec.hs#L185 A previous, nondeterministic reproducer for the issue was provided by Alexey Kuleshevich in https://github.com/lehins/exec-kill-loop Signed-off-by: Niklas Hambüchen Reviewed-by: Alexey Kuleshevich }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:02 -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.b33f0ede61bc24f4f8b2b0b3e0b256d3@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 Marge Bot ): In [changeset:"5eeefe4c1e007ea2098f241634b48a4dada785a5/ghc" 5eeefe4c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5eeefe4c1e007ea2098f241634b48a4dada785a5" Improve the very simple optimiser slightly There was a missing case in the very simple optimiser, CoreOpt.simpleOptExpr, which led to Trac #13208 comment:2. In particular, in simple_app, if we find a Let, we should just float it outwards. Otherwise we leave behind some easy-to-reduce beta-redexes. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:02 -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.80e1c3305be4b62bca669d62d367d3c1@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 Marge Bot ): In [changeset:"2f4af71e73ac3b59f4faba5bf1b25774b1008898/ghc" 2f4af71e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2f4af71e73ac3b59f4faba5bf1b25774b1008898" Dot/bang operators in export lists (Trac #16339) The dot type operator was handled in the 'tyvarop' parser production, and the bang type operator in 'tyapp'. However, export lists and role annotations use 'oqtycon', so these type operators could not be exported or assigned roles. The fix is to handle them in a lower level production, 'tyconsym'. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:02 -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.64353127e1a9a740912b771051d15941@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 -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"0eb7cf03da3783ca887d5de44d312cf6f3a4113c/ghc" 0eb7cf03/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0eb7cf03da3783ca887d5de44d312cf6f3a4113c" Don't do binder-swap for GlobalIds This patch disables the binder-swap transformation in the (relatively rare) case when the scrutinee is a GlobalId. Reason: we are getting Lint errors so that GHC doesn't even validate. Trac #16346. This is NOT the final solution -- it's just a stop-gap to get us running again. The final solution is in Trac #16296 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:02 -0000 Subject: [GHC] #16348: GHC HEAD regression: tyConAppArgs In-Reply-To: <050.e9808338869e8c4617d16395b0fc7408@haskell.org> References: <050.e9808338869e8c4617d16395b0fc7408@haskell.org> Message-ID: <065.b5cafce45cab9c8b8ecd70c6dbdc4a61@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 -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"c25b135ff5b9c69a90df0ccf51b04952c2dc6ee1/ghc" c25b135f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c25b135ff5b9c69a90df0ccf51b04952c2dc6ee1" Fix exprIsConApp_maybe In this commit commit 7833cf407d1f608bebb1d38bb99d3035d8d735e6 Date: Thu Jan 24 17:58:50 2019 +0100 Look through newtype wrappers (Trac #16254) we made exprIsConApp_maybe quite a bit cleverer. But I had not paid enough attention to keeping exactly the correct substitution and in-scope set, which led to Trac #16348. There were several buglets (like applying the substitution twice in exprIsConApp_maybe, but the proximate source of the bug was that we were calling addNewInScopeIds, which deleted things from the substitution as well as adding them to the in-scope set. That's usually right, but not here! This was quite tricky to track down. But it is nicer now. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 18:51:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 18:51:02 -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.79bb7a14f94b224829cedc1a4ff278b8@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/ -------------------------------------+------------------------------------- Comment (by Matthew Pickering ): In [changeset:"c25b135ff5b9c69a90df0ccf51b04952c2dc6ee1/ghc" c25b135f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c25b135ff5b9c69a90df0ccf51b04952c2dc6ee1" Fix exprIsConApp_maybe In this commit commit 7833cf407d1f608bebb1d38bb99d3035d8d735e6 Date: Thu Jan 24 17:58:50 2019 +0100 Look through newtype wrappers (Trac #16254) we made exprIsConApp_maybe quite a bit cleverer. But I had not paid enough attention to keeping exactly the correct substitution and in-scope set, which led to Trac #16348. There were several buglets (like applying the substitution twice in exprIsConApp_maybe, but the proximate source of the bug was that we were calling addNewInScopeIds, which deleted things from the substitution as well as adding them to the in-scope set. That's usually right, but not here! This was quite tricky to track down. But it is nicer now. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 21:04:34 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 21:04:34 -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.49bd2f0366ee946031fa88cd78c0cab2@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"ac34e784775a0fa8b7284d42ff89571907afdc36/ghc" ac34e78/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ac34e784775a0fa8b7284d42ff89571907afdc36" Remove bogus assertion Remove a bogus assertion in FamInst.newFamInst (There is a comment to explain.) This fixes Trac #16112. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 21:04:34 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 21:04:34 -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.ce5ac475686972e77bf2d1425e8469fc@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 Marge Bot ): In [changeset:"806cc234426dca41e1c799e9e6212cf9e352d180/ghc" 806cc234/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="806cc234426dca41e1c799e9e6212cf9e352d180" Build and copy libffi shared libraries correctly and enable dynamically linking ghc. Test Plan: Ensure build environment does NOT have a system libffi installed (you may want to use a nix environment). Then `hadrian/build.sh -c --flavour=default` Reviewers: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15837 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 21:04:34 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 21:04:34 -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.075319d3f95ee85b72595a18703f7f60@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"6cce36f83aec33d33545e0ef2135894d22dff5ca/ghc" 6cce36f8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6cce36f83aec33d33545e0ef2135894d22dff5ca" Add AnonArgFlag to FunTy The big payload of this patch is: Add an AnonArgFlag to the FunTy constructor of Type, so that (FunTy VisArg t1 t2) means (t1 -> t2) (FunTy InvisArg t1 t2) means (t1 => t2) The big payoff is that we have a simple, local test to make when decomposing a type, leading to many fewer calls to isPredTy. To me the code seems a lot tidier, and probably more efficient (isPredTy has to take the kind of the type). See Note [Function types] in TyCoRep. There are lots of consequences * I made FunTy into a record, so that it'll be easier when we add a linearity field, something that is coming down the road. * Lots of code gets touched in a routine way, simply because it pattern matches on FunTy. * I wanted to make a pattern synonym for (FunTy2 arg res), which picks out just the argument and result type from the record. But alas the pattern-match overlap checker has a heart attack, and either reports false positives, or takes too long. In the end I gave up on pattern synonyms. There's some commented-out code in TyCoRep that shows what I wanted to do. * Much more clarity about predicate types, constraint types and (in particular) equality constraints in kinds. See TyCoRep Note [Types for coercions, predicates, and evidence] and Note [Constraints in kinds]. This made me realise that we need an AnonArgFlag on AnonTCB in a TyConBinder, something that was really plain wrong before. See TyCon Note [AnonTCB InivsArg] * When building function types we must know whether we need VisArg (mkVisFunTy) or InvisArg (mkInvisFunTy). This turned out to be pretty easy in practice. * Pretty-printing of types, esp in IfaceType, gets tidier, because we were already recording the (->) vs (=>) distinction in an ad-hoc way. Death to IfaceFunTy. * mkLamType needs to keep track of whether it is building (t1 -> t2) or (t1 => t2). See Type Note [mkLamType: dictionary arguments] Other minor stuff * Some tidy-up in validity checking involving constraints; Trac #16263 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 21:04:34 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 21:04:34 -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.7e6d876a591e31746d46daea6ba62fff@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"ee284b854e514685036dc21a1ee61241c76d14b5/ghc" ee284b85/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ee284b854e514685036dc21a1ee61241c76d14b5" Fix regression incorrectly advertising TH support `--supported-languages` must only advertise language extensions which are supported by the compiler in order for tooling such as Cabal relying on this signalling not to behave incorrectly. Fixes #16331 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 21:04:34 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 21:04:34 -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.09f71fcc10764a6e4291e7cda7966273@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 Marge Bot ): In [changeset:"9059343e8d1fc94ac62145688d6fdd70a791eaf1/ghc" 9059343e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9059343e8d1fc94ac62145688d6fdd70a791eaf1" base: Allow fusion for zip7 and related Fixes #14037. Metric Decrease: T9872b T9872d Reviewers: bgamari, simonpj, hvr Reviewed By: simonpj Subscribers: AndreasK, simonpj, osa1, dfeuer, rwbarton, carter GHC Trac Issues: #14037 Differential Revision: https://phabricator.haskell.org/D5249 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 21:04:34 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 21:04:34 -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.8b5000ed30cf6b6a4bad373c3aeec133@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"14586f5d737ec5dc828633267b50dcf0d47e1696/ghc" 14586f5d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="14586f5d737ec5dc828633267b50dcf0d47e1696" Disable fragile test cases: T14697 T5559 T3424 See Trac #15072, Trac #16349, Trac #16350 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 21:04:34 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 21:04:34 -0000 Subject: [GHC] #16349: Nondeterministic T3424 timeouts on CI In-Reply-To: <050.2a09de2550baf6c7c958ab823c4e0558@haskell.org> References: <050.2a09de2550baf6c7c958ab823c4e0558@haskell.org> Message-ID: <065.75a72c91bebaca498a99d8f0416ea24a@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"14586f5d737ec5dc828633267b50dcf0d47e1696/ghc" 14586f5d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="14586f5d737ec5dc828633267b50dcf0d47e1696" Disable fragile test cases: T14697 T5559 T3424 See Trac #15072, Trac #16349, Trac #16350 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 21:04:34 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 21:04:34 -0000 Subject: [GHC] #16201: ghci063 failing on Darwin In-Reply-To: <046.5e984b197caa806ce5eae32ad316f9a0@haskell.org> References: <046.5e984b197caa806ce5eae32ad316f9a0@haskell.org> Message-ID: <061.f6c1e4230d26cf2f91d08247a268fe16@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 -------------------------------------+------------------------------------- Comment (by Vladislav Zavialov ): In [changeset:"f320f3b2f2f421af41b8f7588529ed46bbe6ccf3/ghc" f320f3b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f320f3b2f2f421af41b8f7588529ed46bbe6ccf3" Fix the ghci063 test on Darwin (Trac #16201) We use "touch -r" to set modification timestamps, which leads to precision loss on Darwin. For example, before: 2019-02-25 01:11:23.807627350 +0300 after: 2019-02-25 01:11:23.807627000 +0300 ^^^ This means we can't trick GHCi into thinking the file hasn't been changed by restoring its old timestamp, as we cannot faithfully restore all digits. The solution is to nullify the insignificant digits before the first :load }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 21:04:34 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 21:04:34 -0000 Subject: [GHC] #16350: Nondeterministic T5559 failures on CI In-Reply-To: <050.9b58e539362fa36351f44a14284fd7e8@haskell.org> References: <050.9b58e539362fa36351f44a14284fd7e8@haskell.org> Message-ID: <065.212e2d3fdcff5251a7a66877dccd2be5@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"14586f5d737ec5dc828633267b50dcf0d47e1696/ghc" 14586f5d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="14586f5d737ec5dc828633267b50dcf0d47e1696" Disable fragile test cases: T14697 T5559 T3424 See Trac #15072, Trac #16349, Trac #16350 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 21:04:34 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 21:04: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.1df3e4c1255a6fbba713f656a94000cb@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"5bc195b1fe788e9a900a15fbe473967850517c3e/ghc" 5bc195b1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5bc195b1fe788e9a900a15fbe473967850517c3e" Treat kind/type variables identically, demolish FKTV Implements GHC Proposal #24: .../ghc-proposals/blob/master/proposals/0024 -no-kind-vars.rst Fixes Trac #16334, Trac #16315 With this patch, scoping rules for type and kind variables have been unified: kind variables no longer receieve special treatment. This simplifies both the language and the implementation. User-facing changes ------------------- * Kind variables are no longer implicitly quantified when an explicit forall is used: p :: Proxy (a :: k) -- still accepted p :: forall k a. Proxy (a :: k) -- still accepted p :: forall a. Proxy (a :: k) -- no longer accepted In other words, now we adhere to the "forall-or-nothing" rule more strictly. Related function: RnTypes.rnImplicitBndrs * The -Wimplicit-kind-vars warning has been deprecated. * Kind variables are no longer implicitly quantified in constructor declarations: data T a = T1 (S (a :: k) | forall (b::k). T2 (S b) -- no longer accepted data T (a :: k) = T1 (S (a :: k) | forall (b::k). T2 (S b) -- still accepted Related function: RnTypes.extractRdrKindSigVars * Implicitly quantified kind variables are no longer put in front of other variables: f :: Proxy (a :: k) -> Proxy (b :: j) f :: forall k j (a :: k) (b :: j). Proxy a -> Proxy b -- old order f :: forall k (a :: k) j (b :: j). Proxy a -> Proxy b -- new order This is a breaking change for users of TypeApplications. Note that we still respect the dpendency order: 'k' before 'a', 'j' before 'b'. See "Ordering of specified variables" in the User's Guide. Related function: RnTypes.rnImplicitBndrs * In type synonyms and type family equations, free variables on the RHS are no longer implicitly quantified unless used in an outermost kind annotation: type T = Just (Nothing :: Maybe a) -- no longer accepted type T = Just Nothing :: Maybe (Maybe a) -- still accepted The latter form is a workaround due to temporary lack of an explicit quantification method. Ideally, we would write something along these lines: type T @a = Just (Nothing :: Maybe a) Related function: RnTypes.extractHsTyRdrTyVarsKindVars * Named wildcards in kinds are fixed (Trac #16334): x :: (Int :: _t) -- this compiles, infers (_t ~ Type) Related function: RnTypes.partition_nwcs Implementation notes -------------------- * One of the key changes is the removal of FKTV in RnTypes: - data FreeKiTyVars = FKTV { fktv_kis :: [Located RdrName] - , fktv_tys :: [Located RdrName] } + type FreeKiTyVars = [Located RdrName] We used to keep track of type and kind variables separately, but now that they are on equal footing when it comes to scoping, we can put them in the same list. * extract_lty and family are no longer parametrized by TypeOrKind, as we now do not distinguish kind variables from type variables. * PatSynExPE and the related Note [Pattern synonym existentials do not scope] have been removed (Trac #16315). With no implicit kind quantification, we can no longer trigger the error. * reportFloatingKvs and the related Note [Free-floating kind vars] have been removed. With no implicit kind quantification, we can no longer trigger the error. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 21:04:35 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 21:04:35 -0000 Subject: [GHC] #15658: strange inferred kind with TypeInType In-Reply-To: <044.5c56e4e9c5ca25f242e17058c46d6daa@haskell.org> References: <044.5c56e4e9c5ca25f242e17058c46d6daa@haskell.org> Message-ID: <059.76f550aca42b9bdf5e597977a0575a6c@haskell.org> #15658: strange inferred kind with TypeInType -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.2 Resolution: fixed | 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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"c26d299dc422f43b8c37da4b26da2067eedcbae8/ghc" c26d299/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c26d299dc422f43b8c37da4b26da2067eedcbae8" Visible dependent quantification This implements GHC proposal 35 (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0035 -forall-arrow.rst) by adding the ability to write kinds with visible dependent quantification (VDQ). Most of the work for supporting VDQ was actually done _before_ this patch. That is, GHC has been able to reason about kinds with VDQ for some time, but it lacked the ability to let programmers directly write these kinds in the source syntax. This patch is primarly about exposing this ability, by: * Changing `HsForAllTy` to add an additional field of type `ForallVisFlag` to distinguish between invisible `forall`s (i.e, with dots) and visible `forall`s (i.e., with arrows) * Changing `Parser.y` accordingly The rest of the patch mostly concerns adding validity checking to ensure that VDQ is never used in the type of a term (as permitting this would require full-spectrum dependent types). This is accomplished by: * Adding a `vdqAllowed` predicate to `TcValidity`. * Introducing `splitLHsSigmaTyInvis`, a variant of `splitLHsSigmaTy` that only splits invisible `forall`s. This function is used in certain places (e.g., in instance declarations) to ensure that GHC doesn't try to split visible `forall`s (e.g., if it tried splitting `instance forall a -> Show (Blah a)`, then GHC would mistakenly allow that declaration!) This also updates Template Haskell by introducing a new `ForallVisT` constructor to `Type`. Fixes #16326. Also fixes #15658 by documenting this feature in the users' guide. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 21:04:35 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 21:04:35 -0000 Subject: [GHC] #16270: Report multiple errors during parsing In-Reply-To: <048.8241d0d6fb8bb59986f0e3aa22e6e182@haskell.org> References: <048.8241d0d6fb8bb59986f0e3aa22e6e182@haskell.org> Message-ID: <063.4c9698fb285bd28bb2deea879c8fe3c6@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: | -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"f37efb11b957a21f3048f7005a234f96350ff938/ghc" f37efb11/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f37efb11b957a21f3048f7005a234f96350ff938" Lexer: turn some fatal errors into non-fatal ones The following previously fatal lexer errors are now non-fatal: * errors about enabling `LambdaCase` * errors about enabling `NumericUnderscores` * errors about having valid characters in primitive strings See #16270 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 21:04:34 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 21:04:34 -0000 Subject: [GHC] #24: dlopen() errors reported badly In-Reply-To: <045.676523c95d1fc6d4297bf919f23ef94f@haskell.org> References: <045.676523c95d1fc6d4297bf919f23ef94f@haskell.org> Message-ID: <060.5143e32a6d68da5ccb30e55cb49f4d96@haskell.org> #24: dlopen() errors reported badly --------------------------------+-------------------- Reporter: cwitty | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Driver | Version: 5.02 Resolution: Fixed | Keywords: Type of failure: None/Unknown | --------------------------------+-------------------- Changes (by Marge Bot ): * failure: => None/Unknown Comment: In [changeset:"5bc195b1fe788e9a900a15fbe473967850517c3e/ghc" 5bc195b1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5bc195b1fe788e9a900a15fbe473967850517c3e" Treat kind/type variables identically, demolish FKTV Implements GHC Proposal #24: .../ghc-proposals/blob/master/proposals/0024 -no-kind-vars.rst Fixes Trac #16334, Trac #16315 With this patch, scoping rules for type and kind variables have been unified: kind variables no longer receieve special treatment. This simplifies both the language and the implementation. User-facing changes ------------------- * Kind variables are no longer implicitly quantified when an explicit forall is used: p :: Proxy (a :: k) -- still accepted p :: forall k a. Proxy (a :: k) -- still accepted p :: forall a. Proxy (a :: k) -- no longer accepted In other words, now we adhere to the "forall-or-nothing" rule more strictly. Related function: RnTypes.rnImplicitBndrs * The -Wimplicit-kind-vars warning has been deprecated. * Kind variables are no longer implicitly quantified in constructor declarations: data T a = T1 (S (a :: k) | forall (b::k). T2 (S b) -- no longer accepted data T (a :: k) = T1 (S (a :: k) | forall (b::k). T2 (S b) -- still accepted Related function: RnTypes.extractRdrKindSigVars * Implicitly quantified kind variables are no longer put in front of other variables: f :: Proxy (a :: k) -> Proxy (b :: j) f :: forall k j (a :: k) (b :: j). Proxy a -> Proxy b -- old order f :: forall k (a :: k) j (b :: j). Proxy a -> Proxy b -- new order This is a breaking change for users of TypeApplications. Note that we still respect the dpendency order: 'k' before 'a', 'j' before 'b'. See "Ordering of specified variables" in the User's Guide. Related function: RnTypes.rnImplicitBndrs * In type synonyms and type family equations, free variables on the RHS are no longer implicitly quantified unless used in an outermost kind annotation: type T = Just (Nothing :: Maybe a) -- no longer accepted type T = Just Nothing :: Maybe (Maybe a) -- still accepted The latter form is a workaround due to temporary lack of an explicit quantification method. Ideally, we would write something along these lines: type T @a = Just (Nothing :: Maybe a) Related function: RnTypes.extractHsTyRdrTyVarsKindVars * Named wildcards in kinds are fixed (Trac #16334): x :: (Int :: _t) -- this compiles, infers (_t ~ Type) Related function: RnTypes.partition_nwcs Implementation notes -------------------- * One of the key changes is the removal of FKTV in RnTypes: - data FreeKiTyVars = FKTV { fktv_kis :: [Located RdrName] - , fktv_tys :: [Located RdrName] } + type FreeKiTyVars = [Located RdrName] We used to keep track of type and kind variables separately, but now that they are on equal footing when it comes to scoping, we can put them in the same list. * extract_lty and family are no longer parametrized by TypeOrKind, as we now do not distinguish kind variables from type variables. * PatSynExPE and the related Note [Pattern synonym existentials do not scope] have been removed (Trac #16315). With no implicit kind quantification, we can no longer trigger the error. * reportFloatingKvs and the related Note [Free-floating kind vars] have been removed. With no implicit kind quantification, we can no longer trigger the error. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 21:04:35 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 21:04:35 -0000 Subject: [GHC] #16334: Named wildcards in kinds In-Reply-To: <048.1c12b4f97b648562a3f1fdca2d35171a@haskell.org> References: <048.1c12b4f97b648562a3f1fdca2d35171a@haskell.org> Message-ID: <063.00178c56d644cad6d504d9afa5cfc449@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"5bc195b1fe788e9a900a15fbe473967850517c3e/ghc" 5bc195b1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5bc195b1fe788e9a900a15fbe473967850517c3e" Treat kind/type variables identically, demolish FKTV Implements GHC Proposal #24: .../ghc-proposals/blob/master/proposals/0024 -no-kind-vars.rst Fixes Trac #16334, Trac #16315 With this patch, scoping rules for type and kind variables have been unified: kind variables no longer receieve special treatment. This simplifies both the language and the implementation. User-facing changes ------------------- * Kind variables are no longer implicitly quantified when an explicit forall is used: p :: Proxy (a :: k) -- still accepted p :: forall k a. Proxy (a :: k) -- still accepted p :: forall a. Proxy (a :: k) -- no longer accepted In other words, now we adhere to the "forall-or-nothing" rule more strictly. Related function: RnTypes.rnImplicitBndrs * The -Wimplicit-kind-vars warning has been deprecated. * Kind variables are no longer implicitly quantified in constructor declarations: data T a = T1 (S (a :: k) | forall (b::k). T2 (S b) -- no longer accepted data T (a :: k) = T1 (S (a :: k) | forall (b::k). T2 (S b) -- still accepted Related function: RnTypes.extractRdrKindSigVars * Implicitly quantified kind variables are no longer put in front of other variables: f :: Proxy (a :: k) -> Proxy (b :: j) f :: forall k j (a :: k) (b :: j). Proxy a -> Proxy b -- old order f :: forall k (a :: k) j (b :: j). Proxy a -> Proxy b -- new order This is a breaking change for users of TypeApplications. Note that we still respect the dpendency order: 'k' before 'a', 'j' before 'b'. See "Ordering of specified variables" in the User's Guide. Related function: RnTypes.rnImplicitBndrs * In type synonyms and type family equations, free variables on the RHS are no longer implicitly quantified unless used in an outermost kind annotation: type T = Just (Nothing :: Maybe a) -- no longer accepted type T = Just Nothing :: Maybe (Maybe a) -- still accepted The latter form is a workaround due to temporary lack of an explicit quantification method. Ideally, we would write something along these lines: type T @a = Just (Nothing :: Maybe a) Related function: RnTypes.extractHsTyRdrTyVarsKindVars * Named wildcards in kinds are fixed (Trac #16334): x :: (Int :: _t) -- this compiles, infers (_t ~ Type) Related function: RnTypes.partition_nwcs Implementation notes -------------------- * One of the key changes is the removal of FKTV in RnTypes: - data FreeKiTyVars = FKTV { fktv_kis :: [Located RdrName] - , fktv_tys :: [Located RdrName] } + type FreeKiTyVars = [Located RdrName] We used to keep track of type and kind variables separately, but now that they are on equal footing when it comes to scoping, we can put them in the same list. * extract_lty and family are no longer parametrized by TypeOrKind, as we now do not distinguish kind variables from type variables. * PatSynExPE and the related Note [Pattern synonym existentials do not scope] have been removed (Trac #16315). With no implicit kind quantification, we can no longer trigger the error. * reportFloatingKvs and the related Note [Free-floating kind vars] have been removed. With no implicit kind quantification, we can no longer trigger the error. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 21:04:35 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 21:04:35 -0000 Subject: [GHC] #13633: testwsdeque failure on POWER8 In-Reply-To: <047.ae02b20f2505c57c0490241ee65b452f@haskell.org> References: <047.ae02b20f2505c57c0490241ee65b452f@haskell.org> Message-ID: <062.86a1d2371b56067db3b9d56fffafd344@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 Marge Bot ): In [changeset:"5c084e0468be46f5ab48b2c1669a7e4d4d0f3c43/ghc" 5c084e04/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5c084e0468be46f5ab48b2c1669a7e4d4d0f3c43" RTS: Add missing memory barrier In the work stealing queue a load-load-barrier is required to ensure that a read of queue data cannot be reordered before a read of the bottom pointer into the queue. The added load-load-barrier ensures that the ordering of writes enforced at the end of `pushWSDeque` is also respected in the order of reads in `stealWSDeque_`. In other words, when reading `q->bottom` we want to make sure that we see the updates to `q->elements`. Fixes #13633 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 21:04:35 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 21:04:35 -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.2903fded05ca2ee75f563e5562e7879b@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 Ben Gamari ): In [changeset:"e6ce17433b75c6c985bffaf1f6fc18d299666ccb/ghc" e6ce1743/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e6ce17433b75c6c985bffaf1f6fc18d299666ccb" Revert "compiler: Write .o files atomically. See #14533" This reverts commit 0e2d300a59b1b5c167d2e7d99a448c8663ba6d7d. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 21:04:35 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 21:04:35 -0000 Subject: [GHC] #16326: Implement visible dependent quantification In-Reply-To: <050.f131455e14d32ddc45fc2fafca130412@haskell.org> References: <050.f131455e14d32ddc45fc2fafca130412@haskell.org> Message-ID: <065.0ca76ee7bb4c13e895dfd305ce1d4054@haskell.org> #16326: Implement visible dependent quantification -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: GHCProposal, | VisibleDependentQuantification Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/T16326_Compile{1,2}, | dependent/should_fail/T16326_Fail{1,2,3,4,5,6,7,8,9,10,11,12}, | th/T16326_TH Blocked By: | Blocking: Related Tickets: #15658 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/378 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"c26d299dc422f43b8c37da4b26da2067eedcbae8/ghc" c26d299/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c26d299dc422f43b8c37da4b26da2067eedcbae8" Visible dependent quantification This implements GHC proposal 35 (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0035 -forall-arrow.rst) by adding the ability to write kinds with visible dependent quantification (VDQ). Most of the work for supporting VDQ was actually done _before_ this patch. That is, GHC has been able to reason about kinds with VDQ for some time, but it lacked the ability to let programmers directly write these kinds in the source syntax. This patch is primarly about exposing this ability, by: * Changing `HsForAllTy` to add an additional field of type `ForallVisFlag` to distinguish between invisible `forall`s (i.e, with dots) and visible `forall`s (i.e., with arrows) * Changing `Parser.y` accordingly The rest of the patch mostly concerns adding validity checking to ensure that VDQ is never used in the type of a term (as permitting this would require full-spectrum dependent types). This is accomplished by: * Adding a `vdqAllowed` predicate to `TcValidity`. * Introducing `splitLHsSigmaTyInvis`, a variant of `splitLHsSigmaTy` that only splits invisible `forall`s. This function is used in certain places (e.g., in instance declarations) to ensure that GHC doesn't try to split visible `forall`s (e.g., if it tried splitting `instance forall a -> Show (Blah a)`, then GHC would mistakenly allow that declaration!) This also updates Template Haskell by introducing a new `ForallVisT` constructor to `Type`. Fixes #16326. Also fixes #15658 by documenting this feature in the users' guide. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 21:24:19 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 21:24:19 -0000 Subject: [GHC] #16384: GHC infers ill-kinded type for typed TH splice with unlifted values In-Reply-To: <049.204094150d2dd49ce6dfbaa5f785ab8c@haskell.org> References: <049.204094150d2dd49ce6dfbaa5f785ab8c@haskell.org> Message-ID: <064.e3ec47ad6104c4ed0bed966c5cdb700b@haskell.org> #16384: GHC infers ill-kinded type for typed TH splice with unlifted values -------------------------------------+------------------------------------- Reporter: gridaphobe | 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 harpocrates): * cc: harpocrates (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 22:00:38 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 22:00:38 -0000 Subject: [GHC] #16326: Implement visible dependent quantification In-Reply-To: <050.f131455e14d32ddc45fc2fafca130412@haskell.org> References: <050.f131455e14d32ddc45fc2fafca130412@haskell.org> Message-ID: <065.36c3e38eb7a3793180b3463cd605db71@haskell.org> #16326: Implement visible dependent quantification -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: GHCProposal, | VisibleDependentQuantification Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/T16326_Compile{1,2}, | dependent/should_fail/T16326_Fail{1,2,3,4,5,6,7,8,9,10,11,12}, | th/T16326_TH Blocked By: | Blocking: Related Tickets: #15658 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/378 -------------------------------------+------------------------------------- Comment (by goldfire): :) We discussed the possibility of allowing VDQ in visible type applications, and how this patch wouldn't do so. Is there a Trac ticket requesting this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 22:03:42 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 22:03:42 -0000 Subject: [GHC] #16326: Implement visible dependent quantification In-Reply-To: <050.f131455e14d32ddc45fc2fafca130412@haskell.org> References: <050.f131455e14d32ddc45fc2fafca130412@haskell.org> Message-ID: <065.cd2f6260bd35c83669d76d1113f37d9c@haskell.org> #16326: Implement visible dependent quantification -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.7 Resolution: fixed | Keywords: GHCProposal, | VisibleDependentQuantification Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/T16326_Compile{1,2}, | dependent/should_fail/T16326_Fail{1,2,3,4,5,6,7,8,9,10,11,12}, | th/T16326_TH Blocked By: | Blocking: Related Tickets: #15658 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/378 -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:7 goldfire]: > We discussed the possibility of allowing VDQ in visible type applications, and how this patch wouldn't do so. Is there a Trac ticket requesting this? #16371. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 22:11:06 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 22:11:06 -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.eeaa7fc1a81e256a39442f25658ee25f@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): This was reverted due to a (apparently nondeterministic) build failure on Windows in later builds even though my Winodws validate succeeded. The build that failed for bgamari is https://gitlab.haskell.org/ghc/ghc/-/jobs/37771 The only thing I can imagine could result in this is when in `withAtomicRename targetFile f`, the action `f` doesn't actually write the file. But why would the assembler ''sometimes'' not do that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 23:40:15 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 23:40:15 -0000 Subject: [GHC] #16386: T16219 fails on Windows Message-ID: <046.254723c6029307e45222252a793b733d@haskell.org> #16386: T16219 fails on Windows ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- {{{ =====> T16219(normal) 85 of 6839 [0, 0, 0] cd "backpack/cabal/T16219/T16219.run" && $MAKE -s --no-print-directory T16219 CLEANUP=1 Wrong exit code for T16219()(expected 0 , actual 2 ) Stderr ( T16219 ): C:\GitLabRunner\builds\8fc0e283\0\ghc\ghc\inplace\lib\../mingw/bin\ar.exe: dist\build\backpack- issue-0.1.0.0-60IHJZyC3G628wj7263Sr0-library-a+Dil0EMVFuE1Kv7vqZWLGcN\objs-3388 \libHSbackpack- issue-0.1.0.0-60IHJZyC3G628wj7263Sr0-library-a+Dil0EMVFuE1Kv7vqZWLGcN.a: No such file or directory make[2]: *** [Makefile:12: T16219] Error 1 *** unexpected failure for T16219(normal) =====> bkpcabal03(normal) 88 of 6839 [0, 1, 0] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 23:42:16 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 23:42:16 -0000 Subject: [GHC] #16386: T16219 fails on Windows In-Reply-To: <046.254723c6029307e45222252a793b733d@haskell.org> References: <046.254723c6029307e45222252a793b733d@haskell.org> Message-ID: <061.acc1d78bc4eff7ca543b2160119b2c5b@haskell.org> #16386: T16219 fails on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * cc: Phyx- (added) Comment: `cabal09` has an intriguingly similar (albeit not reliable) failure: {{{ =====> cabal09(normal) 249 of 6839 [0, 1, 0] cd "cabal/cabal09/cabal09.run" && $MAKE -s --no-print-directory cabal09 CLEANUP=1 Wrong exit code for cabal09()(expected 0 , actual 2 ) Stderr ( cabal09 ): C:\GitLabRunner\builds\8fc0e283\0\ghc\ghc\tmp\ghcD256.o.tmp: renameFile:renamePath:MoveFileEx "\\\\?\\C:\\GitLabRunner\\builds\\8fc0e283\\0\\ghc\\ghc\\tmp\\ghcD256.o.tmp" Just "\\\\?\\C:\\GitLabRunner\\builds\\8fc0e283\\0\\ghc\\ghc\\tmp\\ghcD256.o": does not exist (The system cannot find the file specified.) make[2]: *** [Makefile:14: cabal09] Error 1 *** unexpected failure for cabal09(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 23:46:40 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 23:46:40 -0000 Subject: [GHC] #16387: Duplicate vsnwprintf symbol on Windows Message-ID: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> #16387: Duplicate vsnwprintf symbol on Windows -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- Leading to failure of `T5836`: ``` Stderr ( T5836 ): GHC runtime linker: fatal error: I found a duplicate definition for symbol __mingw_vsnwprintf whilst processing object file C:\GitLabRunner\builds\8fc0e283\0\ghc\ghc\inplace\mingw\x86_64-w64-mingw32\lib\libmingwex.a The symbol was previously defined in (GHCi built-in symbols) This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. ghc-stage2.exe: panic! (the 'impossible' happened) (GHC version 8.9.20190303 for x86_64-unknown-mingw32): loadArchive "C:\\GitLabRunner\\builds\\8fc0e283\\0\\ghc\\ghc\\inplace\\mingw\\x86_64-w64-mingw32\\lib\\libmingwex.a": failed Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug *** unexpected failure for T5836(ghci) ``` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 23:47:51 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 23:47:51 -0000 Subject: [GHC] #16387: Duplicate vsnwprintf symbol on Windows In-Reply-To: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> References: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> Message-ID: <061.ca5def1f4d2cfe07859b4a8f29e02a7c@haskell.org> #16387: Duplicate vsnwprintf symbol on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * os: Unknown/Multiple => Windows Old description: > Leading to failure of `T5836`: > > ``` > Stderr ( T5836 ): > GHC runtime linker: fatal error: I found a duplicate definition for > symbol > __mingw_vsnwprintf > whilst processing object file > C:\GitLabRunner\builds\8fc0e283\0\ghc\ghc\inplace\mingw\x86_64-w64-mingw32\lib\libmingwex.a > The symbol was previously defined in > (GHCi built-in symbols) > This could be caused by: > * Loading two different object files which export the same symbol > * Specifying the same object file twice on the GHCi command line > * An incorrect `package.conf' entry, causing some object to be > loaded twice. > ghc-stage2.exe: panic! (the 'impossible' happened) > (GHC version 8.9.20190303 for x86_64-unknown-mingw32): > loadArchive > "C:\\GitLabRunner\\builds\\8fc0e283\\0\\ghc\\ghc\\inplace\\mingw\\x86_64-w64-mingw32\\lib\\libmingwex.a": > failed > > Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug > *** unexpected failure for T5836(ghci) > ``` New description: Leading to failure of `T5836`: {{{ Stderr ( T5836 ): GHC runtime linker: fatal error: I found a duplicate definition for symbol __mingw_vsnwprintf whilst processing object file C:\GitLabRunner\builds\8fc0e283\0\ghc\ghc\inplace\mingw\x86_64-w64-mingw32\lib\libmingwex.a The symbol was previously defined in (GHCi built-in symbols) This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. ghc-stage2.exe: panic! (the 'impossible' happened) (GHC version 8.9.20190303 for x86_64-unknown-mingw32): loadArchive "C:\\GitLabRunner\\builds\\8fc0e283\\0\\ghc\\ghc\\inplace\\mingw\\x86_64-w64-mingw32\\lib\\libmingwex.a": failed Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug *** unexpected failure for T5836(ghci) }}} -- Comment: It seems there is some funniness around `printf` and MinGW. See `Note [Symbols for MinGW's printf]`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 23:48:02 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 23:48:02 -0000 Subject: [GHC] #16387: Duplicate vsnwprintf symbol on Windows In-Reply-To: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> References: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> Message-ID: <061.1d9b8347898eba7cf5dec66bffaaecf1@haskell.org> #16387: Duplicate vsnwprintf symbol on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): Marking as broken for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 23:52:28 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 23:52:28 -0000 Subject: [GHC] #16388: T15904 fails on Windows Message-ID: <046.82f2f3342e8649744417a61e12155c7d@haskell.org> #16388: T15904 fails on Windows ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- {{{ =====> T15904(normal) 2036 of 6839 [0, 6, 0] cd "hp2ps/T15904.run" && $MAKE -s --no-print-directory T15904 Wrong exit code for T15904()(expected 0 , actual 2 ) Stdout ( T15904 ): [1 of 1] Compiling T15904 ( T15904.hs, T15904.o ) Linking "T15904".exe ... Stderr ( T15904 ): "T15904".exe.manifest: openFile: invalid argument (Invalid argument) make[2]: *** [Makefile:7: T15904] Error 1 *** unexpected failure for T15904(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 4 23:56:30 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 04 Mar 2019 23:56:30 -0000 Subject: [GHC] #16389: T16190 fails on Windows Message-ID: <046.d5077b2a45b5901405da0c7bcdf7c6eb@haskell.org> #16389: T16190 fails on Windows ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- {{{ =====> T16190(normal) 3408 of 6839 [0, 7, 0] cd "perf/compiler/T16190.run" && "/c/GitLabRunner/builds/8fc0e283/0/ghc/ghc/inplace/bin/ghc-stage2.exe" --make T16190.hs -dstg-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 -v0 Compile failed (exit code 1) errors were: C:\\GitLabRunner\\builds\\8fc0e283\\0\\ghc\\ghc\\tmp\\ghc368_0\\ghc_5.s: Assembler messages: C:\\GitLabRunner\\builds\\8fc0e283\\0\\ghc\\ghc\\tmp\\ghc368_0\\ghc_5.s:5: Error: file not found: C:GitLabRunneruildsfc0e283 `gcc.exe' failed in phase `Assembler'. (Exit code: 1) *** unexpected failure for T16190(normal) }}} There is some use of TemplateHaskell's `embedBytes`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 00:14:04 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 00:14:04 -0000 Subject: [GHC] #16390: T10672 fails Message-ID: <046.82965e14e463cdb431c4fdc0d223bd88@haskell.org> #16390: T10672 fails ----------------------------------------+--------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- This test, which is only run on Windows, seems to be reliably timing out. Marking as broken. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 00:14:19 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 00:14:19 -0000 Subject: [GHC] #16390: T10672 fails In-Reply-To: <046.82965e14e463cdb431c4fdc0d223bd88@haskell.org> References: <046.82965e14e463cdb431c4fdc0d223bd88@haskell.org> Message-ID: <061.a428334cfb1c4569d9e9594482773171@haskell.org> #16390: T10672 fails ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: broken-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 bgamari): * keywords: => broken-test -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 00:14:46 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 00:14:46 -0000 Subject: [GHC] #16389: T16190 fails on Windows In-Reply-To: <046.d5077b2a45b5901405da0c7bcdf7c6eb@haskell.org> References: <046.d5077b2a45b5901405da0c7bcdf7c6eb@haskell.org> Message-ID: <061.0ff1fc8be3414331927c35129779492c@haskell.org> #16389: T16190 fails on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: broken-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 bgamari): * keywords: => broken-test Old description: > {{{ > =====> T16190(normal) 3408 of 6839 [0, 7, 0] > cd "perf/compiler/T16190.run" && > "/c/GitLabRunner/builds/8fc0e283/0/ghc/ghc/inplace/bin/ghc-stage2.exe" > --make T16190.hs -dstg-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 -v0 > Compile failed (exit code 1) errors were: > C:\\GitLabRunner\\builds\\8fc0e283\\0\\ghc\\ghc\\tmp\\ghc368_0\\ghc_5.s: > Assembler messages: > C:\\GitLabRunner\\builds\\8fc0e283\\0\\ghc\\ghc\\tmp\\ghc368_0\\ghc_5.s:5: > Error: file not found: C:GitLabRunneruildsfc0e283 > `gcc.exe' failed in phase `Assembler'. (Exit code: 1) > > *** unexpected failure for T16190(normal) > }}} > > There is some use of TemplateHaskell's `embedBytes`. New description: {{{ =====> T16190(normal) 3408 of 6839 [0, 7, 0] cd "perf/compiler/T16190.run" && "/c/GitLabRunner/builds/8fc0e283/0/ghc/ghc/inplace/bin/ghc-stage2.exe" --make T16190.hs -dstg-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 -v0 Compile failed (exit code 1) errors were: C:\\GitLabRunner\\builds\\8fc0e283\\0\\ghc\\ghc\\tmp\\ghc368_0\\ghc_5.s: Assembler messages: C:\\GitLabRunner\\builds\\8fc0e283\\0\\ghc\\ghc\\tmp\\ghc368_0\\ghc_5.s:5: Error: file not found: C:GitLabRunneruildsfc0e283 `gcc.exe' failed in phase `Assembler'. (Exit code: 1) *** unexpected failure for T16190(normal) }}} There is some use of TemplateHaskell's `embedBytes`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 00:14:54 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 00:14:54 -0000 Subject: [GHC] #16388: T15904 fails on Windows In-Reply-To: <046.82f2f3342e8649744417a61e12155c7d@haskell.org> References: <046.82f2f3342e8649744417a61e12155c7d@haskell.org> Message-ID: <061.c1e8b6bb20bf66f4ffca435046691c35@haskell.org> #16388: T15904 fails on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: broken-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 bgamari): * keywords: => broken-test -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 00:15:01 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 00:15:01 -0000 Subject: [GHC] #16387: Duplicate vsnwprintf symbol on Windows In-Reply-To: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> References: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> Message-ID: <061.f0a9717eea22df75be641f1eea127bec@haskell.org> #16387: Duplicate vsnwprintf symbol on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: broken-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 bgamari): * keywords: => broken-test -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 00:15:16 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 00:15:16 -0000 Subject: [GHC] #16386: T16219 fails on Windows In-Reply-To: <046.254723c6029307e45222252a793b733d@haskell.org> References: <046.254723c6029307e45222252a793b733d@haskell.org> Message-ID: <061.8bd195fdc8e1a8b5501fb349e1f4076c@haskell.org> #16386: T16219 fails on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: broken-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 bgamari): * keywords: => broken-test -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 00:17:34 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 00:17:34 -0000 Subject: [GHC] #16387: Duplicate vsnwprintf symbol on Windows In-Reply-To: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> References: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> Message-ID: <061.c96e54f8491fa721a117bee2d9371cd8@haskell.org> #16387: Duplicate vsnwprintf symbol on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: broken-test 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): `ClosedFam1TH` also fails due to this in the `ext-interp` way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 01:03:03 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 01:03:03 -0000 Subject: [GHC] #16389: T16190 fails on Windows In-Reply-To: <046.d5077b2a45b5901405da0c7bcdf7c6eb@haskell.org> References: <046.d5077b2a45b5901405da0c7bcdf7c6eb@haskell.org> Message-ID: <061.b3c82da45a3211757400dafb61af8682@haskell.org> #16389: T16190 fails on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: broken-test 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 hsyl20): That's because we don't escape "\" in the file name when we emit the ".incbin" ASM directive (in nativeGen/PprBase.hs#pprBytes). I thought I could fix this simply by copying the escaping code used when we emit ".file" directives (in nativeGen/AsmCodeGen.hs#cmmNativeGens) but we it seems like we don't escape those paths either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 03:56:16 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 03:56:16 -0000 Subject: [GHC] #16378: bkpcabal01 fails with recent Cabal In-Reply-To: <046.6dbe508947082fe98f8d1db57ed7604b@haskell.org> References: <046.6dbe508947082fe98f8d1db57ed7604b@haskell.org> Message-ID: <061.0c685521b1fc20f434d1e3e3339d078d@haskell.org> #16378: bkpcabal01 fails with recent Cabal -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new 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: | -------------------------------------+------------------------------------- Comment (by bgamari): A full log from running the test directly: {{{ ~/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01]$ make bkpcabal01 rm -f -r tmp.d inst dist Setup make -s --no-print-directory clean '/mnt/work/ghc/ghc-8.8/inplace/bin/ghc-pkg' init tmp.d '/mnt/work/ghc/ghc-8.8/inplace/bin/ghc-stage2' -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 -v0 --make Setup cp p/P.hs.in1 p/P.hs cp q/Q.hs.in1 q/Q.hs # typecheck p ./Setup -v0 configure --enable-library-vanilla --disable-shared --with- ghc='/mnt/work/ghc/ghc-8.8/inplace/bin/ghc-stage2' --ghc-options='-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' --package- db=tmp.d --prefix='/home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst' --cid "p-0.1" p ./Setup -v0 build ./Setup -v0 copy ./Setup -v0 register # build impl ./Setup -v0 configure --enable-library-vanilla --disable-shared --with- ghc='/mnt/work/ghc/ghc-8.8/inplace/bin/ghc-stage2' --ghc-options='-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' --package- db=tmp.d --prefix='/home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst' --cid "impl-0.1" impl ./Setup -v0 build ./Setup -v0 copy ./Setup -v0 register # typecheck q ./Setup -v0 configure --enable-library-vanilla --disable-shared --with- ghc='/mnt/work/ghc/ghc-8.8/inplace/bin/ghc-stage2' --ghc-options='-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' --package- db=tmp.d --prefix='/home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst' --cid "q-0.1" q Error: The following packages are broken because other packages they depend on are missing. These broken packages must be rebuilt before they can be used. planned package bkpcabal01-0.1.0.0 is broken due to missing package p-0.1+FBOSaiWyMx9DR2UZVI6wQJ make: *** [Makefile:25: bkpcabal01] Error 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 04:08:03 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 04:08:03 -0000 Subject: [GHC] #16378: bkpcabal01 fails with recent Cabal In-Reply-To: <046.6dbe508947082fe98f8d1db57ed7604b@haskell.org> References: <046.6dbe508947082fe98f8d1db57ed7604b@haskell.org> Message-ID: <061.911c9abc3f777dccaf85cee7f71331d4@haskell.org> #16378: bkpcabal01 fails with recent Cabal -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new 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: | -------------------------------------+------------------------------------- Comment (by bgamari): Here is a diff showing two runs of the test up to the point where it fails using GHC 8.6.3 (which passes) and `ghc-8.8` (which fails), {{{#!patch --- good 2019-03-05 04:05:04.165349753 +0000 +++ bad 2019-03-05 04:05:25.995764548 +0000 @@ -1,78 +1,74 @@ -++ which /nix/store/y6vdn971gmxziv4ryqqbaf1iy814i2z1-ghc-build- environment/bin/ghc -+ TEST_HC=/nix/store/y6vdn971gmxziv4ryqqbaf1iy814i2z1-ghc-build- environment/bin/ghc -++ dirname /nix/store/y6vdn971gmxziv4ryqqbaf1iy814i2z1-ghc-build- environment/bin/ghc -+ GHC_PKG=/nix/store/y6vdn971gmxziv4ryqqbaf1iy814i2z1-ghc-build- environment/bin/ghc-pkg +++ which /home/ben/ghc/ghc-8.8/inplace/bin/ghc-stage2 ++ TEST_HC=/home/ben/ghc/ghc-8.8/inplace/bin/ghc-stage2 +++ dirname /home/ben/ghc/ghc-8.8/inplace/bin/ghc-stage2 ++ GHC_PKG=/home/ben/ghc/ghc-8.8/inplace/bin/ghc-pkg + rm -R tmp.d -+ /nix/store/y6vdn971gmxziv4ryqqbaf1iy814i2z1-ghc-build-environment/bin /ghc-pkg init tmp.d -+ /nix/store/y6vdn971gmxziv4ryqqbaf1iy814i2z1-ghc-build- environment/bin/ghc -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 -v0 --make Setup - -on the commandline: warning: - unrecognised warning flag: -Werror=compat ++ /home/ben/ghc/ghc-8.8/inplace/bin/ghc-pkg init tmp.d ++ /home/ben/ghc/ghc-8.8/inplace/bin/ghc-stage2 -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 -v0 --make Setup + cp p/P.hs.in1 p/P.hs + cp q/Q.hs.in1 q/Q.hs -+ ./Setup -v0 configure --enable-library-vanilla --disable-shared --with- ghc=/nix/store/y6vdn971gmxziv4ryqqbaf1iy814i2z1-ghc-build- environment/bin/ghc '--ghc-options=-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' --package-db=tmp.d --prefix=/home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst --cid p-0.1 p - -on the commandline: warning: - unrecognised warning flag: -Werror=compat ++ ./Setup -v0 configure --enable-library-vanilla --disable-shared --with- ghc=/home/ben/ghc/ghc-8.8/inplace/bin/ghc-stage2 '--ghc-options=-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' --package- db=tmp.d --prefix=/home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst --cid p-0.1 p + ./Setup -v0 build + ./Setup -v0 copy + ./Setup -v0 register -+ ./Setup -v0 configure --enable-library-vanilla --disable-shared --with- ghc=/nix/store/y6vdn971gmxziv4ryqqbaf1iy814i2z1-ghc-build- environment/bin/ghc '--ghc-options=-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' --package-db=tmp.d --prefix=/home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst --cid impl-0.1 impl - -on the commandline: warning: - unrecognised warning flag: -Werror=compat ++ ./Setup -v0 configure --enable-library-vanilla --disable-shared --with- ghc=/home/ben/ghc/ghc-8.8/inplace/bin/ghc-stage2 '--ghc-options=-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' --package- db=tmp.d --prefix=/home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst --cid impl-0.1 impl + ./Setup -v0 build + ./Setup -v0 copy + ./Setup -v0 register -+ ./Setup -v0 configure --enable-library-vanilla --disable-shared --with- ghc=/nix/store/y6vdn971gmxziv4ryqqbaf1iy814i2z1-ghc-build- environment/bin/ghc '--ghc-options=-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' --package-db=tmp.d --prefix=/home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst --cid q-0.1 q ++ ./Setup -v0 configure --enable-library-vanilla --disable-shared --with- ghc=/home/ben/ghc/ghc-8.8/inplace/bin/ghc-stage2 '--ghc-options=-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' --package- db=tmp.d --prefix=/home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst --cid q-0.1 q +Error: + The following packages are broken because other packages they depend on are missing. These broken packages must be rebuilt before they can be used. +planned package bkpcabal01-0.1.0.0 is broken due to missing package p-0.1+FBOSaiWyMx9DR2UZVI6wQJ -on the commandline: warning: - unrecognised warning flag: -Werror=compat -+ /nix/store/y6vdn971gmxziv4ryqqbaf1iy814i2z1-ghc-build-environment/bin /ghc-pkg dump --package-db tmp.d -name: z-bkpcabal01-z-impl -version: 0.1.0.0 -package-name: bkpcabal01 -lib-name: impl -id: impl-0.1 -key: impl-0.1 -license: BSD-3-Clause -maintainer: ezyang at cs.stanford.edu -author: Edward Z. Yang -abi: a7d521e071cf58b6a6aa186f8681aa41 -exposed-modules: - H I -import-dirs: /home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst/lib/x86_64 -linux-ghc-8.4.3/impl-0.1 -library-dirs: /home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst/lib/x86_64 -linux-ghc-8.4.3/impl-0.1 -dynamic-library-dirs: /home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst/lib/x86_64 -linux-ghc-8.4.3 -data-dir: /home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst/share/x86_64 -linux-ghc-8.4.3/impl-0.1 -hs-libraries: HSimpl-0.1 -depends: - base-4.11.1.0 -abi-depends: base-4.11.1.0=9da3f387598d41928f3ebf8097acf9b3 -haddock-interfaces: /home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst/share/doc/x86_64 -linux-ghc-8.4.3/impl-0.1/html/bkpcabal01.haddock -haddock-html: /home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst/share/doc/x86_64 -linux-ghc-8.4.3/impl-0.1/html ++ /home/ben/ghc/ghc-8.8/inplace/bin/ghc-pkg dump --package-db tmp.d +name: z-bkpcabal01-z-impl +version: 0.1.0.0 +package-name: bkpcabal01 +lib-name: impl +id: impl-0.1 +key: impl-0.1 +license: BSD-3-Clause +maintainer: ezyang at cs.stanford.edu +author: Edward Z. Yang +abi: 60c029e13f182ee101522cce908d8781 +exposed-modules: H I +import-dirs: + /home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst/lib/x86_64 -linux-ghc-8.7.20190305/impl-0.1 +library-dirs: + /home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst/lib/x86_64 -linux-ghc-8.7.20190305/impl-0.1 +dynamic-library-dirs: + /home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst/lib/x86_64 -linux-ghc-8.7.20190305 +data-dir: + /home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst/share/x86_64 -linux-ghc-8.7.20190305/impl-0.1 +hs-libraries: HSimpl-0.1 +depends: base-4.12.0.0 +haddock-interfaces: + /home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst/share/doc/x86_64 -linux-ghc-8.7.20190305/impl-0.1/html/bkpcabal01.haddock +haddock-html: + /home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst/share/doc/x86_64 -linux-ghc-8.7.20190305/impl-0.1/html pkgroot: "/mnt/work/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01" --- -name: z-bkpcabal01-z-p -version: 0.1.0.0 -package-name: bkpcabal01 -lib-name: p -id: p-0.1 -instantiated-with: H= -key: p-0.1 -license: BSD-3-Clause -maintainer: ezyang at cs.stanford.edu -author: Edward Z. Yang -abi: 7f90760373fbe773631ab356be622147 -indefinite: True -exposed-modules: - P -import-dirs: /home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst/lib/x86_64 -linux-ghc-8.4.3/p-0.1 -data-dir: /home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst/share/x86_64 -linux-ghc-8.4.3/p-0.1 -depends: - base-4.11.1.0 -abi-depends: base-4.11.1.0=9da3f387598d41928f3ebf8097acf9b3 -haddock-interfaces: /home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst/share/doc/x86_64 -linux-ghc-8.4.3/p-0.1/html/bkpcabal01.haddock -haddock-html: /home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst/share/doc/x86_64 -linux-ghc-8.4.3/p-0.1/html +name: z-bkpcabal01-z-p +version: 0.1.0.0 +package-name: bkpcabal01 +lib-name: p +id: p-0.1 +instantiated-with: H= +key: p-0.1 +license: BSD-3-Clause +maintainer: ezyang at cs.stanford.edu +author: Edward Z. Yang +abi: 7fb495b5fcc553191970ae3cce6444ea +indefinite: True +exposed-modules: P +import-dirs: + /home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst/lib/x86_64 -linux-ghc-8.7.20190305/p-0.1 +data-dir: + /home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst/share/x86_64 -linux-ghc-8.7.20190305/p-0.1 +depends: base-4.12.0.0 +haddock-interfaces: + /home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst/share/doc/x86_64 -linux-ghc-8.7.20190305/p-0.1/html/bkpcabal01.haddock +haddock-html: + /home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst/share/doc/x86_64 -linux-ghc-8.7.20190305/p-0.1/html pkgroot: "/mnt/work/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01" }}} This was generated using the following script: {{{#!bash #!/usr/bin/env bash set -x TEST_HC=$(which $TEST_HC) GHC_PKG=$(dirname $TEST_HC)/ghc-pkg rm -R tmp.d $GHC_PKG init tmp.d $TEST_HC -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 -v0 --make Setup cp p/P.hs.in1 p/P.hs cp q/Q.hs.in1 q/Q.hs # typecheck p ./Setup -v0 configure --enable-library-vanilla --disable-shared --with- ghc=$TEST_HC --ghc-options='-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' --package-db=tmp.d --prefix='/home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst' --cid "p-0.1" p ./Setup -v0 build ./Setup -v0 copy ./Setup -v0 register # build impl ./Setup -v0 configure --enable-library-vanilla --disable-shared --with- ghc=$TEST_HC --ghc-options='-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' --package-db=tmp.d --prefix='/home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst' --cid "impl-0.1" impl ./Setup -v0 build ./Setup -v0 copy ./Setup -v0 register # typecheck q ./Setup -v0 configure --enable-library-vanilla --disable-shared --with- ghc=$TEST_HC --ghc-options='-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' --package-db=tmp.d --prefix='/home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst' --cid "q-0.1" q $GHC_PKG dump --package-db tmp.d }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 04:18:41 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 04:18:41 -0000 Subject: [GHC] #16378: bkpcabal01 fails with recent Cabal In-Reply-To: <046.6dbe508947082fe98f8d1db57ed7604b@haskell.org> References: <046.6dbe508947082fe98f8d1db57ed7604b@haskell.org> Message-ID: <061.fde855be1a7cddd6cd54ad99ccb7ce3b@haskell.org> #16378: bkpcabal01 fails with recent Cabal -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new 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: | -------------------------------------+------------------------------------- Comment (by bgamari): Adding `-v2` to the failing `Setup configure` invocation reveals these differences: {{{#!patch --- good 2019-03-05 04:17:02.545005732 +0000 +++ bad 2019-03-05 04:17:23.240399325 +0000 @@ -1,39 +1,38 @@ . . . -+ ./Setup -v2 configure --enable-library-vanilla --disable-shared --with- ghc=/nix/store/y6vdn971gmxziv4ryqqbaf1iy814i2z1-ghc-build- environment/bin/ghc '--ghc-options=-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' --package-db=tmp.d --prefix=/home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst --cid q-0.1 q ++ ./Setup -v2 configure --enable-library-vanilla --disable-shared --with- ghc=/home/ben/ghc/ghc-8.8/inplace/bin/ghc-stage2 '--ghc-options=-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' --package- db=tmp.d --prefix=/home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst --cid q-0.1 q Using Parsec parser Configuring library 'q' for bkpcabal01-0.1.0.0.. -Dependency base -any: using base-4.11.1.0 +Dependency base -any: using base-4.12.0.0 Dependency impl -any: using bkpcabal01-0.1.0.0 Dependency p -any: using bkpcabal01-0.1.0.0 - -on the commandline: warning: - unrecognised warning flag: -Werror=compat Source component graph: component lib:q - dependency lib:p dependency lib:impl + dependency lib:p Configured component graph: component q-0.1 include impl-0.1 (H) + include base-4.12.0.0 include p-0.1 - include base-4.11.1.0 Linked component graph: unit q-0.1[I=] include impl-0.1 (H) + include base-4.12.0.0 include p-0.1[H=impl-0.1:H] - include base-4.11.1.0 Q=q-0.1[I=]:Q Ready component graph: indefinite q-0.1 depends impl-0.1 - depends p-0.1 - depends base-4.11.1.0 -Using Cabal-2.2.0.1 compiled by ghc-8.4 -Using compiler: ghc-8.4.3 -Using install prefix: -/home/ben/ghc/ghc-8.8/testsuite/tests/backpack/cabal/bkpcabal01/inst + depends base-4.12.0.0 + depends p-0.1+FBOSaiWyMx9DR2UZVI6wQJ +CallStack (from HasCallStack): + dieNoWrap, called at libraries/Cabal/Cabal/Distribution/Utils/LogProgress.hs:61:9 in Cabal-2.5.0.0:Distribution.Utils.LogProgress +Error: + The following packages are broken because other packages they depend on are missing. These broken packages must be rebuilt before they can be used. +planned package bkpcabal01-0.1.0.0 is broken due to missing package p-0.1+FBOSaiWyMx9DR2UZVI6wQJ + . . . }}} Not particularly illuminating. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 11:02:14 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 11:02:14 -0000 Subject: [GHC] #15918: GHC panic from QuantifiedConstraints(?) In-Reply-To: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> References: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> Message-ID: <066.a7efaa60c7ada7e41d8955b03c409c5a@haskell.org> #15918: GHC panic from QuantifiedConstraints(?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch 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: | https://gitlab.haskell.org/ghc/ghc/merge_requests/489 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/489 Comment: https://gitlab.haskell.org/ghc/ghc/merge_requests/489 follows up on comment:11 by adding a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 11:04:11 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 11:04:11 -0000 Subject: [GHC] #16391: "Quantified type's kind mentions quantified type variable" error with fancy-kinded GADT Message-ID: <050.e07e7af69cce8e666cdbeacaf56a9da6@haskell.org> #16391: "Quantified type's kind mentions quantified type variable" error with fancy-kinded GADT -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 (Type checker) | Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given the following: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} import Data.Kind type Const (a :: Type) (b :: Type) = a }}} GHC happily accepts these definitions: {{{#!hs type family F :: Const Type a where F = Int type TS = (Int :: Const Type a) }}} However, the situation becomes murkier with data types. For some reason, GHC //rejects// this definition: {{{#!hs data T :: Const Type a where MkT :: T }}} {{{ $ /opt/ghc/8.6.3/bin/ghc Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Bug.hs:14:3: error: • Quantified type's kind mentions quantified type variable (skolem escape) type: forall a1. T of kind: Const * a • In the definition of data constructor ‘MkT’ In the data type declaration for ‘T’ | 14 | MkT :: T | ^^^^^^^^ }}} I'm not quite sure how to interpret that error message, but it seems fishy to me. Even fishier is the fact that GHC //accepts// this slight modification of `T`: {{{#!hs data T2 :: Const Type a -> Type where MkT2 :: T2 b }}} Quite mysterious. ----- I briefly looked into where this error message is being thrown from. It turns out if you make this one-line change to GHC: {{{#!diff diff --git a/compiler/typecheck/TcValidity.hs b/compiler/typecheck/TcValidity.hs index 218f539c68..c7925767f9 100644 --- a/compiler/typecheck/TcValidity.hs +++ b/compiler/typecheck/TcValidity.hs @@ -635,7 +635,7 @@ check_type ve@(ValidityEnv{ ve_tidy_env = env, ve_ctxt = ctxt ; check_type (ve{ve_tidy_env = env'}) tau -- Allow foralls to right of arrow - ; checkTcM (not (any (`elemVarSet` tyCoVarsOfType phi_kind) tvs)) + ; checkTcM (not (any (`elemVarSet` exactTyCoVarsOfType phi_kind) tvs)) (forAllEscapeErr env' ty tau_kind) } where }}} Then GHC will accept `T`. Whether this change is the right choice to make, I don't think I'm qualified to say. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 13:13:15 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 13:13:15 -0000 Subject: [GHC] #16392: In ghci, revertCAFs should be executed in the external interpreter when necessary Message-ID: <045.92444231bf9792c99a9e6f96a7aa684c@haskell.org> #16392: In ghci, revertCAFs should be executed in the external interpreter when necessary -------------------------------------+------------------------------------- Reporter: lolotp | 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: -------------------------------------+------------------------------------- I believe this bug was discovered and reported earlier here, https://mail.haskell.org/pipermail/ghc-devs/2018-June/015842.html. I stumbled upon this while tracking down a problem with ghci. To describe the problem, we call revertCAFs whenever we load modules in ghci so that they can be re-evaluated. This however, doesn't work as intended when use with `-fexternal-interpreter` because the CAFs of loaded modules actually live in the external interpreter process instead while `revertCAFs` only work for CAFs in the ghci process. To fix this, we should call revertCAFs in the external interpreter when it's used. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 13:49:39 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 13:49:39 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.dce3d5daad97595c3370e74fe54bb4c6@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: bollu Type: task | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | ApplicativeDo, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13309 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by danidiaz): * cc: danidiaz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 14:42:30 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 14:42:30 -0000 Subject: [GHC] #16376: GHCi HEAD silently accepts ill-kinded visible type applications with :type In-Reply-To: <050.2844026e72998c0da21d307d0ec6cfc6@haskell.org> References: <050.2844026e72998c0da21d307d0ec6cfc6@haskell.org> Message-ID: <065.76e7099431d0061cfe26b689027709a4@haskell.org> #16376: GHCi HEAD silently accepts ill-kinded visible type applications with :type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: GHCi | Version: 8.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Combining this with `-fdefer-type-errors` leads to a panic: {{{ GHCi, version 8.9.20190227: https://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :set -XTypeApplications -fdefer-type-errors λ> f = id @Maybe :2:9: warning: [-Wdeferred-type-errors] • Expecting one more argument to ‘Maybe’ Expected a type, but ‘Maybe’ has kind ‘* -> *’ • In the type ‘Maybe’ In the expression: id @Maybe In an equation for ‘f’: f = id @Maybe ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.9.20190227 for x86_64-unknown-linux): nameModule internal f_a1BS Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1159:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Name.hs:249:3 in ghc:Name }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 14:52:53 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 14:52:53 -0000 Subject: [GHC] #16393: Implement the "Explicit specificity in type variable binders" proposal Message-ID: <050.285680da74569a2533788064c4575173@haskell.org> #16393: Implement the "Explicit specificity in type variable binders" proposal -------------------------------------+------------------------------------- Reporter: harpocrates | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The [https://github.com/ghc-proposals/ghc- proposals/blob/master/proposals/0026-explicit-specificity.rst explicit specificity proposal] (aka proposal 26) was accepted 8 months ago. This ticket is to track its implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 15:17:03 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 15:17:03 -0000 Subject: [GHC] #16291: Document or enable commented-out sanity check in checkStackChunk In-Reply-To: <043.e6a97c4834ec429c76fd9907c1aec308@haskell.org> References: <043.e6a97c4834ec429c76fd9907c1aec308@haskell.org> Message-ID: <058.2c738707f34cd1219a469d60ab56362f@haskell.org> #16291: Document or enable commented-out sanity check in checkStackChunk -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * type: bug => task Old description: > `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. New description: `checkStackChunk` is currently defined like this: {{{#!c 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 Tue Mar 5 15:20:23 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 15:20:23 -0000 Subject: [GHC] #16291: Document or enable commented-out sanity check in checkStackChunk In-Reply-To: <043.e6a97c4834ec429c76fd9907c1aec308@haskell.org> References: <043.e6a97c4834ec429c76fd9907c1aec308@haskell.org> Message-ID: <058.9a39f7970dccf92a428e54a6488ba119@haskell.org> #16291: Document or enable commented-out sanity check in checkStackChunk -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => closed * resolution: => fixed Comment: Fixed with 6b890d76a252259843a6e87043f8f12e6a8a0aae -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 16:36:39 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 16:36:39 -0000 Subject: [GHC] #16387: Duplicate vsnwprintf symbol on Windows In-Reply-To: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> References: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> Message-ID: <061.870858d00c94ce6ee6a4e3729ab173c8@haskell.org> #16387: Duplicate vsnwprintf symbol on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: broken-test 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): `T5452` in `extt-interp` also fails in this way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 16:55:00 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 16:55:00 -0000 Subject: [GHC] #16387: Duplicate vsnwprintf symbol on Windows In-Reply-To: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> References: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> Message-ID: <061.1c0849c975df05d4144f9068e331f2a1@haskell.org> #16387: Duplicate vsnwprintf symbol on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: broken-test 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 Phyx-): I'll need to double check but I believe we always `libmingwex` now? If so we can just remove the built-in symbol or mark it weak. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 17:05:16 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 17:05:16 -0000 Subject: [GHC] #16387: Duplicate vsnwprintf symbol on Windows In-Reply-To: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> References: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> Message-ID: <061.58ddcff8e81192cf63eba4655ffeaadb@haskell.org> #16387: Duplicate vsnwprintf symbol on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: broken-test 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): `T15550` in `ext-interp` as well. Unfortunately I have been unable to reproduce this on my local Windows machine, even after updating msys. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 17:09:03 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 17:09:03 -0000 Subject: [GHC] #16387: Duplicate vsnwprintf symbol on Windows In-Reply-To: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> References: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> Message-ID: <061.17d80bcb7228fd217fd1ba9702b2ded6@haskell.org> #16387: Duplicate vsnwprintf symbol on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: broken-test 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): Replying to [comment:6 Phyx-]: > I'll need to double check but I believe we always `libmingwex` now? If so we can just remove the built-in symbol or mark it weak. Good timing; I just sent you an email about this. :) Indeed it does seem that we link against `mingwex` whenever it is available. However, looking through the history I don't believe this has changed in the recent past. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 17:10:51 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 17:10:51 -0000 Subject: [GHC] #16387: Duplicate vsnwprintf symbol on Windows In-Reply-To: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> References: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> Message-ID: <061.a7b5f6335c6e3362d475a6cb1c285de3@haskell.org> #16387: Duplicate vsnwprintf symbol on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: broken-test 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): Ahh, I might be wrong, actually: See 90538d86af579595987826cd893828d6f379f35a. The RTS has always imported `mingwex` when available (although it looks like the `configure` test may have been buggy at one point). However, as of the above commit we now always link `base` against `mingwex`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 17:15:02 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 17:15:02 -0000 Subject: [GHC] #16387: Duplicate vsnwprintf symbol on Windows In-Reply-To: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> References: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> Message-ID: <061.22068c7bd1d4aa589b8a242d941dfc04@haskell.org> #16387: Duplicate vsnwprintf symbol on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: broken-test 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): Huh, this is extremely perplexing: `T5836` doesn't fail reliably due to this. I cannot imagine how this sort of issue could be non-deterministic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 17:20:50 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 17:20:50 -0000 Subject: [GHC] #16387: Duplicate vsnwprintf symbol on Windows In-Reply-To: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> References: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> Message-ID: <061.d015f31ef7c85e491619ea7254ea39b0@haskell.org> #16387: Duplicate vsnwprintf symbol on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: broken-test 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 Phyx-): Yeah, so what confuses me too is that it's also in the rts's package config. I think the linker log with - Dl would shine a light on it. A dump of one that fails and one that doesn't should show what changed. It should indeed be quite deterministic. What it could be is that it's not print itself causing the inclusion but that there is another symbol in that object file that is sometimes required and other times not. For instance one invocation may be lasting longer than the other, different order in GC? Or in one case a finalizer being called but not the other. But the log would show what demanded the object file be loaded. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 17:34:03 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 17:34:03 -0000 Subject: [GHC] #16387: Duplicate vsnwprintf symbol on Windows In-Reply-To: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> References: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> Message-ID: <061.5124c442d706f12fcb1ebc1c67d4c1d5@haskell.org> #16387: Duplicate vsnwprintf symbol on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: broken-test 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 Phyx-): Ah right. The one in the rts is never used by the runtime linker as it doesn't know its own dependencies. I.e. We never load librts inside ghci. So makes sense why that one isn't getting picked up. I remember adding because of a failing test, but I don't remember which one. But grepping through my local test archives that doesn't seem to ever fail for me. Could you compile that test with a debug rts and dump the linker log? I can try to figure it out then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 17:43:23 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 17:43:23 -0000 Subject: [GHC] #12596: can't find interface-file declaration In-Reply-To: <046.38012533792a227b36238e24bbed4707@haskell.org> References: <046.38012533792a227b36238e24bbed4707@haskell.org> Message-ID: <061.9607f98d2824efc221db7471ab520edb@haskell.org> #12596: can't find interface-file declaration -------------------------------------+------------------------------------- Reporter: mwotton | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): I ran into this when trying to use a derived instance for TH.Lift (for some algebraic data type that used Text somewhere). Some web searching turned up this work-around (use TH.dataToExpQ) https://stackoverflow.com/questions/38143464/cant-find-inerface-file- declaration-for-variable -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 18:00:39 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 18:00:39 -0000 Subject: [GHC] #16387: Duplicate vsnwprintf symbol on Windows In-Reply-To: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> References: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> Message-ID: <061.66b3ed45d4c8fd1611b6ca214fe598de@haskell.org> #16387: Duplicate vsnwprintf symbol on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: broken-test 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 Phyx-): Or if they are reproducible only on the build bots I will put up a Mr to do this. I assume I can get artifacts out of the build? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 18:33:44 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 18:33:44 -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.573d221868b9d983bc3258d7f9151a6f@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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): To confirm my hunch that even generating code with bracket syntax would still be fragile, I tried compiling GHC 8.4.4 with 8.2.2 as the bootstrapping compiler again, but instead of attempting to derive a `Lift` instance for `Role`, I defined one manually using bracket syntax: {{{#!hs instance Lift Role where lift NominalR = [| NominalR |] ... }}} Alas, that also suffers from the same issues observed in comment:7: {{{ libraries/template-haskell/Language/Haskell/TH/Syntax.hs:2005:28: error: • Failed to load interface for ‘Language.Haskell.TH.Lib’ Use -v to see a list of the files searched for. • In the expression: [| NominalR |] In an equation for ‘lift’: lift NominalR = [| NominalR |] In the instance declaration for ‘Lift Role’ | 2005 | lift NominalR = [| NominalR |] | ^^^^^^^^^^^^^^ }}} This all seems horribly delicate. There has to be a way to ensure that subsequent changes to `template-haskell` won't break the build in similar ways, but I can't think of how to orchestrate this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 18:55:12 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 18:55:12 -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.2142ce438e0c8b20c901b354e8f83c7c@haskell.org> #16208: map/coerce does not fire with all newtypes -------------------------------------+------------------------------------- Reporter: monoidal | 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: | simplCore/should_run/T16208 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/453 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => simplCore/should_run/T16208 * resolution: => fixed * milestone: => 8.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 18:57:53 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 18:57:53 -0000 Subject: [GHC] #16251: T5515 broken in devel2 flavour In-Reply-To: <046.ba26575c5471a49d616aae74eb31e3bc@haskell.org> References: <046.ba26575c5471a49d616aae74eb31e3bc@haskell.org> Message-ID: <061.aa3ba6b4ebd5c1b6eef8478f9e41b1c4@haskell.org> #16251: T5515 broken in devel2 flavour -------------------------------------+------------------------------------- Reporter: bgamari | 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: indexed- | types/should_fail/T5515 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/444 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => indexed-types/should_fail/T5515 * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/444 * resolution: => fixed * milestone: => 8.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 18:58:40 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 18:58:40 -0000 Subject: [GHC] #16251: T5515 broken in devel2 flavour In-Reply-To: <046.ba26575c5471a49d616aae74eb31e3bc@haskell.org> References: <046.ba26575c5471a49d616aae74eb31e3bc@haskell.org> Message-ID: <061.4537ccbef379e33eaf61c78924ec7e17@haskell.org> #16251: T5515 broken in devel2 flavour -------------------------------------+------------------------------------- Reporter: bgamari | 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: indexed- | types/should_fail/T5515 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/444 -------------------------------------+------------------------------------- Comment (by RyanGlScott): Landed in [https://gitlab.haskell.org/ghc/ghc/commit/80dfcee61e3bfb67f131cd674f96467e16c0f9d8 80dfcee6]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 18:59:19 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 18:59:19 -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.1880637de534ab1fb061cd202c4fd3f4@haskell.org> #16208: map/coerce does not fire with all newtypes -------------------------------------+------------------------------------- Reporter: monoidal | 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: | simplCore/should_run/T16208 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/453 -------------------------------------+------------------------------------- Comment (by RyanGlScott): Landed in [https://gitlab.haskell.org/ghc/ghc/commit/646b6dfbe125aa756a935e840979ba11b4a882c0 646b6dfb]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 19:00:49 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 19:00:49 -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.50d3cf9a6ff9e5726e3f300318e14142@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: #16342 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/444 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/444 * related: => #16342 Comment: This was allegedly fixed in [https://gitlab.haskell.org/ghc/ghc/commit/80dfcee61e3bfb67f131cd674f96467e16c0f9d8 80dfcee6], although a test case has yet to materialize. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 19:01:15 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 19:01:15 -0000 Subject: [GHC] #16342: Kind inference crash In-Reply-To: <046.eae912a23f2090497b4d3634101a1dd3@haskell.org> References: <046.eae912a23f2090497b4d3634101a1dd3@haskell.org> Message-ID: <061.5a2dd7c1d17f330555893b94995ea396@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: #16221 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/444 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/444 * related: => #16221 Comment: This was allegedly fixed in [https://gitlab.haskell.org/ghc/ghc/commit/80dfcee61e3bfb67f131cd674f96467e16c0f9d8 80dfcee6], although a test case has yet to materialize. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 21:43:18 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 21:43:18 -0000 Subject: [GHC] #16251: T5515 broken in devel2 flavour In-Reply-To: <046.ba26575c5471a49d616aae74eb31e3bc@haskell.org> References: <046.ba26575c5471a49d616aae74eb31e3bc@haskell.org> Message-ID: <061.adda90cd53ec50d6961725bbbc37d5a6@haskell.org> #16251: T5515 broken in devel2 flavour -------------------------------------+------------------------------------- Reporter: bgamari | 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: indexed- | types/should_fail/T5515 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/444 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"80dfcee61e3bfb67f131cd674f96467e16c0f9d8/ghc" 80dfcee6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="80dfcee61e3bfb67f131cd674f96467e16c0f9d8" Be more careful when naming TyCon binders This patch fixes two rather gnarly test cases: * Trac #16342 (mutual recursion) See Note [Tricky scoping in generaliseTcTyCon] * Trac #16221 (shadowing) See Note [Unification variables need fresh Names] The main changes are: * Substantial reworking of TcTyClsDecls.generaliseTcTyCon This is the big change, and involves the rather tricky function TcHsSyn.zonkRecTyVarBndrs. See Note [Inferring kinds for type declarations] and Note [Tricky scoping in generaliseTcTyCon] for the details. * bindExplicitTKBndrs_Tv and bindImplicitTKBndrs_Tv both now allocate /freshly-named/ unification variables. Indeed, more generally, unification variables are always fresh; see Note [Unification variables need fresh Names] in TcMType * Clarify the role of tcTyConScopedTyVars. See Note [Scoped tyvars in a TcTyCon] in TyCon As usual, this dragged in some more refactoring: * Renamed TcMType.zonkTyCoVarBndr to zonkAndSkolemise * I renamed checkValidTelescope to checkTyConTelescope; it's only used on TyCons, and indeed takes a TyCon as argument. * I folded the slightly-mysterious reportFloatingKvs into checkTyConTelescope. (Previously all its calls immediately followed a call to checkTyConTelescope.) It makes much more sense there. * I inlined some called-once functions to simplify checkValidTyFamEqn. It's less spaghetti-like now. * This patch also fixes Trac #16251. I'm not quite sure why #16251 went wrong in the first place, nor how this patch fixes it, but hey, it's good, and life is short. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 21:43:18 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 21:43:18 -0000 Subject: [GHC] #16342: Kind inference crash In-Reply-To: <046.eae912a23f2090497b4d3634101a1dd3@haskell.org> References: <046.eae912a23f2090497b4d3634101a1dd3@haskell.org> Message-ID: <061.a50d5a0c4774e3a9a4302495c14aa5b9@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: #16221 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/444 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"80dfcee61e3bfb67f131cd674f96467e16c0f9d8/ghc" 80dfcee6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="80dfcee61e3bfb67f131cd674f96467e16c0f9d8" Be more careful when naming TyCon binders This patch fixes two rather gnarly test cases: * Trac #16342 (mutual recursion) See Note [Tricky scoping in generaliseTcTyCon] * Trac #16221 (shadowing) See Note [Unification variables need fresh Names] The main changes are: * Substantial reworking of TcTyClsDecls.generaliseTcTyCon This is the big change, and involves the rather tricky function TcHsSyn.zonkRecTyVarBndrs. See Note [Inferring kinds for type declarations] and Note [Tricky scoping in generaliseTcTyCon] for the details. * bindExplicitTKBndrs_Tv and bindImplicitTKBndrs_Tv both now allocate /freshly-named/ unification variables. Indeed, more generally, unification variables are always fresh; see Note [Unification variables need fresh Names] in TcMType * Clarify the role of tcTyConScopedTyVars. See Note [Scoped tyvars in a TcTyCon] in TyCon As usual, this dragged in some more refactoring: * Renamed TcMType.zonkTyCoVarBndr to zonkAndSkolemise * I renamed checkValidTelescope to checkTyConTelescope; it's only used on TyCons, and indeed takes a TyCon as argument. * I folded the slightly-mysterious reportFloatingKvs into checkTyConTelescope. (Previously all its calls immediately followed a call to checkTyConTelescope.) It makes much more sense there. * I inlined some called-once functions to simplify checkValidTyFamEqn. It's less spaghetti-like now. * This patch also fixes Trac #16251. I'm not quite sure why #16251 went wrong in the first place, nor how this patch fixes it, but hey, it's good, and life is short. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 21:43:18 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 21:43:18 -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.fcb04e59d2bb99ae7581b3ccf4dbdb15@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: #16342 | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/444 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"80dfcee61e3bfb67f131cd674f96467e16c0f9d8/ghc" 80dfcee6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="80dfcee61e3bfb67f131cd674f96467e16c0f9d8" Be more careful when naming TyCon binders This patch fixes two rather gnarly test cases: * Trac #16342 (mutual recursion) See Note [Tricky scoping in generaliseTcTyCon] * Trac #16221 (shadowing) See Note [Unification variables need fresh Names] The main changes are: * Substantial reworking of TcTyClsDecls.generaliseTcTyCon This is the big change, and involves the rather tricky function TcHsSyn.zonkRecTyVarBndrs. See Note [Inferring kinds for type declarations] and Note [Tricky scoping in generaliseTcTyCon] for the details. * bindExplicitTKBndrs_Tv and bindImplicitTKBndrs_Tv both now allocate /freshly-named/ unification variables. Indeed, more generally, unification variables are always fresh; see Note [Unification variables need fresh Names] in TcMType * Clarify the role of tcTyConScopedTyVars. See Note [Scoped tyvars in a TcTyCon] in TyCon As usual, this dragged in some more refactoring: * Renamed TcMType.zonkTyCoVarBndr to zonkAndSkolemise * I renamed checkValidTelescope to checkTyConTelescope; it's only used on TyCons, and indeed takes a TyCon as argument. * I folded the slightly-mysterious reportFloatingKvs into checkTyConTelescope. (Previously all its calls immediately followed a call to checkTyConTelescope.) It makes much more sense there. * I inlined some called-once functions to simplify checkValidTyFamEqn. It's less spaghetti-like now. * This patch also fixes Trac #16251. I'm not quite sure why #16251 went wrong in the first place, nor how this patch fixes it, but hey, it's good, and life is short. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 21:43:18 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 21:43:18 -0000 Subject: [GHC] #16359: Test runner warns of missing basline for performance tests with expected changes In-Reply-To: <045.4f071e01d4b88ffb73dd52669a2afd78@haskell.org> References: <045.4f071e01d4b88ffb73dd52669a2afd78@haskell.org> Message-ID: <060.a986bd5942815cfe81542723133f2aae@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 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"6c4e45b043b0577d64e5addf5eaf6503e4a10b23/ghc" 6c4e45b0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6c4e45b043b0577d64e5addf5eaf6503e4a10b23" Test Runner: don't show missing baseline warning for performance tests with expected changes on the current commit. Trac #16359 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 21:43:18 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 21:43:18 -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.a56e05222b9cd5fb3816189b8ad7c458@haskell.org> #16208: map/coerce does not fire with all newtypes -------------------------------------+------------------------------------- Reporter: monoidal | 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: | simplCore/should_run/T16208 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/453 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"646b6dfbe125aa756a935e840979ba11b4a882c0/ghc" 646b6dfb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="646b6dfbe125aa756a935e840979ba11b4a882c0" Fix map/coerce rule for newtypes with wrappers This addresses Trac #16208 by marking newtype wrapper unfoldings as compulsory. Furthermore, we can remove the special case for newtypes in exprIsConApp_maybe (introduced in 7833cf407d1f). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 22:17:18 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 22:17:18 -0000 Subject: [GHC] #16394: GHC internal error while typechecking of instance definition Message-ID: <046.1aa3a5a103e1dd4c8fc51a808f32f1b2@haskell.org> #16394: GHC internal error while typechecking of instance definition -------------------------------------+------------------------------------- Reporter: Day1721 | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.6.3 (Type checker) | Keywords: | Operating System: Linux Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello. \\ This code won't typecheck because of GHC internal error. {{{#!hs {-# LANGUAGE PolyKinds, TypeFamilies, DataKinds #-} class C a where type T (n :: a) -- v--DIFF--v instance C a => C b => C (a, b) where type T '(n, m) = (T n, T m) }}} with error message: {{{ Bug.hs:7:10: error: • GHC internal error: ‘T’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [a1LS :-> Type variable ‘a’ = a :: *, a1LT :-> Type variable ‘b’ = b :: *] • In the type instance declaration for ‘T’ In the instance declaration for ‘C b => C (a, b)’ | 7 | type T (n, m) = (T n, T m) | ^ Failed, no modules loaded. }}} but this works fine: {{{#!hs {-# LANGUAGE PolyKinds, TypeFamilies, DataKinds #-} class C a where type T (n :: a) -- v--DIFF--v instance (C a, C b) => C (a, b) where type T '(n, m) = (T n, T m) }}} Not sure is a bug, but either way it would be better to make more understandable error message -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 22:53:09 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 22:53:09 -0000 Subject: [GHC] #16391: "Quantified type's kind mentions quantified type variable" error with fancy-kinded GADT In-Reply-To: <050.e07e7af69cce8e666cdbeacaf56a9da6@haskell.org> References: <050.e07e7af69cce8e666cdbeacaf56a9da6@haskell.org> Message-ID: <065.e5f76ab2df65efb4c2781250e548013c@haskell.org> #16391: "Quantified type's kind mentions quantified type variable" error with fancy-kinded GADT -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Two things here. First, could you add this note in module `Type` {{{ Note [Phantom type variables in kinds] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Consider type K (r :: RuntimeRep) = Type -- Note 'r' is unused data T r :: K r -- T :: forall r -> K r foo :: forall r. T r The body of the forall in foo's type has kind (K r), and normally it would make no sense to have forall r. (ty :: K r) because the kind of the forall would escape the binding of 'r'. But in this case it's fine because (K r) exapands to Type, so we expliclity /permit/ the type forall r. T r To accommodate such a type, in typeKind (forall a.ty) we use occCheckExpand to expand any type synonyms in the kind of 'ty' to eliminate 'a'. See kinding rule (FORALL) in Note [Kinding rules for types] And in TcValidity.checkEscapingKind, we use also use occCheckExpand, for the same reason. }}} just after `Note [Kinding rules for types]`. And refer to the Note from the calls to `occCheckExpand` in `typeKind` and `tcTypeKind`. Then, in `TcValidity`, perhpas pull that entire check out intoa named function `checkEscapingKind`, and refer again to the same Note. And I think it'd be simpler to use `occCheckExpand` there too. (Your suggestion of `exactTyCoVarsOfType` is equivalent, but using the same function in all three places seems better.) Does that make sense? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 23:00:19 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 23:00:19 -0000 Subject: [GHC] #16391: "Quantified type's kind mentions quantified type variable" error with fancy-kinded GADT In-Reply-To: <050.e07e7af69cce8e666cdbeacaf56a9da6@haskell.org> References: <050.e07e7af69cce8e666cdbeacaf56a9da6@haskell.org> Message-ID: <065.2e3476ac014c75ffb4692e65d72702af@haskell.org> #16391: "Quantified type's kind mentions quantified type variable" error with fancy-kinded GADT -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The other bad thing is that the error message is a mess, becuase it mentions 'a' in one place and 'a1' in the other. Very confusing. Reason: {{{ (forAllEscapeErr env' ty tau_kind) }}} we pass `env'` (the result of tidying tvs) to `forAllEscapeErr`, which then prints `ty` in this tidy-env, thereby tidying the same tyvars again. This would not be hard to clear up, perhpas not by printing `ty` afresh, but by passing `tvs'` and `phi` to `forAllEscapeErr`, and printing the foralls manually, as it were. Does that make sense? Also I wonder if if might be easier to understand if we said {{{ • Quantified type's kind mentions quantified type variable type: forall a1. T where the body of the forall has this kind T :: Const * a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 23:04:05 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 23:04:05 -0000 Subject: [GHC] #16391: "Quantified type's kind mentions quantified type variable" error with fancy-kinded GADT In-Reply-To: <050.e07e7af69cce8e666cdbeacaf56a9da6@haskell.org> References: <050.e07e7af69cce8e666cdbeacaf56a9da6@haskell.org> Message-ID: <065.ac5c62ffc826f92b650066db1be24f41@haskell.org> #16391: "Quantified type's kind mentions quantified type variable" error with fancy-kinded GADT -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): PS: here is a test caes that is rightly rejected by the test in `TcFValidity`. {{{ type family T (r :: RuntimeRep) :: TYPE r foo :: T r foo = foo }}} It'd be good to add a note to `TcValidity` to show this example of how the test does something useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 5 23:08:39 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 05 Mar 2019 23:08:39 -0000 Subject: [GHC] #16394: GHC internal error while typechecking of instance definition In-Reply-To: <046.1aa3a5a103e1dd4c8fc51a808f32f1b2@haskell.org> References: <046.1aa3a5a103e1dd4c8fc51a808f32f1b2@haskell.org> Message-ID: <061.1580c767686e27e51c3d129d78052609@haskell.org> #16394: GHC internal error while typechecking of instance definition -------------------------------------+------------------------------------- Reporter: Day1721 | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: Operating System: Linux | 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): Happily, HEAD gives {{{ T16394.hs:9:10: error: Illegal class instance: `C a => C b => C (a, b)' Class instances must be of the form context => C ty_1 ... ty_n where `C' is a class | 9 | instance C a => C b => C (a, b) where | ^^^^^^^^^^^^^^^^^^^^^^ }}} Would someone like to add a regression test and close this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 00:05:46 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 00:05:46 -0000 Subject: [GHC] #16395: Sort out long tickets Message-ID: <046.56e8dcf2681d65c59443c6f0badfd0ad@haskell.org> #16395: Sort out long tickets -------------------------------------+------------------------------------- Reporter: bgamari | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | 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: -------------------------------------+------------------------------------- Two tickets, #1436 and #2074, are quite long and therefore fail the GitLab import. Fixing this will require some manual spelunking in the Trac database. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 00:10:20 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 00:10:20 -0000 Subject: [GHC] #16396: TH doesn't preserve `forall` Message-ID: <047.790f0e5a210fad12f366755de54095d0@haskell.org> #16396: TH doesn't preserve `forall` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new 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: -------------------------------------+------------------------------------- I think there are several bugs in the way TH currently deals with type variable quantification. **Background** GHC uses the "forall-or-nothing" rule. This means that, if there is a top- level `forall` in a type signature, that `forall` must bind ''all'' variables being brought into scope in that signature. Examples: {{{#!hs f1 :: a -> a f1 x = x -- OK, no forall f2 :: forall . a -> a f2 x = x -- rejected f3 :: forall a. a -> a f3 x = x -- OK, forall binds all variables f4 :: forall a. a -> a f4 x = helper x where helper :: a -> a -- OK; this uses a already in scope helper _ = x f5 :: forall a. a -> a f5 x = helper x where helper :: forall . a -> a -- OK; a is already in scope helper _ = x f6 :: forall a. a -> a f6 x = helper x where helper :: forall a. a -> a -- this is a new variable `a` helper _ = x -- rejected; the two `a`s are different }}} Upshot: the existence of `forall` matters. **Strangeness 1** {{{#!hs foo1 :: $([t| a -> a |]) foo1 x = x }}} is rejected, because `a` is not in scope. This is incongruent with the treatment of `f1`. One could argue, though, that all type variables used in quotes should be in scope. I would disagree with such an argument (that's not what we do these days in terms), but it's not silly. **Strangeness 2** {{{#!hs foo2 :: $([t| $(varT (mkName "a")) -> $(varT (mkName "a")) |]) foo2 x = x }}} is rejected because `a` is not in scope. This behavior seems just wrong. **Strangeness 3** {{{#!hs foo3 :: $([t| forall . $(varT (mkName "a")) -> $(varT (mkName "a")) |]) foo3 x = x }}} is rejected in the same way as `foo2`. While this ''should'' be rejected (it's `f2`), `-ddump-splices` says that the splice evaluates to `a -> a`; note: no `forall`. So it's rejected under false pretenses. **Strangeness 4** {{{#!hs foo4 :: $([t| forall a . $(varT (mkName "a")) -> $(varT (mkName "a")) |]) foo4 x = x }}} This one is accepted (as it should be), but it produces a warning! {{{ Scratch.hs:51:21: warning: [-Wunused-foralls] Unused quantified type variable ‘a’ In the type ‘forall a. $(varT (mkName "a")) -> $(varT (mkName "a"))’ | 51 | foo :: $([t| forall a . $(varT (mkName "a")) -> $(varT (mkName "a")) |]) | }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 00:21:58 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 00:21:58 -0000 Subject: [GHC] #16084: Improve link times on Windows In-Reply-To: <046.0ada86ea9a76f7a78e8437f0c6bc9eae@haskell.org> References: <046.0ada86ea9a76f7a78e8437f0c6bc9eae@haskell.org> Message-ID: <061.98571f5576afba7eba9caa17db6a88fa@haskell.org> #16084: Improve link times on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: upstream Priority: high | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have pushed a new branch testing a new `binutils` build provided by Tamar to `wip/fix-windows-ci` (see !495). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 00:40:30 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 00:40:30 -0000 Subject: [GHC] #2074: build of ghc-6.8.2 with extras failed In-Reply-To: <041.b1ea0f1c2d41a058090fb96d5ed514ac@haskell.org> References: <041.b1ea0f1c2d41a058090fb96d5ed514ac@haskell.org> Message-ID: <056.b2e401bb53b68251c7ae4c4d58ff10ef@haskell.org> #2074: build of ghc-6.8.2 with extras failed ---------------------------------+---------------------------------------- Reporter: sk | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.2 Resolution: fixed | Keywords: strange closure type 15 Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: ---------------------------------+---------------------------------------- Changes (by bgamari): * Attachment "build.log.gz" added. Complete build log -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 00:43:07 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 00:43:07 -0000 Subject: [GHC] #1436: Build errors: awkward "no rule to make target" errors where there ARE rules In-Reply-To: <044.5a3e1c2172ae5a465f387c111e517c59@haskell.org> References: <044.5a3e1c2172ae5a465f387c111e517c59@haskell.org> Message-ID: <059.88aefc8c2e649df2237704054567abd5@haskell.org> #1436: Build errors: awkward "no rule to make target" errors where there ARE rules ----------------------------------------+------------------------------ Reporter: guest | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Build System (make) | Version: 6.6.1 Resolution: worksforme | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Changes (by bgamari): * Attachment "build.log.gz" added. Complete build log -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 00:52:01 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 00:52:01 -0000 Subject: [GHC] #16395: Sort out long tickets In-Reply-To: <046.56e8dcf2681d65c59443c6f0badfd0ad@haskell.org> References: <046.56e8dcf2681d65c59443c6f0badfd0ad@haskell.org> Message-ID: <061.765a691f806cffcd75ac9c1cc6b79ab4@haskell.org> #16395: Sort out long tickets -------------------------------------+------------------------------------- Reporter: bgamari | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | 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 bgamari): In both cases I have updated removed the long content from the description and moved it to an attachment. Dropping the relevant rows from the `ticket_change` table should allow the export to proceed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 01:34:54 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 01:34:54 -0000 Subject: [GHC] #16394: GHC internal error while typechecking of instance definition In-Reply-To: <046.1aa3a5a103e1dd4c8fc51a808f32f1b2@haskell.org> References: <046.1aa3a5a103e1dd4c8fc51a808f32f1b2@haskell.org> Message-ID: <061.86057257dec474c45705340e29f83bd0@haskell.org> #16394: GHC internal error while typechecking of instance definition -------------------------------------+------------------------------------- Reporter: Day1721 | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: fixed | Keywords: Operating System: Linux | 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 bgamari): * status: new => closed * resolution: => fixed Comment: Done in !496. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 01:35:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 01:35:08 -0000 Subject: [GHC] #16394: GHC internal error while typechecking of instance definition In-Reply-To: <046.1aa3a5a103e1dd4c8fc51a808f32f1b2@haskell.org> References: <046.1aa3a5a103e1dd4c8fc51a808f32f1b2@haskell.org> Message-ID: <061.8e0cc0cca3a1706696f98ab0b978237d@haskell.org> #16394: GHC internal error while typechecking of instance definition -------------------------------------+------------------------------------- Reporter: Day1721 | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: fixed | Keywords: Operating System: Linux | 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 bgamari): * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 01:44:30 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 01:44:30 -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.f8f1510c43437d559bde161d0c403cc7@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 bgamari): Is this now fixed, davide? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 02:05:41 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 02:05:41 -0000 Subject: [GHC] #16392: In ghci, revertCAFs should be executed in the external interpreter when necessary In-Reply-To: <045.92444231bf9792c99a9e6f96a7aa684c@haskell.org> References: <045.92444231bf9792c99a9e6f96a7aa684c@haskell.org> Message-ID: <060.e6e3af32c928f5530a982c900f8030cd@haskell.org> #16392: In ghci, revertCAFs should be executed in the external interpreter when necessary -------------------------------------+------------------------------------- Reporter: lolotp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => newcomer Comment: Good catch! Care to offer a patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 02:09:29 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 02:09:29 -0000 Subject: [GHC] #16113: T14740 fails in debugged compiler In-Reply-To: <046.c9b4ae7f3e4977e264b15bebaf299066@haskell.org> References: <046.c9b4ae7f3e4977e264b15bebaf299066@haskell.org> Message-ID: <061.b6d288235a42bc65adb2e33efcf8d696@haskell.org> #16113: T14740 fails in debugged compiler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: high | 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: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 06:34:34 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 06:34:34 -0000 Subject: [GHC] #16392: In ghci, revertCAFs should be executed in the external interpreter when necessary In-Reply-To: <045.92444231bf9792c99a9e6f96a7aa684c@haskell.org> References: <045.92444231bf9792c99a9e6f96a7aa684c@haskell.org> Message-ID: <060.0f9e2fb326d4b48ab313fe2639675686@haskell.org> #16392: In ghci, revertCAFs should be executed in the external interpreter when necessary -------------------------------------+------------------------------------- Reporter: lolotp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 06:40:22 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 06:40:22 -0000 Subject: [GHC] #16392: In ghci, revertCAFs should be executed in the external interpreter when necessary In-Reply-To: <045.92444231bf9792c99a9e6f96a7aa684c@haskell.org> References: <045.92444231bf9792c99a9e6f96a7aa684c@haskell.org> Message-ID: <060.cea7591ad408fcdaa42b1d3b8b438b97@haskell.org> #16392: In ghci, revertCAFs should be executed in the external interpreter when necessary -------------------------------------+------------------------------------- Reporter: lolotp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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 lolotp): @osa1, I’m working on a patch at the moment, it should hopefully be ready soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 10:12:53 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 10:12:53 -0000 Subject: [GHC] #16397: --no-colour doesn't seem to do anything. Message-ID: <045.788e961a8aac47720720b6d8d2b3d420@haskell.org> #16397: --no-colour doesn't seem to do anything. -------------------------------------+------------------------------------- Reporter: phadej | 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: -------------------------------------+------------------------------------- I still get purple colored output. {{{ | Run Ghc CompileHs Stage0: compiler/hsSyn/HsInstances.hs => _build/stage0/compiler/build/HsInstances.o }}} README mentions `--progress-colour=MODE`, but also having `--colour`/ `--no-colour` is confusing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 10:36:32 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 10:36:32 -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.cd302b06bcc585e8199fac872259b215@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 simonpj): > I agree that comment:2 was addressed, but what about comment:1? It seems to me that this was not addressed and was the original reason for leaving the ticket open. Yes, you are right. * I'd like to get rid of `Note [Beta redexes]` in Core Lint. * The change to `simpleOptPgm` makes that more feasible. * But we do worker/wrapper join points, and currently w/w generates exactly these kind of beta redexes (contrary, I think, to the claim that it was only `simpleOptPgm`) I'm not sure it matters all that much, but yes we should leave the ticket open -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 10:40:47 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 10:40:47 -0000 Subject: [GHC] #15918: GHC panic from QuantifiedConstraints(?) In-Reply-To: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> References: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> Message-ID: <066.275bf4698ba76ccad6a446f1820df3e7@haskell.org> #15918: GHC panic from QuantifiedConstraints(?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T15918 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/489 -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => quantified-constraints/T15918 * status: patch => closed * resolution: => fixed Comment: Regression test landed in https://gitlab.haskell.org/ghc/ghc/commit/db039a4a10fc8fa9e03e6781d1c0dc33151beda6 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 10:42:18 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 10:42:18 -0000 Subject: [GHC] #15918: GHC panic from QuantifiedConstraints(?) In-Reply-To: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> References: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> Message-ID: <066.bc56fab3b7681290ad8df5a8a6e6d8c0@haskell.org> #15918: GHC panic from QuantifiedConstraints(?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: fixed | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T15918 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/489 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: => 8.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 10:46:09 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 10:46:09 -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.e7e9c7c86d3750647bcabcb165b6f7f2@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 monoidal): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 10:48:38 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 10:48:38 -0000 Subject: [GHC] #15918: GHC panic from QuantifiedConstraints(?) In-Reply-To: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> References: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> Message-ID: <066.eec678f7c6928a05ada91012c4e88cc4@haskell.org> #15918: GHC panic from QuantifiedConstraints(?) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.2 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: quantified- | constraints/T15918 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/489 -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: fixed => Comment: Actually on second thoughts I cannot recall our Plan for `mkCastTy`, so I'm not sure this problem is truly fixed. Maybe it's just harder to trigger now! Let's see what Richard remembers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 11:19:57 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 11:19:57 -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.a18f8513077d1f6c4087dd876e5dcba1@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 #16263 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #13780, #15872 => #13780, #15872, #16263 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 11:20:07 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 11:20:07 -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.a45c6c95664fbcc96c8cd55ac86dfa9f@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 #16263 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #12102, #13933 => #12102, #13933, #16263 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 11:22:12 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 11:22:12 -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.64487c0390eda57c6f37b287589f8b64@haskell.org> #16221: Core Lint error with a data type -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.1 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: #16342 | Differential Rev(s): | https://gitlab.haskell.org/ghc/ghc/merge_requests/444, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/499 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: https://gitlab.haskell.org/ghc/ghc/merge_requests/444 => https://gitlab.haskell.org/ghc/ghc/merge_requests/444, https://gitlab.haskell.org/ghc/ghc/merge_requests/499 * milestone: => 8.10.1 Comment: https://gitlab.haskell.org/ghc/ghc/merge_requests/499 adds a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 11:22:37 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 11:22:37 -0000 Subject: [GHC] #16342: Kind inference crash In-Reply-To: <046.eae912a23f2090497b4d3634101a1dd3@haskell.org> References: <046.eae912a23f2090497b4d3634101a1dd3@haskell.org> Message-ID: <061.a3bcfe214deb8d45e8216c7588a2ae95@haskell.org> #16342: Kind inference crash -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.10.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: #16221 | Differential Rev(s): | https://gitlab.haskell.org/ghc/ghc/merge_requests/444, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/499 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: https://gitlab.haskell.org/ghc/ghc/merge_requests/444 => https://gitlab.haskell.org/ghc/ghc/merge_requests/444, https://gitlab.haskell.org/ghc/ghc/merge_requests/499 * milestone: => 8.10.1 Comment: https://gitlab.haskell.org/ghc/ghc/merge_requests/499 adds a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 11:23:16 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 11:23: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.3d4e9d9f0a84a951d6a9d3ab86938d4b@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): | https://gitlab.haskell.org/ghc/ghc/merge_requests/128, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/499 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: https://gitlab.haskell.org/ghc/ghc/merge_requests/128 => https://gitlab.haskell.org/ghc/ghc/merge_requests/128, https://gitlab.haskell.org/ghc/ghc/merge_requests/499 Comment: https://gitlab.haskell.org/ghc/ghc/merge_requests/499 adds a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 11:27:04 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 11:27:04 -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.20dcc367795c6fe0a413a12d46405e98@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 #16263 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ryan, there's now an extensive comment in `Note [Constraints in kinds]` in TyCoRep that describes what is supposed to happen for equality constraints in kinds. In the light of that description, could you spare the time to look into this ticket and #15872 to see what needs doing? I think we may need to look at the user manual too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 11:29:12 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 11:29:12 -0000 Subject: [GHC] #16344: GHC infers over-polymorphic kinds In-Reply-To: <046.ba3f557688069cd52f4109e1cb268f64@haskell.org> References: <046.ba3f557688069cd52f4109e1cb268f64@haskell.org> Message-ID: <061.79c06b541c4eec3730d54e42e00b92ab@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 simonpj): Branch `wip/over-poly-kinds`, [https://gitlab.haskell.org/ghc/ghc/merge_requests/436 MR 436] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 11:33:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 11:33:08 -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.76b4307ed1acd2594b29bd0f051fc079@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 #16263 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I don't think we're on the same page here. This ticket and #15872 demonstrate that constraints in kinds are horribly broken, and that there's no way to profitably use them. I would think that we should fix GHC's treatment of constraints in kinds before we document how they work in the users' manual. Unfortunately, fixing that is far beyond my technical expertise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 11:42:19 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 11:42:19 -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.47cd6a8fc283e8faa9fe371463d21ab7@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 #16263 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Hang on. The Note explains that * equality constraints `(~)` and `(~~)` should be fine; * other constraints like `Eq a` should be illegal; * `(~#)` isn't a constraint at all; see `Note [Types for coercions, predicates, and evidence]` in `TyCoRep` We should both make the user manual reflect this, and fix any bugs (which surely exist). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 11:42:52 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 11:42:52 -0000 Subject: [GHC] #16392: In ghci, revertCAFs should be executed in the external interpreter when necessary In-Reply-To: <045.92444231bf9792c99a9e6f96a7aa684c@haskell.org> References: <045.92444231bf9792c99a9e6f96a7aa684c@haskell.org> Message-ID: <060.b100785b3d2ca6b7253c6d83691f4447@haskell.org> #16392: In ghci, revertCAFs should be executed in the external interpreter when necessary -------------------------------------+------------------------------------- Reporter: lolotp | Owner: lolotp Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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/500 -------------------------------------+------------------------------------- Changes (by lolotp): * owner: (none) => lolotp * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/500 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 11:47:28 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 11:47:28 -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.a314c55cfd9f290552dc2f64e466d392@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 #16263 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:21 simonpj]: > We should both make the user manual reflect this, and fix any bugs (which surely exist). I'm just pointing out that "make the user manual reflect this" and "fix any bugs" are two actions which require very different sets of abilities. I //might// be able to do the former, but definitely not the latter. Given that, perhaps we should wait until someone with the competency to fix the latter comes along, and then we can update the users' manual at the same time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 12:22:01 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 12:22:01 -0000 Subject: [GHC] #16398: Missing documentation in Windows bindist tarball Message-ID: <046.e3cbddb01120834a441e20e73a81ed58@haskell.org> #16398: Missing documentation in Windows bindist tarball -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Documentation | Version: 8.6.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Takenobu noticed the following omissions from the 8.6.4 bindist tarball: > Perhaps you may know, but the following html documents are not included in > the windows tarball [1]: > > * doc/html/index.html > * doc/html/users_guide/index.html > * doc/html/libraries/index.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 12:33:58 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 12:33:58 -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.e3bd3a26d65e2151b95fd2d772fb6405@haskell.org> #15837: Hadrian should build dynamically linked ghc binary -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5385 Wiki Page: | Phab:D5327 Phab:D5423 -------------------------------------+------------------------------------- Changes (by davide): * status: new => closed * resolution: => fixed Comment: For the most part yes. Any further issues can be documented in separate tickets. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 17:14:52 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 17:14:52 -0000 Subject: [GHC] #16397: --no-colour doesn't seem to do anything. In-Reply-To: <045.788e961a8aac47720720b6d8d2b3d420@haskell.org> References: <045.788e961a8aac47720720b6d8d2b3d420@haskell.org> Message-ID: <060.f5adc3d00448fe2d19ee2f468a90dc6c@haskell.org> #16397: --no-colour doesn't seem to do anything. -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: (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 phadej): * version: 8.6.3 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 17:20:18 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 17:20:18 -0000 Subject: [GHC] #16399: Error when running --share Message-ID: <045.90a81f87a69f7cddc31b48993e06ecbb@haskell.org> #16399: Error when running --share -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: (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: -------------------------------------+------------------------------------- On a fresh checkout, db039a4a10fc8fa9e03e6781d1c0dc33151beda6 {{{ # succeeds ./hadrian/build.sh --progress-colour=Never --share=_share -j3 ... # fails ./hadrian/build.sh --progress-colour=Never --share=_share -j3 --build- root=_build-experiment ... # this succeeds ok ./hadrian/build.sh --progress-colour=Never --share=_share -j3 ... Build completed in 6.97s # Trying without share: still fails with the same error ./hadrian/build.sh --progress-colour=Never -j3 --build-root=_build- experiment ... | Run Ghc CompileHs Stage1: libraries/ghc-prim/GHC/Classes.hs => _build- baseline/stage1/libraries/ghc-prim/build/GHC/Classes.p_o Error when running Shake build system: at action, called at src/Rules.hs:35:19 in main:Rules at need, called at src/Rules.hs:52:5 in main:Rules * Depends on: _build-baseline/stage1/bin/ghc-pkg at need, called at src/Utilities.hs:71:18 in main:Utilities * Depends on: _build-baseline/stage1/libraries/integer-gmp/build /libHSinteger-gmp-1.0.2.0-ghc8.9.20190306.so at need, called at src/Rules/Gmp.hs:14:5 in main:Rules.Gmp * Depends on: _build-baseline/stage1/gmp/include/ghc-gmp.h at need, called at src/Development/Shake/Internal/Derived.hs:118:15 in shake-0.17.6-ef5d6f7a92b6a347b5077f2591e0d47990d974d264275e5e4048829d4b393706:Development.Shake.Internal.Derived * Depends on: _build-baseline/stage1/libraries/integer-gmp/build/config.mk at error, called at src/Development/Shake/Internal/Rules/File.hs:180:58 in shake-0.17.6-ef5d6f7a92b6a347b5077f2591e0d47990d974d264275e5e4048829d4b393706:Development.Shake.Internal.Rules.File * Raised the exception: Error, file does not exist and no rule available: _build-baseline/stage1/libraries/integer-gmp/build/config.mk }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 17:21:33 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 17:21:33 -0000 Subject: [GHC] #16399: Error when running --share In-Reply-To: <045.90a81f87a69f7cddc31b48993e06ecbb@haskell.org> References: <045.90a81f87a69f7cddc31b48993e06ecbb@haskell.org> Message-ID: <060.d608086070e3a01832f1e394f567ec9f@haskell.org> #16399: Error when running --share -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: (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): * cc: snowleopard, alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 19:05:09 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 19:05:09 -0000 Subject: [GHC] #16400: Hadrian: support shake's --lint-fsatrace feature Message-ID: <045.61d70d6489542a352df44f69f69713ec@haskell.org> #16400: Hadrian: support shake's --lint-fsatrace feature -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: lint shake | Operating System: Unknown/Multiple hadrian fsatrace | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Shake's `--lint-fsatrace` feature uses [https://github.com/jacereda/fsatrace fsatrace] to track file accesses of external commands. This allows for more accurate dependency linting which is important e.g. for caching. Hadrian already accepts the `--lint-fsatrace` command line option (it is passed on to shake automatically), but it currently has no effect. The shake options are not set correctly (In particular [https://github.com/jacereda/fsatrace shakeLintInside] must be set). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 19:08:08 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 19:08:08 -0000 Subject: [GHC] #16400: Hadrian: support shake's --lint-fsatrace feature In-Reply-To: <045.61d70d6489542a352df44f69f69713ec@haskell.org> References: <045.61d70d6489542a352df44f69f69713ec@haskell.org> Message-ID: <060.cf10bf510f090e35b9646d73e8695183@haskell.org> #16400: Hadrian: support shake's --lint-fsatrace feature -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: lint shake Resolution: | hadrian fsatrace Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by davide): * owner: (none) => davide -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 19:19:35 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 19:19:35 -0000 Subject: [GHC] #16387: Duplicate vsnwprintf symbol on Windows In-Reply-To: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> References: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> Message-ID: <061.d0e5cde1bee6c60ceaf74cc4e46387ea@haskell.org> #16387: Duplicate vsnwprintf symbol on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: broken-test 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): So far I have only seen this on CI.tgit -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 19:45:04 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 19:45:04 -0000 Subject: [GHC] #16391: "Quantified type's kind mentions quantified type variable" error with fancy-kinded GADT In-Reply-To: <050.e07e7af69cce8e666cdbeacaf56a9da6@haskell.org> References: <050.e07e7af69cce8e666cdbeacaf56a9da6@haskell.org> Message-ID: <065.5d0ecad375b36a98b4e18420d4d7d3e5@haskell.org> #16391: "Quantified type's kind mentions quantified type variable" error with fancy-kinded GADT -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/503 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/503 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 20:21:23 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 20:21:23 -0000 Subject: [GHC] #16365: Inconsistency in quantified constraint solving In-Reply-To: <050.a379a836df5c0074c7f647d7d8a8a117@haskell.org> References: <050.a379a836df5c0074c7f647d7d8a8a117@haskell.org> Message-ID: <065.4b6607bee62439c71468fcea996c73c6@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 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Note that this is quite annoying in practice for the `singletons` library, as the existence of this bug prevents it from using `deriving` to generate its `Show` instances, instead forcing it to laboriously generate `Show` instances with Template Haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 20:28:33 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 20:28:33 -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.15d72d7cf681229d357b1dfa53854808@haskell.org> #12509: ghci -XSafe fails in an inscrutable way -------------------------------------+------------------------------------- Reporter: int-e | Owner: RolandSenn Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | 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): * status: patch => closed * resolution: => fixed Comment: [https://ghc.haskell.org/trac/ghc/ticket/12509#comment:13 Obviously] patch [https://gitlab.haskell.org/ghc/ghc/merge_requests/241 !241] got merged by Marge Bot! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 21:11:11 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 21:11:11 -0000 Subject: [GHC] #16365: Inconsistency in quantified constraint solving In-Reply-To: <050.a379a836df5c0074c7f647d7d8a8a117@haskell.org> References: <050.a379a836df5c0074c7f647d7d8a8a117@haskell.org> Message-ID: <065.d2cd1651192f9bf65bc6b946292ce292@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 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): It does look to me that GHC should do what Ryan asks... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 21:31:32 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 21:31:32 -0000 Subject: [GHC] #15918: mkCastTy sometimes drops insoluble (Type ~ Constraint) coercions (was: GHC panic from QuantifiedConstraints(?)) In-Reply-To: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> References: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> Message-ID: <066.b7b095a0364e0a3d2e6e7114f01e77c4@haskell.org> #15918: mkCastTy sometimes drops insoluble (Type ~ Constraint) coercions -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | 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: quantified- | constraints/T15918 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/489 -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: QuantifiedConstraints => * milestone: 8.10.1 => ⊥ Old description: > Minimized from > https://gist.github.com/Icelandjack/683bd4b79027695ffc31632645c9d58b, I > don't expect `Build []` to kind check but ti shouldn't crash. > > {{{#!hs > {-# Language PolyKinds #-} > {-# Language TypeFamilies #-} > {-# Language ConstraintKinds #-} > {-# Language FlexibleContexts #-} > {-# Language QuantifiedConstraints #-} > {-# Language UndecidableInstances #-} > > import Data.Kind > > class Rev f where > rev :: f a > > instance (forall xx. cls xx => Rev xx) => Rev (Build cls) where > rev = undefined > > data Build :: ((k -> Type) -> Constraint) -> (k -> Type) > > uu = rev :: Build [] a > }}} > > gives a panic > > {{{ > $ ./ghc-stage2 --interactive -ignore-dot-ghci ~/hs/711_bug.hs > GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( ~/hs/711_bug.hs, interpreted ) > ghc-stage2: panic! (the 'impossible' happened) > (GHC version 8.7.20181029 for x86_64-unknown-linux): > ASSERT failed! > irred_a1zW :: [(xx_a1zV[sk:3] |> Sym {co_a1zu})] > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in > ghc:Outputable > pprPanic, called at compiler/utils/Outputable.hs:1219:5 in > ghc:Outputable > assertPprPanic, called at compiler/typecheck/TcType.hs:1826:53 in > ghc:TcType > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > > > }}} New description: EDIT: See comment:3 for the real cause and comment:17 for the current plan. --------------------------- Minimized from https://gist.github.com/Icelandjack/683bd4b79027695ffc31632645c9d58b, I don't expect `Build []` to kind check but ti shouldn't crash. {{{#!hs {-# Language PolyKinds #-} {-# Language TypeFamilies #-} {-# Language ConstraintKinds #-} {-# Language FlexibleContexts #-} {-# Language QuantifiedConstraints #-} {-# Language UndecidableInstances #-} import Data.Kind class Rev f where rev :: f a instance (forall xx. cls xx => Rev xx) => Rev (Build cls) where rev = undefined data Build :: ((k -> Type) -> Constraint) -> (k -> Type) uu = rev :: Build [] a }}} gives a panic {{{ $ ./ghc-stage2 --interactive -ignore-dot-ghci ~/hs/711_bug.hs GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( ~/hs/711_bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181029 for x86_64-unknown-linux): ASSERT failed! irred_a1zW :: [(xx_a1zV[sk:3] |> Sym {co_a1zu})] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:1826:53 in ghc:TcType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Comment: I think we decided to punt. comment:11 reports that the original bug is fixed. In addition, this ticket's friend #15799 is also no longer triggering. So I think the underlying bug here is real, but it's both difficult (impossible?) to trigger and difficult to fix. Furthermore, the bug can only strike in ''incorrect'' programs. This bug ''cannot'' make ill-typed Core. All of this suggests that we take my personal favorite course of action: do nothing. I've retitled the ticket to be more informative and will set the milestone accordingly. But I don't quite want to close the ticket, because I do believe there is a real bug here. Perhaps someday we'll find a way to trigger this ticket, making it more worthwhile to invest in a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 21:35:22 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 21:35:22 -0000 Subject: [GHC] #16385: Lousy error message for `instance forall c. c` In-Reply-To: <050.5577675c68c6eb87c39c68c755f609c4@haskell.org> References: <050.5577675c68c6eb87c39c68c755f609c4@haskell.org> Message-ID: <065.805339b61eb7457c4b3c6f3d527dfdad@haskell.org> #16385: Lousy error message for `instance forall c. c` -------------------------------------+------------------------------------- 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: Poor/confusing | Test Case: error message | rename/should_fail/T16385 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/483 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => rename/should_fail/T16385 * resolution: => fixed * milestone: => 8.10.1 Comment: Fixed in [https://gitlab.haskell.org/ghc/ghc/commit/78dd04f9126dc5df966070b8db4b39a517a9d99f 78dd04f9]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 21:48:28 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 21:48:28 -0000 Subject: [GHC] #8964: split_marker_entry assert breaks -split-objs and -ddump-opt-cmm In-Reply-To: <045.a507fc91c5f6f7ecd651faf4aa4b1d22@haskell.org> References: <045.a507fc91c5f6f7ecd651faf4aa4b1d22@haskell.org> Message-ID: <060.625a7385eed487c33b9c3dad3466c3f9@haskell.org> #8964: split_marker_entry assert breaks -split-objs and -ddump-opt-cmm ---------------------------------------+--------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: lowest | Milestone: ⊥ Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | ---------------------------------------+--------------------------------- Comment (by Marge Bot ): In [changeset:"37f257afcd6a52cf4d76c60d766b1aeb520b9f05/ghc" 37f257af/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="37f257afcd6a52cf4d76c60d766b1aeb520b9f05" Rip out object splitting The splitter is an evil Perl script that processes assembler code. Its job can be done better by the linker's --gc-sections flag. GHC passes this flag to the linker whenever -split-sections is passed on the command line. This is based on @DemiMarie's D2768. Fixes Trac #11315 Fixes Trac #9832 Fixes Trac #8964 Fixes Trac #8685 Fixes Trac #8629 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 21:48:28 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 21:48:28 -0000 Subject: [GHC] #11315: GHC doesn't restore split objects In-Reply-To: <050.3912eec305e6bc9feb185ccfad42de4c@haskell.org> References: <050.3912eec305e6bc9feb185ccfad42de4c@haskell.org> Message-ID: <065.5f0dbc5d9d485de7f2710e348224065f@haskell.org> #11315: GHC doesn't restore split objects -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"37f257afcd6a52cf4d76c60d766b1aeb520b9f05/ghc" 37f257af/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="37f257afcd6a52cf4d76c60d766b1aeb520b9f05" Rip out object splitting The splitter is an evil Perl script that processes assembler code. Its job can be done better by the linker's --gc-sections flag. GHC passes this flag to the linker whenever -split-sections is passed on the command line. This is based on @DemiMarie's D2768. Fixes Trac #11315 Fixes Trac #9832 Fixes Trac #8964 Fixes Trac #8685 Fixes Trac #8629 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 21:48:28 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 21:48:28 -0000 Subject: [GHC] #9832: Get rid of PERL dependency of `ghc-split` In-Reply-To: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> References: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> Message-ID: <057.8d71735f855ae0d7303604616e53a55b@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: dobenour Type: task | Status: patch Priority: normal | Milestone: 8.8.1 Component: Driver | Version: Resolution: | Keywords: perl Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): Phab:D2768 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Marge Bot ): In [changeset:"37f257afcd6a52cf4d76c60d766b1aeb520b9f05/ghc" 37f257af/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="37f257afcd6a52cf4d76c60d766b1aeb520b9f05" Rip out object splitting The splitter is an evil Perl script that processes assembler code. Its job can be done better by the linker's --gc-sections flag. GHC passes this flag to the linker whenever -split-sections is passed on the command line. This is based on @DemiMarie's D2768. Fixes Trac #11315 Fixes Trac #9832 Fixes Trac #8964 Fixes Trac #8685 Fixes Trac #8629 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 21:48:28 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 21:48:28 -0000 Subject: [GHC] #8629: Option 'split-objs' being ignored when trying to reduce object code size in iOS cross-compilation In-Reply-To: <051.7f175708aaf58854c5eeaa60c17f6275@haskell.org> References: <051.7f175708aaf58854c5eeaa60c17f6275@haskell.org> Message-ID: <066.bf8dfcb4ad0f51eedaf38c7cef561de6@haskell.org> #8629: Option 'split-objs' being ignored when trying to reduce object code size in iOS cross-compilation ---------------------------------+---------------------------------------- Reporter: f1rstmistake | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: ios Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 8300 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Marge Bot ): In [changeset:"37f257afcd6a52cf4d76c60d766b1aeb520b9f05/ghc" 37f257af/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="37f257afcd6a52cf4d76c60d766b1aeb520b9f05" Rip out object splitting The splitter is an evil Perl script that processes assembler code. Its job can be done better by the linker's --gc-sections flag. GHC passes this flag to the linker whenever -split-sections is passed on the command line. This is based on @DemiMarie's D2768. Fixes Trac #11315 Fixes Trac #9832 Fixes Trac #8964 Fixes Trac #8685 Fixes Trac #8629 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 21:48:28 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 21:48:28 -0000 Subject: [GHC] #15918: mkCastTy sometimes drops insoluble (Type ~ Constraint) coercions In-Reply-To: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> References: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> Message-ID: <066.8002ac61c23b3bc9fbb52efadc67bc53@haskell.org> #15918: mkCastTy sometimes drops insoluble (Type ~ Constraint) coercions -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | 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: quantified- | constraints/T15918 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/489 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"db039a4a10fc8fa9e03e6781d1c0dc33151beda6/ghc" db039a4a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="db039a4a10fc8fa9e03e6781d1c0dc33151beda6" Add regression test for #15918 The test case in #15918 no longer triggers an `ASSERT` failure on GHC HEAD, likely due to commit 682783828275cca5fd8bf5be5b52054c75e0e22c (`Make a smart mkAppTyM`). This patch adds a regression test for #15918 to finally put it to rest. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 21:48:28 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 21:48:28 -0000 Subject: [GHC] #8685: -split-objs doesn't work for executables In-Reply-To: <045.94465e8e883e56c8348459fd1c8e42a7@haskell.org> References: <045.94465e8e883e56c8348459fd1c8e42a7@haskell.org> Message-ID: <060.e568d7ce569d27a7e63b1133cc61d505@haskell.org> #8685: -split-objs doesn't work for executables -------------------------------------+------------------------------------- Reporter: refold | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"37f257afcd6a52cf4d76c60d766b1aeb520b9f05/ghc" 37f257af/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="37f257afcd6a52cf4d76c60d766b1aeb520b9f05" Rip out object splitting The splitter is an evil Perl script that processes assembler code. Its job can be done better by the linker's --gc-sections flag. GHC passes this flag to the linker whenever -split-sections is passed on the command line. This is based on @DemiMarie's D2768. Fixes Trac #11315 Fixes Trac #9832 Fixes Trac #8964 Fixes Trac #8685 Fixes Trac #8629 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 21:48:28 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 21:48:28 -0000 Subject: [GHC] #16187: Hadrian: Build fails when using absolute path for build root In-Reply-To: <045.6d7936d9e406faf3ac625fde5f6b9c5b@haskell.org> References: <045.6d7936d9e406faf3ac625fde5f6b9c5b@haskell.org> Message-ID: <060.ab44efd5da08d26e00432cadd9e0a77c@haskell.org> #16187: Hadrian: Build fails when using absolute path for build root -------------------------------------+------------------------------------- Reporter: davide | Owner: sykloid Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: hadrian build Resolution: | root relative absolute path 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 Marge Bot ): In [changeset:"2ff77b9894eecf51fa619ed2266ca196e296cd1e/ghc" 2ff77b9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2ff77b9894eecf51fa619ed2266ca196e296cd1e" Handle absolute paths to build roots in Hadrian. Fixes #16187. This patch fixes various path concatenation issues to allow functioning builds with hadrian when the build root location is specified with an absolute path. Remarks: - The path concatenation operator (-/-) now handles absolute second operands appropriately. Its behavior should match that of POSIX () in this regard. - The `getDirectoryFiles*` family of functions only searches for matches under the directory tree rooted by its first argument; all of the results are also relative to this root. If the first argument is the empty string, the current working directory is used. This patch passes the appropriate directory (almost always either `top` or `root`), and subsequently attaches that directory prefix so that the paths refer to the appropriate files. - Windows `tar` does not like colons (':') in paths to archive files, it tries to resolve them as remote paths. The `--force-local` option remedies this, and is applied on windows builds. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 6 21:48:28 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 06 Mar 2019 21:48:28 -0000 Subject: [GHC] #16385: Lousy error message for `instance forall c. c` In-Reply-To: <050.5577675c68c6eb87c39c68c755f609c4@haskell.org> References: <050.5577675c68c6eb87c39c68c755f609c4@haskell.org> Message-ID: <065.7f8a93536c85244c03dfc79519b87c0f@haskell.org> #16385: Lousy error message for `instance forall c. c` -------------------------------------+------------------------------------- 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: Poor/confusing | Test Case: error message | rename/should_fail/T16385 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/483 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"78dd04f9126dc5df966070b8db4b39a517a9d99f/ghc" 78dd04f9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="78dd04f9126dc5df966070b8db4b39a517a9d99f" Fix #16385 by appending _maybe to a use of lookupGlobalOcc `instance forall c. c` claimed that `c` was out of scope because the renamer was invoking `lookupGlobalOcc` on `c` (in `RnNames.getLocalNonValBinders`) without binding `c` first. To avoid this, this patch changes GHC to invoke `lookupGlobalOcc_maybe` on `c` instead, and if that returns `Nothing`, then bail out, resulting in a better error message. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 00:12:34 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 00:12:34 -0000 Subject: [GHC] #16401: Bad error message if we use TypeApplications with an identifier that doesn't exist Message-ID: <047.f558b0350babe4be1d0ac88aaa1c8733@haskell.org> #16401: Bad error message if we use TypeApplications with an identifier that doesn't exist -------------------------------------+------------------------------------- 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 TypeApplications #-} {-# LANGUAGE DataKinds #-} module BadError where foo :: Int foo = doesNotExist @123 {- [1 of 1] Compiling BadError ( BadError.hs, BadError.o ) BadError.hs:6:7: error: • Cannot apply expression of type ‘t1’ to a visible type argument ‘123’ • In the expression: doesNotExist @123 In an equation for ‘foo’: foo = doesNotExist @123 | 6 | foo = doesNotExist @123 -} }}} What I would expect is for it to say that {{{doesNotExist}}} is not bound as one might reasonably expect. This is very, very confusing and easy to hit in real life. If you are exposing a function {{{f}}}, using it somewhere with {{{f @123}}} but then later decide to remove or rename {{{f}}}, the error message doesn't suggest at all that {{{f}}} has disappeared and leaves the user scratching their head. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 00:22:03 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 00:22:03 -0000 Subject: [GHC] #16401: Bad error message if we use TypeApplications with an identifier that doesn't exist In-Reply-To: <047.f558b0350babe4be1d0ac88aaa1c8733@haskell.org> References: <047.f558b0350babe4be1d0ac88aaa1c8733@haskell.org> Message-ID: <062.999a5cca93343818724416a82e9d14ba@haskell.org> #16401: Bad error message if we use TypeApplications with an identifier that doesn't exist -------------------------------------+------------------------------------- Reporter: Fuuzetsu | 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: #13834 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13834 Comment: Thanks for the bug report. This is "fixed" in GHC 8.8 in the sense that it will at least report that `doesNotExist` is not in scope: {{{ [1 of 1] Compiling BadError ( Bug.hs, interpreted ) Bug.hs:6:7: error: Variable not in scope: doesNotExist | 6 | foo = doesNotExist @123 | ^^^^^^^^^^^^ Bug.hs:6:7: error: • Cannot apply expression of type ‘t1’ to a visible type argument ‘123’ • In the expression: doesNotExist @123 In an equation for ‘foo’: foo = doesNotExist @123 | 6 | foo = doesNotExist @123 | ^^^^^^^^^^^^^^^^^ }}} Of course, there's still the confusing "Cannot apply expression" part. That has previously been reported as #13834, so to avoid ticket duplication, I'll close this ticket in favor of that one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 03:36:32 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 03:36:32 -0000 Subject: [GHC] #16402: GHC doesnt' notice that (narrowWordFOO (x .&. FOO)) is just `x`. Message-ID: <047.0382e9c557b9dc406984a3eb800b61ef@haskell.org> #16402: GHC doesnt' notice that (narrowWordFOO (x .&. FOO)) is just `x`. -------------------------------------+------------------------------------- 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 {-# OPTIONS_GHC -ddump-simpl -ddump-to-file -dhex-word-literals -O2 #-} {-# LANGUAGE TypeApplications #-} module NarrowWord where import Data.Word import Data.Bits smallWord_foo :: Word64 -> Word64 smallWord_foo x = fromIntegral @Word16 $ fromIntegral (x .&. 0xFFFF) smallWord_bar :: Word64 -> Word64 smallWord_bar x = fromIntegral @Word16 $ fromIntegral x test :: Bool test = let w = 72430412501 in smallWord_foo w == smallWord_bar w }}} {{{#!hs -- RHS size: {terms: 7, types: 3, coercions: 0, joins: 0/0} smallWord_bar :: Word64 -> Word64 [GblId, Arity=1, Caf=NoCafRefs, Str=m, 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= \ (x_a1so [Occ=Once!] :: Word64) -> case x_a1so of { GHC.Word.W64# x#_a2Mw [Occ=Once] -> GHC.Word.W64# (GHC.Prim.narrow16Word# x#_a2Mw) }}] smallWord_bar = \ (x_a1so :: Word64) -> case x_a1so of { GHC.Word.W64# x#_a2Mw -> GHC.Word.W64# (GHC.Prim.narrow16Word# x#_a2Mw) } -- RHS size: {terms: 9, types: 3, coercions: 0, joins: 0/0} smallWord_foo :: Word64 -> Word64 [GblId, Arity=1, Caf=NoCafRefs, Str=m, 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= \ (x_a1hU [Occ=Once!] :: Word64) -> case x_a1hU of { GHC.Word.W64# x#_a30a [Occ=Once] -> GHC.Word.W64# (GHC.Prim.narrow16Word# (GHC.Prim.and# x#_a30a 0xffff##)) }}] smallWord_foo = \ (x_a1hU :: Word64) -> case x_a1hU of { GHC.Word.W64# x#_a30a -> GHC.Word.W64# (GHC.Prim.narrow16Word# (GHC.Prim.and# x#_a30a 0xffff##)) } -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} test :: Bool [GblId, Caf=NoCafRefs, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True) Tmpl= GHC.Types.True}] test = GHC.Types.True }}} For Word8, Word16, Word32, Word64 and Int8, Int16, Int32, Int64, I would expect GHC to never produce the {{{and}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 09:20:56 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 09:20:56 -0000 Subject: [GHC] #16394: GHC internal error while typechecking of instance definition In-Reply-To: <046.1aa3a5a103e1dd4c8fc51a808f32f1b2@haskell.org> References: <046.1aa3a5a103e1dd4c8fc51a808f32f1b2@haskell.org> Message-ID: <061.859776f551ad57ab61f6e6f5d3bc7e36@haskell.org> #16394: GHC internal error while typechecking of instance definition -------------------------------------+------------------------------------- Reporter: Day1721 | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: error/warning at compile-time | typecheck/should_fail/T16394 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): MR!496 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_fail/T16394 * differential: => MR!496 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 09:49:59 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 09:49:59 -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.10dc0c8ecca4a7ff052c07088453e679@haskell.org> #16263: Rework GHC's treatment of constraints in kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: TypeInType, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T16263 Blocked By: | Blocking: Related Tickets: #12102, #15872 | Differential Rev(s): | https://gitlab.haskell.org/ghc/ghc/merge_requests/128, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/499 -------------------------------------+------------------------------------- Changes (by simonpj): * status: patch => closed * testcase: => polykinds/T16263 * resolution: => fixed Comment: Landed as {{{ commit 25c3dd39f7d446f66b5c967be81f80cd7facb509 Author: Simon Peyton Jones Date: Wed Mar 6 10:17:12 2019 +0000 Test Trac #16263 testsuite/tests/polykinds/T16263.hs | 7 +++++++ testsuite/tests/polykinds/T16263.stderr | 2 ++ testsuite/tests/polykinds/all.T | 1 + 3 files changed, 10 insertions(+) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 09:51:13 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 09:51:13 -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.193757170328feb08f286a15229d08d4@haskell.org> #16221: Core Lint error with a data type -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | polykinds/T16221,T16221a Blocked By: | Blocking: Related Tickets: #16342 | Differential Rev(s): | https://gitlab.haskell.org/ghc/ghc/merge_requests/444, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/499 -------------------------------------+------------------------------------- Changes (by simonpj): * status: patch => closed * testcase: => polykinds/T16221,T16221a * resolution: => fixed Comment: Test landed as {{{ commit 07f378cee37338c5f2655b3a7e46dfef3f1c5cc1 Author: Simon Peyton Jones Date: Wed Mar 6 09:54:06 2019 +0000 Add tests for Trac #16221 and #16342 testsuite/tests/polykinds/T16221.hs | 13 +++++++++++++ testsuite/tests/polykinds/T16221a.hs | 7 +++++++ testsuite/tests/polykinds/T16221a.stderr | 6 ++++++ testsuite/tests/polykinds/T16342.hs | 13 +++++++++++++ testsuite/tests/polykinds/all.T | 3 +++ 5 files changed, 42 insertions(+) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 09:51:51 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 09:51:51 -0000 Subject: [GHC] #16342: Kind inference crash In-Reply-To: <046.eae912a23f2090497b4d3634101a1dd3@haskell.org> References: <046.eae912a23f2090497b4d3634101a1dd3@haskell.org> Message-ID: <061.5c652f7312f27160523a6dec514d5649@haskell.org> #16342: Kind inference crash -------------------------------------+------------------------------------- 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: #16221 | Differential Rev(s): | https://gitlab.haskell.org/ghc/ghc/merge_requests/444, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/499 -------------------------------------+------------------------------------- Changes (by simonpj): * status: patch => closed * resolution: => fixed Comment: Test landed as {{{ commit 07f378cee37338c5f2655b3a7e46dfef3f1c5cc1 Author: Simon Peyton Jones Date: Wed Mar 6 09:54:06 2019 +0000 Add tests for Trac #16221 and #16342 testsuite/tests/polykinds/T16221.hs | 13 +++++++++++++ testsuite/tests/polykinds/T16221a.hs | 7 +++++++ testsuite/tests/polykinds/T16221a.stderr | 6 ++++++ testsuite/tests/polykinds/T16342.hs | 13 +++++++++++++ testsuite/tests/polykinds/all.T | 3 +++ 5 files changed, 42 insertions(+) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 10:11:45 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 10:11:45 -0000 Subject: [GHC] #15918: mkCastTy sometimes drops insoluble (Type ~ Constraint) coercions In-Reply-To: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> References: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> Message-ID: <066.6f7a76a41b829fcc6b90732adc9347a4@haskell.org> #15918: mkCastTy sometimes drops insoluble (Type ~ Constraint) coercions -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | 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: quantified- | constraints/T15918 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/489 -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > EDIT: See comment:3 for the real cause and comment:17 for the current > plan. > --------------------------- > > Minimized from > https://gist.github.com/Icelandjack/683bd4b79027695ffc31632645c9d58b, I > don't expect `Build []` to kind check but ti shouldn't crash. > > {{{#!hs > {-# Language PolyKinds #-} > {-# Language TypeFamilies #-} > {-# Language ConstraintKinds #-} > {-# Language FlexibleContexts #-} > {-# Language QuantifiedConstraints #-} > {-# Language UndecidableInstances #-} > > import Data.Kind > > class Rev f where > rev :: f a > > instance (forall xx. cls xx => Rev xx) => Rev (Build cls) where > rev = undefined > > data Build :: ((k -> Type) -> Constraint) -> (k -> Type) > > uu = rev :: Build [] a > }}} > > gives a panic > > {{{ > $ ./ghc-stage2 --interactive -ignore-dot-ghci ~/hs/711_bug.hs > GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( ~/hs/711_bug.hs, interpreted ) > ghc-stage2: panic! (the 'impossible' happened) > (GHC version 8.7.20181029 for x86_64-unknown-linux): > ASSERT failed! > irred_a1zW :: [(xx_a1zV[sk:3] |> Sym {co_a1zu})] > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in > ghc:Outputable > pprPanic, called at compiler/utils/Outputable.hs:1219:5 in > ghc:Outputable > assertPprPanic, called at compiler/typecheck/TcType.hs:1826:53 in > ghc:TcType > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > > > }}} New description: '''EDIT: See comment:3 for the real cause and comment:17 for the current plan.''' See also: * TyCoRep `Note [Respecting definitional equality]` and its supporting `Note [Non-trivial definitional equality]` * #11715 Constraint vs * * #15799 TL;DR: there's a bug in here, that we don't know how to solve. But it's not biting us, and once we solve #11715 that may point the way. --------------------------- Minimized from https://gist.github.com/Icelandjack/683bd4b79027695ffc31632645c9d58b, I don't expect `Build []` to kind check but ti shouldn't crash. {{{#!hs {-# Language PolyKinds #-} {-# Language TypeFamilies #-} {-# Language ConstraintKinds #-} {-# Language FlexibleContexts #-} {-# Language QuantifiedConstraints #-} {-# Language UndecidableInstances #-} import Data.Kind class Rev f where rev :: f a instance (forall xx. cls xx => Rev xx) => Rev (Build cls) where rev = undefined data Build :: ((k -> Type) -> Constraint) -> (k -> Type) uu = rev :: Build [] a }}} gives a panic {{{ $ ./ghc-stage2 --interactive -ignore-dot-ghci ~/hs/711_bug.hs GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( ~/hs/711_bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181029 for x86_64-unknown-linux): ASSERT failed! irred_a1zW :: [(xx_a1zV[sk:3] |> Sym {co_a1zu})] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:1826:53 in ghc:TcType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 10:13:15 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 10:13:15 -0000 Subject: [GHC] #15799: GHC panic (and warnings) In-Reply-To: <051.9f403c90f37670c8d3e47780b16a76ec@haskell.org> References: <051.9f403c90f37670c8d3e47780b16a76ec@haskell.org> Message-ID: <066.9742a693ea589889df89214f155ed959@haskell.org> #15799: GHC panic (and warnings) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.1 Resolution: fixed | 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 simonpj): Just to note: the underlying bug is not fixed, but it's asleep. See #15918 for more details -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 10:14:17 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 10:14:17 -0000 Subject: [GHC] #15918: mkCastTy sometimes drops insoluble (Type ~ Constraint) coercions In-Reply-To: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> References: <051.49ae86c5825fcdcbb20533e9006e485e@haskell.org> Message-ID: <066.8426400def88326f186ddeaac3c884f3@haskell.org> #15918: mkCastTy sometimes drops insoluble (Type ~ Constraint) coercions -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | 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: quantified- | constraints/T15918 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/489 -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > '''EDIT: See comment:3 for the real cause and comment:17 for the current > plan.''' > > See also: > * TyCoRep `Note [Respecting definitional equality]` and its supporting > `Note [Non-trivial definitional equality]` > * #11715 Constraint vs * > * #15799 > > TL;DR: there's a bug in here, that we don't know how to solve. But it's > not biting us, and once we solve #11715 that may point the way. > > --------------------------- > > Minimized from > https://gist.github.com/Icelandjack/683bd4b79027695ffc31632645c9d58b, I > don't expect `Build []` to kind check but ti shouldn't crash. > > {{{#!hs > {-# Language PolyKinds #-} > {-# Language TypeFamilies #-} > {-# Language ConstraintKinds #-} > {-# Language FlexibleContexts #-} > {-# Language QuantifiedConstraints #-} > {-# Language UndecidableInstances #-} > > import Data.Kind > > class Rev f where > rev :: f a > > instance (forall xx. cls xx => Rev xx) => Rev (Build cls) where > rev = undefined > > data Build :: ((k -> Type) -> Constraint) -> (k -> Type) > > uu = rev :: Build [] a > }}} > > gives a panic > > {{{ > $ ./ghc-stage2 --interactive -ignore-dot-ghci ~/hs/711_bug.hs > GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( ~/hs/711_bug.hs, interpreted ) > ghc-stage2: panic! (the 'impossible' happened) > (GHC version 8.7.20181029 for x86_64-unknown-linux): > ASSERT failed! > irred_a1zW :: [(xx_a1zV[sk:3] |> Sym {co_a1zu})] > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in > ghc:Outputable > pprPanic, called at compiler/utils/Outputable.hs:1219:5 in > ghc:Outputable > assertPprPanic, called at compiler/typecheck/TcType.hs:1826:53 in > ghc:TcType > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > > > }}} New description: '''EDIT: See comment:3 for the real cause and comment:17 for the current plan.''' See also: * TyCoRep `Note [Respecting definitional equality]` and its supporting `Note [Non-trivial definitional equality]` * #11715 Constraint vs * * #15799 * #13650 TL;DR: there's a bug in here, that we don't know how to solve. But it's not biting us, and once we solve #11715 that may point the way. --------------------------- Minimized from https://gist.github.com/Icelandjack/683bd4b79027695ffc31632645c9d58b, I don't expect `Build []` to kind check but ti shouldn't crash. {{{#!hs {-# Language PolyKinds #-} {-# Language TypeFamilies #-} {-# Language ConstraintKinds #-} {-# Language FlexibleContexts #-} {-# Language QuantifiedConstraints #-} {-# Language UndecidableInstances #-} import Data.Kind class Rev f where rev :: f a instance (forall xx. cls xx => Rev xx) => Rev (Build cls) where rev = undefined data Build :: ((k -> Type) -> Constraint) -> (k -> Type) uu = rev :: Build [] a }}} gives a panic {{{ $ ./ghc-stage2 --interactive -ignore-dot-ghci ~/hs/711_bug.hs GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( ~/hs/711_bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181029 for x86_64-unknown-linux): ASSERT failed! irred_a1zW :: [(xx_a1zV[sk:3] |> Sym {co_a1zu})] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcType.hs:1826:53 in ghc:TcType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 10:15:01 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 10:15:01 -0000 Subject: [GHC] #11715: Constraint vs * In-Reply-To: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> References: <046.907e6fb89981c8664a4e7309489f51fd@haskell.org> Message-ID: <061.68f3069a2da5fec9110238dc16823cbc@haskell.org> #11715: Constraint vs * -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Typeable, Resolution: | LevityPolymorphism, Roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11621, #13742, | Differential Rev(s): Phab:D3316 #16139, #16148 | Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > I first noticed something was a bit odd with `Constraint` when chasing > #11334. Consider this testcase (`-O0` is sufficient), > {{{#!hs > import Data.Typeable > > main = do > print $ typeRep (Proxy :: Proxy Eq) > print $ typeOf (Proxy :: Proxy Eq) > }}} > With `ghc-8.0` this will produce, > {{{ > Eq > Proxy (* -> *) Eq > }}} > Notice the second line; GHC seems to be claiming that `Eq :: * -> *`, > which is clearly nonsense. > > I believe this issue may be the cause of some of the testsuite failures > that I'm seeing on #11011. Unfortunately I haven't the foggiest where > this issue might originate. > > See also > * #11621 > * #12933 > * #9547 > * #13931 New description: I first noticed something was a bit odd with `Constraint` when chasing #11334. Consider this testcase (`-O0` is sufficient), {{{#!hs import Data.Typeable main = do print $ typeRep (Proxy :: Proxy Eq) print $ typeOf (Proxy :: Proxy Eq) }}} With `ghc-8.0` this will produce, {{{ Eq Proxy (* -> *) Eq }}} Notice the second line; GHC seems to be claiming that `Eq :: * -> *`, which is clearly nonsense. I believe this issue may be the cause of some of the testsuite failures that I'm seeing on #11011. Unfortunately I haven't the foggiest where this issue might originate. See also * #11621 * #12933 * #9547 * #13931 * #15918 (about `mkCastTy`) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 12:09:21 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 12:09:21 -0000 Subject: [GHC] #16400: Hadrian: support shake's --lint-fsatrace feature In-Reply-To: <045.61d70d6489542a352df44f69f69713ec@haskell.org> References: <045.61d70d6489542a352df44f69f69713ec@haskell.org> Message-ID: <060.9a79fb10d6893af8bcf0535171e2ed25@haskell.org> #16400: Hadrian: support shake's --lint-fsatrace feature -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: lint shake Resolution: | hadrian fsatrace Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by davide: Old description: > Shake's `--lint-fsatrace` feature uses > [https://github.com/jacereda/fsatrace fsatrace] to track file accesses of > external commands. This allows for more accurate dependency linting which > is important e.g. for caching. > > Hadrian already accepts the `--lint-fsatrace` command line option (it is > passed on to shake automatically), but it currently has no effect. The > shake options are not set correctly (In particular > [https://github.com/jacereda/fsatrace shakeLintInside] must be set). New description: Shake's `--lint-fsatrace` feature uses [https://github.com/jacereda/fsatrace fsatrace] to track file accesses of external commands. This allows for more accurate dependency linting which is important e.g. for caching. Hadrian already accepts the `--lint-fsatrace` command line option (it is passed on to shake automatically), but it currently has no effect. The shake options are not set correctly (In particular [https://github.com/jacereda/fsatrace shakeLintInside] must be set). Required Changes: * [https://github.com/jacereda/fsatrace shakeLintInside] must be set * Out of tree build dirs don't get linted. {{{ buildRoot -/- "lint-test" %> \out -> let gen t f = cmd Shell "echo" t ">" (toNative f) :: Action () gen "x" $ out <.> "txt" need [out <.> "txt"] -- This need should set off a lint error. writeFile' out "" }}} * fsatrace gives absolute paths. Shake then tries and fails to convert to relative paths [https://github.com/ndmitchell/shake/blob/master/src/Development/Shake/Command.hs#L148 here]. Stuck with an unexpected absolute path, shake think the file isn't needed event thought the relative path **is** needed. * What else? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 12:13:16 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 12:13:16 -0000 Subject: [GHC] #16403: Add isBinDigit to Data.Char Message-ID: <045.fc1b72d5cb0a2f54968b0797376d0c25@haskell.org> #16403: Add isBinDigit to Data.Char -------------------------------------+------------------------------------- Reporter: hesiod | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: | Version: 8.6.4 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 {{{Data.Char}}} module contains helper functions that determine whether a Char is a decimal, octal or hexadecimal digit ({{{isDigit}}}, {{{isOctDigit}}}, {{{isHexDigit}}}). A similar helper function for binary digits is not included for no apparent reason (maybe because the number parsers in the {{{Numeric}}} module also don't support binary digits?). The implementation for such a {{{isBinDigit}}} should be trivial, aside from performance considerations: {{{isDigit}}} and friends perform the test using only subtraction and an unsigned comparison, I'm not sure whether {{{isBinDigit}}} offers any different performant implementations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 13:09:38 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 13:09:38 -0000 Subject: [GHC] #16404: Type error recovery crash Message-ID: <046.af43f5ce7fff1451c2c768f83d9a2ef2@haskell.org> #16404: Type error recovery 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: -------------------------------------+------------------------------------- This program is derived from #16376: {{{ {-# LANGUAGE TypeApplications #-} module Bug where h x = let f = id @Maybe in Just f }}} If you compile with `-fdefer-type-errors -dcore-lint` you'll get {{{ *** Core Lint errors : in result of Desugar (before optimization) *** : warning: In the expression: f_arZ @ a_at1 Out of scope: f_arZ :: forall a. a [LclId] *** Offending Program *** Rec { $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "T16376"#) h :: forall p a. p -> Maybe a [LclIdX] h = \ (@ p_asV) (@ a_at1) -> case typeError @ ('TupleRep '[]) @ ((* -> *) ~# *) "T16376.hs:4:19: error:\n\ \ \\226\\128\\162 Expecting one more argument to \\226\\128\\152Maybe\\226\\128\\153\n\ \ Expected a type, but \\226\\128\\152Maybe\\226\\128\\153 has kind \\226\\128\\152* -> *\\226\\128\\153\n\ \ \\226\\128\\162 In the type \\226\\128\\152Maybe\\226\\128\\153\n\ \ In the expression: id @Maybe\n\ \ In an equation for \\226\\128\\152f\\226\\128\\153: f = id @Maybe\n\ \(deferred type error)"# of co_asZ { __DEFAULT -> letrec { h_at5 :: p_asV -> Maybe a_at1 [LclId] h_at5 = \ (x_arY :: p_asV) -> Just @ a_at1 (f_arZ @ a_at1); } in h_at5 } end Rec } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 13:40:41 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 13:40:41 -0000 Subject: [GHC] #16404: Type error recovery crash In-Reply-To: <046.af43f5ce7fff1451c2c768f83d9a2ef2@haskell.org> References: <046.af43f5ce7fff1451c2c768f83d9a2ef2@haskell.org> Message-ID: <061.0e790e314517c2a1b7193753008114a6@haskell.org> #16404: Type error recovery 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 simonpj): Reason for this: this code in `TcBinds` {{{ tcPolyBinds sig_fn prag_fn rec_group rec_tc closed bind_list = setSrcSpan loc $ recoverM (recoveryCode binder_names sig_fn) $ do -- Set up main recover; take advantage of any type sigs }}} recovers from an error in the binding for `f`. But the recovery code is: {{{ recoveryCode :: [Name] -> TcSigFun -> TcM (LHsBinds GhcTcId, [Id]) recoveryCode binder_names sig_fn = do { traceTc "tcBindsWithSigs: error recovery" (ppr binder_names) ; let poly_ids = map mk_dummy binder_names ; return (emptyBag, poly_ids) } }}} That is, it returns no bindings. That's probably wrong if we have `-fdefer-type-errors`. We should probably generate a stub binding {{{ f = typeError "Deferred error in binding for f" }}} That would avoid downstream breakage. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 13:44:30 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 13:44:30 -0000 Subject: [GHC] #16404: Type error recovery crash In-Reply-To: <046.af43f5ce7fff1451c2c768f83d9a2ef2@haskell.org> References: <046.af43f5ce7fff1451c2c768f83d9a2ef2@haskell.org> Message-ID: <061.1475eefa635d4eda8a8b524c53f3d711@haskell.org> #16404: Type error recovery 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: | -------------------------------------+------------------------------------- Old description: > This program is derived from #16376: > {{{ > {-# LANGUAGE TypeApplications #-} > module Bug where > > h x = let f = id @Maybe > in Just f > }}} > If you compile with `-fdefer-type-errors -dcore-lint` you'll get > {{{ > *** Core Lint errors : in result of Desugar (before optimization) *** > : warning: > In the expression: f_arZ @ a_at1 > Out of scope: f_arZ :: forall a. a > [LclId] > *** Offending Program *** > Rec { > $trModule :: Module > [LclIdX] > $trModule = Module (TrNameS "main"#) (TrNameS "T16376"#) > > h :: forall p a. p -> Maybe a > [LclIdX] > h = \ (@ p_asV) (@ a_at1) -> > case typeError > @ ('TupleRep '[]) > @ ((* -> *) ~# *) > "T16376.hs:4:19: error:\n\ > \ \\226\\128\\162 Expecting one more argument to > \\226\\128\\152Maybe\\226\\128\\153\n\ > \ Expected a type, but > \\226\\128\\152Maybe\\226\\128\\153 has kind \\226\\128\\152* -> > *\\226\\128\\153\n\ > \ \\226\\128\\162 In the type > \\226\\128\\152Maybe\\226\\128\\153\n\ > \ In the expression: id @Maybe\n\ > \ In an equation for \\226\\128\\152f\\226\\128\\153: f > = id @Maybe\n\ > \(deferred type error)"# > of co_asZ > { __DEFAULT -> > letrec { > h_at5 :: p_asV -> Maybe a_at1 > [LclId] > h_at5 = \ (x_arY :: p_asV) -> Just @ a_at1 (f_arZ @ a_at1); } in > h_at5 > } > end Rec } > }}} New description: This program is derived from #16376: {{{ {-# LANGUAGE TypeApplications #-} module Bug where h x = let f = id @Maybe in Just f }}} If you compile with `-fdefer-type-errors -dcore-lint` you'll get {{{ *** Core Lint errors : in result of Desugar (before optimization) *** : warning: In the expression: f_arZ @ a_at1 Out of scope: f_arZ :: forall a. a [LclId] *** Offending Program *** Rec { $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "T16376"#) h :: forall p a. p -> Maybe a [LclIdX] h = \ (@ p_asV) (@ a_at1) -> case typeError @ ('TupleRep '[]) @ ((* -> *) ~# *) "T16376.hs:4:19: error:\n\ \ \\226\\128\\162 Expecting one more argument to \\226\\128\\152Maybe\\226\\128\\153\n\ \ Expected a type, but \\226\\128\\152Maybe\\226\\128\\153 has kind \\226\\128\\152* -> *\\226\\128\\153\n\ \ \\226\\128\\162 In the type \\226\\128\\152Maybe\\226\\128\\153\n\ \ In the expression: id @Maybe\n\ \ In an equation for \\226\\128\\152f\\226\\128\\153: f = id @Maybe\n\ \(deferred type error)"# of co_asZ { __DEFAULT -> letrec { h_at5 :: p_asV -> Maybe a_at1 [LclId] h_at5 = \ (x_arY :: p_asV) -> Just @ a_at1 (f_arZ @ a_at1); } in h_at5 } end Rec } }}} Without Lint it just squeezes by, because that `case typeError of ..." discards the "..." since it is unreachable -- Comment (by simonpj): The breakage is worse for GHCi, with `-fdefer-type-errors`, because the `case (typeError "...") ...` transformation doesn't happen, so `f` is still there at the end: {{{ ==================== Simplified expression ==================== case Control.Exception.Base.typeError @ ('GHC.Types.TupleRep '[]) @ ((* -> *) GHC.Prim.~# *) ":2:9: error:\n\ \ \\226\\128\\162 Expecting one more argument to \\226\\128\\152Maybe\\226\\128\\153\n\ \ Expected a type, but \\226\\128\\152Maybe\\226\\128\\153 has kind \\226\\128\\152* -> *\\226\\128\\153\n\ \ \\226\\128\\162 In the type \\226\\128\\152Maybe\\226\\128\\153\n\ \ In the expression: id @Maybe\n\ \ In an equation for \\226\\128\\152f\\226\\128\\153: f = id @Maybe\n\ \(deferred type error)"# of co_a1zL { __DEFAULT -> GHC.Base.returnIO @ [()] (GHC.Types.: @ () (f_a1yP `cast` (UnsafeCo representational (forall a. a) () :: (forall a. a) ~R# ())) (GHC.Types.[] @ ())) } }}} which leads to an outright crash. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 13:45:27 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 13:45:27 -0000 Subject: [GHC] #16404: Type error recovery crash In-Reply-To: <046.af43f5ce7fff1451c2c768f83d9a2ef2@haskell.org> References: <046.af43f5ce7fff1451c2c768f83d9a2ef2@haskell.org> Message-ID: <061.8477d44be0c4d003d48ad6372560ae94@haskell.org> #16404: Type error recovery 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 simonpj): My conclusions: * Add a stub binding in `TcBinds.recoveryCode` * Maybe the case-of-error transformation happen even in GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 13:46:10 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 13:46:10 -0000 Subject: [GHC] #16376: GHCi HEAD silently accepts ill-kinded visible type applications with :type In-Reply-To: <050.2844026e72998c0da21d307d0ec6cfc6@haskell.org> References: <050.2844026e72998c0da21d307d0ec6cfc6@haskell.org> Message-ID: <065.565da505f5217db4d62abfc120bad340@haskell.org> #16376: GHCi HEAD silently accepts ill-kinded visible type applications with :type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: GHCi | Version: 8.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): comment:3 reveals another bug: see #16404 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 14:46:26 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 14:46:26 -0000 Subject: [GHC] #16405: Plugin tests are remarkably fragile on Windows Message-ID: <046.973efe1095058a0c1e05f8cf2c342063@haskell.org> #16405: Plugin tests are remarkably fragile on Windows -------------------------------------+------------------------------------- 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: -------------------------------------+------------------------------------- There is something odd afoot in the tests in `testsuite/tests/plugins` on Windows. In any given testsuite run at least half a dozen of these tests fail for one reason or another (often a timeout sometimes another). I'm collecting these failures here to try to make sense of them: {{{ =====> T16260(normal) 6833 of 6839 [2, 14, 0] cd "plugins/T16260.run" && $MAKE -s --no-print-directory -C simple-plugin package.T16260 TOP=/c/GitLabRunner/builds/78d7d3f9/0/ghc/ghc/testsuite cd "plugins/T16260.run" && $MAKE -s --no-print-directory T16260 --- plugins/T16260.run/T16260.stdout.normalised 2019-03-06 03:20:38.902713500 +0000 +++ plugins/T16260.run/T16260.run.stdout.normalised 2019-03-06 03:20:38.903686400 +0000 @@ -1,4 +0,0 @@ -False -None -True -Safe Actual stdout output differs from expected: diff -uw "plugins/T16260.run/T16260.stdout.normalised" "plugins/T16260.run/T16260.run.stdout.normalised" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 14:47:16 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 14:47:16 -0000 Subject: [GHC] #16405: Plugin tests are remarkably fragile on Windows In-Reply-To: <046.973efe1095058a0c1e05f8cf2c342063@haskell.org> References: <046.973efe1095058a0c1e05f8cf2c342063@haskell.org> Message-ID: <061.eccf2e5f7f656615a5d31c4e5472d9d0@haskell.org> #16405: Plugin tests are remarkably fragile on Windows -------------------------------------+------------------------------------- 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 bgamari): It seems like nearly all of these failures are due to timeouts. I have increased the timeout multiplier to 5 and yet still essentially the same number of tests fail. I'm going to mark these as fragile for the moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 16:07:52 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 16:07:52 -0000 Subject: [GHC] #16400: Hadrian: support shake's --lint-fsatrace feature In-Reply-To: <045.61d70d6489542a352df44f69f69713ec@haskell.org> References: <045.61d70d6489542a352df44f69f69713ec@haskell.org> Message-ID: <060.7882ef0c0367e48aac3902a428f0eb27@haskell.org> #16400: Hadrian: support shake's --lint-fsatrace feature -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: lint shake Resolution: | hadrian fsatrace Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by snowleopard): * cc: NeilMitchell (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 16:14:16 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 16:14:16 -0000 Subject: [GHC] #14741: High-memory usage during compilation using Template Haskell In-Reply-To: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> References: <048.2e25a805133a398645ff22a5c79e588c@haskell.org> Message-ID: <063.aad011303762fe31117080f21850e7d6@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.6.4 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): * version: 8.2.2 => 8.6.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 17:19:55 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 17:19:55 -0000 Subject: [GHC] #16400: Hadrian: support shake's --lint-fsatrace feature In-Reply-To: <045.61d70d6489542a352df44f69f69713ec@haskell.org> References: <045.61d70d6489542a352df44f69f69713ec@haskell.org> Message-ID: <060.cedcd14c25913af881ee7d1fa3266ee4@haskell.org> #16400: Hadrian: support shake's --lint-fsatrace feature -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.3 (Hadrian) | Keywords: lint shake Resolution: | hadrian fsatrace Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > Shake's `--lint-fsatrace` feature uses > [https://github.com/jacereda/fsatrace fsatrace] to track file accesses of > external commands. This allows for more accurate dependency linting which > is important e.g. for caching. > > Hadrian already accepts the `--lint-fsatrace` command line option (it is > passed on to shake automatically), but it currently has no effect. The > shake options are not set correctly (In particular > [https://github.com/jacereda/fsatrace shakeLintInside] must be set). > > Required Changes: > > * [https://github.com/jacereda/fsatrace shakeLintInside] must be set > * Out of tree build dirs don't get linted. > {{{ > buildRoot -/- "lint-test" %> \out -> > let gen t f = cmd Shell "echo" t ">" (toNative f) :: Action () > gen "x" $ out <.> "txt" > need [out <.> "txt"] -- This need should set off a lint error. > writeFile' out "" > }}} > * fsatrace gives absolute paths. Shake then tries and fails to convert > to relative paths > [https://github.com/ndmitchell/shake/blob/master/src/Development/Shake/Command.hs#L148 > here]. Stuck with an unexpected absolute path, shake think the file isn't > needed event thought the relative path **is** needed. > * What else? New description: Shake's `--lint-fsatrace` feature uses [https://github.com/jacereda/fsatrace fsatrace] to track file accesses of external commands. This allows for more accurate dependency linting which is important e.g. for caching. Hadrian already accepts the `--lint-fsatrace` command line option (it is passed on to shake automatically), but it currently has no effect. The shake options are not set correctly (In particular [https://github.com/jacereda/fsatrace shakeLintInside] must be set). Required Changes: 1. [https://github.com/jacereda/fsatrace shakeLintInside] must be set 2. Out of tree build dirs don't get linted. {{{ buildRoot -/- "lint-test" %> \out -> let gen t f = cmd Shell "echo" t ">" (toNative f) :: Action () gen "x" $ out <.> "txt" need [out <.> "txt"] -- This need should set off a lint error. writeFile' out "" }}} * fsatrace gives absolute paths. Shake then tries and fails to convert to relative paths [https://github.com/ndmitchell/shake/blob/master/src/Development/Shake/Command.hs#L148 here]. Stuck with an unexpected absolute path, shake thinks the file isn't needed even thought the relative path **is** needed. 3. What else? -- Comment (by davide): I've added a shake PR https://github.com/ndmitchell/shake/pull/656 (this related to point 2 above). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 19:20:58 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 19:20:58 -0000 Subject: [GHC] #16391: "Quantified type's kind mentions quantified type variable" error with fancy-kinded GADT In-Reply-To: <050.e07e7af69cce8e666cdbeacaf56a9da6@haskell.org> References: <050.e07e7af69cce8e666cdbeacaf56a9da6@haskell.org> Message-ID: <065.5b0dd0f5760165e146a74d98829d8ba1@haskell.org> #16391: "Quantified type's kind mentions quantified type variable" error with fancy-kinded GADT -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | dependent/should_compile/T16391a, | dependent/should_fail/T16391b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/503 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => dependent/should_compile/T16391a, dependent/should_fail/T16391b * resolution: => fixed * milestone: => 8.10.1 Comment: Landed in [https://gitlab.haskell.org/ghc/ghc/commit/068b7e983f4a0b35f453aa5e609998efd0c3f334 068b7e98]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 20:30:29 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 20:30:29 -0000 Subject: [GHC] #16406: Array code works with GHC 8.4.4, hangs with GHC 8.6.4 Message-ID: <047.c6717f5d6f549f0b63ee9f534201a281@haskell.org> #16406: Array code works with GHC 8.4.4, hangs with GHC 8.6.4 -------------------------------------+------------------------------------- Reporter: arybczak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.6.4 (other) | Keywords: array | 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: ```haskell import Data.Array.IArray import Data.Bits import Data.Word loop :: Array Int Word32 loop = accumArray (curry snd) 0 (0,79) $ [(i, xxor i) | i <- [16..79]] where xxor :: Int -> Word32 xxor i = loop ! (i-16) `xor` loop ! (i-3) `xor` loop ! (i-8) `xor` loop ! (i-14) ``` When loaded into ghci-8.4.4, `loop` works fine: ``` GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/unknown/.ghci λ> :l array.hs [1 of 1] Compiling Main ( array.hs, interpreted ) Ok, one module loaded. λ> loop array (0,79) [(0,0),(1,0),(2,0),(3,0),(4,0),(5,0),(6,0),(7,0),(8,0),(9,0),(10,0),(11,0),(12,0),(13,0),(14,0),(15,0),(16,0),(17,0),(18,0),(19,0),(20,0),(21,0),(22,0),(23,0),(24,0),(25,0),(26,0),(27,0),(28,0),(29,0),(30,0),(31,0),(32,0),(33,0),(34,0),(35,0),(36,0),(37,0),(38,0),(39,0),(40,0),(41,0),(42,0),(43,0),(44,0),(45,0),(46,0),(47,0),(48,0),(49,0),(50,0),(51,0),(52,0),(53,0),(54,0),(55,0),(56,0),(57,0),(58,0),(59,0),(60,0),(61,0),(62,0),(63,0),(64,0),(65,0),(66,0),(67,0),(68,0),(69,0),(70,0),(71,0),(72,0),(73,0),(74,0),(75,0),(76,0),(77,0),(78,0),(79,0)] ``` However, when loaded into ghci-8.6.4, it hangs (with no CPU utilization): ``` GHCi, version 8.6.4: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/unknown/.ghci λ> :l array.hs [1 of 1] Compiling Main ( array.hs, interpreted ) Ok, one module loaded. λ> loop array ``` The definition of loop is a piece of code taken from Crypto library (https://hackage.haskell.org/package/Crypto-4.2.5.1/docs/src/Data-Digest- SHA1.html, `oneBlock` function) Granted, this library is pretty much dead (last update in 2012), but it's a bit suspect that code suddenly stops working in the worst way possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 20:32:24 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 20:32:24 -0000 Subject: [GHC] #16406: Array code works with GHC 8.4.4, hangs with GHC 8.6.4 In-Reply-To: <047.c6717f5d6f549f0b63ee9f534201a281@haskell.org> References: <047.c6717f5d6f549f0b63ee9f534201a281@haskell.org> Message-ID: <062.607dc50196857b4653cdd595c4510a10@haskell.org> #16406: Array code works with GHC 8.4.4, hangs with GHC 8.6.4 -------------------------------------+------------------------------------- Reporter: arybczak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.6.4 (other) | Resolution: | Keywords: array 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 arybczak: Old description: > Consider the following: > > ```haskell > import Data.Array.IArray > import Data.Bits > import Data.Word > > loop :: Array Int Word32 > loop = accumArray (curry snd) 0 (0,79) $ [(i, xxor i) | i <- [16..79]] > where > xxor :: Int -> Word32 > xxor i = loop ! (i-16) `xor` loop ! (i-3) `xor` loop ! (i-8) `xor` > loop ! (i-14) > ``` > > When loaded into ghci-8.4.4, `loop` works fine: > > ``` > GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help > Loaded GHCi configuration from /home/unknown/.ghci > λ> :l array.hs > [1 of 1] Compiling Main ( array.hs, interpreted ) > Ok, one module loaded. > λ> loop > array (0,79) > [(0,0),(1,0),(2,0),(3,0),(4,0),(5,0),(6,0),(7,0),(8,0),(9,0),(10,0),(11,0),(12,0),(13,0),(14,0),(15,0),(16,0),(17,0),(18,0),(19,0),(20,0),(21,0),(22,0),(23,0),(24,0),(25,0),(26,0),(27,0),(28,0),(29,0),(30,0),(31,0),(32,0),(33,0),(34,0),(35,0),(36,0),(37,0),(38,0),(39,0),(40,0),(41,0),(42,0),(43,0),(44,0),(45,0),(46,0),(47,0),(48,0),(49,0),(50,0),(51,0),(52,0),(53,0),(54,0),(55,0),(56,0),(57,0),(58,0),(59,0),(60,0),(61,0),(62,0),(63,0),(64,0),(65,0),(66,0),(67,0),(68,0),(69,0),(70,0),(71,0),(72,0),(73,0),(74,0),(75,0),(76,0),(77,0),(78,0),(79,0)] > ``` > > However, when loaded into ghci-8.6.4, it hangs (with no CPU utilization): > ``` > GHCi, version 8.6.4: http://www.haskell.org/ghc/ :? for help > Loaded GHCi configuration from /home/unknown/.ghci > λ> :l array.hs > [1 of 1] Compiling Main ( array.hs, interpreted ) > Ok, one module loaded. > λ> loop > array > ``` > > The definition of loop is a piece of code taken from Crypto library > (https://hackage.haskell.org/package/Crypto-4.2.5.1/docs/src/Data-Digest- > SHA1.html, `oneBlock` function) > > Granted, this library is pretty much dead (last update in 2012), but it's > a bit suspect that code suddenly stops working in the worst way possible. New description: Consider the following: {{{#!haskell import Data.Array.IArray import Data.Bits import Data.Word loop :: Array Int Word32 loop = accumArray (curry snd) 0 (0,79) $ [(i, xxor i) | i <- [16..79]] where xxor :: Int -> Word32 xxor i = loop ! (i-16) `xor` loop ! (i-3) `xor` loop ! (i-8) `xor` loop ! (i-14) }}} When loaded into ghci-8.4.4, `loop` works fine: {{{ GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/unknown/.ghci λ> :l array.hs [1 of 1] Compiling Main ( array.hs, interpreted ) Ok, one module loaded. λ> loop array (0,79) [(0,0),(1,0),(2,0),(3,0),(4,0),(5,0),(6,0),(7,0),(8,0),(9,0),(10,0),(11,0),(12,0),(13,0),(14,0),(15,0),(16,0),(17,0),(18,0),(19,0),(20,0),(21,0),(22,0),(23,0),(24,0),(25,0),(26,0),(27,0),(28,0),(29,0),(30,0),(31,0),(32,0),(33,0),(34,0),(35,0),(36,0),(37,0),(38,0),(39,0),(40,0),(41,0),(42,0),(43,0),(44,0),(45,0),(46,0),(47,0),(48,0),(49,0),(50,0),(51,0),(52,0),(53,0),(54,0),(55,0),(56,0),(57,0),(58,0),(59,0),(60,0),(61,0),(62,0),(63,0),(64,0),(65,0),(66,0),(67,0),(68,0),(69,0),(70,0),(71,0),(72,0),(73,0),(74,0),(75,0),(76,0),(77,0),(78,0),(79,0)] }}} However, when loaded into ghci-8.6.4, it hangs (with no CPU utilization): {{{ GHCi, version 8.6.4: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/unknown/.ghci λ> :l array.hs [1 of 1] Compiling Main ( array.hs, interpreted ) Ok, one module loaded. λ> loop array }}} The definition of loop is a piece of code taken from Crypto library (https://hackage.haskell.org/package/Crypto-4.2.5.1/docs/src/Data-Digest- SHA1.html, `oneBlock` function) Granted, this library is pretty much dead (last update in 2012), but it's a bit suspect that code suddenly stops working in the worst way possible. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 7 20:35:45 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 07 Mar 2019 20:35:45 -0000 Subject: [GHC] #16406: Array code works with GHC 8.4.4, hangs with GHC 8.6.4 In-Reply-To: <047.c6717f5d6f549f0b63ee9f534201a281@haskell.org> References: <047.c6717f5d6f549f0b63ee9f534201a281@haskell.org> Message-ID: <062.1429a625e369d35ed3751cbab48e430b@haskell.org> #16406: Array code works with GHC 8.4.4, hangs with GHC 8.6.4 -------------------------------------+------------------------------------- Reporter: arybczak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.6.4 (other) | Resolution: | Keywords: array 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 arybczak: Old description: > Consider the following: > > {{{#!haskell > import Data.Array.IArray > import Data.Bits > import Data.Word > > loop :: Array Int Word32 > loop = accumArray (curry snd) 0 (0,79) $ [(i, xxor i) | i <- [16..79]] > where > xxor :: Int -> Word32 > xxor i = loop ! (i-16) `xor` loop ! (i-3) `xor` loop ! (i-8) `xor` > loop ! (i-14) > }}} > > When loaded into ghci-8.4.4, `loop` works fine: > > {{{ > GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help > Loaded GHCi configuration from /home/unknown/.ghci > λ> :l array.hs > [1 of 1] Compiling Main ( array.hs, interpreted ) > Ok, one module loaded. > λ> loop > array (0,79) > [(0,0),(1,0),(2,0),(3,0),(4,0),(5,0),(6,0),(7,0),(8,0),(9,0),(10,0),(11,0),(12,0),(13,0),(14,0),(15,0),(16,0),(17,0),(18,0),(19,0),(20,0),(21,0),(22,0),(23,0),(24,0),(25,0),(26,0),(27,0),(28,0),(29,0),(30,0),(31,0),(32,0),(33,0),(34,0),(35,0),(36,0),(37,0),(38,0),(39,0),(40,0),(41,0),(42,0),(43,0),(44,0),(45,0),(46,0),(47,0),(48,0),(49,0),(50,0),(51,0),(52,0),(53,0),(54,0),(55,0),(56,0),(57,0),(58,0),(59,0),(60,0),(61,0),(62,0),(63,0),(64,0),(65,0),(66,0),(67,0),(68,0),(69,0),(70,0),(71,0),(72,0),(73,0),(74,0),(75,0),(76,0),(77,0),(78,0),(79,0)] > }}} > > However, when loaded into ghci-8.6.4, it hangs (with no CPU utilization): > {{{ > GHCi, version 8.6.4: http://www.haskell.org/ghc/ :? for help > Loaded GHCi configuration from /home/unknown/.ghci > λ> :l array.hs > [1 of 1] Compiling Main ( array.hs, interpreted ) > Ok, one module loaded. > λ> loop > array > }}} > > The definition of loop is a piece of code taken from Crypto library > (https://hackage.haskell.org/package/Crypto-4.2.5.1/docs/src/Data-Digest- > SHA1.html, `oneBlock` function) > > Granted, this library is pretty much dead (last update in 2012), but it's > a bit suspect that code suddenly stops working in the worst way possible. New description: Consider the following: {{{#!haskell import Data.Array.IArray import Data.Bits import Data.Word loop :: Array Int Word32 loop = accumArray (curry snd) 0 (0,79) $ [(i, xxor i) | i <- [16..79]] where xxor :: Int -> Word32 xxor i = loop ! (i-16) `xor` loop ! (i-3) `xor` loop ! (i-8) `xor` loop ! (i-14) }}} When loaded into ghci-8.4.4, `loop` works fine: {{{ GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/unknown/.ghci λ> :l array.hs [1 of 1] Compiling Main ( array.hs, interpreted ) Ok, one module loaded. λ> loop array (0,79) [(0,0),(1,0),(2,0),(3,0),(4,0),(5,0),(6,0),(7,0),(8,0),(9,0),(10,0),(11,0),(12,0),(13,0),(14,0),(15,0),(16,0),(17,0),(18,0),(19,0),(20,0),(21,0),(22,0),(23,0),(24,0),(25,0),(26,0),(27,0),(28,0),(29,0),(30,0),(31,0),(32,0),(33,0),(34,0),(35,0),(36,0),(37,0),(38,0),(39,0),(40,0),(41,0),(42,0),(43,0),(44,0),(45,0),(46,0),(47,0),(48,0),(49,0),(50,0),(51,0),(52,0),(53,0),(54,0),(55,0),(56,0),(57,0),(58,0),(59,0),(60,0),(61,0),(62,0),(63,0),(64,0),(65,0),(66,0),(67,0),(68,0),(69,0),(70,0),(71,0),(72,0),(73,0),(74,0),(75,0),(76,0),(77,0),(78,0),(79,0)] }}} However, when loaded into ghci-8.6.4, it hangs (with no CPU utilization): {{{ GHCi, version 8.6.4: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/unknown/.ghci λ> :l array.hs [1 of 1] Compiling Main ( array.hs, interpreted ) Ok, one module loaded. λ> loop array }}} The definition of loop is a piece of code taken from Crypto library (https://hackage.haskell.org/package/Crypto-4.2.5.1/docs/src/Data-Digest- SHA1.html, `oneBlock` function) Granted, this library is pretty much dead (last update in 2012), but it's a bit suspect that code suddenly stops working in the (almost) worst way possible. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 01:44:31 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 01:44:31 -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.9409b484dabec05005bf25c03d6a593a@haskell.org> #16221: Core Lint error with a data type -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | polykinds/T16221,T16221a Blocked By: | Blocking: Related Tickets: #16342 | Differential Rev(s): | https://gitlab.haskell.org/ghc/ghc/merge_requests/444, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/499 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"07f378cee37338c5f2655b3a7e46dfef3f1c5cc1/ghc" 07f378ce/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="07f378cee37338c5f2655b3a7e46dfef3f1c5cc1" Add tests for Trac #16221 and #16342 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 01:44:31 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 01:44:31 -0000 Subject: [GHC] #16342: Kind inference crash In-Reply-To: <046.eae912a23f2090497b4d3634101a1dd3@haskell.org> References: <046.eae912a23f2090497b4d3634101a1dd3@haskell.org> Message-ID: <061.6273cd3fe68959e23f2e4f59241cd504@haskell.org> #16342: Kind inference crash -------------------------------------+------------------------------------- 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: #16221 | Differential Rev(s): | https://gitlab.haskell.org/ghc/ghc/merge_requests/444, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/499 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"07f378cee37338c5f2655b3a7e46dfef3f1c5cc1/ghc" 07f378ce/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="07f378cee37338c5f2655b3a7e46dfef3f1c5cc1" Add tests for Trac #16221 and #16342 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 01:44:31 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 01:44:31 -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.2a1edb36f73f81b8f5782df7cffe9eb9@haskell.org> #16263: Rework GHC's treatment of constraints in kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: fixed | Keywords: TypeInType, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T16263 Blocked By: | Blocking: Related Tickets: #12102, #15872 | Differential Rev(s): | https://gitlab.haskell.org/ghc/ghc/merge_requests/128, Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/499 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"25c3dd39f7d446f66b5c967be81f80cd7facb509/ghc" 25c3dd3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="25c3dd39f7d446f66b5c967be81f80cd7facb509" Test Trac #16263 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 01:44:31 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 01:44:31 -0000 Subject: [GHC] #16392: In ghci, revertCAFs should be executed in the external interpreter when necessary In-Reply-To: <045.92444231bf9792c99a9e6f96a7aa684c@haskell.org> References: <045.92444231bf9792c99a9e6f96a7aa684c@haskell.org> Message-ID: <060.a207657ed5b2d87f43b1a58fbe0aa1e2@haskell.org> #16392: In ghci, revertCAFs should be executed in the external interpreter when necessary -------------------------------------+------------------------------------- Reporter: lolotp | Owner: lolotp Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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/500 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"7a68254a7284db5bf8f1fa82aba4a6825d8f050a/ghc" 7a68254a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7a68254a7284db5bf8f1fa82aba4a6825d8f050a" Fix #16392: revertCAFs in external interpreter when necessary We revert CAFs when loading/adding modules in ghci (presumably to refresh execution states and to allow for object code to be unloaded from the runtime). However, with `-fexternal-interpreter` enabled, we are only doing it in the ghci process instead of the external interpreter process where the cafs are allocated and computed. This makes sure that revertCAFs is done in the appropriate process no matter if that flag is present or not. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 01:44:31 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 01:44:31 -0000 Subject: [GHC] #16391: "Quantified type's kind mentions quantified type variable" error with fancy-kinded GADT In-Reply-To: <050.e07e7af69cce8e666cdbeacaf56a9da6@haskell.org> References: <050.e07e7af69cce8e666cdbeacaf56a9da6@haskell.org> Message-ID: <065.2404071ab32a9a9fb5f65d8057ca9862@haskell.org> #16391: "Quantified type's kind mentions quantified type variable" error with fancy-kinded GADT -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | dependent/should_compile/T16391a, | dependent/should_fail/T16391b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://gitlab.haskell.org/ghc/ghc/merge_requests/503 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"068b7e983f4a0b35f453aa5e609998efd0c3f334/ghc" 068b7e98/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="068b7e983f4a0b35f453aa5e609998efd0c3f334" Fix #16391 by using occCheckExpand in TcValidity The type-variables-escaping-their-scope-via-kinds check in `TcValidity` was failing to properly expand type synonyms, which led to #16391. This is easily fixed by using `occCheckExpand` before performing the validity check. Along the way, I refactored this check out into its own function, and sprinkled references to Notes to better explain all of the moving parts. Many thanks to @simonpj for the suggestions. Bumps the haddock submodule. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 01:44:57 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 01:44:57 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2315913=3A_ghc-8=2E6=2E2_fails_to_bui?= =?utf-8?q?ld_on_s390x_=28unregisterised=29=3A_=E2=80=98stg=5FMUT?= =?utf-8?b?X0FSUl9QVFJTX0ZST1pFTjBfaW5mb+KAmSB1bmRlY2xhcmVkIChm?= =?utf-8?q?irst_use_in_this_function=29=3B_did_you_mean_=E2=80=98?= =?utf-8?b?c3RnX01VVF9BUlJfUFRSU19GUk9aRU5fRElSVFlfaW5mb+KAmT8=?= In-Reply-To: <050.5c8d8e19b2fece59f8d8381f971f9a5b@haskell.org> References: <050.5c8d8e19b2fece59f8d8381f971f9a5b@haskell.org> Message-ID: <065.b1ed5af93633f5976f0e73db21569a7b@haskell.org> #15913: ghc-8.6.2 fails to build on s390x (unregisterised): ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.2 (make) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by juhpetersen): * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 01:45:23 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 01:45:23 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2315913=3A_ghc-8=2E6=2E2_fails_to_bui?= =?utf-8?q?ld_on_s390x_=28unregisterised=29=3A_=E2=80=98stg=5FMUT?= =?utf-8?b?X0FSUl9QVFJTX0ZST1pFTjBfaW5mb+KAmSB1bmRlY2xhcmVkIChm?= =?utf-8?q?irst_use_in_this_function=29=3B_did_you_mean_=E2=80=98?= =?utf-8?b?c3RnX01VVF9BUlJfUFRSU19GUk9aRU5fRElSVFlfaW5mb+KAmT8=?= In-Reply-To: <050.5c8d8e19b2fece59f8d8381f971f9a5b@haskell.org> References: <050.5c8d8e19b2fece59f8d8381f971f9a5b@haskell.org> Message-ID: <065.ab8b69c2fb41696cf8e061a52e2f5c49@haskell.org> #15913: ghc-8.6.2 fails to build on s390x (unregisterised): ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.6.3 (make) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by juhpetersen): * version: 8.6.2 => 8.6.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 04:46:25 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 04:46:25 -0000 Subject: [GHC] #16378: bkpcabal01 fails with recent Cabal In-Reply-To: <046.6dbe508947082fe98f8d1db57ed7604b@haskell.org> References: <046.6dbe508947082fe98f8d1db57ed7604b@haskell.org> Message-ID: <061.d24eac09ccb7459ddd2aee30dbffa0f3@haskell.org> #16378: bkpcabal01 fails with recent Cabal -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new 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: | -------------------------------------+------------------------------------- Comment (by ezyang): bkpcabal01 test is wrong. Detailed explanation and patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 04:53:58 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 04:53:58 -0000 Subject: [GHC] #16378: bkpcabal01 fails with recent Cabal In-Reply-To: <046.6dbe508947082fe98f8d1db57ed7604b@haskell.org> References: <046.6dbe508947082fe98f8d1db57ed7604b@haskell.org> Message-ID: <061.061fda792b18cd8be1dbb34614eaed2e@haskell.org> #16378: bkpcabal01 fails with recent Cabal -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch 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/512 -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/512 Comment: I don't currently have a working ghc build (my checkout is borked) but I'll try to test it locally tomorrow. Give it a try. https://gitlab.haskell.org/ghc/ghc/merge_requests/512 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 07:45:44 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 07:45:44 -0000 Subject: [GHC] #16406: Array code works with GHC 8.4.4, hangs with GHC 8.6.4 In-Reply-To: <047.c6717f5d6f549f0b63ee9f534201a281@haskell.org> References: <047.c6717f5d6f549f0b63ee9f534201a281@haskell.org> Message-ID: <062.abae54a35788aa180374c7f1cef9a8f0@haskell.org> #16406: Array code works with GHC 8.4.4, hangs with GHC 8.6.4 -------------------------------------+------------------------------------- Reporter: arybczak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.6.4 (other) | Resolution: | Keywords: array Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by fredrikcarlen): Behaviour confirmed on macOS v10.14.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 08:26:39 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 08:26:39 -0000 Subject: [GHC] #16406: Array code works with GHC 8.4.4, hangs with GHC 8.6.4 In-Reply-To: <047.c6717f5d6f549f0b63ee9f534201a281@haskell.org> References: <047.c6717f5d6f549f0b63ee9f534201a281@haskell.org> Message-ID: <062.7f5d741f0141fa2f757ecf8bb772d076@haskell.org> #16406: Array code works with GHC 8.4.4, hangs with GHC 8.6.4 -------------------------------------+------------------------------------- Reporter: arybczak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.6.4 (other) | Resolution: | Keywords: array Operating System: 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): Confirmed on GHC HEAD on Linux. It fails with `<>` exception when compiled. Some commits that may be relevant: - "Harden fixST" 5a49651f3161473b383ec497af38e9daa022b9ac - "Index arrays more eagerly" e7678d6a0607013749e9ba4d88df949ad1192765 I think this is the commit that broke this example: - "Make accumArray and accum stricter" 08345bd0e8d237ec3929aaee7613c4f76e07e131 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 08:26:51 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 08:26:51 -0000 Subject: [GHC] #16406: Array code works with GHC 8.4.4, hangs with GHC 8.6.4 In-Reply-To: <047.c6717f5d6f549f0b63ee9f534201a281@haskell.org> References: <047.c6717f5d6f549f0b63ee9f534201a281@haskell.org> Message-ID: <062.6d536a010dc0d87b6d9427080926c478@haskell.org> #16406: Array code works with GHC 8.4.4, hangs with GHC 8.6.4 -------------------------------------+------------------------------------- Reporter: arybczak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.6.4 (other) | Resolution: | Keywords: array Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 08:59:07 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 08:59:07 -0000 Subject: [GHC] #16406: Array code works with GHC 8.4.4, hangs with GHC 8.6.4 In-Reply-To: <047.c6717f5d6f549f0b63ee9f534201a281@haskell.org> References: <047.c6717f5d6f549f0b63ee9f534201a281@haskell.org> Message-ID: <062.7bfe9e47180c8da64a6986308afcc083@haskell.org> #16406: Array code works with GHC 8.4.4, hangs with GHC 8.6.4 -------------------------------------+------------------------------------- Reporter: arybczak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.6.4 (other) | Resolution: | Keywords: array Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That's bad. We should not be changing Haskell's semantics, unless the library was somehow exploiting an undocumented (or perhaps even wrong) corner of the semantics. Worth investigating! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 09:23:38 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 09:23:38 -0000 Subject: [GHC] #16407: Non-versioned haddock.exe is not part of the Windows bindist tarball Message-ID: <049.d586b38b96ef0c2c2866f7589880a9e2@haskell.org> #16407: Non-versioned haddock.exe is not part of the Windows bindist tarball ----------------------------------------+--------------------------------- Reporter: cocreature | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.6.4 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 GHC 8.6.3 Windows bindist tarball contained both `ghc-8.6.3/bin/haddock-8.6.3.exe` as well as `ghc-8.6.4/bin/haddock.exe`. However, the 8.6.4 tarball only contains the executable with a version suffix `ghc-8.6.4/bin/haddock-8.6.4.exe`. This broke some users, e.g., the Shake CI https://ci.appveyor.com/project/ndmitchell/shake/builds/22909548#L971 but also `rules_haskell` which assume the existence of that executable. Assuming this change was not intentional, it would be great if we could get a bindist that contains the unversioned haddock.exe. Not sure if this is related to #16398. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 09:25:22 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 09:25:22 -0000 Subject: [GHC] #16407: Non-versioned haddock.exe is not part of the Windows bindist tarball In-Reply-To: <049.d586b38b96ef0c2c2866f7589880a9e2@haskell.org> References: <049.d586b38b96ef0c2c2866f7589880a9e2@haskell.org> Message-ID: <064.578e06dfdac6b0839c4d1de0e9df9989@haskell.org> #16407: Non-versioned haddock.exe is not part of the Windows bindist tarball ---------------------------------+---------------------------------------- Reporter: cocreature | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.6.4 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 NeilMitchell): * cc: NeilMitchell (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 10:07:45 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 10:07:45 -0000 Subject: [GHC] #16365: Inconsistency in quantified constraint solving In-Reply-To: <050.a379a836df5c0074c7f647d7d8a8a117@haskell.org> References: <050.a379a836df5c0074c7f647d7d8a8a117@haskell.org> Message-ID: <065.b21ace2fe59aedfc2afa906dfb3a5177@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 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): In `works3` we get {{{ [G] forall z. CF a z -- From the type signature [W] forall z. CF a z -- from the call of works1 }}} We can solve this no problem. And we also get {{{ [G] CF a b -- From the pattern match on Dict Dict <- works1 p [W] C (F a b) -- From the call of Dict on the RHS of works3 }}} Now `C (F a b)` is a superclass of `CF a b`, so we get {{{ [G] C (F a b) -- Via superclass expansion [W] C (F a b) -- From the call of Dict on the RHS of works3 }}} We can solve this without difficulty. --------------- However, in `fails` we get this: {{{ [G] forall z. CF a z -- From the type signature on fails [W] C (F a b) }}} From superclass expansion we get {{{ [G] forall z. C (F a z) -- From superclass expansion [W] C (F a b) }}} And now we are stuck. What `z` would make `C (F a z)` match `C (F a b)`? Well, yes, `b` would, but maybe also lots of other things. GHC simply doesn't support matching involving type families. So, as it stands, this looks reasonable. And I don't see an easy way to improve matters. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 10:12:15 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 10:12:15 -0000 Subject: [GHC] #16374: Cannot deduce constraint from itself with poly-kinded type family In-Reply-To: <045.9902b332efcda928f7c92c9ed54e9ea9@haskell.org> References: <045.9902b332efcda928f7c92c9ed54e9ea9@haskell.org> Message-ID: <060.1be67e331d243c24d8b727bc02c33f45@haskell.org> #16374: Cannot deduce constraint from itself with poly-kinded type family -------------------------------------+------------------------------------- Reporter: roland | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.3 checker) | Keywords: Resolution: | TypeErrorMessages Operating System: 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: => TypeErrorMessages Comment: > It might be helpful to have GHC automatically enable -fprint-explicit- kinds is an ambiguous type variable occurs in a kind position, such as in this program. I totally agree. Would anyone like to do this? There are a number of other [wiki:Status/TypeErrorMessages tickets about improving type error messages] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 10:32:23 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 10:32:23 -0000 Subject: [GHC] #16365: Inconsistency in quantified constraint solving In-Reply-To: <050.a379a836df5c0074c7f647d7d8a8a117@haskell.org> References: <050.a379a836df5c0074c7f647d7d8a8a117@haskell.org> Message-ID: <065.a8ed5256d73324b1630dde8eacc46bdd@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 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm still not convinced. You say: Replying to [comment:3 simonpj]: > From superclass expansion we get > {{{ > [G] forall z. C (F a z) -- From superclass expansion > [W] C (F a b) > }}} > And now we are stuck. What `z` would make `C (F a z)` match `C (F a b)`? Well, yes, `b` would, but maybe also lots of other things. GHC simply doesn't support matching involving type families. I don't really see why `F` being a type family has anything to do with this. Recall the definition of `F`: {{{#!hs type family F a :: Type -> Type }}} Note that `F`'s second argument is //matchable//. This means that given an equality between `F`s, we can easily decompose it into their second type arguments, as demonstrated by the fact that this function typechecks: {{{#!hs f :: Proxy a -> F a b :~: F a c -> b :~: c f _ Refl = Refl }}} Now recall what things we are trying to solve: {{{ [G] forall z. C (F a z) -- From superclass expansion [W] C (F a b) }}} These two constraints only differ in their second argument. But as we just established above, `F` is matchable in its second argument. Therefore, GHC should have no trouble concluding that `z` equals `b`. In other words, `b` is the only sensible choice here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 10:55:55 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 10:55:55 -0000 Subject: [GHC] #16365: Inconsistency in quantified constraint solving In-Reply-To: <050.a379a836df5c0074c7f647d7d8a8a117@haskell.org> References: <050.a379a836df5c0074c7f647d7d8a8a117@haskell.org> Message-ID: <065.9a7706895eeb363b08251e3793402bfa@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 Resolution: | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah! I had not focused on the fact that `F` only has arity 1. Good point. Avoiding the issues of superclasses for now, this fails: {{{ fails2 :: (forall z. C (F a z)) => Proxy (a, b) -> Dict (C (F a b)) fails2 _ = Dict }}} saying (quite helpfully) {{{ T16365.hs:37:11: error: • Illegal type synonym family application ‘F a’ in instance: C (F a z) • In the quantified constraint ‘forall z. C (F a z)’ In the type signature: fails2 :: (forall z. C (F a z)) => Proxy (a, b) -> Dict (C (F a b)) | 37 | fails2 :: (forall z. C (F a z)) => Proxy (a, b) -> Dict (C (F a b)) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} You sneak around that by hiding it under a superclass. I'm not sure how to stop you doing that :-). But this succeeds: {{{ fails3 :: (F a ~ fa, forall z. C (fa z)) => Proxy (a, b) -> Dict (C (F a b)) fails3 _ = Dict }}} Alas, I don't see how to use the same trick for `CF`, with its superclass. In other tickets we have wondered if this kind of floating could happen automatically. I argued "no" because it's subtle and you can do it manually. But with your superclass thing you can't do it manually (I thihik. So maybe that's an argument in favour. Hmm. Maybe we could elaboarate the matching process. Usually we match {{{ template: forall a b. [a] -> b target: [(Int,Bool)] -> Char }}} and produce a substitution {{{ a :-> (Int,Bool) b :-> Char }}} such that applying the substitution to the template yields the target. But we could instead additionally produce a list of wanted equalities, and treat a type-family application as a wildcard, something like this: {{{ template: forall a. F a -> a -> Int target: Char -> [Bool] -> Int }}} then we succeed in matching, thus: {{{ Substitution: a :-> Int Wanted equalities: F a ~ [Bool] }}} I don't think this would be terribly useful at top level, but in these quantified constraints it really might be. Interesting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 12:14:45 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 12:14:45 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.f2612c6086d66835fe69664a9712a788@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 mwu): The observation about stack behavior is interesting, I was curious to what degree it affects our builds. I have built and tested the stack's fork with binary interface support (many thanks to hussein.aitlahcen!) on our codebase ([https://github.com/luna/luna]). I have observed visible improvements both in build time (32 min vs 39 min) and memory usage (peaking at 12.3 GB instead of 14.2 GB) — however it is still very slow. With `-fomit-interface-pragmas` everything builds in little over 4 minutes but the binary performance is much worse. So I'm afraid GHC-side solution still remains very much needed. Is there still a chance that the fix will land in GHC 8.8? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 12:44:15 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 12:44:15 -0000 Subject: [GHC] #16389: T16190 fails on Windows In-Reply-To: <046.d5077b2a45b5901405da0c7bcdf7c6eb@haskell.org> References: <046.d5077b2a45b5901405da0c7bcdf7c6eb@haskell.org> Message-ID: <061.40a36104fd988111f367bbf3d8c267f8@haskell.org> #16389: T16190 fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: hsyl20 Type: bug | Status: new Priority: highest | Milestone: 8.10.1 Component: Compiler (NCG) | Version: 8.6.3 Resolution: | Keywords: broken-test 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: | -------------------------------------+------------------------------------- Changes (by hsyl20): * owner: (none) => hsyl20 * failure: None/Unknown => Compile-time crash or panic * component: Compiler => Compiler (NCG) * priority: normal => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 13:52:59 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 13:52:59 -0000 Subject: [GHC] #16376: GHCi HEAD silently accepts ill-kinded visible type applications with :type In-Reply-To: <050.2844026e72998c0da21d307d0ec6cfc6@haskell.org> References: <050.2844026e72998c0da21d307d0ec6cfc6@haskell.org> Message-ID: <065.9e02821b0755bf8d141e9cc3e99a5d0d@haskell.org> #16376: GHCi HEAD silently accepts ill-kinded visible type applications with :type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.10.1 Component: GHCi | Version: 8.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | ghci/scripts/T16376 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => ghci/scripts/T16376 * resolution: => fixed * milestone: => 8.10.1 Comment: Fixed in [https://gitlab.haskell.org/ghc/ghc/commit/5be7ad7861c8d39f60b7101fd8d8e816ff50353a 5be7ad78]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 14:32:06 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 14:32:06 -0000 Subject: [GHC] #16408: incomplete ghc-8.6.4 windows binary tarball Message-ID: <045.9cb735e21c123b47058e9636be84f031@haskell.org> #16408: incomplete ghc-8.6.4 windows binary tarball -------------------------------------+------------------------------------- Reporter: ruomad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.6.4 (other) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- the tarball for windows binaries does not include profiling version for core libraries, which leads to this cryptic error "base must match >=4.7 && <5, but the stack configuration has no specified version (latest matching version is 4.12.0.0)" Also, haddock fails because there is no haddock.exe, only haddock-8.6.4.exe -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 14:36:56 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 14:36:56 -0000 Subject: [GHC] #16406: Array code works with GHC 8.4.4, hangs with GHC 8.6.4 In-Reply-To: <047.c6717f5d6f549f0b63ee9f534201a281@haskell.org> References: <047.c6717f5d6f549f0b63ee9f534201a281@haskell.org> Message-ID: <062.e9fff7f4981ecaa9019b06267107ec8e@haskell.org> #16406: Array code works with GHC 8.4.4, hangs with GHC 8.6.4 -------------------------------------+------------------------------------- Reporter: arybczak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.6.4 (other) | Resolution: | Keywords: array Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): That was an intentional change. As I recall: Haskell 98's reference implementation didn't match its spec. We followed the Result: `accumArray` was terribly inefficient. Is there real code in the wild that makes use of its former laziness? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 14:41:45 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 14:41:45 -0000 Subject: [GHC] #16406: Array code works with GHC 8.4.4, hangs with GHC 8.6.4 In-Reply-To: <047.c6717f5d6f549f0b63ee9f534201a281@haskell.org> References: <047.c6717f5d6f549f0b63ee9f534201a281@haskell.org> Message-ID: <062.384135540a51d3685f9af07b8c065f14@haskell.org> #16406: Array code works with GHC 8.4.4, hangs with GHC 8.6.4 -------------------------------------+------------------------------------- Reporter: arybczak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.6.4 (other) | Resolution: | Keywords: array Operating System: 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): dfeuer, the code at the top of this ticket ties a knot and is from the Crypto library. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 14:45:17 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 14:45:17 -0000 Subject: [GHC] #16406: Array code works with GHC 8.4.4, hangs with GHC 8.6.4 In-Reply-To: <047.c6717f5d6f549f0b63ee9f534201a281@haskell.org> References: <047.c6717f5d6f549f0b63ee9f534201a281@haskell.org> Message-ID: <062.1a79d7910fb48565c115e5434c294a35@haskell.org> #16406: Array code works with GHC 8.4.4, hangs with GHC 8.6.4 -------------------------------------+------------------------------------- Reporter: arybczak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.6.4 (other) | Resolution: | Keywords: array Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Ah, missed that. I tend think it's better to fix the crypto library. Make it use conversion from a list. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 14:45:33 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 14:45:33 -0000 Subject: [GHC] #16406: Array code works with GHC 8.4.4, hangs with GHC 8.6.4 In-Reply-To: <047.c6717f5d6f549f0b63ee9f534201a281@haskell.org> References: <047.c6717f5d6f549f0b63ee9f534201a281@haskell.org> Message-ID: <062.0ead9587450c6e86ed4218459673cd2f@haskell.org> #16406: Array code works with GHC 8.4.4, hangs with GHC 8.6.4 -------------------------------------+------------------------------------- Reporter: arybczak | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.6.4 (other) | Resolution: | Keywords: array Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The report has this to say about accumArray: > If the accumulating function is strict, then accumArray is strict in the values, as well as the indices, in the association list. Thus, unlike ordinary arrays built with array, accumulated arrays should not in general be recursive. It does sound like we are within our rights to be strict here. However, perhaps we should document this strictness a bit better -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 14:51:21 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 14:51:21 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2315913=3A_ghc-8=2E6=2E2_fails_to_bui?= =?utf-8?q?ld_on_s390x_=28unregisterised=29=3A_=E2=80=98stg=5FMUT?= =?utf-8?b?X0FSUl9QVFJTX0ZST1pFTjBfaW5mb+KAmSB1bmRlY2xhcmVkIChm?= =?utf-8?q?irst_use_in_this_function=29=3B_did_you_mean_=E2=80=98?= =?utf-8?b?c3RnX01VVF9BUlJfUFRSU19GUk9aRU5fRElSVFlfaW5mb+KAmT8=?= In-Reply-To: <050.5c8d8e19b2fece59f8d8381f971f9a5b@haskell.org> References: <050.5c8d8e19b2fece59f8d8381f971f9a5b@haskell.org> Message-ID: <065.a1f039def57cee7035e498443a5bf462@haskell.org> #15913: ghc-8.6.2 fails to build on s390x (unregisterised): ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.6.3 (make) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high Comment: We should really get to the bottom of this header file issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 14:58:04 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 14:58:04 -0000 Subject: [GHC] #16408: incomplete ghc-8.6.4 windows binary tarball In-Reply-To: <045.9cb735e21c123b47058e9636be84f031@haskell.org> References: <045.9cb735e21c123b47058e9636be84f031@haskell.org> Message-ID: <060.977eb8e3dffe3885eeb9000831a324fb@haskell.org> #16408: incomplete ghc-8.6.4 windows binary tarball -------------------------------------+------------------------------------- Reporter: ruomad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 8.6.4 (other) | Resolution: | Keywords: Operating System: 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): Thank you for reporting this. This is quite bad. I'll take a look right now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 15:07:57 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 15:07:57 -0000 Subject: [GHC] #16389: T16190 fails on Windows In-Reply-To: <046.d5077b2a45b5901405da0c7bcdf7c6eb@haskell.org> References: <046.d5077b2a45b5901405da0c7bcdf7c6eb@haskell.org> Message-ID: <061.aeb23f4bfe602787590c14d529474ba8@haskell.org> #16389: T16190 fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: hsyl20 Type: bug | Status: new Priority: highest | Milestone: 8.10.1 Component: Compiler (NCG) | Version: 8.6.3 Resolution: | Keywords: broken-test 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/515 -------------------------------------+------------------------------------- Changes (by hsyl20): * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/515 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 15:33:23 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 15:33:23 -0000 Subject: [GHC] #9832: Get rid of PERL dependency of `ghc-split` In-Reply-To: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> References: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> Message-ID: <057.88b99b3db747a40b49720a4692260f31@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: dobenour Type: task | Status: closed Priority: normal | Milestone: 8.10.1 Component: Driver | Version: Resolution: fixed | Keywords: perl Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): Phab:D2768 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: 8.8.1 => 8.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 15:34:00 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 15:34:00 -0000 Subject: [GHC] #11315: GHC doesn't restore split objects In-Reply-To: <050.3912eec305e6bc9feb185ccfad42de4c@haskell.org> References: <050.3912eec305e6bc9feb185ccfad42de4c@haskell.org> Message-ID: <065.8f9a43fe98547a4d5c0842f1a9c3337a@haskell.org> #11315: GHC doesn't restore split objects -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 15:34:17 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 15:34:17 -0000 Subject: [GHC] #8964: split_marker_entry assert breaks -split-objs and -ddump-opt-cmm In-Reply-To: <045.a507fc91c5f6f7ecd651faf4aa4b1d22@haskell.org> References: <045.a507fc91c5f6f7ecd651faf4aa4b1d22@haskell.org> Message-ID: <060.7fd3df5c789c4e2908addf5aa9b209dd@haskell.org> #8964: split_marker_entry assert breaks -split-objs and -ddump-opt-cmm -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: closed Priority: lowest | Milestone: 8.10.1 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: ⊥ => 8.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 15:34:32 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 15:34:32 -0000 Subject: [GHC] #8685: -split-objs doesn't work for executables In-Reply-To: <045.94465e8e883e56c8348459fd1c8e42a7@haskell.org> References: <045.94465e8e883e56c8348459fd1c8e42a7@haskell.org> Message-ID: <060.9aae61d4110157d3768c129da4f4350b@haskell.org> #8685: -split-objs doesn't work for executables -------------------------------------+------------------------------------- Reporter: refold | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.10.1 Component: Driver | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 15:35:08 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 15:35:08 -0000 Subject: [GHC] #8629: Option 'split-objs' being ignored when trying to reduce object code size in iOS cross-compilation In-Reply-To: <051.7f175708aaf58854c5eeaa60c17f6275@haskell.org> References: <051.7f175708aaf58854c5eeaa60c17f6275@haskell.org> Message-ID: <066.64df30a77d5b8754ac25c41c82329031@haskell.org> #8629: Option 'split-objs' being ignored when trying to reduce object code size in iOS cross-compilation ---------------------------------+---------------------------------------- Reporter: f1rstmistake | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: ios Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 8300 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.10.1 Comment: `-split-objs` has been removed in favor of `-split-sections`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 15:35:25 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 15:35:25 -0000 Subject: [GHC] #8685: -split-objs doesn't work for executables In-Reply-To: <045.94465e8e883e56c8348459fd1c8e42a7@haskell.org> References: <045.94465e8e883e56c8348459fd1c8e42a7@haskell.org> Message-ID: <060.0c1e78fac9e695ef9d7fe79591cf073d@haskell.org> #8685: -split-objs doesn't work for executables -------------------------------------+------------------------------------- Reporter: refold | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.10.1 Component: Driver | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): `-split-objs` has been removed in favor of `-split-sections`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 15:35:42 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 15:35:42 -0000 Subject: [GHC] #8964: split_marker_entry assert breaks -split-objs and -ddump-opt-cmm In-Reply-To: <045.a507fc91c5f6f7ecd651faf4aa4b1d22@haskell.org> References: <045.a507fc91c5f6f7ecd651faf4aa4b1d22@haskell.org> Message-ID: <060.39258f62f1c2263f87eb8eba32bddc71@haskell.org> #8964: split_marker_entry assert breaks -split-objs and -ddump-opt-cmm -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: closed Priority: lowest | Milestone: 8.10.1 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): `-split-objs` has been removed in favor of `-split-sections`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 15:35:58 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 15:35:58 -0000 Subject: [GHC] #9832: Get rid of PERL dependency of `ghc-split` In-Reply-To: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> References: <042.a80d180822707ef08b1350d4a542cee3@haskell.org> Message-ID: <057.4e23f0cb825a728d2aff538d183874c1@haskell.org> #9832: Get rid of PERL dependency of `ghc-split` ---------------------------------+---------------------------------------- Reporter: hvr | Owner: dobenour Type: task | Status: closed Priority: normal | Milestone: 8.10.1 Component: Driver | Version: Resolution: fixed | Keywords: perl Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8405 | Differential Rev(s): Phab:D2768 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): `-split-objs` has been removed in favor of `-split-sections`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 15:36:05 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 15:36:05 -0000 Subject: [GHC] #11315: GHC doesn't restore split objects In-Reply-To: <050.3912eec305e6bc9feb185ccfad42de4c@haskell.org> References: <050.3912eec305e6bc9feb185ccfad42de4c@haskell.org> Message-ID: <065.5857501e5ee670b8b7cea9a94db492c8@haskell.org> #11315: GHC doesn't restore split objects -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): `-split-objs` has been removed in favor of `-split-sections`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 16:33:19 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 16:33:19 -0000 Subject: [GHC] #11441: RFC: Inline intermediate languages (Core, STG, Cmm, even StrictCore) In-Reply-To: <051.ccabecb7c53dcc1fcd24e4d67c3a2d24@haskell.org> References: <051.ccabecb7c53dcc1fcd24e4d67c3a2d24@haskell.org> Message-ID: <066.49ae9eed6ca5ffbcdca6b4a2bdc2a50f@haskell.org> #11441: RFC: Inline intermediate languages (Core, STG, Cmm, even StrictCore) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by recursion-ninja): I would find this capability extremely useful for writing optimized string alignment code that is still under the purview of the GHC memory manager instead of an FFI binding to C or C++ where the memory models are disjoint and sharing is much more difficult. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 16:50:11 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 16:50:11 -0000 Subject: [GHC] #16409: fresh install crashes Message-ID: <049.ee11eb1866ed5a206294f568163bbc4f@haskell.org> #16409: fresh install crashes -------------------------------------+------------------------------------- Reporter: eightorbit | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 8.6.3 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: -------------------------------------+------------------------------------- A fresh install on windows 10 enterprise using: HaskellPlatform-8.6.3-core-x86_64-setup.exe run as administrator crashes every time I try to start with this error (from powershell): {{{ PS C:\Users\rburgess> ghci -v GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help Glasgow Haskell Compiler, Version 8.6.3, stage 2 booted by GHC version 8.4.3 Using binary package database: C:\Program Files\Haskell Platform\8.6.3\lib\package.conf.d\package.cache package flags [] loading package database C:\Program Files\Haskell Platform\8.6.3\lib\package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.3 wired-in package integer-gmp mapped to integer-gmp-1.0.2.0 wired-in package base mapped to base-4.12.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.14.0.0 wired-in package ghc mapped to ghc-8.6.3 package flags [] loading package database C:\Program Files\Haskell Platform\8.6.3\lib\package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.3 wired-in package integer-gmp mapped to integer-gmp-1.0.2.0 wired-in package base mapped to base-4.12.0.0 wired-in package rts mapped to rts-1.0 wired-in package template-haskell mapped to template-haskell-2.14.0.0 wired-in package ghc mapped to ghc-8.6.3 *** Parser [source]: !!! Parser [source]: finished in 0.00 milliseconds, allocated 0.184 megabytes *** Desugar: *** Simplify [expr]: !!! Simplify [expr]: finished in 0.00 milliseconds, allocated 0.125 megabytes *** CorePrep [expr]: !!! CorePrep [expr]: finished in 0.00 milliseconds, allocated 1.860 megabytes *** ByteCodeGen [Ghci1]: !!! ByteCodeGen [Ghci1]: finished in 0.00 milliseconds, allocated 0.135 megabytes *** gcc: "C:\Program Files\Haskell Platform\8.6.3\lib\../mingw/bin/gcc.exe" "-fno- stack-protector" "-DTABLES_NEXT_TO_CODE" "--print-search-dirs" Loading package ghc-prim-0.5.3 ... linking ... ghc.exe: internal error: IMAGE_REL_AMD64_ADDR32[NB]: High bits are set in 1d6004c2659 for ghczmprim_GHCziTypes_ZMZN_closure (GHC version 8.6.3 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} =================================================================== Trying to run ghci and winghci also crashes, but no error. This is a company computer and I don't have admin rights, so I can't try and reinstall very easily. I seem to recall the installation trying to put something in the admin's local directory but we changed this to my local directory. I googled around and only found similar things with compiling. For fun I tried: {{{ PS C:\Users\rburgess> ghci -fexternal-interpreter GHCi, version 8.6.3: http://www.haskell.org/ghc/ :? for help ghc-iserv: internal error: IMAGE_REL_AMD64_ADDR32[NB]: High bits are set in 24d38172659 for ghczmprim_GHCziTypes_ZMZN_closure (GHC version 8.6.3 for x86_64_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Any help appreciated. It was hard enough to get this approved, I don't want to get some admin back unless a resolution is very likely. I use this as an argument to get them to let me run linux on my computer where I've never had a problem with ghci. :) But if I'm going to sell them on haskell, it would be nice to get it working locally. Let me know if you need other info or try non-admin things. Thanks! --rob -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 17:15:28 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 17:15:28 -0000 Subject: [GHC] #16409: fresh install crashes In-Reply-To: <049.ee11eb1866ed5a206294f568163bbc4f@haskell.org> References: <049.ee11eb1866ed5a206294f568163bbc4f@haskell.org> Message-ID: <064.28ef60b82efdc3a8a0afa5435ff76513@haskell.org> #16409: fresh install crashes -------------------------------------+------------------------------------- Reporter: eightorbit | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by eightorbit): * os: Unknown/Multiple => Windows * architecture: Unknown/Multiple => x86_64 (amd64) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 20:11:32 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 20:11:32 -0000 Subject: [GHC] #16410: Order of declarations matters Message-ID: <051.b4f1d0f744bb85adeac5e79a6937ac01@haskell.org> #16410: Order of declarations matters -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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: -------------------------------------+------------------------------------- This piece of code works. {{{#!hs {-# Language DataKinds #-} {-# Language GADTs #-} {-# Language InstanceSigs #-} {-# Language PolyKinds #-} {-# Language TypeFamilies #-} import Data.Kind class Category (tag::Type) where type Strip tag :: Type class Category tag => Stripped tag where type Hom tag::Strip tag -> Strip tag -> Type instance Category () where type Strip () = () instance Stripped () where type Hom () = Unit1 data Unit1 :: () -> () -> Type where U1 :: Unit1 '() '() data Tag data Unit2 :: () -> () -> Type where U2 :: Unit2 '() '() instance Category Tag where type Strip Tag = () instance Stripped Tag where type Hom Tag = Unit2 }}} Note that `Unit1` and `Unit2` are declared identically, separated by `data Tag`. The order is important. If we change the last line to `Hom Tag = Unit1` (same as `Hom ()`) we get {{{ $ ghc -ignore-dot-ghci 1152_bug.hs GHCi, version 8.7.20190115: https://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 1152_bug.hs, interpreted ) 1152_bug.hs:28:18: error: • Expected kind ‘Strip Tag -> Strip Tag -> *’, but ‘Unit1’ has kind ‘() -> () -> *’ • In the type ‘Unit1’ In the type instance declaration for ‘Hom’ In the instance declaration for ‘Stripped Tag’ | 28 | type Hom Tag = Unit1 | ^^^^^ Failed, no modules loaded. Prelude> }}} even though `Strip Tag` is defined to equal `()`. Here comes the weird part. If I move `Unit1` decl beneath `data Tag` {{{#!hs data Tag data Unit1 :: () -> () -> Type where U1 :: Unit1 '() '() data Unit2 :: () -> () -> Type where U2 :: Unit2 '() '() }}} then `type Hom Tag = Unit1` and `type Hom Tag = Unit2` both work well. If I move `Unit2` decl above `data Tag` then both `Hom Tag = Unit1` and `Hom Tag = Unit2` fail! {{{#!hs data Unit1 :: () -> () -> Type where U1 :: Unit1 '() '() data Unit2 :: () -> () -> Type where U2 :: Unit2 '() '() data Tag }}} If I replace all occurrences of `Tag` with `Bool` it succeeds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 20:40:32 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 20:40:32 -0000 Subject: [GHC] #16410: Order of declarations matters In-Reply-To: <051.b4f1d0f744bb85adeac5e79a6937ac01@haskell.org> References: <051.b4f1d0f744bb85adeac5e79a6937ac01@haskell.org> Message-ID: <066.03400b81eef7545dd6e4a9fa1c587661@haskell.org> #16410: Order of declarations matters -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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 int-index): My gut instinct is that this is another instance of #12088. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 21:00:12 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 21:00:12 -0000 Subject: [GHC] #16410: Order of declarations matters In-Reply-To: <051.b4f1d0f744bb85adeac5e79a6937ac01@haskell.org> References: <051.b4f1d0f744bb85adeac5e79a6937ac01@haskell.org> Message-ID: <066.2d8a67550dff6885170cc32e0ac43d1f@haskell.org> #16410: Order of declarations matters -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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 Iceland_jack): I get similar behavior for {{{#!hs {-# Language DataKinds #-} {-# Language GADTs #-} {-# Language PolyKinds #-} {-# Language TypeFamilyDependencies #-} {-# Language TypeOperators #-} {-# Language UndecidableInstances #-} import Data.Kind -- import Data.Type.Equality class Category (tag::Type) where type Strip (tag::Type) class Category tag => Stripped tag where type Hom tag = (res::Strip tag -> Strip tag -> Type) | res -> tag data REFL (k :: Type) :: Type data a :~: b where Refl :: a :~: a instance Category (REFL k) where type Strip (REFL k) = k instance Stripped (REFL k) where type Hom (REFL k) = (:~:) }}} This works. Moving `(:~:)` above `REFL` fails {{{ Type family equation violates injectivity annotation. Type variable ‘k’ cannot be inferred from the right-hand side. In the type family equation: Hom (REFL k) = (:~:) -- Defined at 1154_bug.hs:24:7 | 24 | type Hom (REFL k) = (:~:) | ^^^ Failed, no modules loaded. }}} Similarly removing the `(:~:)` declaration and importing it from `Data.Type.Equality` yields the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 21:58:30 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 21:58:30 -0000 Subject: [GHC] #16410: Order of declarations matters In-Reply-To: <051.b4f1d0f744bb85adeac5e79a6937ac01@haskell.org> References: <051.b4f1d0f744bb85adeac5e79a6937ac01@haskell.org> Message-ID: <066.02f79728da926c4bb32f21990192393c@haskell.org> #16410: Order of declarations matters -------------------------------------+------------------------------------- Reporter: Iceland_jack | 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 simonpj): > My gut instinct is that this is another instance of #12088. Mine too - but I have not investigated properly -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 8 23:53:43 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 08 Mar 2019 23:53:43 -0000 Subject: [GHC] #16410: Order of declarations matters In-Reply-To: <051.b4f1d0f744bb85adeac5e79a6937ac01@haskell.org> References: <051.b4f1d0f744bb85adeac5e79a6937ac01@haskell.org> Message-ID: <066.0cf4470ee5941711f182c60f70f2865e@haskell.org> #16410: Order of declarations matters -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12088 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #12088 Comment: Indeed, this is a duplicate of #12088. Note that the same workaround applies here: you can use a Template Haskell splice to force the dependency analysis to come to its senses. That is, the following typechecks (note the addition of the `$(pure [])` bit): {{{#!hs {-# Language DataKinds #-} {-# Language GADTs #-} {-# Language InstanceSigs #-} {-# Language PolyKinds #-} {-# Language TypeFamilies #-} {-# LANGUAGE TemplateHaskell #-} import Data.Kind class Category (tag::Type) where type Strip tag :: Type class Category tag => Stripped tag where type Hom tag::Strip tag -> Strip tag -> Type instance Category () where type Strip () = () instance Stripped () where type Hom () = Unit1 data Unit1 :: () -> () -> Type where U1 :: Unit1 '() '() data Tag data Unit2 :: () -> () -> Type where U2 :: Unit2 '() '() instance Category Tag where type Strip Tag = () $(pure []) instance Stripped Tag where type Hom Tag = Unit1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 9 00:00:45 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Mar 2019 00:00:45 -0000 Subject: [GHC] #16411: Inconsistent -Wpartial-fields warnings with (~) vs. (~~) Message-ID: <050.26b942379fc3a645b4402ebb6ca80467@haskell.org> #16411: Inconsistent -Wpartial-fields warnings with (~) vs. (~~) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.4 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: -------------------------------------+------------------------------------- In this program: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -Wpartial-fields #-} module Bug where import Data.Type.Equality data T1 z where MkT1a :: { rec1 :: () } -> T1 Int MkT1b :: (z ~ Bool) => T1 z data T2 z where MkT2a :: { rec2 :: () } -> T2 Int MkT2b :: (z ~~ Bool) => T2 z }}} I get no `-Wpartial-fields`–related warnings for `rec1`, but I do for `rec2`: {{{ GHCi, version 8.6.4: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:13:14: warning: [-Wpartial-fields] Use of partial record field selector: ‘rec2’ | 13 | MkT2a :: { rec2 :: () } -> T2 Int | ^^^^ }}} This feels strangely inconsistent, since if GHC doesn't warn for `rec1`, which uses `(~)`, then I feel like it shouldn't warn for `rec2` either, as the only difference is that the surrounding constructor uses a slightly different equality constraint `(~~)`. The reason this happens is because the `dataConCannotMatch` function has special reasoning for `(~)`, but not `(~~)`. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 9 00:05:31 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Mar 2019 00:05:31 -0000 Subject: [GHC] #16411: Inconsistent -Wpartial-fields warnings with (~) vs. (~~) In-Reply-To: <050.26b942379fc3a645b4402ebb6ca80467@haskell.org> References: <050.26b942379fc3a645b4402ebb6ca80467@haskell.org> Message-ID: <065.b3749692a39f97d2ca8489b0a8bc7b2e@haskell.org> #16411: Inconsistent -Wpartial-fields warnings with (~) vs. (~~) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.4 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: | https://gitlab.haskell.org/ghc/ghc/merge_requests/520 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => https://gitlab.haskell.org/ghc/ghc/merge_requests/520 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 9 02:52:01 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Mar 2019 02:52:01 -0000 Subject: [GHC] #16412: Type family signatures in indefinite modules Message-ID: <049.da2ae5ed91c8fd60520698c53e8a8da2@haskell.org> #16412: Type family signatures in indefinite modules -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.4 Keywords: backpack | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Backpack does not allow type family signatures in indefinite modules. As an example, although GHC does accept: {{{ -- indefinite module data Foo :: Bool -- implementing module type Foo = 'True }}} It does not accept: {{{ -- indefinite module type family Foo (b :: Bool) :: Bool -- implementing module type family Foo (b :: Bool) :: Bool where Foo 'True = 'False Foo 'False = 'True }}} I'm not sure if there is a fundamental reason for this (e.g. a requirement that everything is matchable). It would be helpful for the thing I'm experimenting with if this restriction could be lifted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 9 03:06:03 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Mar 2019 03:06:03 -0000 Subject: [GHC] #16413: GHC bindist with DWARF support seems much slower than non-DWARF Message-ID: <048.54a1f35c625b5a80fae818b322632834@haskell.org> #16413: GHC bindist with DWARF support seems much slower than non-DWARF -------------------------------------+------------------------------------- Reporter: jberryman | 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: -------------------------------------+------------------------------------- Comparing the DWARF and non-DWARF binary distributions, I'm seeing times for a `cabal new-build --disable-profiling --disable-library-profiling all` for a multi-library project showing e.g. 5:46.90 for DWARF, vs 3:56.40 for non-DWARF bindists. I'm assuming this is unexpected since I don't see it proclaimed loudly anywhere. I thought this was irrelevant, but I did try doing `cabal new-build ... --enable-debug-info=0` with the DWARF-supporting GHC but that didn't seem to improve compile time. I don't see anything relevant in my `~/.cabal/config`. Even more confused because I see the same slow timing (~ 5:45) for a `stack build` in the same project, yet it looks like `stack` pulls in a GHC without DWARF-compiled libs: {{{ $ readelf --debug-dump $HOME/.stack/programs/x86_64-linux/ghc-8.6.3/lib/ghc-8.6.3/text-1.2.3.1/libHStext-1.2.3.1-ghc8.6.3.so | grep Version $ }}} Maybe `stack` is compiling in a different way though, and the timing similarity is just a coincidence. I first noticed this when building GHC from source. It seemed that uncommenting these caused the regression (though I haven't double- checked): {{{ #GhcLibHcOpts += -g3 #GhcRtsHcOpts += -g3 }}} Attached is the project repo I tested with (again, with `cabal new-clean && cabal new-build --disable-profiling --disable-library-profiling all`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 9 03:28:11 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Mar 2019 03:28:11 -0000 Subject: [GHC] #16413: GHC bindist with DWARF support seems much slower than non-DWARF In-Reply-To: <048.54a1f35c625b5a80fae818b322632834@haskell.org> References: <048.54a1f35c625b5a80fae818b322632834@haskell.org> Message-ID: <063.cb54e2d12a2d63a87ec4da682592af5e@haskell.org> #16413: GHC bindist with DWARF support seems much slower than non-DWARF -------------------------------------+------------------------------------- Reporter: jberryman | 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 jberryman): Too big to attach. Here's the project dir : https://s3.amazonaws.com /jberryman-public/dwarf-repro.tar.gz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 9 03:54:44 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Mar 2019 03:54:44 -0000 Subject: [GHC] #16164: Provide bitreverse primop In-Reply-To: <047.f3aae0f1a192ff22dd51ddc4f1892d2e@haskell.org> References: <047.f3aae0f1a192ff22dd51ddc4f1892d2e@haskell.org> Message-ID: <062.fb5cdc9a246cb144d8924e79067d6ed0@haskell.org> #16164: Provide bitreverse primop -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 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 rockbmb): I've got a couple of questions: 1. Does the inexistence of such an operation in GCC mean such a primop would, at first, only be available when the compiler uses the LLVM backend? 2. From the [understanding](https://ghc.haskell.org/trac/ghc/wiki/Commentary/PrimOps#AddinganewPrimOp) I've been gathering, am I right to assume that this primop will be out-of- line? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 9 07:08:28 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Mar 2019 07:08:28 -0000 Subject: [GHC] #16325: Hadrian should respect the build root setting for the testsuite and its own binaries In-Reply-To: <050.da86ece9240730c7fd61c1e01f766897@haskell.org> References: <050.da86ece9240730c7fd61c1e01f766897@haskell.org> Message-ID: <065.feb57c04d77f4f7b1e560d6a998feb2e@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) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"5d7441432e4c00a463f645248b354707d7d8335e/ghc" 5d74414/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5d7441432e4c00a463f645248b354707d7d8335e" Hadrian: Drop remaining symlink traversal code from build scripts This partly resolves #16325 (https://ghc.haskell.org/trac/ghc/ticket/16325). As previously discussed in https://github.com/snowleopard/hadrian/issues/667, we do not need the symlink traversal code in build scripts. However, it appears we forgot to delete this code from our Stack-based build scripts, which led to placing all build artefacts in an unexpected location when using Hadrian in combination with symlink trees. This commit fixes this. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 9 07:08:28 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Mar 2019 07:08:28 -0000 Subject: [GHC] #10069: CPR related performance issue In-Reply-To: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> References: <044.df2160ed865e3cc2be2a2ba9ad4e0ac8@haskell.org> Message-ID: <059.3cd640b87200098f51ecaf5553a15b6a@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: | -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"1675d40afe07b9c414eaa37d85819f37f8420118/ghc" 1675d40a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1675d40afe07b9c414eaa37d85819f37f8420118" Always do the worker/wrapper split for NOINLINEs Trac #10069 revealed that small NOINLINE functions didn't get split into worker and wrapper. This was due to `certainlyWillInline` saying that any unfoldings with a guidance of `UnfWhen` inline unconditionally. That isn't the case for NOINLINE functions, so we catch this case earlier now. Nofib results: -------------------------------------------------------------------------------- Program Allocs Instrs -------------------------------------------------------------------------------- fannkuch-redux -0.3% 0.0% gg +0.0% +0.1% maillist -0.2% -0.2% minimax 0.0% -0.8% -------------------------------------------------------------------------------- Min -0.3% -0.8% Max +0.0% +0.1% Geometric Mean -0.0% -0.0% Fixes #10069. ------------------------- Metric Increase: T9233 ------------------------- }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 9 07:08:28 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Mar 2019 07:08:28 -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.fcc077f8306bb03f93721409698ffcff@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.6.4 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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"224a6b864c6aa0d851fcbf79469e5702b1116dbc/ghc" 224a6b86/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="224a6b864c6aa0d851fcbf79469e5702b1116dbc" TH: support raw bytes literals (#14741) GHC represents String literals as ByteString internally for efficiency reasons. However, until now it wasn't possible to efficiently create large string literals with TH (e.g. to embed a file in a binary, cf #14741): TH code had to unpack the bytes into a [Word8] that GHC then had to re- pack into a ByteString. This patch adds the possibility to efficiently create a "string" literal from raw bytes. We get the following compile times for different sizes of TH created literals: || Size || Before || After || Gain || || 30K || 2.307s || 2.299 || 0% || || 3M || 3.073s || 2.400s || 21% || || 30M || 8.517s || 3.390s || 60% || Ticket #14741 can be fixed if the original code uses this new TH feature. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 9 07:08:28 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Mar 2019 07:08:28 -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.aa35036cd2fb794efbf2c4cb8b595474@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 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"2762f94dc27cc065dded7755f99c66cba26683dd/ghc" 2762f94/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2762f94dc27cc065dded7755f99c66cba26683dd" Fix #13839: GHCi warnings do not respect the default module header }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 9 07:08:28 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Mar 2019 07:08:28 -0000 Subject: [GHC] #16376: GHCi HEAD silently accepts ill-kinded visible type applications with :type In-Reply-To: <050.2844026e72998c0da21d307d0ec6cfc6@haskell.org> References: <050.2844026e72998c0da21d307d0ec6cfc6@haskell.org> Message-ID: <065.61bc07a41eb82ef4c12116ffe16929ed@haskell.org> #16376: GHCi HEAD silently accepts ill-kinded visible type applications with :type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.10.1 Component: GHCi | Version: 8.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | ghci/scripts/T16376 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"5be7ad7861c8d39f60b7101fd8d8e816ff50353a/ghc" 5be7ad78/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5be7ad7861c8d39f60b7101fd8d8e816ff50353a" Use captureTopConstraints in TcRnDriver calls Trac #16376 showed the danger of failing to report an error that exists only in the unsolved constraints, if an exception is raised (via failM). Well, the commit 5c1f268e (Fail fast in solveLocalEqualities) did just that -- i.e. it found errors in the constraints, and called failM to avoid a misleading cascade. So we need to be sure to call captureTopConstraints to report those insolubles. This was wrong in TcRnDriver.tcRnExpr and in TcRnDriver.tcRnType. As a result the error messages from test T13466 improved slightly, a happy outcome. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 9 15:32:37 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Mar 2019 15:32:37 -0000 Subject: [GHC] #16413: GHC bindist with DWARF support seems much slower than non-DWARF In-Reply-To: <048.54a1f35c625b5a80fae818b322632834@haskell.org> References: <048.54a1f35c625b5a80fae818b322632834@haskell.org> Message-ID: <063.543b333534d17bef19a5cf23552a8041@haskell.org> #16413: GHC bindist with DWARF support seems much slower than non-DWARF -------------------------------------+------------------------------------- Reporter: jberryman | 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 bgamari): There are two possible reasons for this: 1. The source notes used to generate debug information hide some optimisation opportunities from the simplier. This is known to happen in a few cases, although this shouldn't cause anywhere near the sort of slowdown you observe. 2. The link resulting object files take longer to assemble and link. This is known to be the case; while binaries with debug information are generally larger than those without in any language, this effect is greatly exaggerated in Haskell. I have seen binaries produced by GHC with debug information which are ten times larger than their un-adorned counterparts. Producing all of these additional bytes of course costs time. The time effect of (2) very much depends upon which linker you are using. Can you paste the output from `ghc --info`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Mar 9 15:37:35 2019 From: ghc-devs at haskell.org (GHC) Date: Sat, 09 Mar 2019 15:37:35 -0000 Subject: [GHC] #16409: fresh install crashes In-Reply-To: <049.ee11eb1866ed5a206294f568163bbc4f@haskell.org> References: <049.ee11eb1866ed5a206294f568163bbc4f@haskell.org> Message-ID: <064.a6a25239ce35552527f0d331276fcbb1@haskell.org> #16409: fresh install crashes -------------------------------------+------------------------------------- Reporter: eightorbit | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 8.6.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This looks like a duplicate of #14576. I strongly suspect, although am not certain, that this was fixed in 8.6.4. You should be able to install this from the [[http://downloads.haskell.org/~ghc/8.6.4/|bare binary distribution]] without Administrator privileges (just extract the tarball into a directory and use `ghc` from there). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 10 14:31:16 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Mar 2019 14:31:16 -0000 Subject: [GHC] #16344: GHC infers over-polymorphic kinds In-Reply-To: <046.ba3f557688069cd52f4109e1cb268f64@haskell.org> References: <046.ba3f557688069cd52f4109e1cb268f64@haskell.org> Message-ID: <061.9d65ddd33a013544bde44da4e9be92ab@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 Marge Bot ): In [changeset:"1f5cc9dc8aeeafa439d6d12c3c4565ada524b926/ghc" 1f5cc9d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1f5cc9dc8aeeafa439d6d12c3c4565ada524b926" Stop inferring over-polymorphic kinds Before this patch GHC was trying to be too clever (Trac #16344); it succeeded in kind-checking this polymorphic-recursive declaration data T ka (a::ka) b = MkT (T Type Int Bool) (T (Type -> Type) Maybe Bool) As Note [No polymorphic recursion] discusses, the "solution" was horribly fragile. So this patch deletes the key lines in TcHsType, and a wodge of supporting stuff in the renamer. There were two regressions, both the same: a closed type family decl like this (T12785b) does not have a CUSK: type family Payload (n :: Peano) (s :: HTree n x) where Payload Z (Point a) = a Payload (S n) (a `Branch` stru) = a To kind-check the equations we need a dependent kind for Payload, and we don't get that any more. Solution: make it a CUSK by giving the result kind -- probably a good thing anyway. The other case (T12442) was very similar: a close type family declaration without a CUSK. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 10 14:31:16 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Mar 2019 14:31:16 -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.a753c0cd0bc331792349eb6598953478@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 Marge Bot ): In [changeset:"cfbedf1780002f4f76aa9c6c754818a436888e9f/ghc" cfbedf17/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cfbedf1780002f4f76aa9c6c754818a436888e9f" compiler: Write .o files atomically. See #14533 This issue was reproduced with, and the fix confirmed with, the `hatrace` tool for syscall-based fault injection: https://github.com/nh2/hatrace The concrete test case for GHC is at https://github.com/nh2/hatrace/blob/e23d35a2d2c79e8bf49e9e2266b3ff7094267f29/test/HatraceSpec.hs#L185 A previous, nondeterministic reproducer for the issue was provided by Alexey Kuleshevich in https://github.com/lehins/exec-kill-loop Signed-off-by: Niklas Hambüchen Reviewed-by: Alexey Kuleshevich }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Mar 10 14:31:16 2019 From: ghc-devs at haskell.org (GHC) Date: Sun, 10 Mar 2019 14:31:16 -0000 Subject: [GHC] #16389: T16190 fails on Windows In-Reply-To: <046.d5077b2a45b5901405da0c7bcdf7c6eb@haskell.org> References: <046.d5077b2a45b5901405da0c7bcdf7c6eb@haskell.org> Message-ID: <061.d338cc19fbfb127d44609761b9ba257a@haskell.org> #16389: T16190 fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: hsyl20 Type: bug | Status: new Priority: highest | Milestone: 8.10.1 Component: Compiler (NCG) | Version: 8.6.3 Resolution: | Keywords: broken-test 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/515 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"6b2f09916e0c8c5f37c9fbe08eb076476501c8d6/ghc" 6b2f099/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6b2f09916e0c8c5f37c9fbe08eb076476501c8d6" NCG: correctly escape path strings on Windows (#16389) GHC native code generator generates .incbin and .file directives. We need to escape those strings correctly on Windows (see #16389). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 11 08:39:04 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 11 Mar 2019 08:39:04 -0000 Subject: [GHC] #16344: GHC infers over-polymorphic kinds In-Reply-To: <046.ba3f557688069cd52f4109e1cb268f64@haskell.org> References: <046.ba3f557688069cd52f4109e1cb268f64@haskell.org> Message-ID: <061.cee1a09ac734ea93952851df9244e101@haskell.org> #16344: GHC infers over-polymorphic kinds -------------------------------------+------------------------------------- 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: | dependent/should_fail/T16344,T16344a, | should_compile/T16344b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => dependent/should_fail/T16344,T16344a, should_compile/T16344b * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 12 00:28:37 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Mar 2019 00:28:37 -0000 Subject: [GHC] #13951: InScope set assertion failure from monad-skeleton In-Reply-To: <049.5db03d032e7f17d002eb17274d5a81f3@haskell.org> References: <049.5db03d032e7f17d002eb17274d5a81f3@haskell.org> Message-ID: <064.ebc5c5a002e3a6bec5092d3e70625a0a@haskell.org> #13951: InScope set assertion failure from monad-skeleton -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"2f453414c5b1b27b6a84a3b5c7cd1bb5449f1f5d/ghc" 2f453414/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2f453414c5b1b27b6a84a3b5c7cd1bb5449f1f5d" Add a test for Trac #13951 It no longer gives a warning. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 12 00:28:36 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Mar 2019 00:28:36 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.e78aa4d04393e382459d83a6c450b6c6@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"60b03adea8cc55ff65fbf6458487c3baf12bb0a1/ghc" 60b03ade/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="60b03adea8cc55ff65fbf6458487c3baf12bb0a1" Change the warning in substTy back to an assertion We'd like to enforce the substitution invariant (Trac #11371). In a492af06d326453 the assertion was downgraded to a warning; I'm restoring the assertion and making the calls that don't maintain the invariant as unchecked. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Mar 12 14:59:19 2019 From: ghc-devs at haskell.org (GHC) Date: Tue, 12 Mar 2019 14:59:19 -0000 Subject: [GHC] #16347: GHC HEAD regression: piResultTys1 In-Reply-To: <050.5658c2f45fbb3a51a60e5b0dd63cbfb9@haskell.org> References: <050.5658c2f45fbb3a51a60e5b0dd63cbfb9@haskell.org> Message-ID: <065.216e95128d05493931e5a8ef9c32e2a2@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 Marge Bot ): In [changeset:"4db9bdd91549b4eada5324cd7452e7e74ada28f5/ghc" 4db9bdd9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4db9bdd91549b4eada5324cd7452e7e74ada28f5" Add regression test for #16347 Commit 1f5cc9dc8aeeafa439d6d12c3c4565ada524b926 ended up fixing #16347. Let's add a regression test to ensure that it stays fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 13 23:43:59 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Mar 2019 23:43:59 -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.bb3bb4fccf4daaf0760cf1573b108e5d@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: | -------------------------------------+----------------------------------- Comment (by Marge Bot ): In [changeset:"23fc615679072a6fa433460a92f597af2ae388b2/ghc" 23fc615/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="23fc615679072a6fa433460a92f597af2ae388b2" testsuite: Mark heapprof001 as fragile on all platforms See #15382. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Mar 13 23:43:59 2019 From: ghc-devs at haskell.org (GHC) Date: Wed, 13 Mar 2019 23:43:59 -0000 Subject: [GHC] #16411: Inconsistent -Wpartial-fields warnings with (~) vs. (~~) In-Reply-To: <050.26b942379fc3a645b4402ebb6ca80467@haskell.org> References: <050.26b942379fc3a645b4402ebb6ca80467@haskell.org> Message-ID: <065.8079f33866882ab6cbdc95a70a30c558@haskell.org> #16411: Inconsistent -Wpartial-fields warnings with (~) vs. (~~) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.4 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: | https://gitlab.haskell.org/ghc/ghc/merge_requests/520 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"36546a43e490ea6f989e6cad369d1a251c94a42b/ghc" 36546a4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="36546a43e490ea6f989e6cad369d1a251c94a42b" Fix #16411 by making dataConCannotMatch aware of (~~) The `dataConCannotMatch` function (which powers the `-Wpartial-fields` warning, among other things) had special reasoning for explicit equality constraints of the form `a ~ b`, but it did not extend that reasoning to `a ~~ b` constraints, leading to #16411. Easily fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 15 19:06:02 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Mar 2019 19:06:02 -0000 Subject: [GHC] #16394: GHC internal error while typechecking of instance definition In-Reply-To: <046.1aa3a5a103e1dd4c8fc51a808f32f1b2@haskell.org> References: <046.1aa3a5a103e1dd4c8fc51a808f32f1b2@haskell.org> Message-ID: <061.c631819124a32be87f2f89024a6af35b@haskell.org> #16394: GHC internal error while typechecking of instance definition -------------------------------------+------------------------------------- Reporter: Day1721 | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.6.3 checker) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: error/warning at compile-time | typecheck/should_fail/T16394 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): MR!496 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"10a971208dcd537742fe4e15b2713eb0f3052a3a/ghc" 10a97120/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="10a971208dcd537742fe4e15b2713eb0f3052a3a" testsuite: Add testcase for #16394 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 15 19:06:02 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Mar 2019 19:06:02 -0000 Subject: [GHC] #14828: panic! when using :print on some functions with class constraints? In-Reply-To: <042.277052228000c219ea7b7bc26108babf@haskell.org> References: <042.277052228000c219ea7b7bc26108babf@haskell.org> Message-ID: <057.afff54d72e77f57be7930f20df5eecdd@haskell.org> #14828: panic! when using :print on some functions with class constraints? -------------------------------------+------------------------------------- Reporter: jol | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Resolution: | Keywords: debugger Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"8162eab27101cddb0c822347300640f07110379a/ghc" 8162eab2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8162eab27101cddb0c822347300640f07110379a" Remove the GHCi debugger's panicking isUnliftedType check The GHCi debugger has never been that robust in the face of higher-rank types, or even types that are _interally_ higher-rank, such as the types of many class methods (e.g., `fmap`). In GHC 8.2, however, things became even worse, as the debugger would start to _panic_ when a user tries passing the name of a higher-rank thing to `:print`. This all ties back to a strange `isUnliftedType` check in `Debugger` that was mysteriously added 11 years ago (in commit 4d71f5ee6dbbfedb4a55767e4375f4c0aadf70bb) with no explanation whatsoever. After some experimentation, no one is quite sure what this `isUnliftedType` check is actually accomplishing. The test suite still passes if it's removed, and I am unable to observe any differences in debugger before even with data types that _do_ have fields of unlifted types (e.g., `data T = MkT Int#`). Given that this is actively causing problems (see #14828), the prudent thing to do seems to be just removing this `isUnliftedType` check, and waiting to see if anyone shouts about it. This patch accomplishes just that. Note that this patch fix the underlying issues behind #14828, as the debugger will still print unhelpful info if you try this: ``` λ> f :: (forall a. a -> a) -> b -> b; f g x = g x λ> :print f f = (_t1::t1) ``` But fixing this will require much more work, so let's start with the simple stuff for now. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Mar 15 19:06:02 2019 From: ghc-devs at haskell.org (GHC) Date: Fri, 15 Mar 2019 19:06:02 -0000 Subject: [GHC] #12770: Shrink list of RUNPATH entries for GHC libraries In-Reply-To: <045.bd5b05d08df9d175446cf54d30fac216@haskell.org> References: <045.bd5b05d08df9d175446cf54d30fac216@haskell.org> Message-ID: <060.3f314ac151fb99ca1a6cfa49145457f4@haskell.org> #12770: Shrink list of RUNPATH entries for GHC libraries -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"4df757729dab0a5be07f111843ed3ca9de6c3771/ghc" 4df7577/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4df757729dab0a5be07f111843ed3ca9de6c3771" Hadrian: remove unneeded rpaths. Issue #12770 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 18 11:30:33 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Mar 2019 11:30:33 -0000 Subject: [GHC] #15454: Have GHCi automatically use -fobject-code for modules that use UnboxedTuples In-Reply-To: <046.9b666c82251616f1d78d961f028abb97@haskell.org> References: <046.9b666c82251616f1d78d961f028abb97@haskell.org> Message-ID: <061.ad2ef76b1f2abcbfd88fb24dd8331753@haskell.org> #15454: Have GHCi automatically use -fobject-code for modules that use UnboxedTuples -------------------------------------+------------------------------------- Reporter: mgsloan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.10.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 Marge Bot ): In [changeset:"c01d5af31c8feb634fc3dffc84e6e7ece61ba190/ghc" c01d5af3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c01d5af31c8feb634fc3dffc84e6e7ece61ba190" Extract out use of UnboxedTuples from GHCi.Leak See #13101 + #15454 for motivation. This change reduces the number of modules that need to be compiled to object code when loading GHC into GHCi. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Mar 18 11:30:33 2019 From: ghc-devs at haskell.org (GHC) Date: Mon, 18 Mar 2019 11:30:33 -0000 Subject: [GHC] #13101: Enable GHC to be loaded into GHCi In-Reply-To: <046.89a8eaf8c834efef8f09f13b000a4227@haskell.org> References: <046.89a8eaf8c834efef8f09f13b000a4227@haskell.org> Message-ID: <061.e580dff7ef25d18c067139e826c34743@haskell.org> #13101: Enable GHC to be loaded into GHCi -------------------------------------+------------------------------------- Reporter: bgamari | 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: | -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"c01d5af31c8feb634fc3dffc84e6e7ece61ba190/ghc" c01d5af3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c01d5af31c8feb634fc3dffc84e6e7ece61ba190" Extract out use of UnboxedTuples from GHCi.Leak See #13101 + #15454 for motivation. This change reduces the number of modules that need to be compiled to object code when loading GHC into GHCi. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 21 16:59:51 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Mar 2019 16:59:51 -0000 Subject: [GHC] #16386: T16219 fails on Windows In-Reply-To: <046.254723c6029307e45222252a793b733d@haskell.org> References: <046.254723c6029307e45222252a793b733d@haskell.org> Message-ID: <061.cdbb1f8a46ed3393795af2416a6b8a9c@haskell.org> #16386: T16219 fails on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: broken-test 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 Marge Bot ): In [changeset:"db1362375cb960529cd068dd6cacd9ba0cf3977b/ghc" db13623/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="db1362375cb960529cd068dd6cacd9ba0cf3977b" testsuite: Mark T16219 and cabal09 as broken on Windows See #16386. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 21 16:59:51 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Mar 2019 16:59:51 -0000 Subject: [GHC] #16387: Duplicate vsnwprintf symbol on Windows In-Reply-To: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> References: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> Message-ID: <061.5576a6f85d55f127028d64b0790234e6@haskell.org> #16387: Duplicate vsnwprintf symbol on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: broken-test 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 Marge Bot ): In [changeset:"23b639fd1b7c558383792c48bd35f457b01b2515/ghc" 23b639f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="23b639fd1b7c558383792c48bd35f457b01b2515" testsuite: Mark T5836 as broken on Windows See #16387. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 21 16:59:51 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Mar 2019 16:59:51 -0000 Subject: [GHC] #16388: T15904 fails on Windows In-Reply-To: <046.82f2f3342e8649744417a61e12155c7d@haskell.org> References: <046.82f2f3342e8649744417a61e12155c7d@haskell.org> Message-ID: <061.83531718247d5caa7eacfc86c006847a@haskell.org> #16388: T15904 fails on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: broken-test 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 Marge Bot ): In [changeset:"a1bda08d6cd1fe1cb8d77c552e33f5d48936aa8c/ghc" a1bda08/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a1bda08d6cd1fe1cb8d77c552e33f5d48936aa8c" testsuite: Mark T15904 as broken on Windows It seems to look for some sort of manifest file. See #16388. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 21 16:59:51 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Mar 2019 16:59:51 -0000 Subject: [GHC] #16389: T16190 fails on Windows In-Reply-To: <046.d5077b2a45b5901405da0c7bcdf7c6eb@haskell.org> References: <046.d5077b2a45b5901405da0c7bcdf7c6eb@haskell.org> Message-ID: <061.1576daec75ccea189d87eb167b53bb04@haskell.org> #16389: T16190 fails on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: hsyl20 Type: bug | Status: new Priority: highest | Milestone: 8.10.1 Component: Compiler (NCG) | Version: 8.6.3 Resolution: | Keywords: broken-test 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/515 -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"b7f5d5526ac0989fcbe0cb1aff00aaee3e2690bb/ghc" b7f5d552/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b7f5d5526ac0989fcbe0cb1aff00aaee3e2690bb" testsuite: Mark T16190 as broken on Windows There seems to be some filepath funniness due to TH embedding going on here. See #16389. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 21 16:59:51 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Mar 2019 16:59:51 -0000 Subject: [GHC] #16390: T10672 fails In-Reply-To: <046.82965e14e463cdb431c4fdc0d223bd88@haskell.org> References: <046.82965e14e463cdb431c4fdc0d223bd88@haskell.org> Message-ID: <061.ae2564971c394d451bd5b6b56411797d@haskell.org> #16390: T10672 fails ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.10.1 Component: Compiler | Version: 8.6.3 Resolution: | Keywords: broken-test 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 Marge Bot ): In [changeset:"88a6e9a4e596d22d1dd8b983a15781183050f51a/ghc" 88a6e9a4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="88a6e9a4e596d22d1dd8b983a15781183050f51a" testsuite: Mark T10672 as broken This test, which is only run on Windows, seems to be reliably timing out. See #16390. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 21 16:59:51 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Mar 2019 16:59:51 -0000 Subject: [GHC] #16387: Duplicate vsnwprintf symbol on Windows In-Reply-To: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> References: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> Message-ID: <061.0b7dd536b7775e851b67e9b618fbcbfb@haskell.org> #16387: Duplicate vsnwprintf symbol on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: broken-test 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 Marge Bot ): In [changeset:"ae382245ea65bf8824db7f4dbab5ade78e6ed9dd/ghc" ae382245/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ae382245ea65bf8824db7f4dbab5ade78e6ed9dd" rts/RtsSymbols: Drop __mingw_vsnwprintf As described in #16387, this is already defined by mingw and consequently defining it in the RTS as well leads to multiple definition errors from the RTS linker at runtime. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 21 16:59:51 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Mar 2019 16:59:51 -0000 Subject: [GHC] #16387: Duplicate vsnwprintf symbol on Windows In-Reply-To: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> References: <046.7199f269ccebbf3f701db09269e7e130@haskell.org> Message-ID: <061.69085b542dca4db80718125bcc6b22a7@haskell.org> #16387: Duplicate vsnwprintf symbol on Windows ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.3 Resolution: | Keywords: broken-test 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 Marge Bot ): In [changeset:"d98cb7637a305e31de5e05a1feb9f6f2339f8cc4/ghc" d98cb763/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d98cb7637a305e31de5e05a1feb9f6f2339f8cc4" testsuite: Don't mark T5836 as broken I believe removing __mingw_vsnwprintf from RtsSymbols fixed #16387. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 21 16:59:51 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Mar 2019 16:59:51 -0000 Subject: [GHC] #11514: Impredicativity is still sneaking in In-Reply-To: <047.227daeb89545e5c355bd1a0b7e05346f@haskell.org> References: <047.227daeb89545e5c355bd1a0b7e05346f@haskell.org> Message-ID: <062.e89a1a4096ea46eb7d6e5130559e6d9b@haskell.org> #11514: Impredicativity is still sneaking in -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"8d18a873c5d7688c6e7d91efab6bb0d6f99393c6/ghc" 8d18a873/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8d18a873c5d7688c6e7d91efab6bb0d6f99393c6" Reject nested predicates in impredicativity checking When GHC attempts to unify a metavariable with a type containing foralls, it will be rejected as an occurrence of impredicativity. GHC was /not/ extending the same treatment to predicate types, such as in the following (erroneous) example from #11514: ```haskell foo :: forall a. (Show a => a -> a) -> () foo = undefined ``` This will attempt to instantiate `undefined` at `(Show a => a -> a) -> ()`, which is impredicative. This patch catches impredicativity arising from predicates in this fashion. Since GHC is pickier about impredicative instantiations, some test cases needed to be updated to be updated so as not to fall afoul of the new validity check. (There were a surprising number of impredicative uses of `undefined`!) Moreover, the `T14828` test case now has slightly less informative types shown with `:print`. This is due to a a much deeper issue with the GHCi debugger (see #14828). Fixes #11514. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Mar 21 16:59:51 2019 From: ghc-devs at haskell.org (GHC) Date: Thu, 21 Mar 2019 16:59:51 -0000 Subject: [GHC] #14828: panic! when using :print on some functions with class constraints? In-Reply-To: <042.277052228000c219ea7b7bc26108babf@haskell.org> References: <042.277052228000c219ea7b7bc26108babf@haskell.org> Message-ID: <057.c1c6637355f0d02055709bd2c42999d1@haskell.org> #14828: panic! when using :print on some functions with class constraints? -------------------------------------+------------------------------------- Reporter: jol | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.2 Resolution: | Keywords: debugger Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Marge Bot ): In [changeset:"8d18a873c5d7688c6e7d91efab6bb0d6f99393c6/ghc" 8d18a873/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8d18a873c5d7688c6e7d91efab6bb0d6f99393c6" Reject nested predicates in impredicativity checking When GHC attempts to unify a metavariable with a type containing foralls, it will be rejected as an occurrence of impredicativity. GHC was /not/ extending the same treatment to predicate types, such as in the following (erroneous) example from #11514: ```haskell foo :: forall a. (Show a => a -> a) -> () foo = undefined ``` This will attempt to instantiate `undefined` at `(Show a => a -> a) -> ()`, which is impredicative. This patch catches impredicativity arising from predicates in this fashion. Since GHC is pickier about impredicative instantiations, some test cases needed to be updated to be updated so as not to fall afoul of the new validity check. (There were a surprising number of impredicative uses of `undefined`!) Moreover, the `T14828` test case now has slightly less informative types shown with `:print`. This is due to a a much deeper issue with the GHCi debugger (see #14828). Fixes #11514. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler