From ghc-devs at haskell.org Wed Aug 1 00:22:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 00:22:07 -0000 Subject: [GHC] #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression In-Reply-To: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> References: <050.fd7ef040d95cb71a84308b4da17db589@haskell.org> Message-ID: <065.92b754419952b6b60e5748b8d25cf497@haskell.org> #15346: Core Lint error in GHC 8.6.1: From-type of Cast differs from type of enclosed expression -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | dependent/should_compile/T15346 Blocked By: | Blocking: Related Tickets: #15419 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: comment:13 merged in 06c29ddc113e5225ebc0aa37a81d9d1cf0b7f15a, testcase in f579162afbacc21a264d0fe7a117bc9c241220bb. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 00:23:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 00:23:56 -0000 Subject: [GHC] #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb In-Reply-To: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> References: <049.ee161e70aa71dbd4af4a0de9bc8eb38f@haskell.org> Message-ID: <064.e7bfb282afd60fa17477848812d7a11f@haskell.org> #7836: "Invalid object in processHeapClosureForDead" when profiling with -hb -------------------------------------+------------------------------------- Reporter: hyperthunk | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.5 Resolution: fixed | Keywords: profiling Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15063, #15087, | Differential Rev(s): Phab:D4928 #15165 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.6.1 Comment: Merged in 30a4bcc3fc3a434b3b6ab64289934281591ce09a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 09:11:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 09:11:26 -0000 Subject: [GHC] #15461: Machine accessible interface to GHCi In-Reply-To: <046.c2d301970bbdff7b63fe4e2523868200@haskell.org> References: <046.c2d301970bbdff7b63fe4e2523868200@haskell.org> Message-ID: <061.31947398f43af982e1faf371726a8ccf@haskell.org> #15461: Machine accessible interface to GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.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 dpwiz): * cc: dpwiz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 09:36:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 09:36:43 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.d3611a90822e0e5644447b1362ef4776@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:71 simonpj]: > I was suspicious about comment:64 so I took a look. Sure enough > > * The list `[1..n]` wasn't being fused away because it was shared between `insert` and `union`, while `balanced` worked differently and generated no intermediate list. Ah yes. Lesson learned once again: benchmarking is hard and subtle. > * More significantly, the integers were in ascending order which is fantastically good for balanced union: the tree that implements the set is always balanced and never needs to be transformed. Right. I probably had the wrong intuition about set performance characteristics here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 11:01:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 11:01:33 -0000 Subject: [GHC] #15275: AArch64 validation fails with many invalid relocations In-Reply-To: <046.09db5dc304d31321bf750c17c4d53c7c@haskell.org> References: <046.09db5dc304d31321bf750c17c4d53c7c@haskell.org> Message-ID: <061.6d3a357caa00a5fbd68d84f67f322c45@haskell.org> #15275: AArch64 validation fails with many invalid relocations -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Linking) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Sadly, not that I know of. I have previously observed this when using `ld.gold`. I'm frankly quite surprised that `R_AARCH64_ADR_PREL_PG_HI21` given that we are compiling with `-fPIC`. I rather suspect this may be (yet another) linker bug. I'm currently trying a build linked with `ld.bfd` to see if it exhibits the same issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 11:30:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 11:30:18 -0000 Subject: [GHC] #15350: gcdExtInteger violates assertion In-Reply-To: <047.463f72a51535cf21b879b51cdb0841bf@haskell.org> References: <047.463f72a51535cf21b879b51cdb0841bf@haskell.org> Message-ID: <062.fdcd1de065a16804169566751d4d5cef@haskell.org> #15350: gcdExtInteger violates assertion -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: Bodigrim Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 12:19:12 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 12:19:12 -0000 Subject: [GHC] #14887: Explicitly quantifying a kind variable causes a telescope to fail to kind-check In-Reply-To: <050.26e9faa4d4a29b625c8bfcdef0d31364@haskell.org> References: <050.26e9faa4d4a29b625c8bfcdef0d31364@haskell.org> Message-ID: <065.490583251fd29fd13d2c4673ee664da1@haskell.org> #14887: Explicitly quantifying a kind variable causes a telescope to fail to kind- check -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Principle: implicitly-quantified variables always precede explicitly- quantified variables in a type or kind. So `Foo1` and `Foo2` in the OP are ''not'' equivalent. * In `Foo1` the implicitly-quantified variables are `k` and `a::k`; and GHC can put them in that order. * But in `Foo2` the implicitly quantified variable is only `a::k` and that can't come first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 12:21:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 12:21:56 -0000 Subject: [GHC] #14887: Explicitly quantifying a kind variable causes a telescope to fail to kind-check In-Reply-To: <050.26e9faa4d4a29b625c8bfcdef0d31364@haskell.org> References: <050.26e9faa4d4a29b625c8bfcdef0d31364@haskell.org> Message-ID: <065.271fe3218a2ed8264becfbdc08b0a339@haskell.org> #14887: Explicitly quantifying a kind variable causes a telescope to fail to kind- check -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Richard's [https://phabricator.haskell.org/rGHCfaec8d358985e5d0bf363bd96f23fe76c9e281f7 #change-V13ptOp5f1gq patch] says "The error message for dependent/should_fail/TypeSkolEscape has become noticeably worse. However, this is because the code in TcErrors goes to some length to preserve pre-8.0 error messages for kind errors. It's time to rip off that plaster and get rid of much of the kind-error-specific error messages. I tried this, and doing so led to a lovely error message for TypeSkolEscape. So: I'm accepting the error message quality regression for now, but will open up a new ticket to fix it, along with a larger error-message improvement I've been pondering. This applies also to dependent/should_fail/{BadTelescope2,T14066,T14066e}, polykinds/T11142." We think this is related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 13:56:09 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 13:56:09 -0000 Subject: [GHC] #12625: Bad error message for flags with required but missing arguments In-Reply-To: <050.552ad6bb3a020bd4f5961b4cb97a9c89@haskell.org> References: <050.552ad6bb3a020bd4f5961b4cb97a9c89@haskell.org> Message-ID: <065.9fb15faf03314001f3b4807a52202ce8@haskell.org> #12625: Bad error message for flags with required but missing arguments -------------------------------------+------------------------------------- Reporter: dramforever | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T12625 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D5030 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * status: new => patch * testcase: => T12625 * differential: => Phab: D5030 Comment: Fix in [https://phabricator.haskell.org/D5030]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 14:25:12 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 14:25:12 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.32ff36764942879f503c3948440a395f@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): vdukhovni, the patch has been merged. That being said, I'm a bit confused; I have tried building it under a FreeBSD 11 VM but it doesn't appear that `MAP_GUARD` is defined. I checked in both the `mmap(2)` manpage as well as `` and found no mention of `MAP_GUARD`. What am I missing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 14:29:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 14:29:25 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.269cada5f51ce57b5378f7f62ba40f5b@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Ahh, the problem is that I'm on 11.0 yet apparently `MAP_GUARD` is only supported in 11.1 and later (judging by the manpages on freebsd.org) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 14:39:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 14:39:33 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.784b831daee3d86b3c80f8e371e2935b@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Comment (by vdukhovni): Yes, I'm on a FreeBSD 11.1 system: {{{ $ uname -sr FreeBSD 11.1-RELEASE-p10 $ grep -rw MAP_GUARD /usr/include/sys /usr/include/sys/mman.h:#define MAP_GUARD 0x00002000 /* reserve but don't map address range */ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 14:48:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 14:48:25 -0000 Subject: [GHC] #15148: Allow setting of custom alignments In-Reply-To: <047.65d79bc1b0303b6249ecd616495d5687@haskell.org> References: <047.65d79bc1b0303b6249ecd616495d5687@haskell.org> Message-ID: <062.2c566bf6c143ff40e6b851f6d74d59f8@haskell.org> #15148: Allow setting of custom alignments -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (NCG) | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15124 | Differential Rev(s): Phab:D4706 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * differential: => Phab:D4706 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 15:12:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 15:12:29 -0000 Subject: [GHC] #15358: no way to talk about unpacking sum types / unpacking tuples In-Reply-To: <046.10280472f5df7e66337f813b5dfe7fe0@haskell.org> References: <046.10280472f5df7e66337f813b5dfe7fe0@haskell.org> Message-ID: <061.00d4b656f1f94a4ee09bacc080669151@haskell.org> #15358: no way to talk about unpacking sum types / unpacking tuples -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: unboxedsums, | unboxedtuples Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 Comment: This certainly won't happen for 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 15:36:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 15:36:20 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.be8f64551a82e6f2efbaa15f61e16b25@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): Phab:D3752, #12506, #13386 | Phab:D4766 Wiki Page: | -------------------------------------+------------------------------------- Comment (by _recursion): Is there any chance that this will be able to make it into 8.6? We ([https://www.luna-lang.org/ Luna]) have a codebase that is ''very'' heavy on type families, and we're seeing obscene compile times and memory usage when building with optimisation. When it takes longer to compile than ghc in the `perf` build flavour, we have ''something'' wrong! I'd have tried the patch (D4766) myself, but it's currently not able to apply without conflict resolution to either the `master` or `ghc-8.6` branches, and I don't want to risk mucking something up trying to resolve conflicts! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 15:58:55 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 15:58:55 -0000 Subject: [GHC] #14887: Explicitly quantifying a kind variable causes a telescope to fail to kind-check In-Reply-To: <050.26e9faa4d4a29b625c8bfcdef0d31364@haskell.org> References: <050.26e9faa4d4a29b625c8bfcdef0d31364@haskell.org> Message-ID: <065.ba7c1c01e2d392cd228cd38e98f5553e@haskell.org> #14887: Explicitly quantifying a kind variable causes a telescope to fail to kind- check -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think the best way to get good error messages here is to bring both implicit and explicit variables into scope all at once, and then have `setImplicationStatus` report errors involving both explicit and implicit variables. See `Note [Keeping scoped variables in order: Explicit]` in !TcHsType for the general idea; here, I'm proposing this plan to cover implicit variables, too. One wrinkle: datatypes go via a different mechanism, in `kcLHsQTyVars` and friends. Question: could we unify these mechanisms? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 16:05:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 16:05:05 -0000 Subject: [GHC] #15463: "Serious" validation failures on i686 Message-ID: <048.69c70a3c6d4c72255c91639c0649f11f@haskell.org> #15463: "Serious" validation failures on i686 -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: None/Unknown Test Case: T3171, | Blocked By: heapprof001 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A very recent run of `./validate` on i686 revealed 6 failures, 4 of which I'm hopefully fixing with [https://phabricator.haskell.org/D5031 D5031], but the other two look more serious. The circle ci build logs are here: https://circleci.com/gh/ghc/ghc/7578 One of the remaining failures in particular seems somewhat critical: {{{ Wrong exit code for heapprof001(prof_hc_hb)(expected 0 , actual 139 ) Stdout ( heapprof001 ): a <= a <= a <= a <= a <= a <= a <= Stderr ( heapprof001 ): Segmentation fault *** unexpected failure for heapprof001(prof_hc_hb) }}} While the other one might be a lot simpler: {{{ Actual stdout output differs from expected: --- ./ghci/should_run/T3171.run/T3171.stdout.normalised 2018-07-31 05:27:01.821192706 +0000 +++ ./ghci/should_run/T3171.run/T3171.run.stdout.normalised 2018-07-31 05:27:01.821192706 +0000 @@ -1 +0,0 @@ -Interrupted. *** unexpected failure for T3171(normal) }}} I have not investigated any of those yet, but the first one does seem like a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 17:07:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 17:07:03 -0000 Subject: [GHC] #11295: Figure out what LLVM passes are fruitful In-Reply-To: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> References: <046.97e900ad29a1522a4b7374676cc6de7a@haskell.org> Message-ID: <061.78cbfc68c8a184d0d6ef7293af84619d@haskell.org> #11295: Figure out what LLVM passes are fruitful -------------------------------------+------------------------------------- Reporter: bgamari | Owner: kavon Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (LLVM) | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14528 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Any word on this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 18:22:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 18:22:48 -0000 Subject: [GHC] #15357: Make nofib suitable for runtime measurements. In-Reply-To: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> References: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> Message-ID: <062.176d67b3822bb14e73eeb19b76a81766@haskell.org> #15357: Make nofib suitable for runtime measurements. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.8.1 Component: NoFib benchmark | Version: 8.4.3 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5793 | Differential Rev(s): Phab:D4989 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 Comment: I'm not sure we want this to be in 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 18:23:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 18:23:59 -0000 Subject: [GHC] #14534: Split T12971 into its own Makefile In-Reply-To: <045.dc9d469c7c661699270f66b7951e0a7a@haskell.org> References: <045.dc9d469c7c661699270f66b7951e0a7a@haskell.org> Message-ID: <060.31f13671ef61e11e89e3eeb84ac1ae89@haskell.org> #14534: Split T12971 into its own Makefile -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: patch Priority: low | Milestone: 8.8.1 Component: Test Suite | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4252 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 18:24:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 18:24:32 -0000 Subject: [GHC] #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 In-Reply-To: <045.eca6114dcdeb61c7b163f0880d93f0b7@haskell.org> References: <045.eca6114dcdeb61c7b163f0880d93f0b7@haskell.org> Message-ID: <060.f91db39f8be6bed6433998fe56d5a7f4@haskell.org> #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 -------------------------------+-------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5021 Wiki Page: | -------------------------------+-------------------------------------- Changes (by bgamari): * differential: D5021 => Phab:D5021 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 18:42:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 18:42:47 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.231f5585c194ad102d43f0176f470ac4@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"f8618a9b15177ee8c84771b927cb3583c9cd8408/ghc" f8618a9b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f8618a9b15177ee8c84771b927cb3583c9cd8408" Remove the type-checking knot. Bug #15380 hangs because a knot-tied TyCon ended up in a kind. Looking at the code in tcInferApps, I'm amazed this hasn't happened before! I couldn't think of a good way to fix it (with dependent types, we can't really keep types out of kinds, after all), so I just went ahead and removed the knot. This was remarkably easy to do. In tcTyVar, when we find a TcTyCon, just use it. (Previously, we looked up the knot-tied TyCon and used that.) Then, during the final zonk, replace TcTyCons with the real, full-blooded TyCons in the global environment. It's all very easy. The new bit is explained in the existing Note [Type checking recursive type and class declarations] in TcTyClsDecls. Naturally, I removed various references to the knot and the zonkTcTypeInKnot (and related) functions. Now, we can print types during type checking with abandon! NB: There is a teensy error message regression with this patch, around the ordering of quantified type variables. This ordering problem is fixed (I believe) with the patch for #14880. The ordering affects only internal variables that cannot be instantiated with any kind of visible type application. There is also a teensy regression around the printing of types in TH splices. I think this is really a TH bug and will file separately. Test case: dependent/should_fail/T15380 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 18:42:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 18:42:47 -0000 Subject: [GHC] #15380: Infinite typechecker loop in GHC 8.6 In-Reply-To: <050.ceee7eb83a4946e532604b8e627271f4@haskell.org> References: <050.ceee7eb83a4946e532604b8e627271f4@haskell.org> Message-ID: <065.d228861d6bc3ed3ffe507953047d5fed@haskell.org> #15380: Infinite typechecker loop in GHC 8.6 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4974 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"f8618a9b15177ee8c84771b927cb3583c9cd8408/ghc" f8618a9b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f8618a9b15177ee8c84771b927cb3583c9cd8408" Remove the type-checking knot. Bug #15380 hangs because a knot-tied TyCon ended up in a kind. Looking at the code in tcInferApps, I'm amazed this hasn't happened before! I couldn't think of a good way to fix it (with dependent types, we can't really keep types out of kinds, after all), so I just went ahead and removed the knot. This was remarkably easy to do. In tcTyVar, when we find a TcTyCon, just use it. (Previously, we looked up the knot-tied TyCon and used that.) Then, during the final zonk, replace TcTyCons with the real, full-blooded TyCons in the global environment. It's all very easy. The new bit is explained in the existing Note [Type checking recursive type and class declarations] in TcTyClsDecls. Naturally, I removed various references to the knot and the zonkTcTypeInKnot (and related) functions. Now, we can print types during type checking with abandon! NB: There is a teensy error message regression with this patch, around the ordering of quantified type variables. This ordering problem is fixed (I believe) with the patch for #14880. The ordering affects only internal variables that cannot be instantiated with any kind of visible type application. There is also a teensy regression around the printing of types in TH splices. I think this is really a TH bug and will file separately. Test case: dependent/should_fail/T15380 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 18:45:04 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 18:45:04 -0000 Subject: [GHC] #15380: Infinite typechecker loop in GHC 8.6 In-Reply-To: <050.ceee7eb83a4946e532604b8e627271f4@haskell.org> References: <050.ceee7eb83a4946e532604b8e627271f4@haskell.org> Message-ID: <065.74ad040b0275725253c45fa9e0a112b4@haskell.org> #15380: Infinite typechecker loop in GHC 8.6 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | dependent/should_fail/T15380 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4974 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: patch => merge * testcase: => dependent/should_fail/T15380 Comment: Fixed now. Though this touches quite a few files, I don't think it should cause merging trouble. But it's not really critical. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 18:54:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 18:54:07 -0000 Subject: [GHC] #15464: Template Haskell creates System names when it shouldn't Message-ID: <047.b087cccbf7c0ae5ecdb334fdb02ac7ea@haskell.org> #15464: Template Haskell creates System names when it shouldn't -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template | Version: 8.4.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: -------------------------------------+------------------------------------- If we desugar {{{ [d| foo :: a -> a foo x = x |] }}} we discover that `a` has a "system" name. This is explained in this Note (is DsMeta): {{{ Note [Scoped type variables in bindings] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Consider f :: forall a. a -> a f x = x::a Here the 'forall a' brings 'a' into scope over the binding group. To achieve this we a) Gensym a binding for 'a' at the same time as we do one for 'f' collecting the relevant binders with hsSigTvBinders b) When processing the 'forall', don't gensym The relevant places are signposted with references to this Note }}} The problem is that the gensym approach creates system names, as explained further in `Note [Binders in Template Haskell]` in Convert. Essentially, it explains why to use system names as the result of `qNewName`, which !DsMeta uses for its gensyms. There is a good logic to this approach, but system names are just wrong in the quote above. This can be user-visible when we print out the results, as we see in test case `th/T10267`, which includes silliness like `j :: forall a0. a0 -> a0`. (Recall that GHC appends a `0` to system names when printing.) I worry that the answer here is a new `NameFlavour`, but perhaps cooler heads will prevail. (This problem became user-visible with the fix to #15380, but I fault TH here, not #15380.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 18:54:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 18:54:29 -0000 Subject: [GHC] #15380: Infinite typechecker loop in GHC 8.6 In-Reply-To: <050.ceee7eb83a4946e532604b8e627271f4@haskell.org> References: <050.ceee7eb83a4946e532604b8e627271f4@haskell.org> Message-ID: <065.fd30323527b2276063e9380c254e2785@haskell.org> #15380: Infinite typechecker loop in GHC 8.6 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | dependent/should_fail/T15380 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4974 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Posted #15464 as the follow-up TH bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 19:00:52 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 19:00:52 -0000 Subject: [GHC] #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 In-Reply-To: <045.eca6114dcdeb61c7b163f0880d93f0b7@haskell.org> References: <045.eca6114dcdeb61c7b163f0880d93f0b7@haskell.org> Message-ID: <060.2b6de629417d0bf6da5e7afb6becdfb8@haskell.org> #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 -------------------------------+-------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5021 Wiki Page: | -------------------------------+-------------------------------------- Comment (by George): Replying to [comment:6 angerman]: Thanks for the quick response and fix! Would it be possible to give a high level summary of the bug and the fix? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 19:05:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 19:05:50 -0000 Subject: [GHC] #15461: Machine accessible interface to GHCi In-Reply-To: <046.c2d301970bbdff7b63fe4e2523868200@haskell.org> References: <046.c2d301970bbdff7b63fe4e2523868200@haskell.org> Message-ID: <061.6e249df24e8056f940bfbb7586ee323f@haskell.org> #15461: Machine accessible interface to GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.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: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:5 alanz]: > An interim step would be to add tests to ghc/ghci that explicitly exercise the features currently used in haskell-mod and/or Intero Note that Intero is irrelevant in this context; Intero started as a fork of http://hackage.haskell.org/package/ghci-ng-7.6.3.5 and has diverged from GHCi's roots ever since without contributing back. So let's just focus on haskell-mode and keep Intero out of this please. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 23:39:12 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 23:39:12 -0000 Subject: [GHC] #15234: WARNING in hptSomeThingsBelowUs when using a source plugin In-Reply-To: <049.15722b69a2f4eb74d7898931a7d1b55a@haskell.org> References: <049.15722b69a2f4eb74d7898931a7d1b55a@haskell.org> Message-ID: <064.e54b2bb050e322eb850a173f72388334@haskell.org> #15234: WARNING in hptSomeThingsBelowUs when using a source plugin -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | SourcePlugins, plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4937 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"52065e95c6df89d0048c6e3f35d6cc26ce8246f9/ghc" 52065e9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="52065e95c6df89d0048c6e3f35d6cc26ce8246f9" Plugin dependency information is stored separately We need to store the used plugins so that we recompile a module when a plugin that it uses is recompiled. However, storing the `ModuleName`s of the plugins used by a module in the `dep_mods` field made the rest of GHC think that they belong in the HPT, causing at least the issues reported in #15234 We therefor store the `ModuleName`s of the plugins in a new field, `dep_plgins`, which is only used the the recompilation logic. Reviewers: mpickering, bgamari Reviewed By: mpickering, bgamari Subscribers: alpmestan, rwbarton, thomie, carter GHC Trac Issues: #15234 Differential Revision: https://phabricator.haskell.org/D4937 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 23:39:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 23:39:28 -0000 Subject: [GHC] #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 In-Reply-To: <045.eca6114dcdeb61c7b163f0880d93f0b7@haskell.org> References: <045.eca6114dcdeb61c7b163f0880d93f0b7@haskell.org> Message-ID: <060.2526b0a05116d4687a93c58d92785b35@haskell.org> #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 -------------------------------+-------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5021 Wiki Page: | -------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"b803c40608119469bdda330cb88860be2cbed25b/ghc" b803c406/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b803c40608119469bdda330cb88860be2cbed25b" linker: Nub rpaths When compiling and linking files in `ghci`, we keep adding rpath arguments to the linker command invoation. If those are identical we should `nub` them out. Otherwise we not only risk overflowing the argument limit, but also embed huge amounts of identical rpath values into the dynamic library, eventually leading to the overflow of the load command size limit, due to the number of rpath entries alone. A further improvement could be to pass `-Xlinker -dead_strip_dylibs`; that however might be stipping too aggressively, and potentially lead to missing symbols? For the time being I suggest to only do the nubbing and if need be to provide -Wl,-dead_strip_dylibs when invoking ghci. Test Plan: ./validate Reviewers: bgamari, hvr Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15446 Differential Revision: https://phabricator.haskell.org/D5021 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 23:39:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 23:39:43 -0000 Subject: [GHC] #15450: Inconsistency w.r.t. coverage checking warnings for EmptyCase under unsatisfiable constraints In-Reply-To: <050.a778e3d607f09b5ab14f992506aa831f@haskell.org> References: <050.a778e3d607f09b5ab14f992506aa831f@haskell.org> Message-ID: <065.69177b29af7d6d8717160ed95700a801@haskell.org> #15450: Inconsistency w.r.t. coverage checking warnings for EmptyCase under unsatisfiable constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #12957 | Differential Rev(s): Phab:D5017 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7f3cb50dd311caefb536d582f1e3d1b33d6650f6/ghc" 7f3cb50d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7f3cb50dd311caefb536d582f1e3d1b33d6650f6" Fix #15450 by refactoring checkEmptyCase' `checkEmptyCase'` (the code path for coverage-checking `EmptyCase` expressions) had a fair bit of code duplication from the code path for coverage-checking non-`EmptyCase` expressions, and to make things worse, it behaved subtly different in some respects (for instance, emitting different warnings under unsatisfiable constraints, as shown in #15450). This patch attempts to clean up both this discrepancy and the code duplication by doing the following: * Factor out a `pmInitialTmTyCs` function, which returns the initial set of term and type constraints to use when beginning coverage checking. If either set of constraints is unsatisfiable, we use an empty set in its place so that we can continue to emit as many warnings as possible. (The code path for non-`EmptyCase` expressions was doing this already, but not the code path for `EmptyCase` expressions, which is the root cause of #15450.) Along the way, I added a `Note` to explain why we do this. * Factor out a `pmIsSatisfiable` constraint which checks if a set of term and type constraints are satisfiable. This does not change any existing behavior; this is just for the sake of deduplicating code. Test Plan: make test TEST=T15450 Reviewers: simonpj, bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15450 Differential Revision: https://phabricator.haskell.org/D5017 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 1 23:39:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Aug 2018 23:39:59 -0000 Subject: [GHC] #15415: GHCi's :kind doesn't work with wildcards In-Reply-To: <047.9324d649243992c743ffcce486b06b5a@haskell.org> References: <047.9324d649243992c743ffcce486b06b5a@haskell.org> Message-ID: <062.46221b1725971a1d4acb8e35f976a7ec@haskell.org> #15415: GHCi's :kind doesn't work with wildcards -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5022 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"120cc9f85ee1120072eb44c5bf37ac3055883605/ghc" 120cc9f8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="120cc9f85ee1120072eb44c5bf37ac3055883605" Fix #15415 and simplify tcWildCardBinders Test Plan: Validate Reviewers: goldfire, simonpj, bgamari Reviewed By: simonpj Subscribers: RyanGlScott, rwbarton, thomie, carter GHC Trac Issues: #15415 Differential Revision: https://phabricator.haskell.org/D5022 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 00:31:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 00:31:06 -0000 Subject: [GHC] #11261: Implement DWARF debugging on powerpc64 In-Reply-To: <047.fcb308b656617448e39264eeafa29658@haskell.org> References: <047.fcb308b656617448e39264eeafa29658@haskell.org> Message-ID: <062.47309f6d46d5cadf83bd5aedb515e197@haskell.org> #11261: Implement DWARF debugging on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: 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: | -------------------------------------+------------------------------------- Comment (by admock): Replying to [comment:11 trommler]: > Replying to [comment:9 admock]: > > What's required to add this? > I have started work on this two years ago in my github repository > [https://github.com/trommler/ghc/tree/T11261]. > > The issue where I got stuck was that I could not find a way to tell a function label apart from > other label types. In the ppc64 ABI a function label is the label of a function descriptor but > for debug information I need the label of the function code. Thanks. I won't have any time to look at this for a couple of weeks, but I've wanted this a few times so I'll give it a shot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 00:42:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 00:42:52 -0000 Subject: [GHC] #15453: Bug in opt_trans_rule in OptCoercion In-Reply-To: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> References: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> Message-ID: <062.a2aaee1b1976c5d45f397d1cad5c05ee@haskell.org> #15453: Bug in opt_trans_rule in OptCoercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5018 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.6.1 Comment: comment:7 merged to `ghc-8.6` with eb2b71c55df329570361e78f2f0ecdfcf3fe5974. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 00:43:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 00:43:28 -0000 Subject: [GHC] #15348: Enable two-step allocator on FreeBSD In-Reply-To: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> References: <046.2b8f6765233cec777c7b07c9071be031@haskell.org> Message-ID: <061.3a18681d2512c85d9569b40813655f98@haskell.org> #15348: Enable two-step allocator on FreeBSD -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: FreeBSD | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4939 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Indeed things look better with FreeBSD 11.2. Merged to `ghc-8.6` with 79e136104922aa4dcb555084731a890294cda106. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 01:00:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 01:00:16 -0000 Subject: [GHC] #13897: Ship check-ppr in bindist and compile during testsuite run In-Reply-To: <046.c1d9498de95e82cc15e6c9fd657e4d84@haskell.org> References: <046.c1d9498de95e82cc15e6c9fd657e4d84@haskell.org> Message-ID: <061.dca0c50ebfa9f81ebc18d0c756e4f9a0@haskell.org> #13897: Ship check-ppr in bindist and compile during testsuite run -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alanz Type: task | Status: upstream Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: continuous | integration Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13716 Related Tickets: | Differential Rev(s): Phab:D4039 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => continuous integration * milestone: 8.6.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 01:01:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 01:01:24 -0000 Subject: [GHC] #15234: WARNING in hptSomeThingsBelowUs when using a source plugin In-Reply-To: <049.15722b69a2f4eb74d7898931a7d1b55a@haskell.org> References: <049.15722b69a2f4eb74d7898931a7d1b55a@haskell.org> Message-ID: <064.67b48c0e1a7672b28e5b029d4994ab2c@haskell.org> #15234: WARNING in hptSomeThingsBelowUs when using a source plugin -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | SourcePlugins, plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4937 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 01:01:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 01:01:57 -0000 Subject: [GHC] #15138: Unable to instantiate data members of kind Nat in backpack signatures. In-Reply-To: <042.e290873b59fcee0c98fbf371f48d1238@haskell.org> References: <042.e290873b59fcee0c98fbf371f48d1238@haskell.org> Message-ID: <057.8cd2b0bcaaf8b5245d8cd145de7a9123@haskell.org> #15138: Unable to instantiate data members of kind Nat in backpack signatures. -------------------------------------+------------------------------------- Reporter: ppk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.1 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:D4951 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 Comment: Unfortunately it doesn't look like this will quite make it. Sorry ppk! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 01:03:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 01:03:26 -0000 Subject: [GHC] #15415: GHCi's :kind doesn't work with wildcards In-Reply-To: <047.9324d649243992c743ffcce486b06b5a@haskell.org> References: <047.9324d649243992c743ffcce486b06b5a@haskell.org> Message-ID: <062.4f676899246691584d0acb8e6d986a7e@haskell.org> #15415: GHCi's :kind doesn't work with wildcards -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 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:D5022 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.6` with a97ead78b76bfd914adb7c5b331ee364fc6f1928. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 01:03:50 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 01:03:50 -0000 Subject: [GHC] #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 In-Reply-To: <045.eca6114dcdeb61c7b163f0880d93f0b7@haskell.org> References: <045.eca6114dcdeb61c7b163f0880d93f0b7@haskell.org> Message-ID: <060.01f748d213c502d7df9c7a5e55280703@haskell.org> #15446: compiling files in ghci on MacOS eventually results in malformed mach-o: load commands size (32800) > 32768 -------------------------------+-------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5021 Wiki Page: | -------------------------------+-------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.6` with c9be85961829845b2442fba74dc61c3e8cbad09f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 01:04:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 01:04:20 -0000 Subject: [GHC] #15450: Inconsistency w.r.t. coverage checking warnings for EmptyCase under unsatisfiable constraints In-Reply-To: <050.a778e3d607f09b5ab14f992506aa831f@haskell.org> References: <050.a778e3d607f09b5ab14f992506aa831f@haskell.org> Message-ID: <065.6b59ff9040d4228ffcd510f6ed43ae7a@haskell.org> #15450: Inconsistency w.r.t. coverage checking warnings for EmptyCase under unsatisfiable constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #12957 | Differential Rev(s): Phab:D5017 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.6` with ebd773a09be134157880eaa1099f4b5d30a67aac. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 02:43:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 02:43:15 -0000 Subject: [GHC] #15412: "Instance head is not headed by a class" when `Constraint` replaced with `type C = Constraint` In-Reply-To: <051.c4281f14deae6a8271fa4ba5fd050a12@haskell.org> References: <051.c4281f14deae6a8271fa4ba5fd050a12@haskell.org> Message-ID: <066.8e2334b902b2c1d704abd984d91e87fd@haskell.org> #15412: "Instance head is not headed by a class" when `Constraint` replaced with `type C = Constraint` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/typecheck/should_compile/T15412 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged in 6a7cb80648253ebcc84be5f11e2cc78eae085aa8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 02:43:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 02:43:53 -0000 Subject: [GHC] #15380: Infinite typechecker loop in GHC 8.6 In-Reply-To: <050.ceee7eb83a4946e532604b8e627271f4@haskell.org> References: <050.ceee7eb83a4946e532604b8e627271f4@haskell.org> Message-ID: <065.3edb1ff999a102e5280e5bcda0940869@haskell.org> #15380: Infinite typechecker loop in GHC 8.6 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: TypeInType, Resolution: fixed | TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | dependent/should_fail/T15380 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4974 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.6` with 59f38587d44efd00b10a6d98f6a7a1b22e87f13a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 02:44:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 02:44:05 -0000 Subject: [GHC] #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards In-Reply-To: <050.ef8e4534e8122f92ce5a478cf81c9256@haskell.org> References: <050.ef8e4534e8122f92ce5a478cf81c9256@haskell.org> Message-ID: <065.d2d29aa785f5620b6ec52c401d5c06ee@haskell.org> #15385: -Wincomplete-patterns gets confused when combining GADTs and pattern guards -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | pmcheck/should_compile/T15385 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4968 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: comment:9 merged in 42c51e2f39ce829fa4a380b604c9a7f5ea71d28d, comment:10 in e649085bb35628e10b08a9a1ef27095ad0510b40. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 02:44:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 02:44:44 -0000 Subject: [GHC] #15234: WARNING in hptSomeThingsBelowUs when using a source plugin In-Reply-To: <049.15722b69a2f4eb74d7898931a7d1b55a@haskell.org> References: <049.15722b69a2f4eb74d7898931a7d1b55a@haskell.org> Message-ID: <064.b8a84186286254fb802eda7ee0fe186d@haskell.org> #15234: WARNING in hptSomeThingsBelowUs when using a source plugin -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: | SourcePlugins, plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4937 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.6` with e86db0d59dc2f9d8f4140c6b3052762a1ae82428. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 03:44:25 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 03:44:25 -0000 Subject: [GHC] #15138: Unable to instantiate data members of kind Nat in backpack signatures. In-Reply-To: <042.e290873b59fcee0c98fbf371f48d1238@haskell.org> References: <042.e290873b59fcee0c98fbf371f48d1238@haskell.org> Message-ID: <057.d3c96ccae04790193c8cc691fd366f23@haskell.org> #15138: Unable to instantiate data members of kind Nat in backpack signatures. -------------------------------------+------------------------------------- Reporter: ppk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.1 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:D4951 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ppk): Replying to [comment:4 bgamari]: > Unfortunately it doesn't look like this will quite make it. Sorry ppk! That is okey. Thanks for all the effort you and the ghc team makes. But here are some of the things about the failing test cases. I am documenting it here so that it can be useful for diagnosing them if this patch has to eventually land. 1. The failing tests are all in the backpack tests should_fail section namely bkpfail23,25,26,27 and 46 2. Of these all except `bkpfail46` is still giving compilation error which but the stderr are not matching. As a result the most interesting test is `bkpfail46` as that is a case that was rejected before the patch which is getting accepted now. So we should really understand bkpfail46 to make sense whether it is i. Making backpack more general (a good thing). This just means that the test case is no more relevant and could just be removed or ignored. ii. Or this could be a break in typesafety and hence bad. I do not think I understand the issues there fully to make a comment on it one way or the other. 3. The next critical test is the bkpfail25 as it gives an error message of the form {{{ bkpfail25.bkp:7:18: error: _ The type synonym _T_ should have 1 argument, but has been given none _ In the instance declaration for _Functor T_ }}} There is a comment `bkpfail25.bkp` that precisely says that such an error message is "too late". So this too looks like a test case that needs some analysis. 4. The other tests that fails, I do not have much to say. I wanted to say that I also have a dependent phab which builds on this to fix #15379 where I did document this. These tests were failing on my machine and I was thinking that it could be some change that I introduced in that patch which made the difference. Now it looks like this is a problem even here. In summary, this looks like a test that requires some serious thought from someone who understands the backpack system much more than me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 09:12:30 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 09:12:30 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.5c6094a17721c9ab8df7f74071d2b35a@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): New results: following the suggestion to go back to the (incorrect) baseline before the patch, and then *only* rewriting `tyCoVarsOf{Type|Co}[s]` in terms of `VarSet`, thus skipping the detour via `FV`, I compared three different versions: - the pre-patch baseline, available on the `wip/T14880-baseline` branch on git.haskell.org; - the patch, applied fully, available on the `wip/T14880` branch - the baseline version with the `tvCoVarsOf...` functions rewritten in terms of `VarSets`, copying the logic from the `FV` flavors, available on the `wip/T14880-just-tvs` branch. The expectation was that `-just-tvs` would perform better than the baseline, because it skips the additional machinery of `FV`; however, it turns out that it's actually slower and allocates more. Detailed timing results: {{{ ** Baseline ** Command being timed: "/home/tobias/well-typed/devel/ghc- phab/inplace/bin/ghc-stage2 -c testsuite/tests/perf/compiler/T5631.hs -fforce-recomp +RTS -rlogs/T14880-baseline.ticky -RTS" User time (seconds): 3.17 System time (seconds): 0.08 Percent of CPU this job got: 99% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:03.27 Maximum resident set size (kbytes): 292764 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 0 Minor (reclaiming a frame) page faults: 42788 Voluntary context switches: 392 Involuntary context switches: 18 ** Just VarSet ** Command being timed: "/home/tobias/well-typed/devel/ghc- phab/inplace/bin/ghc-stage2 -c testsuite/tests/perf/compiler/T5631.hs -fforce-recomp +RTS -rlogs/T14880-just-tvs.ticky -RTS" User time (seconds): 3.28 System time (seconds): 0.06 Percent of CPU this job got: 91% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:03.64 Maximum resident set size (kbytes): 294916 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 6 Minor (reclaiming a frame) page faults: 42784 Voluntary context switches: 452 Involuntary context switches: 20 ** 14880 patch ** Command being timed: "/home/tobias/well-typed/devel/ghc- phab/inplace/bin/ghc-stage2 -c testsuite/tests/perf/compiler/T5631.hs -fforce-recomp +RTS -rlogs/T14880.ticky -RTS" User time (seconds): 3.26 System time (seconds): 0.07 Percent of CPU this job got: 95% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:03.49 Maximum resident set size (kbytes): 295684 Average resident set size (kbytes): 0 Major (requiring I/O) page faults: 11 Minor (reclaiming a frame) page faults: 43047 Voluntary context switches: 422 Involuntary context switches: 17 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 10:39:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 10:39:47 -0000 Subject: [GHC] #14827: Recognize when inlining would create a join point In-Reply-To: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> References: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> Message-ID: <062.2a52240f8a277762d09c450ee75988c9@haskell.org> #14827: Recognize when inlining would create a join point -------------------------------------+------------------------------------- Reporter: ersetzen | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ersetzen): Posting into this issue feels somewhat like necromancy but I found a similar issue and the cause is actually quite simple: {{{ main :: IO () main = print foo {-# INLINE[1] foo #-} foo :: Int foo = bar 3 {-# INLINE[~1] bar #-} bar :: Int -> Int bar i = i + 1 }}} We inline bar into foo but not into the unfolding of foo: {{{ -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} foo [InlPrag=INLINE[1] (sat-args=0)] :: Int [LclId, Unf=Unf{Src=InlineStable, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=ALWAYS_IF(arity=0,unsat_ok=False,boring_ok=False) Tmpl= bar (GHC.Types.I# 3#)}] foo = GHC.Types.I# 4# }}} Laterwe inline the unfolding of foo which still references bar - but the phase for inling bar is over. {{{ main _s26f= ... case bar (GHC.Types.I# 3#) of { GHC.Types.I# ww3_a26u -> ... }}} So bar never gets inlined at the use side even though everything along the way had inline pragmas. There isn't really a single decision that was wrong but the result is very unintuitive and can break fusion. A compiler warning for this type of phase collision might be worthwhile if it is easily doable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 12:23:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 12:23:56 -0000 Subject: [GHC] #11759: can't decompose ghc.exe path In-Reply-To: <045.78646c85aa5779cba5b2cf0a5492deb5@haskell.org> References: <045.78646c85aa5779cba5b2cf0a5492deb5@haskell.org> Message-ID: <060.d755544aae9efde353a34c849134db12@haskell.org> #11759: can't decompose ghc.exe path -------------------------------------+------------------------------------- Reporter: erisco | Owner: Phyx- Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Driver | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2101 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Gurkenglas): May not be dead? {{{ PS C:\Users\gurke> ghc ghc.exe: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-mingw32): can't decompose ghc.exe path: "C:\\Users\\gurke\\AppData\\Roaming\\local\\bin\\ghc.exe" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 12:27:14 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 12:27:14 -0000 Subject: [GHC] #15465: PAP object entered Message-ID: <054.65b86eeb26556bf73809a3044c0a3cb9@haskell.org> #15465: PAP object entered ---------------------------------------+---------------------------------- Reporter: recursion-ninja | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------------+---------------------------------- This occurred while running our sizeable program I have no idea what the program was doing when this error was encountered but the compiler asked me to report it here: programName: internal error: PAP object entered! (GHC version 8.4.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted I don't have a way to reproduce this yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 12:30:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 12:30:17 -0000 Subject: [GHC] #15465: PAP object entered In-Reply-To: <054.65b86eeb26556bf73809a3044c0a3cb9@haskell.org> References: <054.65b86eeb26556bf73809a3044c0a3cb9@haskell.org> Message-ID: <069.1799284ae5ee333076015c8514daca43@haskell.org> #15465: PAP object entered ------------------------------------+-------------------------------------- Reporter: recursion-ninja | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Description changed by recursion-ninja: Old description: > This occurred while running our sizeable program I have no idea what the > program was doing when this error was encountered but the compiler asked > me to report it here: > > programName: internal error: PAP object entered! > (GHC version 8.4.3 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > Aborted > > I don't have a way to reproduce this yet. New description: This occurred while running our sizeable program I have no idea what the program was doing when this error was encountered but the compiler asked me to report it here: {{{ programName: internal error: PAP object entered! (GHC version 8.4.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted }}} I don't have a way to reproduce this yet. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 12:33:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 12:33:44 -0000 Subject: [GHC] #11759: can't decompose ghc.exe path In-Reply-To: <045.78646c85aa5779cba5b2cf0a5492deb5@haskell.org> References: <045.78646c85aa5779cba5b2cf0a5492deb5@haskell.org> Message-ID: <060.8b615900487fd75716bf0664c6309077@haskell.org> #11759: can't decompose ghc.exe path -------------------------------------+------------------------------------- Reporter: erisco | Owner: Phyx- Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Driver | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2101 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Does `C:\\Users\\gurke\\AppData\\Roaming\\local\\lib\\`? exist? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 12:45:50 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 12:45:50 -0000 Subject: [GHC] #11759: can't decompose ghc.exe path In-Reply-To: <045.78646c85aa5779cba5b2cf0a5492deb5@haskell.org> References: <045.78646c85aa5779cba5b2cf0a5492deb5@haskell.org> Message-ID: <060.495f12726cdb130450cb37ba6893a6b2@haskell.org> #11759: can't decompose ghc.exe path -------------------------------------+------------------------------------- Reporter: erisco | Owner: Phyx- Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Driver | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2101 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Gurkenglas): Nope. `C:\Users\gurke\AppData\Roaming\local\` exists, immediately in there's only `bin\`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 12:49:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 12:49:49 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.8241e315fef4dd6ed8b4f7fe815bd424@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Very interesting. What happens if you make a version of `FV` that uses its same setup (passing around partially applied functions, etc.) but without the list? Then rewrite the functions in terms of that? Also, I think it would be helpful not to use ticky profiling when generating these results (unless the data somehow comes from the ticky output), but also to include the allocations. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 12:56:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 12:56:41 -0000 Subject: [GHC] #11759: can't decompose ghc.exe path In-Reply-To: <045.78646c85aa5779cba5b2cf0a5492deb5@haskell.org> References: <045.78646c85aa5779cba5b2cf0a5492deb5@haskell.org> Message-ID: <060.9fc52e7d7dfd5e2babca6f04416ea3c8@haskell.org> #11759: can't decompose ghc.exe path -------------------------------------+------------------------------------- Reporter: erisco | Owner: Phyx- Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Driver | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2101 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Then that's the problem. Your bindist is incorrectly installed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 13:00:02 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 13:00:02 -0000 Subject: [GHC] #11759: can't decompose ghc.exe path In-Reply-To: <045.78646c85aa5779cba5b2cf0a5492deb5@haskell.org> References: <045.78646c85aa5779cba5b2cf0a5492deb5@haskell.org> Message-ID: <060.f292b61c78d1ece81d582ea05fc2bbc2@haskell.org> #11759: can't decompose ghc.exe path -------------------------------------+------------------------------------- Reporter: erisco | Owner: Phyx- Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Driver | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D2101 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Gurkenglas): Then it should say that instead of telling me to report that ghc wrongly assumed something to be impossible, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 14:07:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 14:07:40 -0000 Subject: [GHC] #15466: debug validation failures Message-ID: <048.92e70258a7492f32c7bd776d901c7bf2@haskell.org> #15466: debug validation failures --------------------------------------+--------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- The most recent completed run of `validate-x86_64-linux-debug` on Circle CI (https://circleci.com/gh/ghc/ghc/7730) shows 13 unexpected failures and 1 unexpected pass. **Summary** {{{ Unexpected passes: concurrent/T13615/T13615.run T13615 [unexpected] (ghci) Unexpected failures: codeGen/should_compile/T9329.run T9329 [exit code non-0] (normal) codeGen/should_run/cgrun018.run cgrun018 [exit code non-0] (normal) codeGen/should_run/cgrun018.run cgrun018 [exit code non-0] (g1) codeGen/should_run/cgrun069.run cgrun069 [exit code non-0] (normal) codeGen/should_run/cgrun069.run cgrun069 [exit code non-0] (g1) codeGen/should_run/T9577.run T9577 [bad stdout] (normal) concurrent/should_run/T3429.run T3429 [bad exit code] (debug_numa) driver/T14075/T14075.run T14075 [bad stderr] (normal) driver/recomp007/recomp007.run recomp007 [bad stderr] (normal) rts/T14702.run T14702 [bad exit code] (threaded1) rts/nursery-chunks1.run nursery-chunks1 [bad stderr] (threaded1) rts/numa001.run numa001 [bad exit code] (debug_numa) ../../libraries/base/tests/T11760.run T11760 [bad exit code] (normal) }}} --- **T9329** {{{ Compile failed (exit code 1) errors were: /tmp/ghc78722_0/ghc_4.hc: In function ‘bar’: /tmp/ghc78722_0/ghc_4.hc:18:12: error: error: ‘c6_info’ undeclared (first use in this function) *Sp = (W_)&c6_info; ^ /tmp/ghc78722_0/ghc_4.hc:18:12: error: note: each undeclared identifier is reported only once for each function it appears in `gcc' failed in phase `C Compiler'. (Exit code: 1) *** unexpected failure for T9329(normal) }}} **cgrun018** {{{ Compile failed (exit code 1) errors were: [1 of 1] Compiling Main ( cgrun018.hs, cgrun018.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20180731 for x86_64-unknown-linux): pprStatics: float F32 F32 F32 F32 F32 F32 F32 F32 F32 F32 F32 Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/cmm/PprC.hs:521:5 in ghc:PprC Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for cgrun018(normal) --- Compile failed (exit code 1) errors were: [1 of 1] Compiling Main ( cgrun018.hs, cgrun018.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20180731 for x86_64-unknown-linux): pprStatics: float F32 F32 F32 F32 F32 F32 F32 F32 F32 F32 F32 Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/cmm/PprC.hs:521:5 in ghc:PprC Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for cgrun018(g1) }}} **cgrun069** {{{ Compile failed (exit code 1) errors were: /tmp/ghc83995_0/ghc_4.hc:5:12: error: error: conflicting types for ‘memsetErr’ const char memsetErr[] = "Memset Error - align: %d size: %d\012"; ^ In file included from /tmp/ghc83995_0/ghc_4.hc:3:0: error: /tmp/ghc83995_0/ghc_4.hc:4:6: error: note: previous declaration of ‘memsetErr’ was here ERW_(memsetErr); ^ /home/ghc/project/includes/Stg.h:242:46: error: note: in definition of macro ‘ERW_’ #define ERW_(X) extern StgWordArray (X) ^ /tmp/ghc83995_0/ghc_4.hc:8:12: error: error: conflicting types for ‘memcpyErr’ const char memcpyErr[] = "Memcpy Error - align: %d size: %d\012"; ^ In file included from /tmp/ghc83995_0/ghc_4.hc:3:0: error: /tmp/ghc83995_0/ghc_4.hc:7:6: error: note: previous declaration of ‘memcpyErr’ was here ERW_(memcpyErr); ^ /home/ghc/project/includes/Stg.h:242:46: error: note: in definition of macro ‘ERW_’ #define ERW_(X) extern StgWordArray (X) ^ /tmp/ghc83995_0/ghc_4.hc:11:12: error: error: conflicting types for ‘memmoveErr’ const char memmoveErr[] = "Memmove Error Occured\012"; ^ In file included from /tmp/ghc83995_0/ghc_4.hc:3:0: error: /tmp/ghc83995_0/ghc_4.hc:10:6: error: note: previous declaration of ‘memmoveErr’ was here ERW_(memmoveErr); ^ /home/ghc/project/includes/Stg.h:242:46: error: note: in definition of macro ‘ERW_’ #define ERW_(X) extern StgWordArray (X) ^ `gcc' failed in phase `C Compiler'. (Exit code: 1) *** unexpected failure for cgrun069(normal) --- Compile failed (exit code 1) errors were: /tmp/ghc84416_0/ghc_4.hc:5:12: error: error: conflicting types for ‘memsetErr’ const char memsetErr[] = "Memset Error - align: %d size: %d\012"; ^ In file included from /tmp/ghc84416_0/ghc_4.hc:3:0: error: /tmp/ghc84416_0/ghc_4.hc:4:6: error: note: previous declaration of ‘memsetErr’ was here ERW_(memsetErr); ^ /home/ghc/project/includes/Stg.h:242:46: error: note: in definition of macro ‘ERW_’ #define ERW_(X) extern StgWordArray (X) ^ /tmp/ghc84416_0/ghc_4.hc:8:12: error: error: conflicting types for ‘memcpyErr’ const char memcpyErr[] = "Memcpy Error - align: %d size: %d\012"; ^ In file included from /tmp/ghc84416_0/ghc_4.hc:3:0: error: /tmp/ghc84416_0/ghc_4.hc:7:6: error: note: previous declaration of ‘memcpyErr’ was here ERW_(memcpyErr); ^ /home/ghc/project/includes/Stg.h:242:46: error: note: in definition of macro ‘ERW_’ #define ERW_(X) extern StgWordArray (X) ^ /tmp/ghc84416_0/ghc_4.hc:11:12: error: error: conflicting types for ‘memmoveErr’ const char memmoveErr[] = "Memmove Error Occured\012"; ^ In file included from /tmp/ghc84416_0/ghc_4.hc:3:0: error: /tmp/ghc84416_0/ghc_4.hc:10:6: error: note: previous declaration of ‘memmoveErr’ was here ERW_(memmoveErr); ^ /home/ghc/project/includes/Stg.h:242:46: error: note: in definition of macro ‘ERW_’ #define ERW_(X) extern StgWordArray (X) ^ `gcc' failed in phase `C Compiler'. (Exit code: 1) *** unexpected failure for cgrun069(g1) }}} **T9577** {{{ --- ./codeGen/should_run/T9577.run/T9577.stdout.normalised 2018-08-02 03:38:39.932680724 +0000 +++ ./codeGen/should_run/T9577.run/T9577.run.stdout.normalised 2018-08-02 03:38:39.932680724 +0000 @@ -1 +1 @@ -True +False *** unexpected failure for T9577(normal) }}} **T3429** {{{ Wrong exit code for T3429(debug_numa)(expected 0 , actual 1 ) Stderr ( T3429 ): T3429: unknown RTS option: -N2 T3429: T3429: Usage: [+RTS | -RTS ] ... --RTS T3429: T3429: +RTS Indicates run time system options follow T3429: -RTS Indicates program arguments follow T3429: --RTS Indicates that ALL subsequent arguments will be given to the T3429: program (including any of these RTS flags) T3429: T3429: The following run time system options are available: T3429: T3429: -? Prints this message and exits; the program is not executed T3429: --info Print information about the RTS used by this program T3429: T3429: -K Sets the maximum stack size (default: 80% of the heap) T3429: Egs: -K32k -K512k -K8M T3429: -ki Sets the initial thread stack size (default 1k) Egs: -ki4k -ki2m T3429: -kc Sets the stack chunk size (default 32k) T3429: -kb Sets the stack chunk buffer size (default 1k) T3429: T3429: -A Sets the minimum allocation area size (default 1m) Egs: -A20m -A10k T3429: -AL Sets the amount of large-object memory that can be allocated T3429: before a GC is triggered (default: the value of -A) T3429: -n Allocation area chunk size (0 = disabled, default: 0) T3429: -O Sets the minimum size of the old generation (default 1M) T3429: -M Sets the maximum heap size (default unlimited) Egs: -M256k -M1G T3429: -H Sets the minimum heap size (default 0M) Egs: -H24m -H1G T3429: -xb Sets the address from which a suitable start for the heap memory T3429: will be searched from. This is useful if the default address T3429: clashes with some third-party library. T3429: -m Minimum % of heap which must be available (default 3%) T3429: -G Number of generations (default: 2) T3429: -c Use in-place compaction instead of copying in the oldest generation T3429: when live data is at least % of the maximum heap size set with T3429: -M (default: 30%) T3429: -c Use in-place compaction for all oldest generation collections T3429: (the default is to use copying) T3429: -w Use mark-region for the oldest generation (experimental) T3429: -I Perform full GC after idle time (default: 0.3, 0 == off) T3429: T3429: -T Collect GC statistics (useful for in-program statistics access) T3429: -t[] One-line GC statistics (if omitted, uses stderr) T3429: -s[] Summary GC statistics (if omitted, uses stderr) T3429: -S[] Detailed GC statistics (if omitted, uses stderr) T3429: T3429: T3429: -Z Don't squeeze out update frames on stack overflow T3429: -B Sound the bell at the start of each garbage collection T3429: T3429: -hT Produce a heap profile grouped by closure type T3429: -l[flags] Log events in binary format to the file .eventlog T3429: -v[flags] Log events to stderr T3429: where [flags] can contain: T3429: s scheduler events T3429: g GC and heap events T3429: p par spark events (sampled) T3429: f par spark events (full detail) T3429: u user events (emitted from Haskell code) T3429: a all event classes above T3429: t add time stamps (only useful with -v) T3429: -x disable an event class, for any flag above T3429: the initial enabled event classes are 'sgpu' T3429: T3429: -h Heap residency profile (output file .hp) T3429: -i Time between heap profile samples (seconds, default: 0.1) T3429: T3429: -r Produce ticky-ticky statistics (with -rstderr for stderr) T3429: T3429: -C Context-switch interval in seconds. T3429: 0 or no argument means switch as often as possible. T3429: Default: 0.02 sec. T3429: -V Master tick interval in seconds (0 == disable timer). T3429: This sets the resolution for -C and the heap profile timer -i, T3429: and is the frequency of time profile samples. T3429: Default: 0.01 sec. T3429: T3429: -Ds DEBUG: scheduler T3429: -Di DEBUG: interpreter T3429: -Dw DEBUG: weak T3429: -DG DEBUG: gccafs T3429: -Dg DEBUG: gc T3429: -Db DEBUG: block T3429: -DS DEBUG: sanity T3429: -Dt DEBUG: stable T3429: -Dp DEBUG: prof T3429: -Da DEBUG: apply T3429: -Dl DEBUG: linker T3429: -Dm DEBUG: stm T3429: -Dz DEBUG: stack squeezing T3429: -Dc DEBUG: program coverage T3429: -Dr DEBUG: sparks T3429: -DC DEBUG: compact T3429: T3429: NOTE: DEBUG events are sent to stderr by default; add -l to create a T3429: binary event log file instead. T3429: T3429: --install-signal-handlers= T3429: Install signal handlers (default: yes) T3429: -e Maximum number of outstanding local sparks (default: 4096) T3429: -xm Base address to mmap memory in the GHCi linker T3429: (hex; must be <80000000) T3429: -xq The allocation limit given to a thread after it receives T3429: an AllocationLimitExceeded exception. (default: 100k) T3429: T3429: -Mgrace= T3429: The amount of allocation after the program receives a T3429: HeapOverflow exception before the exception is thrown again, if T3429: the program is still exceeding the heap limit. T3429: T3429: RTS options may also be specified using the GHCRTS environment variable. T3429: T3429: Other RTS options may be available for programs compiled a different way. T3429: The GHC User's Guide has full details. T3429: *** unexpected failure for T3429(debug_numa) }}} **T13615** {{{ *** unexpected pass for T13615(ghci) }}} **T14075** {{{ Actual stderr output differs from expected: --- ./driver/T14075/T14075.run/T14075.stderr.normalised 2018-08-02 03:40:01.063504007 +0000 +++ ./driver/T14075/T14075.run/T14075.run.stderr.normalised 2018-08-02 03:40:01.063504007 +0000 @@ -1,3 +1,4 @@ +ghc: setNumCapabilities: not supported on this platform F.hs:1:1: instance O.O F.F -- Defined at F.hs-boot:6:10 *** unexpected failure for T14075(normal) }}} **recomp007** {{{ Actual stderr output differs from expected: --- /dev/null 2018-08-01 14:11:13.420752000 +0000 +++ ./driver/recomp007/recomp007.run/recomp007.run.stderr.normalised 2018-08-02 03:40:46.313078664 +0000 @@ -0,0 +1,122 @@ +WARNING: file compiler/utils/ListSetOps.hs, line 58 + [] + [Distribution.Backpack, Distribution.Backpack.FullUnitId, + Distribution.Backpack.ModuleShape, + Distribution.Backpack.PreModuleShape, + Distribution.Backpack.ReadyComponent, + Distribution.CabalSpecVersion, Distribution.Compat.Graph, + Distribution.Compat.Semigroup, Distribution.Compiler, + Distribution.License, Distribution.ModuleName, + Distribution.Parsec.Common, Distribution.SPDX.License, + Distribution.SPDX.LicenseExceptionId, + Distribution.SPDX.LicenseExpression, Distribution.SPDX.LicenseId, + Distribution.SPDX.LicenseReference, + Distribution.Simple.BuildTarget, Distribution.Simple.Compiler, + Distribution.Simple.Doctest, Distribution.Simple.Flag, + Distribution.Simple.Haddock, Distribution.Simple.InstallDirs, + Distribution.Simple.PackageIndex, Distribution.Simple.Program.Find, + Distribution.Simple.Program.GHC, Distribution.Simple.Program.Types, + Distribution.Simple.Setup, Distribution.System, + Distribution.Types.AbiDependency, Distribution.Types.AbiHash, + Distribution.Types.Benchmark, + Distribution.Types.BenchmarkInterface, + Distribution.Types.BenchmarkType, Distribution.Types.BuildInfo, + Distribution.Types.BuildType, Distribution.Types.ComponentId, + Distribution.Types.ComponentLocalBuildInfo, + Distribution.Types.ComponentName, + Distribution.Types.ComponentRequestedSpec, + Distribution.Types.CondTree, Distribution.Types.Condition, + Distribution.Types.Dependency, Distribution.Types.ExeDependency, + Distribution.Types.Executable, Distribution.Types.ExecutableScope, + Distribution.Types.ExposedModule, Distribution.Types.ForeignLib, + Distribution.Types.ForeignLibOption, + Distribution.Types.ForeignLibType, + Distribution.Types.GenericPackageDescription, + Distribution.Types.IncludeRenaming, + Distribution.Types.InstalledPackageInfo, + Distribution.Types.LegacyExeDependency, Distribution.Types.Library, + Distribution.Types.LocalBuildInfo, Distribution.Types.Mixin, + Distribution.Types.Module, Distribution.Types.ModuleReexport, + Distribution.Types.ModuleRenaming, + Distribution.Types.MungedPackageId, + Distribution.Types.MungedPackageName, + Distribution.Types.PackageDescription, + Distribution.Types.PackageId, Distribution.Types.PackageName, + Distribution.Types.PkgconfigDependency, + Distribution.Types.PkgconfigName, + Distribution.Types.SetupBuildInfo, Distribution.Types.SourceRepo, + Distribution.Types.TargetInfo, Distribution.Types.TestSuite, + Distribution.Types.TestSuiteInterface, Distribution.Types.TestType, + Distribution.Types.UnitId, Distribution.Types.UnqualComponentName, + Distribution.Types.Version, Distribution.Types.VersionRange, + Distribution.Utils.ShortText, Distribution.Verbosity, + Language.Haskell.Extension, Control.Applicative, Data.Complex, + Data.Functor.Compose, Data.Functor.Const, Data.Functor.Identity, + Data.Functor.Product, Data.Functor.Sum, Data.Monoid, + Data.Semigroup, Data.Semigroup.Internal, Data.Version, Data.Void, + GHC.Exts, GHC.Generics, GHC.IO.Exception, Data.Graph, + Data.IntMap.Internal, Data.IntSet.Internal, Data.Map.Internal, + Data.Sequence.Internal, Data.Set.Internal, Data.Tree, + Text.PrettyPrint.Annotated.HughesPJ, Text.PrettyPrint.HughesPJ, + Data.Text, Data.Text.Lazy] +WARNING: file compiler/utils/ListSetOps.hs, line 58 + [Distribution.Backpack, Distribution.Backpack.FullUnitId, + Distribution.Backpack.ModuleShape, + Distribution.Backpack.PreModuleShape, + Distribution.Backpack.ReadyComponent, + Distribution.CabalSpecVersion, Distribution.Compat.Graph, + Distribution.Compat.Semigroup, Distribution.Compiler, + Distribution.License, Distribution.ModuleName, + Distribution.Parsec.Common, Distribution.SPDX.License, + Distribution.SPDX.LicenseExceptionId, + Distribution.SPDX.LicenseExpression, Distribution.SPDX.LicenseId, + Distribution.SPDX.LicenseReference, + Distribution.Simple.BuildTarget, Distribution.Simple.Compiler, + Distribution.Simple.Doctest, Distribution.Simple.Flag, + Distribution.Simple.Haddock, Distribution.Simple.InstallDirs, + Distribution.Simple.PackageIndex, Distribution.Simple.Program.Find, + Distribution.Simple.Program.GHC, Distribution.Simple.Program.Types, + Distribution.Simple.Setup, Distribution.System, + Distribution.Types.AbiDependency, Distribution.Types.AbiHash, + Distribution.Types.Benchmark, + Distribution.Types.BenchmarkInterface, + Distribution.Types.BenchmarkType, Distribution.Types.BuildInfo, + Distribution.Types.BuildType, Distribution.Types.ComponentId, + Distribution.Types.ComponentLocalBuildInfo, + Distribution.Types.ComponentName, + Distribution.Types.ComponentRequestedSpec, + Distribution.Types.CondTree, Distribution.Types.Condition, + Distribution.Types.Dependency, Distribution.Types.ExeDependency, + Distribution.Types.Executable, Distribution.Types.ExecutableScope, + Distribution.Types.ExposedModule, Distribution.Types.ForeignLib, + Distribution.Types.ForeignLibOption, + Distribution.Types.ForeignLibType, + Distribution.Types.GenericPackageDescription, + Distribution.Types.IncludeRenaming, + Distribution.Types.InstalledPackageInfo, + Distribution.Types.LegacyExeDependency, Distribution.Types.Library, + Distribution.Types.LocalBuildInfo, Distribution.Types.Mixin, + Distribution.Types.Module, Distribution.Types.ModuleReexport, + Distribution.Types.ModuleRenaming, + Distribution.Types.MungedPackageId, + Distribution.Types.MungedPackageName, + Distribution.Types.PackageDescription, + Distribution.Types.PackageId, Distribution.Types.PackageName, + Distribution.Types.PkgconfigDependency, + Distribution.Types.PkgconfigName, + Distribution.Types.SetupBuildInfo, Distribution.Types.SourceRepo, + Distribution.Types.TargetInfo, Distribution.Types.TestSuite, + Distribution.Types.TestSuiteInterface, Distribution.Types.TestType, + Distribution.Types.UnitId, Distribution.Types.UnqualComponentName, + Distribution.Types.Version, Distribution.Types.VersionRange, + Distribution.Utils.ShortText, Distribution.Verbosity, + Language.Haskell.Extension, Control.Applicative, Data.Complex, + Data.Functor.Compose, Data.Functor.Const, Data.Functor.Identity, + Data.Functor.Product, Data.Functor.Sum, Data.Monoid, + Data.Semigroup, Data.Semigroup.Internal, Data.Version, Data.Void, + GHC.Exts, GHC.Generics, GHC.IO.Exception, Data.Graph, + Data.IntMap.Internal, Data.IntSet.Internal, Data.Map.Internal, + Data.Sequence.Internal, Data.Set.Internal, Data.Tree, + Text.PrettyPrint.Annotated.HughesPJ, Text.PrettyPrint.HughesPJ, + Data.Text, Data.Text.Lazy] + [] *** unexpected failure for recomp007(normal) }}} **T14702** {{{ Wrong exit code for T14702(threaded1)(expected 0 , actual 1 ) Stderr ( T14702 ): T14702: unknown RTS option: -N8 T14702: T14702: Usage: [+RTS | -RTS ] ... --RTS T14702: T14702: +RTS Indicates run time system options follow T14702: -RTS Indicates program arguments follow T14702: --RTS Indicates that ALL subsequent arguments will be given to the T14702: program (including any of these RTS flags) T14702: T14702: The following run time system options are available: T14702: T14702: -? Prints this message and exits; the program is not executed T14702: --info Print information about the RTS used by this program T14702: T14702: -K Sets the maximum stack size (default: 80% of the heap) T14702: Egs: -K32k -K512k -K8M T14702: -ki Sets the initial thread stack size (default 1k) Egs: -ki4k -ki2m T14702: -kc Sets the stack chunk size (default 32k) T14702: -kb Sets the stack chunk buffer size (default 1k) T14702: T14702: -A Sets the minimum allocation area size (default 1m) Egs: -A20m -A10k T14702: -AL Sets the amount of large-object memory that can be allocated T14702: before a GC is triggered (default: the value of -A) T14702: -n Allocation area chunk size (0 = disabled, default: 0) T14702: -O Sets the minimum size of the old generation (default 1M) T14702: -M Sets the maximum heap size (default unlimited) Egs: -M256k -M1G T14702: -H Sets the minimum heap size (default 0M) Egs: -H24m -H1G T14702: -xb Sets the address from which a suitable start for the heap memory T14702: will be searched from. This is useful if the default address T14702: clashes with some third-party library. T14702: -m Minimum % of heap which must be available (default 3%) T14702: -G Number of generations (default: 2) T14702: -c Use in-place compaction instead of copying in the oldest generation T14702: when live data is at least % of the maximum heap size set with T14702: -M (default: 30%) T14702: -c Use in-place compaction for all oldest generation collections T14702: (the default is to use copying) T14702: -w Use mark-region for the oldest generation (experimental) T14702: -I Perform full GC after idle time (default: 0.3, 0 == off) T14702: T14702: -T Collect GC statistics (useful for in-program statistics access) T14702: -t[] One-line GC statistics (if omitted, uses stderr) T14702: -s[] Summary GC statistics (if omitted, uses stderr) T14702: -S[] Detailed GC statistics (if omitted, uses stderr) T14702: T14702: T14702: -Z Don't squeeze out update frames on stack overflow T14702: -B Sound the bell at the start of each garbage collection T14702: T14702: -hT Produce a heap profile grouped by closure type T14702: -l[flags] Log events in binary format to the file .eventlog T14702: -v[flags] Log events to stderr T14702: where [flags] can contain: T14702: s scheduler events T14702: g GC and heap events T14702: p par spark events (sampled) T14702: f par spark events (full detail) T14702: u user events (emitted from Haskell code) T14702: a all event classes above T14702: t add time stamps (only useful with -v) T14702: -x disable an event class, for any flag above T14702: the initial enabled event classes are 'sgpu' T14702: T14702: -h Heap residency profile (output file .hp) T14702: -i Time between heap profile samples (seconds, default: 0.1) T14702: T14702: -r Produce ticky-ticky statistics (with -rstderr for stderr) T14702: T14702: -C Context-switch interval in seconds. T14702: 0 or no argument means switch as often as possible. T14702: Default: 0.02 sec. T14702: -V Master tick interval in seconds (0 == disable timer). T14702: This sets the resolution for -C and the heap profile timer -i, T14702: and is the frequency of time profile samples. T14702: Default: 0.01 sec. T14702: T14702: -Ds DEBUG: scheduler T14702: -Di DEBUG: interpreter T14702: -Dw DEBUG: weak T14702: -DG DEBUG: gccafs T14702: -Dg DEBUG: gc T14702: -Db DEBUG: block T14702: -DS DEBUG: sanity T14702: -Dt DEBUG: stable T14702: -Dp DEBUG: prof T14702: -Da DEBUG: apply T14702: -Dl DEBUG: linker T14702: -Dm DEBUG: stm T14702: -Dz DEBUG: stack squeezing T14702: -Dc DEBUG: program coverage T14702: -Dr DEBUG: sparks T14702: -DC DEBUG: compact T14702: T14702: NOTE: DEBUG events are sent to stderr by default; add -l to create a T14702: binary event log file instead. T14702: T14702: --install-signal-handlers= T14702: Install signal handlers (default: yes) T14702: -e Maximum number of outstanding local sparks (default: 4096) T14702: -xm Base address to mmap memory in the GHCi linker T14702: (hex; must be <80000000) T14702: -xq The allocation limit given to a thread after it receives T14702: an AllocationLimitExceeded exception. (default: 100k) T14702: T14702: -Mgrace= T14702: The amount of allocation after the program receives a T14702: HeapOverflow exception before the exception is thrown again, if T14702: the program is still exceeding the heap limit. T14702: T14702: RTS options may also be specified using the GHCRTS environment variable. T14702: T14702: Other RTS options may be available for programs compiled a different way. T14702: The GHC User's Guide has full details. T14702: *** unexpected failure for T14702(threaded1) }}} **nursery-chunks1** {{{ Actual stderr output differs from expected: --- /dev/null 2018-08-01 14:11:13.420752000 +0000 +++ ./rts/nursery-chunks1.run/nursery-chunks1.run.stderr.normalised 2018-08-02 03:45:18.786560729 +0000 @@ -0,0 +1,3 @@ +nursery-chunks1: setNumCapabilities: not supported on this platform +nursery-chunks1: setNumCapabilities: not supported on this platform +nursery-chunks1: setNumCapabilities: not supported on this platform *** unexpected failure for nursery-chunks1(threaded1) }}} **numa001** {{{ Wrong exit code for numa001(debug_numa)(expected 0 , actual 1 ) Stderr ( numa001 ): numa001: unknown RTS option: -N2 numa001: numa001: Usage: [+RTS | -RTS ] ... --RTS numa001: numa001: +RTS Indicates run time system options follow numa001: -RTS Indicates program arguments follow numa001: --RTS Indicates that ALL subsequent arguments will be given to the numa001: program (including any of these RTS flags) numa001: numa001: The following run time system options are available: numa001: numa001: -? Prints this message and exits; the program is not executed numa001: --info Print information about the RTS used by this program numa001: numa001: -K Sets the maximum stack size (default: 80% of the heap) numa001: Egs: -K32k -K512k -K8M numa001: -ki Sets the initial thread stack size (default 1k) Egs: -ki4k -ki2m numa001: -kc Sets the stack chunk size (default 32k) numa001: -kb Sets the stack chunk buffer size (default 1k) numa001: numa001: -A Sets the minimum allocation area size (default 1m) Egs: -A20m -A10k numa001: -AL Sets the amount of large-object memory that can be allocated numa001: before a GC is triggered (default: the value of -A) numa001: -n Allocation area chunk size (0 = disabled, default: 0) numa001: -O Sets the minimum size of the old generation (default 1M) numa001: -M Sets the maximum heap size (default unlimited) Egs: -M256k -M1G numa001: -H Sets the minimum heap size (default 0M) Egs: -H24m -H1G numa001: -xb Sets the address from which a suitable start for the heap memory numa001: will be searched from. This is useful if the default address numa001: clashes with some third-party library. numa001: -m Minimum % of heap which must be available (default 3%) numa001: -G Number of generations (default: 2) numa001: -c Use in-place compaction instead of copying in the oldest generation numa001: when live data is at least % of the maximum heap size set with numa001: -M (default: 30%) numa001: -c Use in-place compaction for all oldest generation collections numa001: (the default is to use copying) numa001: -w Use mark-region for the oldest generation (experimental) numa001: -I Perform full GC after idle time (default: 0.3, 0 == off) numa001: numa001: -T Collect GC statistics (useful for in-program statistics access) numa001: -t[] One-line GC statistics (if omitted, uses stderr) numa001: -s[] Summary GC statistics (if omitted, uses stderr) numa001: -S[] Detailed GC statistics (if omitted, uses stderr) numa001: numa001: numa001: -Z Don't squeeze out update frames on stack overflow numa001: -B Sound the bell at the start of each garbage collection numa001: numa001: -hT Produce a heap profile grouped by closure type numa001: -l[flags] Log events in binary format to the file .eventlog numa001: -v[flags] Log events to stderr numa001: where [flags] can contain: numa001: s scheduler events numa001: g GC and heap events numa001: p par spark events (sampled) numa001: f par spark events (full detail) numa001: u user events (emitted from Haskell code) numa001: a all event classes above numa001: t add time stamps (only useful with -v) numa001: -x disable an event class, for any flag above numa001: the initial enabled event classes are 'sgpu' numa001: numa001: -h Heap residency profile (output file .hp) numa001: -i Time between heap profile samples (seconds, default: 0.1) numa001: numa001: -r Produce ticky-ticky statistics (with -rstderr for stderr) numa001: numa001: -C Context-switch interval in seconds. numa001: 0 or no argument means switch as often as possible. numa001: Default: 0.02 sec. numa001: -V Master tick interval in seconds (0 == disable timer). numa001: This sets the resolution for -C and the heap profile timer -i, numa001: and is the frequency of time profile samples. numa001: Default: 0.01 sec. numa001: numa001: -Ds DEBUG: scheduler numa001: -Di DEBUG: interpreter numa001: -Dw DEBUG: weak numa001: -DG DEBUG: gccafs numa001: -Dg DEBUG: gc numa001: -Db DEBUG: block numa001: -DS DEBUG: sanity numa001: -Dt DEBUG: stable numa001: -Dp DEBUG: prof numa001: -Da DEBUG: apply numa001: -Dl DEBUG: linker numa001: -Dm DEBUG: stm numa001: -Dz DEBUG: stack squeezing numa001: -Dc DEBUG: program coverage numa001: -Dr DEBUG: sparks numa001: -DC DEBUG: compact numa001: numa001: NOTE: DEBUG events are sent to stderr by default; add -l to create a numa001: binary event log file instead. numa001: numa001: --install-signal-handlers= numa001: Install signal handlers (default: yes) numa001: -e Maximum number of outstanding local sparks (default: 4096) numa001: -xm Base address to mmap memory in the GHCi linker numa001: (hex; must be <80000000) numa001: -xq The allocation limit given to a thread after it receives numa001: an AllocationLimitExceeded exception. (default: 100k) numa001: numa001: -Mgrace= numa001: The amount of allocation after the program receives a numa001: HeapOverflow exception before the exception is thrown again, if numa001: the program is still exceeding the heap limit. numa001: numa001: RTS options may also be specified using the GHCRTS environment variable. numa001: numa001: Other RTS options may be available for programs compiled a different way. numa001: The GHC User's Guide has full details. numa001: *** unexpected failure for numa001(debug_numa) }}} **T11760** {{{ Wrong exit code for T11760(normal)(expected 0 , actual 1 ) Stderr ( T11760 ): T11760: unknown RTS option: -N2 T11760: T11760: Usage: [+RTS | -RTS ] ... --RTS T11760: T11760: +RTS Indicates run time system options follow T11760: -RTS Indicates program arguments follow T11760: --RTS Indicates that ALL subsequent arguments will be given to the T11760: program (including any of these RTS flags) T11760: T11760: The following run time system options are available: T11760: T11760: -? Prints this message and exits; the program is not executed T11760: --info Print information about the RTS used by this program T11760: T11760: -K Sets the maximum stack size (default: 80% of the heap) T11760: Egs: -K32k -K512k -K8M T11760: -ki Sets the initial thread stack size (default 1k) Egs: -ki4k -ki2m T11760: -kc Sets the stack chunk size (default 32k) T11760: -kb Sets the stack chunk buffer size (default 1k) T11760: T11760: -A Sets the minimum allocation area size (default 1m) Egs: -A20m -A10k T11760: -AL Sets the amount of large-object memory that can be allocated T11760: before a GC is triggered (default: the value of -A) T11760: -n Allocation area chunk size (0 = disabled, default: 0) T11760: -O Sets the minimum size of the old generation (default 1M) T11760: -M Sets the maximum heap size (default unlimited) Egs: -M256k -M1G T11760: -H Sets the minimum heap size (default 0M) Egs: -H24m -H1G T11760: -xb Sets the address from which a suitable start for the heap memory T11760: will be searched from. This is useful if the default address T11760: clashes with some third-party library. T11760: -m Minimum % of heap which must be available (default 3%) T11760: -G Number of generations (default: 2) T11760: -c Use in-place compaction instead of copying in the oldest generation T11760: when live data is at least % of the maximum heap size set with T11760: -M (default: 30%) T11760: -c Use in-place compaction for all oldest generation collections T11760: (the default is to use copying) T11760: -w Use mark-region for the oldest generation (experimental) T11760: -I Perform full GC after idle time (default: 0.3, 0 == off) T11760: T11760: -T Collect GC statistics (useful for in-program statistics access) T11760: -t[] One-line GC statistics (if omitted, uses stderr) T11760: -s[] Summary GC statistics (if omitted, uses stderr) T11760: -S[] Detailed GC statistics (if omitted, uses stderr) T11760: T11760: T11760: -Z Don't squeeze out update frames on stack overflow T11760: -B Sound the bell at the start of each garbage collection T11760: T11760: -hT Produce a heap profile grouped by closure type T11760: -h Heap residency profile (output file .hp) T11760: -i Time between heap profile samples (seconds, default: 0.1) T11760: T11760: -C Context-switch interval in seconds. T11760: 0 or no argument means switch as often as possible. T11760: Default: 0.02 sec. T11760: -V Master tick interval in seconds (0 == disable timer). T11760: This sets the resolution for -C and the heap profile timer -i, T11760: and is the frequency of time profile samples. T11760: Default: 0.01 sec. T11760: T11760: --install-signal-handlers= T11760: Install signal handlers (default: yes) T11760: -e Maximum number of outstanding local sparks (default: 4096) T11760: -xm Base address to mmap memory in the GHCi linker T11760: (hex; must be <80000000) T11760: -xq The allocation limit given to a thread after it receives T11760: an AllocationLimitExceeded exception. (default: 100k) T11760: T11760: -Mgrace= T11760: The amount of allocation after the program receives a T11760: HeapOverflow exception before the exception is thrown again, if T11760: the program is still exceeding the heap limit. T11760: T11760: RTS options may also be specified using the GHCRTS environment variable. T11760: T11760: Other RTS options may be available for programs compiled a different way. T11760: The GHC User's Guide has full details. T11760: *** unexpected failure for T11760(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 14:23:12 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 14:23:12 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.c5b7de2462c0f4a27cd2ae0ed5f7f5a0@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:75 goldfire]: > Very interesting. What happens if you make a version of `FV` that uses its same setup (passing around partially applied functions, etc.) but without the list? Then rewrite the functions in terms of that? Ah, good point, I'll try that. Shouldn't be overly difficult. > Also, I think it would be helpful not to use ticky profiling when generating these results (unless the data somehow comes from the ticky output), but also to include the allocations. Right, of course. The data is just plain old `time --verbose`; the reason I have `-ticky` there is because the idea was to generate ticky profiles at the same time, and the thought behind it was that ticky overhead would be somewhat proportional, and thus not disruptive. But I'll do another run without ticky. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 14:29:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 14:29:20 -0000 Subject: [GHC] #9441: CSE should deal with letrec In-Reply-To: <045.987758d932a89023c69da6c12f8363f5@haskell.org> References: <045.987758d932a89023c69da6c12f8363f5@haskell.org> Message-ID: <060.50d55be7a0c0e331217bcedd618e7321@haskell.org> #9441: CSE should deal with letrec -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: RolandSenn Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: CSE Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: (none) => RolandSenn Comment: I'll try to add the missing regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 14:33:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 14:33:31 -0000 Subject: [GHC] #15466: debug validation failures In-Reply-To: <048.92e70258a7492f32c7bd776d901c7bf2@haskell.org> References: <048.92e70258a7492f32c7bd776d901c7bf2@haskell.org> Message-ID: <063.92545c365cc3961d8bf337263e9c90ee@haskell.org> #15466: debug validation failures ---------------------------------+-------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): Hmm, I'm a bit confused; the references to `PprC` makes me think that this is being built unregisterised for some reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 14:34:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 14:34:53 -0000 Subject: [GHC] #15466: debug validation failures In-Reply-To: <048.92e70258a7492f32c7bd776d901c7bf2@haskell.org> References: <048.92e70258a7492f32c7bd776d901c7bf2@haskell.org> Message-ID: <063.feb9842eb676ff3aa6a3701b5a59dbc4@haskell.org> #15466: debug validation failures ---------------------------------+-------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by bgamari): Ahhh, I see; it looks like the `validate-x86_64-linux-debug` test configuration is using `configure_unreg` instead of `configure_unix`. I suspect this is my cut-and-paste error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 14:39:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 14:39:47 -0000 Subject: [GHC] #15466: debug validation failures In-Reply-To: <048.92e70258a7492f32c7bd776d901c7bf2@haskell.org> References: <048.92e70258a7492f32c7bd776d901c7bf2@haskell.org> Message-ID: <063.d1fdd1b153299ab1b0e16970243e96ee@haskell.org> #15466: debug validation failures ---------------------------------+-------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5037 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * differential: => Phab:D5037 Comment: Fixed in Phab:D5037. I'd imagine this will fix many, but perhaps not all, of the issues reported above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 14:45:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 14:45:15 -0000 Subject: [GHC] #12096: Attach stacktrace information to SomeException In-Reply-To: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> References: <049.d8705f5da8c3125826af35f329bd903a@haskell.org> Message-ID: <064.03ed42011b32993919594b75557ad378@haskell.org> #12096: Attach stacktrace information to SomeException -------------------------------------+------------------------------------- Reporter: ndtimofeev | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Exceptions Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13372 | Differential Rev(s): Wiki Page: | Exceptions/StackTraces | -------------------------------------+------------------------------------- Changes (by k-bx): * cc: k-bx (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 15:17:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 15:17:22 -0000 Subject: [GHC] #15467: unregisterised validation failures Message-ID: <048.3355061b396ea4e51fa8e18011bf957e@haskell.org> #15467: unregisterised validation failures --------------------------------------+--------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: T7040_ghci | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- The most recent completed run of `validate-x86_64-linux-unreg` on Circle CI (​https://circleci.com/gh/ghc/ghc/7733) shows 13 unexpected failures and 1 unexpected pass. **Summary** {{{ Unexpected passes: concurrent/T13615/T13615.run T13615 [unexpected] (ghci) Unexpected failures: codeGen/should_compile/T9329.run T9329 [exit code non-0] (normal) codeGen/should_run/cgrun018.run cgrun018 [exit code non-0] (normal) codeGen/should_run/cgrun018.run cgrun018 [exit code non-0] (g1) codeGen/should_run/cgrun069.run cgrun069 [exit code non-0] (normal) codeGen/should_run/cgrun069.run cgrun069 [exit code non-0] (g1) codeGen/should_run/T9577.run T9577 [bad stdout] (normal) concurrent/should_run/T3429.run T3429 [bad exit code] (debug_numa) driver/T14075/T14075.run T14075 [bad stderr] (normal) rts/T7040_ghci.run T7040_ghci [bad stderr] (ghci) rts/T14702.run T14702 [bad exit code] (threaded1) rts/nursery-chunks1.run nursery-chunks1 [bad stderr] (threaded1) rts/numa001.run numa001 [bad exit code] (debug_numa) ../../libraries/base/tests/T11760.run T11760 [bad exit code] (normal) }}} All failures but `T7040_ghci` happen in the debug validation job too (see #15466). `recomp007` doesn't fail here and `T7040_ghci` "replaces" it. I'm therefore only including the details for `T7040_ghci` here, as you can find out everything about the other faiilures in #15466. --- **T7040_ghci** {{{ Actual stderr output differs from expected: --- /dev/null 2018-08-01 14:20:42.758797000 +0000 +++ ./rts/T7040_ghci.run/T7040_ghci.run.stderr.normalised 2018-08-02 04:15:35.594990695 +0000 @@ -0,0 +1,4 @@ + +T7040_ghci:6:30: + Not in scope: ‘Main.main’ + No module named ‘Main’ is imported. *** unexpected failure for T7040_ghci(ghci) }}} I suspect this is one of those cases where ghci can't load the module because of unboxed sums and what not, I havent' checked yet, but we were seeing that type of error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 15:30:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 15:30:32 -0000 Subject: [GHC] #15466: debug validation failures In-Reply-To: <048.92e70258a7492f32c7bd776d901c7bf2@haskell.org> References: <048.92e70258a7492f32c7bd776d901c7bf2@haskell.org> Message-ID: <063.bc94c103996f550cd6640fb72722f8d7@haskell.org> #15466: debug validation failures ---------------------------------+-------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by alpmestan): * differential: Phab:D5037 => Comment: All the failures that are in common with #15467 are in fact due to the debug validation job building an unregisterised GHC, as you pointed out above and fixed by: https://phabricator.haskell.org/D5037 So the only "proper" `debug` failure would seem to be: {{{ driver/recomp007/recomp007.run recomp007 [bad stderr] (norma }}} At least that's what we can assume until your patch lands in master and Circle CI builds it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 15:35:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 15:35:01 -0000 Subject: [GHC] #15467: unregisterised validation failures In-Reply-To: <048.3355061b396ea4e51fa8e18011bf957e@haskell.org> References: <048.3355061b396ea4e51fa8e18011bf957e@haskell.org> Message-ID: <063.9dc6c12c7d8538ab8cb0ff090e25be01@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: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by alpmestan): The failures that are in common with #15466 are in fact due to the fact that the debug validation job was building unregisterised GHCs. That will be fixed with D5037. All but one of the failures from #15466 would likely be due to the unregisterised nature of the GHC under test, so I'm reproducing the details for them here, below, since this is where they really belong. ---- **T9329** {{{ Compile failed (exit code 1) errors were: /tmp/ghc78722_0/ghc_4.hc: In function ‘bar’: /tmp/ghc78722_0/ghc_4.hc:18:12: error: error: ‘c6_info’ undeclared (first use in this function) *Sp = (W_)&c6_info; ^ /tmp/ghc78722_0/ghc_4.hc:18:12: error: note: each undeclared identifier is reported only once for each function it appears in `gcc' failed in phase `C Compiler'. (Exit code: 1) *** unexpected failure for T9329(normal) }}} **cgrun018** {{{ Compile failed (exit code 1) errors were: [1 of 1] Compiling Main ( cgrun018.hs, cgrun018.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20180731 for x86_64-unknown-linux): pprStatics: float F32 F32 F32 F32 F32 F32 F32 F32 F32 F32 F32 Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/cmm/PprC.hs:521:5 in ghc:PprC Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for cgrun018(normal) --- Compile failed (exit code 1) errors were: [1 of 1] Compiling Main ( cgrun018.hs, cgrun018.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20180731 for x86_64-unknown-linux): pprStatics: float F32 F32 F32 F32 F32 F32 F32 F32 F32 F32 F32 Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/cmm/PprC.hs:521:5 in ghc:PprC Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for cgrun018(g1) }}} **cgrun069** {{{ Compile failed (exit code 1) errors were: /tmp/ghc83995_0/ghc_4.hc:5:12: error: error: conflicting types for ‘memsetErr’ const char memsetErr[] = "Memset Error - align: %d size: %d\012"; ^ In file included from /tmp/ghc83995_0/ghc_4.hc:3:0: error: /tmp/ghc83995_0/ghc_4.hc:4:6: error: note: previous declaration of ‘memsetErr’ was here ERW_(memsetErr); ^ /home/ghc/project/includes/Stg.h:242:46: error: note: in definition of macro ‘ERW_’ #define ERW_(X) extern StgWordArray (X) ^ /tmp/ghc83995_0/ghc_4.hc:8:12: error: error: conflicting types for ‘memcpyErr’ const char memcpyErr[] = "Memcpy Error - align: %d size: %d\012"; ^ In file included from /tmp/ghc83995_0/ghc_4.hc:3:0: error: /tmp/ghc83995_0/ghc_4.hc:7:6: error: note: previous declaration of ‘memcpyErr’ was here ERW_(memcpyErr); ^ /home/ghc/project/includes/Stg.h:242:46: error: note: in definition of macro ‘ERW_’ #define ERW_(X) extern StgWordArray (X) ^ /tmp/ghc83995_0/ghc_4.hc:11:12: error: error: conflicting types for ‘memmoveErr’ const char memmoveErr[] = "Memmove Error Occured\012"; ^ In file included from /tmp/ghc83995_0/ghc_4.hc:3:0: error: /tmp/ghc83995_0/ghc_4.hc:10:6: error: note: previous declaration of ‘memmoveErr’ was here ERW_(memmoveErr); ^ /home/ghc/project/includes/Stg.h:242:46: error: note: in definition of macro ‘ERW_’ #define ERW_(X) extern StgWordArray (X) ^ `gcc' failed in phase `C Compiler'. (Exit code: 1) *** unexpected failure for cgrun069(normal) --- Compile failed (exit code 1) errors were: /tmp/ghc84416_0/ghc_4.hc:5:12: error: error: conflicting types for ‘memsetErr’ const char memsetErr[] = "Memset Error - align: %d size: %d\012"; ^ In file included from /tmp/ghc84416_0/ghc_4.hc:3:0: error: /tmp/ghc84416_0/ghc_4.hc:4:6: error: note: previous declaration of ‘memsetErr’ was here ERW_(memsetErr); ^ /home/ghc/project/includes/Stg.h:242:46: error: note: in definition of macro ‘ERW_’ #define ERW_(X) extern StgWordArray (X) ^ /tmp/ghc84416_0/ghc_4.hc:8:12: error: error: conflicting types for ‘memcpyErr’ const char memcpyErr[] = "Memcpy Error - align: %d size: %d\012"; ^ In file included from /tmp/ghc84416_0/ghc_4.hc:3:0: error: /tmp/ghc84416_0/ghc_4.hc:7:6: error: note: previous declaration of ‘memcpyErr’ was here ERW_(memcpyErr); ^ /home/ghc/project/includes/Stg.h:242:46: error: note: in definition of macro ‘ERW_’ #define ERW_(X) extern StgWordArray (X) ^ /tmp/ghc84416_0/ghc_4.hc:11:12: error: error: conflicting types for ‘memmoveErr’ const char memmoveErr[] = "Memmove Error Occured\012"; ^ In file included from /tmp/ghc84416_0/ghc_4.hc:3:0: error: /tmp/ghc84416_0/ghc_4.hc:10:6: error: note: previous declaration of ‘memmoveErr’ was here ERW_(memmoveErr); ^ /home/ghc/project/includes/Stg.h:242:46: error: note: in definition of macro ‘ERW_’ #define ERW_(X) extern StgWordArray (X) ^ `gcc' failed in phase `C Compiler'. (Exit code: 1) *** unexpected failure for cgrun069(g1) }}} **T9577** {{{ --- ./codeGen/should_run/T9577.run/T9577.stdout.normalised 2018-08-02 03:38:39.932680724 +0000 +++ ./codeGen/should_run/T9577.run/T9577.run.stdout.normalised 2018-08-02 03:38:39.932680724 +0000 @@ -1 +1 @@ -True +False *** unexpected failure for T9577(normal) }}} **T3429** {{{ Wrong exit code for T3429(debug_numa)(expected 0 , actual 1 ) Stderr ( T3429 ): T3429: unknown RTS option: -N2 T3429: T3429: Usage: [+RTS | -RTS ] ... --RTS T3429: T3429: +RTS Indicates run time system options follow T3429: -RTS Indicates program arguments follow T3429: --RTS Indicates that ALL subsequent arguments will be given to the T3429: program (including any of these RTS flags) T3429: T3429: The following run time system options are available: T3429: T3429: -? Prints this message and exits; the program is not executed T3429: --info Print information about the RTS used by this program T3429: T3429: -K Sets the maximum stack size (default: 80% of the heap) T3429: Egs: -K32k -K512k -K8M T3429: -ki Sets the initial thread stack size (default 1k) Egs: -ki4k -ki2m T3429: -kc Sets the stack chunk size (default 32k) T3429: -kb Sets the stack chunk buffer size (default 1k) T3429: T3429: -A Sets the minimum allocation area size (default 1m) Egs: -A20m -A10k T3429: -AL Sets the amount of large-object memory that can be allocated T3429: before a GC is triggered (default: the value of -A) T3429: -n Allocation area chunk size (0 = disabled, default: 0) T3429: -O Sets the minimum size of the old generation (default 1M) T3429: -M Sets the maximum heap size (default unlimited) Egs: -M256k -M1G T3429: -H Sets the minimum heap size (default 0M) Egs: -H24m -H1G T3429: -xb Sets the address from which a suitable start for the heap memory T3429: will be searched from. This is useful if the default address T3429: clashes with some third-party library. T3429: -m Minimum % of heap which must be available (default 3%) T3429: -G Number of generations (default: 2) T3429: -c Use in-place compaction instead of copying in the oldest generation T3429: when live data is at least % of the maximum heap size set with T3429: -M (default: 30%) T3429: -c Use in-place compaction for all oldest generation collections T3429: (the default is to use copying) T3429: -w Use mark-region for the oldest generation (experimental) T3429: -I Perform full GC after idle time (default: 0.3, 0 == off) T3429: T3429: -T Collect GC statistics (useful for in-program statistics access) T3429: -t[] One-line GC statistics (if omitted, uses stderr) T3429: -s[] Summary GC statistics (if omitted, uses stderr) T3429: -S[] Detailed GC statistics (if omitted, uses stderr) T3429: T3429: T3429: -Z Don't squeeze out update frames on stack overflow T3429: -B Sound the bell at the start of each garbage collection T3429: T3429: -hT Produce a heap profile grouped by closure type T3429: -l[flags] Log events in binary format to the file .eventlog T3429: -v[flags] Log events to stderr T3429: where [flags] can contain: T3429: s scheduler events T3429: g GC and heap events T3429: p par spark events (sampled) T3429: f par spark events (full detail) T3429: u user events (emitted from Haskell code) T3429: a all event classes above T3429: t add time stamps (only useful with -v) T3429: -x disable an event class, for any flag above T3429: the initial enabled event classes are 'sgpu' T3429: T3429: -h Heap residency profile (output file .hp) T3429: -i Time between heap profile samples (seconds, default: 0.1) T3429: T3429: -r Produce ticky-ticky statistics (with -rstderr for stderr) T3429: T3429: -C Context-switch interval in seconds. T3429: 0 or no argument means switch as often as possible. T3429: Default: 0.02 sec. T3429: -V Master tick interval in seconds (0 == disable timer). T3429: This sets the resolution for -C and the heap profile timer -i, T3429: and is the frequency of time profile samples. T3429: Default: 0.01 sec. T3429: T3429: -Ds DEBUG: scheduler T3429: -Di DEBUG: interpreter T3429: -Dw DEBUG: weak T3429: -DG DEBUG: gccafs T3429: -Dg DEBUG: gc T3429: -Db DEBUG: block T3429: -DS DEBUG: sanity T3429: -Dt DEBUG: stable T3429: -Dp DEBUG: prof T3429: -Da DEBUG: apply T3429: -Dl DEBUG: linker T3429: -Dm DEBUG: stm T3429: -Dz DEBUG: stack squeezing T3429: -Dc DEBUG: program coverage T3429: -Dr DEBUG: sparks T3429: -DC DEBUG: compact T3429: T3429: NOTE: DEBUG events are sent to stderr by default; add -l to create a T3429: binary event log file instead. T3429: T3429: --install-signal-handlers= T3429: Install signal handlers (default: yes) T3429: -e Maximum number of outstanding local sparks (default: 4096) T3429: -xm Base address to mmap memory in the GHCi linker T3429: (hex; must be <80000000) T3429: -xq The allocation limit given to a thread after it receives T3429: an AllocationLimitExceeded exception. (default: 100k) T3429: T3429: -Mgrace= T3429: The amount of allocation after the program receives a T3429: HeapOverflow exception before the exception is thrown again, if T3429: the program is still exceeding the heap limit. T3429: T3429: RTS options may also be specified using the GHCRTS environment variable. T3429: T3429: Other RTS options may be available for programs compiled a different way. T3429: The GHC User's Guide has full details. T3429: *** unexpected failure for T3429(debug_numa) }}} **T13615** {{{ *** unexpected pass for T13615(ghci) }}} **T14075** {{{ Actual stderr output differs from expected: --- ./driver/T14075/T14075.run/T14075.stderr.normalised 2018-08-02 03:40:01.063504007 +0000 +++ ./driver/T14075/T14075.run/T14075.run.stderr.normalised 2018-08-02 03:40:01.063504007 +0000 @@ -1,3 +1,4 @@ +ghc: setNumCapabilities: not supported on this platform F.hs:1:1: instance O.O F.F -- Defined at F.hs-boot:6:10 *** unexpected failure for T14075(normal) }}} **recomp007** {{{ Actual stderr output differs from expected: --- /dev/null 2018-08-01 14:11:13.420752000 +0000 +++ ./driver/recomp007/recomp007.run/recomp007.run.stderr.normalised 2018-08-02 03:40:46.313078664 +0000 @@ -0,0 +1,122 @@ +WARNING: file compiler/utils/ListSetOps.hs, line 58 + [] + [Distribution.Backpack, Distribution.Backpack.FullUnitId, + Distribution.Backpack.ModuleShape, + Distribution.Backpack.PreModuleShape, + Distribution.Backpack.ReadyComponent, + Distribution.CabalSpecVersion, Distribution.Compat.Graph, + Distribution.Compat.Semigroup, Distribution.Compiler, + Distribution.License, Distribution.ModuleName, + Distribution.Parsec.Common, Distribution.SPDX.License, + Distribution.SPDX.LicenseExceptionId, + Distribution.SPDX.LicenseExpression, Distribution.SPDX.LicenseId, + Distribution.SPDX.LicenseReference, + Distribution.Simple.BuildTarget, Distribution.Simple.Compiler, + Distribution.Simple.Doctest, Distribution.Simple.Flag, + Distribution.Simple.Haddock, Distribution.Simple.InstallDirs, + Distribution.Simple.PackageIndex, Distribution.Simple.Program.Find, + Distribution.Simple.Program.GHC, Distribution.Simple.Program.Types, + Distribution.Simple.Setup, Distribution.System, + Distribution.Types.AbiDependency, Distribution.Types.AbiHash, + Distribution.Types.Benchmark, + Distribution.Types.BenchmarkInterface, + Distribution.Types.BenchmarkType, Distribution.Types.BuildInfo, + Distribution.Types.BuildType, Distribution.Types.ComponentId, + Distribution.Types.ComponentLocalBuildInfo, + Distribution.Types.ComponentName, + Distribution.Types.ComponentRequestedSpec, + Distribution.Types.CondTree, Distribution.Types.Condition, + Distribution.Types.Dependency, Distribution.Types.ExeDependency, + Distribution.Types.Executable, Distribution.Types.ExecutableScope, + Distribution.Types.ExposedModule, Distribution.Types.ForeignLib, + Distribution.Types.ForeignLibOption, + Distribution.Types.ForeignLibType, + Distribution.Types.GenericPackageDescription, + Distribution.Types.IncludeRenaming, + Distribution.Types.InstalledPackageInfo, + Distribution.Types.LegacyExeDependency, Distribution.Types.Library, + Distribution.Types.LocalBuildInfo, Distribution.Types.Mixin, + Distribution.Types.Module, Distribution.Types.ModuleReexport, + Distribution.Types.ModuleRenaming, + Distribution.Types.MungedPackageId, + Distribution.Types.MungedPackageName, + Distribution.Types.PackageDescription, + Distribution.Types.PackageId, Distribution.Types.PackageName, + Distribution.Types.PkgconfigDependency, + Distribution.Types.PkgconfigName, + Distribution.Types.SetupBuildInfo, Distribution.Types.SourceRepo, + Distribution.Types.TargetInfo, Distribution.Types.TestSuite, + Distribution.Types.TestSuiteInterface, Distribution.Types.TestType, + Distribution.Types.UnitId, Distribution.Types.UnqualComponentName, + Distribution.Types.Version, Distribution.Types.VersionRange, + Distribution.Utils.ShortText, Distribution.Verbosity, + Language.Haskell.Extension, Control.Applicative, Data.Complex, + Data.Functor.Compose, Data.Functor.Const, Data.Functor.Identity, + Data.Functor.Product, Data.Functor.Sum, Data.Monoid, + Data.Semigroup, Data.Semigroup.Internal, Data.Version, Data.Void, + GHC.Exts, GHC.Generics, GHC.IO.Exception, Data.Graph, + Data.IntMap.Internal, Data.IntSet.Internal, Data.Map.Internal, + Data.Sequence.Internal, Data.Set.Internal, Data.Tree, + Text.PrettyPrint.Annotated.HughesPJ, Text.PrettyPrint.HughesPJ, + Data.Text, Data.Text.Lazy] +WARNING: file compiler/utils/ListSetOps.hs, line 58 + [Distribution.Backpack, Distribution.Backpack.FullUnitId, + Distribution.Backpack.ModuleShape, + Distribution.Backpack.PreModuleShape, + Distribution.Backpack.ReadyComponent, + Distribution.CabalSpecVersion, Distribution.Compat.Graph, + Distribution.Compat.Semigroup, Distribution.Compiler, + Distribution.License, Distribution.ModuleName, + Distribution.Parsec.Common, Distribution.SPDX.License, + Distribution.SPDX.LicenseExceptionId, + Distribution.SPDX.LicenseExpression, Distribution.SPDX.LicenseId, + Distribution.SPDX.LicenseReference, + Distribution.Simple.BuildTarget, Distribution.Simple.Compiler, + Distribution.Simple.Doctest, Distribution.Simple.Flag, + Distribution.Simple.Haddock, Distribution.Simple.InstallDirs, + Distribution.Simple.PackageIndex, Distribution.Simple.Program.Find, + Distribution.Simple.Program.GHC, Distribution.Simple.Program.Types, + Distribution.Simple.Setup, Distribution.System, + Distribution.Types.AbiDependency, Distribution.Types.AbiHash, + Distribution.Types.Benchmark, + Distribution.Types.BenchmarkInterface, + Distribution.Types.BenchmarkType, Distribution.Types.BuildInfo, + Distribution.Types.BuildType, Distribution.Types.ComponentId, + Distribution.Types.ComponentLocalBuildInfo, + Distribution.Types.ComponentName, + Distribution.Types.ComponentRequestedSpec, + Distribution.Types.CondTree, Distribution.Types.Condition, + Distribution.Types.Dependency, Distribution.Types.ExeDependency, + Distribution.Types.Executable, Distribution.Types.ExecutableScope, + Distribution.Types.ExposedModule, Distribution.Types.ForeignLib, + Distribution.Types.ForeignLibOption, + Distribution.Types.ForeignLibType, + Distribution.Types.GenericPackageDescription, + Distribution.Types.IncludeRenaming, + Distribution.Types.InstalledPackageInfo, + Distribution.Types.LegacyExeDependency, Distribution.Types.Library, + Distribution.Types.LocalBuildInfo, Distribution.Types.Mixin, + Distribution.Types.Module, Distribution.Types.ModuleReexport, + Distribution.Types.ModuleRenaming, + Distribution.Types.MungedPackageId, + Distribution.Types.MungedPackageName, + Distribution.Types.PackageDescription, + Distribution.Types.PackageId, Distribution.Types.PackageName, + Distribution.Types.PkgconfigDependency, + Distribution.Types.PkgconfigName, + Distribution.Types.SetupBuildInfo, Distribution.Types.SourceRepo, + Distribution.Types.TargetInfo, Distribution.Types.TestSuite, + Distribution.Types.TestSuiteInterface, Distribution.Types.TestType, + Distribution.Types.UnitId, Distribution.Types.UnqualComponentName, + Distribution.Types.Version, Distribution.Types.VersionRange, + Distribution.Utils.ShortText, Distribution.Verbosity, + Language.Haskell.Extension, Control.Applicative, Data.Complex, + Data.Functor.Compose, Data.Functor.Const, Data.Functor.Identity, + Data.Functor.Product, Data.Functor.Sum, Data.Monoid, + Data.Semigroup, Data.Semigroup.Internal, Data.Version, Data.Void, + GHC.Exts, GHC.Generics, GHC.IO.Exception, Data.Graph, + Data.IntMap.Internal, Data.IntSet.Internal, Data.Map.Internal, + Data.Sequence.Internal, Data.Set.Internal, Data.Tree, + Text.PrettyPrint.Annotated.HughesPJ, Text.PrettyPrint.HughesPJ, + Data.Text, Data.Text.Lazy] + [] *** unexpected failure for recomp007(normal) }}} **T14702** {{{ Wrong exit code for T14702(threaded1)(expected 0 , actual 1 ) Stderr ( T14702 ): T14702: unknown RTS option: -N8 T14702: T14702: Usage: [+RTS | -RTS ] ... --RTS T14702: T14702: +RTS Indicates run time system options follow T14702: -RTS Indicates program arguments follow T14702: --RTS Indicates that ALL subsequent arguments will be given to the T14702: program (including any of these RTS flags) T14702: T14702: The following run time system options are available: T14702: T14702: -? Prints this message and exits; the program is not executed T14702: --info Print information about the RTS used by this program T14702: T14702: -K Sets the maximum stack size (default: 80% of the heap) T14702: Egs: -K32k -K512k -K8M T14702: -ki Sets the initial thread stack size (default 1k) Egs: -ki4k -ki2m T14702: -kc Sets the stack chunk size (default 32k) T14702: -kb Sets the stack chunk buffer size (default 1k) T14702: T14702: -A Sets the minimum allocation area size (default 1m) Egs: -A20m -A10k T14702: -AL Sets the amount of large-object memory that can be allocated T14702: before a GC is triggered (default: the value of -A) T14702: -n Allocation area chunk size (0 = disabled, default: 0) T14702: -O Sets the minimum size of the old generation (default 1M) T14702: -M Sets the maximum heap size (default unlimited) Egs: -M256k -M1G T14702: -H Sets the minimum heap size (default 0M) Egs: -H24m -H1G T14702: -xb Sets the address from which a suitable start for the heap memory T14702: will be searched from. This is useful if the default address T14702: clashes with some third-party library. T14702: -m Minimum % of heap which must be available (default 3%) T14702: -G Number of generations (default: 2) T14702: -c Use in-place compaction instead of copying in the oldest generation T14702: when live data is at least % of the maximum heap size set with T14702: -M (default: 30%) T14702: -c Use in-place compaction for all oldest generation collections T14702: (the default is to use copying) T14702: -w Use mark-region for the oldest generation (experimental) T14702: -I Perform full GC after idle time (default: 0.3, 0 == off) T14702: T14702: -T Collect GC statistics (useful for in-program statistics access) T14702: -t[] One-line GC statistics (if omitted, uses stderr) T14702: -s[] Summary GC statistics (if omitted, uses stderr) T14702: -S[] Detailed GC statistics (if omitted, uses stderr) T14702: T14702: T14702: -Z Don't squeeze out update frames on stack overflow T14702: -B Sound the bell at the start of each garbage collection T14702: T14702: -hT Produce a heap profile grouped by closure type T14702: -l[flags] Log events in binary format to the file .eventlog T14702: -v[flags] Log events to stderr T14702: where [flags] can contain: T14702: s scheduler events T14702: g GC and heap events T14702: p par spark events (sampled) T14702: f par spark events (full detail) T14702: u user events (emitted from Haskell code) T14702: a all event classes above T14702: t add time stamps (only useful with -v) T14702: -x disable an event class, for any flag above T14702: the initial enabled event classes are 'sgpu' T14702: T14702: -h Heap residency profile (output file .hp) T14702: -i Time between heap profile samples (seconds, default: 0.1) T14702: T14702: -r Produce ticky-ticky statistics (with -rstderr for stderr) T14702: T14702: -C Context-switch interval in seconds. T14702: 0 or no argument means switch as often as possible. T14702: Default: 0.02 sec. T14702: -V Master tick interval in seconds (0 == disable timer). T14702: This sets the resolution for -C and the heap profile timer -i, T14702: and is the frequency of time profile samples. T14702: Default: 0.01 sec. T14702: T14702: -Ds DEBUG: scheduler T14702: -Di DEBUG: interpreter T14702: -Dw DEBUG: weak T14702: -DG DEBUG: gccafs T14702: -Dg DEBUG: gc T14702: -Db DEBUG: block T14702: -DS DEBUG: sanity T14702: -Dt DEBUG: stable T14702: -Dp DEBUG: prof T14702: -Da DEBUG: apply T14702: -Dl DEBUG: linker T14702: -Dm DEBUG: stm T14702: -Dz DEBUG: stack squeezing T14702: -Dc DEBUG: program coverage T14702: -Dr DEBUG: sparks T14702: -DC DEBUG: compact T14702: T14702: NOTE: DEBUG events are sent to stderr by default; add -l to create a T14702: binary event log file instead. T14702: T14702: --install-signal-handlers= T14702: Install signal handlers (default: yes) T14702: -e Maximum number of outstanding local sparks (default: 4096) T14702: -xm Base address to mmap memory in the GHCi linker T14702: (hex; must be <80000000) T14702: -xq The allocation limit given to a thread after it receives T14702: an AllocationLimitExceeded exception. (default: 100k) T14702: T14702: -Mgrace= T14702: The amount of allocation after the program receives a T14702: HeapOverflow exception before the exception is thrown again, if T14702: the program is still exceeding the heap limit. T14702: T14702: RTS options may also be specified using the GHCRTS environment variable. T14702: T14702: Other RTS options may be available for programs compiled a different way. T14702: The GHC User's Guide has full details. T14702: *** unexpected failure for T14702(threaded1) }}} **nursery-chunks1** {{{ Actual stderr output differs from expected: --- /dev/null 2018-08-01 14:11:13.420752000 +0000 +++ ./rts/nursery-chunks1.run/nursery-chunks1.run.stderr.normalised 2018-08-02 03:45:18.786560729 +0000 @@ -0,0 +1,3 @@ +nursery-chunks1: setNumCapabilities: not supported on this platform +nursery-chunks1: setNumCapabilities: not supported on this platform +nursery-chunks1: setNumCapabilities: not supported on this platform *** unexpected failure for nursery-chunks1(threaded1) }}} **numa001** {{{ Wrong exit code for numa001(debug_numa)(expected 0 , actual 1 ) Stderr ( numa001 ): numa001: unknown RTS option: -N2 numa001: numa001: Usage: [+RTS | -RTS ] ... --RTS numa001: numa001: +RTS Indicates run time system options follow numa001: -RTS Indicates program arguments follow numa001: --RTS Indicates that ALL subsequent arguments will be given to the numa001: program (including any of these RTS flags) numa001: numa001: The following run time system options are available: numa001: numa001: -? Prints this message and exits; the program is not executed numa001: --info Print information about the RTS used by this program numa001: numa001: -K Sets the maximum stack size (default: 80% of the heap) numa001: Egs: -K32k -K512k -K8M numa001: -ki Sets the initial thread stack size (default 1k) Egs: -ki4k -ki2m numa001: -kc Sets the stack chunk size (default 32k) numa001: -kb Sets the stack chunk buffer size (default 1k) numa001: numa001: -A Sets the minimum allocation area size (default 1m) Egs: -A20m -A10k numa001: -AL Sets the amount of large-object memory that can be allocated numa001: before a GC is triggered (default: the value of -A) numa001: -n Allocation area chunk size (0 = disabled, default: 0) numa001: -O Sets the minimum size of the old generation (default 1M) numa001: -M Sets the maximum heap size (default unlimited) Egs: -M256k -M1G numa001: -H Sets the minimum heap size (default 0M) Egs: -H24m -H1G numa001: -xb Sets the address from which a suitable start for the heap memory numa001: will be searched from. This is useful if the default address numa001: clashes with some third-party library. numa001: -m Minimum % of heap which must be available (default 3%) numa001: -G Number of generations (default: 2) numa001: -c Use in-place compaction instead of copying in the oldest generation numa001: when live data is at least % of the maximum heap size set with numa001: -M (default: 30%) numa001: -c Use in-place compaction for all oldest generation collections numa001: (the default is to use copying) numa001: -w Use mark-region for the oldest generation (experimental) numa001: -I Perform full GC after idle time (default: 0.3, 0 == off) numa001: numa001: -T Collect GC statistics (useful for in-program statistics access) numa001: -t[] One-line GC statistics (if omitted, uses stderr) numa001: -s[] Summary GC statistics (if omitted, uses stderr) numa001: -S[] Detailed GC statistics (if omitted, uses stderr) numa001: numa001: numa001: -Z Don't squeeze out update frames on stack overflow numa001: -B Sound the bell at the start of each garbage collection numa001: numa001: -hT Produce a heap profile grouped by closure type numa001: -l[flags] Log events in binary format to the file .eventlog numa001: -v[flags] Log events to stderr numa001: where [flags] can contain: numa001: s scheduler events numa001: g GC and heap events numa001: p par spark events (sampled) numa001: f par spark events (full detail) numa001: u user events (emitted from Haskell code) numa001: a all event classes above numa001: t add time stamps (only useful with -v) numa001: -x disable an event class, for any flag above numa001: the initial enabled event classes are 'sgpu' numa001: numa001: -h Heap residency profile (output file .hp) numa001: -i Time between heap profile samples (seconds, default: 0.1) numa001: numa001: -r Produce ticky-ticky statistics (with -rstderr for stderr) numa001: numa001: -C Context-switch interval in seconds. numa001: 0 or no argument means switch as often as possible. numa001: Default: 0.02 sec. numa001: -V Master tick interval in seconds (0 == disable timer). numa001: This sets the resolution for -C and the heap profile timer -i, numa001: and is the frequency of time profile samples. numa001: Default: 0.01 sec. numa001: numa001: -Ds DEBUG: scheduler numa001: -Di DEBUG: interpreter numa001: -Dw DEBUG: weak numa001: -DG DEBUG: gccafs numa001: -Dg DEBUG: gc numa001: -Db DEBUG: block numa001: -DS DEBUG: sanity numa001: -Dt DEBUG: stable numa001: -Dp DEBUG: prof numa001: -Da DEBUG: apply numa001: -Dl DEBUG: linker numa001: -Dm DEBUG: stm numa001: -Dz DEBUG: stack squeezing numa001: -Dc DEBUG: program coverage numa001: -Dr DEBUG: sparks numa001: -DC DEBUG: compact numa001: numa001: NOTE: DEBUG events are sent to stderr by default; add -l to create a numa001: binary event log file instead. numa001: numa001: --install-signal-handlers= numa001: Install signal handlers (default: yes) numa001: -e Maximum number of outstanding local sparks (default: 4096) numa001: -xm Base address to mmap memory in the GHCi linker numa001: (hex; must be <80000000) numa001: -xq The allocation limit given to a thread after it receives numa001: an AllocationLimitExceeded exception. (default: 100k) numa001: numa001: -Mgrace= numa001: The amount of allocation after the program receives a numa001: HeapOverflow exception before the exception is thrown again, if numa001: the program is still exceeding the heap limit. numa001: numa001: RTS options may also be specified using the GHCRTS environment variable. numa001: numa001: Other RTS options may be available for programs compiled a different way. numa001: The GHC User's Guide has full details. numa001: *** unexpected failure for numa001(debug_numa) }}} **T11760** {{{ Wrong exit code for T11760(normal)(expected 0 , actual 1 ) Stderr ( T11760 ): T11760: unknown RTS option: -N2 T11760: T11760: Usage: [+RTS | -RTS ] ... --RTS T11760: T11760: +RTS Indicates run time system options follow T11760: -RTS Indicates program arguments follow T11760: --RTS Indicates that ALL subsequent arguments will be given to the T11760: program (including any of these RTS flags) T11760: T11760: The following run time system options are available: T11760: T11760: -? Prints this message and exits; the program is not executed T11760: --info Print information about the RTS used by this program T11760: T11760: -K Sets the maximum stack size (default: 80% of the heap) T11760: Egs: -K32k -K512k -K8M T11760: -ki Sets the initial thread stack size (default 1k) Egs: -ki4k -ki2m T11760: -kc Sets the stack chunk size (default 32k) T11760: -kb Sets the stack chunk buffer size (default 1k) T11760: T11760: -A Sets the minimum allocation area size (default 1m) Egs: -A20m -A10k T11760: -AL Sets the amount of large-object memory that can be allocated T11760: before a GC is triggered (default: the value of -A) T11760: -n Allocation area chunk size (0 = disabled, default: 0) T11760: -O Sets the minimum size of the old generation (default 1M) T11760: -M Sets the maximum heap size (default unlimited) Egs: -M256k -M1G T11760: -H Sets the minimum heap size (default 0M) Egs: -H24m -H1G T11760: -xb Sets the address from which a suitable start for the heap memory T11760: will be searched from. This is useful if the default address T11760: clashes with some third-party library. T11760: -m Minimum % of heap which must be available (default 3%) T11760: -G Number of generations (default: 2) T11760: -c Use in-place compaction instead of copying in the oldest generation T11760: when live data is at least % of the maximum heap size set with T11760: -M (default: 30%) T11760: -c Use in-place compaction for all oldest generation collections T11760: (the default is to use copying) T11760: -w Use mark-region for the oldest generation (experimental) T11760: -I Perform full GC after idle time (default: 0.3, 0 == off) T11760: T11760: -T Collect GC statistics (useful for in-program statistics access) T11760: -t[] One-line GC statistics (if omitted, uses stderr) T11760: -s[] Summary GC statistics (if omitted, uses stderr) T11760: -S[] Detailed GC statistics (if omitted, uses stderr) T11760: T11760: T11760: -Z Don't squeeze out update frames on stack overflow T11760: -B Sound the bell at the start of each garbage collection T11760: T11760: -hT Produce a heap profile grouped by closure type T11760: -h Heap residency profile (output file .hp) T11760: -i Time between heap profile samples (seconds, default: 0.1) T11760: T11760: -C Context-switch interval in seconds. T11760: 0 or no argument means switch as often as possible. T11760: Default: 0.02 sec. T11760: -V Master tick interval in seconds (0 == disable timer). T11760: This sets the resolution for -C and the heap profile timer -i, T11760: and is the frequency of time profile samples. T11760: Default: 0.01 sec. T11760: T11760: --install-signal-handlers= T11760: Install signal handlers (default: yes) T11760: -e Maximum number of outstanding local sparks (default: 4096) T11760: -xm Base address to mmap memory in the GHCi linker T11760: (hex; must be <80000000) T11760: -xq The allocation limit given to a thread after it receives T11760: an AllocationLimitExceeded exception. (default: 100k) T11760: T11760: -Mgrace= T11760: The amount of allocation after the program receives a T11760: HeapOverflow exception before the exception is thrown again, if T11760: the program is still exceeding the heap limit. T11760: T11760: RTS options may also be specified using the GHCRTS environment variable. T11760: T11760: Other RTS options may be available for programs compiled a different way. T11760: The GHC User's Guide has full details. T11760: *** unexpected failure for T11760(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 17:19:30 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 17:19:30 -0000 Subject: [GHC] #9441: CSE should deal with letrec In-Reply-To: <045.987758d932a89023c69da6c12f8363f5@haskell.org> References: <045.987758d932a89023c69da6c12f8363f5@haskell.org> Message-ID: <060.cd77e8995342b4ba4ad45bfd2f09e125@haskell.org> #9441: CSE should deal with letrec -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: RolandSenn Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: CSE Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: T9441 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D5038 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * status: new => patch * testcase: => T9441 * differential: => Phab: D5038 Comment: Added missing regresssion test. See: [https://phabricator.haskell.org/D5038] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 18:28:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 18:28:27 -0000 Subject: [GHC] #15468: in ghci -fbreak-on-exception omits exception info Message-ID: <045.c69e90cb12eca9530a2ffc4e534856c3@haskell.org> #15468: in ghci -fbreak-on-exception omits exception info -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.4.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: -------------------------------------+------------------------------------- In ghc 8.4.3 Without -fbreak-on-exception you get a good error message: {{{ ghci -ignore-dot-ghci GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> let 2 + 2 = 5 Prelude> 2 + 2 5 Prelude> 3 + 3 *** Exception: :1:5-13: Non-exhaustive patterns in function + }}} With -fbreak-on-exception there is no info about the exception: {{{ ghci -ignore-dot-ghci -fbreak-on-exception GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> let 2 + 2 = 5 Prelude> 2 + 2 5 Prelude> 3 + 3 Stopped in , _exception :: e = _ [] [] Prelude> }}} In addition, contrary to the documentation, it doesn't seem possible to get ghci to print out the value of the exception {{{ ] [] Prelude> :print _exception _exception = (_t1::e) [] [] Prelude> :info _exception _exception :: e -- Defined in ‘interactive:Ghci3’ [] [] Prelude> }}} Finally the fact that you get now warning about {{{ let 2 + 2 = 5 }}} or for {{{ 2 = 3 }}} makes me think I should file an ER to add the following to the default warnings for ghci {{{ ghci -ignore-dot-ghci -Wname-shadowing -Wunused-pattern-binds GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> let 2 + 2 = 5 :1:7: warning: [-Wname-shadowing] This binding for ‘+’ shadows the existing binding imported from ‘Prelude’ (and originally defined in ‘GHC.Num’) Prelude> 2 = 3 :2:1: warning: [-Wunused-pattern-binds] This pattern-binding binds no variables: 2 = 3 Prelude> }}} I noticed the second and when googling to see if it had been reported I came across the following which documented the first: https://code.likeagirl.io/2-2-5-and-why-compiler-warnings-are-good- eaadef327146 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 18:29:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 18:29:36 -0000 Subject: [GHC] #15468: in ghci -fbreak-on-exception omits exception info In-Reply-To: <045.c69e90cb12eca9530a2ffc4e534856c3@haskell.org> References: <045.c69e90cb12eca9530a2ffc4e534856c3@haskell.org> Message-ID: <060.ed6291629d74e8235abe399d88be3759@haskell.org> #15468: in ghci -fbreak-on-exception omits exception info -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.4.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: | -------------------------------------+------------------------------------- Description changed by George: Old description: > In ghc 8.4.3 > > Without -fbreak-on-exception you get a good error message: > > {{{ > ghci -ignore-dot-ghci > GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help > Prelude> let 2 + 2 = 5 > Prelude> 2 + 2 > 5 > Prelude> 3 + 3 > *** Exception: :1:5-13: Non-exhaustive patterns in function > + > }}} > > With -fbreak-on-exception there is no info about the exception: > > {{{ > ghci -ignore-dot-ghci -fbreak-on-exception > GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help > Prelude> let 2 + 2 = 5 > Prelude> 2 + 2 > 5 > Prelude> 3 + 3 > Stopped in , > _exception :: e = _ > [] [] Prelude> > }}} > > In addition, contrary to the documentation, it doesn't seem possible to > get ghci to print out the value of the exception > > {{{ > ] [] Prelude> :print _exception > _exception = (_t1::e) > [] [] Prelude> :info _exception > _exception :: e -- Defined in ‘interactive:Ghci3’ > [] [] Prelude> > }}} > > Finally the fact that you get now warning about > > {{{ > let 2 + 2 = 5 > }}} > > or for > {{{ > 2 = 3 > }}} > > makes me think I should file an ER to add the following to the default > warnings for ghci > > {{{ > ghci -ignore-dot-ghci -Wname-shadowing -Wunused-pattern-binds > GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help > Prelude> let 2 + 2 = 5 > > :1:7: warning: [-Wname-shadowing] > This binding for ‘+’ shadows the existing binding > imported from ‘Prelude’ (and originally defined in ‘GHC.Num’) > Prelude> 2 = 3 > > :2:1: warning: [-Wunused-pattern-binds] > This pattern-binding binds no variables: 2 = 3 > Prelude> > }}} > > I noticed the second and when googling to see if it had been reported I > came across the following which documented the first: > https://code.likeagirl.io/2-2-5-and-why-compiler-warnings-are-good- > eaadef327146 New description: In ghc 8.4.3 Without -fbreak-on-exception you get a good error message: {{{ ghci -ignore-dot-ghci GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> let 2 + 2 = 5 Prelude> 2 + 2 5 Prelude> 3 + 3 *** Exception: :1:5-13: Non-exhaustive patterns in function + }}} With -fbreak-on-exception there is no info about the exception: {{{ ghci -ignore-dot-ghci -fbreak-on-exception GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> let 2 + 2 = 5 Prelude> 2 + 2 5 Prelude> 3 + 3 Stopped in , _exception :: e = _ [] [] Prelude> }}} In addition, contrary to the documentation, it doesn't seem possible to get ghci to print out the value of the exception {{{ ] [] Prelude> :print _exception _exception = (_t1::e) [] [] Prelude> :info _exception _exception :: e -- Defined in ‘interactive:Ghci3’ [] [] Prelude> }}} Finally the fact that you get no warning about {{{ let 2 + 2 = 5 }}} or for {{{ 2 = 3 }}} makes me think I should file an ER to add the following to the default warnings for ghci {{{ ghci -ignore-dot-ghci -Wname-shadowing -Wunused-pattern-binds GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> let 2 + 2 = 5 :1:7: warning: [-Wname-shadowing] This binding for ‘+’ shadows the existing binding imported from ‘Prelude’ (and originally defined in ‘GHC.Num’) Prelude> 2 = 3 :2:1: warning: [-Wunused-pattern-binds] This pattern-binding binds no variables: 2 = 3 Prelude> }}} I noticed the second and when googling to see if it had been reported I came across the following which documented the first: https://code.likeagirl.io/2-2-5-and-why-compiler-warnings-are-good- eaadef327146 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 19:19:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 19:19:52 -0000 Subject: [GHC] #15287: T11627[ab] fail on some Darwin environments In-Reply-To: <046.b4a6b2737b3c1fbfc1faf99f30e4d4f9@haskell.org> References: <046.b4a6b2737b3c1fbfc1faf99f30e4d4f9@haskell.org> Message-ID: <061.25398f0d95bf60e7f1924526484d0156@haskell.org> #15287: T11627[ab] fail on some Darwin environments -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14758 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 19:24:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 19:24:44 -0000 Subject: [GHC] #15469: Validation doesn't play nicely on a shared computer Message-ID: <047.813561308b64ee5ac44f49e79e4d4ae6@haskell.org> #15469: Validation doesn't play nicely on a shared computer -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Test Suite | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In my shared Linux server, validation creates a directory structure under `/tmp` to do its work. It then creates a directory named something like `ghctest-52ezqtk2` under which the tests live. However, some of the tests in the testsuite are library tests. These end up in a `libraries` directory, accessed with prefixes like `../../libraries/xyz`. That is, the `libraries` directory ends up to be `/tmp/libraries`. The problem is that I share this Linux server with my students, who are also attempting to run validation. After the occasional cleanout of `/tmp`, whoever validates first creates the `/tmp/libraries` directory and then owns that directory -- anyone else who tries to validate gets permission errors until the next cleanout of `tmp`. Even with the presumably quick fix of changing the permissions on `libraries`, the very use of that folder means that two people cannot validate simultaneously on the same machine. Can we fix this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 19:30:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 19:30:47 -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.acfdc5b7f76620bddf4d835027802a59@haskell.org> #14037: Fix fusion for GHC's utility functions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 20:25:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 20:25:34 -0000 Subject: [GHC] #15469: Validation doesn't play nicely on a shared computer In-Reply-To: <047.813561308b64ee5ac44f49e79e4d4ae6@haskell.org> References: <047.813561308b64ee5ac44f49e79e4d4ae6@haskell.org> Message-ID: <062.f96b85103340748f2ebf3030082f96dc@haskell.org> #15469: Validation doesn't play nicely on a shared computer -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Test Suite | 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 thomie): Do you know which tests are writing to `/tmp/libraries`? haddock.base and haddock.Cabal? Possibly relevant commit (but I'm sure there is a better solution than reinstating this hack): https://git.haskell.org/ghc.git/blobdiff/e02beb1849416f5af8ec56acd17f37b5dc7c24a4..f72f23f9f6ff2914ec99fc86f67c89927f18ba47:/testsuite/driver/testlib.py {{{ - # Hack. A few tests depend on files in ancestor directories - # (e.g. extra_files(['../../../../libraries/base/dist- install/haddock.t'])) - # Make sure tempdir is sufficiently "deep", such that copying/linking those - # files won't cause any problems. - # - # If you received a framework failure about adding an extra level: - # * add one extra '../' to the startswith('../../../../../') in do_test - # * add one more number here: - tempdir = os.path.join(tempdir, '1', '2', '3') }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 20:42:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 20:42:11 -0000 Subject: [GHC] #15141: decideKindGeneralisationPlan is too complicated In-Reply-To: <046.4f6050513c6b4233d9cf0aed569bb12a@haskell.org> References: <046.4f6050513c6b4233d9cf0aed569bb12a@haskell.org> Message-ID: <061.a504896056baa3714c3a9c4e1f38470f@haskell.org> #15141: decideKindGeneralisationPlan is too complicated -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4971 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"c955a514f033a12f6d0ab0fbacec3e18a5757ab5/ghc" c955a51/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c955a514f033a12f6d0ab0fbacec3e18a5757ab5" Remove decideKindGeneralisationPlan TypeInType came with a new function: decideKindGeneralisationPlan. This type-level counterpart to the term-level decideGeneralisationPlan chose whether or not a kind should be generalized. The thinking was that if `let` should not be generalized, then kinds shouldn't either (under the same circumstances around -XMonoLocalBinds). However, this is too conservative -- the situation described in the motivation for "let should be be generalized" does not occur in types. This commit thus removes decideKindGeneralisationPlan, always generalizing. One consequence is that tc_hs_sig_type_and_gen no longer calls solveEqualities, which reports all unsolved constraints, instead relying on the solveLocalEqualities in tcImplicitTKBndrs. An effect of this is that reporing kind errors gets delayed more frequently. This seems to be a net benefit in error reporting; often, alongside a kind error, the type error is now reported (and users might find type errors easier to understand). Some of these errors ended up at the top level, where it was discovered that the GlobalRdrEnv containing the definitions in the local module was not in the TcGblEnv, and thus errors were reported with qualified names unnecessarily. This commit rejiggers some of the logic around captureTopConstraints accordingly. One error message (typecheck/should_fail/T1633) is a regression, mentioning the name of a default method. However, that problem is already reported as #10087, its solution is far from clear, and so I'm not addressing it here. This commit fixes #15141. As it's an internal refactor, there is no concrete test case for it. Along the way, we no longer need the hsib_closed field of HsImplicitBndrs (it was used only in decideKindGeneralisationPlan) and so it's been removed, simplifying the datatype structure. Along the way, I removed code in the validity checker that looks at coercions. This isn't related to this patch, really (though it was, at one point), but it's an improvement, so I kept it. This updates the haddock submodule. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 20:42:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 20:42:11 -0000 Subject: [GHC] #10087: DefaultSignatures: error message mentions internal name In-Reply-To: <051.aa4c4a0637fafc7e89e489be234173b6@haskell.org> References: <051.aa4c4a0637fafc7e89e489be234173b6@haskell.org> Message-ID: <066.aadf51feb8e2ef1804eab5e46c308c6e@haskell.org> #10087: DefaultSignatures: error message mentions internal name -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.4 checker) | Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12854, #13755 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"c955a514f033a12f6d0ab0fbacec3e18a5757ab5/ghc" c955a51/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c955a514f033a12f6d0ab0fbacec3e18a5757ab5" Remove decideKindGeneralisationPlan TypeInType came with a new function: decideKindGeneralisationPlan. This type-level counterpart to the term-level decideGeneralisationPlan chose whether or not a kind should be generalized. The thinking was that if `let` should not be generalized, then kinds shouldn't either (under the same circumstances around -XMonoLocalBinds). However, this is too conservative -- the situation described in the motivation for "let should be be generalized" does not occur in types. This commit thus removes decideKindGeneralisationPlan, always generalizing. One consequence is that tc_hs_sig_type_and_gen no longer calls solveEqualities, which reports all unsolved constraints, instead relying on the solveLocalEqualities in tcImplicitTKBndrs. An effect of this is that reporing kind errors gets delayed more frequently. This seems to be a net benefit in error reporting; often, alongside a kind error, the type error is now reported (and users might find type errors easier to understand). Some of these errors ended up at the top level, where it was discovered that the GlobalRdrEnv containing the definitions in the local module was not in the TcGblEnv, and thus errors were reported with qualified names unnecessarily. This commit rejiggers some of the logic around captureTopConstraints accordingly. One error message (typecheck/should_fail/T1633) is a regression, mentioning the name of a default method. However, that problem is already reported as #10087, its solution is far from clear, and so I'm not addressing it here. This commit fixes #15141. As it's an internal refactor, there is no concrete test case for it. Along the way, we no longer need the hsib_closed field of HsImplicitBndrs (it was used only in decideKindGeneralisationPlan) and so it's been removed, simplifying the datatype structure. Along the way, I removed code in the validity checker that looks at coercions. This isn't related to this patch, really (though it was, at one point), but it's an improvement, so I kept it. This updates the haddock submodule. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 20:44:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 20:44:16 -0000 Subject: [GHC] #15141: decideKindGeneralisationPlan is too complicated In-Reply-To: <046.4f6050513c6b4233d9cf0aed569bb12a@haskell.org> References: <046.4f6050513c6b4233d9cf0aed569bb12a@haskell.org> Message-ID: <061.a28eecb64c0db0977869538f72ccebfa@haskell.org> #15141: decideKindGeneralisationPlan is too complicated -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4971 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: patch => closed * resolution: => fixed Comment: All set now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 21:10:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 21:10:17 -0000 Subject: [GHC] #15469: Validation doesn't play nicely on a shared computer In-Reply-To: <047.813561308b64ee5ac44f49e79e4d4ae6@haskell.org> References: <047.813561308b64ee5ac44f49e79e4d4ae6@haskell.org> Message-ID: <062.e0fa98701f2e2e17ed81ae66cd4edd2f@haskell.org> #15469: Validation doesn't play nicely on a shared computer -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Test Suite | 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 goldfire): All the libraries tests do this, including those for `libraries/base`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 21:20:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 21:20:26 -0000 Subject: [GHC] #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) In-Reply-To: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> References: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> Message-ID: <065.4176281022063f904705c7b9a2f7becf@haskell.org> #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: merge Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeInType, Resolution: | TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmm, I'm afraid there is a piece that we are missing on `ghc-8.6`. `T15370` fails with {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.6.0.20180802 for x86_64-unknown-linux): tcTyVarDetails co_a1vS :: y_a1vK[sk:1] ~# x_a1vJ[sk:1] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Var.hs:497:22 in ghc:Var Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} when this is cherry-picked on `ghc-8.6`. Tritlo, do you think you could look into this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 21:34:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 21:34:55 -0000 Subject: [GHC] #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) In-Reply-To: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> References: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> Message-ID: <065.0205856fa669476b3836413f45c75bc4@haskell.org> #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: merge Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeInType, Resolution: | TypedHoles 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 Tritlo): Yes. Does `ghc-8.6` include b202e7a48401bd8e805a92dcfe5ea059cbd8e41c already? I think that resolved the original panic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 23:00:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 23:00:48 -0000 Subject: [GHC] #15469: Validation doesn't play nicely on a shared computer In-Reply-To: <047.813561308b64ee5ac44f49e79e4d4ae6@haskell.org> References: <047.813561308b64ee5ac44f49e79e4d4ae6@haskell.org> Message-ID: <062.4134a3464542abd2a93cc1616ac905e9@haskell.org> #15469: Validation doesn't play nicely on a shared computer -------------------------------------+------------------------------------- Reporter: goldfire | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Test Suite | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5039 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * owner: (none) => thomie * differential: => Phab:D5039 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 2 23:45:02 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Aug 2018 23:45:02 -0000 Subject: [GHC] #15470: Record projections with ambiguous types Message-ID: <047.3cdd34484629508fb5a4f38ac9554616@haskell.org> #15470: Record projections with ambiguous types -------------------------------------+------------------------------------- Reporter: sweirich | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code fails {{{ {-# LANGUAGE DataKinds, KindSignatures, PolyKinds, TypeFamilies, RankNTypes, AllowAmbiguousTypes #-} module TypeLambda where data Fun a b type family App (f :: Fun t k) (x :: t) :: k data MONAD m = MONAD { return :: forall a. a -> App m a , (>>=) :: forall a b. App m a -> (a -> App m b) -> App m b } }}} with the error message {{{ TypeLambda.hs:12:5: error: • Couldn't match type ‘App m b0’ with ‘App m b’ Expected type: App m a -> (a -> App m b) -> App m b Actual type: App m a -> (a -> App m b0) -> App m b0 NB: ‘App’ is a non-injective type family The type variable ‘b0’ is ambiguous • In the expression: (>>=) In an equation for ‘TypeLambda.>>=’: (TypeLambda.>>=) MONAD {>>= = (>>=)} = (>>=) • Relevant bindings include (>>=) :: forall a b. App m a -> (a -> App m b) -> App m b (bound at TypeLambda.hs:12:5) | 12 | , (>>=) :: forall a b. App m a -> (a -> App m b) -> App m b | ^^^^^ Failed, no modules loaded. }}} However, with ScopedTypeVariables and TypeApplications, it is possible to define the projections: {{{ data MONAD2 m = MONAD2 (forall a. a -> App m a) (forall a b. App m a -> (a -> App m b) -> App m b) bind :: forall b a m. MONAD2 m -> App m a -> (a -> App m b) -> App m b bind (MONAD2 _ b) = b @a @b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 3 00:24:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Aug 2018 00:24:52 -0000 Subject: [GHC] #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) In-Reply-To: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> References: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> Message-ID: <065.395cab3359adf162786d1fc5f0bd8b46@haskell.org> #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: merge Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeInType, Resolution: | TypedHoles 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 Tritlo): bgamari: It appears that the changes in b202e7a48401bd8e805a92dcfe5ea059cbd8e41c are not yet merged. If you merge that to `ghc-8.6`, it fixes the panic in `T15370`, and then https://phabricator.haskell.org/D5004 fixes the assertion that was being violated in `DEBUG`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 3 06:54:11 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Aug 2018 06:54:11 -0000 Subject: [GHC] #15138: Unable to instantiate data members of kind Nat in backpack signatures. In-Reply-To: <042.e290873b59fcee0c98fbf371f48d1238@haskell.org> References: <042.e290873b59fcee0c98fbf371f48d1238@haskell.org> Message-ID: <057.36fd4bf3db424583147f31ee837a3281@haskell.org> #15138: Unable to instantiate data members of kind Nat in backpack signatures. -------------------------------------+------------------------------------- Reporter: ppk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.1 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:D4951 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ppk): I think the issue was a wild card pattern match gone wrong. The sharp eyes of @bgamari spotted it. The changes have been pushed to Phab. I think this patch is ready to land -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 3 07:02:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Aug 2018 07:02:20 -0000 Subject: [GHC] #15379: Don't reject user-written instances of KnownNat and friends in hsig files In-Reply-To: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> References: <045.08503b42088a8d712a4ac8fd7649deb0@haskell.org> Message-ID: <060.68379cd34cbff56d11f0b019bfa8de41@haskell.org> #15379: Don't reject user-written instances of KnownNat and friends in hsig files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4988 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ppk): Replying to [comment:14 ppk]: > Some of the test cases in `backpack/should_fail/` are failing. Of which I think the bkpfail46.bkp is actually //not giving// a compilation failure (and hence the test is failing). > Can you have a look at this test case ? Was this a previous limitation of backpack that was > now fixed or is it the case that some thing that should not have been acceptable is now being > accepted (thereby seriously questioning the type safety). The test cases were failing not due to changes here but due to problems in the dependent patch for #15138 (see comment:5:ticket:15138 and comm:6:ticket:15138). This comment is therefore irrelevant for deciding on this patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 3 09:11:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Aug 2018 09:11:27 -0000 Subject: [GHC] #9441: CSE should deal with letrec In-Reply-To: <045.987758d932a89023c69da6c12f8363f5@haskell.org> References: <045.987758d932a89023c69da6c12f8363f5@haskell.org> Message-ID: <060.2a41c5ac820a6c11daa45a517b45a384@haskell.org> #9441: CSE should deal with letrec -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: RolandSenn Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: CSE Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: T9441a, performance bug | T9441b, T9441c Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D5038 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * testcase: T9441 => T9441a, T9441b, T9441c -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 3 09:31:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Aug 2018 09:31:52 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.003527cd46760645e842fedb12daf5f9@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Hmm, so when I skip the `-ticky`, the difference between the baseline and the `VarSet` version melts away: Baseline: {{{ User time (seconds): 3.26 System time (seconds): 0.09 Percent of CPU this job got: 94% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:03.53 }}} VarSet: {{{ User time (seconds): 3.25 System time (seconds): 0.06 Percent of CPU this job got: 96% Elapsed (wall clock) time (h:mm:ss or m:ss): 0:03.44 }}} In fact, `VarSet` now ends up faster than `FV`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 3 12:31:03 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Aug 2018 12:31:03 -0000 Subject: [GHC] #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds In-Reply-To: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> References: <050.40ddf94ca7e8c216668a96dab0045b8d@haskell.org> Message-ID: <065.1f875ce2f8492a1c5eee1ca5d5b877dc@haskell.org> #13555: Typechecker regression when combining PolyKinds and MonoLocalBinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | 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): Phab:D3472 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Note that as a result of commit c955a514f033a12f6d0ab0fbacec3e18a5757ab5 (`Remove decideKindGeneralisationPlan`), the original program now typechecks again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 3 12:48:03 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Aug 2018 12:48:03 -0000 Subject: [GHC] #13600: surprising error message with bang pattern In-Reply-To: <051.cb1136f932f929f97ddeb5e4dd8a6304@haskell.org> References: <051.cb1136f932f929f97ddeb5e4dd8a6304@haskell.org> Message-ID: <066.8ecb016f5998d59b4042923c0a0b72b7@haskell.org> #13600: surprising error message with bang pattern -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: v0d1ch Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: BangPatterns, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #15166, #15458 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by v0d1ch): * owner: (none) => v0d1ch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 3 12:56:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Aug 2018 12:56:45 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.ade7ba71b56672fe0b9b38e0be161161@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Before we continue drilling in that direction, are these results reproducible? Timing is notoriously fickle, and I think it would be wise to make sure we know what we're getting into here. Also, I do think it's worthwhile to still measure allocations, just as another data point. If the `FV`/`VarSet` change isn't the driving force here, then what is? I recommend removing the code that adds the fvs of a variable's kind (without replacing this logic with anything) and testing again. That should surely take less time. (Be careful, e.g., by comparing `-ddump-tc- trace`s, that GHC's overall behavior doesn't change by doing this.) Then, add the `closeOverKinds`. Maybe the algorithm in `closeOverKinds` (simple though it is) is somehow grossly inefficient. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 3 13:41:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Aug 2018 13:41:19 -0000 Subject: [GHC] #13600: surprising error message with bang pattern In-Reply-To: <051.cb1136f932f929f97ddeb5e4dd8a6304@haskell.org> References: <051.cb1136f932f929f97ddeb5e4dd8a6304@haskell.org> Message-ID: <066.ee09ca6f2cfc588abdaa4591c943ee6c@haskell.org> #13600: surprising error message with bang pattern -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: v0d1ch Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: BangPatterns, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #15166, #15458 | Differential Rev(s): Phab:D5040 Wiki Page: | -------------------------------------+------------------------------------- Changes (by v0d1ch): * differential: => Phab:D5040 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 3 14:30:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Aug 2018 14:30:28 -0000 Subject: [GHC] #15471: Polymorphism, typed splices and type inference don't mix Message-ID: <049.084aa260e703fc9ae584d3d54f195e8c@haskell.org> #15471: Polymorphism, typed splices and type inference don't mix -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Trying to quote and splice a polymorphic function doesn't work unless you have a type signature. {{{ {-# LANGUAGE TemplateHaskell #-} module A where foo1 x = x test_foo = [|| foo1 ||] }}} {{{ {-# LANGUAGE TemplateHaskell #-} module B where import A qux = $$(test_foo) }}} The type of `qux` is `Any -> Any`! Which is clearly wrong. Adding a type signature to `qux` fixes the problem. {{{ qux :: a -> a qux = $$(test_foo) }}} Either there should be a better error or this should just work. It seems that this has always been broken. Ryan tested on GHC 7.8.4 for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 3 14:43:12 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Aug 2018 14:43:12 -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.fa1fb306b813809cab9e7b269c2bc5d3@haskell.org> #15471: Polymorphism, typed splices and type inference don't mix -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * failure: None/Unknown => GHC rejects valid program * component: Compiler => Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 3 14:49:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Aug 2018 14:49:59 -0000 Subject: [GHC] #15472: GHC HEAD type inference regression post-"Remove decideKindGeneralisationPlan" Message-ID: <050.060e4a1d545056b90564d103437d8ddb@haskell.org> #15472: GHC HEAD type inference regression post-"Remove decideKindGeneralisationPlan" -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Commit c955a514f033a12f6d0ab0fbacec3e18a5757ab5 (`Remove decideKindGeneralisationPlan`) causes the `singletons` library to no longer compile. Here is as minimal of an example as I can muster: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} module Bug (sPermutations) where import Data.Kind data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type infixr 0 ~> type family Apply (f :: k1 ~> k2) (x :: k1) :: k2 data family Sing :: forall k. k -> Type data instance Sing :: forall a. [a] -> Type where SNil :: Sing '[] SCons :: Sing x -> Sing xs -> Sing (x:xs) newtype instance Sing (f :: k1 ~> k2) = SLambda { applySing :: forall t. Sing t -> Sing (Apply f t) } type SingFunction1 f = forall t. Sing t -> Sing (Apply f t) singFun1 :: forall f. SingFunction1 f -> Sing f singFun1 f = SLambda f type SingFunction2 f = forall t. Sing t -> SingFunction1 (Apply f t) singFun2 :: forall f. SingFunction2 f -> Sing f singFun2 f = SLambda (\x -> singFun1 (f x)) type family Undefined :: k where {} sUndefined :: a sUndefined = undefined type family LetGo k z x ys where LetGo k z x '[] = z LetGo k z x (y ': ys) = Apply (Apply k y) (LetGo k z x ys) type family Foldr (k :: a ~> b ~> b) (x :: b) (xs :: [a]) :: b where Foldr k z x = LetGo k z x x sFoldr :: forall (t1 :: a ~> b ~> b) (t2 :: b) (t3 :: [a]). Sing t1 -> Sing t2 -> Sing t3 -> Sing (Foldr t1 t2 t3 :: b) sFoldr (sK :: Sing k) (sZ :: Sing z) (sX :: Sing x) = let sGo :: forall arg. Sing arg -> Sing (LetGo k z x arg) sGo SNil = sZ sGo (SCons (sY :: Sing y) (sYs :: Sing ys)) = sK `applySing` sY `applySing` sGo sYs in sGo sX type family LetInterleave xs0 t ts is (a1 :: [a]) (a2 :: [[a]]) :: [[a]] where LetInterleave xs0 t ts is a1 a2 = Undefined a1 a2 data LetInterleaveSym5 l_ahko l_ahkp l_ahkq l_ahkr (l_ahks :: [a]) :: [[a]] ~> [[a]] type instance Apply (LetInterleaveSym5 l_ahko l_ahkp l_ahkq l_ahkr l_ahks) l_ahkn = LetInterleave l_ahko l_ahkp l_ahkq l_ahkr l_ahks l_ahkn data LetInterleaveSym4 l_ahkv l_ahkw l_ahkx l_ahky :: forall a. [a] ~> [[a]] ~> [[a]] type instance Apply (LetInterleaveSym4 l_ahkv l_ahkw l_ahkx l_ahky) l_ahku = LetInterleaveSym5 l_ahkv l_ahkw l_ahkx l_ahky l_ahku data LetInterleaveSym3 l_ahkB l_ahkC l_ahkD l_ahkA type instance Apply (LetInterleaveSym3 l_ahkB l_ahkC l_ahkD) l_ahkA = LetInterleaveSym4 l_ahkB l_ahkC l_ahkD l_ahkA data LetInterleaveSym2 l_ahkG l_ahkH l_ahkF type instance Apply (LetInterleaveSym2 l_ahkG l_ahkH) l_ahkF = LetInterleaveSym3 l_ahkG l_ahkH l_ahkF data LetInterleaveSym1 l_ahkK l_ahkJ type instance Apply (LetInterleaveSym1 l_ahkK) l_ahkJ = LetInterleaveSym2 l_ahkK l_ahkJ data LetInterleaveSym0 l_ahkM type instance Apply LetInterleaveSym0 l_ahkM = LetInterleaveSym1 l_ahkM type family LetPerms xs0 a1 a2 where LetPerms xs0 '[] _ = '[] LetPerms xs0 (t ': ts) is = Foldr (LetInterleaveSym4 xs0 t ts is) (LetPerms xs0 ts (t ': is)) (Permutations is) {- $(singletons [d| permutations :: forall a. [a] -> [[a]] permutations xs0 = xs0 : perms xs0 [] where perms [] _ = [] perms (t:ts) is = foldr interleave (perms ts (t:is)) (permutations is) where interleave :: [a] -> [[a]] -> [[a]] interleave = undefined |]) -} type family Permutations (xs0 :: [a]) :: [[a]] where Permutations xs0 = xs0 ': LetPerms xs0 xs0 '[] sPermutations :: forall (t1 :: [a]). Sing t1 -> Sing (Permutations t1 :: [[a]]) sPermutations (sXs0 :: Sing xs0) = let sPerms :: forall arg1 arg2. Sing arg1 -> Sing arg2 -> Sing (LetPerms xs0 arg1 arg2) sPerms SNil _ = SNil sPerms (SCons (sT :: Sing t) (sTs :: Sing ts)) (sIs :: Sing is) = let sInterleave :: forall (t2 :: [a]) (t3 :: [[a]]). Sing t2 -> Sing t3 -> Sing (LetInterleave xs0 t ts is t2 t3 :: [[a]]) sInterleave (sA1 :: Sing a1) (sA2 :: Sing a2) = sUndefined sA1 sA2 in sFoldr (singFun2 @(LetInterleaveSym4 xs0 t ts is) sInterleave) (sPerms sTs (sT `SCons` sIs)) (sPermutations sIs) in sXs0 `SCons` sPerms sXs0 SNil }}} After that commit, this program (which previously typechecked) now errors with: {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:105:66: error: • Could not deduce: t2 ~~ t30 from the context: arg1 ~ (x : xs) bound by a pattern with constructor: SCons :: forall a (x :: a) (xs :: [a]). Sing x -> Sing xs -> Sing (x : xs), in an equation for ‘sPerms’ at Bug.hs:99:17-53 ‘t2’ is a rigid type variable bound by a type expected by the context: SingFunction2 (LetInterleaveSym4 t1 x xs arg2) at Bug.hs:105:24-76 Expected type: Sing t -> Sing t2 -> Sing (Apply (Apply (LetInterleaveSym4 t1 x xs arg2) t) t2) Actual type: Sing t20 -> Sing t30 -> Sing (LetInterleave t1 x xs arg2 t20 t30) • In the second argument of ‘singFun2’, namely ‘sInterleave’ In the first argument of ‘sFoldr’, namely ‘(singFun2 @(LetInterleaveSym4 xs0 t ts is) sInterleave)’ In the expression: sFoldr (singFun2 @(LetInterleaveSym4 xs0 t ts is) sInterleave) (sPerms sTs (sT `SCons` sIs)) (sPermutations sIs) • Relevant bindings include sInterleave :: forall (t2 :: [a1]) (t3 :: [[a1]]). Sing t2 -> Sing t3 -> Sing (LetInterleave t1 x xs arg2 t2 t3) (bound at Bug.hs:103:17) sIs :: Sing arg2 (bound at Bug.hs:99:57) sTs :: Sing xs (bound at Bug.hs:99:39) sT :: Sing x (bound at Bug.hs:99:24) sPerms :: Sing arg1 -> Sing arg2 -> Sing (LetPerms t1 arg1 arg2) (bound at Bug.hs:98:9) sXs0 :: Sing t1 (bound at Bug.hs:94:16) (Some bindings suppressed; use -fmax-relevant-binds=N or -fno-max- relevant-binds) | 105 | in sFoldr (singFun2 @(LetInterleaveSym4 xs0 t ts is) sInterleave) | ^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 3 14:50:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Aug 2018 14:50:26 -0000 Subject: [GHC] #15472: GHC HEAD type inference regression post-"Remove decideKindGeneralisationPlan" In-Reply-To: <050.060e4a1d545056b90564d103437d8ddb@haskell.org> References: <050.060e4a1d545056b90564d103437d8ddb@haskell.org> Message-ID: <065.181cdd1157d76fa7a9f7d36d9c2496f9@haskell.org> #15472: GHC HEAD type inference regression post-"Remove decideKindGeneralisationPlan" -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.5 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => TypeInType * failure: None/Unknown => GHC rejects valid program * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 3 16:39:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Aug 2018 16:39:43 -0000 Subject: [GHC] #15472: GHC HEAD type inference regression post-"Remove decideKindGeneralisationPlan" In-Reply-To: <050.060e4a1d545056b90564d103437d8ddb@haskell.org> References: <050.060e4a1d545056b90564d103437d8ddb@haskell.org> Message-ID: <065.3076c270c24532f2db735b6d7423f3dc@haskell.org> #15472: GHC HEAD type inference regression post-"Remove decideKindGeneralisationPlan" -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.5 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 goldfire): This is subtle, but I claim that the new behavior is correct. I don't know what disaster that spells for `singletons`. By the way, I hate CUSKs. Here is what's happening. 1. `LetInterleave` gets the kind `forall (k1 :: Type) (k2 :: Type) (k3 :: Type) (k4 :: Type) (a :: Type). k1 -> k2 -> k3 -> k4 -> [a] -> [[a]] -> [[a]]` (ignoring the fact that type families must be saturated / don't have kinds, which is not at issue here). 2. `LetInterleaveSym4` doesn't constrain any of its type variables. We thus have `LetInterleaveSym4 :: forall (k1 :: Type) (k2 :: Type) (k3 :: Type) (k4 :: Type). k1 -> k2 -> k3 -> k4 -> forall (a :: Type). [a] ~> [[a]] ~> [[a]]`. 3. `LetPerms` and `Permutations` are mutually recursive. 4. But `Permutations` has a CUSK, so its kind is determined before ever looking at `LetPerms`. We assign `Permutations :: forall (a :: Type). [a] -> [[a]]`. 5. We then kind-check `LetPerms`. The first argument to `LetPerms`, namely `xs0`, is unconstrained by any pattern or usage. We thus infer `LetPerms :: forall (k :: Type) (a :: Type). k -> [a] -> [a] -> [[a]]`. 6. We process the type signature for `sPermutations`, getting `sPermutations :: forall (a :: Type) (t1 :: [a]). Sing t1 -> Sing (Permutations t1)`. 7. `a` and `t1` are brought into scope (via `ScopedTypeVariables`) in the definition of `sPermutations`. 8. We process the type signature for `sPerms`. According to the lack of `decideKindGeneralisationPlan`, we then ''generalize'' this type. We get `sPerms :: forall (a2 :: Type) (arg1 :: [a2]) (arg2 :: [a2]). Sing arg1 -> Sing arg2 -> Sing (LetPerms xs0 arg1 arg2)`. Note that nothing tells us that the `a2` in the kind of `arg1` and `arg2` should be the same as `a`. 9. The patterns for the second equation of `sPerms` bring type variables into scope as follows: `(t :: a2)`, `(ts :: [a2])`, and `(is :: [a2])`. 10. We process the type signature for `sInterleave`, getting `sInterleave :: forall (t2 :: [a]) (t3 :: [a]). Sing t2 -> Sing t3 -> Sing (LetInterleave xs0 t ts is t2 t3)`. This is well-kinded. 11. We see that `singFun2 :: forall {k1 :: Type} {k2 :: Type} {k3 :: Type} (f :: k1 ~> k2 ~> k3). (forall (t1 :: k1). Sing t1 -> forall (t2 :: k2). Sing t2 -> Sing (f @@ t1 @@ t2)) -> Sing f`. 12. We can see that `LetInterleaveSym4 xs0 t ts is` has kind `forall b. [b] ~> [[b]] ~> [[b]]`. 13. Thus, we can find the type of `singFun2 @(LetInterleaveSym4 xs0 t ts is)` to be `(forall (t1 :: [b0]). Sing t1 -> forall (t2 :: [[b0]]). Sing t2 -> Sing (LetInterleaveSym4 xs0 t ts is @@ t1 @@ t2)) -> Sing (LetInterleaveSym4 xs0 t ts is)`, where `b0` is a fresh unification variable. 14. We are now checking `sInterleave` against the type `forall (t1 :: [b0]). Sing t1 -> forall (t2 :: [[b0]]). Sing t2 -> Sing (LetInterleaveSym4 xs0 t ts is @@ t1 @@ t2)`. This works fine, choosing `b0` to be `a` (as forced by `sInterleave`'s type signature). 15. We thus get that `singFun2 @(LetInterleaveSym4 xs0 t ts is) sInterleave :: Sing (LetInterleaveSym4 xs0 t ts is @a)`, where I've explicitly instantiated the `a` in the return kind of `LetInterleaveSym4`. 16. We see that `sFoldr :: forall (a :: Type) (b :: Type) (t1 :: a ~> b ~> b) (t2 :: b) (t3 :: [a]). Sing t1 -> Sing t2 -> Sing t3 -> Sing (Foldr t1 t2 t3)`. 17. From the type of the first argument to `sFoldr`, we see that `t1` must instantiate to `LetInterleaveSym4 xs0 t ts is @a :: [a] ~> [[a]] ~> [[a]]`. 18. Thus, the return type of the call to `sFoldr` must be `Sing (Foldr (LetInterleaveSym4 xs0 t ts is @a) jibber jabber)`, where `Foldr (LetInterleaveSym4 xs0 t ts is @a) jibber jabber :: [[a]]`. 19. The expected return type of `sPerms` is `Sing (LetPerms xs0 arg1 arg2)`, where `LetPerms xs0 arg1 arg2 :: [[a2]]`. 20. We check the return type of `sFoldr` against the expected return type of `sPerms` and get a kind error, saying that `a2` doesn't equal `a`. (The actual error reported is a type error that gives rise to the kind error; GHC reports the type error thinking that types are friendlier than kinds.) As we can see now, the problem is in the generalization in step 8. But this generalization is correct -- that type signature for `sPerms` really ''is'' too polymorphic for this usage. Note that this doesn't bite in the original, unsingletonized code because there is no signature at all on `perms`. Possible ways forward for `singletons`: A. When the user omits a type signature, make sure that we write a ''partial'' type signature (say, by writing `forall (arg1 :: _) (arg2 :: _). ...`). Partial type signatures do not get generalized, as doing so would be silly. B. Give `perms` a type annotation in the original. C. Interestingly, don't give `Permutations` a CUSK. If GHC has to do mutual kind inference, it discovers that `LetPerms :: [a] -> [a] -> [a] -> [[a]]` which then gently guides inference later to be correct. (If you try loading this code into GHC 8.4, you discover this less general type for `LetPerms`, because the feature that GHC removes types with CUSKs from a mutually recursive group is new.) Well, that was my mental calisthenics for the day. If you agree that this isn't GHC's fault, please close the ticket. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 3 16:54:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Aug 2018 16:54:16 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.97b8bc9a9618caa29df946112259ea0e@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:78 goldfire]: > Before we continue drilling in that direction, are these results reproducible? Timing is notoriously fickle, and I think it would be wise to make sure we know what we're getting into here. Oh yes, absolutely right, and I just did exactly that. Turns out the switch from FV to VarSet increases allocations quite a bit, but not enough to explain the failure completely - only about halfway. Observe: baseline: {{{ ("bytes allocated", "1145886664") }}} with VarSet instead of fv: {{{ ("bytes allocated", "1176456040") }}} patch applied fully: {{{ ("bytes allocated", "1207902048") }}} This uses the settings from the test suite directly, and a validate build. So it should be perfectly reproducible, something like this: {{{ for NAME in T14880-baseline T14880-just-tvs T14880 do echo "$NAME" git checkout "wip/$NAME" && (make -j2 && (/usr/bin/time --verbose ~/well-typed/devel/ghc-phab/inplace/bin/ghc-stage2 -c testsuite/tests/perf/compiler/T5631.hs -fforce-recomp +RTS -V0 -tlogs/$NAME.stat --machine-readable -RTS) |& tee logs/$NAME.timing && echo "$NAME") done }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 3 17:01:40 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Aug 2018 17:01:40 -0000 Subject: [GHC] #15472: GHC HEAD type inference regression post-"Remove decideKindGeneralisationPlan" In-Reply-To: <050.060e4a1d545056b90564d103437d8ddb@haskell.org> References: <050.060e4a1d545056b90564d103437d8ddb@haskell.org> Message-ID: <065.e539329377504b5bcf66edeaff8e0c0c@haskell.org> #15472: GHC HEAD type inference regression post-"Remove decideKindGeneralisationPlan" -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: invalid | 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: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: Thanks, goldfire! I am quite appreciative of the time you took to make that very detailed response. If you're convinced that this is correct behavior, then I'm convinced too, so I'll close this. Fortunately, `singletons` doesn't have to work very hard at all to work around this. Option (B) does indeed work quite nicely (and is backwards compatible): {{{#!diff diff -ru singletons-2.4.1.orig/src/Data/Singletons/Prelude/List.hs singletons-2.4.1/src/Data/Singletons/Prelude/List.hs --- singletons-2.4.1.orig/src/Data/Singletons/Prelude/List.hs 2018-01-08 11:09:19.000000000 -0500 +++ singletons-2.4.1/src/Data/Singletons/Prelude/List.hs 2018-08-03 12:53:25.480813967 -0400 @@ -310,6 +310,7 @@ permutations :: forall a. [a] -> [[a]] permutations xs0 = xs0 : perms xs0 [] where + perms :: [a] -> [a] -> [[a]] perms [] _ = [] perms (t:ts) is = foldr interleave (perms ts (t:is)) (permutations is) where interleave xs r = let (_,zs) = interleave' id xs r in zs }}} An alternative option (D) is to leave off the type signature for `interleave` entirely. (Unfortunately, that's not backwards compatible due to #13549/#13555, but //c'est la vie//.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 3 17:29:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Aug 2018 17:29:58 -0000 Subject: [GHC] #15472: GHC HEAD type inference regression post-"Remove decideKindGeneralisationPlan" In-Reply-To: <050.060e4a1d545056b90564d103437d8ddb@haskell.org> References: <050.060e4a1d545056b90564d103437d8ddb@haskell.org> Message-ID: <065.c706058a1e4ebe3acd21ac348fa90485@haskell.org> #15472: GHC HEAD type inference regression post-"Remove decideKindGeneralisationPlan" -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: invalid | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): Is there a small program that would demonstrate the difference in behavior? Might be worth adding to the testsuite. Or is this already covered by existing tests? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 3 18:53:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Aug 2018 18:53:59 -0000 Subject: [GHC] #15472: GHC HEAD type inference regression post-"Remove decideKindGeneralisationPlan" In-Reply-To: <050.060e4a1d545056b90564d103437d8ddb@haskell.org> References: <050.060e4a1d545056b90564d103437d8ddb@haskell.org> Message-ID: <065.ebfe7a24369d7fb5390783e2fcc707e7@haskell.org> #15472: GHC HEAD type inference regression post-"Remove decideKindGeneralisationPlan" -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: invalid | 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 RyanGlScott): If you can successfully find a smaller program than this which exhibits the same issue, then I applaud you. But the original program is small enough that it may be worth checking in under a `should_fail` directory somewhere in the test suite. Also, we should mention this in the GHC 8.8 migration guide (https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.8.1). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 3 18:59:12 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Aug 2018 18:59:12 -0000 Subject: [GHC] #15473: GHC 8.6+ loops infinitely on an UndecidableInstances error message Message-ID: <050.0e1359f1570b3b8da9f1e08c07e4c7b6@haskell.org> #15473: GHC 8.6+ loops infinitely on an UndecidableInstances error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This regression was introduced in commit e1b5a1174e42e390855b153015ce5227b3251d89 (`Fix a nasty bug in piResultTys`), which is present in the `ghc-8.6` and `master` branches. To observe the issue, try compiling the following program: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} -- {-# LANGUAGE UndecidableInstances #-} module Bug where type family Undefined :: k where {} type family LetInterleave xs t ts is (a_ahkO :: [a]) (a_ahkP :: [[a]]) :: [[a]] where LetInterleave xs t ts is y z = Undefined y z }}} You'll get this far: {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:11:3: error: • Variables ‘a, a’ occur more often in the type family application }}} Before GHC hangs. (I was unable to kill this with Ctrl+C; I had to resort to `kill -9`.) Interestingly, the commit f8618a9b15177ee8c84771b927cb3583c9cd8408 (`Remove the type-checking knot.`) does not appear to have an effect on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 3 20:51:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Aug 2018 20:51:53 -0000 Subject: [GHC] #15474: Error message mentions Any Message-ID: <047.c27fe3661bd6607bc87bf78cbba746cc@haskell.org> #15474: Error message mentions Any -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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: -------------------------------------+------------------------------------- I'm not sure if this is a bug. File: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} module T15474 where import Data.Kind (Type) data Proxy a type Forall = forall t. Proxy t f1 :: forall (t :: Type). Proxy t f1 = f1 f2 :: Forall f2 = f1 }}} gives an error message mentioning Any: {{{ • Couldn't match type ‘GHC.Types.Any’ with ‘*’ Expected type: Proxy t Actual type: Proxy t0 }}} The appearance of Any is suspicious - I thought it's an implementation detail? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 3 20:52:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Aug 2018 20:52:55 -0000 Subject: [GHC] #15474: Error message mentions Any In-Reply-To: <047.c27fe3661bd6607bc87bf78cbba746cc@haskell.org> References: <047.c27fe3661bd6607bc87bf78cbba746cc@haskell.org> Message-ID: <062.7a4723fe7bbc3929b6c2a913bc547974@haskell.org> #15474: Error message mentions Any -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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: | -------------------------------------+------------------------------------- Description changed by monoidal: Old description: > I'm not sure if this is a bug. File: > > {{{#!hs > {-# LANGUAGE RankNTypes #-} > {-# LANGUAGE TypeInType #-} > module T15474 where > > import Data.Kind (Type) > > data Proxy a > > type Forall = forall t. Proxy t > > f1 :: forall (t :: Type). Proxy t > f1 = f1 > > f2 :: Forall > f2 = f1 > }}} > > gives an error message mentioning Any: > > {{{ > • Couldn't match type ‘GHC.Types.Any’ with ‘*’ > Expected type: Proxy t > Actual type: Proxy t0 > }}} > > The appearance of Any is suspicious - I thought it's an implementation > detail? New description: I'm not sure if this is a bug. File: {{{#!hs {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} module T15474 where import Data.Kind (Type) data Proxy a type Forall = forall t. Proxy t f1 :: forall (t :: Type). Proxy t f1 = f1 f2 :: Forall f2 = f1 }}} gives an error message mentioning Any: {{{ • Couldn't match type ‘GHC.Types.Any’ with ‘*’ Expected type: Proxy t Actual type: Proxy t0 }}} The appearance of Any is suspicious to me - I thought it's an implementation detail? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 3 21:07:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Aug 2018 21:07:25 -0000 Subject: [GHC] #15472: GHC HEAD type inference regression post-"Remove decideKindGeneralisationPlan" In-Reply-To: <050.060e4a1d545056b90564d103437d8ddb@haskell.org> References: <050.060e4a1d545056b90564d103437d8ddb@haskell.org> Message-ID: <065.ecb685ae47957d395709f8161c243167@haskell.org> #15472: GHC HEAD type inference regression post-"Remove decideKindGeneralisationPlan" -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: invalid | 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 RyanGlScott): Actually, here is an ever-so-slightly smaller way to trigger the issue (which I also discovered in `singletons`) {{{#!hs {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Data.Kind import Data.List.NonEmpty (NonEmpty(..)) data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type infixr 0 ~> type family Apply (f :: k1 ~> k2) (x :: k1) :: k2 data family Sing :: forall k. k -> Type data instance Sing :: forall a. [a] -> Type where SNil :: Sing '[] SCons :: Sing x -> Sing xs -> Sing (x:xs) data instance Sing :: forall a. NonEmpty a -> Type where (:%|) :: Sing x -> Sing xs -> Sing (x :| xs) type family LetGo x xs b cs where LetGo x xs b (c:cs) = b <> LetGo x xs c cs LetGo x xs b '[] = b type family SconcatDefault (arg :: NonEmpty a) :: a where SconcatDefault (x :| xs) = LetGo x xs x xs class PSemigroup (a :: Type) where type (<>) (arg1 :: a) (arg2 :: a) :: a type Sconcat (arg :: NonEmpty a) :: a type Sconcat arg = SconcatDefault arg class SSemigroup a where (%<>) :: forall (t1 :: a) (t2 :: a). Sing t1 -> Sing t2 -> Sing (t1 <> t2 :: a) sSconcat :: forall (t :: NonEmpty a). Sing t -> Sing (Sconcat t :: a) default sSconcat :: forall (t :: NonEmpty a). (Sconcat t :: a) ~ SconcatDefault t => Sing t -> Sing (Sconcat t :: a) sSconcat ((sA :: Sing x) :%| (sAs :: Sing xs)) = let sGo :: forall arg1 arg2. Sing arg1 -> Sing arg2 -> Sing (LetGo x xs arg1 arg2) sGo sB (SCons sC sCs) = sB %<> sGo sC sCs sGo sB SNil = sB in sGo sA sAs }}} This typechecks in GHC 8.4/8.6 but fails in HEAD with: {{{ $ ~/Software/ghc4/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:48:35: error: • Could not deduce (SSemigroup k) arising from a use of ‘%<>’ from the context: SSemigroup a bound by the class declaration for ‘SSemigroup’ at Bug.hs:37:7-16 or from: Sconcat t ~ SconcatDefault t bound by the type signature for: sSconcat :: forall (t :: NonEmpty a). (Sconcat t ~ SconcatDefault t) => Sing t -> Sing (Sconcat t) at Bug.hs:(42,23)-(44,53) or from: t ~ (x ':| xs) bound by a pattern with constructor: :%| :: forall a (x :: a) (xs :: [a]). Sing x -> Sing xs -> Sing (x ':| xs), in an equation for ‘sSconcat’ at Bug.hs:45:13-47 or from: arg2 ~ (x1 : xs1) bound by a pattern with constructor: SCons :: forall a (x :: a) (xs :: [a]). Sing x -> Sing xs -> Sing (x : xs), in an equation for ‘sGo’ at Bug.hs:48:19-30 Possible fix: add (SSemigroup k) to the context of the data constructor ‘SCons’ or the type signature for: sGo :: forall k (arg1 :: k) (arg2 :: [k]). Sing arg1 -> Sing arg2 -> Sing (LetGo x xs arg1 arg2) • In the expression: sB %<> sGo sC sCs In an equation for ‘sGo’: sGo sB (SCons sC sCs) = sB %<> sGo sC sCs In the expression: let sGo :: forall arg1 arg2. Sing arg1 -> Sing arg2 -> Sing (LetGo x xs arg1 arg2) sGo sB (SCons sC sCs) = sB %<> sGo sC sCs sGo sB SNil = sB in sGo sA sAs | 48 | sGo sB (SCons sC sCs) = sB %<> sGo sC sCs | ^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 3 23:05:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Aug 2018 23:05:58 -0000 Subject: [GHC] #15475: Plugin recompilation check still panics Message-ID: <049.1dcd6c48f70db9da972b9cd8df87f1a4@haskell.org> #15475: Plugin recompilation check still panics -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I get a panic as follows when trying to use a plugin with the latest commit on the 8.6 branch. {{{ : error: ghc: panic! (the 'impossible' happened) (GHC version 8.6.1.20180803 for x86_64-unknown-linux): mkPluginUsage: file not found LiftPlugin /nix/store/q8rg4mca5zqv98arpxd7164pqa72hf1n-ncurses-6.1/lib /libHSlift-plugin-0.1.0.0-LpWZumtLigSEjndVxGCyUH-ghc8.6.1.20180803.so Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/deSugar/DsUsage.hs:215:15 in ghc:DsUsage Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} My example is nixified and not very minimal but I can provide it tomorrow if that would help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 3 23:18:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Aug 2018 23:18:09 -0000 Subject: [GHC] #15475: Plugin recompilation check still panics In-Reply-To: <049.1dcd6c48f70db9da972b9cd8df87f1a4@haskell.org> References: <049.1dcd6c48f70db9da972b9cd8df87f1a4@haskell.org> Message-ID: <064.cc95ed2a423a591ea555fa6de9238efd@haskell.org> #15475: Plugin recompilation check still panics -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Repro: {{{ git clone -b plugin https://github.com/LightAndLight/typed-cfg.git cachix use mpickering nix-shell cabal build }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 4 00:50:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Aug 2018 00:50:09 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.21beb9a2c562d1a5cb9cbad0bcd27b74@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The next step would appear to be to duplicate the `FV` module (with identical function structure) but to drop the lists. Then use the new `NonDetFV` instead of `FV`. I would be shocked if the allocations go anywhere but down. Then, we'll have a new conundrum: why is `VarSet` slower than this `NonDetFV`? But let's not figure that out until we've made the observation that it is indeed slower. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 4 05:10:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Aug 2018 05:10:39 -0000 Subject: [GHC] #15138: Unable to instantiate data members of kind Nat in backpack signatures. In-Reply-To: <042.e290873b59fcee0c98fbf371f48d1238@haskell.org> References: <042.e290873b59fcee0c98fbf371f48d1238@haskell.org> Message-ID: <057.32b36104bee9608d8f51380398f76ddf@haskell.org> #15138: Unable to instantiate data members of kind Nat in backpack signatures. -------------------------------------+------------------------------------- Reporter: ppk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.1 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:D4951 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ppk): @bgamari now that the patch is not failing the tests can you schedule this for ghc-8.6 instead of ghc-8.8. Please also consider #15379 if that is the case as without it, this patch alone will not be as useful. We had this discussion on IRC but I am putting it here for documentation. Thanks for spotting that bug in any case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 4 09:47:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Aug 2018 09:47:17 -0000 Subject: [GHC] #10249: GHCi leaky abstraction: error message mentions `ghciStepIO` In-Reply-To: <051.818ff8bc84030bedfa7f9663d4a7c3ef@haskell.org> References: <051.818ff8bc84030bedfa7f9663d4a7c3ef@haskell.org> Message-ID: <066.bfd3cf0432d6cffcefdcc6ae85078223@haskell.org> #10249: GHCi leaky abstraction: error message mentions `ghciStepIO` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | ghci/scripts/T10249 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1527, Wiki Page: | Phab:D1528 -------------------------------------+------------------------------------- Changes (by thomie): * owner: thomie => (none) * status: closed => new * resolution: fixed => Comment: The example from comment:2 is not fixed yet: {{{ $ ghci GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> x <- 'a' :1:6: error: • Couldn't match expected type ‘IO a0’ with actual type ‘Char’ • In the first argument of ‘GHC.GHCi.ghciStepIO :: forall a. IO a -> IO a’, namely ‘'a'’ In a stmt of an interactive GHCi command: x <- GHC.GHCi.ghciStepIO :: forall a. IO a -> IO a 'a' }}} WIP patch here: https://phabricator.haskell.org/D1528 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 4 10:25:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Aug 2018 10:25:17 -0000 Subject: [GHC] #15472: GHC HEAD type inference regression post-"Remove decideKindGeneralisationPlan" In-Reply-To: <050.060e4a1d545056b90564d103437d8ddb@haskell.org> References: <050.060e4a1d545056b90564d103437d8ddb@haskell.org> Message-ID: <065.41c897c49a92528ad326eed62355a004@haskell.org> #15472: GHC HEAD type inference regression post-"Remove decideKindGeneralisationPlan" -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: invalid | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): Thanks. I have simplified the code. {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind (Type) data Proxy b type family LetGo :: k foo :: Proxy (LetGo :: Type) foo = undefined sSconcat :: forall x. x sSconcat = undefined where sGo :: x -> Proxy LetGo sGo _ = foo }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 4 15:38:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Aug 2018 15:38:48 -0000 Subject: [GHC] #15138: Unable to instantiate data members of kind Nat in backpack signatures. In-Reply-To: <042.e290873b59fcee0c98fbf371f48d1238@haskell.org> References: <042.e290873b59fcee0c98fbf371f48d1238@haskell.org> Message-ID: <057.597f8cc7b23354b1dcd72f9e27576ecf@haskell.org> #15138: Unable to instantiate data members of kind Nat in backpack signatures. -------------------------------------+------------------------------------- Reporter: ppk | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 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:D4951 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.8.1 => 8.6.1 Comment: Absolutely. Thanks ppk! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 4 20:06:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Aug 2018 20:06:04 -0000 Subject: [GHC] #14268: Implement Explicit Foralls Proposal In-Reply-To: <046.b2c6e5199adb1a263d1f797400e3472d@haskell.org> References: <046.b2c6e5199adb1a263d1f797400e3472d@haskell.org> Message-ID: <061.be21475a54e730bc17bc4bb49d86d160@haskell.org> #14268: Implement Explicit Foralls Proposal -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13809, 14198 Related Tickets: #13809 | Differential Rev(s): Phab:D4046 Wiki Page: | -------------------------------------+------------------------------------- Changes (by johnleo): * cc: johnleo (added) * owner: johnleo => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 4 20:06:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Aug 2018 20:06:45 -0000 Subject: [GHC] #14268: Implement Explicit Foralls Proposal In-Reply-To: <046.b2c6e5199adb1a263d1f797400e3472d@haskell.org> References: <046.b2c6e5199adb1a263d1f797400e3472d@haskell.org> Message-ID: <061.662c4daf1d75d6b6731289de985f0b48@haskell.org> #14268: Implement Explicit Foralls Proposal -------------------------------------+------------------------------------- Reporter: johnleo | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13809, 14198 Related Tickets: #13809 | Differential Rev(s): Phab:D4046 Wiki Page: | -------------------------------------+------------------------------------- Comment (by johnleo): Richard Eisenberg and his students will be taking over this task. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 4 21:41:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Aug 2018 21:41:45 -0000 Subject: [GHC] #15476: Add -fwarn-star-is-type to -Wcompat Message-ID: <048.67e8d721665e22ae26b64d4ed62436c4@haskell.org> #15476: Add -fwarn-star-is-type to -Wcompat -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 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: -------------------------------------+------------------------------------- According to the accepted proposal https://github.com/ghc-proposals/ghc- proposals/blob/master/proposals/0030-remove-star-kind.rst This change must be included in 8.8, but I think it won't do any harm to include it in GHC 8.6 as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 4 21:45:38 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Aug 2018 21:45:38 -0000 Subject: [GHC] #15476: Add -fwarn-star-is-type to -Wcompat In-Reply-To: <048.67e8d721665e22ae26b64d4ed62436c4@haskell.org> References: <048.67e8d721665e22ae26b64d4ed62436c4@haskell.org> Message-ID: <063.9a540bf79b7249f5a5760bb44efea096@haskell.org> #15476: Add -fwarn-star-is-type to -Wcompat -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: patch 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): Phab:D5044 Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: bgamari (added) * status: new => patch * differential: => Phab:D5044 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 5 03:27:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Aug 2018 03:27:43 -0000 Subject: [GHC] #15477: Can't build `prof`-flavour with `-fauto-all` Message-ID: <047.4794b5de26cd8e48e632f3a281741211@haskell.org> #15477: Can't build `prof`-flavour with `-fauto-all` -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Building the prof flavour and adding `-fauto-all` to {{{ GhcStage2HcOpts = -O -fprof-auto GhcLibHcOpts = -O -fprof-auto }}} Yields: {{{ ghc-stage2: internal error: evacuate(static): strange closure type -1869574000 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 5 03:54:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Aug 2018 03:54:37 -0000 Subject: [GHC] #15453: Bug in opt_trans_rule in OptCoercion In-Reply-To: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> References: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> Message-ID: <062.2702b3213308a0ddae4392298ff9c065@haskell.org> #15453: Bug in opt_trans_rule in OptCoercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5018 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ningning): Replying to [comment:14 simonpj]: > A first step would be to include `GRefl` and anything else that isn't reflected in the paper. Questions: - In this paper, types and kinds are separated, coercions are between types, and they are homogeneous; while in GHC, types and kinds are merged, coercions can be between kinds. This is important because all GRefl is doing is casts between kinds. Do we want to merge types and kinds in the paper, make coercion heterogeneous and add kinds information? - Do we want to add roles? - If the answer is yes for both questions, I am actually wondering if it might be simpler to add coercion optimization rules in core-spec. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 5 07:24:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Aug 2018 07:24:02 -0000 Subject: [GHC] #15478: ghc-pkg package config validation too strict Message-ID: <044.130dca4572b68b7b6254840c20564a5f@haskell.org> #15478: ghc-pkg package config validation too strict -------------------------------------+------------------------------------- Reporter: mboes | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Registration of a package using the following config works: {{{ name: frob version: 0.1.0.0 id: frob-0.1.0.0-inplace key: frob-0.1.0.0-inplace exposed: True exposed-modules: Baz from base-4.11.1.0:Data.Bool, Foo from base-4.11.1.0:Data.List, Frob depends: base-4.11.1.0 }}} But while GHC is happy to work with the following variant of the above configuration added by hand to the package database, it's not possible to add it via `ghc-pkg register`, because it's rejected at validation phase: {{{ name: frob version: 0.1.0.0 id: frob-0.1.0.0-inplace key: frob-0.1.0.0-inplace exposed: True exposed-modules: Baz from base:Data.Bool, Foo from base:Data.List, Frob depends: base }}} We get the following error: {{{ $ ghc-pkg register frob.conf frob-0.1.0.0: module reexport refers to a non-existent defining package: base (use --force to override) }}} This is unfortunate, because in general unit-id's don't just have version numbers but also hashes, and in some settings these can be hard to guess. The general point is that ghc-pkg should be exactly as permissive as GHC itself, not less or more. One way to achieve that is to make the `checkModule` function in `utils/ghc-pkg/Main.hs` (called by `validatePackageConfig`) use `lookupPackageName` as a fallback to `lookupUnitId`, and say that if `lookupPackageName` returns exactly one result (i.e. the name is unambiguous) then that should be considered okay. Perhaps not A-okay, because the name could become ambiguous in the future when more entries are added to the database, but that should at most be a warning, not an error, I think. Note: in principle we should be able to use the `--force` flag here to bypass the results of configuration validation. But oddly enough, `--force` ''filters out'' entries that it objects about, rather than just letting them pass through. So `--force` is not a workable workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 5 08:30:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Aug 2018 08:30:21 -0000 Subject: [GHC] #15439: Refactor `printMinimalImports` into two functions and reexport them In-Reply-To: <047.2af82a21a770553007c81fa29bcda40d@haskell.org> References: <047.2af82a21a770553007c81fa29bcda40d@haskell.org> Message-ID: <062.1b5b6475f0e485d6458a530f5212d8e8@haskell.org> #15439: Refactor `printMinimalImports` into two functions and reexport them -------------------------------------+------------------------------------- Reporter: chshersh | Owner: vrom911 Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: GHC API | Version: 8.4.3 Resolution: | Keywords: | imports,refactoring,source plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5045 Wiki Page: | -------------------------------------+------------------------------------- Changes (by vrom911): * owner: (none) => vrom911 * differential: => Phab:D5045 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 5 10:03:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Aug 2018 10:03:39 -0000 Subject: [GHC] #15189: Avoid word "transformer" in the documentation of ST In-Reply-To: <051.babfb617b882c0b638e02ac50b14cd85@haskell.org> References: <051.babfb617b882c0b638e02ac50b14cd85@haskell.org> Message-ID: <066.bd3a00c1ec48ee782a3879202207cf73@haskell.org> #15189: Avoid word "transformer" in the documentation of ST -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: ulysses4ever Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Documentation | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5019 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ulysses4ever): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 5 10:34:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Aug 2018 10:34:07 -0000 Subject: [GHC] #15261: Show -with-rtsopts options in runtime's --info In-Reply-To: <043.f2c7fda7e5ce90f13c2733f909af5e70@haskell.org> References: <043.f2c7fda7e5ce90f13c2733f909af5e70@haskell.org> Message-ID: <058.c24d13768ad7a180ad4956ba0ec8f800@haskell.org> #15261: Show -with-rtsopts options in runtime's --info -------------------------------------+------------------------------------- Reporter: osa1 | Owner: RolandSenn Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: (none) => RolandSenn Comment: I'll work on this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 5 14:42:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Aug 2018 14:42:48 -0000 Subject: [GHC] #15453: Bug in opt_trans_rule in OptCoercion In-Reply-To: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> References: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> Message-ID: <062.2a888a16e45f4a23ed235554984d177e@haskell.org> #15453: Bug in opt_trans_rule in OptCoercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5018 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): That paper is from quite a while ago, before all these more recent innovations. I think adding the coercion optimization rules to the core- spec might indeed be the better route. I know Simon's on holiday for next stretch, so don't expect an answer from him soon. In the end, where the rules are isn't nearly as important as just having them written down somewhere. If you're happy adding to core-spec, go for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 5 15:06:20 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Aug 2018 15:06:20 -0000 Subject: [GHC] #15439: Refactor `printMinimalImports` into two functions and reexport them In-Reply-To: <047.2af82a21a770553007c81fa29bcda40d@haskell.org> References: <047.2af82a21a770553007c81fa29bcda40d@haskell.org> Message-ID: <062.e84f6098282acaa69a449c6b29c56bfc@haskell.org> #15439: Refactor `printMinimalImports` into two functions and reexport them -------------------------------------+------------------------------------- Reporter: chshersh | Owner: vrom911 Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: GHC API | Version: 8.4.3 Resolution: | Keywords: | imports,refactoring,source plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5045 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"73683f143d352343b00b1ab4f3abeb38b81794be/ghc" 73683f1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="73683f143d352343b00b1ab4f3abeb38b81794be" Refactor printMinimalImports (#15439) Summary: Split into getMinimalImports and printMinimalImports. Export both functions from RnNames module. Reviewers: bgamari, mpickering Reviewed By: mpickering Subscribers: mpickering, rwbarton, carter GHC Trac Issues: #15439 Differential Revision: https://phabricator.haskell.org/D5045 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 5 15:07:30 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Aug 2018 15:07:30 -0000 Subject: [GHC] #15439: Refactor `printMinimalImports` into two functions and reexport them In-Reply-To: <047.2af82a21a770553007c81fa29bcda40d@haskell.org> References: <047.2af82a21a770553007c81fa29bcda40d@haskell.org> Message-ID: <062.4c688012a38244308d534a3f54cb0d44@haskell.org> #15439: Refactor `printMinimalImports` into two functions and reexport them -------------------------------------+------------------------------------- Reporter: chshersh | Owner: vrom911 Type: feature request | Status: merge Priority: normal | Milestone: 8.6.1 Component: GHC API | Version: 8.4.3 Resolution: | Keywords: | imports,refactoring,source plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5045 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 5 16:24:20 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Aug 2018 16:24:20 -0000 Subject: [GHC] #13368: Derive superclasses automatically if possible In-Reply-To: <051.eacbca4ceeb8e62b053fe812233c250b@haskell.org> References: <051.eacbca4ceeb8e62b053fe812233c250b@haskell.org> Message-ID: <066.15dab13cfa07aea1a00aea1df7ac7356@haskell.org> #13368: Derive superclasses automatically if possible -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10607 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by songzh): I added a module `Data.Derive.Superclass` in derive- package[http://hackage.haskell.org/package/derive-topdown-0.0.2.0 which partially solve this problem. {{{ #!div style="font-size: 80%" {{{#!haskell > newtype IO_ a = IO_ (IO a) > strategy_deriving_superclasses newtype_ ''MonadIO ''IO_ You will get: > strategy_deriving_superclasses newtype_ ''MonadIO ''IO_ > ======> > deriving newtype instance MonadIO IO_ > deriving newtype instance Monad IO_ > deriving newtype instance Applicative IO_ > deriving newtype instance Functor IO_ Appearently, Functor f => Applicative f => Monad f => MonadIO f > newtype F32 = F32 Float > newtype_deriving_superclasses ''RealFloat ''F32 You will get: > newtype_deriving_superclasses ''RealFloat ''F32 > ======> > deriving newtype instance RealFloat F32 > deriving newtype instance RealFrac F32 > deriving newtype instance Real F32 > deriving newtype instance Num F32 > deriving newtype instance Ord F32 > deriving newtype instance Eq F32 > deriving newtype instance Fractional F32 > deriving newtype instance Floating F32 }}} }}} Please try the package, if there are problem with it, please contact with me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 5 17:48:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Aug 2018 17:48:31 -0000 Subject: [GHC] #15479: Return HsType GhcTc from tc_hs_type Message-ID: <048.00ac96140ec7697046679926451177c4@haskell.org> #15479: Return HsType GhcTc from tc_hs_type -------------------------------------+------------------------------------- Reporter: int-index | 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: -------------------------------------+------------------------------------- This is a part of https://ghc.haskell.org/trac/ghc/wiki/Design/TypeRefactor -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 5 17:49:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Aug 2018 17:49:39 -0000 Subject: [GHC] #15479: Return HsType GhcTc from tc_hs_type In-Reply-To: <048.00ac96140ec7697046679926451177c4@haskell.org> References: <048.00ac96140ec7697046679926451177c4@haskell.org> Message-ID: <063.f49321ca52c88c6d6a394ad76fe7cfae@haskell.org> #15479: Return HsType GhcTc from tc_hs_type -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: ⊥ Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5047 Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: goldfire (added) * status: new => patch * differential: => Phab:D5047 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 5 20:28:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Aug 2018 20:28:07 -0000 Subject: [GHC] #15466: debug validation failures In-Reply-To: <048.92e70258a7492f32c7bd776d901c7bf2@haskell.org> References: <048.92e70258a7492f32c7bd776d901c7bf2@haskell.org> Message-ID: <063.a4e0964e447f1e377d0c10497b166aea@haskell.org> #15466: debug validation failures ---------------------------------+-------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"f355b72113e646cb3785937f5506ee4c084c127f/ghc" f355b721/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f355b72113e646cb3785937f5506ee4c084c127f" circleci: Don't build validate-x86_64-linux-debug unregisterised Summary: This was a cut-and-paste error. Reviewers: alpmestan Reviewed By: alpmestan Subscribers: alpmestan, rwbarton, thomie, carter GHC Trac Issues: #15466 Differential Revision: https://phabricator.haskell.org/D5037 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 00:59:29 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 00:59:29 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs In-Reply-To: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> References: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> Message-ID: <061.f02f00ad62ec4bd2b5277bba60fcd88f@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4980 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"4d91cabcd5e3c603997d9876f6d30204a9b029c6/ghc" 4d91cabc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4d91cabcd5e3c603997d9876f6d30204a9b029c6" Allow scoped type variables refer to types This patch implements GHC proposal 29: (sorry, URL is too long for the commit message linter) and fixess #15050. The change is simple: Just use a different meta variable form. Test suite and documentation updated. Differential Revision: https://phabricator.haskell.org/D4980 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 01:00:44 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 01:00:44 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs In-Reply-To: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> References: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> Message-ID: <061.0b0e8a66c661e7c58bb4212402a0b3b4@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4980 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 01:04:10 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 01:04:10 -0000 Subject: [GHC] #15480: Rename SigTv Message-ID: <046.695d8e9aa6fe945eae6e4901e7dcaf7f@haskell.org> #15480: Rename SigTv -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After #15050 and [changeset:"4d91cabcd5e3c603997d9876f6d30204a9b029c6/ghc" 4d91cabc/ghc] it seems odd to call `SigTv` for the kind of type variables that used to be used in type signatures in patterns, but are now used in other places (kind signatures, partial type signatures). Also, `SigTv` may be associated with sigma. At some point I assumed that `SigTv` are type variables that may unify with polytypes, while `TauTv` are those that unify with monotypes. As a service to our future self, I’d like to rename `SigTv`. Suggestions? Best one I have is `TvTv` or `TyVarTv` (for a type variable that stands for a type variable). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 07:27:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 07:27:32 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.f9b601160166df61b345145ce2270948@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): Phab:D3752, #12506, #13386 | Phab:D4766 Wiki Page: | -------------------------------------+------------------------------------- Changes (by redv): * cc: redv (added) Comment: I would also be keen on seeing some progress here. More libraries are using type families. I would like to use superrecord for example, but compile time performance is not good. At a guess, probably due to slow type families. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 11:21:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 11:21:34 -0000 Subject: [GHC] #15481: TH fails to recover from reifyFixity with -fexternal-interpreter Message-ID: <050.5475c911201fc232088c3ce363d7a784@haskell.org> #15481: TH fails to recover from reifyFixity with -fexternal-interpreter -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template | Version: 8.4.3 Haskell | Keywords: RemoteGHCi | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (Originally reported at https://github.com/glguy/th- abstraction/issues/53.) If you compile the following program: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Bug where import Language.Haskell.TH main :: IO () main = putStrLn $(recover (stringE "reifyFixity failed") (do foo <- newName "foo" _ <- reifyFixity foo stringE "reifyFixity successful")) }}} It will work fine without the use of `-fexternal-interpreter`. However, using `-fexternal-interpreter` will result in an error: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs -fforce-recomp [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) $ /opt/ghc/8.4.3/bin/ghc Bug.hs -fforce-recomp -fexternal-interpreter [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:7:19: error: • The exact Name ‘foo_a3MT’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful • In the untyped splice: $(recover (stringE "reifyFixity failed") (do foo <- newName "foo" _ <- reifyFixity foo stringE "reifyFixity successful")) | 7 | main = putStrLn $(recover (stringE "reifyFixity failed") | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... Bug.hs:7:19: error: • The exact Name ‘foo_a3MT’ is not in scope Probable cause: you used a unique Template Haskell name (NameU), perhaps via newName, but did not bind it If that's it, then -ddump-splices might be useful • In the untyped splice: $(recover (stringE "reifyFixity failed") (do foo <- newName "foo" _ <- reifyFixity foo stringE "reifyFixity successful")) | 7 | main = putStrLn $(recover (stringE "reifyFixity failed") | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 11:47:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 11:47:56 -0000 Subject: [GHC] #15477: Can't build `prof`-flavour with `-fauto-all` In-Reply-To: <047.4794b5de26cd8e48e632f3a281741211@haskell.org> References: <047.4794b5de26cd8e48e632f3a281741211@haskell.org> Message-ID: <062.cc3ffce01f7bec34782aec05308a740d@haskell.org> #15477: Can't build `prof`-flavour with `-fauto-all` -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I couldn't reproduce this, but when I run the test suite with {{{ make EXTRA_HC_OPTS="-prof -fprof-auto -with-rtsopts=-p" }}} I found one segfaulting test which is `concprog001`. When it doesn't segfault it fails with this instead: {{{ concprog001: internal error: evacuate: strange closure type 0 (GHC version 8.7.20180806 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 11:49:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 11:49:25 -0000 Subject: [GHC] #15220: ScopedTypeVariables binds a non-existent variable In-Reply-To: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> References: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> Message-ID: <062.eb4196675db24437ac2159298fe6c9c6@haskell.org> #15220: ScopedTypeVariables binds a non-existent variable -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): What is the status of this ticket post-commit 4d91cabcd5e3c603997d9876f6d30204a9b029c6 (`Allow scoped type variables refer to types`)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 11:53:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 11:53:22 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs In-Reply-To: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> References: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> Message-ID: <061.07274bb9753f50567890be43e6a747e5@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4980 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thanks, nomeata! Do you think you could add a mention of this new feature in the 8.8.1 release notes? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 12:17:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 12:17:18 -0000 Subject: [GHC] #15481: TH fails to recover from reifyFixity with -fexternal-interpreter In-Reply-To: <050.5475c911201fc232088c3ce363d7a784@haskell.org> References: <050.5475c911201fc232088c3ce363d7a784@haskell.org> Message-ID: <065.f582e840876c2bdf62748c4c892b199b@haskell.org> #15481: TH fails to recover from reifyFixity with -fexternal-interpreter -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: RemoteGHCi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by angerman): * cc: angerman (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 14:11:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 14:11:45 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs In-Reply-To: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> References: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> Message-ID: <061.23264c5f1e24e9da8613bb60e467c43f@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4980 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"f811685c3c1579333743da135c8cb80924aea4ce/ghc" f811685c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f811685c3c1579333743da135c8cb80924aea4ce" Mention #15050 in the release notes for 8.8.1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 14:52:42 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 14:52:42 -0000 Subject: [GHC] #15475: Plugin recompilation check still panics In-Reply-To: <049.1dcd6c48f70db9da972b9cd8df87f1a4@haskell.org> References: <049.1dcd6c48f70db9da972b9cd8df87f1a4@haskell.org> Message-ID: <064.10d2b68dcb7c807a06cb348d08c06c30@haskell.org> #15475: Plugin recompilation check still panics -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5048 Wiki Page: | -------------------------------------+------------------------------------- Changes (by darchon): * status: new => patch * differential: => Phab:D5048 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 16:09:42 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 16:09:42 -0000 Subject: [GHC] #15482: the_gc_thread variable from GC.c is not aligned to 64 Message-ID: <045.517cd029a074e1225f6142d10f834f62@haskell.org> #15482: the_gc_thread variable from GC.c is not aligned to 64 -------------------------------------+------------------------------------- Reporter: arrowd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When compiling GHC with clang and -march=native flag, the compiler emits vmovaps instruction with unaligned operand for this code: {{{ * thread #1, name = 'ghc-pkg', stop reason = signal SIGBUS: hardware error frame #0: 0x0000000804e476c6 libHSrts-ghc8.0.2.so`initGcThreads [inlined] new_gc_thread(n=0) at GC.c:818 815 ws->todo_q = newWSDeque(128); 816 ws->todo_overflow = NULL; 817 ws->n_todo_overflow = 0; -> 818 ws->todo_large_objects = NULL; 819 820 ws->part_list = NULL; 821 ws->n_part_blocks = 0; }}} Research done by another FreeBSD developer suggested that this is due {{{ StgWord8 the_gc_thread[sizeof(gc_thread) + 64 * sizeof(gen_workspace)]; }}} not being aligned to 64 bytes, because struct gc_thread have no alignment specifier. Detailed information can be found in FreeBSD bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=226059 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 19:29:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 19:29:47 -0000 Subject: [GHC] #15469: Validation doesn't play nicely on a shared computer In-Reply-To: <047.813561308b64ee5ac44f49e79e4d4ae6@haskell.org> References: <047.813561308b64ee5ac44f49e79e4d4ae6@haskell.org> Message-ID: <062.0b44d6f3149baa1c21ef7a083ba18728@haskell.org> #15469: Validation doesn't play nicely on a shared computer -------------------------------------+------------------------------------- Reporter: goldfire | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Test Suite | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5039 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"29dfb63624442a27119c1a218fc3dae71afb16de/ghc" 29dfb636/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="29dfb63624442a27119c1a218fc3dae71afb16de" Strip ../ from testdir (fixes #15469) Test Plan: Harbormaster Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15469 Differential Revision: https://phabricator.haskell.org/D5039 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 19:31:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 19:31:06 -0000 Subject: [GHC] #15469: Validation doesn't play nicely on a shared computer In-Reply-To: <047.813561308b64ee5ac44f49e79e4d4ae6@haskell.org> References: <047.813561308b64ee5ac44f49e79e4d4ae6@haskell.org> Message-ID: <062.84cf83ac42d71573109e54d805f19504@haskell.org> #15469: Validation doesn't play nicely on a shared computer -------------------------------------+------------------------------------- Reporter: goldfire | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Test Suite | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5039 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 19:33:41 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 19:33:41 -0000 Subject: [GHC] #15483: ghc -M requires -dep-suffix for no good reason Message-ID: <051.2a35f99f194ba90ad12a8198bda71c04@haskell.org> #15483: ghc -M requires -dep-suffix for no good reason -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Driver | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Doing {{{ ghc -M Foo.hs }}} gives {{{ You must specify at least one -dep-suffix }}} I went to the documentation and noticed ([https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/separate_compilation.html #makefile-dependencies 7.8.12]) an example: {{{ depend : ghc -dep-suffix '' -M $(HC_OPTS) $(SRCS) }}} So, empty suffix is fine. Why not default to empty string then? I found a commit which introduced the requirement ([https://github.com/ghc/ghc/commit/af072fc35d8dbe7962e62700da052593e999c0ef af072fc]): it says, it fixed #7381, and this doesn't seem to do anything with `dep-suffix` in particular. So, maybe there is no good reason to require that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 21:24:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 21:24:04 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.bbb967a158a5fd74f0a7e78f9e8d0a7a@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): NonDetFV (`NDFV`) speed / allocations test still running. While writing the code for `NDFV`, one thing caught my eye however: the `delFV` / `delFVs` functions, rather than actually remove anything from the `have` list and the `haveSet`, *add* to the `in_scope` set; naturally, rewriting this in terms of `VarSet`, where the `delVarSet` function actually removes the var from the set, will change performance characteristics, one way or the other, depending on the situation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 21:49:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 21:49:09 -0000 Subject: [GHC] #15484: MultiLayerModules and T13701 timeout on i386 Linux Message-ID: <046.f49e8907dc2fd082faa408fb71333802@haskell.org> #15484: MultiLayerModules and T13701 timeout on i386 Linux -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- CircleCI's Linux/i386 configuration fails with timeouts on `MultiLayerModules`, `T13701`, -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 21:50:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 21:50:01 -0000 Subject: [GHC] #15463: "Serious" validation failures on i686 In-Reply-To: <048.69c70a3c6d4c72255c91639c0649f11f@haskell.org> References: <048.69c70a3c6d4c72255c91639c0649f11f@haskell.org> Message-ID: <063.9cf876ef19853deeaef6079870bc6e69@haskell.org> #15463: "Serious" validation failures on i686 -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: T3171, | heapprof001 Blocked By: | Blocking: Related Tickets: #15383 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #15383 Comment: The `T3171` failure is being tracked as #15383. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 21:50:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 21:50:09 -0000 Subject: [GHC] #15383: T3171 doesn't terminate with Interrupted message on Darwin In-Reply-To: <046.1d648bf17453b21fb35b42043bd02c26@haskell.org> References: <046.1d648bf17453b21fb35b42043bd02c26@haskell.org> Message-ID: <061.5666cdd4351f6f5cc727d7616ea6b2a7@haskell.org> #15383: T3171 doesn't terminate with Interrupted message on Darwin ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15463 | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by bgamari): * related: => #15463 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:03:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:03:51 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.f7a61b33de3be7984085a8b123084f21@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Speed test results: performance for the `NDFV` version is virtually identical to that of the baseline (which uses `FV`). So leaving out the list when it is not going to be demanded anyway makes absolutely no difference, as one would expect. Full logs to be attached. The relevant branches can be found on git.haskell.org: - `wip/T14880-baseline` (before the patch) - `wip/T14880` (patch applied as-is) - `wip/T14880-just-tvs` (just the move from `FV` to `VarSet`) - `wip/T14880-nondet-fv` (introducing the `NDFV` flavour of `FV`, but otherwise identical to the baseline) To reproduce logs, use something like: {{{#!bash for NAME in T14880-nondet-fv T14880 T14880-baseline T14880-just-tvs do echo "$NAME" git checkout "wip/$NAME" \ && ( make -j2 \ && (/usr/bin/time --verbose \ ~/path/to/ghc/inplace/bin/ghc-stage2 \ -c testsuite/tests/perf/compiler/T5631.hs \ -fforce-recomp \ +RTS -V0 -tlogs/$NAME.stat --machine-readable -RTS) \ |& tee logs/$NAME.timing \ && echo "$NAME" ) done }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:11:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:11:18 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.ce6fd013f1c0da9f07831a42207bc9c8@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * Attachment "logs2.tar.gz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:25:42 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:25:42 -0000 Subject: [GHC] #15439: Refactor `printMinimalImports` into two functions and reexport them In-Reply-To: <047.2af82a21a770553007c81fa29bcda40d@haskell.org> References: <047.2af82a21a770553007c81fa29bcda40d@haskell.org> Message-ID: <062.32a95e5c4198392ace850b2af9754dbd@haskell.org> #15439: Refactor `printMinimalImports` into two functions and reexport them -------------------------------------+------------------------------------- Reporter: chshersh | Owner: vrom911 Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHC API | Version: 8.4.3 Resolution: fixed | Keywords: | imports,refactoring,source plugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5045 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with f6e889fd1b9aa4e6f3ddaf69bc9446a7ca86fc8f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:27:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:27:33 -0000 Subject: [GHC] #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) In-Reply-To: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> References: <050.3c4d55750e3ba0c081843f0ae418da24@haskell.org> Message-ID: <065.9323dba81370b1cb2083fee99748816f@haskell.org> #15370: Typed hole panic on GHC 8.6 (tcTyVarDetails) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Tritlo Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeInType, Resolution: fixed | TypedHoles Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: comment:16 merged in f4e54330d14c1601128d6ab3750a10709c05a427 and comment:13 merged in 588364c38530b51902d79d0175deed359796d172. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:29:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:29:49 -0000 Subject: [GHC] #10355: Dynamic linker not initialised In-Reply-To: <046.b020405a0b5eb69acc1047433b42d151@haskell.org> References: <046.b020405a0b5eb69acc1047433b42d151@haskell.org> Message-ID: <061.1edd16bf077406ab39ebf7e83495406f@haskell.org> #10355: Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: dpiponi | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9868, #10919, | Differential Rev(s): Phab:D5012 #13137, #13531, #13607 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4fc6524a2a4a0003495a96c8b84783286f65c198/ghc" 4fc6524/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4fc6524a2a4a0003495a96c8b84783286f65c198" Stop the linker panic If we fail to initialize the liker properly, we still set the `initLinkerDone`. In fact we even set that prior to actually initializing the linker. However if the linker initialization fails, we the `Done` state is still true. As such we run into the `Dynamic Linker not initialised` error. Which while technically corret is confusing as it pulls the attation away from the real issue. This change puts the Done state into an MVar, and as such ensureing that all parallel access needs to wait for the linker to be actually initialized, or try to re-initilize if it fails. Reviewers: bgamari, RyanGlScott, simonmar, hvr Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #9868, #10355, #13137, #13607, #13531 Differential Revision: https://phabricator.haskell.org/D5012 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:29:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:29:49 -0000 Subject: [GHC] #13137: Dynamic linker not initialised. In-Reply-To: <045.40f0726ebefc735f7ea0c8f42d81dbc6@haskell.org> References: <045.40f0726ebefc735f7ea0c8f42d81dbc6@haskell.org> Message-ID: <060.67d856391493f8c2f6e5aea251d23dff@haskell.org> #13137: Dynamic linker not initialised. -------------------------------------+------------------------------------- Reporter: djduke | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9868, #10355, | Differential Rev(s): Phab:D5012 #10919, #13531, #13607 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4fc6524a2a4a0003495a96c8b84783286f65c198/ghc" 4fc6524/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4fc6524a2a4a0003495a96c8b84783286f65c198" Stop the linker panic If we fail to initialize the liker properly, we still set the `initLinkerDone`. In fact we even set that prior to actually initializing the linker. However if the linker initialization fails, we the `Done` state is still true. As such we run into the `Dynamic Linker not initialised` error. Which while technically corret is confusing as it pulls the attation away from the real issue. This change puts the Done state into an MVar, and as such ensureing that all parallel access needs to wait for the linker to be actually initialized, or try to re-initilize if it fails. Reviewers: bgamari, RyanGlScott, simonmar, hvr Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #9868, #10355, #13137, #13607, #13531 Differential Revision: https://phabricator.haskell.org/D5012 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:29:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:29:49 -0000 Subject: [GHC] #13531: GHC fails with "Dynamic linker not initialised" when -j is on and trying to load nonexistent .so file In-Reply-To: <042.f97bf302ed95b0f9a174910a7d6a0986@haskell.org> References: <042.f97bf302ed95b0f9a174910a7d6a0986@haskell.org> Message-ID: <057.93458d7eba0a1853bb2f06115227da4e@haskell.org> #13531: GHC fails with "Dynamic linker not initialised" when -j is on and trying to load nonexistent .so file -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13137, #9868, | Differential Rev(s): Phab:D5012 #10355, #13607, #10919 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4fc6524a2a4a0003495a96c8b84783286f65c198/ghc" 4fc6524/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4fc6524a2a4a0003495a96c8b84783286f65c198" Stop the linker panic If we fail to initialize the liker properly, we still set the `initLinkerDone`. In fact we even set that prior to actually initializing the linker. However if the linker initialization fails, we the `Done` state is still true. As such we run into the `Dynamic Linker not initialised` error. Which while technically corret is confusing as it pulls the attation away from the real issue. This change puts the Done state into an MVar, and as such ensureing that all parallel access needs to wait for the linker to be actually initialized, or try to re-initilize if it fails. Reviewers: bgamari, RyanGlScott, simonmar, hvr Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #9868, #10355, #13137, #13607, #13531 Differential Revision: https://phabricator.haskell.org/D5012 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:29:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:29:49 -0000 Subject: [GHC] #9868: ghc: panic! Dynamic linker not initialised In-Reply-To: <046.5f3f9e960e287bc6e82a07e7ce17a8b6@haskell.org> References: <046.5f3f9e960e287bc6e82a07e7ce17a8b6@haskell.org> Message-ID: <061.58dd138196e4cc228b266a886377b9a5@haskell.org> #9868: ghc: panic! Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: Jamedjo | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #10355, #10919, | Differential Rev(s): Phab:D5012 #13137, #13531, #13607 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4fc6524a2a4a0003495a96c8b84783286f65c198/ghc" 4fc6524/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4fc6524a2a4a0003495a96c8b84783286f65c198" Stop the linker panic If we fail to initialize the liker properly, we still set the `initLinkerDone`. In fact we even set that prior to actually initializing the linker. However if the linker initialization fails, we the `Done` state is still true. As such we run into the `Dynamic Linker not initialised` error. Which while technically corret is confusing as it pulls the attation away from the real issue. This change puts the Done state into an MVar, and as such ensureing that all parallel access needs to wait for the linker to be actually initialized, or try to re-initilize if it fails. Reviewers: bgamari, RyanGlScott, simonmar, hvr Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #9868, #10355, #13137, #13607, #13531 Differential Revision: https://phabricator.haskell.org/D5012 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:29:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:29:49 -0000 Subject: [GHC] #13607: Panic when shared object file is missing: Dynamic linker not initialised In-Reply-To: <050.42a412821545515fa30e9fa080a5d0f2@haskell.org> References: <050.42a412821545515fa30e9fa080a5d0f2@haskell.org> Message-ID: <065.a88eab0d984b0cbc127445753ce801fc@haskell.org> #13607: Panic when shared object file is missing: Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.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: #9868, #10355, | Differential Rev(s): Phab:D5012 #10919, #13137, #13531 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4fc6524a2a4a0003495a96c8b84783286f65c198/ghc" 4fc6524/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4fc6524a2a4a0003495a96c8b84783286f65c198" Stop the linker panic If we fail to initialize the liker properly, we still set the `initLinkerDone`. In fact we even set that prior to actually initializing the linker. However if the linker initialization fails, we the `Done` state is still true. As such we run into the `Dynamic Linker not initialised` error. Which while technically corret is confusing as it pulls the attation away from the real issue. This change puts the Done state into an MVar, and as such ensureing that all parallel access needs to wait for the linker to be actually initialized, or try to re-initilize if it fails. Reviewers: bgamari, RyanGlScott, simonmar, hvr Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #9868, #10355, #13137, #13607, #13531 Differential Revision: https://phabricator.haskell.org/D5012 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:29:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:29:49 -0000 Subject: [GHC] #12625: Bad error message for flags with required but missing arguments In-Reply-To: <050.552ad6bb3a020bd4f5961b4cb97a9c89@haskell.org> References: <050.552ad6bb3a020bd4f5961b4cb97a9c89@haskell.org> Message-ID: <065.63a5c8f04855b7141c112e4b7ad658a3@haskell.org> #12625: Bad error message for flags with required but missing arguments -------------------------------------+------------------------------------- Reporter: dramforever | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T12625 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D5030 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ff06176b87078ce56cc7b6b3405a029ef3d0046f/ghc" ff06176b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ff06176b87078ce56cc7b6b3405a029ef3d0046f" Improve error message for flags with missing required arguments (#12625) Test Plan: make TEST=T12625 Reviewers: jstolarek, austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #12625 Differential Revision: https://phabricator.haskell.org/D5030 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:29:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:29:49 -0000 Subject: [GHC] #15482: the_gc_thread variable from GC.c is not aligned to 64 In-Reply-To: <045.517cd029a074e1225f6142d10f834f62@haskell.org> References: <045.517cd029a074e1225f6142d10f834f62@haskell.org> Message-ID: <060.1e725929f029aa72e6440d338e9f6e06@haskell.org> #15482: the_gc_thread variable from GC.c is not aligned to 64 -------------------------------------+------------------------------------- Reporter: arrowd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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:"c6cc93bca69abc258513af8cf2370b14e70fd8fb/ghc" c6cc93bc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c6cc93bca69abc258513af8cf2370b14e70fd8fb" rts: Ensure that the_gc_thread is aligned Since we cast this to a gc_thread the compiler may assume that it's aligned. Make sure that this is so. Fixes #15482. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:31:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:31:21 -0000 Subject: [GHC] #13531: GHC fails with "Dynamic linker not initialised" when -j is on and trying to load nonexistent .so file In-Reply-To: <042.f97bf302ed95b0f9a174910a7d6a0986@haskell.org> References: <042.f97bf302ed95b0f9a174910a7d6a0986@haskell.org> Message-ID: <057.6c375fd1d76dbc589f34aa51da61a1c3@haskell.org> #13531: GHC fails with "Dynamic linker not initialised" when -j is on and trying to load nonexistent .so file -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13137, #9868, | Differential Rev(s): Phab:D5012 #10355, #13607, #10919 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.8.1 Comment: Fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:31:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:31:52 -0000 Subject: [GHC] #12625: Bad error message for flags with required but missing arguments In-Reply-To: <050.552ad6bb3a020bd4f5961b4cb97a9c89@haskell.org> References: <050.552ad6bb3a020bd4f5961b4cb97a9c89@haskell.org> Message-ID: <065.ec572ffa560f167f79d177e08543eaa0@haskell.org> #12625: Bad error message for flags with required but missing arguments -------------------------------------+------------------------------------- Reporter: dramforever | Owner: RolandSenn Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T12625 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D5030 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:38:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:38:58 -0000 Subject: [GHC] #15138: Unable to instantiate data members of kind Nat in backpack signatures. In-Reply-To: <042.e290873b59fcee0c98fbf371f48d1238@haskell.org> References: <042.e290873b59fcee0c98fbf371f48d1238@haskell.org> Message-ID: <057.4c199b1ad6d26a216d82dc643f460ed3@haskell.org> #15138: Unable to instantiate data members of kind Nat in backpack signatures. -------------------------------------+------------------------------------- Reporter: ppk | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.1 Resolution: fixed | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4951 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: 8.6.1 => 8.8.1 Comment: I just looked at the patch for #15379 and I'm afraid it's a bit large for 8.6. Retargetting this for 8.6. Sorry ppk! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:45:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:45:49 -0000 Subject: [GHC] #15350: gcdExtInteger violates assertion In-Reply-To: <047.463f72a51535cf21b879b51cdb0841bf@haskell.org> References: <047.463f72a51535cf21b879b51cdb0841bf@haskell.org> Message-ID: <062.5b64e892be4b555fdd52b376710b1cdc@haskell.org> #15350: gcdExtInteger violates assertion -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: Bodigrim Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5042 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D5042 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:46:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:46:17 -0000 Subject: [GHC] #15418: Performance drop 60 times on non-profiling binary In-Reply-To: <045.a055029aec148ca416c29df30694b018@haskell.org> References: <045.a055029aec148ca416c29df30694b018@haskell.org> Message-ID: <060.b37d275f659c37d15c8c5a29b0de4caa@haskell.org> #15418: Performance drop 60 times on non-profiling binary -------------------------------------+------------------------------------- Reporter: hth313 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14414, #9599 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 Comment: It doesn't look like we will be able to address this in 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:46:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:46:51 -0000 Subject: [GHC] #15465: PAP object entered In-Reply-To: <054.65b86eeb26556bf73809a3044c0a3cb9@haskell.org> References: <054.65b86eeb26556bf73809a3044c0a3cb9@haskell.org> Message-ID: <069.a1f3ddc95762aa671b4b17fbab2d520d@haskell.org> #15465: PAP object entered ------------------------------------+-------------------------------------- Reporter: recursion-ninja | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: We'll need a reproducer to be able to do much about this, I'm afraid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:47:02 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:47:02 -0000 Subject: [GHC] #15465: PAP object entered In-Reply-To: <054.65b86eeb26556bf73809a3044c0a3cb9@haskell.org> References: <054.65b86eeb26556bf73809a3044c0a3cb9@haskell.org> Message-ID: <069.d054e04d868efa8718b49f18db807723@haskell.org> #15465: PAP object entered ------------------------------------+-------------------------------------- Reporter: recursion-ninja | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:48:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:48:37 -0000 Subject: [GHC] #15482: the_gc_thread variable from GC.c is not aligned to 64 In-Reply-To: <045.517cd029a074e1225f6142d10f834f62@haskell.org> References: <045.517cd029a074e1225f6142d10f834f62@haskell.org> Message-ID: <060.ac68a6d6134575ecb3b0d6a0e2689e74@haskell.org> #15482: the_gc_thread variable from GC.c is not aligned to 64 -------------------------------------+------------------------------------- Reporter: arrowd | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:49:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:49:15 -0000 Subject: [GHC] #15482: the_gc_thread variable from GC.c is not aligned to 64 In-Reply-To: <045.517cd029a074e1225f6142d10f834f62@haskell.org> References: <045.517cd029a074e1225f6142d10f834f62@haskell.org> Message-ID: <060.4c5ca6717cefe4bfcfb72a72003956d5@haskell.org> #15482: the_gc_thread variable from GC.c is not aligned to 64 -------------------------------------+------------------------------------- Reporter: arrowd | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged in 87a79e394013e5f722496900227b126015d0d780. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:51:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:51:33 -0000 Subject: [GHC] #15260: Xmobar crashes with segmentation fault In-Reply-To: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> References: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> Message-ID: <061.125273b688ab099782b7a5f1bcde706f@haskell.org> #15260: Xmobar crashes with segmentation fault ----------------------------------+-------------------------------------- Reporter: Voronwe | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Fix was merged to `ghc-8.6` in 3ec1d931218e603ba1622faa2b52884b2477a7db and `master` in 56590db07a776ce81eb89d4a4d86bd0f953fb44e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:53:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:53:25 -0000 Subject: [GHC] Batch modify: #11295, #13724, #14164, #14401, #14405, #14412, ... In-Reply-To: <510.1dabc871e27eb5dfb74b0c5a38842056@haskell.org> References: <510.1dabc871e27eb5dfb74b0c5a38842056@haskell.org> Message-ID: <525.2a01e113433ceabc1114a7476a80a2ba@haskell.org> Batch modification to #11295, #13724, #14164, #14401, #14405, #14412, #15053, #15075, #15159, #15213, #15241, #15298, #15309, #15312, #15313, #15319, #15320, #15322, #15325, #15326, #15327, #15328, #15332, #15336, #15337, #15338, #15340, #15344, #15345, #15354, #15356, #15359, #15360, #15361, #15362, #15368, #15369, #15376, #15377, #15378, #15379, #15381, #15382, #15383, #15384, #15388, #15389, #15391, #15392, #15394, #15395, #15403, #15404, #15409, #15411, #15414, #15416, #15420, #15424, #15426, #15427, #15433, #15434, #15435, #15437, #15443, #15448, #15449, #15454, #15459, #15460, #15461, #15464, #15470, #15471, #15477, #15478, #15483, #15484 by bgamari: milestone to 8.8.1 Action: leave Comment: These won't be fixed for in GHC 8.6. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:55:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:55:12 -0000 Subject: [GHC] Batch modify: #15227, #15363, #15375, #15452 In-Reply-To: <060.6259d8735e3051a1d42ba0949539773a@haskell.org> References: <060.6259d8735e3051a1d42ba0949539773a@haskell.org> Message-ID: <075.bc2a6fb8659406bf7ca2b594dd7a5403@haskell.org> Batch modification to #15227, #15363, #15375, #15452 by bgamari: milestone to 8.8.1 Comment: These won't be fixed in GHC 8.6 -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:56:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:56:04 -0000 Subject: [GHC] #15216: plugins10 broken In-Reply-To: <046.4e5e0be222cd091f3b7f1aa715644fd7@haskell.org> References: <046.4e5e0be222cd091f3b7f1aa715644fd7@haskell.org> Message-ID: <061.3c332a5b5f46ad59c8f5039e8e167682@haskell.org> #15216: plugins10 broken -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 Comment: This won't be fixed for GHC 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:56:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:56:32 -0000 Subject: [GHC] #15064: T8089 mysteriously fails when GHC is built with LLVM In-Reply-To: <046.7f8c4e91c0adf39423142484582ab39d@haskell.org> References: <046.7f8c4e91c0adf39423142484582ab39d@haskell.org> Message-ID: <061.7340809291615d553582e7f7f014049c@haskell.org> #15064: T8089 mysteriously fails when GHC is built with LLVM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: osa1 Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (LLVM) | Version: 8.2.2 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 Comment: This won't be fixed for GHC 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 6 22:56:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Aug 2018 22:56:57 -0000 Subject: [GHC] #15455: Memory usage when compiling jsaddle-dom exploded in 8.4.3 In-Reply-To: <046.e653d9fec09649e1b4a200e6da1c2507@haskell.org> References: <046.e653d9fec09649e1b4a200e6da1c2507@haskell.org> Message-ID: <061.485818397876756f2df56256d62a1915@haskell.org> #15455: Memory usage when compiling jsaddle-dom exploded in 8.4.3 -------------------------------------+------------------------------------- Reporter: eskimor | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 Comment: This won't be fixed for GHC 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 7 02:27:30 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Aug 2018 02:27:30 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.7eb2d609b1aa8682d42a4f21342a4aff@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): OK. So `NDFV` behaves roughly identically to `FV` -- faster than just a bare `VarSet`. But ''why''? Let's look at the difference between `NDFV` and `VarSet`. 1. The former has an `InterestingVarFun`. But I don't believe that's used in your tests. 2. The former maintains a set of elements to be removed, while the latter just algorithmically removes elements when necessary. 3. The former uses an accumulator to build sets, while the latter does not. Which of these factors contributes to the performance change? To learn this, we can test each in isolation, by removing the difference and then measuring. I suspect (2). If this is the case, perhaps we'll discover an optimization that can apply well beyond GHC! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 7 03:01:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Aug 2018 03:01:42 -0000 Subject: [GHC] #15220: ScopedTypeVariables binds a non-existent variable In-Reply-To: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> References: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> Message-ID: <062.f89090df1c43fee55092de53deefb251@haskell.org> #15220: ScopedTypeVariables binds a non-existent variable -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): We should still make sure we never zonk a `SigTv` to `Any`, so we can't close quite yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 7 05:33:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Aug 2018 05:33:45 -0000 Subject: [GHC] #15485: GHC uses 300% CPU when calling into blocking C call Message-ID: <047.13adf0146883a7a0c2f9dc50bb228513@haskell.org> #15485: GHC uses 300% CPU when calling into blocking C call -------------------------------------+------------------------------------- Reporter: oconnore | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime | Version: 8.4.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello, I'm trying to write a program that modifies /etc/passwd safely, and so I wrote a function that looks like this: {{{#!hs lockPwd f = bracket main recover (\_ -> f) where mode = unionFileModes ownerReadMode ownerWriteMode main = do fd <- openFd "/etc/.pwd.lock" WriteOnly (Just mode) defaultFileFlags putStrLn "waiting to set lock" waitToSetLock fd (WriteLock, AbsoluteSeek, 0, 0) putStrLn "got lock" return fd recover = flip setLock (Unlock, AbsoluteSeek, 0, 0) }}} When I run it, my fans go wild, and CPU usage hits 300%. /u/gelisam did some more in depth investigation here: https://www.reddit.com/r/haskell/comments/94wbfc/systemunixiowaittosetlock_call_results_in_300_cpu/e3p7sks/ > Googling confirms that the parallel gc is using spin locks. So I think what is happening is that the waitToSetLock call makes the current thread unavailable for garbage collection (I don't know if that means the thread is "descheduled" as in the linked issue), which then causes the other threads to spin-lock while waiting for that thread at the next parallel GC. The problem still occurs with the latest release, GHC 8.4.3, and I could not find an existing issue describing the problem, so please file a ticket. Maybe an argument could be made that this waitToSetLock call should be converted to be [[https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ffi- chap.html#interruptible-foreign-calls|interruptible]], but it also seems like I should be able to make my haskell program block patiently if I want it to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 7 06:01:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Aug 2018 06:01:54 -0000 Subject: [GHC] #15486: primops.txt.pp still has support for WORD_SIZE_IN_BITS < 32 Message-ID: <047.b07118037eff8ffdb7c16341c32020aa@haskell.org> #15486: primops.txt.pp still has support for WORD_SIZE_IN_BITS < 32 -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Was support for `WORD_SIZE_IN_BITS < 32` dropped? According to [https://github.com/ghc/ghc/commit/b38f08350d5c0efaa613f2f6c67dad5366aac271 this GHC commit], it appears that that support was dropped about seven years ago. Also, `find -type f | xargs -n 5 egrep 'WORD_SIZE_IN_BITS\s*<\s*32'` only finds mention of it in `primops.txt.pp`. If support for that was dropped, [https://github.com/ghc/ghc/blob/9897f6783a58265d5eaef5fb06f04320c7737e87/compiler/prelude/primops.txt.pp the current version of compiler/prelude/primops.txt.pp] has dead code and misleading documentation (that's apparently propagated to [https://hackage.haskell.org/package/ghc-prim-0.5.2.0/docs/GHC-Prim.html GHC.Prim documentation]) that might cause programmers to expend unnecessary effort supporting `WORD_SIZE_IN_BITS < 32` in their own code. The following documentation describes a situation that can no longer happen and continues on incorrectly past these two paragraphs: >Haskell98 specifies that signed integers (type `Int` must contain at least 30 bits. GHC always implements `Int` using the primitive type `Int#`, whose size equals the `MachDeps.h` constant `WORD_SIZE_IN_BITS`. > >This is normally set based on the `config.h` parameter `SIZEOF_HSWORD`, i.e., 32 bits on 32-bit machines, 64 bits on 64-bit machines. However, it can also be explicitly set to a smaller number, e.g., 31 bits, to allow the possibility of using tag bits. Currently GHC itself has only 32-bit and 64-bit variants, '''but 30 or 31-bit code can be exported as an external core file for use in other back ends'''. The following is dead code. Further, `INT32` and `WORD32` throughout the document should be replaced with `Int#` and `Word#`: {{{#!c #if WORD_SIZE_IN_BITS < 32 #define INT32 Int32# #define WORD32 Word32# #else #define INT32 Int# #define WORD32 Word# #endif }}} Also, all code inclusively between `#if WORD_SIZE_IN_BITS < 32` lines and their matching `#endif`s can be eliminated. ---- On the other hand, if `WORD_SIZE_IN_BITS < 32` '''is''' still supported, there are a lot of cases wherein a 64-bit version of an instruction uses `INT64` or `WORD64` in its type signature, but the 32-bit version uses `Int#` or `Word#`, which robs programmers of the ability to use speedy hardware instructions on full untagged `Int32#`s or `Word32#`s. Also, the `Double#` decoder to two `Word#`s for the mantissa assumes that the `Word#`s can hold a full 32 bits according to its documentation. There are some other problems that I've forgotten as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 7 07:52:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Aug 2018 07:52:07 -0000 Subject: [GHC] #15482: the_gc_thread variable from GC.c is not aligned to 64 In-Reply-To: <045.517cd029a074e1225f6142d10f834f62@haskell.org> References: <045.517cd029a074e1225f6142d10f834f62@haskell.org> Message-ID: <060.3b2c764435c4dacd47e7f61d9b9619ca@haskell.org> #15482: the_gc_thread variable from GC.c is not aligned to 64 -------------------------------------+------------------------------------- Reporter: arrowd | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | 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 osa1): > Merged in 87a79e394013e5f722496900227b126015d0d780. This commit isn't in the git repo. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 7 11:56:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Aug 2018 11:56:59 -0000 Subject: [GHC] #15241: Validate failures in sanity way In-Reply-To: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> References: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> Message-ID: <058.be883f8629f1d36ee32c930908b5de67@haskell.org> #15241: Validate failures in sanity way -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4839 Wiki Page: | -------------------------------------+------------------------------------- Description changed by osa1: Old description: > It seems like some of the sanity checks fail when running the test suite. > To reproduce, run the test suite using: > > {{{ > make EXTRA_HC_OPTS='-debug -rtsopts' WAY=sanity THREADS=12 > }}} > > Results: > > {{{ > Unexpected failures: > rts/T2783.run T2783 [bad exit > code] (sanity) > rts/flags/T12870e.run T12870e [bad > stdout] (sanity) > rts/flags/T12870f.run T12870f [bad > stdout] (sanity) > ../../libraries/base/tests/length001.run length001 [bad > exit code] (sanity) > ../../libraries/ghc-heap/tests/heap_all.run heap_all [bad > exit code] (sanity) > rts/T7919.run T7919 [bad exit > code] (sanity) > ../../libraries/base/tests/memo001.run memo001 [bad exit > code] (sanity) > ../../libraries/hpc/tests/raytrace/hpc_raytrace.run hpc_raytrace [bad > exit code] (sanity) > }}} > > T2783: > > {{{ > T2783: internal error: ASSERTION FAILED: file rts/ThreadPaused.c, line > 314 > > Stack trace: > test: Failed to get stack frames of current process: no matching address > range: Success > 0x4a3fbd set_initial_registers (rts/Libdw.c:288.0) > 0x7f9d70fd7a18 dwfl_thread_getframes (/usr/lib/x86_64 > -linux-gnu/libdw-0.170.so) > 0x7f9d70fd7efc dwfl_getthread_frames (/usr/lib/x86_64 > -linux-gnu/libdw-0.170.so) > 0x4a3eb6 libdwGetBacktrace (rts/Libdw.c:257.0) > 0x474de3 rtsFatalInternalErrorFn > (rts/RtsMessages.c:171.0) > 0x474ad0 barf (rts/RtsMessages.c:48.0) > 0x474b02 errorBelch (rts/RtsMessages.c:67.0) > 0x479273 threadPaused (rts/ThreadPaused.c:318.0) > 0x48ccdb stg_returnToSched > (rts/StgStartup.cmm:117.1) > 0x48f428 stg_enter_info > (rts/HeapStackCheck.cmm:166.1) > 0x45fd18 > integerzmgmp_GHCziIntegerziType_minusInteger_info > (/home/omer/haskell/test) > > (GHC version 8.4.2 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > zsh: abort (core dumped) ./T2783 +RTS -DS > }}} > > memo001: > > {{{ > memo001: internal error: ASSERTION FAILED: file rts/sm/GCAux.c, line 44 > > (GHC version 8.5.20180612 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > zsh: abort (core dumped) ./memo001 +RTS -DS -A10k > }}} > > length001: > > {{{ > length001: Stack space overflow: current size 33624 bytes. > length001: Use `+RTS -Ksize -RTS' to increase it. > }}} > > Note that the test is run with `-K8m`. New description: It seems like some of the sanity checks fail when running the test suite. To reproduce, run the test suite using: {{{ make EXTRA_HC_OPTS='-debug -rtsopts' WAY=sanity THREADS=12 }}} Results: {{{ Unexpected failures: rts/T2783.run T2783 [bad exit code] (sanity) rts/flags/T12870e.run T12870e [bad stdout] (sanity) rts/flags/T12870f.run T12870f [bad stdout] (sanity) ../../libraries/base/tests/length001.run length001 [bad exit code] (sanity) ../../libraries/ghc-heap/tests/heap_all.run heap_all [bad exit code] (sanity) rts/T7919.run T7919 [bad exit code] (sanity) ../../libraries/base/tests/memo001.run memo001 [bad exit code] (sanity) ../../libraries/hpc/tests/raytrace/hpc_raytrace.run hpc_raytrace [bad exit code] (sanity) }}} T2783: {{{ T2783: internal error: ASSERTION FAILED: file rts/ThreadPaused.c, line 314 Stack trace: test: Failed to get stack frames of current process: no matching address range: Success 0x4a3fbd set_initial_registers (rts/Libdw.c:288.0) 0x7f9d70fd7a18 dwfl_thread_getframes (/usr/lib/x86_64 -linux-gnu/libdw-0.170.so) 0x7f9d70fd7efc dwfl_getthread_frames (/usr/lib/x86_64 -linux-gnu/libdw-0.170.so) 0x4a3eb6 libdwGetBacktrace (rts/Libdw.c:257.0) 0x474de3 rtsFatalInternalErrorFn (rts/RtsMessages.c:171.0) 0x474ad0 barf (rts/RtsMessages.c:48.0) 0x474b02 errorBelch (rts/RtsMessages.c:67.0) 0x479273 threadPaused (rts/ThreadPaused.c:318.0) 0x48ccdb stg_returnToSched (rts/StgStartup.cmm:117.1) 0x48f428 stg_enter_info (rts/HeapStackCheck.cmm:166.1) 0x45fd18 integerzmgmp_GHCziIntegerziType_minusInteger_info (/home/omer/haskell/test) (GHC version 8.4.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./T2783 +RTS -DS }}} memo001: {{{ memo001: internal error: ASSERTION FAILED: file rts/sm/GCAux.c, line 44 (GHC version 8.5.20180612 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./memo001 +RTS -DS -A10k }}} length001: {{{ length001: Stack space overflow: current size 33624 bytes. length001: Use `+RTS -Ksize -RTS' to increase it. }}} Note that the test is run with `-K8m`. hpc_raytrace: gets killed because of timeout. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 7 12:59:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Aug 2018 12:59:59 -0000 Subject: [GHC] #15487: "Ambiguos occurrence" error message uses strange qualification Message-ID: <049.ec049728f6597ec6e0ea496f9893f7ce@haskell.org> #15487: "Ambiguos occurrence" error message uses strange qualification -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following text produces an error message that I find somewhat confusing. This issue is just about the wording of the message. {{{#!hs module A (null) where { } module B where { import qualified A ; null = 42 ; main = null } }}} when I load `B` in ghci, I get {{{ B.hs:1:58: error: Ambiguous occurrence ‘null’ It could refer to either ‘A.null’, imported from ‘Prelude’ at B.hs:1:8 (and originally defined in ‘Data.Foldable’) or ‘B.null’, defined at B.hs:1:39 }}} I think ".. could refer to A.null" looks strange. I would expect `Prelude.null` here, which I do get when I remove "import qualified A" from the text of `B`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 7 14:43:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Aug 2018 14:43:46 -0000 Subject: [GHC] #15472: GHC HEAD type inference regression post-"Remove decideKindGeneralisationPlan" In-Reply-To: <050.060e4a1d545056b90564d103437d8ddb@haskell.org> References: <050.060e4a1d545056b90564d103437d8ddb@haskell.org> Message-ID: <065.b0bed306b430d9c7ec9e1e9276122f08@haskell.org> #15472: GHC HEAD type inference regression post-"Remove decideKindGeneralisationPlan" -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: invalid | 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 RyanGlScott): Thanks, monoidal. I've attempted to update the 8.8 Migration Guide ([https://ghc.haskell.org/trac/ghc/wiki/Migration/8.8?version=2#Kindgeneralizationchangesforlocaldefinitions here]) using this code as an example. goldfire, please shout if my explanation of the issue is wrong is misleading. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 7 15:29:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Aug 2018 15:29:36 -0000 Subject: [GHC] #12607: Memory effects in doomed STM transactions In-Reply-To: <048.8420da21b30e1acff617432d38e2d2e2@haskell.org> References: <048.8420da21b30e1acff617432d38e2d2e2@haskell.org> Message-ID: <063.787911f7e49b4793236702e6f709386e@haskell.org> #12607: Memory effects in doomed STM transactions -------------------------------------+------------------------------------- Reporter: fryguybob | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.1 Resolution: | Keywords: STM, allocate Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by fryguybob): I'm looking at this again and a way to fix the problem is to validate a transaction before you do a large allocation in `rts/sm/Storage.c` `allocate`. I know how to do validation at that point with `stmValidateNestOfTransactions`, but if the transaction is invalid, we do not want to continue executing. How do we gracefully end the transaction at that point? Really all we need to do is gracefully get back to the scheduler loop. Any ideas? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 7 17:12:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Aug 2018 17:12:35 -0000 Subject: [GHC] #15482: the_gc_thread variable from GC.c is not aligned to 64 In-Reply-To: <045.517cd029a074e1225f6142d10f834f62@haskell.org> References: <045.517cd029a074e1225f6142d10f834f62@haskell.org> Message-ID: <060.e2b708f50cc7cf2dc1a9aad6cc41154a@haskell.org> #15482: the_gc_thread variable from GC.c is not aligned to 64 -------------------------------------+------------------------------------- Reporter: arrowd | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | 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 bgamari): I'm not sure what you mean; it surely is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 7 17:15:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Aug 2018 17:15:56 -0000 Subject: [GHC] #9868: ghc: panic! Dynamic linker not initialised In-Reply-To: <046.5f3f9e960e287bc6e82a07e7ce17a8b6@haskell.org> References: <046.5f3f9e960e287bc6e82a07e7ce17a8b6@haskell.org> Message-ID: <061.c55738ce023e896e30dd42e182e722dc@haskell.org> #9868: ghc: panic! Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: Jamedjo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #10355, #10919, | Differential Rev(s): Phab:D5012 #13137, #13531, #13607 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 Comment: I believe this should now be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 7 17:16:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Aug 2018 17:16:09 -0000 Subject: [GHC] #13607: Panic when shared object file is missing: Dynamic linker not initialised In-Reply-To: <050.42a412821545515fa30e9fa080a5d0f2@haskell.org> References: <050.42a412821545515fa30e9fa080a5d0f2@haskell.org> Message-ID: <065.0757d268e2f1042a809b01c2e367754d@haskell.org> #13607: Panic when shared object file is missing: Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #9868, #10355, | Differential Rev(s): Phab:D5012 #10919, #13137, #13531 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 Comment: I believe this should be fixed in 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 7 17:16:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Aug 2018 17:16:28 -0000 Subject: [GHC] #10355: Dynamic linker not initialised In-Reply-To: <046.b020405a0b5eb69acc1047433b42d151@haskell.org> References: <046.b020405a0b5eb69acc1047433b42d151@haskell.org> Message-ID: <061.1a8dc3d36f56bccbe619c67200ab25d9@haskell.org> #10355: Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: dpiponi | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9868, #10919, | Differential Rev(s): Phab:D5012 #13137, #13531, #13607 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 Comment: I believe this should be fixed in 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 7 17:16:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Aug 2018 17:16:41 -0000 Subject: [GHC] #13137: Dynamic linker not initialised. In-Reply-To: <045.40f0726ebefc735f7ea0c8f42d81dbc6@haskell.org> References: <045.40f0726ebefc735f7ea0c8f42d81dbc6@haskell.org> Message-ID: <060.4d29faf8d9aac8937ddeaec009559b95@haskell.org> #13137: Dynamic linker not initialised. -------------------------------------+------------------------------------- Reporter: djduke | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9868, #10355, | Differential Rev(s): Phab:D5012 #10919, #13531, #13607 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.1 Comment: I believe this should be fixed in 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 7 17:21:05 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Aug 2018 17:21:05 -0000 Subject: [GHC] #15486: primops.txt.pp still has support for WORD_SIZE_IN_BITS < 32 In-Reply-To: <047.b07118037eff8ffdb7c16341c32020aa@haskell.org> References: <047.b07118037eff8ffdb7c16341c32020aa@haskell.org> Message-ID: <062.5ad00698aa2f740aa5586d1ee5e2b157@haskell.org> #15486: primops.txt.pp still has support for WORD_SIZE_IN_BITS < 32 -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm pretty certain any recent GHC would blow up spectacularly if you somehow managed to compile it on a `WORD_SIZE_IN_BITS < 32` platform. We ought to drop the dead code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 7 17:25:25 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Aug 2018 17:25:25 -0000 Subject: [GHC] #15486: primops.txt.pp still has support for WORD_SIZE_IN_BITS < 32 In-Reply-To: <047.b07118037eff8ffdb7c16341c32020aa@haskell.org> References: <047.b07118037eff8ffdb7c16341c32020aa@haskell.org> Message-ID: <062.2b7629d41008bf7fbd892435b00b1887@haskell.org> #15486: primops.txt.pp still has support for WORD_SIZE_IN_BITS < 32 -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5050 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D5050 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 7 17:48:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Aug 2018 17:48:15 -0000 Subject: [GHC] #10599: Template Haskell doesn't allow `newName "type"` In-Reply-To: <048.829d4ff7778a587a956aa230325a65a0@haskell.org> References: <048.829d4ff7778a587a956aa230325a65a0@haskell.org> Message-ID: <063.43cf0a6ecffc794a6ce98b53477b4a05@haskell.org> #10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by k-bx): * cc: k-bx (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 7 18:48:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Aug 2018 18:48:44 -0000 Subject: [GHC] #15468: in ghci -fbreak-on-exception omits exception info In-Reply-To: <045.c69e90cb12eca9530a2ffc4e534856c3@haskell.org> References: <045.c69e90cb12eca9530a2ffc4e534856c3@haskell.org> Message-ID: <060.d6cac5f2d5e36501fafbc7846f12baff@haskell.org> #15468: in ghci -fbreak-on-exception omits exception info -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.4.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * status: new => closed * resolution: => invalid Comment: :force does what I want -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 7 19:03:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Aug 2018 19:03:17 -0000 Subject: [GHC] #15468: add -Wname-shadowing and -Wunused-pattern-binds to the default warnings for ghci (was: in ghci -fbreak-on-exception omits exception info) In-Reply-To: <045.c69e90cb12eca9530a2ffc4e534856c3@haskell.org> References: <045.c69e90cb12eca9530a2ffc4e534856c3@haskell.org> Message-ID: <060.d98d9598f65816045333d5e88f6853dd@haskell.org> #15468: add -Wname-shadowing and -Wunused-pattern-binds to the default warnings for ghci -------------------------------------+------------------------------------- Reporter: George | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.4.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: | -------------------------------------+------------------------------------- Changes (by George): * status: closed => new * resolution: invalid => * type: bug => feature request Old description: > In ghc 8.4.3 > > Without -fbreak-on-exception you get a good error message: > > {{{ > ghci -ignore-dot-ghci > GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help > Prelude> let 2 + 2 = 5 > Prelude> 2 + 2 > 5 > Prelude> 3 + 3 > *** Exception: :1:5-13: Non-exhaustive patterns in function > + > }}} > > With -fbreak-on-exception there is no info about the exception: > > {{{ > ghci -ignore-dot-ghci -fbreak-on-exception > GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help > Prelude> let 2 + 2 = 5 > Prelude> 2 + 2 > 5 > Prelude> 3 + 3 > Stopped in , > _exception :: e = _ > [] [] Prelude> > }}} > > In addition, contrary to the documentation, it doesn't seem possible to > get ghci to print out the value of the exception > > {{{ > ] [] Prelude> :print _exception > _exception = (_t1::e) > [] [] Prelude> :info _exception > _exception :: e -- Defined in ‘interactive:Ghci3’ > [] [] Prelude> > }}} > > Finally the fact that you get no warning about > > {{{ > let 2 + 2 = 5 > }}} > > or for > {{{ > 2 = 3 > }}} > > makes me think I should file an ER to add the following to the default > warnings for ghci > > {{{ > ghci -ignore-dot-ghci -Wname-shadowing -Wunused-pattern-binds > GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help > Prelude> let 2 + 2 = 5 > > :1:7: warning: [-Wname-shadowing] > This binding for ‘+’ shadows the existing binding > imported from ‘Prelude’ (and originally defined in ‘GHC.Num’) > Prelude> 2 = 3 > > :2:1: warning: [-Wunused-pattern-binds] > This pattern-binding binds no variables: 2 = 3 > Prelude> > }}} > > I noticed the second and when googling to see if it had been reported I > came across the following which documented the first: > https://code.likeagirl.io/2-2-5-and-why-compiler-warnings-are-good- > eaadef327146 New description: In ghc 8.4.3 {{{ ghci -ignore-dot-ghci GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> let 2 + 2 = 5 Prelude> 2 + 2 5 }}} Users get no warning about the preceding or or for {{{ 2 = 3 }}} thus suggest that -Wname-shadowing and -Wunused-pattern-binds be added to the default warnings for ghci {{{ ghci -ignore-dot-ghci -Wname-shadowing -Wunused-pattern-binds GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> let 2 + 2 = 5 :1:7: warning: [-Wname-shadowing] This binding for ‘+’ shadows the existing binding imported from ‘Prelude’ (and originally defined in ‘GHC.Num’) Prelude> 2 = 3 :2:1: warning: [-Wunused-pattern-binds] This pattern-binding binds no variables: 2 = 3 Prelude> }}} I noticed the second and when googling to see if it had been reported I came across the following which documented the first: https://code.likeagirl.io/2-2-5-and-why-compiler-warnings-are-good- eaadef327146 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 7 19:40:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Aug 2018 19:40:21 -0000 Subject: [GHC] #15482: the_gc_thread variable from GC.c is not aligned to 64 In-Reply-To: <045.517cd029a074e1225f6142d10f834f62@haskell.org> References: <045.517cd029a074e1225f6142d10f834f62@haskell.org> Message-ID: <060.5e5e479e6059890901975137c4ea230b@haskell.org> #15482: the_gc_thread variable from GC.c is not aligned to 64 -------------------------------------+------------------------------------- Reporter: arrowd | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | 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 osa1): It now is, it wasn't when I posted my comment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 7 19:55:30 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Aug 2018 19:55:30 -0000 Subject: [GHC] #15138: Unable to instantiate data members of kind Nat in backpack signatures. In-Reply-To: <042.e290873b59fcee0c98fbf371f48d1238@haskell.org> References: <042.e290873b59fcee0c98fbf371f48d1238@haskell.org> Message-ID: <057.bf34d6519a1f12e971103e0034ebcb5e@haskell.org> #15138: Unable to instantiate data members of kind Nat in backpack signatures. -------------------------------------+------------------------------------- Reporter: ppk | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.1 Resolution: fixed | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4951 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"7d771987c2766bfedc92f5183d6fd571ab508a0e/ghc" 7d771987/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7d771987c2766bfedc92f5183d6fd571ab508a0e" Support typechecking of type literals in backpack Backpack is unable to type check signatures that expect a data which is a type level literal. This was reported in issue #15138. These commits are a fix for this. It also includes a minimal test case that was mentioned in the issue. Reviewers: bgamari, ezyang, goldfire Reviewed By: bgamari, ezyang Subscribers: simonpj, ezyang, rwbarton, thomie, carter GHC Trac Issues: #15138 Differential Revision: https://phabricator.haskell.org/D4951 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 7 19:55:30 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Aug 2018 19:55:30 -0000 Subject: [GHC] #15473: GHC 8.6+ loops infinitely on an UndecidableInstances error message In-Reply-To: <050.0e1359f1570b3b8da9f1e08c07e4c7b6@haskell.org> References: <050.0e1359f1570b3b8da9f1e08c07e4c7b6@haskell.org> Message-ID: <065.43484fdd6d73f7480a7403c1f6dbcd3f@haskell.org> #15473: GHC 8.6+ loops infinitely on an UndecidableInstances error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a533a09231450b9ce0c94d2990d77749fc744baa/ghc" a533a09/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a533a09231450b9ce0c94d2990d77749fc744baa" testsuite: Add (broken) test for #15473 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 7 19:57:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Aug 2018 19:57:09 -0000 Subject: [GHC] #15473: GHC 8.6+ loops infinitely on an UndecidableInstances error message In-Reply-To: <050.0e1359f1570b3b8da9f1e08c07e4c7b6@haskell.org> References: <050.0e1359f1570b3b8da9f1e08c07e4c7b6@haskell.org> Message-ID: <065.4fcdf71743a4b321d226c73533731f01@haskell.org> #15473: GHC 8.6+ loops infinitely on an UndecidableInstances error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5487f305d9dea298f0822082389d8a0225956c55/ghc" 5487f305/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5487f305d9dea298f0822082389d8a0225956c55" testsuite: Add (broken) test for #15473 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 7 22:41:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Aug 2018 22:41:44 -0000 Subject: [GHC] #5142: stub header files don't work with the MS C compiler In-Reply-To: <047.54b8421507beab9ed5b9b5ea133b33f5@haskell.org> References: <047.54b8421507beab9ed5b9b5ea133b33f5@haskell.org> Message-ID: <062.fdb405f2845e8aa8d9e928463cce6ada@haskell.org> #5142: stub header files don't work with the MS C compiler ---------------------------------+---------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.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 thomie): * owner: simonmar => (none) * cc: Phyx- (added) Comment: Azel: you might want to discuss with @Phyx-, but I don't think anyone is working on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 01:05:52 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 01:05:52 -0000 Subject: [GHC] #15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0 Message-ID: <043.32eb5b85b23ae8693c74c6f6abd5a883@haskell.org> #15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0 -------------------------------------+------------------------------------- Reporter: noah | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux accelerate,memory,compile | Architecture: x86_64 | Type of failure: Compile-time (amd64) | performance bug Test Case: accelerate | Blocked By: 1.2.0 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Every time I try to run {{{ cabal install accelerate }}} the compiler take up nearly all 4GB of memory. Stracing it reveals that it seems to be spending nearly all of the time it runs checking a timer file descriptor, and occasionally checking its memory usage without actually doing anything about the problem. This makes installing accelerate nearly impossible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 02:31:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 02:31:22 -0000 Subject: [GHC] #12421: TestEquality and TestCoercion documentation is confusing In-Reply-To: <045.c655c505ffcb7aac601fde4e2ee18aac@haskell.org> References: <045.c655c505ffcb7aac601fde4e2ee18aac@haskell.org> Message-ID: <060.4b1da879a9d52557512fd9cb242e9748@haskell.org> #12421: TestEquality and TestCoercion documentation is confusing -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Zemyla): An instance of `TestCoercion` doesn't need to be a GADT, though. `MutVar` and `MVar`, for instance, have fairly sensible semantics for a hypothetical `TestCoercion` instance: If two mutable variables point at the same spot, then their runtime representation must be the same. The same applies to `StableName`: If two `StableName`s match, then they were created using the same object. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 02:46:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 02:46:40 -0000 Subject: [GHC] #15489: TestCoercion should be a superclass of TestEquality Message-ID: <045.bc9e2f8562ab0ff84b5c436cdbc44591@haskell.org> #15489: TestCoercion should be a superclass of TestEquality -------------------------------------+------------------------------------- Reporter: Zemyla | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Given that you can implement {{{#!hs testCoercionFromEquality :: TestEquality f => f a -> f b -> Maybe (Coercion a b) testCoercionFromEquality fa fb = fmap repr $ testEquality fa fb }}} that shows the superclass relationship. Are there enough libraries that implement new instances of `TestEquality` that adding this superclass would break? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 08:02:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 08:02:22 -0000 Subject: [GHC] #5142: stub header files don't work with the MS C compiler In-Reply-To: <047.54b8421507beab9ed5b9b5ea133b33f5@haskell.org> References: <047.54b8421507beab9ed5b9b5ea133b33f5@haskell.org> Message-ID: <062.86923e6cbf45cd9ab18db3358a768054@haskell.org> #5142: stub header files don't work with the MS C compiler ---------------------------------+---------------------------------------- Reporter: simonmar | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.0.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 Phyx-): No, no one is working on this at the moment as far as I know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 08:56:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 08:56:50 -0000 Subject: [GHC] #13835: ghci with ":set +t" should print type before starting evaluation In-Reply-To: <049.babc2baa39ced2b9a895aa8b0723cb93@haskell.org> References: <049.babc2baa39ced2b9a895aa8b0723cb93@haskell.org> Message-ID: <064.ecb3670292970e151ecb9b233c5deeec@haskell.org> #13835: ghci with ":set +t" should print type before starting evaluation -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | 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 j.waldmann): Here is a somewhat longer explanation: With the current behaviour (print type after value), a naive user (student) thinks * 1. expression e has value v, and then * 2. value v has type t, suggesting that 1 is somehow a precondition for 2, and that a type is a property of a value. But the truth is * 1. expression e has type t, and then * 2. expression e has value v. This 1 //is// a precondition for 2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 09:56:16 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 09:56:16 -0000 Subject: [GHC] #15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0 In-Reply-To: <043.32eb5b85b23ae8693c74c6f6abd5a883@haskell.org> References: <043.32eb5b85b23ae8693c74c6f6abd5a883@haskell.org> Message-ID: <058.bcdef499c543401982931253e0083c45@haskell.org> #15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0 -------------------------------------+------------------------------------- Reporter: noah | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | accelerate,memory,compile Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: accelerate performance bug | 1.2.0 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): Have you tried {{{ strace cabal install accelerate -v -v -v -j1 --ghc-options=-v2 }}} (or similar) it definitely shows that ghc is working. Compilation time still is abysmal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 12:18:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 12:18:14 -0000 Subject: [GHC] #15490: Can Template Haskell and RULES be combined? Message-ID: <047.7e032bb8158a417844a4d7ce8bbd1794@haskell.org> #15490: Can Template Haskell and RULES be combined? -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It would be nice if there was something like this: {{{#!hs {-# RULES "(literal*)" forall n. (n*) = $( makeOptimizedMultiplication [|| n ||] ) #-} }}} where `makeOptimizedMultiplication` is a Template Haskell function that, if `n` is an integer literal, produces an optimized multiplication function for that literal. However, that code above gives a `VarE` corresponding to the `n` in the quoter rather than the AST of the `n` that's actually being matched by the rewrite rule, so I can't get a `LitE` that way. This sort of thing would come in very handy for a large fixed-width integer type, because I don't think GHC and LLVM will know that standard fixed-width integer optimizations apply to it. For example, with a `Word65536` type, multiplying blindly at runtime by the literal `1099511627777` requires a lot of extra work. At the very least, all 65536 bits of that literal have to be read and dealt with pretty blindly. However, at compile time, the compiler can take the time to figure out that `(1099511627777*)` can be replaced with the much, much lighter `(\x -> shiftL x 40 + x)` (and not only that, but if `Word65536`s are stored in a byte array, 1 byte evenly divides the shift amount of 40 bits, which can be exploited to speed things up greatly). With appropriate `RULES` and Template Haskell functions, the compiler gains the ability to apply lots of fixed-width integer optimizations. Since the above sort of code doesn't work, is there some other way to do this that I don't know about? If not, can the feature be added? ---- The only downside I can think of is that the user of the `Word65536` type might not knowingly be expecting Template Haskell to be at work since they didn't use any splices or quoters and might not have even included `{-# LANGUAGE TemplateHaskell #-}` in their code, so perhaps some easy method of consenting to the application of TH-based rewrites might be in order. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 13:36:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 13:36:50 -0000 Subject: [GHC] #15491: No control over synopsis in Library Documentation Message-ID: <043.cb5ee572ce3b8350aa87b62b20003cc2@haskell.org> #15491: No control over synopsis in Library Documentation -------------------------------------+------------------------------------- Reporter: h001 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Documentation (amd64) | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- You can not hide synopsis of Library Documentation (Microsoft Edge 41.16299.402.0, Microsoft EdgeHTML 16.16299) so that reading the documentation is impossible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 13:37:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 13:37:10 -0000 Subject: [GHC] #15491: No control over synopsis in Library Documentation In-Reply-To: <043.cb5ee572ce3b8350aa87b62b20003cc2@haskell.org> References: <043.cb5ee572ce3b8350aa87b62b20003cc2@haskell.org> Message-ID: <058.1f6b2a62919b1d7304645dbe6cfd3af9@haskell.org> #15491: No control over synopsis in Library Documentation -------------------------------------+------------------------------------- Reporter: h001 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Documentation | (amd64) bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by h001): * Attachment "p.jpg" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 13:42:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 13:42:24 -0000 Subject: [GHC] #10869: Option to dump preprocessed source In-Reply-To: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> References: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> Message-ID: <061.99da29ee5c98cd99e012e7b165f6e419@haskell.org> #10869: Option to dump preprocessed source -------------------------------------+------------------------------------- Reporter: phischu | Owner: RolandSenn Type: feature request | Status: patch Priority: low | Milestone: Component: Driver | Version: 7.10.2 Resolution: | Keywords: easy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10869 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D4861 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RolandSenn): Flag is now called **keep-hscpp-file**. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 14:11:52 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 14:11:52 -0000 Subject: [GHC] #15491: No control over synopsis in Library Documentation In-Reply-To: <043.cb5ee572ce3b8350aa87b62b20003cc2@haskell.org> References: <043.cb5ee572ce3b8350aa87b62b20003cc2@haskell.org> Message-ID: <058.bc15501e71543113660c2873a21b4c09@haskell.org> #15491: No control over synopsis in Library Documentation -------------------------------------+------------------------------------- Reporter: h001 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Documentation | (amd64) bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => invalid Comment: Thanks for the bug report. However, this site is intended for bugs in GHC itself, not Haddock bugs. I encourage you to open an issue at https://github.com/haskell/haddock/issues instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 14:24:54 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 14:24:54 -0000 Subject: [GHC] #15490: Can Template Haskell and RULES be combined? In-Reply-To: <047.7e032bb8158a417844a4d7ce8bbd1794@haskell.org> References: <047.7e032bb8158a417844a4d7ce8bbd1794@haskell.org> Message-ID: <062.890981ce8ef39c92c9fadb5e03df810c@haskell.org> #15490: Can Template Haskell and RULES be combined? -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Template Haskell is the wrong tool for this, since it deals with Haskell (the surface language), but rules actually apply to Core. But I suppose you can write a GHC plugin that installs a `BuiltInRule` (see https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc-8.4.3/CoreSyn.html#t:CoreRule) which can have arbitrary functions to decide whether the rule fires, and what to replace it with. Or write a GHC Plugin with a Core2Core pass that simply rewrites the code as desired. In all cases, the plugin will have to be loaded explicitly, i.e. these kind of rules are not exported. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 14:40:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 14:40:06 -0000 Subject: [GHC] #15392: Inconsistency in parsing trailing commas inside import section In-Reply-To: <047.bf5810ab1ba7cf69560278d4553648c5@haskell.org> References: <047.bf5810ab1ba7cf69560278d4553648c5@haskell.org> Message-ID: <062.87ad30f6ae627e4d71869c7f1dc19ca4@haskell.org> #15392: Inconsistency in parsing trailing commas inside import section -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 (Parser) | Keywords: Resolution: | imports,trailing,commas Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chshersh): bgamari, so this is indeed a bug and it makes sense to fix it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 16:04:52 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 16:04:52 -0000 Subject: [GHC] #15392: Inconsistency in parsing trailing commas inside import section In-Reply-To: <047.bf5810ab1ba7cf69560278d4553648c5@haskell.org> References: <047.bf5810ab1ba7cf69560278d4553648c5@haskell.org> Message-ID: <062.9cc71d2db89f1873f43b0c25d66782c2@haskell.org> #15392: Inconsistency in parsing trailing commas inside import section -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 (Parser) | Keywords: Resolution: | imports,trailing,commas Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Not a bug, unfortunately, but behavious as specified in the report: https://www.haskell.org/onlinereport/haskell2010/haskellch5.html#x11-1000005.2 There is a language extensions proposal underway that would fix this, but it now does much more stuff: https://github.com/ghc-proposals/ghc-proposals/pull/87 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 16:08:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 16:08:33 -0000 Subject: [GHC] #15490: Can Template Haskell and RULES be combined? In-Reply-To: <047.7e032bb8158a417844a4d7ce8bbd1794@haskell.org> References: <047.7e032bb8158a417844a4d7ce8bbd1794@haskell.org> Message-ID: <062.e9cecc8fe45f6a1302017dc1f8df1c1e@haskell.org> #15490: Can Template Haskell and RULES be combined? -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ChaiTRex): OK. Thanks for the pointer to GHC plugins. I'll look into that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 18:13:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 18:13:38 -0000 Subject: [GHC] #10927: IndexError: pop from empty list In-Reply-To: <045.caca6922033a1cb1a5f73e4552615a1e@haskell.org> References: <045.caca6922033a1cb1a5f73e4552615a1e@haskell.org> Message-ID: <060.bbe9e9f4dc3a21a59adcc57f10858c5e@haskell.org> #10927: IndexError: pop from empty list -------------------------------------+------------------------------------- Reporter: schwab | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => new * owner: hvr => (none) * resolution: fixed => Comment: Yes, the bug is back. CC @hvr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 18:14:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 18:14:08 -0000 Subject: [GHC] #10927: IndexError: pop from empty list In-Reply-To: <045.caca6922033a1cb1a5f73e4552615a1e@haskell.org> References: <045.caca6922033a1cb1a5f73e4552615a1e@haskell.org> Message-ID: <060.d3bc4d3931169849bd14b8c80ad20ad6@haskell.org> #10927: IndexError: pop from empty list -------------------------------------+------------------------------------- Reporter: schwab | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: hvr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 18:27:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 18:27:30 -0000 Subject: [GHC] #15085: :type-at/:all-types and :r don't mix In-Reply-To: <044.f4e4f79c3e387be82389134e302aff88@haskell.org> References: <044.f4e4f79c3e387be82389134e302aff88@haskell.org> Message-ID: <059.52ddd2c4b164355553ed475d4f9a6c15@haskell.org> #15085: :type-at/:all-types and :r don't mix -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dmwit): Sure, here's a copy-and-paste of a session with 8.4.2. (I don't have 8.4.3 handy to test with.) {{{ % ghci-8.4.2 -ignore-dot-ghci GHCi, version 8.4.2: http://www.haskell.org/ghc/ :? for help Prelude> :!cat test.hs x = () Prelude> :set +c Prelude> :l test.hs [1 of 1] Compiling Main ( test.hs, interpreted ) Ok, one module loaded. Collecting type info for 1 module(s) ... *Main> :all-types test.hs:(1,1)-(1,2): () test.hs:(1,5)-(1,7): () *Main> :!cat test.hs x = True *Main> :r [1 of 1] Compiling Main ( test.hs, interpreted ) Ok, one module loaded. *Main> :all-types test.hs:(1,1)-(1,2): () test.hs:(1,5)-(1,7): () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 18:37:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 18:37:36 -0000 Subject: [GHC] #15085: :type-at/:all-types and :r don't mix In-Reply-To: <044.f4e4f79c3e387be82389134e302aff88@haskell.org> References: <044.f4e4f79c3e387be82389134e302aff88@haskell.org> Message-ID: <059.93bee0020d264b617785e5ea0758739b@haskell.org> #15085: :type-at/:all-types and :r don't mix -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dmwit): Okay, I confirmed the bug still exists in 8.4.3. The transcript is essentially identical to the one I posted above for 8.4.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 19:10:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 19:10:22 -0000 Subject: [GHC] #4442: Add unaligned version of indexWordArray# In-Reply-To: <044.4c85d11a3d9c22b5e6021cb85ad43106@haskell.org> References: <044.4c85d11a3d9c22b5e6021cb85ad43106@haskell.org> Message-ID: <059.55f790efe71f86fde366f3e3ff5e9d73@haskell.org> #4442: Add unaligned version of indexWordArray# -------------------------------------+------------------------------------- Reporter: tibbe | Owner: reinerp Type: feature request | Status: closed Priority: low | Milestone: Component: Compiler | Version: 7.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14447 | Differential Rev(s): Phab:D4488 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * differential: => Phab:D4488 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 19:25:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 19:25:07 -0000 Subject: [GHC] #12043: internal error: evacuate: strange closure type In-Reply-To: <047.629114b05785e472aaf473c1aa71fdb1@haskell.org> References: <047.629114b05785e472aaf473c1aa71fdb1@haskell.org> Message-ID: <062.c7aacf471d5923558d2827fd371a12fc@haskell.org> #12043: internal error: evacuate: strange closure type ----------------------------------+------------------------------ Reporter: mattchan | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: invalid | Keywords: Operating System: MacOS X | Architecture: ia64 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Changes (by thomie): * status: infoneeded => closed * resolution: => invalid Comment: Please reopen if it happens again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 20:00:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 20:00:13 -0000 Subject: [GHC] #15492: Plugin recompilation check fails when profiling is enabled Message-ID: <049.6cd45f735e6cc5104c701afb7f68bb71@haskell.org> #15492: Plugin recompilation check fails when profiling is enabled -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When compiling with profiling enabled and using a plugin, GHC will panic as follows: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.6.1.20180803 for x86_64-unknown-linux): mkPluginUsage: no dylibs GraphMod Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/deSugar/DsUsage.hs:178:15 in ghc:DsUsage }}} Investigating determines that the following paths are being inspected: {{{ /nix/store/m0ylnbifx5ba1qwi8vzipxq4p7ma3073-graphmod- plugin-0.1.0.0/lib/ghc-8.6.1.20180803/x86_64-linux-ghc-8.6.1.20180803 /libHSgraphmod-plugin-0.1.0.0-3YjHj1EtcCZGtpEicyDU7w_p- ghc8.6.1.20180803.so /nix/store/q8rg4mca5zqv98arpxd7164pqa72hf1n-ncurses-6.1/lib/libHSgraphmod- plugin-0.1.0.0-3YjHj1EtcCZGtpEicyDU7w_p-ghc8.6.1.20180803.so /nix/store/hhzvw77vrmn5f506kfyb1yh1sdinkbwf-gmp-6.1.2/lib/libHSgraphmod- plugin-0.1.0.0-3YjHj1EtcCZGtpEicyDU7w_p-ghc8.6.1.20180803.so }}} None of which exist. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 20:10:39 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 20:10:39 -0000 Subject: [GHC] #12002: Pragmas after a module declaration are ignored without warning. In-Reply-To: <050.a06dfff8e83390aaf98ce91845f96e30@haskell.org> References: <050.a06dfff8e83390aaf98ce91845f96e30@haskell.org> Message-ID: <065.d65a6e266abfb622385bcf34f23cdf10@haskell.org> #12002: Pragmas after a module declaration are ignored without warning. -------------------------------------+------------------------------------- Reporter: seanparsons | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Parser) | 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: #2260 #13918 | Differential Rev(s): #13921 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: Other => Incorrect error/warning at compile-time Comment: Replying to [comment:3 harpocrates]: > I'll be submitting a fix for this shortly. @harpocrates: did you manage to create that patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 20:42:55 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 20:42:55 -0000 Subject: [GHC] #15461: Machine accessible interface to GHCi In-Reply-To: <046.c2d301970bbdff7b63fe4e2523868200@haskell.org> References: <046.c2d301970bbdff7b63fe4e2523868200@haskell.org> Message-ID: <061.18199c50b34cbb8dec76c3b0f641ac84@haskell.org> #15461: Machine accessible interface to GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.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: | -------------------------------------+------------------------------------- Comment (by alanz): There was a discussion on IRC a while back, the record is here: https://gist.github.com/alanz/8f6325c670247f51fbd31c78692c4d66 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 21:23:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 21:23:02 -0000 Subject: [GHC] #15491: No control over synopsis in Library Documentation In-Reply-To: <043.cb5ee572ce3b8350aa87b62b20003cc2@haskell.org> References: <043.cb5ee572ce3b8350aa87b62b20003cc2@haskell.org> Message-ID: <058.03c5640520f5e24f3ffcd271685c9931@haskell.org> #15491: No control over synopsis in Library Documentation -------------------------------------+------------------------------------- Reporter: h001 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Documentation | (amd64) bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by h001): I think that it should be reported to the one who generates the documentation. Does Haddock maintainer generate documentation ? The same problem applies to documentation on https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 21:25:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 21:25:02 -0000 Subject: [GHC] #15491: No control over synopsis in Library Documentation In-Reply-To: <043.cb5ee572ce3b8350aa87b62b20003cc2@haskell.org> References: <043.cb5ee572ce3b8350aa87b62b20003cc2@haskell.org> Message-ID: <058.d23e8dca4fc196041a3c33b8d6ab6881@haskell.org> #15491: No control over synopsis in Library Documentation -------------------------------------+------------------------------------- Reporter: h001 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Resolution: invalid | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Documentation | (amd64) bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by h001): Replying to [comment:1 RyanGlScott]: > Thanks for the bug report. However, this site is intended for bugs in GHC itself, not Haddock bugs. I encourage you to open an issue at https://github.com/haskell/haddock/issues instead. I think that it should be reported to the one who generates the documentation. Does Haddock maintainer generate documentation ? The same problem applies to documentation on https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 23:03:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 23:03:59 -0000 Subject: [GHC] #15482: the_gc_thread variable from GC.c is not aligned to 64 In-Reply-To: <045.517cd029a074e1225f6142d10f834f62@haskell.org> References: <045.517cd029a074e1225f6142d10f834f62@haskell.org> Message-ID: <060.4176a001c464a2c87edd2e0420ca1fb0@haskell.org> #15482: the_gc_thread variable from GC.c is not aligned to 64 -------------------------------------+------------------------------------- Reporter: arrowd | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | 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 bgamari): Unfortunately it seems that comment:1 causes segfaults on Darwin; reverting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 8 23:25:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Aug 2018 23:25:29 -0000 Subject: [GHC] #9334: Implement "instance chains" In-Reply-To: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> References: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> Message-ID: <062.61e2887548b45d557ba0cbb27d573fce@haskell.org> #9334: Implement "instance chains" -------------------------------------+------------------------------------- Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 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: | -------------------------------------+------------------------------------- Changes (by redneb): * cc: redneb (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 00:19:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 00:19:56 -0000 Subject: [GHC] #15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0 In-Reply-To: <043.32eb5b85b23ae8693c74c6f6abd5a883@haskell.org> References: <043.32eb5b85b23ae8693c74c6f6abd5a883@haskell.org> Message-ID: <058.7fe9ada7d363ebf3c3881574859ffdcf@haskell.org> #15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0 -------------------------------------+------------------------------------- Reporter: noah | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | accelerate,memory,compile Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: accelerate performance bug | 1.2.0 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tmcdonell): * cc: tmcdonell (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 00:53:50 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 00:53:50 -0000 Subject: [GHC] #15493: Elide empty dictionaries Message-ID: <046.11d72f5ab1e49faf4e242eab224c7a9c@haskell.org> #15493: Elide empty dictionaries -------------------------------------+------------------------------------- Reporter: mnoonan | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Suppose you define a type class `C` with no methods, and use it as a constraint on a function `f :: C => Foo`. GHC's generated Core for `f` currently passes an empty dictionary for `C`. With optimizations, it seems to be true that at use sites, calls to `f` will be replaced with calls to an inner function that skips the typeclass dictionary. But can I count on this optimization always working? Would it possible to get a guarantee that the `C =>` constraint will have no run-time overhead, by dropping it entirely from the generated Core? Or is there a subtlety that prevents this from being sound? For context, I would like to implicitly pass compile-time evidence that various properties hold (e.g. such-and-such a list is non-empty), while retaining a guarantee that the evidence will have no run-time cost. Like this: {{{ newtype Named a name = Named a class Fact p -- Ideally, we'd have a guarantee that the following function -- compiles to exactly the same code as `Prelude.head` head :: Fact (IsCons xs) => (a `Named` xs) -> a head xs = Prelude.head (coerce xs) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 01:52:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 01:52:28 -0000 Subject: [GHC] #15493: Elide empty dictionaries In-Reply-To: <046.11d72f5ab1e49faf4e242eab224c7a9c@haskell.org> References: <046.11d72f5ab1e49faf4e242eab224c7a9c@haskell.org> Message-ID: <061.15dd696e88a9d8fbac603d3fcd4de535@haskell.org> #15493: Elide empty dictionaries -------------------------------------+------------------------------------- Reporter: mnoonan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by mnoonan: Old description: > Suppose you define a type class `C` with no methods, and use it as a > constraint on a function `f :: C => Foo`. GHC's generated Core for `f` > currently passes an empty dictionary for `C`. With optimizations, it > seems to be true that at use sites, calls to `f` will be replaced with > calls to an inner function that skips the typeclass dictionary. But can I > count on this optimization always working? > > Would it possible to get a guarantee that the `C =>` constraint will have > no run-time overhead, by dropping it entirely from the generated Core? Or > is there a subtlety that prevents this from being sound? > > For context, I would like to implicitly pass compile-time evidence that > various properties hold (e.g. such-and-such a list is non-empty), while > retaining a guarantee that the evidence will have no run-time cost. Like > this: > > {{{ > newtype Named a name = Named a > > class Fact p > > -- Ideally, we'd have a guarantee that the following function > -- compiles to exactly the same code as `Prelude.head` > head :: Fact (IsCons xs) => (a `Named` xs) -> a > head xs = Prelude.head (coerce xs) > }}} New description: Suppose you define a type class `C` with no methods, and use it as a constraint on a function `f :: C => Foo`. GHC's generated Core for `f` currently passes an empty dictionary for `C`. With optimizations, it seems to be true that at use sites, calls to `f` will be replaced with calls to an inner function that skips the typeclass dictionary. But can I count on this optimization always working? Would it possible to get a guarantee that the `C =>` constraint will have no run-time overhead, by dropping it entirely from the generated Core? Or is there a subtlety that prevents this from being sound? For context, I would like to implicitly pass compile-time evidence that various properties hold (e.g. such-and-such a list is non-empty), while retaining a guarantee that the evidence will have no run-time cost. Like this: {{{ newtype Named a name = Named a class Fact p -- Ideally, we'd have a guarantee that the following function -- compiles to exactly the same code as `Prelude.head` head :: Fact (IsCons xs) => ([a] `Named` xs) -> a head xs = Prelude.head (coerce xs) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 02:32:09 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 02:32:09 -0000 Subject: [GHC] #15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0 In-Reply-To: <043.32eb5b85b23ae8693c74c6f6abd5a883@haskell.org> References: <043.32eb5b85b23ae8693c74c6f6abd5a883@haskell.org> Message-ID: <058.520104cb29252fbab4ff682646bea227@haskell.org> #15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0 -------------------------------------+------------------------------------- Reporter: noah | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | accelerate,memory,compile Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: accelerate performance bug | 1.2.0 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by noah): Okay, I've tried that and now it seems to be able to compile accelerate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 07:38:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 07:38:52 -0000 Subject: [GHC] #15482: the_gc_thread variable from GC.c is not aligned to 64 In-Reply-To: <045.517cd029a074e1225f6142d10f834f62@haskell.org> References: <045.517cd029a074e1225f6142d10f834f62@haskell.org> Message-ID: <060.dd2ef83faf17ad52a55189692d26082f@haskell.org> #15482: the_gc_thread variable from GC.c is not aligned to 64 -------------------------------------+------------------------------------- Reporter: arrowd | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | 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 arrowd): Conrad Meyer, the FreeBSD guy that initially come with this suggestion also says that this fix is incorrect. Quoting him: Their change c6cc93bca only aligns the array to W_ aka StgWord aka StgWord64 aka unsigned long (8 bytes). This is insufficient for AVX2 alignment[1] (16 bytes for xmm, 32 for ymm) and still violates the guarantee attached to the gen_workspace structure (64 byte alignment). They need to remove the 64-byte gen_workspace alignment or add 64-byte alignment to the array to remove their UB. (They could align both to the smaller 32 bytes and still allow the compiler to take advantage of AVX2.) I don't know what lead them to believe an 8-byte alignment would fix an unaligned 32-byte AVX access. [1]: https://www.felixcloutier.com/x86/MOVAPS.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 09:28:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 09:28:01 -0000 Subject: [GHC] #15494: Cannot install GHC through stack on NixOS Message-ID: <047.5002e288e4122b8fa8aa01e403aa8f68@haskell.org> #15494: Cannot install GHC through stack on NixOS -------------------------------------+------------------------------------- Reporter: Stefanov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: install | Operating System: Linux fail,NixOS,Linux | Type of failure: Installing GHC Architecture: arm | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- stack setup gives me this error: Error: Error encountered while installing GHC with make install run in /home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3.temp/ghc-8.4.3/ Possibly a domain-specific problem,caused by NixOS's file-system. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 09:29:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 09:29:00 -0000 Subject: [GHC] #15494: Cannot install GHC through stack on NixOS In-Reply-To: <047.5002e288e4122b8fa8aa01e403aa8f68@haskell.org> References: <047.5002e288e4122b8fa8aa01e403aa8f68@haskell.org> Message-ID: <062.b8404995c89db7fafb90e2f1c262c71a@haskell.org> #15494: Cannot install GHC through stack on NixOS -------------------------------------+------------------------------------- Reporter: Stefanov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: install | fail,NixOS,Linux Operating System: Linux | Architecture: arm Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Stefanov: Old description: > stack setup gives me this error: > > Error: Error encountered while installing GHC with > make install > run in > /home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3.temp/ghc-8.4.3/ > > Possibly a domain-specific problem,caused by NixOS's file-system. New description: stack setup gives me this error: Error: Error encountered while installing GHC with make install run in /home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3.temp/ghc-8.4.3/ Possibly a domain-specific problem,caused by NixOS's file management. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 09:30:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 09:30:19 -0000 Subject: [GHC] #15494: Cannot install GHC through stack on NixOS In-Reply-To: <047.5002e288e4122b8fa8aa01e403aa8f68@haskell.org> References: <047.5002e288e4122b8fa8aa01e403aa8f68@haskell.org> Message-ID: <062.a7879aae738a64c1060e255c2b82e9d1@haskell.org> #15494: Cannot install GHC through stack on NixOS -------------------------------------+------------------------------------- Reporter: Stefanov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: install | fail,NixOS,Linux Operating System: Linux | Architecture: arm Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Stefanov: Old description: > stack setup gives me this error: > > Error: Error encountered while installing GHC with > make install > run in > /home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3.temp/ghc-8.4.3/ > > Possibly a domain-specific problem,caused by NixOS's file management. New description: stack setup gives me this error: # The .dll case calls STRIP_CMD explicitly, instead of `install -s`, because # on Win64, "install -s" calls a strip that doesn't understand 64bit binaries. # For some reason, this means the DLLs end up non-executable, which means # executables that use them just segfault. Error: Error encountered while installing GHC with make install run in /home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3.temp/ghc-8.4.3/ Possibly a domain-specific problem,caused by NixOS's file management. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 09:30:45 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 09:30:45 -0000 Subject: [GHC] #15494: Cannot install GHC through stack on NixOS In-Reply-To: <047.5002e288e4122b8fa8aa01e403aa8f68@haskell.org> References: <047.5002e288e4122b8fa8aa01e403aa8f68@haskell.org> Message-ID: <062.6e7d773507a92a304b3f43d31ea5f33a@haskell.org> #15494: Cannot install GHC through stack on NixOS -------------------------------------+------------------------------------- Reporter: Stefanov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: install | fail,NixOS,Linux Operating System: Linux | Architecture: arm Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Stefanov: Old description: > stack setup gives me this error: > > # The .dll case calls STRIP_CMD explicitly, instead of `install -s`, > because > # on Win64, "install -s" calls a strip that doesn't understand 64bit > binaries. > # For some reason, this means the DLLs end up non-executable, which means > # executables that use them just segfault. > Error: Error encountered while installing GHC with > make install > run in > /home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3.temp/ghc-8.4.3/ > > Possibly a domain-specific problem,caused by NixOS's file management. New description: stack setup gives me this error: # The .dll case calls STRIP_CMD explicitly, instead of `install -s`, because # on Win64, "install -s" calls a strip that doesn't understand 64bit binaries. # For some reason, this means the DLLs end up non-executable, which means # executables that use them just segfault. Error: Error encountered while installing GHC with make install run in /home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3.temp/ghc-8.4.3/ Possibly a domain-specific problem,caused by NixOS's file management. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 10:08:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 10:08:59 -0000 Subject: [GHC] #15494: Cannot install GHC through stack on NixOS In-Reply-To: <047.5002e288e4122b8fa8aa01e403aa8f68@haskell.org> References: <047.5002e288e4122b8fa8aa01e403aa8f68@haskell.org> Message-ID: <062.297e40d1581427c421e5042deda26765@haskell.org> #15494: Cannot install GHC through stack on NixOS -------------------------------------+------------------------------------- Reporter: Stefanov | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: install | fail,NixOS,Linux Operating System: Linux | Architecture: arm Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by osa1: Old description: > stack setup gives me this error: > > # The .dll case calls STRIP_CMD explicitly, instead of `install -s`, > because > # on Win64, "install -s" calls a strip that doesn't understand 64bit > binaries. > # For some reason, this means the DLLs end up non-executable, which means > # executables that use them just segfault. > > Error: Error encountered while installing GHC with > make install > run in > /home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3.temp/ghc-8.4.3/ > > Possibly a domain-specific problem,caused by NixOS's file management. New description: stack setup gives me this error: {{{ # The .dll case calls STRIP_CMD explicitly, instead of `install -s`, because # on Win64, "install -s" calls a strip that doesn't understand 64bit binaries. # For some reason, this means the DLLs end up non-executable, which means # executables that use them just segfault. Error: Error encountered while installing GHC with make install run in /home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3.temp/ghc-8.4.3/ }}} Possibly a domain-specific problem,caused by NixOS's file management. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 12:00:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 12:00:53 -0000 Subject: [GHC] #15495: Handling Source Locations via TTG Message-ID: <050.b9166c5b755fb618e3ff0003339d26df@haskell.org> #15495: Handling Source Locations via TTG -------------------------------------+------------------------------------- Reporter: Shayan-Najd | 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: -------------------------------------+------------------------------------- == Problem == The current implementation of [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGrowGuidance TTG HsSyn AST] in GHC stores source locations for terms of a datatype `Exp` in a separate wrapper datatype `LExp` which is mutually recursive with `Exp` such that every recursive reference to `Exp` is done **indirectly**, via a reference to the wrapper datatype `LExp` (see the example code below). We refer to this style of storing source locations as the ping-pong style. Besides the indirection and the resulting complications of the ping-pong style, there are two key problems with it: a. It bakes-in the source locations in the base TTG AST, forcing all instances to store source locations, even if they don't need them.For example, TH AST does not carry source locations, or even within GHC, there are generated terms without source locations. b. It results in a form of conceptual redundancy: source locations are tree decorations and they belong in the extension points. (see https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGrowGuidance TTG Guidance]) == Solution == We can move the source location decorations to a wrapper constructor and remove the ping-pong style. This can be done smoothly, mechanically, and gradually by using a getter/setter methods for source locations. More details can be found at [https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/HandlingSourceLocations the related wiki page]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 12:39:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 12:39:46 -0000 Subject: [GHC] #13600: surprising error message with bang pattern In-Reply-To: <051.cb1136f932f929f97ddeb5e4dd8a6304@haskell.org> References: <051.cb1136f932f929f97ddeb5e4dd8a6304@haskell.org> Message-ID: <066.c9c0d6d9cca99296b68e074e975c6e3a@haskell.org> #13600: surprising error message with bang pattern -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: v0d1ch Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: BangPatterns, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #15166, #15458 | Differential Rev(s): Phab:D5040 Wiki Page: | -------------------------------------+------------------------------------- Changes (by v0d1ch): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 12:54:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 12:54:18 -0000 Subject: [GHC] #9334: Implement "instance chains" In-Reply-To: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> References: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> Message-ID: <062.bf96e37ba45966ca315a4b21154c5657@haskell.org> #9334: Implement "instance chains" -------------------------------------+------------------------------------- Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 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: | -------------------------------------+------------------------------------- Changes (by sighingnow): * cc: sighingnow (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 13:17:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 13:17:39 -0000 Subject: [GHC] #15492: Plugin recompilation check fails when profiling is enabled In-Reply-To: <049.6cd45f735e6cc5104c701afb7f68bb71@haskell.org> References: <049.6cd45f735e6cc5104c701afb7f68bb71@haskell.org> Message-ID: <064.1b164312c9e5a158fe87b79f1ad16fb5@haskell.org> #15492: Plugin recompilation check fails when profiling is enabled -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5048 Wiki Page: | -------------------------------------+------------------------------------- Changes (by darchon): * status: new => patch * differential: => Phab:D5048 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 13:21:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 13:21:52 -0000 Subject: [GHC] #15482: the_gc_thread variable from GC.c is not aligned to 64 In-Reply-To: <045.517cd029a074e1225f6142d10f834f62@haskell.org> References: <045.517cd029a074e1225f6142d10f834f62@haskell.org> Message-ID: <060.a7c95dbad8f02268b8106b96f1f7e1d8@haskell.org> #15482: the_gc_thread variable from GC.c is not aligned to 64 -------------------------------------+------------------------------------- Reporter: arrowd | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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): Phab:D5052 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * differential: => Phab:D5052 * resolution: fixed => Comment: Ahh, I see the issue now. We explicitly claim that `gen_workspace` should be 64-byte aligned. I was previously under the mistaken impression that the problem was merely that `the_gc_thread`, a `StgWord8[]`, wasn't aligned to 8-bytes as `gc_thread` would require. I pushed a new fix as Phab:D5052 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 13:21:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 13:21:57 -0000 Subject: [GHC] #15482: the_gc_thread variable from GC.c is not aligned to 64 In-Reply-To: <045.517cd029a074e1225f6142d10f834f62@haskell.org> References: <045.517cd029a074e1225f6142d10f834f62@haskell.org> Message-ID: <060.f452f3846a19231b825b6a1cf963cc13@haskell.org> #15482: the_gc_thread variable from GC.c is not aligned to 64 -------------------------------------+------------------------------------- Reporter: arrowd | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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): Phab:D5052 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 14:11:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 14:11:57 -0000 Subject: [GHC] #15493: Elide empty dictionaries In-Reply-To: <046.11d72f5ab1e49faf4e242eab224c7a9c@haskell.org> References: <046.11d72f5ab1e49faf4e242eab224c7a9c@haskell.org> Message-ID: <061.b094b29e92aad940896c3457f6e2b16e@haskell.org> #15493: Elide empty dictionaries -------------------------------------+------------------------------------- Reporter: mnoonan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 14:14:50 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 14:14:50 -0000 Subject: [GHC] #14887: Explicitly quantifying a kind variable causes a telescope to fail to kind-check In-Reply-To: <050.26e9faa4d4a29b625c8bfcdef0d31364@haskell.org> References: <050.26e9faa4d4a29b625c8bfcdef0d31364@haskell.org> Message-ID: <065.3d8f9ea74125976ac75b2a04733914ca@haskell.org> #14887: Explicitly quantifying a kind variable causes a telescope to fail to kind- check -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've found another bizarre case where implicitly quantifying a kind variable works, but explicitly quantifying it does not. Consider the following program: {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} {-# OPTIONS_GHC -Wno-partial-type-signatures #-} module Bug where import Data.Proxy f :: forall (x :: a). Proxy (x :: _) f = Proxy }}} This typechecks, but if I change the type signature of `f` to explicitly quantify `a`: {{{#!hs f :: forall a (x :: a). Proxy (x :: _) }}} Then it no longer typechecks! Here is the error you get an a somewhat recent GHC HEAD build: {{{ GHCi, version 8.7.20180802: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:9:32: error: • Expected kind ‘a’, but ‘x’ has kind ‘a1’ • In the first argument of ‘Proxy’, namely ‘(x :: _)’ In the type ‘Proxy (x :: _)’ In the type signature: f :: forall a (x :: a). Proxy (x :: _) | 9 | f :: forall a (x :: a). Proxy (x :: _) | ^ }}} Do you think that this shares a symptom in common with the other programs mentioned in this ticket? (Or is this a separate bug?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 15:02:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 15:02:31 -0000 Subject: [GHC] #15493: Elide empty dictionaries In-Reply-To: <046.11d72f5ab1e49faf4e242eab224c7a9c@haskell.org> References: <046.11d72f5ab1e49faf4e242eab224c7a9c@haskell.org> Message-ID: <061.2bb72b37f73c4cab065f1a4e8f788b4e@haskell.org> #15493: Elide empty dictionaries -------------------------------------+------------------------------------- Reporter: mnoonan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): See discussion in [https://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1075&context=compsci_pubs goldfire's "Constrained Type Families"], subsection **7.3 Runtime Efficiency** > Constrained type families may also seem to have a non-trivial efficiency impact. For a simple example, suppose we have a type family `F`, and consider an existentially-packaged type family application: > > {{{#!hs > data FPack a where > FPack :: F a -> FPack a > }}} > > We might expect an `FPack a` value to contain exactly a value of type `F a`. With constrained type families, however, the declaration above would be incorrect; we would need to add a predicate for its constraining class, say `C`: > > {{{#!hs > data FPack1 a where > FPack1 :: C a => F a -> FPack1 a > }}} > > Now, a value of type `FPack1 a` does not just contain an `F a` value, but must also carry a `C a` dictionary, and uses of `FPack1` will be responsible for constructing, packing, and unpacking these dictionaries. Over sufficiently many uses of `FPack1`, this additional cost could be noticeable. > > This efficiency impact can be mitigated, however. This issue can crop up only when we have a value of type `F a` (or other type family application) without an instance of the associated class `C a`. But in order for the value of type `F a` to be useful, parametricity tells us that `C a`, or some other class with a similar structure to the equations for `F a` must be in scope. Barring this, it must be that `F a` is used as a phantom type. In this case, we would want a “phantom dictionary” for `C a`, closely paralleling existing work on proof irrelevance in the dependently- typed programming community (..): the `C a` dictionary essentially represents a proof that will never be examined. While we do not propose here a new solution to this problem, we believe that existing work will be applicable in our case as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 15:44:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 15:44:05 -0000 Subject: [GHC] #15261: Show -with-rtsopts options in runtime's --info In-Reply-To: <043.f2c7fda7e5ce90f13c2733f909af5e70@haskell.org> References: <043.f2c7fda7e5ce90f13c2733f909af5e70@haskell.org> Message-ID: <058.bbc7a94350c7449f9fd5baf0e9986bcd@haskell.org> #15261: Show -with-rtsopts options in runtime's --info -------------------------------------+------------------------------------- Reporter: osa1 | Owner: RolandSenn Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T15261a | T15261b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D5053 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * status: new => patch * testcase: => T15261a T15261b * differential: => Phab: D5053 Comment: Patch in [https://phabricator.haskell.org/D5053] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 15:54:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 15:54:53 -0000 Subject: [GHC] #15333: Weird cachegrind results for binary-trees In-Reply-To: <044.7a98f83472ccde2b3f7411c5c885bd25@haskell.org> References: <044.7a98f83472ccde2b3f7411c5c885bd25@haskell.org> Message-ID: <059.e06479da93af4dd1c139928ffd9955ae@haskell.org> #15333: Weird cachegrind results for binary-trees -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research Component: NoFib benchmark | needed suite | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): I'm still not really sure what's going on, but I feel like alignment instructions might skew cachegrinds instruction counts according to [http://valgrind.org/docs/manual/cg-manual.html section 5.2.10 of the valgrind manual]. I've had a few other cases in the meantime. Passing `-fllvm -optlo -Os` to use the LLVM backend optimising for code size helps. Is there some equivalent for the NCG? That would be far more reliable for the counted instruction metric that our benchmark CI relies on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 16:13:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 16:13:49 -0000 Subject: [GHC] #15496: if a variable that isn't in scope is used and main is not defined ghc freaks out Message-ID: <045.6049aaba6f9f66633738b009614d806d@haskell.org> #15496: if a variable that isn't in scope is used and main is not defined ghc freaks out ----------------------------------------+--------------------------------- Reporter: kuhnsB | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- --y = 5::Double f::Double ->Double f x = x+y --main = print 5 produces: ghc: panic! (the 'impossible' happened) (GHC version 8.0.2 for x86_64-unknown-linux): initTc: unsolved constraints WC {wc_insol = [W] y_axB :: t_axA[tau:1] (CHoleCan: y)} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug un-commenting either line 1 or 4 causes ghc to identify the other problem correctly -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 17:11:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 17:11:16 -0000 Subject: [GHC] #15496: if a variable that isn't in scope is used and main is not defined ghc freaks out In-Reply-To: <045.6049aaba6f9f66633738b009614d806d@haskell.org> References: <045.6049aaba6f9f66633738b009614d806d@haskell.org> Message-ID: <060.69951fca488d7205a76c15b3b96ac3a2@haskell.org> #15496: if a variable that isn't in scope is used and main is not defined ghc freaks out ---------------------------------+---------------------------------------- Reporter: kuhnsB | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: Thank you for the report. This bug has been fixed in GHC 8.2 (#12921). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 17:59:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 17:59:32 -0000 Subject: [GHC] #15497: Coercion Quantification Message-ID: <047.3a4a4e067b87a899efdf8c3f044fd1ac@haskell.org> #15497: Coercion Quantification -------------------------------------+------------------------------------- Reporter: ningning | 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: | https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase2 -------------------------------------+------------------------------------- As described in [https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase2]. We would like to have coercion quantifications back in Haskell Core language. This means in Core we can define types like {{{#!hs \/ (a: k1) . \/ (co : k1 ~ k2) -- an explicit quantification for the coercion -> (a |> co) -- use the name for an explicit cast -> ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 21:10:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 21:10:44 -0000 Subject: [GHC] #15498: HPC: do notation marks () as non-covered Message-ID: <046.edf2ae21fb84a5ac0a88ee9e0942fbe3@haskell.org> #15498: HPC: do notation marks () as non-covered -------------------------------------+------------------------------------- Reporter: tom-bop | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Code Coverage | Version: 8.2.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With this Main.hs, the "()" in "pure ()" is marked by HPC as a non-covered expression: {{{#!hs foo :: IO () foo = do _ <- putStrLn "Unimportant string" pure () main :: IO () main = do foo putStrLn "Unimportant #2" }}} Repro: - `ghc -fhpc Main.hs` - `./Main` - `hpc markup Main.tix` This is an admittedly small issue, but it can be valuable for a project to aspire to 100% code coverage and false negatives prevent us from getting there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 22:47:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 22:47:13 -0000 Subject: [GHC] #15499: Panic in occurence analysis phase (?), getRuntimeRep Message-ID: <048.4ced706f36b918299fae10c865c8eddf@haskell.org> #15499: Panic in occurence analysis phase (?), getRuntimeRep -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.4 Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- Compiling this: {{{#!hs {-# LANGUAGE DataKinds, GADTs, KindSignatures #-} module Holo () where data ADT (p :: Integer) where ADT :: { a :: a , b :: Integer } -> ADT p foo = undefined {b=undefined} }}} ..yields: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): getRuntimeRep p_a29z :: Integer Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1967:18 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -v4 suggests this happend during the occurence analysis phase (log attached). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 22:48:09 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 22:48:09 -0000 Subject: [GHC] #15499: Panic in occurence analysis phase (?), getRuntimeRep In-Reply-To: <048.4ced706f36b918299fae10c865c8eddf@haskell.org> References: <048.4ced706f36b918299fae10c865c8eddf@haskell.org> Message-ID: <063.0f967bac592c6b60ead7c8bf57bfd6d9@haskell.org> #15499: Panic in occurence analysis phase (?), getRuntimeRep -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.4 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by _deepfire): * Attachment "ghc-843-panic.log" added. ghc -c Holo.hs -v4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 22:55:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 22:55:48 -0000 Subject: [GHC] #15499: Panic in occurence analysis phase (?), getRuntimeRep In-Reply-To: <048.4ced706f36b918299fae10c865c8eddf@haskell.org> References: <048.4ced706f36b918299fae10c865c8eddf@haskell.org> Message-ID: <063.7f3306772fc256bd0a6a947472a5fae4@haskell.org> #15499: Panic in occurence analysis phase (?), getRuntimeRep -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.4 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by _deepfire): Potentially related are #14786 and #14175, due to also being `getRuntimeRep` panics (#14175 only had it for 8.3HEAD). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 23:07:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 23:07:55 -0000 Subject: [GHC] #15500: internal error: Unable to commit 1048576 bytes of memory. Deepseq Message-ID: <044.ed1ba65c9d5b6f387d34c884da0b6fe1@haskell.org> #15500: internal error: Unable to commit 1048576 bytes of memory. Deepseq --------------------------------------+---------------------------------- Reporter: alxdb | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: memory deepseq | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- the following code is a (nearly) minimal working example that causes the aforementioned internal error. {{{#!hs module Main where import Control.DeepSeq myfunc :: Int -> Int myfunc x = sum . take x $ [0..] logiter :: (NFData a) => Int -> (a -> a) -> a -> IO a logiter iter f x | iter >= 0 = do let y = f x deepseq y print $ "iter " ++ show iter if iter == 0 then return y else logiter (iter - 1) f y | otherwise = error "no negative iter!" main :: IO () main = do print "start" print . show $ myfunc 2000000 print "done" print "start" res <- logiter 5 myfunc 2000000 print "done" print . show $ res }}} Perhaps this is an issue with deepseq, however it the message does say to come and report the bug, so that's what I'm doing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 9 23:21:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Aug 2018 23:21:05 -0000 Subject: [GHC] #15500: internal error: Unable to commit 1048576 bytes of memory. Deepseq In-Reply-To: <044.ed1ba65c9d5b6f387d34c884da0b6fe1@haskell.org> References: <044.ed1ba65c9d5b6f387d34c884da0b6fe1@haskell.org> Message-ID: <059.94a4381ecf6ce7dd51b081c8ec6ec4be@haskell.org> #15500: internal error: Unable to commit 1048576 bytes of memory. Deepseq ----------------------------------+-------------------------------------- Reporter: alxdb | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: invalid | Keywords: memory deepseq Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by alxdb): * status: new => closed * resolution: => invalid Comment: I've just realised now, that this is likely due to the fact that I'm asking for the sum of several trillion numbers, recursion eh... I guess this is expected behaviour? perhaps the error message should be something a bit more informative, i.e. you've just run out of memory, rather than stating that this is an internal compiler error? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 10 03:07:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Aug 2018 03:07:15 -0000 Subject: [GHC] #15494: Cannot install GHC through stack on NixOS In-Reply-To: <047.5002e288e4122b8fa8aa01e403aa8f68@haskell.org> References: <047.5002e288e4122b8fa8aa01e403aa8f68@haskell.org> Message-ID: <062.c320f3d3dad64f6348eaddb960353928@haskell.org> #15494: Cannot install GHC through stack on NixOS -------------------------------------+------------------------------------- Reporter: Stefanov | Owner: (none) Type: bug | Status: upstream Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: install | fail,NixOS,Linux Operating System: Linux | Architecture: arm Type of failure: Installing GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => upstream Comment: Indeed I strongly suspect that this is due to NixOS's odd filesystem structure. Afterall, GHC has a few dependencies (`libc`, `gmp`, and perhaps the `iconv` executable) which NixOS places in rather odd places. You will likely need to bring this up with either the Stack or NixOS upstreams. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 10 03:08:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Aug 2018 03:08:54 -0000 Subject: [GHC] #15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0 In-Reply-To: <043.32eb5b85b23ae8693c74c6f6abd5a883@haskell.org> References: <043.32eb5b85b23ae8693c74c6f6abd5a883@haskell.org> Message-ID: <058.8376a27346d0d9dbd2db770215b0742c@haskell.org> #15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0 -------------------------------------+------------------------------------- Reporter: noah | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | accelerate,memory,compile Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: accelerate performance bug | 1.2.0 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed spending 40 seconds in the simplifier does sound bad. Can you attach the full output from compiling with `ghc -v3`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 10 06:49:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Aug 2018 06:49:44 -0000 Subject: [GHC] #15498: HPC: do notation marks () as non-covered In-Reply-To: <046.edf2ae21fb84a5ac0a88ee9e0942fbe3@haskell.org> References: <046.edf2ae21fb84a5ac0a88ee9e0942fbe3@haskell.org> Message-ID: <061.088d54703e8c3e3feabd9c975ecb124a@haskell.org> #15498: HPC: do notation marks () as non-covered -------------------------------------+------------------------------------- Reporter: tom-bop | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Code Coverage | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Do you mean `()` should've marked as evaluated because it's a CAF? Otherwise I think the coverage output is correct, `()` is never evaluated. Replace `()` with `undefined` and you'll see that program output does not change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 10 07:30:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Aug 2018 07:30:54 -0000 Subject: [GHC] #15333: Weird cachegrind results for binary-trees In-Reply-To: <044.7a98f83472ccde2b3f7411c5c885bd25@haskell.org> References: <044.7a98f83472ccde2b3f7411c5c885bd25@haskell.org> Message-ID: <059.eaa9477a455edc9bb498a945055451cf@haskell.org> #15333: Weird cachegrind results for binary-trees -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research Component: NoFib benchmark | needed suite | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by sgraf: Old description: > I'm currently investigating an alleged regression in my branch of the > late lambda lift and hit a confusing data point. Note that I'm very much > relying on cachegrinds counted instructions/memory accesses for my > findings. > > Check out the most recent version of `nofib` and run the following > script: > > {{{#!sh > #! /bin/sh > sed -i 's/import Debug.Trace//g' Main.hs # Make the following line > idempotent > echo "import Debug.Trace" | cat - Main.hs > Main.tmp && mv Main.tmp > Main.hs # add the import for trace > sed -i 's/trace "" \$ bit/bit/g' Main.hs # strip `trace $ ` prefixes in > the call to `bit` > ghc -O2 -XBangPatterns Main.hs -o bt1 > sed -i 's/bit/trace "" $ bit/g' Main.hs # prepend `trace $ ` to the call > to `bit` > ghc -O2 -XBangPatterns Main.hs -o bt2 > valgrind --tool=cachegrind ./bt1 12 2>&1 > /dev/null # without trace > valgrind --tool=cachegrind ./bt2 12 2>&1 > /dev/null # with trace > }}} > > This will compile two versions of `binary-trees`, one with an extra > `trace "" $` call before the only call to the `bit` function. One would > expect the version with the `trace` call (`bt1`) to allocate more than > the version without (`bt2`). Indeed, the output of `+RTS -s` suggests > that: > > {{{ > $ ./bt1 12 +RTS -s > ... > 43,107,560 bytes allocated in the heap > ... > $ ./bt2 12 +RTS -s > ... > 43,116,888 bytes allocated in the heap > ... > }}} > > That's fine. A few benchmark runs by hand also suggested the tracing > version is a little slower (probably due to IO). > > Compare that to the output of the above cachegrind calls: > > {{{ > $ valgrind --tool=cachegrind ./bt1 12 > /dev/null > ... > I refs: 118,697,583 > ... > D refs: 43,475,212 > ... > $ valgrind --tool=cachegrind ./bt2 12 > /dev/null > ... > I refs: 116,340,710 > ... > D refs: 42,523,369 > ... > }}} > > It's the other way round here! How's that possible? > > Even if this isn't strictly a bug in GHC or NoFib, it's relevant > nonetheless, as our benchmark infrastructure currently relies on > instruction counts. I couldn't reproduce this by writing my own no-op > `trace _ a = a; {-# NOINLINE trace #-}`, btw. > > I checked this on GHC 8.2.2 and a semi-recent HEAD commit > (bb539cfe335eeec7989332b859b1f3162c5e105a). New description: I'm currently investigating an alleged regression in my branch of the late lambda lift and hit a confusing data point. Note that I'm very much relying on cachegrinds counted instructions/memory accesses for my findings. Check out the most recent version of `nofib` and run the following script: {{{#!sh #! /bin/sh sed -i 's/import Debug.Trace//g' Main.hs # Make the following line idempotent echo "import Debug.Trace" | cat - Main.hs > Main.tmp && mv Main.tmp Main.hs # add the import for trace # bt1: Vanilly sed -i 's/trace "" \$ bit/bit/g' Main.hs # strip `trace $ ` prefixes in the call to `bit` ghc -O2 -XBangPatterns Main.hs -o bt1 # bt2: Additional trace call sed -i 's/bit/trace "" $ bit/g' Main.hs # prepend `trace $ ` to the call to `bit` ghc -O2 -XBangPatterns Main.hs -o bt2 valgrind --tool=cachegrind ./bt1 12 2>&1 > /dev/null # without trace valgrind --tool=cachegrind ./bt2 12 2>&1 > /dev/null # with trace }}} This will compile two versions of `binary-trees`, the original, unchanged version and one with an extra `trace "" $` call before the only call to the `bit` function. One would expect the version with the `trace` call (`bt2`) to allocate more than the version without (`bt1`). Indeed, the output of `+RTS -s` suggests that: {{{ $ ./bt1 12 +RTS -s ... 43,107,560 bytes allocated in the heap ... $ ./bt2 12 +RTS -s ... 43,116,888 bytes allocated in the heap ... }}} That's fine. A few benchmark runs by hand also suggested the tracing version is a little slower (probably due to IO). Compare that to the output of the above cachegrind calls: {{{ $ valgrind --tool=cachegrind ./bt1 12 > /dev/null ... I refs: 118,697,583 ... D refs: 43,475,212 ... $ valgrind --tool=cachegrind ./bt2 12 > /dev/null ... I refs: 116,340,710 ... D refs: 42,523,369 ... }}} It's the other way round here! How's that possible? Even if this isn't strictly a bug in GHC or NoFib, it's relevant nonetheless, as our benchmark infrastructure currently relies on instruction counts. I couldn't reproduce this by writing my own no-op `trace _ a = a; {-# NOINLINE trace #-}`, btw. I checked this on GHC 8.2.2, 8.4.3 and a semi-recent HEAD commit (bb539cfe335eeec7989332b859b1f3162c5e105a). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 10 07:33:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Aug 2018 07:33:48 -0000 Subject: [GHC] #15333: Weird cachegrind results for binary-trees In-Reply-To: <044.7a98f83472ccde2b3f7411c5c885bd25@haskell.org> References: <044.7a98f83472ccde2b3f7411c5c885bd25@haskell.org> Message-ID: <059.20545e9a3fa1338991d5a295039cc0f1@haskell.org> #15333: Weird cachegrind results for binary-trees -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research Component: NoFib benchmark | needed suite | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Passing `-fllvm -optlo -Os` doesn't seem to remedy the symptoms of the original bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 10 11:05:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Aug 2018 11:05:09 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.5bc4fadaeb42bdb385f1c9dbf66c8901@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): Phab:D3752, #12506, #13386 | Phab:D4766 Wiki Page: | -------------------------------------+------------------------------------- Comment (by danilo2): I'm just writing to tell that me and our team is waiting for this patch as well. We heavily use type families for our extensible records implementation (and other things) and our current build takes over an hour and consumes almost 30Gb of RAM. We have investigated it heavily and we are sure its related exactly to type families resolution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 10 11:52:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Aug 2018 11:52:43 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.51bc372f8b8781372800edb54d9452ed@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): Phab:D3752, #12506, #13386 | Phab:D4766 Wiki Page: | -------------------------------------+------------------------------------- Changes (by redv): * cc: danilo2 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 10 11:53:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Aug 2018 11:53:15 -0000 Subject: [GHC] #15501: Fix unknown symbols/addresses in perf output Message-ID: <045.068b84fc1146deb53c7717bbca530550@haskell.org> #15501: Fix unknown symbols/addresses in perf output -------------------------------------+------------------------------------- Reporter: last_g | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research needed Component: Compiler | Version: 8.5 (CodeGen) | Keywords: perf, | Operating System: Linux symbols, elf, linux | Architecture: | Type of failure: Debugging Unknown/Multiple | information is incorrect Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): D4713 | Wiki Page: -------------------------------------+------------------------------------- After https://phabricator.haskell.org/D4713 will be merged some addresses in perf output won't be mapped to the symbols. This needs investigation and fix. A draft idea about the root cause: The issue comes from the current perf symbolization algorithm. The basic logic is (kind of) simple: # Take all the @function symbols and put into a sorted list; # the next steps are a hack to support handwritten assembly # Take all the NOTYPE symbols with the size equals to 0 and put into the same ordered list; # Run the symbols__fixup_end procedure which sets a symbol end address to be the beginning of the next symbol for every 0 sized symbol; # If the last symbol is zero sized: set its size to be ~4k. (The actual logic is more complicated because it also involves sections&map groups) In GHC compiled binaries there are no @function symbols and most internal symbols are NOTYPE and 0 sized so we are ending up in the hack's code. This logic effectively means that every address in our code space is attributed to some internal symbol (correct or not). Adding @function symbols with size directive stops this from happening. As the first guess, those addresses can come from _con_info entries which we don't mark as @function but in that case, there should be no unknown addresses in D4730 but we have some there too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 10 14:02:21 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Aug 2018 14:02:21 -0000 Subject: [GHC] #15478: ghc-pkg package config validation too strict In-Reply-To: <044.130dca4572b68b7b6254840c20564a5f@haskell.org> References: <044.130dca4572b68b7b6254840c20564a5f@haskell.org> Message-ID: <059.eab1bc2c6781fe570d36ea0cf5a8c60a@haskell.org> #15478: ghc-pkg package config validation too strict -------------------------------------+------------------------------------- Reporter: mboes | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mboes): It turns out that because `base` is a "wired-in package", it's magical. GHC doesn't use versions to locate wired-in packages, because they are assumed unique. That's why the above example works. But in the general case, it won't. So I guess we should close this ticket - at any rate there's no issue with ghc-pkg, but perhaps we want to consider having GHC accepting just package names in the pkg db when they are unambiguous. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 10 14:29:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Aug 2018 14:29:53 -0000 Subject: [GHC] #15478: ghc-pkg package config validation too strict In-Reply-To: <044.130dca4572b68b7b6254840c20564a5f@haskell.org> References: <044.130dca4572b68b7b6254840c20564a5f@haskell.org> Message-ID: <059.80384541a634324237adb7b7950c56f6@haskell.org> #15478: ghc-pkg package config validation too strict -------------------------------------+------------------------------------- Reporter: mboes | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mboes): * status: new => closed * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 10 15:39:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Aug 2018 15:39:53 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.a017c9e2f7b6f370e94cd785dc84c761@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nfrisby Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 | Differential Rev(s): Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): I reimplemented this as an STG pass and just rebased it onto a recent 8.6 alpha commit. You can track the progress on my [https://github.com/sgraf812/ghc/tree/22ce14be00f73b63c24e584dda1ad5e1252e57bd `lift-lambda` branch, of which this is the current HEAD]. It passes `./validate`, but due to nofib's `lambda` benchmark not made fit for the next step of the MonadFail proposal, we can't run benchmarks. I ran some benchmarks before the rebase, which was relative to [https://github.com/ghc/ghc/tree/bb539cfe335e this commit]. Here are the numbers, eliding some uninteresting ones: {{{ -------------------------------------------------------------------------------- Program Allocs Instrs -------------------------------------------------------------------------------- VSD -0.3% +0.0% VSM 0.0% -0.1% atom -0.8% -1.2% binary-trees -0.0% -1.5% circsim -1.0% -0.6% clausify -1.9% -0.2% constraints -0.9% -0.7% cryptarithm1 -2.8% -8.0% cryptarithm2 -4.0% -2.9% exact-reals -2.1% -0.1% fft2 -1.0% -0.4% fluid -0.9% -0.6% hidden -1.0% -0.6% k-nucleotide -0.0% +2.4% lcss -0.1% -1.3% mate -3.2% -0.6% mkhprog -1.3% +1.0% power -0.7% -1.0% puzzle -0.0% +0.0% queens -17.7% -0.9% reptile -0.3% -17.1% rewrite -1.7% -0.1% typecheck -2.7% -1.9% -------------------------------------------------------------------------------- Min -17.7% -17.1% Max 0.0% +4.2% Geometric Mean -0.5% -0.3% }}} So, no regressions in allocation (which I'd consider a bug) and some small gains in general. Note that because of ticket:15333#comment:2 I'm not really trusting many of the regressions in counted instructions. I'd test with the proposed `-fllvm -optlo -Os` configuration, but that will have to wait until nofib is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 10 18:44:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Aug 2018 18:44:22 -0000 Subject: [GHC] #13296: stat() calls can block Haskell runtime In-Reply-To: <042.f957a412d3d44b27155966b76103fe42@haskell.org> References: <042.f957a412d3d44b27155966b76103fe42@haskell.org> Message-ID: <057.1c519e3b3a884ba41036bb974a71f5bb@haskell.org> #13296: stat() calls can block Haskell runtime -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by redneb): * cc: redneb (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 10 18:44:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Aug 2018 18:44:48 -0000 Subject: [GHC] #15153: GHC uses O_NONBLOCK on regular files, which has no effect, and blocks the runtime In-Reply-To: <042.2f3205a88421ca45196ab3bf4e5a61ff@haskell.org> References: <042.2f3205a88421ca45196ab3bf4e5a61ff@haskell.org> Message-ID: <057.38782e9b174abf03ab027f05cb532fd1@haskell.org> #15153: GHC uses O_NONBLOCK on regular files, which has no effect, and blocks the runtime -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | 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 Fri Aug 10 19:25:33 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Aug 2018 19:25:33 -0000 Subject: [GHC] #15502: -ddump-splices truncates Integer literals to Int literals Message-ID: <047.99c2e69e35ad36d7625dca8406cf953c@haskell.org> #15502: -ddump-splices truncates Integer literals to Int literals -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I trusted that the splice results shown by `-ddump-splices` were correct. They weren't, which caused me to waste a lot of time debugging my Template Haskell expressions when they were already correct. {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.3 }}} == Example program == {{{#!hs {-# OPTIONS_GHC -ddump-splices #-} {-# LANGUAGE TemplateHaskell #-} module Main where import Language.Haskell.TH.Syntax (Lift(lift)) main = print ( $( lift (toInteger (maxBound :: Int) + 1) ) , $( lift (minBound :: Int) ) ) }}} == Output of `runghc` == Note that the output of the program on the bottom line below is correct. The two splice results shown by `-ddump-splices` incorrectly match each other: {{{ Example.hs:8:19-56: Splicing expression lift (toInteger (maxBound :: Int) + 1) ======> -9223372036854775808 Example.hs:9:19-40: Splicing expression lift (minBound :: Int) ======> (-9223372036854775808) (9223372036854775808,-9223372036854775808) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 10 19:59:13 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Aug 2018 19:59:13 -0000 Subject: [GHC] #14294: IndexError: pop from empty list In-Reply-To: <048.d023a95248a740b652c7c9c06b669e05@haskell.org> References: <048.d023a95248a740b652c7c9c06b669e05@haskell.org> Message-ID: <063.64b2ab90f20174329ecad7b0aee421b9@haskell.org> #14294: IndexError: pop from empty list -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: Component: Trac & Git | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10927 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * component: Compiler => Trac & Git * related: => #10927 Comment: This is a duplicate of #10927. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 10 20:48:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Aug 2018 20:48:25 -0000 Subject: [GHC] #15503: interpreter: sequence_ (replicate 100000000 (return ())) gobbles up memory Message-ID: <044.e7b47664b0b4e75e999d3e8ddaf8b64f@haskell.org> #15503: interpreter: sequence_ (replicate 100000000 (return ())) gobbles up memory -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 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: -------------------------------------+------------------------------------- I consider this to be more of a curiosity than a bug, but it might still be worth investigating. The following line, {{{#!hs sequence_ (replicate 100000000 (return ())) }}} causes `ghci` to grow quite big (here it's 6GB on 64 bit Linux; it's roughly proportional to the `100000000` number). This used to be better in ancient times--before version 8.0.1, ghci ran this code in what looks like constant memory. (This came up indirectly on #haskell; somebody had adapted Hutton's game of life program, http://www.cs.nott.ac.uk/~gmh/life.lhs which uses busy waiting for a delay.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 10 20:55:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Aug 2018 20:55:28 -0000 Subject: [GHC] #15504: -XStrict doesn't prevent warnings from -Wunbanged-strict-patterns Message-ID: <047.80d1591e0d401bffffb0231b18ac57fb@haskell.org> #15504: -XStrict doesn't prevent warnings from -Wunbanged-strict-patterns -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm using: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.3 }}} I was under the impression that [https://ghc.haskell.org/trac/ghc/wiki/StrictPragma#Strict -XStrict] automatically included outermost bang patterns, but either that isn't always the case or [https://downloads.haskell.org/~ghc/master/users-guide /using-warnings.html#ghc-flag--Wunbanged-strict-patterns -Wunbanged- strict-patterns] doesn't know that `-XStrict` did its job correctly: {{{#!hs {-# OPTIONS_GHC -Wunbanged-strict-patterns #-} {-# LANGUAGE BangPatterns, MagicHash, Strict, UnboxedTuples #-} module Example where import GHC.Exts (Int(I#), quotRemInt#) lastDigit :: Int -> Int lastDigit (I# x) = let (# q, r #) = quotRemInt# x 10# in I# r }}} compiles with a warning: {{{ [1 of 1] Compiling Example ( Example.hs, Example.o ) Example.hs:9:24: warning: [-Wunbanged-strict-patterns] Pattern bindings containing unlifted types should use an outermost bang pattern: (# q, r #) = quotRemInt# x 10# | 9 | lastDigit (I# x) = let (# q, r #) = quotRemInt# x 10# | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 10 22:57:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Aug 2018 22:57:45 -0000 Subject: [GHC] #12146: syntax repair suggestion is too eager to suggest TemplateHaskell In-Reply-To: <049.ae34cc16e6637ea2bb94449efc0751c9@haskell.org> References: <049.ae34cc16e6637ea2bb94449efc0751c9@haskell.org> Message-ID: <064.6613a43bb274d26d5f678b3bd1b7759f@haskell.org> #12146: syntax repair suggestion is too eager to suggest TemplateHaskell -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #7396 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): @adityadivekar: I submitted a pull for your patches. https://github.com/ghc/ghc/pull/181. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 10 23:27:46 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Aug 2018 23:27:46 -0000 Subject: [GHC] #15499: Panic in occurence analysis phase (?), getRuntimeRep In-Reply-To: <048.4ced706f36b918299fae10c865c8eddf@haskell.org> References: <048.4ced706f36b918299fae10c865c8eddf@haskell.org> Message-ID: <063.bf1b3fbb7c3fc4e3a3a3e7a5d2d37299@haskell.org> #15499: Panic in occurence analysis phase (?), getRuntimeRep -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: RyanGlScott Type: bug | Status: new Priority: high | Milestone: 8.4.4 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: (none) => RyanGlScott * os: Linux => Unknown/Multiple Comment: Ugh, this is my fault. I introduced this regression in ef26182e2014b0a2a029ae466a4b121bf235e4e4 (`Track the order of user-written tyvars in DataCon`). The `-v4` logs are a bit misleading, as the real problem lies in desugaring, not occurrence analysis. Essentially, GHC tries to desugar this: {{{#!hs foo :: forall p. ADT p foo = undefined {b=undefined} }}} Into this: {{{#!hs foo :: forall p. ADT p foo @p = case undefined of ADT @a x y -> ADT @p @a x undefined }}} If the fact that I wrote `ADT @p @a` looks strange to you, that's because it is! The //real// type of the `ADT` constructor is: {{{#!hs ADT :: forall a p. a -> Integer -> ADT p }}} Due to the fact that type variables in GADT type signatures are now quantified in toposorted order after the aforementioned commit. This means that the correct order of arguments //should// be `ADT @a @p`. However, the code in `dsExpr` assumes that the universally quantified type variables always come before the existentially quantified type variables, so `@p` ends up being applied before `@a`, leading to utter disaster and chaos down the line. Thankfully, this isn't too difficult to fix. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 10 23:39:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Aug 2018 23:39:27 -0000 Subject: [GHC] #15499: Panic in occurence analysis phase (?), getRuntimeRep In-Reply-To: <048.4ced706f36b918299fae10c865c8eddf@haskell.org> References: <048.4ced706f36b918299fae10c865c8eddf@haskell.org> Message-ID: <063.4b00459db692456c8cdb71420faf0720@haskell.org> #15499: Panic in occurence analysis phase (?), getRuntimeRep -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: RyanGlScott Type: bug | Status: patch Priority: high | Milestone: 8.4.4 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5060 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5060 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 11 00:15:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Aug 2018 00:15:47 -0000 Subject: [GHC] #15499: Panic in occurence analysis phase (?), getRuntimeRep In-Reply-To: <048.4ced706f36b918299fae10c865c8eddf@haskell.org> References: <048.4ced706f36b918299fae10c865c8eddf@haskell.org> Message-ID: <063.1a5ce87988759c2ea80862ece9fc63fd@haskell.org> #15499: Panic in occurence analysis phase (?), getRuntimeRep -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: RyanGlScott Type: bug | Status: patch Priority: high | Milestone: 8.4.4 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5060 Wiki Page: | -------------------------------------+------------------------------------- Comment (by _deepfire): RyanGlScott, bgamari, do you think we can get this into 8.4.4? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 11 01:27:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Aug 2018 01:27:04 -0000 Subject: [GHC] #12065: there is a way to override the .tix path with HPCTIXFILE In-Reply-To: <045.acf890da63effd264c753e4e22e0c6f2@haskell.org> References: <045.acf890da63effd264c753e4e22e0c6f2@haskell.org> Message-ID: <060.55f4e3331956c3ac29acc6fab942b8a6@haskell.org> #12065: there is a way to override the .tix path with HPCTIXFILE -------------------------------------+------------------------------------- Reporter: kostmo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Code Coverage | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3357 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * resolution: => fixed Comment: In [changeset:"ee7241cfde455ab6731b9ce81b36247f082a1342/ghc"]: {{{ Author: Edward Z. Yang Date: Thu Mar 23 21:03:40 2017 -0400 Document hithertoo undocumented HPCTIXFILE option. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 11 01:58:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Aug 2018 01:58:36 -0000 Subject: [GHC] #11445: Turn on SplitSections by default In-Reply-To: <045.848c295688fc284737f19db2f979eda9@haskell.org> References: <045.848c295688fc284737f19db2f979eda9@haskell.org> Message-ID: <060.4ac30dca704d3bdc364d2f3c9a456f53@haskell.org> #11445: Turn on SplitSections by default -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.0.1-rc1 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:D1800 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: The build system now uses `-split-sections` to build GHC and the core libraries on supported platforms, see comment:21. See #12913 for remaining work to be done for Windows. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 11 02:35:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Aug 2018 02:35:13 -0000 Subject: [GHC] #15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0 In-Reply-To: <043.32eb5b85b23ae8693c74c6f6abd5a883@haskell.org> References: <043.32eb5b85b23ae8693c74c6f6abd5a883@haskell.org> Message-ID: <058.7e4fc129e01e524b8b2cbc6f3d468c3c@haskell.org> #15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0 -------------------------------------+------------------------------------- Reporter: noah | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | accelerate,memory,compile Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: accelerate performance bug | 1.2.0 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by noah): * Attachment "stdout.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 11 02:35:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Aug 2018 02:35:50 -0000 Subject: [GHC] #15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0 In-Reply-To: <043.32eb5b85b23ae8693c74c6f6abd5a883@haskell.org> References: <043.32eb5b85b23ae8693c74c6f6abd5a883@haskell.org> Message-ID: <058.ea62ec667700797a60c5b3eb0b6a9cd4@haskell.org> #15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0 -------------------------------------+------------------------------------- Reporter: noah | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | accelerate,memory,compile Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: accelerate performance bug | 1.2.0 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by noah): * Attachment "stderr.txt.gz" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 11 02:36:31 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Aug 2018 02:36:31 -0000 Subject: [GHC] #15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0 In-Reply-To: <043.32eb5b85b23ae8693c74c6f6abd5a883@haskell.org> References: <043.32eb5b85b23ae8693c74c6f6abd5a883@haskell.org> Message-ID: <058.5e72238c5e70b91def0c9232770a4084@haskell.org> #15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0 -------------------------------------+------------------------------------- Reporter: noah | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | accelerate,memory,compile Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Compile-time | Test Case: accelerate performance bug | 1.2.0 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by noah): Okay, Uploaded the files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 11 07:28:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Aug 2018 07:28:57 -0000 Subject: [GHC] #15499: Panic in occurence analysis phase (?), getRuntimeRep In-Reply-To: <048.4ced706f36b918299fae10c865c8eddf@haskell.org> References: <048.4ced706f36b918299fae10c865c8eddf@haskell.org> Message-ID: <063.4f502e1a373383f3abd9e48acd6ab09e@haskell.org> #15499: Panic in occurence analysis phase (?), getRuntimeRep -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: RyanGlScott Type: bug | Status: patch Priority: high | Milestone: 8.4.4 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5060 Wiki Page: | -------------------------------------+------------------------------------- Changes (by _deepfire): * cc: bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 11 08:27:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Aug 2018 08:27:28 -0000 Subject: [GHC] #9214: UNPACK support for sum types In-Reply-To: <047.5213ff1d75a2abd5ff04d6c7bb79813f@haskell.org> References: <047.5213ff1d75a2abd5ff04d6c7bb79813f@haskell.org> Message-ID: <062.38b714af53c9ebfb0da4c0b6794dce89@haskell.org> #9214: UNPACK support for sum types -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: osa1 Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1540 Wiki Page: UnpackedSumTypes | Phab:D1559 Phab:D2259 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: In [changeset:"714bebff44076061d0a719c4eda2cfd213b7ac3d"]: {{{ Author: Ömer Sinan Ağacan Date: Thu Jul 21 08:07:41 2016 +0000 Implement unboxed sum primitive type }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 11 10:37:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Aug 2018 10:37:43 -0000 Subject: [GHC] #15505: Assertion failure in test T7224 Message-ID: <043.407a087db52d6ea6eac57ab6fce42849@haskell.org> #15505: Assertion failure in test T7224 -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (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: -------------------------------------+------------------------------------- To reproduce, build GHC HEAD with slow validate settings, then run test `T7224`. Output: {{{ =====> T7224(normal) 9 of 15 [0, 2, 0] cd "polykinds/T7224.run" && "/home/omer/haskell/ghc/inplace/test spaces /ghc-stage2" -c T7224.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output Actual stderr output differs from expected: diff -uw "polykinds/T7224.run/T7224.stderr.normalised" "polykinds/T7224.run/T7224.comp.stderr.normalised" --- polykinds/T7224.run/T7224.stderr.normalised 2018-08-11 13:33:16.874459507 +0300 +++ polykinds/T7224.run/T7224.comp.stderr.normalised 2018-08-11 13:33:16.874459507 +0300 @@ -1,13 +1,11 @@ +ghc: panic! (the 'impossible' happened) + (GHC version 8.7.20180809 for x86_64-unknown-linux): + ASSERT failed! + Type-correct unfilled coercion hole {co_asw} + Call stack: + CallStack (from HasCallStack): + callStackDoc, called at compiler/utils/Outputable.hs:: in :Outputable + pprPanic, called at compiler/utils/Outputable.hs:: in :Outputable + assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:: in :TcHsSyn -T7224.hs:6:19: - Expected kind ‘i’, but ‘i’ has kind ‘*’ - In the first argument of ‘m’, namely ‘i’ - In the type signature: ret' :: a -> m i i a - In the class declaration for ‘PMonad'’ - -T7224.hs:7:14: - Expected kind ‘i’, but ‘i’ has kind ‘*’ - In the first argument of ‘m’, namely ‘i’ - In the type signature: - bind' :: m i j a -> (a -> m j k b) -> m i k b - In the class declaration for ‘PMonad'’ +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for T7224(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 11 10:38:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Aug 2018 10:38:57 -0000 Subject: [GHC] #15505: Assertion failures in tests T7224 and T9201 (was: Assertion failure in test T7224) In-Reply-To: <043.407a087db52d6ea6eac57ab6fce42849@haskell.org> References: <043.407a087db52d6ea6eac57ab6fce42849@haskell.org> Message-ID: <058.54fb5d012a8cd7ae0e2f55251734edae@haskell.org> #15505: Assertion failures in tests T7224 and T9201 -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 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: | -------------------------------------+------------------------------------- Description changed by osa1: Old description: > To reproduce, build GHC HEAD with slow validate settings, then run test > `T7224`. Output: > > {{{ > =====> T7224(normal) 9 of 15 [0, 2, 0] > cd "polykinds/T7224.run" && "/home/omer/haskell/ghc/inplace/test > spaces/ghc-stage2" -c T7224.hs -dcore-lint -dcmm-lint -no-user-package-db > -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output > Actual stderr output differs from expected: > diff -uw "polykinds/T7224.run/T7224.stderr.normalised" > "polykinds/T7224.run/T7224.comp.stderr.normalised" > --- polykinds/T7224.run/T7224.stderr.normalised 2018-08-11 > 13:33:16.874459507 +0300 > +++ polykinds/T7224.run/T7224.comp.stderr.normalised 2018-08-11 > 13:33:16.874459507 +0300 > @@ -1,13 +1,11 @@ > +ghc: panic! (the 'impossible' happened) > + (GHC version 8.7.20180809 for x86_64-unknown-linux): > + ASSERT failed! > + Type-correct unfilled coercion hole {co_asw} > + Call stack: > + CallStack (from HasCallStack): > + callStackDoc, called at > compiler/utils/Outputable.hs:: in :Outputable > + pprPanic, called at compiler/utils/Outputable.hs:: > in :Outputable > + assertPprPanic, called at > compiler/typecheck/TcHsSyn.hs:: in :TcHsSyn > > -T7224.hs:6:19: > - Expected kind ‘i’, but ‘i’ has kind ‘*’ > - In the first argument of ‘m’, namely ‘i’ > - In the type signature: ret' :: a -> m i i a > - In the class declaration for ‘PMonad'’ > - > -T7224.hs:7:14: > - Expected kind ‘i’, but ‘i’ has kind ‘*’ > - In the first argument of ‘m’, namely ‘i’ > - In the type signature: > - bind' :: m i j a -> (a -> m j k b) -> m i k b > - In the class declaration for ‘PMonad'’ > +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > *** unexpected failure for T7224(normal) > }}} New description: To reproduce, build GHC HEAD with slow validate settings, then run the tests. Outputs: {{{ =====> T7224(normal) 9 of 15 [0, 2, 0] cd "polykinds/T7224.run" && "/home/omer/haskell/ghc/inplace/test spaces /ghc-stage2" -c T7224.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output Actual stderr output differs from expected: diff -uw "polykinds/T7224.run/T7224.stderr.normalised" "polykinds/T7224.run/T7224.comp.stderr.normalised" --- polykinds/T7224.run/T7224.stderr.normalised 2018-08-11 13:33:16.874459507 +0300 +++ polykinds/T7224.run/T7224.comp.stderr.normalised 2018-08-11 13:33:16.874459507 +0300 @@ -1,13 +1,11 @@ +ghc: panic! (the 'impossible' happened) + (GHC version 8.7.20180809 for x86_64-unknown-linux): + ASSERT failed! + Type-correct unfilled coercion hole {co_asw} + Call stack: + CallStack (from HasCallStack): + callStackDoc, called at compiler/utils/Outputable.hs:: in :Outputable + pprPanic, called at compiler/utils/Outputable.hs:: in :Outputable + assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:: in :TcHsSyn -T7224.hs:6:19: - Expected kind ‘i’, but ‘i’ has kind ‘*’ - In the first argument of ‘m’, namely ‘i’ - In the type signature: ret' :: a -> m i i a - In the class declaration for ‘PMonad'’ - -T7224.hs:7:14: - Expected kind ‘i’, but ‘i’ has kind ‘*’ - In the first argument of ‘m’, namely ‘i’ - In the type signature: - bind' :: m i j a -> (a -> m j k b) -> m i k b - In the class declaration for ‘PMonad'’ +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for T7224(normal) =====> T9201(normal) 11 of 15 [0, 3, 0] cd "typecheck/should_fail/T9201.run" && "/home/omer/haskell/ghc/inplace/test spaces/ghc-stage2" -c T9201.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -dno-debug-output Actual stderr output differs from expected: diff -uw "typecheck/should_fail/T9201.run/T9201.stderr.normalised" "typecheck/should_fail/T9201.run/T9201.comp.stderr.normalised" --- typecheck/should_fail/T9201.run/T9201.stderr.normalised 2018-08-11 13:33:21.058404868 +0300 +++ typecheck/should_fail/T9201.run/T9201.comp.stderr.normalised 2018-08-11 13:33:21.058404868 +0300 @@ -1,7 +1,11 @@ +ghc: panic! (the 'impossible' happened) + (GHC version 8.7.20180809 for x86_64-unknown-linux): + ASSERT failed! + Type-correct unfilled coercion hole {co_asr} + Call stack: + CallStack (from HasCallStack): + callStackDoc, called at compiler/utils/Outputable.hs:: in :Outputable + pprPanic, called at compiler/utils/Outputable.hs:: in :Outputable + assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:: in :TcHsSyn -T9201.hs:6:17: - Expected kind ‘x’, but ‘a’ has kind ‘y’ - In the first argument of ‘f’, namely ‘a’ - In the second argument of ‘d’, namely ‘(f a)’ - In the type signature: - ret :: d a (f a) +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for T9201(normal) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 11 10:39:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Aug 2018 10:39:48 -0000 Subject: [GHC] #15505: Assertion failures in tests T7224, T9201, LevPolyBounded (was: Assertion failures in tests T7224 and T9201) In-Reply-To: <043.407a087db52d6ea6eac57ab6fce42849@haskell.org> References: <043.407a087db52d6ea6eac57ab6fce42849@haskell.org> Message-ID: <058.6d8834c526fe21a201f25059c9ec1fb0@haskell.org> #15505: Assertion failures in tests T7224, T9201, LevPolyBounded -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 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: | -------------------------------------+------------------------------------- Description changed by osa1: Old description: > To reproduce, build GHC HEAD with slow validate settings, then run the > tests. Outputs: > > {{{ > =====> T7224(normal) 9 of 15 [0, 2, 0] > cd "polykinds/T7224.run" && "/home/omer/haskell/ghc/inplace/test > spaces/ghc-stage2" -c T7224.hs -dcore-lint -dcmm-lint -no-user-package-db > -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups > -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output > Actual stderr output differs from expected: > diff -uw "polykinds/T7224.run/T7224.stderr.normalised" > "polykinds/T7224.run/T7224.comp.stderr.normalised" > --- polykinds/T7224.run/T7224.stderr.normalised 2018-08-11 > 13:33:16.874459507 +0300 > +++ polykinds/T7224.run/T7224.comp.stderr.normalised 2018-08-11 > 13:33:16.874459507 +0300 > @@ -1,13 +1,11 @@ > +ghc: panic! (the 'impossible' happened) > + (GHC version 8.7.20180809 for x86_64-unknown-linux): > + ASSERT failed! > + Type-correct unfilled coercion hole {co_asw} > + Call stack: > + CallStack (from HasCallStack): > + callStackDoc, called at > compiler/utils/Outputable.hs:: in :Outputable > + pprPanic, called at compiler/utils/Outputable.hs:: > in :Outputable > + assertPprPanic, called at > compiler/typecheck/TcHsSyn.hs:: in :TcHsSyn > > -T7224.hs:6:19: > - Expected kind ‘i’, but ‘i’ has kind ‘*’ > - In the first argument of ‘m’, namely ‘i’ > - In the type signature: ret' :: a -> m i i a > - In the class declaration for ‘PMonad'’ > - > -T7224.hs:7:14: > - Expected kind ‘i’, but ‘i’ has kind ‘*’ > - In the first argument of ‘m’, namely ‘i’ > - In the type signature: > - bind' :: m i j a -> (a -> m j k b) -> m i k b > - In the class declaration for ‘PMonad'’ > +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > *** unexpected failure for T7224(normal) > > =====> T9201(normal) 11 of 15 [0, 3, 0] > cd "typecheck/should_fail/T9201.run" && > "/home/omer/haskell/ghc/inplace/test spaces/ghc-stage2" -c T9201.hs > -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- > specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- > diagnostics-show-caret -dno-debug-output > Actual stderr output differs from expected: > diff -uw "typecheck/should_fail/T9201.run/T9201.stderr.normalised" > "typecheck/should_fail/T9201.run/T9201.comp.stderr.normalised" > --- typecheck/should_fail/T9201.run/T9201.stderr.normalised > 2018-08-11 13:33:21.058404868 +0300 > +++ typecheck/should_fail/T9201.run/T9201.comp.stderr.normalised > 2018-08-11 13:33:21.058404868 +0300 > @@ -1,7 +1,11 @@ > +ghc: panic! (the 'impossible' happened) > + (GHC version 8.7.20180809 for x86_64-unknown-linux): > + ASSERT failed! > + Type-correct unfilled coercion hole {co_asr} > + Call stack: > + CallStack (from HasCallStack): > + callStackDoc, called at > compiler/utils/Outputable.hs:: in :Outputable > + pprPanic, called at compiler/utils/Outputable.hs:: > in :Outputable > + assertPprPanic, called at > compiler/typecheck/TcHsSyn.hs:: in :TcHsSyn > > -T9201.hs:6:17: > - Expected kind ‘x’, but ‘a’ has kind ‘y’ > - In the first argument of ‘f’, namely ‘a’ > - In the second argument of ‘d’, namely ‘(f a)’ > - In the type signature: > - ret :: d a (f a) > +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > *** unexpected failure for T9201(normal) > }}} New description: To reproduce, build GHC HEAD with slow validate settings, then run the tests. Outputs: {{{ =====> T7224(normal) 9 of 15 [0, 2, 0] cd "polykinds/T7224.run" && "/home/omer/haskell/ghc/inplace/test spaces /ghc-stage2" -c T7224.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output Actual stderr output differs from expected: diff -uw "polykinds/T7224.run/T7224.stderr.normalised" "polykinds/T7224.run/T7224.comp.stderr.normalised" --- polykinds/T7224.run/T7224.stderr.normalised 2018-08-11 13:33:16.874459507 +0300 +++ polykinds/T7224.run/T7224.comp.stderr.normalised 2018-08-11 13:33:16.874459507 +0300 @@ -1,13 +1,11 @@ +ghc: panic! (the 'impossible' happened) + (GHC version 8.7.20180809 for x86_64-unknown-linux): + ASSERT failed! + Type-correct unfilled coercion hole {co_asw} + Call stack: + CallStack (from HasCallStack): + callStackDoc, called at compiler/utils/Outputable.hs:: in :Outputable + pprPanic, called at compiler/utils/Outputable.hs:: in :Outputable + assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:: in :TcHsSyn -T7224.hs:6:19: - Expected kind ‘i’, but ‘i’ has kind ‘*’ - In the first argument of ‘m’, namely ‘i’ - In the type signature: ret' :: a -> m i i a - In the class declaration for ‘PMonad'’ - -T7224.hs:7:14: - Expected kind ‘i’, but ‘i’ has kind ‘*’ - In the first argument of ‘m’, namely ‘i’ - In the type signature: - bind' :: m i j a -> (a -> m j k b) -> m i k b - In the class declaration for ‘PMonad'’ +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for T7224(normal) =====> T9201(normal) 11 of 15 [0, 3, 0] cd "typecheck/should_fail/T9201.run" && "/home/omer/haskell/ghc/inplace/test spaces/ghc-stage2" -c T9201.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed- specialisations -fshow-warning-groups -fdiagnostics-color=never -fno- diagnostics-show-caret -dno-debug-output Actual stderr output differs from expected: diff -uw "typecheck/should_fail/T9201.run/T9201.stderr.normalised" "typecheck/should_fail/T9201.run/T9201.comp.stderr.normalised" --- typecheck/should_fail/T9201.run/T9201.stderr.normalised 2018-08-11 13:33:21.058404868 +0300 +++ typecheck/should_fail/T9201.run/T9201.comp.stderr.normalised 2018-08-11 13:33:21.058404868 +0300 @@ -1,7 +1,11 @@ +ghc: panic! (the 'impossible' happened) + (GHC version 8.7.20180809 for x86_64-unknown-linux): + ASSERT failed! + Type-correct unfilled coercion hole {co_asr} + Call stack: + CallStack (from HasCallStack): + callStackDoc, called at compiler/utils/Outputable.hs:: in :Outputable + pprPanic, called at compiler/utils/Outputable.hs:: in :Outputable + assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:: in :TcHsSyn -T9201.hs:6:17: - Expected kind ‘x’, but ‘a’ has kind ‘y’ - In the first argument of ‘f’, namely ‘a’ - In the second argument of ‘d’, namely ‘(f a)’ - In the type signature: - ret :: d a (f a) +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for T9201(normal) =====> LevPolyBounded(normal) 12 of 15 [0, 4, 0] cd "typecheck/should_fail/LevPolyBounded.run" && "/home/omer/haskell/ghc/inplace/test spaces/ghc-stage2" -c LevPolyBounded.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics- color=never -fno-diagnostics-show-caret -dno-debug-output Actual stderr output differs from expected: diff -uw "typecheck/should_fail/LevPolyBounded.run/LevPolyBounded.stderr.normalised" "typecheck/should_fail/LevPolyBounded.run/LevPolyBounded.comp.stderr.normalised" --- typecheck/should_fail/LevPolyBounded.run/LevPolyBounded.stderr.normalised 2018-08-11 13:33:21.150403667 +0300 +++ typecheck/should_fail/LevPolyBounded.run/LevPolyBounded.comp.stderr.normalised 2018-08-11 13:33:21.150403667 +0300 @@ -1,5 +1,11 @@ +ghc: panic! (the 'impossible' happened) + (GHC version 8.7.20180809 for x86_64-unknown-linux): + ASSERT failed! + Type-correct unfilled coercion hole {co_avm} + Call stack: + CallStack (from HasCallStack): + callStackDoc, called at compiler/utils/Outputable.hs:: in :Outputable + pprPanic, called at compiler/utils/Outputable.hs:: in :Outputable + assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:: in :TcHsSyn -LevPolyBounded.hs:10:15: - Expected a type, but ‘a’ has kind ‘TYPE r’ - In the type signature: LevPolyBounded.minBound :: a - In the class declaration for ‘XBounded’ +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for LevPolyBounded(normal) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 11 11:07:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Aug 2018 11:07:29 -0000 Subject: [GHC] #14373: Introduce PTR-tagging for big constructor families In-Reply-To: <048.fd4e2364f8515bbd8b92613edf1e7763@haskell.org> References: <048.fd4e2364f8515bbd8b92613edf1e7763@haskell.org> Message-ID: <063.508df7a2366cb595a816867544372088@haskell.org> #14373: Introduce PTR-tagging for big constructor families -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4267 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 11 14:09:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Aug 2018 14:09:53 -0000 Subject: [GHC] #15213: 32 bit Haddock runs out of memory compiling 32 bit GHC In-Reply-To: <044.953b3633442fb5d6beadb7e79e6f44ca@haskell.org> References: <044.953b3633442fb5d6beadb7e79e6f44ca@haskell.org> Message-ID: <059.2d0efce001f745a16571fa50dd41a712@haskell.org> #15213: 32 bit Haddock runs out of memory compiling 32 bit GHC ----------------------------------------+------------------------------ Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by harpocrates): Could someone who can replicate this problem check that https://phabricator.haskell.org/D5003 and https://github.com/haskell/haddock/pull/893 together fix this issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 11 15:10:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Aug 2018 15:10:24 -0000 Subject: [GHC] #15499: Panic in occurence analysis phase (?), getRuntimeRep In-Reply-To: <048.4ced706f36b918299fae10c865c8eddf@haskell.org> References: <048.4ced706f36b918299fae10c865c8eddf@haskell.org> Message-ID: <063.4d483823379a36f25643bc7efce820f2@haskell.org> #15499: Panic in occurence analysis phase (?), getRuntimeRep -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: RyanGlScott Type: bug | Status: patch Priority: high | Milestone: 8.4.4 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5060 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): By the way, it's worth noting that working around this issue is very simple: just quantify the type variables in universals-then-existentials order. That is, do this: {{{#!hs data ADT (p :: Integer) where ADT :: forall p a. { a :: a , b :: Integer } -> ADT p }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 11 16:47:53 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Aug 2018 16:47:53 -0000 Subject: [GHC] #15357: Make nofib suitable for runtime measurements. In-Reply-To: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> References: <047.5832a3d42720fd14e156c0ef5919db7d@haskell.org> Message-ID: <062.2c573840a80562fc4ef9c1e1e689f41d@haskell.org> #15357: Make nofib suitable for runtime measurements. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: patch Priority: normal | Milestone: 8.8.1 Component: NoFib benchmark | Version: 8.4.3 suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5793 | Differential Rev(s): Phab:D4989 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * owner: (none) => AndreasK -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 11 16:51:38 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Aug 2018 16:51:38 -0000 Subject: [GHC] #15196: Invert floating point comparisons such that no extra parity check is required. In-Reply-To: <047.7b7b81a2e120787e43a042c6cb25c543@haskell.org> References: <047.7b7b81a2e120787e43a042c6cb25c543@haskell.org> Message-ID: <062.e4394c9c56b93319cf6e11c905ed8b35@haskell.org> #15196: Invert floating point comparisons such that no extra parity check is required. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (NCG) | Version: 8.4.3 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4990 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * owner: (none) => AndreasK -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 11 16:52:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Aug 2018 16:52:16 -0000 Subject: [GHC] #15196: Invert floating point comparisons such that no extra parity check is required. In-Reply-To: <047.7b7b81a2e120787e43a042c6cb25c543@haskell.org> References: <047.7b7b81a2e120787e43a042c6cb25c543@haskell.org> Message-ID: <062.453c305e47caa5d1550b3d24a04ba54d@haskell.org> #15196: Invert floating point comparisons such that no extra parity check is required. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler (NCG) | Version: 8.4.3 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4990 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * status: new => patch Comment: Ready for merge from my PoV -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 11 17:59:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Aug 2018 17:59:39 -0000 Subject: [GHC] #15506: CI setup should build and run nofib Message-ID: <046.24e3bc98425b81f840c863762b50ddb0@haskell.org> #15506: CI setup should build and run nofib -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | 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: -------------------------------------+------------------------------------- Every now and then, a commit breaks nofib; recently changeset:aab8656ba0561e56048a1222c396d2d117aca5a7. This should be avoidable if we compile and run `nofib` as part of the CI setup (and if CI would be usually green, but that’s a different story…) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 11 18:10:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Aug 2018 18:10:58 -0000 Subject: [GHC] #15506: CI setup should build and run nofib In-Reply-To: <046.24e3bc98425b81f840c863762b50ddb0@haskell.org> References: <046.24e3bc98425b81f840c863762b50ddb0@haskell.org> Message-ID: <061.c8fccdfb48dedef9a6c339719d488a38@haskell.org> #15506: CI setup should build and run nofib -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9572 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #9572 Comment: Duplicate of #9572? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 11 18:18:41 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Aug 2018 18:18:41 -0000 Subject: [GHC] #15475: Plugin recompilation check still panics In-Reply-To: <049.1dcd6c48f70db9da972b9cd8df87f1a4@haskell.org> References: <049.1dcd6c48f70db9da972b9cd8df87f1a4@haskell.org> Message-ID: <064.4b22564f45e167f3328a783bb1bac4dd@haskell.org> #15475: Plugin recompilation check still panics -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5048 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"b324c5624432f2c3d5b0a689fdff75a1ccc563f5/ghc" b324c562/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b324c5624432f2c3d5b0a689fdff75a1ccc563f5" Filter plugin dylib locations Summary: Previously we just created a cartesian product of the library paths of the plugin package and the libraries of the package. Of course, some of these combinations result in a filepath of a file doesn't exists, leading to #15475. Instead of making `haskFile` return Nothing in case a file doesn't exist (which would hide errors), we look at all the possible dylib locations and ensure that at least one of those locations is an existing file. If the list turns out to be empty however, we panic. Reviewers: mpickering, bgamari Reviewed By: mpickering Subscribers: monoidal, rwbarton, carter GHC Trac Issues: #15475 Differential Revision: https://phabricator.haskell.org/D5048 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 11 18:19:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Aug 2018 18:19:43 -0000 Subject: [GHC] #15475: Plugin recompilation check still panics In-Reply-To: <049.1dcd6c48f70db9da972b9cd8df87f1a4@haskell.org> References: <049.1dcd6c48f70db9da972b9cd8df87f1a4@haskell.org> Message-ID: <064.f5b41db516c3169e5ecebbe73c368ab6@haskell.org> #15475: Plugin recompilation check still panics -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5048 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 11 20:18:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Aug 2018 20:18:47 -0000 Subject: [GHC] #15507: Deriving with QuantifiedConstraints is unable to penetrate type families Message-ID: <048.e0096a2ee8cdea40b0de9dfd4e22728d@haskell.org> #15507: Deriving with QuantifiedConstraints is unable to penetrate type families -------------------------------------+------------------------------------- Reporter: isovector | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple QuantifiedConstraints | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'd expect the following code to successfully derive a usable `Eq` instance for `Foo`. {{{#!hs {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} module QuantifiedConstraints where import Data.Functor.Identity type family HKD f a where HKD Identity a = a HKD f a = f a data Foo f = Foo { zoo :: HKD f Int , zum :: HKD f Bool } deriving instance (forall a. Eq (HKD f a)) => Eq (Foo f) }}} However, it complains: {{{ • Could not deduce (Eq (HKD f a)) from the context: forall a. Eq (HKD f a) bound by an instance declaration: forall (f :: * -> *). (forall a. Eq (HKD f a)) => Eq (Foo f) at /home/sandy/prj/book-of- types/code/QuantifiedConstraints.hs:20:19-56 • In the ambiguity check for an instance declaration To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the stand-alone deriving instance for ‘(forall a. Eq (HKD f a)) => Eq (Foo f)’ }}} Adding -XAllowAmbiguousTypes doesn't fix the situation: {{{ • Could not deduce (Eq (HKD f a)) arising from a use of ‘GHC.Classes.$dm/=’ from the context: forall a. Eq (HKD f a) bound by the instance declaration at /home/sandy/prj/book-of- types/code/QuantifiedConstraints.hs:21:1-56 • In the expression: GHC.Classes.$dm/= @(Foo f) In an equation for ‘/=’: (/=) = GHC.Classes.$dm/= @(Foo f) When typechecking the code for ‘/=’ in a derived instance for ‘Eq (Foo f)’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘Eq (Foo f)’ }}} and the result of -ddump-deriv: {{{ ==================== Derived instances ==================== Derived class instances: instance (forall a. GHC.Classes.Eq (QuantifiedConstraints.HKD f a)) => GHC.Classes.Eq (QuantifiedConstraints.Foo f) where (GHC.Classes.==) (QuantifiedConstraints.Foo a1_a6MW a2_a6MX) (QuantifiedConstraints.Foo b1_a6MY b2_a6MZ) = (((a1_a6MW GHC.Classes.== b1_a6MY)) GHC.Classes.&& ((a2_a6MX GHC.Classes.== b2_a6MZ))) Derived type family instances: ==================== Filling in method body ==================== GHC.Classes.Eq [QuantifiedConstraints.Foo f_a6N0[ssk:1]] GHC.Classes./= = GHC.Classes.$dm/= @(QuantifiedConstraints.Foo f_a6N0[ssk:1]) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 11 20:31:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Aug 2018 20:31:32 -0000 Subject: [GHC] #15507: Deriving with QuantifiedConstraints is unable to penetrate type families In-Reply-To: <048.e0096a2ee8cdea40b0de9dfd4e22728d@haskell.org> References: <048.e0096a2ee8cdea40b0de9dfd4e22728d@haskell.org> Message-ID: <063.9799e3b7b6df414f41b55b9a20b28be5@haskell.org> #15507: Deriving with QuantifiedConstraints is unable to penetrate type families -------------------------------------+------------------------------------- Reporter: isovector | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 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: | -------------------------------------+------------------------------------- Description changed by isovector: Old description: > I'd expect the following code to successfully derive a usable `Eq` > instance for `Foo`. > > {{{#!hs > {-# LANGUAGE QuantifiedConstraints #-} > {-# LANGUAGE StandaloneDeriving #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE UndecidableInstances #-} > > module QuantifiedConstraints where > > import Data.Functor.Identity > > type family HKD f a where > HKD Identity a = a > HKD f a = f a > > data Foo f = Foo > { zoo :: HKD f Int > , zum :: HKD f Bool > } > > deriving instance (forall a. Eq (HKD f a)) => Eq (Foo f) > }}} > > However, it complains: > > {{{ > • Could not deduce (Eq (HKD f a)) > from the context: forall a. Eq (HKD f a) > bound by an instance declaration: > forall (f :: * -> *). (forall a. Eq (HKD f a)) => Eq > (Foo f) > at /home/sandy/prj/book-of- > types/code/QuantifiedConstraints.hs:20:19-56 > • In the ambiguity check for an instance declaration > To defer the ambiguity check to use sites, enable > AllowAmbiguousTypes > In the stand-alone deriving instance for > ‘(forall a. Eq (HKD f a)) => Eq (Foo f)’ > }}} > > Adding -XAllowAmbiguousTypes doesn't fix the situation: > > {{{ > • Could not deduce (Eq (HKD f a)) > arising from a use of ‘GHC.Classes.$dm/=’ > from the context: forall a. Eq (HKD f a) > bound by the instance declaration > at /home/sandy/prj/book-of- > types/code/QuantifiedConstraints.hs:21:1-56 > • In the expression: GHC.Classes.$dm/= @(Foo f) > In an equation for ‘/=’: (/=) = GHC.Classes.$dm/= @(Foo f) > When typechecking the code for ‘/=’ > in a derived instance for ‘Eq (Foo f)’: > To see the code I am typechecking, use -ddump-deriv > In the instance declaration for ‘Eq (Foo f)’ > }}} > > and the result of -ddump-deriv: > > {{{ > ==================== Derived instances ==================== > Derived class instances: > instance (forall a. > GHC.Classes.Eq (QuantifiedConstraints.HKD f a)) => > GHC.Classes.Eq (QuantifiedConstraints.Foo f) where > (GHC.Classes.==) > (QuantifiedConstraints.Foo a1_a6MW a2_a6MX) > (QuantifiedConstraints.Foo b1_a6MY b2_a6MZ) > = (((a1_a6MW GHC.Classes.== b1_a6MY)) > GHC.Classes.&& ((a2_a6MX GHC.Classes.== b2_a6MZ))) > > Derived type family instances: > > > ==================== Filling in method body ==================== > GHC.Classes.Eq [QuantifiedConstraints.Foo f_a6N0[ssk:1]] > GHC.Classes./= = GHC.Classes.$dm/= > @(QuantifiedConstraints.Foo f_a6N0[ssk:1]) > }}} New description: I'd expect the following code to successfully derive a usable `Eq` instance for `Foo`. {{{#!hs {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE UndecidableInstances #-} module QuantifiedConstraints where import Data.Functor.Identity type family HKD f a where HKD Identity a = a HKD f a = f a data Foo f = Foo { zoo :: HKD f Int , zum :: HKD f Bool } deriving instance (forall a. Eq a => Eq (HKD f a)) => Eq (Foo f) }}} However, it complains: {{{ • Could not deduce (Eq (HKD f a)) from the context: forall a. Eq a => Eq (HKD f a) bound by an instance declaration: forall (f :: * -> *). (forall a. Eq a => Eq (HKD f a)) => Eq (Foo f) at /home/sandy/prj/book-of- types/code/QuantifiedConstraints.hs:20:19-64 or from: Eq a bound by a quantified context at /home/sandy/prj/book-of- types/code/QuantifiedConstraints.hs:20:19-64 • In the ambiguity check for an instance declaration To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the stand-alone deriving instance for ‘(forall a. Eq a => Eq (HKD f a)) => Eq (Foo f)’ }}} Adding -XAllowAmbiguousTypes doesn't fix the situation: {{{ • Could not deduce (Eq (HKD f Int)) arising from a use of ‘==’ from the context: forall a. Eq a => Eq (HKD f a) bound by the instance declaration at /home/sandy/prj/book-of- types/code/QuantifiedConstraints.hs:21:1-64 • In the first argument of ‘(&&)’, namely ‘((a1 == b1))’ In the expression: (((a1 == b1)) && ((a2 == b2))) In an equation for ‘==’: (==) (Foo a1 a2) (Foo b1 b2) = (((a1 == b1)) && ((a2 == b2))) When typechecking the code for ‘==’ in a derived instance for ‘Eq (Foo f)’: To see the code I am typechecking, use -ddump-deriv | 21 | deriving instance (forall a. Eq a => Eq (HKD f a)) => Eq (Foo f) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ /home/sandy/prj/book-of-types/code/QuantifiedConstraints.hs:21:1: error: • Could not deduce (Eq (HKD f a)) arising from a use of ‘GHC.Classes.$dm/=’ from the context: forall a. Eq a => Eq (HKD f a) bound by the instance declaration at /home/sandy/prj/book-of- types/code/QuantifiedConstraints.hs:21:1-64 or from: Eq a bound by a quantified context at /home/sandy/prj/book-of-types/code/QuantifiedConstraints.hs:1:1 • In the expression: GHC.Classes.$dm/= @(Foo f) In an equation for ‘/=’: (/=) = GHC.Classes.$dm/= @(Foo f) When typechecking the code for ‘/=’ in a derived instance for ‘Eq (Foo f)’: To see the code I am typechecking, use -ddump-deriv In the instance declaration for ‘Eq (Foo f)’ | 21 | deriving instance (forall a. Eq a => Eq (HKD f a)) => Eq (Foo f) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} and the result of -ddump-deriv: {{{ ==================== Derived instances ==================== Derived class instances: instance (forall a. GHC.Classes.Eq a => GHC.Classes.Eq (QuantifiedConstraints.HKD f a)) => GHC.Classes.Eq (QuantifiedConstraints.Foo f) where (GHC.Classes.==) (QuantifiedConstraints.Foo a1_a74s a2_a74t) (QuantifiedConstraints.Foo b1_a74u b2_a74v) = (((a1_a74s GHC.Classes.== b1_a74u)) GHC.Classes.&& ((a2_a74t GHC.Classes.== b2_a74v))) Derived type family instances: ==================== Filling in method body ==================== GHC.Classes.Eq [QuantifiedConstraints.Foo f_a74w[ssk:1]] GHC.Classes./= = GHC.Classes.$dm/= @(QuantifiedConstraints.Foo f_a74w[ssk:1]) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 11 20:57:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Aug 2018 20:57:23 -0000 Subject: [GHC] #15426: `elemIndex` and `findIndex` still can't fuse In-Reply-To: <045.556cc5a15fe7d0c4bec73444eba7ef79@haskell.org> References: <045.556cc5a15fe7d0c4bec73444eba7ef79@haskell.org> Message-ID: <060.864238a9c85539f98c1f74317c9603bf@haskell.org> #15426: `elemIndex` and `findIndex` still can't fuse -------------------------------------+------------------------------------- Reporter: kabuhr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: libraries/base | 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 kabuhr): Okay, I'm working on a patch/test case, but I need some advice. The issue seems to be that because `findIndices` is marked `INLINE` instead of merely `INLINABLE`, the unfolding in the interface file for the function: {{{ #!haskell findIndex :: (a -> Bool) -> [a] -> Maybe Int findIndex p = listToMaybe . findIndices p }}} has already been turned into an unfusible version. I can fix this in one of two ways, either by marking `findIndex` as `INLINABLE` which puts a fusible version of `findIndex` (with `findIndices` already inlined) into the interface file **OR** by demoting `findIndices` from `INLINE` to merely `INLINABLE`. (It must be marked `INLINABLE` to keep a fusible version in the interface file; if it's unmarked, an unfusible unfolding is included instead.) I favor the second option, because it seems cleaner and also seems more likely to generate better code when `findIndices` is used directly in user code (i.e., because it will help avoid the same situation we currently have with `findIndex` and `elemIndex`). Is there any drawback to switching `findIndices` from `INLINE` to `INLINABLE`? In other words, what is the motivation in the first place for marking `findIndices` as `INLINE` instead of just `INLINABLE`. I've run the normal test suite (`make test`) before and after the change and didn't observe any performance regressions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 11 23:22:38 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Aug 2018 23:22:38 -0000 Subject: [GHC] #15499: Panic in occurence analysis phase (?), getRuntimeRep In-Reply-To: <048.4ced706f36b918299fae10c865c8eddf@haskell.org> References: <048.4ced706f36b918299fae10c865c8eddf@haskell.org> Message-ID: <063.f919f21250080e59260d3815488faa25@haskell.org> #15499: Panic in occurence analysis phase (?), getRuntimeRep -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: RyanGlScott Type: bug | Status: patch Priority: high | Milestone: 8.4.4 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5060 Wiki Page: | -------------------------------------+------------------------------------- Comment (by _deepfire): RyanGlScott, thank you for the workaround! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 12 00:51:51 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Aug 2018 00:51:51 -0000 Subject: [GHC] #13904: LLVM does not need to trash caller-saved registers. In-Reply-To: <044.9fbf455960cc2fbed77cfe6c815566aa@haskell.org> References: <044.9fbf455960cc2fbed77cfe6c815566aa@haskell.org> Message-ID: <059.63d153204264e651cd60aeb14a915eea@haskell.org> #13904: LLVM does not need to trash caller-saved registers. -------------------------------------+------------------------------------- Reporter: kavon | Owner: kavon Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #4992, #4308 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: Compile-time performance bug => Runtime performance bug Comment: See [wiki:Performance/Runtime] for all runtime performance tickets. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 12 00:56:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Aug 2018 00:56:10 -0000 Subject: [GHC] #15176: Superclass `Monad m =>` makes program run 100 times slower In-Reply-To: <046.1ae5a16457a25527a576b82200e29a09@haskell.org> References: <046.1ae5a16457a25527a576b82200e29a09@haskell.org> Message-ID: <061.391da05bb91df9308bbedf2f8b7e6d1c@haskell.org> #15176: Superclass `Monad m =>` makes program run 100 times slower -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: Compile-time performance bug => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 12 01:36:44 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Aug 2018 01:36:44 -0000 Subject: [GHC] #15426: `elemIndex` and `findIndex` still can't fuse In-Reply-To: <045.556cc5a15fe7d0c4bec73444eba7ef79@haskell.org> References: <045.556cc5a15fe7d0c4bec73444eba7ef79@haskell.org> Message-ID: <060.b8ba04160288606d8ce407a75cf5fe1f@haskell.org> #15426: `elemIndex` and `findIndex` still can't fuse -------------------------------------+------------------------------------- Reporter: kabuhr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: libraries/base | 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 kabuhr): After getting the side-by-side performance comparison stuff from wip/perf- testsuite running, I can confirm that changing `findIndices` from `INLINE` to `INLINABLE` causes no performance regressions in any of the performance tests. So, I'll try to put together a patch and submit to Phabricator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 12 02:27:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Aug 2018 02:27:36 -0000 Subject: [GHC] #15426: `elemIndex` and `findIndex` still can't fuse In-Reply-To: <045.556cc5a15fe7d0c4bec73444eba7ef79@haskell.org> References: <045.556cc5a15fe7d0c4bec73444eba7ef79@haskell.org> Message-ID: <060.9b998f24d6808e8f6f4bdb1d081e9b18@haskell.org> #15426: `elemIndex` and `findIndex` still can't fuse -------------------------------------+------------------------------------- Reporter: kabuhr | Owner: kabuhr Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: libraries/base | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/perf/should_run/T15426.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D5063 -------------------------------------+------------------------------------- Changes (by kabuhr): * owner: (none) => kabuhr * testcase: => testsuite/tests/perf/should_run/T15426.hs * differential: => https://phabricator.haskell.org/D5063 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 12 04:58:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Aug 2018 04:58:32 -0000 Subject: [GHC] #15426: `elemIndex` and `findIndex` still can't fuse In-Reply-To: <045.556cc5a15fe7d0c4bec73444eba7ef79@haskell.org> References: <045.556cc5a15fe7d0c4bec73444eba7ef79@haskell.org> Message-ID: <060.b7913a2f7d030a32c5059b78eff7ee10@haskell.org> #15426: `elemIndex` and `findIndex` still can't fuse -------------------------------------+------------------------------------- Reporter: kabuhr | Owner: kabuhr Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: libraries/base | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/perf/should_run/T15426.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D5063 -------------------------------------+------------------------------------- Comment (by kabuhr): I also ran the nofib benchmark suite with and without the change (switching `findIndices` from `INLINE` to `INLINABLE`). The change resulted in a slight increase (3%) to memory usage for the `cacheprof` benchmark with no change to elapsed time, and a large decrease (41%) to memory usage for the `maillist` benchmark. There were no other memory usage differences. There were variations in elapsed time across the benchmark suite in both directions over the range -5.6% to +4.4, but these appear to be spurious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 12 07:15:38 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Aug 2018 07:15:38 -0000 Subject: [GHC] #15508: concprog001 fails with various errors when compiled with -prof Message-ID: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> #15508: concprog001 fails with various errors when compiled with -prof -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D5051 | Wiki Page: -------------------------------------+------------------------------------- I'm observing a few different runtime errors. I'm not sure if they're because of different bugs so I'm filing one ticket for now. Reproduce with GHC HEAD: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -DS Mult: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 210 (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -DS }}} I tried to fix this in Phab:D5051 but it's causing a segfault in test `T11108` when run with profiling. Not sure what the problem is yet. It's very easy to trigger other kind of panics in `concprog001`, just try different compile and runtime flag combinations: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 zsh: segmentation fault (core dumped) ./Mult +RTS -N2 }}} Yet another way: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: invalid closure, info=0x947edc (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2 }}} It seems to work fine when not compiled for profiling so marking this bug as a profiler bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 12 07:22:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Aug 2018 07:22:39 -0000 Subject: [GHC] #15508: concprog001 fails with various errors when compiled with -prof In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.47c995a15666e3705370e5c37f762475@haskell.org> #15508: concprog001 fails with various errors when compiled with -prof -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5051 Wiki Page: | -------------------------------------+------------------------------------- Description changed by osa1: Old description: > I'm observing a few different runtime errors. I'm not sure if they're > because of different bugs so I'm filing one ticket for now. > > Reproduce with GHC HEAD: > > {{{ > prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce- > recomp -debug > [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) > [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) > [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) > [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) > [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) > [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) > [7 of 7] Compiling Main ( Mult.hs, Mult.o ) > Linking Mult ... > prog001 git:(master) $ ./Mult +RTS -DS > Mult: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 210 > > (GHC version 8.7.20180809 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > zsh: abort (core dumped) ./Mult +RTS -DS > }}} > > I tried to fix this in Phab:D5051 but it's causing a segfault in test > `T11108` when run with profiling. Not sure what the problem is yet. > > It's very easy to trigger other kind of panics in `concprog001`, just try > different compile and runtime flag combinations: > > {{{ > prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce- > recomp -threaded > [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) > [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) > [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) > [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) > [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) > [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) > [7 of 7] Compiling Main ( Mult.hs, Mult.o ) > Linking Mult ... > prog001 git:(master) $ ./Mult +RTS -N2 > zsh: segmentation fault (core dumped) ./Mult +RTS -N2 > }}} > > Yet another way: > > {{{ > prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce- > recomp -threaded -debug > [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) > [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) > [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) > [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) > [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) > [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) > [7 of 7] Compiling Main ( Mult.hs, Mult.o ) > Linking Mult ... > prog001 git:(master) $ ./Mult +RTS -N2 > Mult: internal error: invalid closure, info=0x947edc > (GHC version 8.7.20180809 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > zsh: abort (core dumped) ./Mult +RTS -N2 > }}} > > It seems to work fine when not compiled for profiling so marking this bug > as a profiler bug. New description: I'm observing a few different runtime errors. I'm not sure if they're because of different bugs so I'm filing one ticket for now. The reproduce with GHC HEAD: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: scavenge_one: strange object 624722688 (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2 }}} It's very easy to trigger other kind of panics in `concprog001`, just try different compile and runtime flag combinations. Note that for the examples below you'll need debug + profiling or debug + profiling + threaded runtimes, which are not built by default. To build those apply this patch: {{{ diff --git a/mk/config.mk.in b/mk/config.mk.in index 11050120d4..f083abad22 100644 --- a/mk/config.mk.in +++ b/mk/config.mk.in @@ -297,6 +297,7 @@ GhcRTSWays=l # Usually want the debug version GhcRTSWays += debug +GhcRTSWays += thr_debug_p debug_p # We always have the threaded versions, but note that SMP support may be disabled # (see GhcWithSMP). diff --git a/rts/ghc.mk b/rts/ghc.mk index 532c9aa175..ff3f18f30c 100644 --- a/rts/ghc.mk +++ b/rts/ghc.mk @@ -329,7 +329,6 @@ WARNING_OPTS += -Wstrict-prototypes WARNING_OPTS += -Wmissing-prototypes WARNING_OPTS += -Wmissing-declarations WARNING_OPTS += -Winline -WARNING_OPTS += -Waggregate-return WARNING_OPTS += -Wpointer-arith WARNING_OPTS += -Wmissing-noreturn WARNING_OPTS += -Wnested-externs }}} Examples: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -DS Mult: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 210 (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -DS }}} (I tried to fix this in Phab:D5051 but it's causing a segfault in test `T11108` when run with profiling. Not sure what the problem is yet.) Another way: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 zsh: segmentation fault (core dumped) ./Mult +RTS -N2 }}} Yet another way: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: invalid closure, info=0x947edc (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2 }}} It seems to work fine when not compiled for profiling so marking this bug as a profiler bug. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 12 08:30:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Aug 2018 08:30:56 -0000 Subject: [GHC] #9441: CSE should deal with letrec In-Reply-To: <045.987758d932a89023c69da6c12f8363f5@haskell.org> References: <045.987758d932a89023c69da6c12f8363f5@haskell.org> Message-ID: <060.0c714a4d889716201a8b2ab944088e91@haskell.org> #9441: CSE should deal with letrec -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: RolandSenn Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: CSE Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: T9441a, performance bug | T9441b, T9441c Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D5038 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"ec49b42bbff4ee81c825a0facee26b13f1f297a7/ghc" ec49b42b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ec49b42bbff4ee81c825a0facee26b13f1f297a7" CSE should deal with letrec Summary: Add testcase for #9441 Test Plan: make test TESTS="T9441a T9441b T9441c" Reviewers: dfeuer, simonpj, thomie, austin, bgamari Reviewed By: dfeuer Subscribers: rwbarton, carter GHC Trac Issues: #9441 Differential Revision: https://phabricator.haskell.org/D5038 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 12 08:33:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Aug 2018 08:33:18 -0000 Subject: [GHC] #9441: CSE should deal with letrec In-Reply-To: <045.987758d932a89023c69da6c12f8363f5@haskell.org> References: <045.987758d932a89023c69da6c12f8363f5@haskell.org> Message-ID: <060.26126baabe043729c2a8f2a15092ab82@haskell.org> #9441: CSE should deal with letrec -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: RolandSenn Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: CSE Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: T9441a, performance bug | T9441b, T9441c Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D5038 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 12 09:24:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Aug 2018 09:24:37 -0000 Subject: [GHC] #11477: Remove -Wamp In-Reply-To: <046.3dbac51dca4bf042073a762ce7d4fafd@haskell.org> References: <046.3dbac51dca4bf042073a762ce7d4fafd@haskell.org> Message-ID: <061.4037c37f3bbe4b88a0e28ab469d66938@haskell.org> #11477: Remove -Wamp -------------------------------------+------------------------------------- Reporter: bgamari | Owner: RolandSenn Type: task | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D4785 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed Comment: As far as I can tell this is done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 12 09:39:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Aug 2018 09:39:09 -0000 Subject: [GHC] #4879: Deprecate exports In-Reply-To: <049.ea1fa273b308c2a35269907288b50645@haskell.org> References: <049.ea1fa273b308c2a35269907288b50645@haskell.org> Message-ID: <064.d9164d31e0da1eaf968475b29339750c@haskell.org> #4879: Deprecate exports -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.0.1 Resolution: | Keywords: deprecate | warning Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10071 #2119 | Differential Rev(s): Phab:D638 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): [https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0028 -deprecating-exports-proposal.rst GHC proposal] accepted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 12 10:25:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Aug 2018 10:25:09 -0000 Subject: [GHC] #15269: Qualified Names in --show-iface output In-Reply-To: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> References: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> Message-ID: <061.231789e8a443d2439fb353f23755ffbf@haskell.org> #15269: Qualified Names in --show-iface output -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4852 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"d42eef344a71990d12f27e88cdf10ba0b2a2f34b/ghc" d42eef34/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d42eef344a71990d12f27e88cdf10ba0b2a2f34b" --show-iface: Qualify all non-local names Summary: In order to disambiguate names from different modules, qualify all names that don't originate in the current module. Also update docs for QueryQualifyName Test Plan: validate Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, thomie, carter, tdammers GHC Trac Issues: #15269 Differential Revision: https://phabricator.haskell.org/D4852 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 12 10:28:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Aug 2018 10:28:58 -0000 Subject: [GHC] #15269: Qualified Names in --show-iface output In-Reply-To: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> References: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> Message-ID: <061.33d6487b43a87fea4ec1433dcf2fc33b@haskell.org> #15269: Qualified Names in --show-iface output -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature request | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4852 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => merge Comment: I'm not sure if this is mergable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 12 11:12:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Aug 2018 11:12:57 -0000 Subject: [GHC] #15507: Deriving with QuantifiedConstraints is unable to penetrate type families In-Reply-To: <048.e0096a2ee8cdea40b0de9dfd4e22728d@haskell.org> References: <048.e0096a2ee8cdea40b0de9dfd4e22728d@haskell.org> Message-ID: <063.e77829324dc82289c6804ae4512c9ec9@haskell.org> #15507: Deriving with QuantifiedConstraints is unable to penetrate type families -------------------------------------+------------------------------------- Reporter: isovector | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: Resolution: duplicate | Keywords: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #14860 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #14860 Comment: Alas, this is expected behavior. See #14860. On GHC HEAD, you'll get a more informative error message, at least: {{{ GHCi, version 8.7.20180806: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling QuantifiedConstraints ( Bug.hs, interpreted ) Bug.hs:20:19: error: • Illegal type synonym family application in instance: HKD f a • In the quantified constraint ‘forall a. Eq a => Eq (HKD f a)’ In the stand-alone deriving instance for ‘(forall a. Eq a => Eq (HKD f a)) => Eq (Foo f)’ | 20 | deriving instance (forall a. Eq a => Eq (HKD f a)) => Eq (Foo f) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 12 11:44:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Aug 2018 11:44:21 -0000 Subject: [GHC] #15509: `showEFloat` inconsistency introduced in base-4.12 Message-ID: <042.b4d95dcfedcc55594395a53ebe2f16f7@haskell.org> #15509: `showEFloat` inconsistency introduced in base-4.12 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 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: -------------------------------------+------------------------------------- While base-4.11 had a `showEFloat` that behaved like {{{#!hs showEFloat (Just n) | n <= 0 == showEFloat (Just 1) }}} For non-positive values, base-4.12 introduced an unfortunate inconsistency: {{{#!hs showEFloat (Just n) | n < 0 == showEFloat (Just 1) -- NB: *not* equivalent to showEFloat (Just 0) }}} e.g. now we have {{{#!hs showEFloat (Just 2) 1.0 "" == "1.00e0" showEFloat (Just 1) 1.0 "" == "1.0e0" showEFloat (Just 0) 1.0 "" == "1e0" showEFloat (Just (-1)) 1.0 "" == "1.0e0" showEFloat (Just (-2)) 1.0 "" == "1.0e0" }}} iow, negative `n`s in the precision argument are now treated differently from `(Just 0)` which is a source of subtle bugs for API consumers which assume `showEFloat` to have "continuous total" semantics for the precision argument. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 12 11:45:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Aug 2018 11:45:52 -0000 Subject: [GHC] #15509: `showEFloat` inconsistency introduced in base-4.12 In-Reply-To: <042.b4d95dcfedcc55594395a53ebe2f16f7@haskell.org> References: <042.b4d95dcfedcc55594395a53ebe2f16f7@haskell.org> Message-ID: <057.008d9079cb175e151e358e91cbc18c8c@haskell.org> #15509: `showEFloat` inconsistency introduced in base-4.12 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * version: => 8.6.1-beta1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 12 11:50:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Aug 2018 11:50:42 -0000 Subject: [GHC] #15509: `showEFloat` inconsistency introduced in base-4.12 In-Reply-To: <042.b4d95dcfedcc55594395a53ebe2f16f7@haskell.org> References: <042.b4d95dcfedcc55594395a53ebe2f16f7@haskell.org> Message-ID: <057.e48a415541c048769fa80edb8f1423f9@haskell.org> #15509: `showEFloat` inconsistency introduced in base-4.12 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by hvr: Old description: > While base-4.11 had a `showEFloat` that behaved like > > {{{#!hs > showEFloat (Just n) | n <= 0 == showEFloat (Just 1) > }}} > > For non-positive values, base-4.12 introduced an unfortunate > inconsistency: > > {{{#!hs > showEFloat (Just n) | n < 0 == showEFloat (Just 1) > -- NB: *not* equivalent to showEFloat (Just 0) > }}} > > e.g. now we have > > {{{#!hs > showEFloat (Just 2) 1.0 "" == "1.00e0" > showEFloat (Just 1) 1.0 "" == "1.0e0" > showEFloat (Just 0) 1.0 "" == "1e0" > showEFloat (Just (-1)) 1.0 "" == "1.0e0" > showEFloat (Just (-2)) 1.0 "" == "1.0e0" > }}} > > iow, negative `n`s in the precision argument are now treated differently > from `(Just 0)` which is a source of subtle bugs for API consumers which > assume `showEFloat` to have "continuous total" semantics for the > precision argument. New description: While base-4.11 had a `showEFloat` that behaved like {{{#!hs showEFloat (Just n) | n <= 0 == showEFloat (Just 1) }}} For non-positive values, base-4.12 introduced an unfortunate inconsistency: {{{#!hs showEFloat (Just n) | n < 0 == showEFloat (Just 1) -- NB: *not* equivalent to showEFloat (Just 0) }}} e.g. now we have {{{#!hs showEFloat (Just 2) 1.0 "" == "1.00e0" showEFloat (Just 1) 1.0 "" == "1.0e0" showEFloat (Just 0) 1.0 "" == "1e0" showEFloat (Just (-1)) 1.0 "" == "1.0e0" showEFloat (Just (-2)) 1.0 "" == "1.0e0" }}} iow, negative `n`s in the precision argument are now treated differently from `(Just 0)` which is a source of subtle bugs for API consumers which assume `showEFloat` to have "continuous total" (or rather, saturated subtraction) semantics for the precision argument. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 12 15:14:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Aug 2018 15:14:45 -0000 Subject: [GHC] #15279: CPP #includes may result in nonsensical SrcSpans In-Reply-To: <045.4d706fecf4a6cf42667f6871be2d3572@haskell.org> References: <045.4d706fecf4a6cf42667f6871be2d3572@haskell.org> Message-ID: <060.9c93b81faa88b12f507be8c6e337f048@haskell.org> #15279: CPP #includes may result in nonsensical SrcSpans -------------------------------------+------------------------------------- Reporter: wz1000 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: cpp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #14113 | Differential Rev(s): Phab:D4866 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"f7f9820e8f5601e9a072e504f3d772fd78df6700/ghc" f7f9820/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f7f9820e8f5601e9a072e504f3d772fd78df6700" Check if files are same in combineSrcSpans Summary: If this is not checked, SrcSpans are sometimes mangled by CPP. Test Plan: ./validate Reviewers: bgamari, dfeuer Reviewed By: bgamari Subscribers: dfeuer, rwbarton, thomie, carter GHC Trac Issues: #15279 Differential Revision: https://phabricator.haskell.org/D4866 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 12 15:15:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Aug 2018 15:15:46 -0000 Subject: [GHC] #15279: CPP #includes may result in nonsensical SrcSpans In-Reply-To: <045.4d706fecf4a6cf42667f6871be2d3572@haskell.org> References: <045.4d706fecf4a6cf42667f6871be2d3572@haskell.org> Message-ID: <060.51b322d69383b65488bd7e0055ca033c@haskell.org> #15279: CPP #includes may result in nonsensical SrcSpans -------------------------------------+------------------------------------- Reporter: wz1000 | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: cpp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #14113 | Differential Rev(s): Phab:D4866 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 12 16:49:27 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Aug 2018 16:49:27 -0000 Subject: [GHC] #15361: Error message displays redundant equality constraint In-Reply-To: <050.41dbf0633f06cf78daba7d213be8b850@haskell.org> References: <050.41dbf0633f06cf78daba7d213be8b850@haskell.org> Message-ID: <065.9b1dacf5e8b57defe3811df66b01d4a9@haskell.org> #15361: Error message displays redundant equality constraint -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14394 | Differential Rev(s): Phab:D5002 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"c552feea127d8ed8cbf4994a157c4bbe254b96c3/ghc" c552feea/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c552feea127d8ed8cbf4994a157c4bbe254b96c3" Suppress redundant givens during error reporting Summary: When GHC reports that it cannot solve a constraint in error messages, it often reports what given constraints it has in scope. Unfortunately, sometimes redundant constraints (like `* ~ *`, from #15361) can sneak in. The fix is simple: blast away these redundant constraints using `mkMinimalBySCs`. Test Plan: make test TEST=T15361 Reviewers: simonpj, bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15361 Differential Revision: https://phabricator.haskell.org/D5002 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 12 16:51:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Aug 2018 16:51:28 -0000 Subject: [GHC] #15361: Error message displays redundant equality constraint In-Reply-To: <050.41dbf0633f06cf78daba7d213be8b850@haskell.org> References: <050.41dbf0633f06cf78daba7d213be8b850@haskell.org> Message-ID: <065.46745f051c80b6ebbfed912575762397@haskell.org> #15361: Error message displays redundant equality constraint -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14394 | Differential Rev(s): Phab:D5002 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 12 18:39:44 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Aug 2018 18:39:44 -0000 Subject: [GHC] #15510: Qualified Holes Message-ID: <049.e79fa23b6a2782343800cacfefeeaef8@haskell.org> #15510: Qualified Holes -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: low | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Let us consider the following example code: {{{ import qualified Data.Map as M main :: IO () main = print (M._ (\k v acc -> k + v + acc) 0 myMap) myMap :: Map Int Int myMap = ... }}} This errors with `Not in scope: M._`. It would cool if GHC instead treated `M._` as a hole but only gave suggestions from the module `Data.Map`. So, in this case, it would suggest things like `Data.Map.foldrWithKey` and `Data.Map.foldlWithKey`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 12 21:33:15 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Aug 2018 21:33:15 -0000 Subject: [GHC] #15213: 32 bit Haddock runs out of memory compiling 32 bit GHC In-Reply-To: <044.953b3633442fb5d6beadb7e79e6f44ca@haskell.org> References: <044.953b3633442fb5d6beadb7e79e6f44ca@haskell.org> Message-ID: <059.b747874eb773a1117b06b001df6f6786@haskell.org> #15213: 32 bit Haddock runs out of memory compiling 32 bit GHC ----------------------------------------+---------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5003 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by Phyx-): * status: new => patch * differential: => Phab:D5003 Comment: Those two seem to fix the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 13 00:50:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Aug 2018 00:50:33 -0000 Subject: [GHC] #15081: Finite list becomes infinite after maping fractional function for high numbers In-Reply-To: <044.f762bf620383822c5337aa8807210278@haskell.org> References: <044.f762bf620383822c5337aa8807210278@haskell.org> Message-ID: <059.15a9a144b9737c0db4a00ba9f9f82086@haskell.org> #15081: Finite list becomes infinite after maping fractional function for high numbers -------------------------------------+------------------------------------- Reporter: Onsed | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | libraries/base/tests/enumNumeric Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4650 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): It is still possible to get an infinite list with `enumFromThenTo` and `Double`: {{{ > [9007199254740992,9007199254740993..9007199254740994]::[Double] }}} Another funny result: {{{ > [9007199254740993..9007199254740991]::[Double] [9.007199254740992e15,9.007199254740992e15] }}} Notice that `from` is bigger than `to`, so one would expect an empty list as a result. Like svenpanne said in comment:5: > The underlying problem stays: You can write more precise Integers than Double can represent, and enumerating floating point numbers is inherently fragile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 13 03:01:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Aug 2018 03:01:09 -0000 Subject: [GHC] #15511: GHCi internal error with runQ [| it |] and _ Message-ID: <047.47e93921a344b32cb0a276a01f9b81f9@haskell.org> #15511: GHCi internal error with runQ [| it |] and _ -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHCi gives a GHC internal error with the following input: {{{ :set -XTemplateHaskell :m + Language.Haskell.TH.Syntax runQ [| it |] runQ [| it |] _ }}} Session: {{{ $ ghci GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> :set -XTemplateHaskell Prelude> :m + Language.Haskell.TH.Syntax Prelude Language.Haskell.TH.Syntax> runQ [| it |] UnboundVarE it Prelude Language.Haskell.TH.Syntax> runQ [| it |] VarE Ghci1.it Prelude Language.Haskell.TH.Syntax> _ :1:1: error: GHC internal error: ‘Ghci1.it’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [] Prelude Language.Haskell.TH.Syntax> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 13 03:39:10 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Aug 2018 03:39:10 -0000 Subject: [GHC] #15510: Qualified Holes In-Reply-To: <049.e79fa23b6a2782343800cacfefeeaef8@haskell.org> References: <049.e79fa23b6a2782343800cacfefeeaef8@haskell.org> Message-ID: <064.57c57752827052156e1bab8f2dfa10e7@haskell.org> #15510: Qualified Holes -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Will it stop there, or will we want some form of text-pattern-matching? `M.fold*` to only suggest folds? But more sersiously: While this feature looks maybe a bit obscure (i.e. hard to discover and relatively specialized) it also doesn’t look harmful upon first glance. Maybe write it up as a GHC proposal and attract more discussion there? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 13 09:46:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Aug 2018 09:46:17 -0000 Subject: [GHC] #15511: GHCi internal error with runQ [| it |] and _ In-Reply-To: <047.47e93921a344b32cb0a276a01f9b81f9@haskell.org> References: <047.47e93921a344b32cb0a276a01f9b81f9@haskell.org> Message-ID: <062.ac245103abbcc1dfe6687612c3c65236@haskell.org> #15511: GHCi internal error with runQ [| it |] and _ -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: Thanks for the report. This has been fixed in #15007. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 13 10:04:02 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Aug 2018 10:04:02 -0000 Subject: [GHC] #15512: Rewrite rules should be able to produce custom compiler errors Message-ID: <047.49b395ff618a54610fa1944e1551b2dc@haskell.org> #15512: Rewrite rules should be able to produce custom compiler errors -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It would be nice if rewrite rules could produce compiler errors with custom messages when a certain combination of functions can only produce bottom or some other suitably undesirable outcome. For example, `length . cycle` is either never going to terminate or is going to give an error message (''e''.''g''., if the input list is empty). It would be nice to be able to tell the programmer that at compile time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 13 11:56:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Aug 2018 11:56:39 -0000 Subject: [GHC] #15512: Rewrite rules should be able to produce custom compiler errors In-Reply-To: <047.49b395ff618a54610fa1944e1551b2dc@haskell.org> References: <047.49b395ff618a54610fa1944e1551b2dc@haskell.org> Message-ID: <062.58d2faf7918174a1cc75e03d6ea71aff@haskell.org> #15512: Rewrite rules should be able to produce custom compiler errors -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I don't think this is the place of the simple mechanism of rewrite rules. This can be implemented using a compiler plugin and users could specify rules in the same manner as a rewrite rule. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 13 13:11:16 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Aug 2018 13:11:16 -0000 Subject: [GHC] #15510: Qualified Holes In-Reply-To: <049.e79fa23b6a2782343800cacfefeeaef8@haskell.org> References: <049.e79fa23b6a2782343800cacfefeeaef8@haskell.org> Message-ID: <064.50eeb6e06bb7ec5602e8e12b0231004d@haskell.org> #15510: Qualified Holes -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): Definitely no text pattern matching, since that would steal syntax. I'll probably write this up as a proposal in a few weeks. I don't think there is any downside to this, since it replaces an error message and upgrades it to a better error message. It is probably only useful in niche cases though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 13 14:45:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Aug 2018 14:45:32 -0000 Subject: [GHC] #15513: How to pass "-hide-all-packages" to the GHC API? Message-ID: <048.48cd47e57c6c0c5d32e84baf3ee31f48@haskell.org> #15513: How to pass "-hide-all-packages" to the GHC API? -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Keywords: environment | Operating System: Unknown/Multiple file API | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In brittany, we have make use of the GHC API e.g. in the following fashion: {{{#!hs parseModuleFromString :: [String] -> System.IO.FilePath -> (GHC.DynFlags -> IO (Either String a)) -> String -> IO (Either String (ExactPrint.Anns, GHC.ParsedSource, a)) parseModuleFromString args fp dynCheck str = mask_ $ ExactPrint.ghcWrapper $ ExceptT.runExceptT $ do dflags0 <- lift $ ExactPrint.initDynFlagsPure fp str (dflags1, leftover, warnings) <- lift $ GHC.parseDynamicFlagsCmdLine dflags0 (GHC.noLoc <$> args) when (not $ null leftover) $ ExceptT.throwE $ "when parsing ghc flags: leftover flags: " ++ show (leftover <&> \(L _ s) -> s) when (not $ null warnings) $ ExceptT.throwE $ "when parsing ghc flags: encountered warnings: " ++ show (warnings <&> warnExtractorCompat) dynCheckRes <- ExceptT.ExceptT $ liftIO $ dynCheck dflags1 let res = ExactPrint.parseModuleFromStringInternal dflags1 fp str case res of Left (span, err) -> ExceptT.throwE $ show span ++ ": " ++ err Right (a , m ) -> pure (a, m, dynCheckRes) }}} This code unfortunately picks up "package environment files", which I take it is not at all necessary for this use-case: Brittany only requires parsing functionality, so external packages should be irrelevant. "Unfortunately", because the package environment files can easily become stale, which in turn breaks the API. The users' guide mentions the "-hide-all-packages" flag, but my attempts to pass this to the API so far have failed. What I have tried is calling `parseDynamicFlagsCmdLine` with "-hide-all-packages" as an argument, and using the resulting dynflags afterwards. This appears to be without effect, I think even when it is the first thing executed inside of `runGhc`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 13 16:11:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Aug 2018 16:11:56 -0000 Subject: [GHC] #9441: CSE should deal with letrec In-Reply-To: <045.987758d932a89023c69da6c12f8363f5@haskell.org> References: <045.987758d932a89023c69da6c12f8363f5@haskell.org> Message-ID: <060.b34133c8a5fe6793a00697e77e8c9e89@haskell.org> #9441: CSE should deal with letrec -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: CSE Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: T9441a, performance bug | T9441b, T9441c Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D5038 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * status: closed => new * owner: RolandSenn => (none) * resolution: fixed => Comment: Reopen ticket to improve the tests according to the comments of @nomeata in [https://phabricator.haskell.org/D5038] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 13 16:12:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Aug 2018 16:12:33 -0000 Subject: [GHC] #9441: CSE should deal with letrec In-Reply-To: <045.987758d932a89023c69da6c12f8363f5@haskell.org> References: <045.987758d932a89023c69da6c12f8363f5@haskell.org> Message-ID: <060.2ba3282be51befe00531aaa71e5c418a@haskell.org> #9441: CSE should deal with letrec -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: RolandSenn Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: CSE Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: T9441a, performance bug | T9441b, T9441c Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D5038 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: (none) => RolandSenn -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 13 16:33:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Aug 2018 16:33:24 -0000 Subject: [GHC] #5518: Some unicode symbols are not allow in literal characters or strings In-Reply-To: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> References: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> Message-ID: <059.3ef858c2395fff712bfafd4eb0c10629@haskell.org> #5518: Some unicode symbols are not allow in literal characters or strings ---------------------------------+-------------------------------------- Reporter: ertai | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 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): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by joeyh): Similarly, with ghc 8.2.2 (debian), this is not accepted: main = putChar '🥖' That's U+1F956 baguette. ghc says: lexical error in string/character literal at character '\129366' My system is fully utf-8 enabled and the original problem character works ok. Guess this is just lag getting the unicode character tables updated. However, while it seems reasonable for ghc to not let me define a function eg (🥖) = () since it doesn't know what kind of symbol baguette is, it seems much less reasonable to not accept any unicode inside a string. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 13 17:16:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Aug 2018 17:16:00 -0000 Subject: [GHC] #12980: Unlifted class method rejected In-Reply-To: <047.30d5cc1ce932625fb79015dfcdcefc56@haskell.org> References: <047.30d5cc1ce932625fb79015dfcdcefc56@haskell.org> Message-ID: <062.b818fd73c423da162f37f12a7f11a220@haskell.org> #12980: Unlifted class method rejected -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 13 19:24:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Aug 2018 19:24:51 -0000 Subject: [GHC] #15512: Rewrite rules should be able to produce custom compiler errors In-Reply-To: <047.49b395ff618a54610fa1944e1551b2dc@haskell.org> References: <047.49b395ff618a54610fa1944e1551b2dc@haskell.org> Message-ID: <062.4ed6d3e2c86c61a5b9d346eba07a698f@haskell.org> #15512: Rewrite rules should be able to produce custom compiler errors -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ChaiTRex): * status: new => closed * resolution: => fixed Comment: OK, no problem. On these sorts of suggestions that I find out are not good ideas, how should I close the tickets? As "invalid"? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 13 19:25:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Aug 2018 19:25:17 -0000 Subject: [GHC] #15512: Rewrite rules should be able to produce custom compiler errors In-Reply-To: <047.49b395ff618a54610fa1944e1551b2dc@haskell.org> References: <047.49b395ff618a54610fa1944e1551b2dc@haskell.org> Message-ID: <062.a2f29fca4961cfade6e5df1de81a27b0@haskell.org> #15512: Rewrite rules should be able to produce custom compiler errors -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ChaiTRex): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 13 20:37:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Aug 2018 20:37:38 -0000 Subject: [GHC] #15514: Older Trac ticket links redirect to this site, but not to the specific ticket Message-ID: <047.28955a11ad343c28afe5b086a77914a5@haskell.org> #15514: Older Trac ticket links redirect to this site, but not to the specific ticket -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 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: -------------------------------------+------------------------------------- == Current behavior == An old ticket link is redirected to this new site, just not to the actual ticket, so some form of redirection is configured: || ||= old link =||= redirects to =|| ||= HTTP =|| http://hackage.haskell.org/trac/ghc/ticket/698 || https://ghc.haskell.org/trac/ghc || ||= HTTPS =|| https://hackage.haskell.org/trac/ghc/ticket/698 || https://ghc.haskell.org/trac/ghc || == Desired outcome == An old ticket link should redirect to the actual ticket: || ||= old link =||= redirects to =|| ||= HTTP =|| http://hackage.haskell.org/trac/ghc/ticket/698 || https://ghc.haskell.org/trac/ghc/ticket/698 || ||= HTTPS =|| https://hackage.haskell.org/trac/ghc/ticket/698 || https://ghc.haskell.org/trac/ghc/ticket/698 || -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 13 20:47:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Aug 2018 20:47:01 -0000 Subject: [GHC] #15514: Older Trac ticket links redirect to this site, but not to the specific ticket In-Reply-To: <047.28955a11ad343c28afe5b086a77914a5@haskell.org> References: <047.28955a11ad343c28afe5b086a77914a5@haskell.org> Message-ID: <062.af00d95a1399fdb6d310d626815c2bd5@haskell.org> #15514: Older Trac ticket links redirect to this site, but not to the specific ticket -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by ChaiTRex: Old description: > == Current behavior == > > An old ticket link is redirected to this new site, just not to the actual > ticket, so some form of redirection is configured: > > || ||= old link =||= > redirects to =|| > ||= HTTP =|| http://hackage.haskell.org/trac/ghc/ticket/698 || > https://ghc.haskell.org/trac/ghc || > ||= HTTPS =|| https://hackage.haskell.org/trac/ghc/ticket/698 || > https://ghc.haskell.org/trac/ghc || > > == Desired outcome == > > An old ticket link should redirect to the actual ticket: > > || ||= old link =||= > redirects to =|| > ||= HTTP =|| http://hackage.haskell.org/trac/ghc/ticket/698 || > https://ghc.haskell.org/trac/ghc/ticket/698 || > ||= HTTPS =|| https://hackage.haskell.org/trac/ghc/ticket/698 || > https://ghc.haskell.org/trac/ghc/ticket/698 || New description: == Current behavior == An old ticket link is redirected to this new site, just not to the actual ticket, so some form of redirection is configured: || ||= old link =||= redirects to =|| ||= HTTP =|| http://hackage.haskell.org/trac/ghc/ticket/698 || https://ghc.haskell.org/trac/ghc || ||= HTTPS =|| https://hackage.haskell.org/trac/ghc/ticket/698 || https://ghc.haskell.org/trac/ghc || == Desired outcome == An old ticket link should redirect to the actual ticket: || ||= old link =||= redirects to =|| ||= HTTP =|| http://hackage.haskell.org/trac/ghc/ticket/698 || https://ghc.haskell.org/trac/ghc/ticket/698 || ||= HTTPS =|| https://hackage.haskell.org/trac/ghc/ticket/698 || https://ghc.haskell.org/trac/ghc/ticket/698 || == Importance == This is at least mildly important, as sites like Stack Overflow and old mailing list archives that show up in Google results still have comments and posts with these old Trac links, and some of those Trac tickets contain information that is very valuable. It would be nice if the user experience upon clicking one of the old links was much better. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 13 22:49:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Aug 2018 22:49:13 -0000 Subject: [GHC] #15515: Bogus "No instance" error when type families appear in kinds Message-ID: <050.0a7c38436bfa328034525623f7135078@haskell.org> #15515: Bogus "No instance" error when type families appear in kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 (Type checker) | Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code typechecks: {{{#!hs {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind import Data.Proxy class C a where c :: Proxy a type family F data D :: F -> Type instance C (D :: F -> Type) where c = undefined }}} However, if we try to actually //use// that `C D` instance, like so: {{{#!hs c' :: Proxy (D :: F -> Type) c' = c @(D :: F -> Type) }}} Then GHC gives a rather flummoxing error message: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:20:6: error: • No instance for (C D) arising from a use of ‘c’ • In the expression: c @(D :: F -> Type) In an equation for ‘c'’: c' = c @(D :: F -> Type) | 20 | c' = c @(D :: F -> Type) | ^^^^^^^^^^^^^^^^^^^ }}} But that error is clearly misleading, as we defined such a `C D` instance directly above it! The use of the type family `F` in the kind of `D` appears to play an important role in this bug. If I change `F` to be a data type (e.g., `data F`), then `c'` is accepted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 13 23:27:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Aug 2018 23:27:47 -0000 Subject: [GHC] #15516: ghci: dynamic linking fails on osx Message-ID: <043.9e113393326f5d3476a9ce02881a262c@haskell.org> #15516: ghci: dynamic linking fails on osx -------------------------------------+------------------------------------- Reporter: kfiz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/vj/cm0c8jrs739_t411zdcx72240000gp/T/ghc24522_0/libghc_9.dylib, 5): Symbol not found: _DataziCsvUtils_rowBy_closure Referenced from: /var/folders/vj/cm0c8jrs739_t411zdcx72240000gp/T/ghc24522_0/libghc_9.dylib Expected in: flat namespace in /var/folders/vj/cm0c8jrs739_t411zdcx72240000gp/T/ghc24522_0/libghc_9.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 06:05:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 06:05:34 -0000 Subject: [GHC] #15514: Older Trac ticket links redirect to this site, but not to the specific ticket In-Reply-To: <047.28955a11ad343c28afe5b086a77914a5@haskell.org> References: <047.28955a11ad343c28afe5b086a77914a5@haskell.org> Message-ID: <062.79d2accb89434768f3aea94b7f0f6b79@haskell.org> #15514: Older Trac ticket links redirect to this site, but not to the specific ticket -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: gbaz, bgamari (added) Comment: Who is maintaining hackage.haskell.org? Maybe gbaz knows, or bgamari? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 07:32:43 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 07:32:43 -0000 Subject: [GHC] #10827: GHCi should support interpeting multiple packages/units with separate DynFlags In-Reply-To: <045.56917c0b2dd940e5429ceefba9639e36@haskell.org> References: <045.56917c0b2dd940e5429ceefba9639e36@haskell.org> Message-ID: <060.f93d06888164b8328c8422da6e70ab16@haskell.org> #10827: GHCi should support interpeting multiple packages/units with separate DynFlags -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by _recursion): * cc: _recursion (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 07:54:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 07:54:37 -0000 Subject: [GHC] #5518: Some unicode symbols are not allow in literal characters or strings In-Reply-To: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> References: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> Message-ID: <059.b412a0c76122867573c661b5bd627c23@haskell.org> #5518: Some unicode symbols are not allow in literal characters or strings ---------------------------------+-------------------------------------- Reporter: ertai | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 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): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by ulysses4ever): I can confirm this for 8.4.3 and HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 10:12:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 10:12:49 -0000 Subject: [GHC] #5518: Some unicode symbols are not allow in literal characters or strings In-Reply-To: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> References: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> Message-ID: <059.6911a07e6e68271abfa1522f4822a3fd@haskell.org> #5518: Some unicode symbols are not allow in literal characters or strings ---------------------------------+-------------------------------------- Reporter: ertai | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5066 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by ulysses4ever): * status: closed => new * differential: => Phab:D5066 * resolution: fixed => * version: 7.0.3 => Comment: I renewed the Unicode tables as described [https://github.com/ghc/ghc/blob/24e56ebd010846683b236b6ef3678c2217640120/libraries/base/cbits/README.Unicode here], and this fixed the issue. Merge? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 10:13:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 10:13:26 -0000 Subject: [GHC] #5518: Some unicode symbols are not allow in literal characters or strings In-Reply-To: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> References: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> Message-ID: <059.66ff0cbd732ed22eceb8400e80fcf577@haskell.org> #5518: Some unicode symbols are not allow in literal characters or strings ---------------------------------+-------------------------------------- Reporter: ertai | Owner: ulysses4ever Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5066 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by ulysses4ever): * owner: (none) => ulysses4ever -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 10:13:51 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 10:13:51 -0000 Subject: [GHC] #5518: Some unicode symbols are not allow in literal characters or strings In-Reply-To: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> References: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> Message-ID: <059.a0caaa37afab80091f5783e3725d59ad@haskell.org> #5518: Some unicode symbols are not allow in literal characters or strings ---------------------------------+-------------------------------------- Reporter: ertai | Owner: ulysses4ever Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5066 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by ulysses4ever): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 14:09:43 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 14:09:43 -0000 Subject: [GHC] #15492: Plugin recompilation check fails when profiling is enabled In-Reply-To: <049.6cd45f735e6cc5104c701afb7f68bb71@haskell.org> References: <049.6cd45f735e6cc5104c701afb7f68bb71@haskell.org> Message-ID: <064.35de82d82de41f77d982e818cbaa64e3@haskell.org> #15492: Plugin recompilation check fails when profiling is enabled -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5048 Wiki Page: | -------------------------------------+------------------------------------- Changes (by darchon): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 14:39:55 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 14:39:55 -0000 Subject: [GHC] #15515: Bogus "No instance" error when type families appear in kinds In-Reply-To: <050.0a7c38436bfa328034525623f7135078@haskell.org> References: <050.0a7c38436bfa328034525623f7135078@haskell.org> Message-ID: <065.ea8161f388b3a972ca947d776b318405@haskell.org> #15515: Bogus "No instance" error when type families appear in kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The class instance should be rejected -- indeed, I'm quite surprised it's not. Let's write with explicit kinds: {{{#!hs class C k a where ... instance C (F -> Type) D where ... }}} That instance mentions a type family in one of its arguments, which should be rejected. I would love to come up with a way where we ignore determined dependent arguments during matching, which would then allow this instance to work, but we're not there yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 14:46:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 14:46:20 -0000 Subject: [GHC] #15515: Bogus "No instance" error when type families appear in kinds In-Reply-To: <050.0a7c38436bfa328034525623f7135078@haskell.org> References: <050.0a7c38436bfa328034525623f7135078@haskell.org> Message-ID: <065.8a9bbd426a9b9e1be57e10f6564c095e@haskell.org> #15515: Bogus "No instance" error when type families appear in kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Darn, I was afraid you were going to say that. Is there any relationship between this ticket and #12564? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 14:53:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 14:53:22 -0000 Subject: [GHC] #15515: Bogus "No instance" error when type families appear in kinds In-Reply-To: <050.0a7c38436bfa328034525623f7135078@haskell.org> References: <050.0a7c38436bfa328034525623f7135078@haskell.org> Message-ID: <065.bc10564017b7b08be6dcbe9318134435@haskell.org> #15515: Bogus "No instance" error when type families appear in kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes -- fixing that ticket will allow this one to make forward (as opposed to backward) progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 15:09:25 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 15:09:25 -0000 Subject: [GHC] #12758: Bring sanity to our performance testsuite In-Reply-To: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> References: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> Message-ID: <061.72428723cbb6febd82168b6fbf362630@haskell.org> #12758: Bring sanity to our performance testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.8.1 Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3758 Wiki Page: | -------------------------------------+------------------------------------- Comment (by domenkozar): Some insight how I've implemented a similar setting for Snabb (open source high performance networking drivers). Using Nix, we build a matrix of Snabb (multiple git branches, different versions of software dependencies like Qemu, etc) and plot all of those graphs. There is no smart automation to abort of fail for contributions, but if you run these tests before releases - and even as a cronjob every X days, you can spot regressions easily and then bisect the commit. Nix tags what derivations are benchmarks and those run on specialized hardware 1 at the time. Example report: https://hydra.snabb.co/build/3641949/download/2/report.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 16:48:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 16:48:50 -0000 Subject: [GHC] #15517: haddock triggers panic in trimJoinCont Message-ID: <046.8e85deab87c1c94bb06eaa4a95b7f658@haskell.org> #15517: haddock triggers panic in trimJoinCont -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Running haddock on the [https://github.com/VictorCMiraldo/generics-mrsop `generics-mrsop`] package results in {{{ haddock: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): completeCall fail_av9P Select nodup wild_00 Stop[BoringCtxt] Rep Singl (El FamRoseInt) (Lkup ix CodesRoseInt) Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/simplCore/Simplify.hs:1533:9 in ghc:Simplify }}} The same problem affects 8.6.1 and HEAD, but not 8.2.2. The panic seems to stem from [https://github.com/ghc/ghc/blob/64c71ce956af3af593a46ef0d615c7f6fe6ecece/compiler/simplCore/Simplify.hs#L1613 this catch-all in `trimeJoinCont`]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 16:51:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 16:51:14 -0000 Subject: [GHC] #15517: haddock triggers panic in trimJoinCont In-Reply-To: <046.8e85deab87c1c94bb06eaa4a95b7f658@haskell.org> References: <046.8e85deab87c1c94bb06eaa4a95b7f658@haskell.org> Message-ID: <061.3425772d008765f7b453bd3b51acf3d3@haskell.org> #15517: haddock triggers panic in trimJoinCont -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by sjakobi: Old description: > Running haddock on the [https://github.com/VictorCMiraldo/generics-mrsop > `generics-mrsop`] package results in > > {{{ > haddock: panic! (the 'impossible' happened) > (GHC version 8.4.3 for x86_64-unknown-linux): > completeCall > > fail_av9P > Select nodup wild_00 > Stop[BoringCtxt] Rep Singl (El FamRoseInt) (Lkup ix CodesRoseInt) > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in > ghc:Outputable > pprPanic, called at compiler/simplCore/Simplify.hs:1533:9 in > ghc:Simplify > }}} > > The same problem affects 8.6.1 and HEAD, but not 8.2.2. > > The panic seems to stem from > [https://github.com/ghc/ghc/blob/64c71ce956af3af593a46ef0d615c7f6fe6ecece/compiler/simplCore/Simplify.hs#L1613 > this catch-all in `trimeJoinCont`]. New description: Running haddock on the [https://github.com/VictorCMiraldo/generics-mrsop `generics-mrsop`] package results in {{{ haddock: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): completeCall fail_av9P Select nodup wild_00 Stop[BoringCtxt] Rep Singl (El FamRoseInt) (Lkup ix CodesRoseInt) Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/simplCore/Simplify.hs:1533:9 in ghc:Simplify }}} The same problem affects 8.6.1 and HEAD, but not 8.2.2. The panic seems to stem from [https://github.com/ghc/ghc/blob/64c71ce956af3af593a46ef0d615c7f6fe6ecece/compiler/simplCore/Simplify.hs#L1613 this catch-all in `trimJoinCont`]. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 17:16:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 17:16:14 -0000 Subject: [GHC] #13165: Speed up the RTS hash table In-Reply-To: <047.5597063b110123c6100b4b707918365d@haskell.org> References: <047.5597063b110123c6100b4b707918365d@haskell.org> Message-ID: <062.6a1be416ddfe3839328410829bd63923@haskell.org> #13165: Speed up the RTS hash table -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NoidedSuper): I'm going to take a crack at implementing a linear probing table today, since that seems to be the easiest thing to do. I think specializing the hash table for different key types will probably yield more performance benefits in the long run, but getting some cache-friendliness with linear probing is better than nothing! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 17:26:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 17:26:59 -0000 Subject: [GHC] #15515: Bogus "No instance" error when type families appear in kinds In-Reply-To: <050.0a7c38436bfa328034525623f7135078@haskell.org> References: <050.0a7c38436bfa328034525623f7135078@haskell.org> Message-ID: <065.8d88d449d3f717e4619f704c36fa8d5e@haskell.org> #15515: Bogus "No instance" error when type families appear in kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: 12564 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * blockedby: => 12564 Comment: So as far as why GHC doesn't simply error when you define `instance C (D :: F -> Type)`, I think it might be due to these lines in `check_valid_inst_head`: {{{#!hs | otherwise = mapM_ checkValidTypePat ty_args where ... ty_args = filterOutInvisibleTypes (classTyCon clas) cls_args }}} Where `checkValidTypePat` is what throws the `Illegal type synonym family application in instance` error seen in #12564. Because `ty_args` has filtered out kinds, it won't catch any type families in kinds, like in the original program. I think we could extend this error message to kinds by simply mapping `checkValidTypePat` over all `cls_args`, and not just `ty_args`. Do you agree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 17:37:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 17:37:08 -0000 Subject: [GHC] #15515: Bogus "No instance" error when type families appear in kinds In-Reply-To: <050.0a7c38436bfa328034525623f7135078@haskell.org> References: <050.0a7c38436bfa328034525623f7135078@haskell.org> Message-ID: <065.4d3c03be98ccb86a6ebc71c6c2de9866@haskell.org> #15515: Bogus "No instance" error when type families appear in kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: 12564 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, comment:4 seems right to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 17:47:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 17:47:22 -0000 Subject: [GHC] #15515: Bogus "No instance" error when type families appear in kinds In-Reply-To: <050.0a7c38436bfa328034525623f7135078@haskell.org> References: <050.0a7c38436bfa328034525623f7135078@haskell.org> Message-ID: <065.7151c90f5bc21402ba7252a5a8617fb2@haskell.org> #15515: Bogus "No instance" error when type families appear in kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: 12564 | Blocking: Related Tickets: | Differential Rev(s): Phab:D5068 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5068 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 18:41:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 18:41:08 -0000 Subject: [GHC] #15517: -O0 and pattern synonyms triggers panic in trimJoinCont (was: haddock triggers panic in trimJoinCont) In-Reply-To: <046.8e85deab87c1c94bb06eaa4a95b7f658@haskell.org> References: <046.8e85deab87c1c94bb06eaa4a95b7f658@haskell.org> Message-ID: <061.2b258834b0464575b2685fa5e488634d@haskell.org> #15517: -O0 and pattern synonyms triggers panic in trimJoinCont -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Actually, you don't even need Haddock to reproduce this issue. Here's as small of an example as I can extract from `generics-mrsop`: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE LambdaCase #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} module Generics.MRSOP.Examples.RoseTreeTH () where import Data.Proxy newtype Rep (ki :: kon -> *) (phi :: Nat -> *) (code :: [[Atom kon]]) = Rep (NS (PoA ki phi) code) data NA :: (kon -> *) -> (Nat -> *) -> Atom kon -> * where NA_I :: (IsNat k) => phi k -> NA ki phi (I k) NA_K :: ki k -> NA ki phi (K k) data NP :: (k -> *) -> [k] -> * where NP0 :: NP p '[] (:*) :: p x -> NP p xs -> NP p (x : xs) class IsNat (n :: Nat) where getSNat :: Proxy n -> SNat n instance IsNat Z where getSNat _ = SZ instance IsNat n => IsNat (S n) where getSNat p = SS (getSNat $ proxyUnsuc p) proxyUnsuc :: Proxy (S n) -> Proxy n proxyUnsuc _ = Proxy type PoA (ki :: kon -> *) (phi :: Nat -> *) = NP (NA ki phi) data Atom kon = K kon | I Nat data Nat = S Nat | Z data SNat :: Nat -> * where SZ :: SNat Z SS :: SNat n -> SNat (S n) data Kon = KInt data Singl (kon :: Kon) :: * where SInt :: Int -> Singl KInt type family Lkup (n :: Nat) (ks :: [k]) :: k where Lkup Z (k : ks) = k Lkup (S n) (k : ks) = Lkup n ks data El :: [*] -> Nat -> * where El :: IsNat ix => Lkup ix fam -> El fam ix data NS :: (k -> *) -> [k] -> * where There :: NS p xs -> NS p (x : xs) Here :: p x -> NS p (x : xs) class Family (ki :: kon -> *) (fam :: [*]) (codes :: [[[Atom kon]]]) | fam -> ki codes , ki codes -> fam where sfrom' :: SNat ix -> El fam ix -> Rep ki (El fam) (Lkup ix codes) data Rose a = a :>: [Rose a] | Leaf a type FamRoseInt = '[Rose Int, [Rose Int]] type CodesRoseInt = '[ '[ '[K KInt, I (S Z)], '[K KInt]], '[ '[], '[I Z, I (S Z)]]] pattern IdxRoseInt = SZ pattern IdxListRoseInt = SS SZ pat1 :: PoA Singl (El FamRoseInt) '[I Z, I (S Z)] -> NS (PoA Singl (El FamRoseInt)) '[ '[], '[I Z, I (S Z)]] pat1 d = There (Here d) pat2 :: PoA Singl (El FamRoseInt) '[] -> NS (PoA Singl (El FamRoseInt)) '[ '[], '[I Z, I (S Z)]] pat2 d = Here d pat3 :: PoA Singl (El FamRoseInt) '[K KInt] -> NS (PoA Singl (El FamRoseInt)) '[ '[K KInt, I (S Z)], '[K KInt]] pat3 d = There (Here d) pat4 :: PoA Singl (El FamRoseInt) '[K KInt, I (S Z)] -> NS (PoA Singl (El FamRoseInt)) '[ '[K KInt, I (S Z)], '[K KInt]] pat4 d = Here d instance Family Singl FamRoseInt CodesRoseInt where sfrom' = \case IdxRoseInt -> \case El (x :>: xs) -> Rep (pat4 (NA_K (SInt x) :* (NA_I (El xs) :* NP0))) El (Leaf x) -> Rep (pat3 (NA_K (SInt x) :* NP0)) IdxListRoseInt -> \case El [] -> Rep (pat2 NP0) El (x:xs) -> Rep (pat1 (NA_I (El x) :* (NA_I (El xs) :* NP0))) }}} To trigger the panic, compile this with `-O0` using GHC 8.4 or later: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs -O0 -fforce-recomp [1 of 1] Compiling Generics.MRSOP.Examples.RoseTreeTH ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): completeCall fail_a1dN Select nodup wild_00 Stop[BoringCtxt] Rep Singl (El FamRoseInt) (Lkup ix_a1en CodesRoseInt) Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/simplCore/Simplify.hs:1533:9 in ghc:Simplify }}} This panic does not occur in GHC 8.2.2, so something must have regressed here... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 18:46:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 18:46:19 -0000 Subject: [GHC] #15517: -O0 and pattern synonyms triggers panic in trimJoinCont In-Reply-To: <046.8e85deab87c1c94bb06eaa4a95b7f658@haskell.org> References: <046.8e85deab87c1c94bb06eaa4a95b7f658@haskell.org> Message-ID: <061.93e908d693f1bffb63f8ef856e929cf6@haskell.org> #15517: -O0 and pattern synonyms triggers panic in trimJoinCont -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "core-lint.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 18:47:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 18:47:03 -0000 Subject: [GHC] #15517: -O0 and pattern synonyms triggers panic in trimJoinCont In-Reply-To: <046.8e85deab87c1c94bb06eaa4a95b7f658@haskell.org> References: <046.8e85deab87c1c94bb06eaa4a95b7f658@haskell.org> Message-ID: <061.79cf8c24e42e93eaa3abb62b8c02e002@haskell.org> #15517: -O0 and pattern synonyms triggers panic in trimJoinCont -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've attached the output of running `/opt/ghc/8.4.3/bin/ghc Bug.hs -dcore- lint -O0 -fforce-recomp`. The highlight is: {{{ [1 of 1] Compiling Generics.MRSOP.Examples.RoseTreeTH ( Bug.hs, Bug.o ) *** Core Lint errors : in result of Simplifier *** : warning: [RHS of fail_a1dN :: Void# -> El FamRoseInt ix_a1en -> Rep Singl (El FamRoseInt) (Lkup ix_a1en CodesRoseInt)] idArity 2 exceeds arity imposed by the strictness signature x: fail_a1dN }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 18:50:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 18:50:24 -0000 Subject: [GHC] #15518: -ddump-splices pretty-prints LambdaCase nonsensically Message-ID: <050.995ed236da7a975a0b6882f1ba885e96@haskell.org> #15518: -ddump-splices pretty-prints LambdaCase nonsensically -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template | Version: 8.4.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: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE LambdaCase #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where $([d| f :: Bool -> () f = \case True -> () False -> () |]) }}} {{{ $ /opt/ghc/8.4.3/bin/ghci Bug.hs GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(6,3)-(9,6): Splicing declarations [d| f_a1xr :: Bool -> () f_a1xr = \case True -> () False -> () |] ======> f_a48E :: Bool -> () f_a48E = \case \ True -> GHC.Tuple.() \ False -> GHC.Tuple.() Ok, one module loaded. }}} Notice the use of `\ True` and `\ False`. Those patterns should not be preceded with backslashes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 18:55:04 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 18:55:04 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation Message-ID: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hi! I've just observed an important performance problem. This code: {{{ test0 :: Text -> Result test0 src = let s1 = token 't' s2 = token 'e' s3 = token 's' s4 = token 't' p = many $! s1 <> s2 <> s3 <> s4 in runTokenParser p src {-# NOINLINE test0 #-} }}} runs over 10 times faster than this one: {{{ testGrammar1 :: Grammar Char testGrammar1 = let s1 = token 't' s2 = token 'e' s3 = token 's' s4 = token 't' in many $! s1 <> s2 <> s3 <> s4 {-# INLINE testGrammar1 #-} test1 :: Text -> Result test1 = runTokenParser testGrammar1 {-# NOINLINE test1 #-} }}} I've also observed another thing here, namely the former code runs also over 10 times faster than this code: {{{ test2 :: Text -> Result test2 src = let s1 = token 't' s2 = token 'e' s3 = token 's' s4 = token 't' p = X $! many $! s1 <> s2 <> s3 <> s4 in runTokenParser p src {-# NOINLINE test2 #-} }}} The only difference here is the `X` wrapper, while the `runTokenParser` is defined as `runTokenParser (X !a) = runTokenParser a`. I've created sample project for it here: https://github.com/wdanilo/ghc- bug-peg-optimization/blob/master/src/Main.hs In order to run it execute `stack build --exec test`. The results are: {{{ benchmarking test0 time 420.0 μs (417.6 μs .. 422.9 μs) 1.000 R² (0.999 R² .. 1.000 R²) mean 421.0 μs (419.2 μs .. 425.3 μs) std dev 9.286 μs (4.239 μs .. 15.30 μs) variance introduced by outliers: 14% (moderately inflated) benchmarking test1 time 6.069 ms (6.022 ms .. 6.123 ms) 0.999 R² (0.998 R² .. 1.000 R²) mean 6.065 ms (6.037 ms .. 6.117 ms) std dev 114.5 μs (74.30 μs .. 183.4 μs) benchmarking test2 time 6.070 ms (6.007 ms .. 6.137 ms) 0.999 R² (0.998 R² .. 1.000 R²) mean 6.067 ms (6.039 ms .. 6.129 ms) std dev 123.0 μs (63.88 μs .. 220.1 μs) benchmarking native time 428.0 μs (421.5 μs .. 437.4 μs) 0.998 R² (0.995 R² .. 1.000 R²) mean 427.1 μs (424.1 μs .. 434.7 μs) std dev 15.18 μs (5.678 μs .. 26.26 μs) variance introduced by outliers: 29% (moderately inflated) }}} Where "native" is just standard `Text.takeWhile ...`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 18:59:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 18:59:08 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation In-Reply-To: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> References: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> Message-ID: <061.9e23366d4f24a0efa5f6a5ec929cdbe1@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by danilo2): Btw it seems like an inlining problem (but tbh I don't get where so big slowdown comes from!). If I replicate the code using type classes (each constructor of `Grammar` is separate type) and I create multiple instances which have to be resolved during compilation time and I mark them to be INLINED, the performance is the same as native. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 19:07:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 19:07:07 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation In-Reply-To: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> References: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> Message-ID: <061.5cd1e879864a965741e706da2871cda5@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by danilo2): One more thing - the source code uses `-XStrict` but even without using it and putting everywhere bang patterns by hand I got exactly the same results. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 19:09:48 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 19:09:48 -0000 Subject: [GHC] #15520: Invalid warning Defined but not used Message-ID: <042.29f984e76dd90b968c6e3dfd2c14dbe7@haskell.org> #15520: Invalid warning Defined but not used -------------------------------------+------------------------------------- Reporter: rik | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code gives warning: Defined but not used: data constructor ‘:+++’ {{{#!hs data U = Text :+++ Text x :: U x = "ss" :+++ "ss" }}} Also In prefix notation . -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 19:17:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 19:17:03 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation In-Reply-To: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> References: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> Message-ID: <061.e0dfbfeadfe210cbbca2160477dcaf1c@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by danilo2): * priority: high => highest Comment: I'm changing the priority to highest here because: 1. The predictive performance is super important 2. It's hurting us even more than some of the bugs with highest priority. It's as strange as my other bug #15176 but it's even more common situation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 19:22:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 19:22:56 -0000 Subject: [GHC] #14268: Implement Explicit Foralls Proposal In-Reply-To: <046.b2c6e5199adb1a263d1f797400e3472d@haskell.org> References: <046.b2c6e5199adb1a263d1f797400e3472d@haskell.org> Message-ID: <061.cc72382a205e647e9481ed1943474e37@haskell.org> #14268: Implement Explicit Foralls Proposal -------------------------------------+------------------------------------- Reporter: johnleo | Owner: mayac Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13809, 14198 Related Tickets: #13809 | Differential Rev(s): Phab:D4894 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mayac): * owner: (none) => mayac * differential: Phab:D4046 => Phab:D4894 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 19:31:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 19:31:53 -0000 Subject: [GHC] #2600: Bind type variables in RULES In-Reply-To: <046.60d3c1925e5a0ef8b7d1f9b2b5ebeabc@haskell.org> References: <046.60d3c1925e5a0ef8b7d1f9b2b5ebeabc@haskell.org> Message-ID: <061.b4fda5ffb7481db89f159f18f251b4d7@haskell.org> #2600: Bind type variables in RULES -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2110 | Differential Rev(s): Phab:D4894 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => Phab:D4894 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 19:49:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 19:49:53 -0000 Subject: [GHC] #15518: -ddump-splices pretty-prints LambdaCase nonsensically In-Reply-To: <050.995ed236da7a975a0b6882f1ba885e96@haskell.org> References: <050.995ed236da7a975a0b6882f1ba885e96@haskell.org> Message-ID: <065.76f264dfe92a09cd303fb0e7bb66ca8e@haskell.org> #15518: -ddump-splices pretty-prints LambdaCase nonsensically -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5069 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5069 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 19:55:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 19:55:01 -0000 Subject: [GHC] #15520: Invalid warning Defined but not used In-Reply-To: <042.29f984e76dd90b968c6e3dfd2c14dbe7@haskell.org> References: <042.29f984e76dd90b968c6e3dfd2c14dbe7@haskell.org> Message-ID: <057.67f9b788ab300d4b993c6e7622e4490d@haskell.org> #15520: Invalid warning Defined but not used -------------------------------------+------------------------------------- Reporter: rik | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => infoneeded Comment: I'm unable to reproduce the warning you're seeing, but that's only because you've posted an incomplete program (which doesn't compile). What is the export list you're using here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 19:56:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 19:56:10 -0000 Subject: [GHC] #15521: Provide a strict version of sum Message-ID: <047.f18d8bb60ade7fa2b84025003265a808@haskell.org> #15521: Provide a strict version of sum -------------------------------------+------------------------------------- Reporter: dnadales | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Prelude | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When adding huge list of numbers, a strict version of `sum` is preferred to avoid an unnecessary use of memory. A strict version of `sum` can be easily written using `foldl'` but it'd be nicer if a function such as: {{{#!hs sum' = foldl' (+) 0 }}} would be provided in the prelude already. Does this makes sense? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 20:58:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 20:58:08 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation In-Reply-To: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> References: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> Message-ID: <061.8344ecfc77a31dcb938619c8c78da4b4@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by danilo2): Ok, I've got one more important notice. If I put the `NOINLINE` pragma on the `runTokenParser` function, the `test0` is working 14 times slower. And this is interesting because `runTokenParser` does a simple pattern matching and then evaluates the `Text.span` function. So the `Text.span` (mapping a function to 100000 Chars) takes a tiny fraction of time of this computation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 21:27:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 21:27:07 -0000 Subject: [GHC] #15510: Qualified Holes In-Reply-To: <049.e79fa23b6a2782343800cacfefeeaef8@haskell.org> References: <049.e79fa23b6a2782343800cacfefeeaef8@haskell.org> Message-ID: <064.98a3676d51f6ebe6015571001d3e7927@haskell.org> #15510: Qualified Holes -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): If it only changes error messages it may not need a full proposal process – it does not change what programs are accepted or how they behave. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 23:03:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 23:03:06 -0000 Subject: [GHC] #15518: -ddump-splices pretty-prints LambdaCase nonsensically In-Reply-To: <050.995ed236da7a975a0b6882f1ba885e96@haskell.org> References: <050.995ed236da7a975a0b6882f1ba885e96@haskell.org> Message-ID: <065.39d901c7b511da1ecb1e47d9535ae5b9@haskell.org> #15518: -ddump-splices pretty-prints LambdaCase nonsensically -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5069 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"32008a9d0e09f0cc8899aa871d9a6b63fcc28a1a/ghc" 32008a9d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="32008a9d0e09f0cc8899aa871d9a6b63fcc28a1a" Properly designate LambdaCase alts as CaseAlt in TH Summary: When `\case` expressions are parsed normally, their alternatives are marked as `CaseAlt` (which means that they are pretty-printed without a `\` character in front of them, unlike for lambda expressions). However, `\case` expressions created by way of Template Haskell (in `Convert`) inconsistently designated the case alternatives as `LambdaExpr`, causing them to be pretty-printed poorly (as shown in #15518). The fix is simple: use `CaseAlt` consistently. Test Plan: make test TEST=T15518 Reviewers: goldfire, bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15518 Differential Revision: https://phabricator.haskell.org/D5069 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 23:04:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 23:04:45 -0000 Subject: [GHC] #15518: -ddump-splices pretty-prints LambdaCase nonsensically In-Reply-To: <050.995ed236da7a975a0b6882f1ba885e96@haskell.org> References: <050.995ed236da7a975a0b6882f1ba885e96@haskell.org> Message-ID: <065.7edcf82cbeb0e347f29540da9d7349de@haskell.org> #15518: -ddump-splices pretty-prints LambdaCase nonsensically -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5069 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 23:30:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 23:30:58 -0000 Subject: [GHC] #15517: -O0 and pattern synonyms triggers panic in trimJoinCont In-Reply-To: <046.8e85deab87c1c94bb06eaa4a95b7f658@haskell.org> References: <046.8e85deab87c1c94bb06eaa4a95b7f658@haskell.org> Message-ID: <061.78f7bb5e9edb770bd81bce143215ba86@haskell.org> #15517: -O0 and pattern synonyms triggers panic in trimJoinCont -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) Comment: Commit 33452dfc6cf891b59d63fa9fe138b18cbce4df81 (`Refactor the Mighty Simplifier`) introduced this regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 14 23:47:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Aug 2018 23:47:19 -0000 Subject: [GHC] #15517: -O0 and pattern synonyms triggers panic in trimJoinCont In-Reply-To: <046.8e85deab87c1c94bb06eaa4a95b7f658@haskell.org> References: <046.8e85deab87c1c94bb06eaa4a95b7f658@haskell.org> Message-ID: <061.d16c8a2b8f194ab2c5f2a411afb804d5@haskell.org> #15517: -O0 and pattern synonyms triggers panic in trimJoinCont -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): I reduced to: {{{ {-# LANGUAGE PatternSynonyms #-} module T15517 where data Nat = Z | S Nat pattern Zpat = Z class Family ki where sfrom :: Nat -> () -> ki instance Family Bool where sfrom Zpat = \_ -> False sfrom (S Z) = \_ -> False }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 03:32:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 03:32:18 -0000 Subject: [GHC] #15522: Cannot bind symbolic names in a rule Message-ID: <047.e900d97b29e01629e6290ff4351ab1c8@haskell.org> #15522: Cannot bind symbolic names in a rule -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I assumed the following would be accepted: {{{ {-# RULES "blah" forall (+++). id (+++) = (+++) #-} }}} But it's not, as the parser doesn't like my `+++`. I find this inconsistent with the way that GHC normally treats term-level variables, which can generally be symbolic. That said, I have no need for this feature, and allowing it creates more headaches (it potentially creates parsing challenges, especially with #2600; and soon people will want to specify fixities). I thus propose simply to document that we don't allow it and move on. If you agree (for any definition of "you"), please post, as I'd love other opinions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 08:13:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 08:13:18 -0000 Subject: [GHC] #15521: Provide a strict version of sum In-Reply-To: <047.f18d8bb60ade7fa2b84025003265a808@haskell.org> References: <047.f18d8bb60ade7fa2b84025003265a808@haskell.org> Message-ID: <062.26fed31bd39ea00944d280c93df74ec4@haskell.org> #15521: Provide a strict version of sum -------------------------------------+------------------------------------- Reporter: dnadales | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Prelude | 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 f-a): Is there any occourrence when using a lazy `sum` is more appropriate than using its stricter version? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 08:20:16 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 08:20:16 -0000 Subject: [GHC] #11350: Allow visible type application in patterns In-Reply-To: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> References: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> Message-ID: <066.f7dc22fb18c93c4c00c89ecf5d268f5b@haskell.org> #11350: Allow visible type application in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11385, #13159, | Differential Rev(s): #13158 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by jpbernardy): * cc: jpbernardy (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 08:58:21 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 08:58:21 -0000 Subject: [GHC] #15523: GHC Panic on malformed newtype and StrictData Message-ID: <046.6359f28ac562dce85bc55db993cdbcf9@haskell.org> #15523: GHC Panic on malformed newtype and StrictData -------------------------------------+------------------------------------- Reporter: rdnetto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following source causes a panic: {{{#!hs {-# LANGUAGE StrictData #-} module Main where newtype Duration = Foo data Literal = LitDuration Duration }}} Result: {{{ [1 of 1] Compiling Main ( src/Main.hs, .stack-work/dist/x86_64 -linux-tinfo6/Cabal-2.2.0.1/build/tcalc/tcalc-tmp/Main.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): mkNewTyConRhs Foo [] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/iface/BuildTyCl.hs:77:27 in ghc:BuildTyCl Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} If we remove the StrictData pragma, then we get a syntax error as expected: {{{ /home/reuben/tcalc/src/Main.hs:3:20: error: • The constructor of a newtype must have exactly one field but ‘Foo’ has none • In the definition of data constructor ‘Foo’ In the newtype declaration for ‘Duration’ | 3 | newtype Duration = Foo | ^^^ }}} I was able to reproduce this with GHC 8.4.3 and 8.2.2 (using Stack LTS snapshots). GHC 8.0.2 is not affected. A test case buildable with Stack can be found at https://github.com/rdnetto/tcalc/tree/ghc-bug (i.e. on the ghc-bug branch). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 09:39:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 09:39:44 -0000 Subject: [GHC] #15523: GHC Panic on malformed newtype and StrictData In-Reply-To: <046.6359f28ac562dce85bc55db993cdbcf9@haskell.org> References: <046.6359f28ac562dce85bc55db993cdbcf9@haskell.org> Message-ID: <061.7292de43c5fa945997722156738897b2@haskell.org> #15523: GHC Panic on malformed newtype and StrictData -------------------------------------+------------------------------------- Reporter: rdnetto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5070 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * differential: => Phab:D5070 Comment: Fortunately, the bug is not present in master. I put a regression test on Phab. {{{ $ ghc -O T15523 [1 of 1] Compiling Main ( T15523.hs, T15523.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): mkNewTyConRhs Foo [] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/iface/BuildTyCl.hs:77:27 in ghc:BuildTyCl Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug $ head/inplace/bin/ghc-stage2 T15523 [1 of 1] Compiling Main ( T15523.hs, T15523.o ) T15523.hs:5:20: error: • The constructor of a newtype must have exactly one field but ‘Foo’ has none • In the definition of data constructor ‘Foo’ In the newtype declaration for ‘Duration’ | 5 | newtype Duration = Foo | ^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 09:44:53 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 09:44:53 -0000 Subject: [GHC] #15523: GHC Panic on malformed newtype and StrictData In-Reply-To: <046.6359f28ac562dce85bc55db993cdbcf9@haskell.org> References: <046.6359f28ac562dce85bc55db993cdbcf9@haskell.org> Message-ID: <061.d7a42e83add664d159260595a81aaab8@haskell.org> #15523: GHC Panic on malformed newtype and StrictData -------------------------------------+------------------------------------- Reporter: rdnetto | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5070 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 10:10:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 10:10:59 -0000 Subject: [GHC] #15522: Cannot bind symbolic names in a rule In-Reply-To: <047.e900d97b29e01629e6290ff4351ab1c8@haskell.org> References: <047.e900d97b29e01629e6290ff4351ab1c8@haskell.org> Message-ID: <062.845acc88271513c293f94c7e6862c685@haskell.org> #15522: Cannot bind symbolic names in a rule -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | 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 monoidal): +1, this doesn't seem to be worth the maintenance burden. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 12:44:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 12:44:40 -0000 Subject: [GHC] #13165: Speed up the RTS hash table In-Reply-To: <047.5597063b110123c6100b4b707918365d@haskell.org> References: <047.5597063b110123c6100b4b707918365d@haskell.org> Message-ID: <062.7c52057b37386d6e697752e32b23dd7d@haskell.org> #13165: Speed up the RTS hash table -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm looking forward to hearing how it goes! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 14:40:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 14:40:28 -0000 Subject: [GHC] #15523: GHC Panic on malformed newtype and StrictData In-Reply-To: <046.6359f28ac562dce85bc55db993cdbcf9@haskell.org> References: <046.6359f28ac562dce85bc55db993cdbcf9@haskell.org> Message-ID: <061.f82036c88bd9e120996a4e43530f6754@haskell.org> #15523: GHC Panic on malformed newtype and StrictData -------------------------------------+------------------------------------- Reporter: rdnetto | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5070 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): For the sake of historical curiosity, commit faec8d358985e5d0bf363bd96f23fe76c9e281f7 (`Track type variable scope more carefully.`) is what fixed this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 15:58:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 15:58:08 -0000 Subject: [GHC] #15486: primops.txt.pp still has support for WORD_SIZE_IN_BITS < 32 In-Reply-To: <047.b07118037eff8ffdb7c16341c32020aa@haskell.org> References: <047.b07118037eff8ffdb7c16341c32020aa@haskell.org> Message-ID: <062.853caa339c40be488ed65e9bb95620e4@haskell.org> #15486: primops.txt.pp still has support for WORD_SIZE_IN_BITS < 32 -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5050 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"290889927244c79479c4347dfa6c851a134dd6e0/ghc" 29088992/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="290889927244c79479c4347dfa6c851a134dd6e0" primops: Drop support for WORD_SIZE_IN_BITS < 32 Summary: Fixes #15486. Test Plan: Validate Reviewers: monoidal Reviewed By: monoidal Subscribers: rwbarton, carter GHC Trac Issues: #15486 Differential Revision: https://phabricator.haskell.org/D5050 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 15:58:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 15:58:08 -0000 Subject: [GHC] #15523: GHC Panic on malformed newtype and StrictData In-Reply-To: <046.6359f28ac562dce85bc55db993cdbcf9@haskell.org> References: <046.6359f28ac562dce85bc55db993cdbcf9@haskell.org> Message-ID: <061.a0b2205aaa6cf9b2e52830a012100d34@haskell.org> #15523: GHC Panic on malformed newtype and StrictData -------------------------------------+------------------------------------- Reporter: rdnetto | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5070 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"9f932d8a609f54127510a432f399b9487ea84d6a/ghc" 9f932d8a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9f932d8a609f54127510a432f399b9487ea84d6a" Add a test for Trac #15523 Summary: Fortunately the bug is not present in master. Test Plan: make test TEST=T15523 Reviewers: bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #15523 Differential Revision: https://phabricator.haskell.org/D5070 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 15:58:46 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 15:58:46 -0000 Subject: [GHC] #15486: primops.txt.pp still has support for WORD_SIZE_IN_BITS < 32 In-Reply-To: <047.b07118037eff8ffdb7c16341c32020aa@haskell.org> References: <047.b07118037eff8ffdb7c16341c32020aa@haskell.org> Message-ID: <062.477e390c66afc586379f2240db00ede1@haskell.org> #15486: primops.txt.pp still has support for WORD_SIZE_IN_BITS < 32 -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5050 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 15:58:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 15:58:59 -0000 Subject: [GHC] #15523: GHC Panic on malformed newtype and StrictData In-Reply-To: <046.6359f28ac562dce85bc55db993cdbcf9@haskell.org> References: <046.6359f28ac562dce85bc55db993cdbcf9@haskell.org> Message-ID: <061.564255ce7a2e519aa53823fb985b9249@haskell.org> #15523: GHC Panic on malformed newtype and StrictData -------------------------------------+------------------------------------- Reporter: rdnetto | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5070 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 16:17:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 16:17:15 -0000 Subject: [GHC] #15524: Performance regression when using the GHC API to evaluate code compared to 8.4 Message-ID: <051.53f38e3c9361ef8f17f16bc79295383b@haskell.org> #15524: Performance regression when using the GHC API to evaluate code compared to 8.4 -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 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: -------------------------------------+------------------------------------- I've been in the process of updating IHaskell to support GHC 8.6 and the test suite has become agonisingly slow as compared to GHC 8.4 and below. I've been able to work around this by using `--enable-executable-dynamic` as suggested by `christiaanb` on `#ghc`but I thought this was worth reporting as a bug. I am using `ghc-8.6.1-alpha2` so it's possible that this has been fixed in `beta1`. To reproduce this on a Linux installation with Nix: 1. `git clone https://github.com/gibiansky/IHaskell --branch support- ghc-8-6 repro` 2. `cd repro` 3. Comment out `--enable-executable-dynamic` in `release-8.6.nix` 4. `nix-build release-8.6.nix` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 16:26:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 16:26:28 -0000 Subject: [GHC] #15524: Performance regression when using the GHC API to evaluate code compared to 8.4 In-Reply-To: <051.53f38e3c9361ef8f17f16bc79295383b@haskell.org> References: <051.53f38e3c9361ef8f17f16bc79295383b@haskell.org> Message-ID: <066.42bf66dc00995d41a4de45b88674c016@haskell.org> #15524: Performance regression when using the GHC API to evaluate code compared to 8.4 -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The git hash of the commit for the repro is `ad0ec26cc976b7f263cc4781eead264b7080cc4e` just in case the branch mutates. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 17:35:21 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 17:35:21 -0000 Subject: [GHC] #15521: Provide a strict version of sum In-Reply-To: <047.f18d8bb60ade7fa2b84025003265a808@haskell.org> References: <047.f18d8bb60ade7fa2b84025003265a808@haskell.org> Message-ID: <062.6477cc936b47b3ed708ca6f7e1049fae@haskell.org> #15521: Provide a strict version of sum -------------------------------------+------------------------------------- Reporter: dnadales | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Prelude | 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 ulysses4ever): Replying to [comment:1 f-a]: > Is there any occourrence when using a lazy `sum` is more appropriate than using its stricter version? One might go with a usual non-termination argument: if you have divergent computation inside your list AND you don't actually use the result of `sum`, then you get a different behaviour. Similar argument applies for “expensive” computation inside the list. Also, Haskell Report (the Haskell standard) says that `sum` should behave lazily (AFAIK). So, changing the behavior of `sum` seems a bit of extreme to me. I'd rather argue for adding `sum' / product'` to `Prelude`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 18:43:49 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 18:43:49 -0000 Subject: [GHC] #15521: Provide a strict version of sum In-Reply-To: <047.f18d8bb60ade7fa2b84025003265a808@haskell.org> References: <047.f18d8bb60ade7fa2b84025003265a808@haskell.org> Message-ID: <062.d8cdde87896320629368f7b6df9f3cdb@haskell.org> #15521: Provide a strict version of sum -------------------------------------+------------------------------------- Reporter: dnadales | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Prelude | 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 f-a): Thanks ulysses4ever Replying to [comment:2 ulysses4ever]: > Also, Haskell Report (the Haskell standard) says that `sum` should behave lazily (AFAIK). So, changing the behavior of `sum` seems a bit of extreme to me. I'd rather argue for adding `sum' / product'` to `Prelude`. I thought the same, but: {{{ -- from page 192 of the "Haskell 2010 Language Report" sum :: Num a => [a] -> a The sum function computes the sum of a finite list of numbers. }}} Is mandatory laziness stated somewhere else? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 18:56:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 18:56:01 -0000 Subject: [GHC] #15524: Performance regression when using the GHC API to evaluate code compared to 8.4 In-Reply-To: <051.53f38e3c9361ef8f17f16bc79295383b@haskell.org> References: <051.53f38e3c9361ef8f17f16bc79295383b@haskell.org> Message-ID: <066.899b5e495e375b02d2ad055f947b5ae2@haskell.org> #15524: Performance regression when using the GHC API to evaluate code compared to 8.4 -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > I've been in the process of updating IHaskell to support GHC 8.6 and the > test suite has become agonisingly slow as compared to GHC 8.4 and below. > I've been able to work around this by using `--enable-executable-dynamic` > as suggested by `christiaanb` on `#ghc`but I thought this was worth > reporting as a bug. I am using `ghc-8.6.1-alpha2` so it's possible that > this has been fixed in `beta1`. > > To reproduce this on a Linux installation with Nix: > > 1. `git clone https://github.com/gibiansky/IHaskell --branch support- > ghc-8-6 repro` > 2. `cd repro` > 3. Comment out `--enable-executable-dynamic` in `release-8.6.nix` > 4. `nix-build release-8.6.nix` New description: I've been in the process of updating IHaskell to support GHC 8.6 and the test suite has become agonisingly slow as compared to GHC 8.4 and below. I've been able to work around this by using `--enable-executable-dynamic` as suggested by `christiaanb` on `#ghc`but I thought this was worth reporting as a bug. To reproduce this on a Linux installation with Nix: 1. `git clone https://github.com/gibiansky/IHaskell --branch support- ghc-8-6 repro` 2. `cd repro` 3. Comment out `--enable-executable-dynamic` in `release-8.6.nix` 4. `nix-build release-8.6.nix` -- Comment (by vaibhavsagar): I've since tried this with GHC 8.6.1-beta1 and am seeing the same behaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 19:16:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 19:16:20 -0000 Subject: [GHC] #15521: Provide a strict version of sum In-Reply-To: <047.f18d8bb60ade7fa2b84025003265a808@haskell.org> References: <047.f18d8bb60ade7fa2b84025003265a808@haskell.org> Message-ID: <062.dfaa415e22a442f37d710959cf478d3d@haskell.org> #15521: Provide a strict version of sum -------------------------------------+------------------------------------- Reporter: dnadales | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Prelude | 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 ulysses4ever): Maybe the HR argument is not that important, because the [http://hackage.haskell.org/package/base-4.11.1.0/docs/src/Data.Foldable.html#sum actual definition] is far from HR anyway. Just some code could brake if you change the semantics (see above). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 19:27:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 19:27:37 -0000 Subject: [GHC] #15525: Unicode 8.0 and later characters are invariably lexical errors Message-ID: <047.28ba0e189446e80c83f61ac8574b1084@haskell.org> #15525: Unicode 8.0 and later characters are invariably lexical errors -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've tried a few added alphabet characters and emojis from various Unicode versions. It seems like Unicode 7.0 works fine. It seems like characters from Unicode 8.0 and later are lexical errors. For example, with the Unicode 10.0 [https://emojipedia.org/t-rex/ T. rex emoji], there are three lexical errors below: {{{#!hs module NoTRex where tRex :: String tRex = "🦖" 🦖 :: String 🦖 = "🦖" }}} produces: {{{ [1 of 1] Compiling NoTRex ( NoTRex.hs, NoTRex.o ) NoTRex.hs:4:9: error: lexical error in string/character literal at character '\129430' | 4 | tRex = "🦖" | ^ }}} If that's removed, the name of the function `🦖` is also shown to be a lexical error. Also, pasting the fourth line into GHCi pastes only the characters before the first `🦖`, like the `🦖` and everything afterward weren't pasted in. ---- System information: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.3 $ lsb_release -ds Ubuntu 16.04.5 LTS }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 19:30:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 19:30:15 -0000 Subject: [GHC] #15520: Invalid warning Defined but not used In-Reply-To: <042.29f984e76dd90b968c6e3dfd2c14dbe7@haskell.org> References: <042.29f984e76dd90b968c6e3dfd2c14dbe7@haskell.org> Message-ID: <057.e9a36c4962e61eb91a1c74b76d0d8659@haskell.org> #15520: Invalid warning Defined but not used -------------------------------------+------------------------------------- Reporter: rik | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rik): I do not export the data constructor. The export list only contains other identifiers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 19:30:58 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 19:30:58 -0000 Subject: [GHC] #15525: Unicode 8.0 and later characters are invariably lexical errors In-Reply-To: <047.28ba0e189446e80c83f61ac8574b1084@haskell.org> References: <047.28ba0e189446e80c83f61ac8574b1084@haskell.org> Message-ID: <062.c3613c80c5826239567d81bd54d42b12@haskell.org> #15525: Unicode 8.0 and later characters are invariably lexical errors -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 5518 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ulysses4ever): * related: => 5518 Comment: Yes, the issue was raised in #5518 and there is a [https://phabricator.haskell.org/D5066 patch] waiting to be merged for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 19:31:17 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 19:31:17 -0000 Subject: [GHC] #15525: Unicode 8.0 and later characters are invariably lexical errors In-Reply-To: <047.28ba0e189446e80c83f61ac8574b1084@haskell.org> References: <047.28ba0e189446e80c83f61ac8574b1084@haskell.org> Message-ID: <062.da8a9efe11f27ebff90e79103be37019@haskell.org> #15525: Unicode 8.0 and later characters are invariably lexical errors -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5518 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ulysses4ever): * related: 5518 => #5518 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 19:33:11 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 19:33:11 -0000 Subject: [GHC] #15521: Provide a strict version of sum In-Reply-To: <047.f18d8bb60ade7fa2b84025003265a808@haskell.org> References: <047.f18d8bb60ade7fa2b84025003265a808@haskell.org> Message-ID: <062.a155a793f9f423288ce9314bb7cba508@haskell.org> #15521: Provide a strict version of sum -------------------------------------+------------------------------------- Reporter: dnadales | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Prelude | 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 svenpanne): Be careful, you're mixing things up here, because there are actually 3 different `sum`s: * In `Prelude`: This must behave like the definition on p. 121 from the report mentioned above. * In `Data.List`: The report doesn't state anything regarding strictness, but following the principle of least surprise, this should better behave like `Prelude.sum`. Note that GHC 7.10 (i.e. `base` 4.8) generalized the signature a bit. * In `Data.Foldable`: Basically the same holds here as for the previous item. Note that I'm not saying that the current strictness behavior of `sum` is a brilliant idea, but it's basically far too late to change this. Doing such a change would definitely wreak havoc in the package ecosystem, because it is not even reflected by a change in the signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 19:35:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 19:35:29 -0000 Subject: [GHC] #15520: Invalid warning Defined but not used In-Reply-To: <042.29f984e76dd90b968c6e3dfd2c14dbe7@haskell.org> References: <042.29f984e76dd90b968c6e3dfd2c14dbe7@haskell.org> Message-ID: <057.db10dcef83e4d7967550999e7366930e@haskell.org> #15520: Invalid warning Defined but not used -------------------------------------+------------------------------------- Reporter: rik | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Do you export `x`? I can get the warning you claim with this program, which does //not// export `x`, for instance: {{{#!hs {-# LANGUAGE OverloadedStrings #-} {-# OPTIONS -Wunused-top-binds #-} module Foo (U) where import Data.Text (Text) data U = Text :+++ Text x :: U x = "ss" :+++ "ss" }}} However, this is correct behavior, since `x` is not used anywhere (and therefore `:+++` is transitively not used), so I'm still not sure what the bug is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 19:48:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 19:48:59 -0000 Subject: [GHC] #15526: Explain or remove mystery import in Unsafe.Coerce Message-ID: <045.8c1bd79d636e4b29cdc257cdfcb27b40@haskell.org> #15526: Explain or remove mystery import in Unsafe.Coerce -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Core | Version: 8.4.3 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `Unsafe.Coerce` has the line {{{#!hs import GHC.Integer () -- for build ordering }}} It is not at all clear to me why build ordering demands that `GHC.Integer` be compiled before `Unsafe.Coerce` when the latter uses no numeric literals, no arithmetic, and no numeric types. If there's a real reason for this, the comment should be expanded. Otherwise, the import should be removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 19:56:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 19:56:24 -0000 Subject: [GHC] #15526: Explain or remove mystery import in Unsafe.Coerce In-Reply-To: <045.8c1bd79d636e4b29cdc257cdfcb27b40@haskell.org> References: <045.8c1bd79d636e4b29cdc257cdfcb27b40@haskell.org> Message-ID: <060.f64e543ff1ed3ea52fec6d5ae71f8367@haskell.org> #15526: Explain or remove mystery import in Unsafe.Coerce -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): That comment is indeed cryptic, but I bet there is a good reason for this. There is a `[Note [Depend on GHC.Integer]` [http://git.haskell.org/ghc.git/blob/1e741fe829dcf25acf5bf07ce4593f2b537dd351:/libraries/base/GHC/Base.hs#l158 in GHC.Base] which explains why you often need empty `GHC.Integer` imports: {{{ Note [Depend on GHC.Integer] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Integer type is special because TidyPgm uses GHC.Integer.Type.mkInteger to construct Integer literal values Currently it reads the interface file whether or not the current module *has* any Integer literals, so it's important that GHC.Integer.Type (in package integer-gmp or integer-simple) is compiled before any other module. (There's a hack in GHC to disable this for packages ghc-prim, integer-gmp, integer-simple, which aren't allowed to contain any Integer literals.) Likewise we implicitly need Integer when deriving things like Eq instances. The danger is that if the build system doesn't know about the dependency on Integer, it'll compile some base module before GHC.Integer.Type, resulting in: Failed to load interface for ‘GHC.Integer.Type’ There are files missing in the ‘integer-gmp’ package, Bottom line: we make GHC.Base depend on GHC.Integer; and everything else either depends on GHC.Base, or does not have NoImplicitPrelude (and hence depends on Prelude). }}} Moreover, this workaround is still actively being used—a commit as recent as April 2018 (see 54acfbbf64f5fcb108836412e9be0cfabf0d7801) had to introduce additional `GHC.Integer ()` imports to resolve build ordering issues. In that commit, they followed `import GHC.Integer ()` with `-- see Note [Depend upon GHC.Integer] in libraries/base/GHC/Base.hs`. Would you consider this ticket fixed if that comment were copied over to `Unsafe.Coerce` as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 20:05:21 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 20:05:21 -0000 Subject: [GHC] #15526: Explain or remove mystery import in Unsafe.Coerce In-Reply-To: <045.8c1bd79d636e4b29cdc257cdfcb27b40@haskell.org> References: <045.8c1bd79d636e4b29cdc257cdfcb27b40@haskell.org> Message-ID: <060.eb04a0c0466356179c72aff2130743e3@haskell.org> #15526: Explain or remove mystery import in Unsafe.Coerce -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Thanks, Ryan. Yes, I think that would be sufficient. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 20:29:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 20:29:06 -0000 Subject: [GHC] #15527: TypeApplications error message doesn't parenthesize infix name Message-ID: <050.477d5429b1a8f48b2e52c0542d2adea3@haskell.org> #15527: TypeApplications error message doesn't parenthesize infix name -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If you compile the following program: {{{#!hs module Bug where f :: (Int -> Int) -> (Int -> Int) -> (Int -> Int) f = (.) @Int }}} You'll get this error: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:4:6: error: Pattern syntax in expression context: . at Int Did you mean to enable TypeApplications? | 4 | f = (.) @Int | ^^^^^^^^ }}} I was taken aback by this strange `.@` thing before I realized what was actually going on: the error message simply forgot to parenthesize `.`. This is `ppr_expr`'s fault, since it calls `ppr` on an `RdrName` instead of `pprPrefixOcc`. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 20:33:19 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 20:33:19 -0000 Subject: [GHC] #15527: TypeApplications error message doesn't parenthesize infix name In-Reply-To: <050.477d5429b1a8f48b2e52c0542d2adea3@haskell.org> References: <050.477d5429b1a8f48b2e52c0542d2adea3@haskell.org> Message-ID: <065.8f14285dd22c6f62abebfe45505f5755@haskell.org> #15527: TypeApplications error message doesn't parenthesize infix name -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5071 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5071 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 15 22:28:55 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Aug 2018 22:28:55 -0000 Subject: [GHC] #15521: Provide a strict version of sum In-Reply-To: <047.f18d8bb60ade7fa2b84025003265a808@haskell.org> References: <047.f18d8bb60ade7fa2b84025003265a808@haskell.org> Message-ID: <062.cca1afb1d87250d10d4dffe6071dc6a7@haskell.org> #15521: Provide a strict version of sum -------------------------------------+------------------------------------- Reporter: dnadales | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Prelude | 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 f-a): Yeah risky idea for very little gain. Sorry for having derailed this thread! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 02:01:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 02:01:28 -0000 Subject: [GHC] #15524: Performance regression when using the GHC API to evaluate code compared to 8.4 In-Reply-To: <051.53f38e3c9361ef8f17f16bc79295383b@haskell.org> References: <051.53f38e3c9361ef8f17f16bc79295383b@haskell.org> Message-ID: <066.96b63aa976c1ce0bc5f87ec66a4caad4@haskell.org> #15524: Performance regression when using the GHC API to evaluate code compared to 8.4 -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by vaibhavsagar: Old description: > I've been in the process of updating IHaskell to support GHC 8.6 and the > test suite has become agonisingly slow as compared to GHC 8.4 and below. > I've been able to work around this by using `--enable-executable-dynamic` > as suggested by `christiaanb` on `#ghc`but I thought this was worth > reporting as a bug. > > To reproduce this on a Linux installation with Nix: > > 1. `git clone https://github.com/gibiansky/IHaskell --branch support- > ghc-8-6 repro` > 2. `cd repro` > 3. Comment out `--enable-executable-dynamic` in `release-8.6.nix` > 4. `nix-build release-8.6.nix` New description: I've been in the process of updating IHaskell to support GHC 8.6 and the test suite has become agonisingly slow as compared to GHC 8.4 and below. I've been able to work around this by using `--enable-executable-dynamic` as suggested by `christiaanb` on `#ghc`but I thought this was worth reporting as a bug. To reproduce this on a Linux installation with Nix: 1. `git clone https://github.com/gibiansky/IHaskell` 2. `cd IHaskell` 3. `git checkout 6058cd4fac01a2023dbd09d174f1f8d4c36e7475` 4. Comment out `--enable-executable-dynamic` in `release-8.6.nix` 5. `nix-build release-8.6.nix` -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 07:20:33 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 07:20:33 -0000 Subject: [GHC] #7535: Using -with-rtsopts=-N should fail unless -threaded is also specified In-Reply-To: <048.f92d34b445bc46d26771a99cc0f59338@haskell.org> References: <048.f92d34b445bc46d26771a99cc0f59338@haskell.org> Message-ID: <063.98cfd2ddef6c3c0aceea8456ce2e7866@haskell.org> #7535: Using -with-rtsopts=-N should fail unless -threaded is also specified -------------------------------------+------------------------------------- Reporter: mhoermann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 4243 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 07:39:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 07:39:47 -0000 Subject: [GHC] #15524: Performance regression when using the GHC API to evaluate code compared to 8.4 In-Reply-To: <051.53f38e3c9361ef8f17f16bc79295383b@haskell.org> References: <051.53f38e3c9361ef8f17f16bc79295383b@haskell.org> Message-ID: <066.a620d9ddf708f8881eb49aa6a1925d1b@haskell.org> #15524: Performance regression when using the GHC API to evaluate code compared to 8.4 -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): "Agonisingly slow" sounds bad. What exactly does `--enable-executable- dynamic` do? Does anyone have a theory about what's going on? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 08:20:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 08:20:16 -0000 Subject: [GHC] #15149: Identical distinct type family fields miscompiled In-Reply-To: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> References: <051.0ce70e3fb52ab219faaf194260ba75f3@haskell.org> Message-ID: <066.0e56c9351f1331f5b7bb66489fba4dc2@haskell.org> #15149: Identical distinct type family fields miscompiled -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: adamgundry Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: fixed | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | rename/should_compile/T15149 Blocked By: | Blocking: Related Tickets: #14747, #15277 | Differential Rev(s): Phab:D4821 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * status: patch => closed * resolution: => fixed * milestone: 8.8.1 => 8.6.1 Comment: This was fixed in 8.6.1, looks like the ticket missed being closed when the patch was merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 09:14:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 09:14:49 -0000 Subject: [GHC] #15528: Match is missing a Data instance Message-ID: <049.0ffe4cf92e233c0d90956e38238cf8be@haskell.org> #15528: Match is missing a Data instance -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I try to use `showAstData` on a `Match` then GHC complains that there is no Data instance. {{{ No instance for (Data (Expr.Match p (Expr.LHsExpr p))) }}} It seems that all the constituent parts of `Match` have a `Data` instance so `Match` should as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 09:18:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 09:18:39 -0000 Subject: [GHC] #15528: Match is missing a Data instance In-Reply-To: <049.0ffe4cf92e233c0d90956e38238cf8be@haskell.org> References: <049.0ffe4cf92e233c0d90956e38238cf8be@haskell.org> Message-ID: <064.4942d0abf00072334223eac6b72f9b5b@haskell.org> #15528: Match is missing a Data instance -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: invalid | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => invalid Comment: There is actually instances in `HsInstances` but only if `p` is instantiated to something specific. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 09:58:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 09:58:51 -0000 Subject: [GHC] #13753: Improve GHC's ghc package environment lookup logic In-Reply-To: <042.2a208789b5cdf0bbb17f300eaf094b7c@haskell.org> References: <042.2a208789b5cdf0bbb17f300eaf094b7c@haskell.org> Message-ID: <057.ca7e35fde86a1ed886c41e1ccae6bf4b@haskell.org> #13753: Improve GHC's ghc package environment lookup logic -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4690 Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): Just to clarify: Ben's [https://ghc.haskell.org/trac/ghc/ticket/13753#comment:10 latest comment] refers to the second part of the ticket, the [https://ghc.haskell.org/trac/ghc/ticket/13753#comment:9 `-package-env -` patch] will be in 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 10:00:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 10:00:00 -0000 Subject: [GHC] #15524: Performance regression when using the GHC API to evaluate code compared to 8.4 In-Reply-To: <051.53f38e3c9361ef8f17f16bc79295383b@haskell.org> References: <051.53f38e3c9361ef8f17f16bc79295383b@haskell.org> Message-ID: <066.2bdb4227a835db18b6e1fdb1382baefb@haskell.org> #15524: Performance regression when using the GHC API to evaluate code compared to 8.4 -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vaibhavsagar): To quantify, without `--enable-executable-dynamic` the test suite takes ~300s to run and with it enabled that time goes down to ~20s. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 10:05:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 10:05:32 -0000 Subject: [GHC] #15521: Provide a strict version of sum In-Reply-To: <047.f18d8bb60ade7fa2b84025003265a808@haskell.org> References: <047.f18d8bb60ade7fa2b84025003265a808@haskell.org> Message-ID: <062.bdddd0acccfd3a985c65df0f5b17c3d2@haskell.org> #15521: Provide a strict version of sum -------------------------------------+------------------------------------- Reporter: dnadales | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Prelude | 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 sjakobi): Adding a strict `sum'` function would fit well with the planned addition of `foldMap'` to `Foldable`: Phab:D4924 I don't think it's necessary to add `sum'` as `Foldable` method though: Just adding it as function to `Data.Foldable` should be good enough. An alternative implementation would be {{{ sum' = getSum #. foldMap' Sum }}} but I don't currently see any advantages to this version. Furthermore, if we add `sum'`, we should also add `product'` for consistency. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 10:22:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 10:22:57 -0000 Subject: [GHC] #15529: runtime bug when profiling retainers Message-ID: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> #15529: runtime bug when profiling retainers -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have this project https://github.com/flip111/ghc-runtime-bug1 When i execute the following commands: {{{ stack clean stack build stack build --ghc-options '-j4 -O0 -rtsopts=all -fprof-auto -fprof-auto- calls -fprof-cafs' --executable-profiling stack exec vfix -- +RTS -hr -sstderr }}} After the compilation messages i get the following error: {{{ vfix: internal error: Invalid object *c in pop() (GHC version 8.4.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Command terminated by signal 6 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 10:23:30 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 10:23:30 -0000 Subject: [GHC] #15520: Invalid warning Defined but not used In-Reply-To: <042.29f984e76dd90b968c6e3dfd2c14dbe7@haskell.org> References: <042.29f984e76dd90b968c6e3dfd2c14dbe7@haskell.org> Message-ID: <057.68474298c26c7c056d359ae9f3b5debc@haskell.org> #15520: Invalid warning Defined but not used -------------------------------------+------------------------------------- Reporter: rik | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rik): Sorry for the delay. Complete program: {{{#!hs {-# LANGUAGE NoImplicitPrelude #-} {-# LANGUAGE OverloadedStrings #-} module Test(exported) where import Protolude data U = Text :+++ Text x :: U x = "ss" :+++ "ss" exported :: Bool exported = True }}} Gives warnings: {{{ /Users/rik/siemens/autoencoder/src/Test.hs:7:10: warning: [-Wunused-top- binds] Defined but not used: data constructor ‘:+++’ | 7 | data U = Text :+++ Text | ^^^^^^^^^^^^^^ Test.hs:10:1: warning: [-Wunused-top-binds] Defined but not used: ‘x’ | 10 | x = "ss" :+++ "ss" | ^ Ok, one module loaded. }}} I understand from `x` but not from `:+++` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 10:36:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 10:36:55 -0000 Subject: [GHC] #15512: Rewrite rules should be able to produce custom compiler errors In-Reply-To: <047.49b395ff618a54610fa1944e1551b2dc@haskell.org> References: <047.49b395ff618a54610fa1944e1551b2dc@haskell.org> Message-ID: <062.25cb28549e972978160c7a220b498c5b@haskell.org> #15512: Rewrite rules should be able to produce custom compiler errors -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): You could rewrite {{{ forall x. length (cycle x) = error "length of cycle error" }}} but it would still be a run-time error, not a compile-time error. It's not clear how to achieve the latter. e.g. {{{ let v = length (cycle x) in if ... then ...v... else True }}} then `v` might never be evaluated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 10:59:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 10:59:17 -0000 Subject: [GHC] #15426: `elemIndex` and `findIndex` still can't fuse In-Reply-To: <045.556cc5a15fe7d0c4bec73444eba7ef79@haskell.org> References: <045.556cc5a15fe7d0c4bec73444eba7ef79@haskell.org> Message-ID: <060.5ea8b2b73dabb4b8fe5cca8c66402a85@haskell.org> #15426: `elemIndex` and `findIndex` still can't fuse -------------------------------------+------------------------------------- Reporter: kabuhr | Owner: kabuhr Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: libraries/base | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/perf/should_run/T15426.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D5063 -------------------------------------+------------------------------------- Comment (by simonpj): > The change resulted in a slight increase (3%) to memory usage for the cacheprof benchmark By "memory usage" do you mean "allocation"? A 3% increase in allocation is very strange, and worth understanding better. (I use `-ticky` for these kind of before-and-after comparisons.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 11:28:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 11:28:21 -0000 Subject: [GHC] #15520: Invalid warning Defined but not used In-Reply-To: <042.29f984e76dd90b968c6e3dfd2c14dbe7@haskell.org> References: <042.29f984e76dd90b968c6e3dfd2c14dbe7@haskell.org> Message-ID: <057.def5ef0ffad9eade2d91331acc3e9e31@haskell.org> #15520: Invalid warning Defined but not used -------------------------------------+------------------------------------- Reporter: rik | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rik): {{{ However, this is correct behavior, since x is not used anywhere (and therefore :+++ is transitively not used) }}} Okay, I see now, I'm confused. `x` is exported so GHC does not know if it is used outside this module, so why this warning? See also https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/using- warnings.html?highlight=unused-top-binds#ghc-flag--Wunused-top-binds {{{ A variable is regarded as “used” if It is exported, or It appears in the right hand side of a binding that binds at least one used variable that is used }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 11:30:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 11:30:01 -0000 Subject: [GHC] #15527: TypeApplications error message doesn't parenthesize infix name In-Reply-To: <050.477d5429b1a8f48b2e52c0542d2adea3@haskell.org> References: <050.477d5429b1a8f48b2e52c0542d2adea3@haskell.org> Message-ID: <065.5a64a073ee9d0883c1830734308c1b1c@haskell.org> #15527: TypeApplications error message doesn't parenthesize infix name -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5071 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"5238f204482ac7f05f4e2d2e92576288cc00d42d/ghc" 5238f204/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5238f204482ac7f05f4e2d2e92576288cc00d42d" Fix #15527 by pretty-printing an RdrName prefixly Summary: When `(.) @Int` is used without enabling `TypeApplications`, the resulting error message will pretty-print the (symbolic) `RdrName` `(.)`. However, it does so without parenthesizing it, which causes the pretty-printed expression to appear as `. at Int`. Yuck. Since the expression in a type application will always be prefix, we can fix this issue by using `pprPrefixOcc` instead of plain ol' `ppr`. Test Plan: make test TEST=T15527 Reviewers: bgamari, monoidal, simonpj Reviewed By: monoidal, simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15527 Differential Revision: https://phabricator.haskell.org/D5071 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 11:31:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 11:31:20 -0000 Subject: [GHC] #15520: Invalid warning Defined but not used In-Reply-To: <042.29f984e76dd90b968c6e3dfd2c14dbe7@haskell.org> References: <042.29f984e76dd90b968c6e3dfd2c14dbe7@haskell.org> Message-ID: <057.38c8491da4e679ac2a227a6bb1484035@haskell.org> #15520: Invalid warning Defined but not used -------------------------------------+------------------------------------- Reporter: rik | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rik): Okay, sorry, this issue can be closed. Sorry for wasting your time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 11:32:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 11:32:15 -0000 Subject: [GHC] #15520: Invalid warning Defined but not used In-Reply-To: <042.29f984e76dd90b968c6e3dfd2c14dbe7@haskell.org> References: <042.29f984e76dd90b968c6e3dfd2c14dbe7@haskell.org> Message-ID: <057.2f9ef48282bcf7089d98cf5b0a93d6b0@haskell.org> #15520: Invalid warning Defined but not used -------------------------------------+------------------------------------- Reporter: rik | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: infoneeded => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 11:32:45 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 11:32:45 -0000 Subject: [GHC] #15527: TypeApplications error message doesn't parenthesize infix name In-Reply-To: <050.477d5429b1a8f48b2e52c0542d2adea3@haskell.org> References: <050.477d5429b1a8f48b2e52c0542d2adea3@haskell.org> Message-ID: <065.e3f5cddff04b00f96ae6b6b483ea5d27@haskell.org> #15527: TypeApplications error message doesn't parenthesize infix name -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5071 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 12:53:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 12:53:41 -0000 Subject: [GHC] #15472: GHC HEAD type inference regression post-"Remove decideKindGeneralisationPlan" In-Reply-To: <050.060e4a1d545056b90564d103437d8ddb@haskell.org> References: <050.060e4a1d545056b90564d103437d8ddb@haskell.org> Message-ID: <065.8b301c588a8a2603215abc19067a9f78@haskell.org> #15472: GHC HEAD type inference regression post-"Remove decideKindGeneralisationPlan" -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: invalid | 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): Would it be possible to give a version of Richard's comment:2 for the nice small program in comment:7? In particular, why does ''more'' generalisation lead to a type error? I'm missing that vital point :-). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 14:30:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 14:30:59 -0000 Subject: [GHC] #15472: GHC HEAD type inference regression post-"Remove decideKindGeneralisationPlan" In-Reply-To: <050.060e4a1d545056b90564d103437d8ddb@haskell.org> References: <050.060e4a1d545056b90564d103437d8ddb@haskell.org> Message-ID: <065.218298706c44a9484560b3260f03e2ab@haskell.org> #15472: GHC HEAD type inference regression post-"Remove decideKindGeneralisationPlan" -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: invalid | 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 RyanGlScott): To see why the program in comment:7 is going awry, suppose the `sGo` function were defined at the top level: {{{#!hs sGo :: x -> Proxy LetGo sGo _ = foo }}} This will not kind-check, before or after the offending commit mentioned above. That's because we always kind-generalize for top-level definitions, so the return kind of `LetGo` will be generalized to `k`, which is too polymorphic for the RHS `foo` (which expects the return kind of `LetGo` to be `Type`). Now, if `sGo` is a locally defined function, as in comment:7: {{{#!hs sSconcat :: forall x. x sSconcat = undefined where sGo :: x -> Proxy LetGo sGo _ = foo }}} Before the offending commit, then the return kind of `LetGo` was //not// generalized, causing it to default to `Type`, which makes everything go through. After the offending commit, however, GHC now kind-generalizes local definitions, which means that the return kind of `LetGo` is now generalized to `k` again. In other words, `sGo` fails to kind-check for the same reasons that it would fail to kind-check if it were defined at the top level. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 15:00:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 15:00:24 -0000 Subject: [GHC] #15529: runtime bug when profiling retainers In-Reply-To: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> References: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> Message-ID: <061.89ec9586a620605a6975f5d1c35e7b5d@haskell.org> #15529: runtime bug when profiling retainers -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ugh, we really ought to be printing ought what closure types are tripping up these RTS panics. I've submitted Phab:D5072 to do so for `pop()` at least. With a version of GHC built with Phab:D5072 applied, if I try running `vfix +RTS -hr -sstderr`, then I get the following information: {{{ vfix: internal error: Invalid object *c in pop(): 62 (GHC version 8.7.20180816 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted (core dumped) }}} It looks like closure type 62 [http://git.haskell.org/ghc.git/blob/5238f204482ac7f05f4e2d2e92576288cc00d42d:/includes/rts/storage/ClosureTypes.h#l84 corresponds to] `SMALL_MUT_ARR_PTRS_FROZEN_CLEAN`. Any ideas there? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 15:21:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 15:21:08 -0000 Subject: [GHC] #15472: GHC HEAD type inference regression post-"Remove decideKindGeneralisationPlan" In-Reply-To: <050.060e4a1d545056b90564d103437d8ddb@haskell.org> References: <050.060e4a1d545056b90564d103437d8ddb@haskell.org> Message-ID: <065.af03be68a85544e8abb3dbd9733b9733@haskell.org> #15472: GHC HEAD type inference regression post-"Remove decideKindGeneralisationPlan" -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: invalid | 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): comment:10 makes perfect sense. Making a ''type'' signature more polymorphic than before may indeed make the ''term''-level declaration fail, since it isn't as polymorphic as the (new) signature requires. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 15:24:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 15:24:29 -0000 Subject: [GHC] #15453: Bug in opt_trans_rule in OptCoercion In-Reply-To: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> References: <047.ebcd4f0be6bf92772a8dd47ee04aca11@haskell.org> Message-ID: <062.5fa85535daa871e25b1ee33b4add995a@haskell.org> #15453: Bug in opt_trans_rule in OptCoercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5018 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm totally fine with adding the rules to core-spec. They are probably more likely to stay in sync if they are in the same document. But I hope that having the original paper and its Latex source will make the task significantly easier. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 15:27:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 15:27:10 -0000 Subject: [GHC] #15480: Rename SigTv In-Reply-To: <046.695d8e9aa6fe945eae6e4901e7dcaf7f@haskell.org> References: <046.695d8e9aa6fe945eae6e4901e7dcaf7f@haskell.org> Message-ID: <061.c0e4a066930f03f665c1fe9166a83bcc@haskell.org> #15480: Rename SigTv -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes.... `TyVarTv` is probably best. It doesn't get used much so being a bit longer doesn't matter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 16:10:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 16:10:10 -0000 Subject: [GHC] #15521: Provide a strict version of sum In-Reply-To: <047.f18d8bb60ade7fa2b84025003265a808@haskell.org> References: <047.f18d8bb60ade7fa2b84025003265a808@haskell.org> Message-ID: <062.36f2f08bfbb7c37f02f0d116a9ed932d@haskell.org> #15521: Provide a strict version of sum -------------------------------------+------------------------------------- Reporter: dnadales | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Prelude | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: core-libraries-committee@… (added) Comment: This is really something that needs to be through the Core Libraries Committee. See the [[https://wiki.haskell.org/Library_submissions|Haskell Wiki]] for details on the committee's proposal process. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 16:25:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 16:25:15 -0000 Subject: [GHC] #14917: Allow levity polymorphism in binding position In-Reply-To: <049.d67991f1b0cd65b675056d1b1f0986b9@haskell.org> References: <049.d67991f1b0cd65b675056d1b1f0986b9@haskell.org> Message-ID: <064.b90d96d3ede45a5fbe0dc847a609b866@haskell.org> #14917: Allow levity polymorphism in binding position -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ericson2314): Taking a step back, I think the first thing we need is a notion of a monomorphic term. A closed term is a monomorphic term, but sime open terwm are too. A term whose free variables are all irellevant is also a monomorphic term. This might seem counterintuitive and maybe I need a new name because of that, but it makes sense because we don't actually want to specialize on types: we just want to specialize on relevant things like runtime representations and constraint dictionaries. The second thing to note is that is that substitution preserves monomorphic-term-ness, so in some sense template polymorphism shouldn't be too hard. What I mean by preservation is that it that the body of an abstraction is a monomorphic term other than the free variable being replaced, and the substituted term is monomorphic, then the beta-reduced term is monnomorphic. The issue with polymorphic recursion is not that we can't make progress unlining, but that the partial evaluation may not terminate. For template polymorphism, I think annotations are sufficient. We want be able to force otherwise-optional specialization "deeply", and control where that request is undecidable vs where it is guaranteed to succeed or prevented from trying. The new quanitifers would be, as said, to require specialization, with the "infection" @goldfire points out that entails. Besides runtime reps, this is also needed for CLaSH, and intrinsics taking immediate values (as @carter told me about). Variables bound with such quantifiers would not penalize monnomorphic terms. That means the final definition of a monnomorphic term is one whose free variables are all irellevant or "monomorphizable". Lastly, I welcome the object file problems. As we said to @goldfire and @nomeata at an NYC Meetup, it's annoying that module organization, a convenience for humans, ends up affecting performance. We desperately want to cache compilation on as fine a granularity as possible, too. I hope tackling this inlining issue forces that caching one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 20:14:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 20:14:57 -0000 Subject: [GHC] #14813: EmptyCase thinks pattern match involving type family is not exhaustive, when it actually is In-Reply-To: <050.3962023f385f083f5f659edfe4ce01db@haskell.org> References: <050.3962023f385f083f5f659edfe4ce01db@haskell.org> Message-ID: <065.81667d2617f87ffcba3718ccc8e5b51c@haskell.org> #14813: EmptyCase thinks pattern match involving type family is not exhaustive, when it actually is -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Another example of this phenomenon: {{{#!hs {-# LANGUAGE EmptyCase #-} {-# LANGUAGE TypeFamilies #-} {-# OPTIONS_GHC -Wall #-} module Bug where import Data.Void type family F a type instance F Int = Void fun :: F Int -> a fun x = case x of }}} Compiling this program yields no warnings, as expected. However, if you factor out the `Int` part like so: {{{#!hs fun :: i ~ Int => F i -> a }}} Then it will yield a warning: {{{ $ /opt/ghc/8.4.3/bin/ghci Bug.hs GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:12:9: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: _ :: F i | 12 | fun x = case x of | ^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 22:43:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 22:43:05 -0000 Subject: [GHC] #15514: Older Trac ticket links redirect to this site, but not to the specific ticket In-Reply-To: <047.28955a11ad343c28afe5b086a77914a5@haskell.org> References: <047.28955a11ad343c28afe5b086a77914a5@haskell.org> Message-ID: <062.323c7d4ce8aa9e66f6b838936e41a862@haskell.org> #15514: Older Trac ticket links redirect to this site, but not to the specific ticket -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gbaz): Thanks for the ping. We'll try to fix this soon! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 22:44:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 22:44:27 -0000 Subject: [GHC] #15524: Performance regression when using the GHC API to evaluate code compared to 8.4 In-Reply-To: <051.53f38e3c9361ef8f17f16bc79295383b@haskell.org> References: <051.53f38e3c9361ef8f17f16bc79295383b@haskell.org> Message-ID: <066.de87af0d9e49dcedd2c24c8d288cc63c@haskell.org> #15524: Performance regression when using the GHC API to evaluate code compared to 8.4 -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by darchon): `--enable-executable-dynamic` is the Cabal flag to ensure that the resulting executable is dynamically linked against all (Haskell) libraries. Among other things, it ensures that GHC is called with `-dynamic` to produce the executable. By default, Cabal/GHC produces executables that are statically linked again (Haskell) libraries. N.B. For Clash, I've had to enable dynamic linking since GHC 8.2 in order not to incur the performance penalty mentioned in this ticket. Since GHC itself is also dynamically linked (at least it is on Linux) I was never too bothered with having to dynamically link the Clash executables. Anyhow, this makes me wonder if we were to statically link the GHC executable (on linux) whether GHC will incur the same performance overhead as us GHC API users. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 16 23:55:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Aug 2018 23:55:22 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.7962f0c53da2d3532421a57ddafc87f8@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Re comment:83 1. I think that `InterestingVarFun` is `const True`, so it only adds overhead. 2. I think you mean that `NDFV` keeps a set of forall-bound variables, and checks in that set before adding to the accumulator. But foralls are rare (I think), so the set will typically be empty. 3. That leaves the accumulator-style as the main candidate. As Richard says, though, the way to find out is to try it one thing at a time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 00:20:49 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 00:20:49 -0000 Subject: [GHC] #15480: Rename SigTv In-Reply-To: <046.695d8e9aa6fe945eae6e4901e7dcaf7f@haskell.org> References: <046.695d8e9aa6fe945eae6e4901e7dcaf7f@haskell.org> Message-ID: <061.e7d4b569aaa35df7d82e118b3587c73d@haskell.org> #15480: Rename SigTv -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5074 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D5074 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 01:38:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 01:38:58 -0000 Subject: [GHC] #13165: Speed up the RTS hash table In-Reply-To: <047.5597063b110123c6100b4b707918365d@haskell.org> References: <047.5597063b110123c6100b4b707918365d@haskell.org> Message-ID: <062.568938aee8723d7670e82348217d8245@haskell.org> #13165: Speed up the RTS hash table -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NoidedSuper): Well, I attempted an implementation at [https://phabricator.haskell.org/D5073], but sadly the test suite seems to break when you run the check (although just building, compiling, and running was working fine). I haven't had the chance to look too much at it but I'm guessing I have a problem with either deleting or mapping over hash tables. I'll work on it some more tomorrow, see if I can fix it. Of course, help is always appreciated! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 03:08:13 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 03:08:13 -0000 Subject: [GHC] #8944: Warn instead of stopping on misplaced Haddock comments In-Reply-To: <047.5551abebc2213482bde9e949bb62029b@haskell.org> References: <047.5551abebc2213482bde9e949bb62029b@haskell.org> Message-ID: <062.2dc633b5d98d3a2ae110f26a4adb8543@haskell.org> #8944: Warn instead of stopping on misplaced Haddock comments -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.9 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D452, Wiki Page: | Phab:D5057 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: Phab:D452 => Phab:D452, Phab:D5057 Comment: Patch by harpocrates in Phab:D5057. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 03:59:30 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 03:59:30 -0000 Subject: [GHC] #15480: Rename SigTv In-Reply-To: <046.695d8e9aa6fe945eae6e4901e7dcaf7f@haskell.org> References: <046.695d8e9aa6fe945eae6e4901e7dcaf7f@haskell.org> Message-ID: <061.93d9346bd2a17505a19f2b83b189a989@haskell.org> #15480: Rename SigTv -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5074 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"a50244c6a87176a4df8d41e6a1a3f102ba129032/ghc" a50244c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a50244c6a87176a4df8d41e6a1a3f102ba129032" Rename SigTv to TyVarTv (#15480) because since #15050, these are no longer used in pattern SIGnatures, but still in other places where meta-variables should only be unified with TYpe VARiables. I also found mentions of `SigTv` in parts of the renamer and desugarer that do not seem to directly relate to `SigTv` as used in the type checker, but rather to uses of `forall a.` in type signatures. I renamed these to `ScopedTv`. Differential Revision: https://phabricator.haskell.org/D5074 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 03:59:30 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 03:59:30 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs In-Reply-To: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> References: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> Message-ID: <061.1dc825c8e6d36899bc9523757a4c1275@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4980 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"a50244c6a87176a4df8d41e6a1a3f102ba129032/ghc" a50244c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a50244c6a87176a4df8d41e6a1a3f102ba129032" Rename SigTv to TyVarTv (#15480) because since #15050, these are no longer used in pattern SIGnatures, but still in other places where meta-variables should only be unified with TYpe VARiables. I also found mentions of `SigTv` in parts of the renamer and desugarer that do not seem to directly relate to `SigTv` as used in the type checker, but rather to uses of `forall a.` in type signatures. I renamed these to `ScopedTv`. Differential Revision: https://phabricator.haskell.org/D5074 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 04:00:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 04:00:22 -0000 Subject: [GHC] #15480: Rename SigTv In-Reply-To: <046.695d8e9aa6fe945eae6e4901e7dcaf7f@haskell.org> References: <046.695d8e9aa6fe945eae6e4901e7dcaf7f@haskell.org> Message-ID: <061.df0bc06f9be75a6a5118f14cdca95cea@haskell.org> #15480: Rename SigTv -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.5 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:D5074 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 04:44:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 04:44:35 -0000 Subject: [GHC] #15530: Type applications in patterns Message-ID: <046.ac75a1c05d26e58243b1cc5f1128ff00@haskell.org> #15530: Type applications in patterns -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The Type applications in pattern proposal was accepted: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0031 -type-applications-in-patterns.rst This ticket tracks its implementation. I am tempted to give it a shot, to learn more about the type checker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 08:00:29 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 08:00:29 -0000 Subject: [GHC] #14813: EmptyCase thinks pattern match involving type family is not exhaustive, when it actually is In-Reply-To: <050.3962023f385f083f5f659edfe4ce01db@haskell.org> References: <050.3962023f385f083f5f659edfe4ce01db@haskell.org> Message-ID: <065.1fa592989ae56ab2941046579ca772bb@haskell.org> #14813: EmptyCase thinks pattern match involving type family is not exhaustive, when it actually is -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK I undersatand now. My question in comment:3 was after reading comment:2. But comment:1 makes it clear why we want to improve `inhabitationCandidates`. Essentially you want to normalise a type using both top-level instances ''and'' local equalities. The constraint solver does this all the time, so the Right Thing is probably just to expose a new API to the constraint solver, alongside `tcCheckSatisfiability`. Something like {{{ tcNormalise :: Bag EvVar -> Type -> TcM Type }}} How would it work? A bit like `tcCheckSatisfiability`, except that after the `solveGivens` call `solveWanteds` passing a single `CHoleCan` constraint. It is not "solved", but it ''is'' normalised. So the `solveWanteds` will return a `CHoleCan` whose type is the desired normalised one. For efficiency, you might want to do a quick check before invoking `tcNormalise`, in case the type is ''already'' an algebraic data type (a common case), in which case normalisation will be a no-op. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 08:17:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 08:17:58 -0000 Subject: [GHC] #14917: Allow levity polymorphism in binding position In-Reply-To: <049.d67991f1b0cd65b675056d1b1f0986b9@haskell.org> References: <049.d67991f1b0cd65b675056d1b1f0986b9@haskell.org> Message-ID: <064.934307444c6ddb8106f863ece80b2f05@haskell.org> #14917: Allow levity polymorphism in binding position -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Richard says ''This means that, with your id definition, you couldn't have'' {{{ idList :: forall a. [a] -> [a] idList = id }}} Yes you could! `idList` is parameterised over a normal always-boxed type variable, so all its calls will be at boxed types. So `idList` can call the boxed-a version of `id`. Easy! Template polymorphism is not infectious. On the contrary, you have to keep specifying it for each enclosing function. It's a bit tiresome to have to do this -- it'd be easier for the programmer to say that ''all'' polymorphism can be specialised in this way, as .NET does -- but I think that's out of reach for us. > Generally, these schemes fail on polymorphic recursion, and I think we should do so here, too. I don't think so. For `f :: V r. forall (a :: TYPE r). blah` we need one version of `f` per instantation of `r`. And there are only a finite number of possiblities for `r` (boxed pointer, unboxed-32-bit, unboxed-64-bit, etc). If a function is template-polymorphic in N `RuntimeRep` parameters, then you could get a number of versions exponential in N, but that's very pathological. > Under your "no variables" rule, this List type would have to be specialized at every possible data parameter. I'm worried about bloat. I agree. I don't understand this no-variable business. Just one specialisation per variant of the `RuntimeRep` parameter(s). > In the end, I think we'd have to implement some deduplication algorithm during linking We already have this problem with specialisation. Suppose you say {{{ module Lib where f = bah f :: Num a => a -> a {-# INLINABLE f #-} module A where { import Lib; foo = f :: Int -> Int } module B where { import Lib; bar = f :: Int -> Int } module C where { import Lib; import A; bax = f :: Int -> Int } }}} Then A and B will independently generate a duplicate version of `f` specialised for `Int -> Int`. But C will not, because it can use the specialised version it "sees" from A. So far no one has reported unacceptable bloat. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 10:59:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 10:59:58 -0000 Subject: [GHC] #15493: Elide empty dictionaries In-Reply-To: <046.11d72f5ab1e49faf4e242eab224c7a9c@haskell.org> References: <046.11d72f5ab1e49faf4e242eab224c7a9c@haskell.org> Message-ID: <061.cee0731fb16e92069d1dde7649cff7b4@haskell.org> #15493: Elide empty dictionaries -------------------------------------+------------------------------------- Reporter: mnoonan | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): In Core, an empty dictionary turns into a dead variable, which is optimised away (with `-O` anyway). But it'll still take up a field in `FPack1`. Reason: it might be bottom. I'd be surprised if you found any appreciable performance impact. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 11:02:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 11:02:50 -0000 Subject: [GHC] #15220: ScopedTypeVariables binds a non-existent variable In-Reply-To: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> References: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> Message-ID: <062.4d318507698f1779cc83d0fb83d4b9f3@haskell.org> #15220: ScopedTypeVariables binds a non-existent variable -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > We should still make sure we never zonk a SigTv to Any, so we can't close quite yet. Why should we make sure of that? We allow `length []` to elaborate to `length @Any ([] @Any)`. I don't see what `SigTv` has to do with it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 11:32:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 11:32:32 -0000 Subject: [GHC] #15531: CApiFFI generates bad prototypes for pointers of `Foreign.C` types Message-ID: <042.811512d96a2763ac70925b9387baa494@haskell.org> #15531: CApiFFI generates bad prototypes for pointers of `Foreign.C` types -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the example {{{#!hs {-# LANGUAGE CApiFFI #-} module Foo where import Foreign.Ptr import Foreign.C foreign import capi unsafe "foo.h fn1" c_fn1 :: Char -> IO Char foreign import capi unsafe "foo.h fn2" c_fn2 :: Ptr Char -> IO (Ptr Char) foreign import capi unsafe "foo.h fn3" c_fn3 :: Ptr (Ptr Char) -> IO (Ptr (Ptr Char)) foreign import capi unsafe "foo.h fn4" c_fn4 :: CChar -> IO CChar foreign import capi unsafe "foo.h fn5" c_fn5 :: Ptr CChar -> IO (Ptr CChar) foreign import capi unsafe "foo.h fn6" c_fn6 :: Ptr (Ptr CChar) -> IO (Ptr (Ptr CChar)) foreign import capi unsafe "foo.h fn7" c_fn7 :: CUChar -> CSChar -> CShort -> CUShort -> CInt -> CUInt -> CLong -> CULong -> CSize -> IO () foreign import capi unsafe "foo.h fn8" c_fn8 :: Ptr CUChar -> Ptr CSChar -> Ptr CShort -> Ptr CUShort -> Ptr CInt -> Ptr CUInt -> Ptr CLong -> Ptr CULong -> Ptr CSize -> IO () }}} which creates various wrappers; this generates the C wrapper {{{#!c #define IN_STG_CODE 0 #include "Rts.h" #include "Stg.h" #ifdef __cplusplus extern "C" { #endif #include "foo.h" void ghczuwrapperZC0ZCmainZCFooZCfn8(void* a1, void* a2, void* a3, void* a4, void* a5, void* a6, void* a7, void* a8, void* a9) {fn8(a1, a2, a3, a4, a5, a6, a7, a8, a9);} #include "foo.h" void ghczuwrapperZC1ZCmainZCFooZCfn7(HsWord8 a1, HsInt8 a2, HsInt16 a3, HsWord16 a4, HsInt32 a5, HsWord32 a6, HsInt64 a7, HsWord64 a8, HsWord64 a9) {fn7(a1, a2, a3, a4, a5, a6, a7, a8, a9);} #include "foo.h" void** ghczuwrapperZC2ZCmainZCFooZCfn6(void** a1) {return fn6(a1);} #include "foo.h" void* ghczuwrapperZC3ZCmainZCFooZCfn5(void* a1) {return fn5(a1);} #include "foo.h" HsInt8 ghczuwrapperZC4ZCmainZCFooZCfn4(HsInt8 a1) {return fn4(a1);} #include "foo.h" HsChar** ghczuwrapperZC5ZCmainZCFooZCfn3(HsChar** a1) {return fn3(a1);} #include "foo.h" HsChar* ghczuwrapperZC6ZCmainZCFooZCfn2(HsChar* a1) {return fn2(a1);} #include "foo.h" HsChar ghczuwrapperZC7ZCmainZCFooZCfn1(HsChar a1) {return fn1(a1);} #ifdef __cplusplus } #endif }}} Specifically, the wrappers for `c_fn4`, `c_fn5` and `c_fn8` are wrong. This is quite a serious bug as it renders `CApiFFI` unusable for matching with C prototypes, as modern C compilers will refuse to coerce a pointer `void**` into an argument to a function expecting a `char**`. One concrete example is e.g. {{{#!hs -- int getfilecon(const char *path, char **con); foreign import capi safe "selinux/selinux.h getfilecon" c_getfilecon' :: CString -> Ptr CString -> IO CInt }}} which even though properly declared (NB: `type CString = Ptr CChar`), when compiled would fail because of this bug: {{{ tmpdir/ghc31009_0/ghc_2.c: In function ‘ghczuwrapperZC0ZCmainZCBarZCgetfilecon’: tmpdir/ghc31009_0/ghc_2.c:8:92: error: warning: passing argument 2 of ‘getfilecon’ from incompatible pointer type [-Wincompatible-pointer-types] HsInt32 ghczuwrapperZC0ZCmainZCBarZCgetfilecon(void* a1, void** a2) {return getfilecon(a1, a2);} ^ | 8 | HsInt32 ghczuwrapperZC0ZCmainZCBarZCgetfilecon(void* a1, void** a2) {return getfilecon(a1, a2);} | ^ In file included from tmpdir/ghc31009_0/ghc_2.c:7:0: error: /usr/include/selinux/selinux.h:101:12: error: note: expected ‘char **’ but argument is of type ‘void **’ extern int getfilecon(const char *path, char ** con); ^ | 101 | extern int getfilecon(const char *path, char ** con); | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 11:35:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 11:35:20 -0000 Subject: [GHC] #15531: CApiFFI generates bad prototypes for pointers of `Foreign.C` types In-Reply-To: <042.811512d96a2763ac70925b9387baa494@haskell.org> References: <042.811512d96a2763ac70925b9387baa494@haskell.org> Message-ID: <057.5830ec7681a3e50492aab7bdc6856935@haskell.org> #15531: CApiFFI generates bad prototypes for pointers of `Foreign.C` types -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by hvr: Old description: > Consider the example > > {{{#!hs > {-# LANGUAGE CApiFFI #-} > > module Foo where > > import Foreign.Ptr > import Foreign.C > > foreign import capi unsafe "foo.h fn1" c_fn1 :: Char -> IO Char > > foreign import capi unsafe "foo.h fn2" c_fn2 :: Ptr Char -> IO (Ptr Char) > > foreign import capi unsafe "foo.h fn3" c_fn3 :: Ptr (Ptr Char) -> IO (Ptr > (Ptr Char)) > > foreign import capi unsafe "foo.h fn4" c_fn4 :: CChar -> IO CChar > > foreign import capi unsafe "foo.h fn5" c_fn5 :: Ptr CChar -> IO (Ptr > CChar) > > foreign import capi unsafe "foo.h fn6" c_fn6 :: Ptr (Ptr CChar) -> IO > (Ptr (Ptr CChar)) > > foreign import capi unsafe "foo.h fn7" c_fn7 :: CUChar -> CSChar -> > CShort -> CUShort -> CInt -> CUInt -> CLong -> CULong -> CSize -> IO () > > foreign import capi unsafe "foo.h fn8" c_fn8 :: Ptr CUChar -> Ptr CSChar > -> Ptr CShort -> Ptr CUShort -> Ptr CInt -> Ptr CUInt -> Ptr CLong -> Ptr > CULong -> Ptr CSize -> IO () > }}} > > which creates various wrappers; this generates the C wrapper > > {{{#!c > > #define IN_STG_CODE 0 > #include "Rts.h" > #include "Stg.h" > #ifdef __cplusplus > extern "C" { > #endif > #include "foo.h" > void ghczuwrapperZC0ZCmainZCFooZCfn8(void* a1, void* a2, void* a3, void* > a4, void* a5, void* a6, void* a7, void* a8, void* a9) {fn8(a1, a2, a3, > a4, a5, a6, a7, a8, a9);} > #include "foo.h" > void ghczuwrapperZC1ZCmainZCFooZCfn7(HsWord8 a1, HsInt8 a2, HsInt16 a3, > HsWord16 a4, HsInt32 a5, HsWord32 a6, HsInt64 a7, HsWord64 a8, HsWord64 > a9) {fn7(a1, a2, a3, a4, a5, a6, a7, a8, a9);} > #include "foo.h" > void** ghczuwrapperZC2ZCmainZCFooZCfn6(void** a1) {return fn6(a1);} > #include "foo.h" > void* ghczuwrapperZC3ZCmainZCFooZCfn5(void* a1) {return fn5(a1);} > #include "foo.h" > HsInt8 ghczuwrapperZC4ZCmainZCFooZCfn4(HsInt8 a1) {return fn4(a1);} > #include "foo.h" > HsChar** ghczuwrapperZC5ZCmainZCFooZCfn3(HsChar** a1) {return fn3(a1);} > #include "foo.h" > HsChar* ghczuwrapperZC6ZCmainZCFooZCfn2(HsChar* a1) {return fn2(a1);} > #include "foo.h" > HsChar ghczuwrapperZC7ZCmainZCFooZCfn1(HsChar a1) {return fn1(a1);} > #ifdef __cplusplus > } > #endif > > }}} > > Specifically, the wrappers for `c_fn4`, `c_fn5` and `c_fn8` are wrong. > > This is quite a serious bug as it renders `CApiFFI` unusable for matching > with C prototypes, as modern C compilers will refuse to coerce a pointer > `void**` into an argument to a function expecting a `char**`. One > concrete example is e.g. > > {{{#!hs > -- int getfilecon(const char *path, char **con); > foreign import capi safe "selinux/selinux.h getfilecon" c_getfilecon' :: > CString -> Ptr CString -> IO CInt > > }}} > > which even though properly declared (NB: `type CString = Ptr CChar`), > when compiled would fail because of this bug: > > {{{ > tmpdir/ghc31009_0/ghc_2.c: In function > ‘ghczuwrapperZC0ZCmainZCBarZCgetfilecon’: > > tmpdir/ghc31009_0/ghc_2.c:8:92: error: > warning: passing argument 2 of ‘getfilecon’ from incompatible > pointer type [-Wincompatible-pointer-types] > HsInt32 ghczuwrapperZC0ZCmainZCBarZCgetfilecon(void* a1, void** a2) > {return getfilecon(a1, a2);} > ^ > | > 8 | HsInt32 ghczuwrapperZC0ZCmainZCBarZCgetfilecon(void* a1, void** a2) > {return getfilecon(a1, a2);} > | > ^ > > In file included from tmpdir/ghc31009_0/ghc_2.c:7:0: error: > > /usr/include/selinux/selinux.h:101:12: error: > note: expected ‘char **’ but argument is of type ‘void **’ > extern int getfilecon(const char *path, char ** con); > ^ > | > 101 | extern int getfilecon(const char *path, char ** con); > | ^ > }}} New description: Consider the example {{{#!hs {-# LANGUAGE CApiFFI #-} module Foo where import Foreign.Ptr import Foreign.C foreign import capi unsafe "foo.h fn1" c_fn1 :: Char -> IO Char foreign import capi unsafe "foo.h fn2" c_fn2 :: Ptr Char -> IO (Ptr Char) foreign import capi unsafe "foo.h fn3" c_fn3 :: Ptr (Ptr Char) -> IO (Ptr (Ptr Char)) foreign import capi unsafe "foo.h fn4" c_fn4 :: CChar -> IO CChar foreign import capi unsafe "foo.h fn5" c_fn5 :: Ptr CChar -> IO (Ptr CChar) foreign import capi unsafe "foo.h fn6" c_fn6 :: Ptr (Ptr CChar) -> IO (Ptr (Ptr CChar)) foreign import capi unsafe "foo.h fn7" c_fn7 :: CUChar -> CSChar -> CShort -> CUShort -> CInt -> CUInt -> CLong -> CULong -> CSize -> IO () foreign import capi unsafe "foo.h fn8" c_fn8 :: Ptr CUChar -> Ptr CSChar -> Ptr CShort -> Ptr CUShort -> Ptr CInt -> Ptr CUInt -> Ptr CLong -> Ptr CULong -> Ptr CSize -> IO () }}} which creates various wrappers; this generates the C wrapper {{{#!c #define IN_STG_CODE 0 #include "Rts.h" #include "Stg.h" #ifdef __cplusplus extern "C" { #endif #include "foo.h" void ghczuwrapperZC0ZCmainZCFooZCfn8(void* a1, void* a2, void* a3, void* a4, void* a5, void* a6, void* a7, void* a8, void* a9) {fn8(a1, a2, a3, a4, a5, a6, a7, a8, a9);} #include "foo.h" void ghczuwrapperZC1ZCmainZCFooZCfn7(HsWord8 a1, HsInt8 a2, HsInt16 a3, HsWord16 a4, HsInt32 a5, HsWord32 a6, HsInt64 a7, HsWord64 a8, HsWord64 a9) {fn7(a1, a2, a3, a4, a5, a6, a7, a8, a9);} #include "foo.h" void** ghczuwrapperZC2ZCmainZCFooZCfn6(void** a1) {return fn6(a1);} #include "foo.h" void* ghczuwrapperZC3ZCmainZCFooZCfn5(void* a1) {return fn5(a1);} #include "foo.h" HsInt8 ghczuwrapperZC4ZCmainZCFooZCfn4(HsInt8 a1) {return fn4(a1);} #include "foo.h" HsChar** ghczuwrapperZC5ZCmainZCFooZCfn3(HsChar** a1) {return fn3(a1);} #include "foo.h" HsChar* ghczuwrapperZC6ZCmainZCFooZCfn2(HsChar* a1) {return fn2(a1);} #include "foo.h" HsChar ghczuwrapperZC7ZCmainZCFooZCfn1(HsChar a1) {return fn1(a1);} #ifdef __cplusplus } #endif }}} Specifically, the wrappers for `c_fn5`, `c_fn6` and `c_fn8` are wrong. This is quite a serious bug as it renders `CApiFFI` unusable for matching with C prototypes, as modern C compilers will refuse to coerce a pointer `void**` into an argument to a function expecting a `char**`. One concrete example is e.g. {{{#!hs -- int getfilecon(const char *path, char **con); foreign import capi safe "selinux/selinux.h getfilecon" c_getfilecon' :: CString -> Ptr CString -> IO CInt }}} which even though properly declared (NB: `type CString = Ptr CChar`), when compiled would fail because of this bug: {{{ tmpdir/ghc31009_0/ghc_2.c: In function ‘ghczuwrapperZC0ZCmainZCBarZCgetfilecon’: tmpdir/ghc31009_0/ghc_2.c:8:92: error: warning: passing argument 2 of ‘getfilecon’ from incompatible pointer type [-Wincompatible-pointer-types] HsInt32 ghczuwrapperZC0ZCmainZCBarZCgetfilecon(void* a1, void** a2) {return getfilecon(a1, a2);} ^ | 8 | HsInt32 ghczuwrapperZC0ZCmainZCBarZCgetfilecon(void* a1, void** a2) {return getfilecon(a1, a2);} | ^ In file included from tmpdir/ghc31009_0/ghc_2.c:7:0: error: /usr/include/selinux/selinux.h:101:12: error: note: expected ‘char **’ but argument is of type ‘void **’ extern int getfilecon(const char *path, char ** con); ^ | 101 | extern int getfilecon(const char *path, char ** con); | ^ }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 11:48:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 11:48:27 -0000 Subject: [GHC] #15495: Handling Source Locations via TTG In-Reply-To: <050.b9166c5b755fb618e3ff0003339d26df@haskell.org> References: <050.b9166c5b755fb618e3ff0003339d26df@haskell.org> Message-ID: <065.1911139c321c8baa09cdbb81fa561da0@haskell.org> #15495: Handling Source Locations via TTG -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Branch `wip/az-D5036` I believe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 11:50:04 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 11:50:04 -0000 Subject: [GHC] #15495: Handling Source Locations via TTG In-Reply-To: <050.b9166c5b755fb618e3ff0003339d26df@haskell.org> References: <050.b9166c5b755fb618e3ff0003339d26df@haskell.org> Message-ID: <065.29bea85e40442135d81edb3fd6ed6025@haskell.org> #15495: Handling Source Locations via TTG -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): I am still looking for the haddock changes though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 13:33:29 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 13:33:29 -0000 Subject: [GHC] #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers Message-ID: <049.8be864d1afb4e700c16c6d8c545dbbfc@haskell.org> #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple LevityPolymorphism | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: 14917 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm going to define two terms that I will use with these meanings for the remainder of this post. 1. Runtime-Rep Polymorphism: full polymorphism in the runtime representation 2. Levity Polymorphism: polymorphism dealing with lifted vs unlifted types that are definitely represented by pointers. GHC's levity polymorphism has the restriction that runtime-rep-polymorphic binders are not allowed. A comment David made recently on https://github.com/haskell/primitive/issues/198 got me thinking about the possibility of relaxing this restriction when it comes to dealing with a function with levity-polymorphic (not runtime-rep-polymorphic) binders. GHC's runtime already appears to allow doing this. AndrasKovacs writes on https://www.reddit.com/r/haskell/comments/6v9rmg/an_unified_array_interface/dlyug4e/ that he is able to store both lifted and unlifted values inside of the same `Array#` (pointing out as well that their primop implementations are identical) without crashing the GC. As further evidence that we can, roughly speaking, use lifted and unlifted values in the same places, I threw together a little experiment: {{{ {-# LANGUAGE MagicHash #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeInType #-} import Data.Primitive import Data.Primitive.UnliftedArray import GHC.Types import GHC.Exts main :: IO () main = do a@(Array myArr) <- newArray 1 ("foo" :: String) >>= unsafeFreezeArray UnliftedArray myArrArr <- newUnliftedArray 1 a >>= unsafeFreezeUnliftedArray putStrLn (myFunc show (2 :: Integer)) putStrLn (myFunc2 (\x -> show (Array x)) myArr) putStrLn (myBigFunc (+1) show show (2 :: Integer)) putStrLn (myBigFunc2 (\x -> array# (indexUnliftedArray (UnliftedArray x) 0 :: Array String)) (\x -> show (Array x)) (\x -> show (UnliftedArray x :: UnliftedArray (Array String))) myArrArr) {-# NOINLINE myFunc #-} myFunc :: (a -> String) -> a -> String myFunc f a = let x = f a in x ++ x myFunc2 :: forall (a :: TYPE 'UnliftedRep). (a -> String) -> a -> String myFunc2 = unsafeCoerce# myFunc {-# NOINLINE myBigFunc #-} myBigFunc :: (a -> b) -> (b -> String) -> (a -> String) -> a -> String myBigFunc f g h a = let y = f a x = g y in x ++ x ++ h a myBigFunc2 :: forall (a :: TYPE 'UnliftedRep) (b :: TYPE 'UnliftedRep). (a -> b) -> (b -> String) -> (a -> String) -> a -> String myBigFunc2 = unsafeCoerce# myBigFunc }}} The compiles (surprisingly without a core lint error) and runs fine. So, here's the idea. We start with David's suggested change to `RuntimeRep`: {{{ data RuntimeRep = PtrRep Levity | ... data Levity = Lifted | Unlifted }}} And then we change the check that disallows runtime-rep polymorphism in binding positions to accept levity polymorphism in binding positions (but continuing to reject runtime-rep polymorphism). For example, the two examples in the above code snippet would be rewritten as: {{{ myFunc :: forall (v :: Levity) (a :: TYPE ('PtrRep v)). (a -> String) -> a -> String myFunc = ... -- same implementation myBigFunc :: forall (v :: Levity) (w :: Levity) (a :: TYPE ('PtrRep v)) (b :: TYPE ('PtrRep w)). (a -> b) -> (b -> String) -> (a -> String) -> a -> String myBigFunc = ... -- same implementation }}} Again, GHC's runtime seems to already allow this. It's just the type system that's missing support for it. The only weird thing I can think of that comes up is that you cannot use bang patterns on a levity-polymorphic argument since unlifted values cannot be entered. I think it is possible to go a little further still. Fields of data types could be levity polymorphic: {{{ data List (a :: TYPE ('PtrRep v)) = Cons a (List a) | Nil map :: forall (v :: Levity) (w :: Levity) (a :: TYPE ('PtrRep v)) (b :: TYPE ('PtrRep w)). (a -> b) -> List a -> List b }}} Again, bang patterns would need to be forbidden on such fields. This doesn't get us everything sought out in https://ghc.haskell.org/trac/ghc/wiki/UnliftedDataTypes, but it's kind of a half-way point that requires no changes to GHC's runtime and no changes to code generation. I think the whole thing can be handled in the type checker. Other potential application: `Array#` and `ArrayArray#` (and nearly all functions that operate on them) could be consolidated into a single type, reducing the number of duplicated primop implementations in GHC. Of course this would all need to be a GHC proposal, but I wanted to first solicit some feedback here on initial draft of the idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 14:12:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 14:12:53 -0000 Subject: [GHC] #15457: (~) and (!) are parsed inconsistently in types (plus documentation warts) In-Reply-To: <050.bc8c0ec5a857afbbf6fcb9729be2d57e@haskell.org> References: <050.bc8c0ec5a857afbbf6fcb9729be2d57e@haskell.org> Message-ID: <065.ea8c1b69cb506b3dbdeddf95a5507eed@haskell.org> #15457: (~) and (!) are parsed inconsistently in types (plus documentation warts) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => new * differential: Phab:D5023 => Comment: The approach in Phab:D5023 isn't quite up to snuff, since it leaves some scenarios where `!` isn't parsed in a precedence-aware fashion (see https://phabricator.haskell.org/D5023#139341). To handle that situation correctly, we'd need to implement something skin to the plan laid out in https://phabricator.haskell.org/D5023#139245. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 14:23:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 14:23:47 -0000 Subject: [GHC] #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers In-Reply-To: <049.8be864d1afb4e700c16c6d8c545dbbfc@haskell.org> References: <049.8be864d1afb4e700c16c6d8c545dbbfc@haskell.org> Message-ID: <064.132b3686f0c2f5a787a98915395feee7@haskell.org> #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 14917 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Lifted types are lazy, unlifted ones are strict. See `Type.isUnliftedType`. So code that is polymorphic in levity might build a thunk for an unlifted value, which the consumer won't expect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 14:27:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 14:27:52 -0000 Subject: [GHC] #15457: (~) and (!) are parsed inconsistently in types (plus documentation warts) In-Reply-To: <050.bc8c0ec5a857afbbf6fcb9729be2d57e@haskell.org> References: <050.bc8c0ec5a857afbbf6fcb9729be2d57e@haskell.org> Message-ID: <065.fdc189179e7712e7a9c4432dfda74dd9@haskell.org> #15457: (~) and (!) are parsed inconsistently in types (plus documentation warts) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: int-index Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * owner: (none) => int-index -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 14:30:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 14:30:59 -0000 Subject: [GHC] #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers In-Reply-To: <049.8be864d1afb4e700c16c6d8c545dbbfc@haskell.org> References: <049.8be864d1afb4e700c16c6d8c545dbbfc@haskell.org> Message-ID: <064.e05d5866e5e50706ca86a70e06522a1b@haskell.org> #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 14917 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): > code that is polymorphic in levity might build a thunk for an unlifted value I thought that this may happen, but I cannot actually get the GHC runtime to exhibit this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 14:50:39 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 14:50:39 -0000 Subject: [GHC] #15524: Performance regression when using the GHC API to evaluate code compared to 8.4 In-Reply-To: <051.53f38e3c9361ef8f17f16bc79295383b@haskell.org> References: <051.53f38e3c9361ef8f17f16bc79295383b@haskell.org> Message-ID: <066.2139542e426e52d796f6e2adf556c0bc@haskell.org> #15524: Performance regression when using the GHC API to evaluate code compared to 8.4 -------------------------------------+------------------------------------- Reporter: vaibhavsagar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This is quite interesting; it would be helpful if someone could paste a few backtraces from GDB (or perf a `perf` profile). If anything I would expect dynamic linking to make things slightly slower, not faster. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 14:54:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 14:54:45 -0000 Subject: [GHC] #15529: runtime bug when profiling retainers In-Reply-To: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> References: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> Message-ID: <061.9c1a0060e02e66b1b4262dd53ffd0bc5@haskell.org> #15529: runtime bug when profiling retainers -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 14:58:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 14:58:15 -0000 Subject: [GHC] #15529: runtime bug when profiling retainers In-Reply-To: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> References: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> Message-ID: <061.64e64236e630ae712a6e573545a538d3@haskell.org> #15529: runtime bug when profiling retainers -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5075 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D5075 Comment: I believe this should do it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 15:03:38 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 15:03:38 -0000 Subject: [GHC] #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers In-Reply-To: <049.8be864d1afb4e700c16c6d8c545dbbfc@haskell.org> References: <049.8be864d1afb4e700c16c6d8c545dbbfc@haskell.org> Message-ID: <064.4a051c2b4ee7677efeacb1aa804fa973@haskell.org> #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 14917 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): This example also works: {{{ {-# LANGUAGE BangPatterns #-} {-# LANGUAGE MagicHash #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE UnboxedTuples #-} {-# LANGUAGE TypeInType #-} import Data.Primitive import Data.Primitive.UnliftedArray import GHC.Types import GHC.Exts main :: IO () main = do a@(Array myArr) <- newArray 1 ("foo" :: String) >>= unsafeFreezeArray UnliftedArray myArrArr <- newUnliftedArray 1 a >>= unsafeFreezeUnliftedArray putStrLn (example even show (show . (+1)) (5 :: Integer)) let r = exampleUnlifted (\x -> isTrue# (sizeofArrayArray# x ># 1#)) (\x -> array# (indexUnliftedArray (UnliftedArray x) 1 :: Array String)) (\x -> array# (indexUnliftedArray (UnliftedArray x) 0 :: Array String)) myArrArr !(# e #) = indexArray# r 0# putStrLn e {-# NOINLINE example #-} example :: (a -> Bool) -> (a -> b) -> (a -> b) -> a -> b example p f g a = if p a then f a else g a exampleUnlifted :: forall (a :: TYPE 'UnliftedRep) (b :: TYPE 'UnliftedRep). (a -> Bool) -> (a -> b) -> (a -> b) -> a -> b exampleUnlifted = unsafeCoerce# example }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 15:09:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 15:09:59 -0000 Subject: [GHC] #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers In-Reply-To: <049.8be864d1afb4e700c16c6d8c545dbbfc@haskell.org> References: <049.8be864d1afb4e700c16c6d8c545dbbfc@haskell.org> Message-ID: <064.67609584b5df09f17716b472fac39e31@haskell.org> #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 14917 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): RR-polymorphism (runtime-rep-polymorphism) actually has two different restrictions: we disallow RR-polymorphic binders and we also disallow RR- polymorphic function arguments. Your argument might hold water to lift the binder restriction, but I think we'll need to keep the function-argument restriction to avoid confusion around laziness. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 15:17:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 15:17:16 -0000 Subject: [GHC] #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers In-Reply-To: <049.8be864d1afb4e700c16c6d8c545dbbfc@haskell.org> References: <049.8be864d1afb4e700c16c6d8c545dbbfc@haskell.org> Message-ID: <064.b049bd2e33d5bda7fadecc94989d46fb@haskell.org> #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 14917 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): > I think we'll need to keep the function-argument restriction to avoid confusion around laziness When you say "confusion around laziness", are you referring to difficulty the user would have with reasoning about the behavior of a functions, or are you referring to an inability of GHC to generate correct code in this situation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 15:34:30 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 15:34:30 -0000 Subject: [GHC] #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers In-Reply-To: <049.8be864d1afb4e700c16c6d8c545dbbfc@haskell.org> References: <049.8be864d1afb4e700c16c6d8c545dbbfc@haskell.org> Message-ID: <064.01b09af61d0f5ca564830633645fc1bf@haskell.org> #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 14917 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The latter. GHC needs to know whether a function should be call-by-need or call-by-value. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 15:35:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 15:35:50 -0000 Subject: [GHC] #15220: ScopedTypeVariables binds a non-existent variable In-Reply-To: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> References: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> Message-ID: <062.7a5f7ad9bb1ccfb9e7f11c68639cdec2@haskell.org> #15220: ScopedTypeVariables binds a non-existent variable -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The semantics of `TyVarTv` (né `SigTv`) state that a `TyVarTv` unifies only with another variable. `Any` is not a variable, and so a `TyVarTv` should not unify to it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 15:43:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 15:43:52 -0000 Subject: [GHC] #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers In-Reply-To: <049.8be864d1afb4e700c16c6d8c545dbbfc@haskell.org> References: <049.8be864d1afb4e700c16c6d8c545dbbfc@haskell.org> Message-ID: <064.4dc23ebdb423ecb58f6485d0db02788c@haskell.org> #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 14917 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): In that case, I should be able to write a function like `exampleUnlifted` (but possibly more complicated) that will segfault. I'll see if I can come up with something. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 15:45:00 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 15:45:00 -0000 Subject: [GHC] #15220: ScopedTypeVariables binds a non-existent variable In-Reply-To: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> References: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> Message-ID: <062.39ef0244c5f7809b39ec64306ba804bf@haskell.org> #15220: ScopedTypeVariables binds a non-existent variable -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Hmm. What should happen to an unbound `TyVarTv` unification variable then? The presenting problem was with the old `SigTv`, when a scoped type variable could only be bound to a variable. But we've changed that now - they are `TauTv`s. I'm unsure about exactly how the remaining uses of `TyVarTv` work and whether this issue will arise at all. I suspect that it will not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 15:48:24 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 15:48:24 -0000 Subject: [GHC] #15499: Panic in occurence analysis phase (?), getRuntimeRep In-Reply-To: <048.4ced706f36b918299fae10c865c8eddf@haskell.org> References: <048.4ced706f36b918299fae10c865c8eddf@haskell.org> Message-ID: <063.f3c0643cd42a00e04fa06e669a0c0cfc@haskell.org> #15499: Panic in occurence analysis phase (?), getRuntimeRep -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: RyanGlScott Type: bug | Status: patch Priority: high | Milestone: 8.4.4 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5060 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"63b6a1d44849c479d2a7cb59211f5c64d133bc62/ghc" 63b6a1d4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="63b6a1d44849c479d2a7cb59211f5c64d133bc62" Be mindful of GADT tyvar order when desugaring record updates Summary: After commit ef26182e2014b0a2a029ae466a4b121bf235e4e4, the type variable binders in GADT constructor type signatures are now quantified in toposorted order, instead of always having all the universals before all the existentials. Unfortunately, that commit forgot to update some code (which was assuming the latter scenario) in `DsExpr` which desugars record updates. This wound up being the cause of #15499. This patch makes up for lost time by desugaring record updates in a way such that the desugared expression applies type arguments to the right-hand side constructor in the correct order—that is, the order in which they were quantified by the user. Test Plan: make test TEST=T15499 Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15499 Differential Revision: https://phabricator.haskell.org/D5060 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 15:49:41 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 15:49:41 -0000 Subject: [GHC] #15499: Panic in occurence analysis phase (?), getRuntimeRep In-Reply-To: <048.4ced706f36b918299fae10c865c8eddf@haskell.org> References: <048.4ced706f36b918299fae10c865c8eddf@haskell.org> Message-ID: <063.353198fdb5341963e9199b19a89730d2@haskell.org> #15499: Panic in occurence analysis phase (?), getRuntimeRep -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: RyanGlScott Type: bug | Status: merge Priority: high | Milestone: 8.4.4 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5060 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 15:54:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 15:54:45 -0000 Subject: [GHC] #15220: ScopedTypeVariables binds a non-existent variable In-Reply-To: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> References: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> Message-ID: <062.dc13a3e3d479e0fba4f5a6b315602d69@haskell.org> #15220: ScopedTypeVariables binds a non-existent variable -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I agree with your suspicion -- all I'm saying is that we should check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 16:10:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 16:10:14 -0000 Subject: [GHC] #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers In-Reply-To: <049.8be864d1afb4e700c16c6d8c545dbbfc@haskell.org> References: <049.8be864d1afb4e700c16c6d8c545dbbfc@haskell.org> Message-ID: <064.8af5dd24d5cf83a29f7e97430db438ae@haskell.org> #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 14917 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): We can get a crash if we instead write `example` as: {{{ example :: (a -> Bool) -> (a -> a) -> (a -> b) -> (a -> b) -> a -> b example p k f g a = if p a then f (k (k a)) else g (k a) }}} This fails at runtime with: {{{ internal error: MUT_ARR_PTRS_FROZEN0 object entered! }}} Thanks for helping me see what I was missing. So GHC couldn't possibly generate code for the definition I gave for the levity-polymorphic `map` function given in the original issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 16:17:31 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 16:17:31 -0000 Subject: [GHC] #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers In-Reply-To: <049.8be864d1afb4e700c16c6d8c545dbbfc@haskell.org> References: <049.8be864d1afb4e700c16c6d8c545dbbfc@haskell.org> Message-ID: <064.191b54f2631c704cf4695dcff7fcd084@haskell.org> #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 14917 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): Dang. That means that levity-polymorphic fields in data constructors won't work either. That takes away most of the utility I hoped this would provide. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 16:19:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 16:19:58 -0000 Subject: [GHC] #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers In-Reply-To: <049.8be864d1afb4e700c16c6d8c545dbbfc@haskell.org> References: <049.8be864d1afb4e700c16c6d8c545dbbfc@haskell.org> Message-ID: <064.cc5d6ffe449cb97d2e6fba187a15ccbb@haskell.org> #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 14917 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): If the levity were retained at runtime (that is, we use a singleton levity), then it is reasonable to case on the levity when deciding whether to be call-by-name or call-by-value. For functions, this could be arranged today via a type-class construction. Not sure how to do it for data constructors, but it's conceivable to add such a thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 16:47:46 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 16:47:46 -0000 Subject: [GHC] #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers In-Reply-To: <049.8be864d1afb4e700c16c6d8c545dbbfc@haskell.org> References: <049.8be864d1afb4e700c16c6d8c545dbbfc@haskell.org> Message-ID: <064.5e64ada17321cb8c64e847a52c7de869@haskell.org> #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 14917 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): The singleton levity trick would work, but it seems a little disappointing that users would need to take a (admittedly small) performance hit to get this extra polymorphism. I retract part of my claim about levity polymorphic data constructors. Here is what would be possible/impossible without any changes to GHC's codegen and runtime: - Defining levity-polymorphic fields in data construtors. YES - Constructing a value with such a data constructor where the levity is monomorphic. YES - Constructing a value with such a data constructor where the levity is polymorphic. NO - Casing on such a value in a levity-monomorphic or levity-polymorphic settings. YES This feels consistent with your earlier claim about the binder rule being relaxable but the function argument rule not being relaxable. Casing on a data constructor introduces a binder but applying a data constructor is applying a function. However, casing on a data constructor to get out a levity polymorphic field still isn't particularly useful, since there is basically nothing interesting you can do with the value at that point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 16:52:17 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 16:52:17 -0000 Subject: [GHC] #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers In-Reply-To: <049.8be864d1afb4e700c16c6d8c545dbbfc@haskell.org> References: <049.8be864d1afb4e700c16c6d8c545dbbfc@haskell.org> Message-ID: <064.d40b46d8977cb7831109bbc1293608a1@haskell.org> #15532: Relaxing Levity-Polymorphic Binder Check for Lifted vs Unlifted pointers -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 14917 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): So, you couldn't write `map` or `foldr` or anything like that, but you could get a levity polymorphic index lookup: {{{ (!) :: forall (v :: Levity) (a :: TYPE ('PtrRep v)). Int -> List a -> a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 18:53:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 18:53:59 -0000 Subject: [GHC] #12146: syntax repair suggestion is too eager to suggest TemplateHaskell In-Reply-To: <049.ae34cc16e6637ea2bb94449efc0751c9@haskell.org> References: <049.ae34cc16e6637ea2bb94449efc0751c9@haskell.org> Message-ID: <064.6a3ff01d3ca41f3377d51eaad0f44a2a@haskell.org> #12146: syntax repair suggestion is too eager to suggest TemplateHaskell -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #7396 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8f4df7f769e0e625922d6f63fa20bd038f3c0c3d/ghc" 8f4df7f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8f4df7f769e0e625922d6f63fa20bd038f3c0c3d" Add test cases for Ticket #12146. Two tests - a ghci script and a compile fail test have been added. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 18:53:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 18:53:59 -0000 Subject: [GHC] #12146: syntax repair suggestion is too eager to suggest TemplateHaskell In-Reply-To: <049.ae34cc16e6637ea2bb94449efc0751c9@haskell.org> References: <049.ae34cc16e6637ea2bb94449efc0751c9@haskell.org> Message-ID: <064.b83e25ec75b58e1af6c97733086dd032@haskell.org> #12146: syntax repair suggestion is too eager to suggest TemplateHaskell -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #7396 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1bbb5fa2f7c5eeb46afbba3301df68cccc8be6a3/ghc" 1bbb5fa2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1bbb5fa2f7c5eeb46afbba3301df68cccc8be6a3" Add comment explaining change in syntax error suggestion for #12146. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 19:28:51 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 19:28:51 -0000 Subject: [GHC] #15533: Access the number of bits in the target machine's Int type at compile time Message-ID: <047.88dc19acc4ad07275cb32cbca32b73f1@haskell.org> #15533: Access the number of bits in the target machine's Int type at compile time -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm not sure of the current progress on GHC cross-compiling user programs, but I think a small addition might need to be made somewhere in the modules included with `ghc`. If I'm reading the documentation correctly, [https://hackage.haskell.org/package/base-4.11.1.0/docs/GHC- ByteOrder.html#v:targetByteOrder GHC.ByteOrder.targetByteOrder] will let us know the endianness of the target machine even if the compiling machine has a different endianness. I assume that this allows Template Haskell to, at compile time, generate proper code specifically for the target based on that fact. I can't find any way of finding out the bit size of an `Int` (specifically the exact value of `(finiteBitSize (undefined :: Int)`) on the target platform, and it would be nice if that were added in a way that's convenient to access in general and by Template Haskell at compile time, similar to `GHC.ByteOrder.targetByteOrder`. ---- I've looked into it a little bit and found that [https://github.com/ghc/ghc/blob/master/compiler/utils/Platform.hs#L33 the GHC API will tell you the word size of the target in bytes with platformWordSize] (also on [https://hackage.haskell.org/package/ghc-8.4.3/docs/Platform.html#v:platformWordSize Hackage]): {{{#!hs lineno=25 id=b marks=31-33 -- | Contains enough information for the native code generator to emit -- code for this platform. data Platform = Platform { platformArch :: Arch, platformOS :: OS, -- Word size in bytes (i.e. normally 4 or 8, -- for 32bit and 64bit platforms respectively) platformWordSize :: {-# UNPACK #-} !Int, platformUnregisterised :: Bool, platformHasGnuNonexecStack :: Bool, platformHasIdentDirective :: Bool, platformHasSubsectionsViaSymbols :: Bool, platformIsCrossCompiling :: Bool } deriving (Read, Show, Eq) }}} The problem is that this doesn't account for possible tag bits reducing the size ''in bits'' of `Int` to something less than the given `platformWordSize`. Recently, [https://ghc.haskell.org/trac/ghc/ticket/15486 support for WORD_SIZE_IN_BITS < 32 was dropped], so tag bits aren't a problem on 32-bit platforms anymore, but they might be on 64-bit platforms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 19:30:00 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 19:30:00 -0000 Subject: [GHC] #15533: Access the number of bits in the target machine's Int type at compile time In-Reply-To: <047.88dc19acc4ad07275cb32cbca32b73f1@haskell.org> References: <047.88dc19acc4ad07275cb32cbca32b73f1@haskell.org> Message-ID: <062.6df2ed1f6e43e846f0127e725c606fe1@haskell.org> #15533: Access the number of bits in the target machine's Int type at compile time -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by ChaiTRex: Old description: > I'm not sure of the current progress on GHC cross-compiling user > programs, but I think a small addition might need to be made somewhere in > the modules included with `ghc`. > > If I'm reading the documentation correctly, > [https://hackage.haskell.org/package/base-4.11.1.0/docs/GHC- > ByteOrder.html#v:targetByteOrder GHC.ByteOrder.targetByteOrder] will let > us know the endianness of the target machine even if the compiling > machine has a different endianness. I assume that this allows Template > Haskell to, at compile time, generate proper code specifically for the > target based on that fact. > > I can't find any way of finding out the bit size of an `Int` > (specifically the exact value of `(finiteBitSize (undefined :: Int)`) on > the target platform, and it would be nice if that were added in a way > that's convenient to access in general and by Template Haskell at compile > time, similar to `GHC.ByteOrder.targetByteOrder`. > > ---- > > I've looked into it a little bit and found that > [https://github.com/ghc/ghc/blob/master/compiler/utils/Platform.hs#L33 > the GHC API will tell you the word size of the target in bytes with > platformWordSize] (also on > [https://hackage.haskell.org/package/ghc-8.4.3/docs/Platform.html#v:platformWordSize > Hackage]): > > {{{#!hs lineno=25 id=b marks=31-33 > -- | Contains enough information for the native code generator to emit > -- code for this platform. > data Platform > = Platform { > platformArch :: Arch, > platformOS :: OS, > -- Word size in bytes (i.e. normally 4 or 8, > -- for 32bit and 64bit platforms respectively) > platformWordSize :: {-# UNPACK #-} !Int, > platformUnregisterised :: Bool, > platformHasGnuNonexecStack :: Bool, > platformHasIdentDirective :: Bool, > platformHasSubsectionsViaSymbols :: Bool, > platformIsCrossCompiling :: Bool > } > deriving (Read, Show, Eq) > }}} > > The problem is that this doesn't account for possible tag bits reducing > the size ''in bits'' of `Int` to something less than the given > `platformWordSize`. > > Recently, [https://ghc.haskell.org/trac/ghc/ticket/15486 support for > WORD_SIZE_IN_BITS < 32 was dropped], so tag bits aren't a problem on > 32-bit platforms anymore, but they might be on 64-bit platforms. New description: I'm not sure of the current progress on GHC cross-compiling user programs, but I think a small addition might need to be made somewhere in the modules included with `ghc`. If I'm reading the documentation correctly, [https://hackage.haskell.org/package/base-4.11.1.0/docs/GHC- ByteOrder.html#v:targetByteOrder GHC.ByteOrder.targetByteOrder] will let us know the endianness of the target machine even if the compiling machine has a different endianness. I assume that this allows Template Haskell to, at compile time, generate proper code specifically for the target based on that fact. I can't find any way of finding out the bit size of an `Int` (specifically the exact value of `(finiteBitSize (undefined :: Int)`) on the target platform, and it would be nice if that were added in a way that's convenient to access in general and by Template Haskell at compile time, similar to `GHC.ByteOrder.targetByteOrder`. ---- I've looked into it a little bit and found that [https://github.com/ghc/ghc/blob/master/compiler/utils/Platform.hs#L31-L33 the GHC API will tell you the word size of the target in bytes with platformWordSize] (also on [https://hackage.haskell.org/package/ghc-8.4.3/docs/Platform.html#v:platformWordSize Hackage]): {{{#!hs lineno=25 id=b marks=31-33 -- | Contains enough information for the native code generator to emit -- code for this platform. data Platform = Platform { platformArch :: Arch, platformOS :: OS, -- Word size in bytes (i.e. normally 4 or 8, -- for 32bit and 64bit platforms respectively) platformWordSize :: {-# UNPACK #-} !Int, platformUnregisterised :: Bool, platformHasGnuNonexecStack :: Bool, platformHasIdentDirective :: Bool, platformHasSubsectionsViaSymbols :: Bool, platformIsCrossCompiling :: Bool } deriving (Read, Show, Eq) }}} The problem is that this doesn't account for possible tag bits reducing the size ''in bits'' of `Int` to something less than the given `platformWordSize`. Recently, [https://ghc.haskell.org/trac/ghc/ticket/15486 support for WORD_SIZE_IN_BITS < 32 was dropped], so tag bits aren't a problem on 32-bit platforms anymore, but they might be on 64-bit platforms. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 20:03:17 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 20:03:17 -0000 Subject: [GHC] #15490: Can Template Haskell and RULES be combined? In-Reply-To: <047.7e032bb8158a417844a4d7ce8bbd1794@haskell.org> References: <047.7e032bb8158a417844a4d7ce8bbd1794@haskell.org> Message-ID: <062.a0b8805b96b7b7090086929f4b78f07c@haskell.org> #15490: Can Template Haskell and RULES be combined? -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ChaiTRex): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 20:27:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 20:27:22 -0000 Subject: [GHC] #15534: Allow associated types in Minimal pragmas Message-ID: <045.6db89ec9707d75439c8a339ed44a058a@haskell.org> #15534: Allow associated types in Minimal pragmas -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Missing associated type definitions can cause compile-time problems similar to the run-time problems that occur when necessary methods are missing. {{{#!hs {-# language TypeFamilies, UndecidableInstances #-} class Foo a where type X a type X a = Y a type Y a type Y a = X a instance Foo Int bob :: X Int bob = undefined }}} Compiling this gives {{{ Minim.hs:14:7: error: • Reduction stack overflow; size = 201 When simplifying the following type: Y Int Use -freduction-depth=0 to disable this check (any upper bound you could choose might fail unpredictably with minor updates to GHC, so disabling the check is recommended if you're sure that type checking should terminate) • In the expression: undefined In an equation for ‘bob’: bob = undefined | 14 | bob = undefined }}} That's not exactly the best error message in the world. I would like to be able to write {{{#!hs {-# MINIMAL X | Y #-} }}} which would mean that instances should give type instances for `X` or `Y`. I don't see any reason to prohibit mixing associated types and methods in a single `MINIMAL` pragma. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 21:27:02 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 21:27:02 -0000 Subject: [GHC] #15535: Expose the StableName constructor Message-ID: <045.6f45bd0659fffa92c0b169d118d7bd0a@haskell.org> #15535: Expose the StableName constructor -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Core | Version: 8.4.3 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A `StableName` is just a wrapper around `StableName#`, but we don't reveal that anywhere. That means that user code needs to use `unsafeCoerce` to convert between `StableName` and `StableName#`, which seems terrible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 22:48:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 22:48:54 -0000 Subject: [GHC] #14917: Allow levity polymorphism in binding position In-Reply-To: <049.d67991f1b0cd65b675056d1b1f0986b9@haskell.org> References: <049.d67991f1b0cd65b675056d1b1f0986b9@haskell.org> Message-ID: <064.5d3863e56cf150ea6ee0ae27555c662b@haskell.org> #14917: Allow levity polymorphism in binding position -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ericson2314): > It's a bit tiresome to have to do this -- it'd be easier for the programmer to say that all polymorphism can be specialised in this way, as .NET does -- but I think that's out of reach for us. Once we have the monomorphizing quantifiers, I would advocate for a language proposal to infer runtime rep parameters and {{{TYPE r}}} where where {{{Type}}} is inferred today. (Someday, I want to rewrite the RTS in Haskell...without getting RSI from wrist typing boilerplate :D) > And there are only a finite number of possiblities for {{{r}}} Well, we'd also like to use this to statically prevent dictionary passing, and constraints are in generate infinitely inhabited. Also it would be nice to unbox aggregates in collections, maybe reusing the unboxed tuple and sum representations. That also creates infinite choices for {{{r}}} in principle. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 17 23:25:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Aug 2018 23:25:19 -0000 Subject: [GHC] #15536: Unify unlifted pointer equality primitives Message-ID: <045.2d1a95e8612f77598982e8dc7f55ecb0@haskell.org> #15536: Unify unlifted pointer equality primitives -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We have a bunch of different primops to test pointer equality between various unlifted pointer types (`MutableArray#`, `MutVar#`, etc.). Now that we have the necessary type machinery, I believe we should be able to get away with just one: {{{#!hs unliftedPtrEquality# :: forall (a :: TYPE 'UnliftedRep). a -> a -> Int# }}} All the rest can then be defined as regular functions in `GHC.Exts` or some such. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 18 00:34:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Aug 2018 00:34:36 -0000 Subject: [GHC] #15537: Panic when building Crucible Message-ID: <051.89702376eb07d7404e01f5e6ebc6adf6@haskell.org> #15537: Panic when building Crucible -------------------------------------+------------------------------------- Reporter: siddharthist | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've encountered a panic, which GHC has asked me to report: {{{ [19 of 21] Compiling Lang.Crucible.LLVM.Translation ( src/Lang/Crucible/LLVM/Translation.hs, dist/build/Lang/Crucible/LLVM/Translation.p_o ) : error: ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): isUnliftedType r_a4Zsg :: TYPE rep_a4Zsf Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:1939:10 in ghc:Type Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This was when compiling [https://github.com/GaloisInc/crucible/tree/master /crucible-llvm crucible-llvm] revision 186mfb7wlz with GHC 8.4.3. I'm building in Nix with a sandbox, so this should be easily reproducible. The Nix files are available here: https://github.com/siddharthist/galois- haskell-nix/tree/ghc-bug. Just run nix-build -A haskellPackages.crucible- llvm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 18 00:46:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Aug 2018 00:46:09 -0000 Subject: [GHC] #15537: Panic when building Crucible In-Reply-To: <051.89702376eb07d7404e01f5e6ebc6adf6@haskell.org> References: <051.89702376eb07d7404e01f5e6ebc6adf6@haskell.org> Message-ID: <066.2ea6e595f4f902f171fdae50137a4c64@haskell.org> #15537: Panic when building Crucible -------------------------------------+------------------------------------- Reporter: siddharthist | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by siddharthist): Sorry, this looks like a duplicate: https://ghc.haskell.org/trac/ghc/ticket/15186. This can probably be closed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 18 02:12:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Aug 2018 02:12:17 -0000 Subject: [GHC] #15537: Panic when building Crucible In-Reply-To: <051.89702376eb07d7404e01f5e6ebc6adf6@haskell.org> References: <051.89702376eb07d7404e01f5e6ebc6adf6@haskell.org> Message-ID: <066.c885c40b080083962c80f12427204341@haskell.org> #15537: Panic when building Crucible -------------------------------------+------------------------------------- Reporter: siddharthist | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15186 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #15186 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 18 12:04:59 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Aug 2018 12:04:59 -0000 Subject: [GHC] #9441: CSE should deal with letrec In-Reply-To: <045.987758d932a89023c69da6c12f8363f5@haskell.org> References: <045.987758d932a89023c69da6c12f8363f5@haskell.org> Message-ID: <060.63a8a9aa146afbd61dd5c2cdf3178a50@haskell.org> #9441: CSE should deal with letrec -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: RolandSenn Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: CSE Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: T9441a, performance bug | T9441b, T9441c Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D5038 Wiki Page: | D5076 -------------------------------------+------------------------------------- Changes (by RolandSenn): * status: new => patch * differential: Phab: D5038 => Phab: D5038 D5076 Comment: See: [https://phabricator.haskell.org/D5076] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 18 14:35:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Aug 2018 14:35:50 -0000 Subject: [GHC] #15050: ScopedTypeVariables could allow more programs In-Reply-To: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> References: <046.5d6395801b3bf469d32cb749f99cf836@haskell.org> Message-ID: <061.71aea1a23f26956e6386e4cf4d41e33c@haskell.org> #15050: ScopedTypeVariables could allow more programs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4980 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Links * [https://github.com/ghc-proposals/ghc- proposals/blob/master/proposals/0031-type-applications-in-patterns.rst GHC proposal] * [https://github.com/ghc-proposals/ghc-proposals/pull/126 GHC proposal discussion] * [https://arxiv.org/abs/1806.03476 paper] (Type variables in patterns) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 18 15:52:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Aug 2018 15:52:58 -0000 Subject: [GHC] #15426: `elemIndex` and `findIndex` still can't fuse In-Reply-To: <045.556cc5a15fe7d0c4bec73444eba7ef79@haskell.org> References: <045.556cc5a15fe7d0c4bec73444eba7ef79@haskell.org> Message-ID: <060.8b8c42bebd28322d106dc44a4549a8a3@haskell.org> #15426: `elemIndex` and `findIndex` still can't fuse -------------------------------------+------------------------------------- Reporter: kabuhr | Owner: kabuhr Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: libraries/base | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/perf/should_run/T15426.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D5063 -------------------------------------+------------------------------------- Comment (by kabuhr): No, these differences were for the "TotalMem" column from the "nofib- analyse" tool. I gather this corresponds to the memory "in use" in "-RTS +t" output, which is peak OS allocation and presumably sensitive to GC timing. After doing some more testing, it seems both the `cacheprof` and `maillist` differences are spurious (e.g., `maillist` either "uses" `8M` or `16M` during each run, and I just happened to have a string of good luck on the `INLINABLE` test). There were no differences in allocations for these or any of the other benchmarks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 18 17:22:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Aug 2018 17:22:19 -0000 Subject: [GHC] #15538: GHC boot script can't handle Git origin not named origin Message-ID: <047.fe333412ac9b31fba3186aedc92cf221@haskell.org> #15538: GHC boot script can't handle Git origin not named origin -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- == Problem I ran the following to get the sources for GHC to build them: {{{ git clone -o ghc --recursive http://git.haskell.org/ghc.git }}} Note especially the `-o ghc` part, which uses the Git origin name `ghc` instead of the default `origin`. When a custom origin name is used, `./boot` fails: {{{ $ ./boot Traceback (most recent call last): File "./boot", line 193, in check_for_url_rewrites() File "./boot", line 29, in check_for_url_rewrites subprocess.check_output('git config remote.origin.url'.split()).find(b'github.com') != -1 and \ File "/usr/lib/python3.5/subprocess.py", line 626, in check_output **kwargs).stdout File "/usr/lib/python3.5/subprocess.py", line 708, in run output=stdout, stderr=stderr) subprocess.CalledProcessError: Command '['git', 'config', 'remote.origin.url']' returned non-zero exit status 1 $ git config remote.origin.url $ echo $? 1 }}} == Solution To get the URL of the proper origin name, `git config branch.master.remote` can be used to get the origin name to use to get the URL: {{{ $ git config "remote.$( git config branch.master.remote ).url" http://git.haskell.org/ghc.git }}} == Workaround Rename the origin to `origin`: {{{ $ git remote rename "$( git config branch.master.remote )" origin $ ./boot Creating libraries/mtl/ghc.mk Creating libraries/unix/ghc.mk Creating libraries/text/ghc.mk ⋮ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 18 17:23:15 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Aug 2018 17:23:15 -0000 Subject: [GHC] #15538: GHC boot script can't handle Git origin not named origin In-Reply-To: <047.fe333412ac9b31fba3186aedc92cf221@haskell.org> References: <047.fe333412ac9b31fba3186aedc92cf221@haskell.org> Message-ID: <062.fc0bd55a170097686485b41e18a7a66b@haskell.org> #15538: GHC boot script can't handle Git origin not named origin -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by ChaiTRex: Old description: > == Problem > > I ran the following to get the sources for GHC to build them: > > {{{ > git clone -o ghc --recursive http://git.haskell.org/ghc.git > }}} > > Note especially the `-o ghc` part, which uses the Git origin name `ghc` > instead of the default `origin`. When a custom origin name is used, > `./boot` fails: > > {{{ > $ ./boot > Traceback (most recent call last): > File "./boot", line 193, in > check_for_url_rewrites() > File "./boot", line 29, in check_for_url_rewrites > subprocess.check_output('git config > remote.origin.url'.split()).find(b'github.com') != -1 and \ > File "/usr/lib/python3.5/subprocess.py", line 626, in check_output > **kwargs).stdout > File "/usr/lib/python3.5/subprocess.py", line 708, in run > output=stdout, stderr=stderr) > subprocess.CalledProcessError: Command '['git', 'config', > 'remote.origin.url']' returned non-zero exit status 1 > > $ git config remote.origin.url > > $ echo $? > 1 > }}} > > == Solution > > To get the URL of the proper origin name, `git config > branch.master.remote` can be used to get the origin name to use to get > the URL: > > {{{ > $ git config "remote.$( git config branch.master.remote ).url" > http://git.haskell.org/ghc.git > }}} > > == Workaround > > Rename the origin to `origin`: > > {{{ > $ git remote rename "$( git config branch.master.remote )" origin > $ ./boot > Creating libraries/mtl/ghc.mk > Creating libraries/unix/ghc.mk > Creating libraries/text/ghc.mk > ⋮ > }}} New description: == Problem I ran the following to get the sources for GHC to build them: {{{ git clone -o ghc --recursive http://git.haskell.org/ghc.git }}} Note especially the `-o ghc` part, which uses the Git origin name `ghc` instead of the default `origin`. When a custom origin name is used, `./boot` fails: {{{ $ ./boot Traceback (most recent call last): File "./boot", line 193, in check_for_url_rewrites() File "./boot", line 29, in check_for_url_rewrites subprocess.check_output('git config remote.origin.url'.split()).find(b'github.com') != -1 and \ File "/usr/lib/python3.5/subprocess.py", line 626, in check_output **kwargs).stdout File "/usr/lib/python3.5/subprocess.py", line 708, in run output=stdout, stderr=stderr) subprocess.CalledProcessError: Command '['git', 'config', 'remote.origin.url']' returned non-zero exit status 1 $ git config remote.origin.url $ echo $? 1 }}} == Solution `git config branch.master.remote` can be used to get the origin name to use to get the desired URL: {{{ $ git config "remote.$( git config branch.master.remote ).url" http://git.haskell.org/ghc.git }}} == Workaround Rename the origin to `origin`: {{{ $ git remote rename "$( git config branch.master.remote )" origin $ ./boot Creating libraries/mtl/ghc.mk Creating libraries/unix/ghc.mk Creating libraries/text/ghc.mk ⋮ }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 18 17:56:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Aug 2018 17:56:42 -0000 Subject: [GHC] #15538: GHC boot script can't handle Git remote not named origin (was: GHC boot script can't handle Git origin not named origin) In-Reply-To: <047.fe333412ac9b31fba3186aedc92cf221@haskell.org> References: <047.fe333412ac9b31fba3186aedc92cf221@haskell.org> Message-ID: <062.83695255546e07393bfe74a0becf6057@haskell.org> #15538: GHC boot script can't handle Git remote not named origin -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > == Problem > > I ran the following to get the sources for GHC to build them: > > {{{ > git clone -o ghc --recursive http://git.haskell.org/ghc.git > }}} > > Note especially the `-o ghc` part, which uses the Git origin name `ghc` > instead of the default `origin`. When a custom origin name is used, > `./boot` fails: > > {{{ > $ ./boot > Traceback (most recent call last): > File "./boot", line 193, in > check_for_url_rewrites() > File "./boot", line 29, in check_for_url_rewrites > subprocess.check_output('git config > remote.origin.url'.split()).find(b'github.com') != -1 and \ > File "/usr/lib/python3.5/subprocess.py", line 626, in check_output > **kwargs).stdout > File "/usr/lib/python3.5/subprocess.py", line 708, in run > output=stdout, stderr=stderr) > subprocess.CalledProcessError: Command '['git', 'config', > 'remote.origin.url']' returned non-zero exit status 1 > > $ git config remote.origin.url > > $ echo $? > 1 > }}} > > == Solution > > `git config branch.master.remote` can be used to get the origin name to > use to get the desired URL: > > {{{ > $ git config "remote.$( git config branch.master.remote ).url" > http://git.haskell.org/ghc.git > }}} > > == Workaround > > Rename the origin to `origin`: > > {{{ > $ git remote rename "$( git config branch.master.remote )" origin > $ ./boot > Creating libraries/mtl/ghc.mk > Creating libraries/unix/ghc.mk > Creating libraries/text/ghc.mk > ⋮ > }}} New description: == Problemorf I ran the following to get the sources for GHC to build them: {{{ git clone -o ghc --recursive http://git.haskell.org/ghc.git }}} Note especially the `-o ghc` part, which uses the Git remote name `ghc` instead of the default `origin`. When a custom remote name is used, `./boot` fails: {{{ $ ./boot Traceback (most recent call last): File "./boot", line 193, in check_for_url_rewrites() File "./boot", line 29, in check_for_url_rewrites subprocess.check_output('git config remote.origin.url'.split()).find(b'github.com') != -1 and \ File "/usr/lib/python3.5/subprocess.py", line 626, in check_output **kwargs).stdout File "/usr/lib/python3.5/subprocess.py", line 708, in run output=stdout, stderr=stderr) subprocess.CalledProcessError: Command '['git', 'config', 'remote.origin.url']' returned non-zero exit status 1 $ git config remote.origin.url $ echo $? 1 }}} == Solution `git config remote.origin.url` can be used first. Whenever `git config remote.origin.url` fails, a `git rev-parse` command (thanks to freenode/#git/_ikke_ for it) can be used to get the remote name and branch that would be pushed to: {{{ $ git rev-parse --symbolic-full-name --abbrev-ref @{upstream} ghc/coercible $ git rev-parse --symbolic-full-name --abbrev-ref @{upstream} | sed 's/\/.*$//' ghc $ git config "remote.$( git rev-parse --symbolic-full-name --abbrev-ref @{upstream} | sed 's/\/.*$//' ).url" http://git.haskell.org/ghc.git }}} == Workaround Rename the remote to `origin`: {{{ $ git remote rename "$( git config branch.master.remote )" origin $ ./boot Creating libraries/mtl/ghc.mk Creating libraries/unix/ghc.mk Creating libraries/text/ghc.mk ⋮ }}} -- Comment (by ChaiTRex): [Solution in report above fixed for custom branch selection] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 18 18:06:33 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Aug 2018 18:06:33 -0000 Subject: [GHC] #15538: GHC boot script can't handle Git remote not named origin In-Reply-To: <047.fe333412ac9b31fba3186aedc92cf221@haskell.org> References: <047.fe333412ac9b31fba3186aedc92cf221@haskell.org> Message-ID: <062.751300aa05644cbd4b8c4fcab0f154ee@haskell.org> #15538: GHC boot script can't handle Git remote not named origin -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by ChaiTRex: Old description: > == Problemorf > > I ran the following to get the sources for GHC to build them: > > {{{ > git clone -o ghc --recursive http://git.haskell.org/ghc.git > }}} > > Note especially the `-o ghc` part, which uses the Git remote name `ghc` > instead of the default `origin`. When a custom remote name is used, > `./boot` fails: > > {{{ > $ ./boot > Traceback (most recent call last): > File "./boot", line 193, in > check_for_url_rewrites() > File "./boot", line 29, in check_for_url_rewrites > subprocess.check_output('git config > remote.origin.url'.split()).find(b'github.com') != -1 and \ > File "/usr/lib/python3.5/subprocess.py", line 626, in check_output > **kwargs).stdout > File "/usr/lib/python3.5/subprocess.py", line 708, in run > output=stdout, stderr=stderr) > subprocess.CalledProcessError: Command '['git', 'config', > 'remote.origin.url']' returned non-zero exit status 1 > > $ git config remote.origin.url > > $ echo $? > 1 > }}} > > == Solution > > `git config remote.origin.url` can be used first. Whenever `git config > remote.origin.url` fails, a `git rev-parse` command (thanks to > freenode/#git/_ikke_ for it) can be used to get the remote name and > branch that would be pushed to: > > {{{ > $ git rev-parse --symbolic-full-name --abbrev-ref @{upstream} > ghc/coercible > > $ git rev-parse --symbolic-full-name --abbrev-ref @{upstream} | sed > 's/\/.*$//' > ghc > > $ git config "remote.$( git rev-parse --symbolic-full-name --abbrev-ref > @{upstream} | sed 's/\/.*$//' ).url" > http://git.haskell.org/ghc.git > }}} > > == Workaround > > Rename the remote to `origin`: > > {{{ > $ git remote rename "$( git config branch.master.remote )" origin > $ ./boot > Creating libraries/mtl/ghc.mk > Creating libraries/unix/ghc.mk > Creating libraries/text/ghc.mk > ⋮ > }}} New description: == Problem I ran the following to get the sources for GHC to build them: {{{ git clone -o ghc --recursive http://git.haskell.org/ghc.git }}} Note especially the `-o ghc` part, which uses the Git remote name `ghc` instead of the default `origin`. When a custom remote name is used, `./boot` fails: {{{ $ ./boot Traceback (most recent call last): File "./boot", line 193, in check_for_url_rewrites() File "./boot", line 29, in check_for_url_rewrites subprocess.check_output('git config remote.origin.url'.split()).find(b'github.com') != -1 and \ File "/usr/lib/python3.5/subprocess.py", line 626, in check_output **kwargs).stdout File "/usr/lib/python3.5/subprocess.py", line 708, in run output=stdout, stderr=stderr) subprocess.CalledProcessError: Command '['git', 'config', 'remote.origin.url']' returned non-zero exit status 1 $ git config remote.origin.url $ echo $? 1 }}} == Solution `git config remote.origin.url` can be used first. Whenever `git config remote.origin.url` fails, a `git rev-parse` command (thanks to freenode/#git/_ikke_ for it) can be used to get the remote name and branch that would be pushed to: {{{ $ git rev-parse --symbolic-full-name --abbrev-ref @{upstream} ghc/coercible $ git rev-parse --symbolic-full-name --abbrev-ref @{upstream} | sed 's/\/.*$//' ghc $ git config "remote.$( git rev-parse --symbolic-full-name --abbrev-ref @{upstream} | sed 's/\/.*$//' ).url" http://git.haskell.org/ghc.git }}} == Workaround Rename the remote to `origin`: {{{ $ git remote rename "$( git config branch.master.remote )" origin $ ./boot Creating libraries/mtl/ghc.mk Creating libraries/unix/ghc.mk Creating libraries/text/ghc.mk ⋮ }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 18 21:45:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Aug 2018 21:45:43 -0000 Subject: [GHC] #15539: Regression since 7.10.3, "variable not in scope" errors sometimes get buried under a sea of much less relevant errors. Message-ID: <044.4a4f045286e58c78e289f91b1fd67dbd@haskell.org> #15539: Regression since 7.10.3, "variable not in scope" errors sometimes get buried under a sea of much less relevant errors. -------------------------------------+------------------------------------- Reporter: Wizek | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Me and Neil Mitchell have ran into this quite a few times while using GHCid, here is our discussion: https://github.com/ndmitchell/ghcid/issues/159 Here is a small reproducible example: {{{#!hs module Main where foo :: String foo = show a where a = baz bar :: Int bar = 1 main = putStrLn foo }}} GHC 8.0.x and above will say {{{ src/Main.hs:4:7: error: • Ambiguous type variable ‘a0’ arising from a use of ‘show’ prevents the constraint ‘(Show a0)’ from being solved. Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instances exist: instance (Show a, Show b) => Show (Either a b) -- Defined in ‘Data.Either’ instance Show Ordering -- Defined in ‘GHC.Show’ instance Show Integer -- Defined in ‘GHC.Show’ ...plus 23 others ...plus 212 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the expression: show a In an equation for ‘foo’: foo = show a where a = baz | 4 | foo = show a | ^^^^^^ src/Main.hs:5:13: error: • Variable not in scope: baz • Perhaps you meant ‘bar’ (line 8) | 5 | where a = baz | ^^^ }}} It's much more useful and much less noisy what 7.10.3 reports: {{{ src/Main.hs:5:13: Not in scope: ‘baz’ Perhaps you meant ‘bar’ (line 8) }}} So a desired output would be something like this for a later GHC release: {{{ src/Main.hs:5:13: error: • Variable not in scope: baz • Perhaps you meant ‘bar’ (line 8) | 5 | where a = baz | ^^^ }}} Or if someone is adamant about keeping the other errors even when there are out of scope variables present, then at least can we please reorder them such that the much more relevant out-of-scope errors are at the top? {{{ src/Main.hs:5:13: error: • Variable not in scope: baz • Perhaps you meant ‘bar’ (line 8) | 5 | where a = baz | ^^^ src/Main.hs:4:7: error: • Ambiguous type variable ‘a0’ arising from a use of ‘show’ prevents the constraint ‘(Show a0)’ from being solved. Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instances exist: instance (Show a, Show b) => Show (Either a b) -- Defined in ‘Data.Either’ instance Show Ordering -- Defined in ‘GHC.Show’ instance Show Integer -- Defined in ‘GHC.Show’ ...plus 23 others ...plus 212 instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the expression: show a In an equation for ‘foo’: foo = show a where a = baz | 4 | foo = show a | ^^^^^^ }}} I might even be up for fixing this if there is agreement on the next steps to be taken. (Though I've never contributed to GHC before, on the surface this doesn't seem hard to fix.) What do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 18 21:47:15 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Aug 2018 21:47:15 -0000 Subject: [GHC] #9441: CSE should deal with letrec In-Reply-To: <045.987758d932a89023c69da6c12f8363f5@haskell.org> References: <045.987758d932a89023c69da6c12f8363f5@haskell.org> Message-ID: <060.b529bfb8b71ef55bd0b68a136e0c2626@haskell.org> #9441: CSE should deal with letrec -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: RolandSenn Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: CSE Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: T9441a, performance bug | T9441b, T9441c Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D5038 Wiki Page: | D5076 -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"a08b285f74cd49196feb0f819d70ad0508689da3/ghc" a08b285f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a08b285f74cd49196feb0f819d70ad0508689da3" CSE should deal with letrec (#9441) Summary: Write tests with fewer lines. See comments of nomeata in https://phabricator.haskell.org/D5038. Test Plan: make test TESTS='T9441a T9441b T9441c' Reviewers: nomeata, dfeuer, bgamari Reviewed By: nomeata Subscribers: rwbarton, carter GHC Trac Issues: #9441 Differential Revision: https://phabricator.haskell.org/D5076 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 18 22:04:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Aug 2018 22:04:04 -0000 Subject: [GHC] #9441: CSE should deal with letrec In-Reply-To: <045.987758d932a89023c69da6c12f8363f5@haskell.org> References: <045.987758d932a89023c69da6c12f8363f5@haskell.org> Message-ID: <060.ad0ed2f179243c0a6a6c737eed9b1674@haskell.org> #9441: CSE should deal with letrec -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: RolandSenn Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: CSE Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime | Test Case: T9441a, performance bug | T9441b, T9441c Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D5038 Wiki Page: | D5076 -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 18 23:43:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Aug 2018 23:43:06 -0000 Subject: [GHC] #15538: GHC boot script can't handle Git remote not named origin In-Reply-To: <047.fe333412ac9b31fba3186aedc92cf221@haskell.org> References: <047.fe333412ac9b31fba3186aedc92cf221@haskell.org> Message-ID: <062.e949a1ba91331129e678ad3336caf02e@haskell.org> #15538: GHC boot script can't handle Git remote not named origin -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: ChaiTRex Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ChaiTRex): * owner: (none) => ChaiTRex -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 18 23:53:00 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Aug 2018 23:53:00 -0000 Subject: [GHC] #15538: GHC boot script can't handle Git remote not named origin In-Reply-To: <047.fe333412ac9b31fba3186aedc92cf221@haskell.org> References: <047.fe333412ac9b31fba3186aedc92cf221@haskell.org> Message-ID: <062.b940a7a93c5201ec3f91f2cf2c02d7db@haskell.org> #15538: GHC boot script can't handle Git remote not named origin -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: ChaiTRex Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Build System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5077 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ChaiTRex): * differential: => Phab:D5077 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 19 01:07:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Aug 2018 01:07:48 -0000 Subject: [GHC] #15536: Unify unlifted pointer equality primitives In-Reply-To: <045.2d1a95e8612f77598982e8dc7f55ecb0@haskell.org> References: <045.2d1a95e8612f77598982e8dc7f55ecb0@haskell.org> Message-ID: <060.23992f19ea7b6c2cd5f18e8af703a1b2@haskell.org> #15536: Unify unlifted pointer equality primitives -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, I believe GHC can do this now. +1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 19 02:55:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Aug 2018 02:55:37 -0000 Subject: [GHC] #15220: ScopedTypeVariables binds a non-existent variable In-Reply-To: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> References: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> Message-ID: <062.4d5e687368c9dbf267b08d6a8f698886@haskell.org> #15220: ScopedTypeVariables binds a non-existent variable -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): As a side node, there is need for `undefined` to trigger this: {{{ f :: (forall a. (a -> (), a)) -> () f (p :: (b -> (), b)) = fst p (snd p) }}} also has `p` instantiated with `Any`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 19 06:06:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Aug 2018 06:06:24 -0000 Subject: [GHC] #15536: Unify unlifted pointer equality primitives In-Reply-To: <045.2d1a95e8612f77598982e8dc7f55ecb0@haskell.org> References: <045.2d1a95e8612f77598982e8dc7f55ecb0@haskell.org> Message-ID: <060.49f910d640d58d6d8c0ffac76ec8b959@haskell.org> #15536: Unify unlifted pointer equality primitives -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I started looking into implementation, and I see a couple wrinkles: 1. The one that blocked me is that I don't know how to express the type I want in `primops.txt.pp`, if it's possible. Anyone know? If it's not possible, where would I have to override a bogus type with the correct one? 2. `StableName#` is not implemented using a pointer equality test. Instead, it seems that we check the stable name table indices for equality. I don't, however, see a reason for this. Isn't there precisely one stable name object per stable name table entry? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 19 11:06:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Aug 2018 11:06:32 -0000 Subject: [GHC] #15158: T8089 failing with ghci, threaded1, threaded2, profthreaded In-Reply-To: <048.e0a32f56c09af74c66cfdba0027fd931@haskell.org> References: <048.e0a32f56c09af74c66cfdba0027fd931@haskell.org> Message-ID: <063.42087f8c979d39fdb849800478e53f3a@haskell.org> #15158: T8089 failing with ghci, threaded1, threaded2, profthreaded -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: libraries/base | Version: 8.5 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: T8089 Blocked By: | Blocking: Related Tickets: #8089, #7325, | Differential Rev(s): Phab:D4700 #15064 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by YitzGale): When will the fix be released? This bug will likely cause some fairly widespread failures. https://www.reddit.com/r/haskell/comments/97zmpa/psa_forever_threaddelay_maxbound_idiom_broken_on/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 19 11:31:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Aug 2018 11:31:55 -0000 Subject: [GHC] #15158: T8089 failing with ghci, threaded1, threaded2, profthreaded In-Reply-To: <048.e0a32f56c09af74c66cfdba0027fd931@haskell.org> References: <048.e0a32f56c09af74c66cfdba0027fd931@haskell.org> Message-ID: <063.e8736a67267ecb1409d10a7e1ee95dd0@haskell.org> #15158: T8089 failing with ghci, threaded1, threaded2, profthreaded -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: libraries/base | Version: 8.5 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: T8089 Blocked By: | Blocking: Related Tickets: #8089, #7325, | Differential Rev(s): Phab:D4700 #15064 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by YitzGale): Another question - this code seems to be mixing up milliseconds and microseconds. What am I missing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 19 12:17:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Aug 2018 12:17:16 -0000 Subject: [GHC] #15525: Unicode 8.0 and later characters are invariably lexical errors In-Reply-To: <047.28ba0e189446e80c83f61ac8574b1084@haskell.org> References: <047.28ba0e189446e80c83f61ac8574b1084@haskell.org> Message-ID: <062.f8bd6e4b7d11224f1c4e91f95d2cfb90@haskell.org> #15525: Unicode 8.0 and later characters are invariably lexical errors -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Parser) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5518 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ChaiTRex): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 19 12:19:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Aug 2018 12:19:48 -0000 Subject: [GHC] #15538: GHC boot script can't handle Git remote not named origin In-Reply-To: <047.fe333412ac9b31fba3186aedc92cf221@haskell.org> References: <047.fe333412ac9b31fba3186aedc92cf221@haskell.org> Message-ID: <062.d58519f0679e9adc23b9bdd9da69074a@haskell.org> #15538: GHC boot script can't handle Git remote not named origin -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: ChaiTRex Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Build System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5077 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ChaiTRex): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 19 12:38:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Aug 2018 12:38:07 -0000 Subject: [GHC] #15540: GHCi does not follow the XDG Base Directory Specification Message-ID: <047.104e0b09441c5fa58dd1aeb68ec6fc11@haskell.org> #15540: GHCi does not follow the XDG Base Directory Specification -------------------------------------+------------------------------------- Reporter: rszibele | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello, GHCi does not follow the XDG Base Directory Specification by default on GNU/Linux based operating systems. It creates for instance the file $HOME/.ghc/ghci_history which belongs in $XDG_CACHE_HOME/ghc/ , or $HOME/.cache/ghc/ if $XDG_CACHE_HOME is not set. $ ghci --version The Glorious Glasgow Haskell Compilation System, version 8.0.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 19 14:55:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Aug 2018 14:55:48 -0000 Subject: [GHC] #15541: package environment files and the GHC API Message-ID: <048.226f5c575460b148605c8a51ca4e89c3@haskell.org> #15541: package environment files and the GHC API -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: GHC API | Version: 8.4.3 Keywords: package | Operating System: Unknown/Multiple environment | Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: #15513 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The GHC API respects package environment files, which is not documented and was not announced. I consider this to be at least a severe documentation bug. Afaik this goes back to ghc-8.0. #15513 is a ticket that essentially asks for the corresponding entry in the migration guide. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 19 17:01:33 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Aug 2018 17:01:33 -0000 Subject: [GHC] #15530: Type applications in patterns In-Reply-To: <046.ac75a1c05d26e58243b1cc5f1128ff00@haskell.org> References: <046.ac75a1c05d26e58243b1cc5f1128ff00@haskell.org> Message-ID: <061.92d1da12f3e06e0a1a8776ef078feb0f@haskell.org> #15530: Type applications in patterns -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): JFTR: Richard indicated that one of his students will tackle that, so no shooting from me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 19 18:26:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Aug 2018 18:26:40 -0000 Subject: [GHC] #15542: DuplicateRecordFields not honored within a data family? Message-ID: <048.60e65b226bb83891446d0a3a23f02b31@haskell.org> #15542: DuplicateRecordFields not honored within a data family? -------------------------------------+------------------------------------- Reporter: michalrus | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I’m observing some weird behavior, which is probably closely related to issue #15149. The following minimized code does not compile on 8.2.1, 8.2.2, but it does compile on 8.4.3. However, in my original (non-free) codebase, this is reversed: 8.2.2 compiles it just fine, and 8.4.3 fails with both errors per usage location at the same time: {{{ src/.../Docs.hs:123:11: error: • Constructor ‘X'Y’ does not have the required strict field(s): z ... src/.../Docs.hs:123:11: error: • Constructor ‘X'Y’ does not have field ‘z’ }}} I noticed, after updating the codebase’s compiler to 8.4.3. If the `z` field is renamed and unique, it compiles correctly. How can I go about debugging/minimizing this? This is the minimized code that works the other way round (OK on 8.4.3, fails on 8.2.2): {{{#!hs {-# LANGUAGE DuplicateRecordFields #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE StrictData #-} module Main where data AB = A | B class SomeClass (ab :: AB) where data SomeData ab instance SomeClass 'A where data SomeData 'A = SomeData'A{someField :: Int} deriving Show instance SomeClass 'B where data SomeData 'B = SomeData'B{someField :: Int} main :: IO () main = print SomeData'A{someField = 5} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 19 20:25:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Aug 2018 20:25:29 -0000 Subject: [GHC] #15541: package environment files and the GHC API In-Reply-To: <048.226f5c575460b148605c8a51ca4e89c3@haskell.org> References: <048.226f5c575460b148605c8a51ca4e89c3@haskell.org> Message-ID: <063.43c1256882906b9a253d4e3b241b9ab4@haskell.org> #15541: package environment files and the GHC API -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: GHC API | Version: 8.4.3 Resolution: | Keywords: package | environment Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #15513 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * cc: alanz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 19 20:35:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Aug 2018 20:35:06 -0000 Subject: [GHC] #15541: package environment files and the GHC API In-Reply-To: <048.226f5c575460b148605c8a51ca4e89c3@haskell.org> References: <048.226f5c575460b148605c8a51ca4e89c3@haskell.org> Message-ID: <063.3511e34a698b0688b84ebdfb6e2bac41@haskell.org> #15541: package environment files and the GHC API -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: GHC API | Version: 8.4.3 Resolution: | Keywords: package | environment Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #15513 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): Also relevant : https://github.com/lspitzner/brittany/issues/173 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 19 21:08:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Aug 2018 21:08:28 -0000 Subject: [GHC] #15541: package environment files and the GHC API In-Reply-To: <048.226f5c575460b148605c8a51ca4e89c3@haskell.org> References: <048.226f5c575460b148605c8a51ca4e89c3@haskell.org> Message-ID: <063.0f50b91dc87bc347e6cf1aaa3a2da992@haskell.org> #15541: package environment files and the GHC API -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: GHC API | Version: 8.4.3 Resolution: | Keywords: package | environment Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #15513 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lspitzner): The haddock on `setSessionDynFlags` currently reads: > Updates both the interactive and program DynFlags in a Session. This also reads the package database (unless it has already been read), and prepares the compilers knowledge about packages. It can be called again to load new packages: just add new package flags to (packageFlags dflags). > > Returns a list of new packages that may need to be linked in using the dynamic linker (see linkPackages) as a result of new package flags. If you are not doing linking or doing static linking, you can ignore the list of packages returned. I assume this is where package environment files are read. So in addition to nothing being documented, this semantic change was made to a function with the innocuous name of `setSessionDynFlags`. Please don't do that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 19 21:27:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Aug 2018 21:27:57 -0000 Subject: [GHC] #15535: Expose the StableName constructor In-Reply-To: <045.6f45bd0659fffa92c0b169d118d7bd0a@haskell.org> References: <045.6f45bd0659fffa92c0b169d118d7bd0a@haskell.org> Message-ID: <060.f3da0da0f77f6e402f3d43035a499b33@haskell.org> #15535: Expose the StableName constructor -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5078 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D5078 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 19 23:01:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Aug 2018 23:01:12 -0000 Subject: [GHC] #15443: ghc panic when running GI.init on intero REPL In-Reply-To: <050.29c9f5cf48c2b9e3ef9ab7db906ae6c7@haskell.org> References: <050.29c9f5cf48c2b9e3ef9ab7db906ae6c7@haskell.org> Message-ID: <065.4102c1a8488aa8e71ce5a43ea8cdf906@haskell.org> #15443: ghc panic when running GI.init on intero REPL --------------------------------+-------------------------------------- Reporter: esclerofilo | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.4.3 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------+-------------------------------------- Changes (by kabuhr): * status: new => closed * resolution: => duplicate Comment: This looks like a duplicate of #14963. I've confirmed that commit Phab:rGHC4a931665e41b fixes the test case given in comment:1. I wasn't able to directly confirm that it fixes the originally reported issue, but that issue matches the pattern described in trac:14963:comment:8 which should be fixed by this commit, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 04:59:28 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 04:59:28 -0000 Subject: [GHC] #8441: Allow family instances in an hs-boot file In-Reply-To: <047.1fa915ff10b87e82918754b9e5d340d2@haskell.org> References: <047.1fa915ff10b87e82918754b9e5d340d2@haskell.org> Message-ID: <062.3221683db5a62d4172e8c58ed5172231@haskell.org> #8441: Allow family instances in an hs-boot file -------------------------------------+------------------------------------- Reporter: goldfire | Owner: ezyang Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: backpack, | TypeFamilies, hs-boot Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by isovector): Was just bitten by this; annoyingly the associated type family instance in question is provided as a default by the typeclass. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 06:50:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 06:50:13 -0000 Subject: [GHC] #806: hGetBufNonBlocking doesn't work on Windows In-Reply-To: <053.4faf11bcb1c323d37868059a7808a067@haskell.org> References: <053.4faf11bcb1c323d37868059a7808a067@haskell.org> Message-ID: <068.d07df78903eb79b833f4c8127a11f321@haskell.org> #806: hGetBufNonBlocking doesn't work on Windows -----------------------------------+---------------------------------- Reporter: titto@… | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 6.4.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: hGetBuf001 Blocked By: 11394 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+---------------------------------- Changes (by Phyx-): * owner: (none) => Phyx- * blockedby: => 11394 * milestone: ⊥ => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 06:50:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 06:50:55 -0000 Subject: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@haskell.org> References: <047.b31f95b84e60784da45a33105d44ed84@haskell.org> Message-ID: <062.55c2ed11fffb5022fa986f8bdaacb8c5@haskell.org> #2189: hSetBuffering stdin NoBuffering doesn't work on Windows -------------------------------------+------------------------------------- Reporter: FalconNL | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 6.8.2 Resolution: | Keywords: hsetbuffering | buffering buffer Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: 11394 | Blocking: Related Tickets: #11394, #13440 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: (none) => Phyx- * blockedby: => 11394 * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 06:51:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 06:51:43 -0000 Subject: [GHC] #2408: threadWaitRead on mingw32 threaded causes internal error In-Reply-To: <044.646a5d9cf31ef2594dbfe492fec77132@haskell.org> References: <044.646a5d9cf31ef2594dbfe492fec77132@haskell.org> Message-ID: <059.98b5bbdd7f05f3f0f94e87fee3d31cce@haskell.org> #2408: threadWaitRead on mingw32 threaded causes internal error -----------------------------------+----------------------------- Reporter: kirby | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: 11394 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+----------------------------- Changes (by Phyx-): * owner: (none) => Phyx- * blockedby: => 11394 * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 06:53:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 06:53:33 -0000 Subject: [GHC] #3081: Double output after Ctrl+C on Windows In-Reply-To: <051.84cd0947da97d4cf55fa6f13b11c0732@haskell.org> References: <051.84cd0947da97d4cf55fa6f13b11c0732@haskell.org> Message-ID: <066.bf8270e143ff3887f583a16120c2d9f2@haskell.org> #3081: Double output after Ctrl+C on Windows -----------------------------------+------------------------------ Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Runtime System | Version: 6.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11394 | Differential Rev(s): Wiki Page: | -----------------------------------+------------------------------ Changes (by Phyx-): * related: => #11394 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 06:54:14 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 06:54:14 -0000 Subject: [GHC] #4471: Incorrect Unicode output on Windows Console In-Reply-To: <046.0459baeecbdbac5352442349bd351ed0@haskell.org> References: <046.0459baeecbdbac5352442349bd351ed0@haskell.org> Message-ID: <061.07b54abe7bd5a5e3012147a436120d6a@haskell.org> #4471: Incorrect Unicode output on Windows Console -------------------------------------+------------------------------------- Reporter: sankeld | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: 11394 | Blocking: Related Tickets: #11394 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: (none) => Phyx- * blockedby: => 11394 * milestone: => 8.8.1 Comment: Fixed in new I/O manager. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 06:55:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 06:55:48 -0000 Subject: [GHC] #5797: readRawBufferPtr cannot be interrupted by exception on Windows with -threaded In-Reply-To: <048.3736f5643746a43df87c9b05401ef4e8@haskell.org> References: <048.3736f5643746a43df87c9b05401ef4e8@haskell.org> Message-ID: <063.20f65e666b3de8d5840ede566bd99730@haskell.org> #5797: readRawBufferPtr cannot be interrupted by exception on Windows with -threaded -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 7.2.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: #11394 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: (none) => Phyx- * related: => #11394 * milestone: ⊥ => 8.8.1 Comment: Will also require patches to network. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 06:58:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 06:58:09 -0000 Subject: [GHC] #7353: Make system IO interruptible on Windows In-Reply-To: <048.cfc723cf8062d55ebdf5fa24c2f6c705@haskell.org> References: <048.cfc723cf8062d55ebdf5fa24c2f6c705@haskell.org> Message-ID: <063.b1cc6a75e9ac7b89c1cd0f901d6915bf@haskell.org> #7353: Make system IO interruptible on Windows -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: 11394 | Blocking: Related Tickets: #8684 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: refold => Phyx- * blockedby: => 11394 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 06:58:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 06:58:55 -0000 Subject: [GHC] #7593: Unable to print exceptions of unicode identifiers In-Reply-To: <044.180348374c60284a01c4dfa59f341d42@haskell.org> References: <044.180348374c60284a01c4dfa59f341d42@haskell.org> Message-ID: <059.77a290aad662424bcba2d20688313e07@haskell.org> #7593: Unable to print exceptions of unicode identifiers -------------------------------------+------------------------------------- Reporter: dagit | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: 11394 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: (none) => Phyx- * blockedby: => 11394 * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 06:59:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 06:59:26 -0000 Subject: [GHC] #10542: Incorrect Unicode input on Windows Console In-Reply-To: <045.3387c3cc5f6c1e19d58646a0ead1675d@haskell.org> References: <045.3387c3cc5f6c1e19d58646a0ead1675d@haskell.org> Message-ID: <060.c5403ce3c25e7b20e448201765148383@haskell.org> #10542: Incorrect Unicode input on Windows Console -------------------------------------+------------------------------------- Reporter: ptroev | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: windows stdin | utf-8 cmd chcp 65001 getLine Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: 11394 | Blocking: Related Tickets: #11394, #4471 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: (none) => Phyx- * blockedby: => 11394 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 07:00:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 07:00:55 -0000 Subject: [GHC] #12873: hWaitForInput with socket as handle excepts on windows In-Reply-To: <044.1ddaa628578738df0ad8573626efc264@haskell.org> References: <044.1ddaa628578738df0ad8573626efc264@haskell.org> Message-ID: <059.b2a8ad7af3c422f382444431b8bc3d94@haskell.org> #12873: hWaitForInput with socket as handle excepts on windows ----------------------------------+-------------------------------------- Reporter: bwurk | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 11394 | Blocking: Related Tickets: #7353 | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Changes (by Phyx-): * blockedby: => 11394 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 07:01:40 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 07:01:40 -0000 Subject: [GHC] #14530: hWaitForInput causes the program to abort on Windows In-Reply-To: <047.b2bc1211baaf66413ffab8f8c11dbb08@haskell.org> References: <047.b2bc1211baaf66413ffab8f8c11dbb08@haskell.org> Message-ID: <062.03e62b4efbddc2ea2101975ca61f6497@haskell.org> #14530: hWaitForInput causes the program to abort on Windows -----------------------------------+-------------------------------------- Reporter: dnadales | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.0.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 11394 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Changes (by Phyx-): * owner: (none) => Phyx- * blockedby: => 11394 * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 07:05:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 07:05:37 -0000 Subject: [GHC] #4942: GHC.ConsoleHandler does not call back application when Close button is pressed In-Reply-To: <045.ed5c0707de124f67b6d45637526a6c9d@haskell.org> References: <045.ed5c0707de124f67b6d45637526a6c9d@haskell.org> Message-ID: <060.b874ece1da4c7d22c2f3178e66a2405a@haskell.org> #4942: GHC.ConsoleHandler does not call back application when Close button is pressed -------------------------------------+------------------------------------- Reporter: Amatic | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: GHC API | Version: 6.12.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocked By: | Blocking: Related Tickets: #11394 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * related: => #11394 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 07:11:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 07:11:04 -0000 Subject: [GHC] #11394: Base should use native Win32 IO on Windows In-Reply-To: <046.3c711b381d30e89343445554e3990623@haskell.org> References: <046.3c711b381d30e89343445554e3990623@haskell.org> Message-ID: <061.148c0e2e671ccbfa8de40d12cf9f161e@haskell.org> #11394: Base should use native Win32 IO on Windows -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Phyx- Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 806, 2189, | 2408, 4471, 7353, 7593, 10542, | 12873, 14530 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > There are a variety of issues caused by the impedance mismatch between > GHC's use of Posix I/O interfaces on Windows (particularly with respect > to console I/O), > > * #10542: Incorrect Unicode input on Windows Console > * #7593: Unable to print exceptions of unicode identifiers > * #4471: Incorrect Unicode output on Windows Console > * #2189: hSetBuffering stdin NoBuffering doesn't work on Windows > > As pointed on in ticket:2189#comment:12 the ultimate solution to this > would be to move all of GHC's IO to use the respective Win32 interfaces. > > = Also relevant = > * #7353: Windows lacks support in the I/O manager > * #806: hGetBufNonBlocking doesn't work on Windows > * #3081: Double output after Ctrl+C on Windows > * #13440: `putStr` has different behaviour on Windows New description: There are a variety of issues caused by the impedance mismatch between GHC's use of Posix I/O interfaces on Windows (particularly with respect to console I/O), * #10542: Incorrect Unicode input on Windows Console * #7593: Unable to print exceptions of unicode identifiers * #4471: Incorrect Unicode output on Windows Console * #2189: hSetBuffering stdin NoBuffering doesn't work on Windows As pointed on in ticket:2189#comment:12 the ultimate solution to this would be to move all of GHC's IO to use the respective Win32 interfaces. = Also relevant = * #7353: Windows lacks support in the I/O manager * #806: hGetBufNonBlocking doesn't work on Windows * #3081: Double output after Ctrl+C on Windows * #13440: `putStr` has different behaviour on Windows * #4942: `GHC.ConsoleHandler` does not call back application when Close button is pressed. -- Comment (by Phyx-): Started designing the last piece of the puzzle which is non-threaded RTS. The non-threaded I/O manager seems to have a completely different interface on Windows, going so far as to having 3 Windows only prim-ops. Trying to understand why... With the threaded RTS I still have to track down a race condition somewhere. I think it has to do with the foreign pointer's finalizers... Wonder if I can turn off GC completely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 07:12:14 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 07:12:14 -0000 Subject: [GHC] #15535: Expose the StableName constructor In-Reply-To: <045.6f45bd0659fffa92c0b169d118d7bd0a@haskell.org> References: <045.6f45bd0659fffa92c0b169d118d7bd0a@haskell.org> Message-ID: <060.68f1995f855522e5564256fd02f1cbbc@haskell.org> #15535: Expose the StableName constructor -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5078 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Out of curiosity, how do you coerce a `StableName` to a `StableName#`? `StableName` is a `data` so you'd have to first coerce it to constructor with one non-pointer field that is as large as a `StableName#`, and then read that field. Sounds tricky ... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 07:27:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 07:27:27 -0000 Subject: [GHC] #15535: Expose the StableName constructor In-Reply-To: <045.6f45bd0659fffa92c0b169d118d7bd0a@haskell.org> References: <045.6f45bd0659fffa92c0b169d118d7bd0a@haskell.org> Message-ID: <060.6146f47ad0cb1137c7592dbf0853cc4c@haskell.org> #15535: Expose the StableName constructor -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5078 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Not tricky. Just gross. {{{#!hs data StableName_ a = StableName_ (StableName# a) unwrap :: StableName a -> StableName# a unwrap sn = case unsafeCoerce sn of StableName_ sn# -> sn# }}} And conversely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 13:01:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 13:01:31 -0000 Subject: [GHC] #15220: ScopedTypeVariables binds a non-existent variable In-Reply-To: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> References: <047.a14e260f2e72ed37873972c527c21a7d@haskell.org> Message-ID: <062.794c02c1058aa0abc730ce5fec4597c8@haskell.org> #15220: ScopedTypeVariables binds a non-existent variable -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm no longer sure what the bug (if any) is here. It all looks fine to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 13:35:41 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 13:35:41 -0000 Subject: [GHC] #15487: "Ambiguos occurrence" error message uses strange qualification In-Reply-To: <049.ec049728f6597ec6e0ea496f9893f7ce@haskell.org> References: <049.ec049728f6597ec6e0ea496f9893f7ce@haskell.org> Message-ID: <064.8e7e40df15b45d5ceddbbe797c1da3f7@haskell.org> #15487: "Ambiguos occurrence" error message uses strange qualification -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): A fix is on `wip/T13064`, and will land when that does. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 13:36:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 13:36:57 -0000 Subject: [GHC] #15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1) In-Reply-To: <050.f9874a3a6f2af319ca747dcd6ecdf690@haskell.org> References: <050.f9874a3a6f2af319ca747dcd6ecdf690@haskell.org> Message-ID: <065.0c037115528830b6e1995b3a67a307bd@haskell.org> #15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1) -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I've fixed this properly; see #13064 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 13:37:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 13:37:09 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.a4f369099ace2cc1848a076c632fa876@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I have fixed this on `wip/T13064`; Ben will complete. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 13:48:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 13:48:54 -0000 Subject: [GHC] #15426: `elemIndex` and `findIndex` still can't fuse In-Reply-To: <045.556cc5a15fe7d0c4bec73444eba7ef79@haskell.org> References: <045.556cc5a15fe7d0c4bec73444eba7ef79@haskell.org> Message-ID: <060.3313d2a8a48acfc73374896b47584558@haskell.org> #15426: `elemIndex` and `findIndex` still can't fuse -------------------------------------+------------------------------------- Reporter: kabuhr | Owner: kabuhr Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: libraries/base | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/perf/should_run/T15426.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D5063 -------------------------------------+------------------------------------- Comment (by simonpj): OK fine. So if I understand aright: * Nofib gets no better but no worse * More fusion happens in other cases (eg the Description) Sounds good to me. It would be good to include a perf regression test that will trip if fusion fails in the future. And a Note to explain the INLINABLE pragma. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 14:03:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 14:03:51 -0000 Subject: [GHC] #15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1) In-Reply-To: <050.f9874a3a6f2af319ca747dcd6ecdf690@haskell.org> References: <050.f9874a3a6f2af319ca747dcd6ecdf690@haskell.org> Message-ID: <065.71c8fe270d47fb610f301797475836d0@haskell.org> #15393: Regression: Detection of unused imports is imprecise (since GHC 8.0.1) -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by SimonHengel): Simon, your are a hero! And I feel I should say sorry for my harsh tone! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 14:10:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 14:10:46 -0000 Subject: [GHC] #15542: DuplicateRecordFields not honored within a data family? In-Reply-To: <048.60e65b226bb83891446d0a3a23f02b31@haskell.org> References: <048.60e65b226bb83891446d0a3a23f02b31@haskell.org> Message-ID: <063.42fb74f57ad3eb53b70147c24d05991b@haskell.org> #15542: DuplicateRecordFields not honored within a data family? -------------------------------------+------------------------------------- Reporter: michalrus | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => ORF * status: new => infoneeded Comment: It's hard to say what's going on without some kind of code to look at. Are you able to build your code against GHC 8.6.1 to see if it works there? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 14:36:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 14:36:37 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation In-Reply-To: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> References: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> Message-ID: <061.f3b3584ae048ad04c27ae9bb385b7641@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): How can I demonstrate without Criterion? (trying to install criterion with my in-place HEAD compiler leads to a raft of dependency conflicts that I do not understand.) I tried just running `test0 src1`, `test1 src1`, `test2 src1` but they all behaved identically. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 14:55:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 14:55:56 -0000 Subject: [GHC] #15539: Regression since 7.10.3, "variable not in scope" errors sometimes get buried under a sea of much less relevant errors. In-Reply-To: <044.4a4f045286e58c78e289f91b1fd67dbd@haskell.org> References: <044.4a4f045286e58c78e289f91b1fd67dbd@haskell.org> Message-ID: <059.d4be8c67a39de945cc38c0878f9377ff@haskell.org> #15539: Regression since 7.10.3, "variable not in scope" errors sometimes get buried under a sea of much less relevant errors. -------------------------------------+------------------------------------- Reporter: Wizek | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ecc0ddf65b1e2700f83f643fffdd41e966013332/ghc" ecc0ddf6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ecc0ddf65b1e2700f83f643fffdd41e966013332" Initialise cec_suppress properly In TcErrors, cec_suppress is used to suppress low-priority errors in favour of truly insoluble ones. But I was failing to initialise it correcly at top level, which resulted in Trac #15539. Easy to fix. A few regression tests have fewer errors reported, but that seems to be an improvement. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 14:58:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 14:58:50 -0000 Subject: [GHC] #15539: Regression since 7.10.3, "variable not in scope" errors sometimes get buried under a sea of much less relevant errors. In-Reply-To: <044.4a4f045286e58c78e289f91b1fd67dbd@haskell.org> References: <044.4a4f045286e58c78e289f91b1fd67dbd@haskell.org> Message-ID: <059.b5d834e09113cf3d0598dc44ee90486e@haskell.org> #15539: Regression since 7.10.3, "variable not in scope" errors sometimes get buried under a sea of much less relevant errors. -------------------------------------+------------------------------------- Reporter: Wizek | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | rename/should_fail/T15539 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => rename/should_fail/T15539 * resolution: => fixed Comment: Good point, thank you. An oversight in `TcErrors`. (The bug only shows up for top level errors. If you say even this: {{{ foo :: forall b. String foo = show a where a = baz }}} which puts the `Show a` constrain under an implication, then the error is suppressed already. It just wasn't happening for constraints that had no enclosing implication. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 15:28:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 15:28:03 -0000 Subject: [GHC] #15503: interpreter: sequence_ (replicate 100000000 (return ())) gobbles up memory In-Reply-To: <044.e7b47664b0b4e75e999d3e8ddaf8b64f@haskell.org> References: <044.e7b47664b0b4e75e999d3e8ddaf8b64f@haskell.org> Message-ID: <059.a5fec3211e37cfcaa5b0b0631b526fab@haskell.org> #15503: interpreter: sequence_ (replicate 100000000 (return ())) gobbles up memory -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: GHCi | Version: 8.4.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: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: low => high * milestone: 8.6.1 => 8.8.1 Comment: Bumping priority since this shouldn't be so hard to nail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 15:30:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 15:30:36 -0000 Subject: [GHC] #12482: Infinite compilation time when using wrongly ordered constraints In-Reply-To: <046.385955bbc36fdf0c78384562d17bec02@haskell.org> References: <046.385955bbc36fdf0c78384562d17bec02@haskell.org> Message-ID: <061.7e3ce267eaf76e68a6114398946f28ad@haskell.org> #12482: Infinite compilation time when using wrongly ordered constraints -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.8.1 Comment: Danilo2, can you still reproduce this with 8.6? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 15:31:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 15:31:27 -0000 Subject: [GHC] #12482: Infinite compilation time when using wrongly ordered constraints In-Reply-To: <046.385955bbc36fdf0c78384562d17bec02@haskell.org> References: <046.385955bbc36fdf0c78384562d17bec02@haskell.org> Message-ID: <061.4402f582bee3b5c71e8f30afef7fe50d@haskell.org> #12482: Infinite compilation time when using wrongly ordered constraints -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Danilo2: is this still happening for you with 8.4 or 8.6? Otherwise we'll just close it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 15:51:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 15:51:55 -0000 Subject: [GHC] #15539: Regression since 7.10.3, "variable not in scope" errors sometimes get buried under a sea of much less relevant errors. In-Reply-To: <044.4a4f045286e58c78e289f91b1fd67dbd@haskell.org> References: <044.4a4f045286e58c78e289f91b1fd67dbd@haskell.org> Message-ID: <059.92938e13812c02caeaded19497741421@haskell.org> #15539: Regression since 7.10.3, "variable not in scope" errors sometimes get buried under a sea of much less relevant errors. -------------------------------------+------------------------------------- Reporter: Wizek | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | rename/should_fail/T15539 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Wizek): Replying to [comment:2 simonpj]: Wonderful. Thank you! This will greatly improve some of my interactions with GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 15:55:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 15:55:09 -0000 Subject: [GHC] #15426: `elemIndex` and `findIndex` still can't fuse In-Reply-To: <045.556cc5a15fe7d0c4bec73444eba7ef79@haskell.org> References: <045.556cc5a15fe7d0c4bec73444eba7ef79@haskell.org> Message-ID: <060.e94206e53a15504c10f45191f8e00c99@haskell.org> #15426: `elemIndex` and `findIndex` still can't fuse -------------------------------------+------------------------------------- Reporter: kabuhr | Owner: kabuhr Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: libraries/base | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/perf/should_run/T15426.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D5063 -------------------------------------+------------------------------------- Changes (by kabuhr): * status: new => patch Comment: Yes, that summary is correct. In the current Phab:D5063 that's pending review, I have added a performance regression test `T15426.hs`, and I have annotated the change in `OldList.hs` with: {{{ #!haskell -- (Note that making this INLINABLE instead of INLINE allows -- 'findIndex' to fuse, fixing #15426.) }}} assuming that's sufficient. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 16:29:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 16:29:12 -0000 Subject: [GHC] #15543: Binary crashes under dtrace Message-ID: <045.599ac00709c714a8189c60aa1b140c4c@haskell.org> #15543: Binary crashes under dtrace -------------------------------------+------------------------------------- Reporter: last_g | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research needed Component: Compiler | Version: 8.4.3 Keywords: dtrace, crash | Operating System: MacOS X Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I'm trying to attach to the simple binary with DTrace command ({{{sudo dtrace -n 'pid$1:::' `ps aux | grep FibbSlow | grep -v grep | awk '{print $2}'` }}}) it crashes with various outcomes. This happens on both GHC 8.4.3 from `stack` and manually built ghc from the master branch. Crashes: {{{ lastg-mbp:t lastg$ ./FibbSlow.master 55 FibbSlow.master: internal error: scavenge: unimplemented/strange closure type 13369548 @ 0x420021abb0^[[B (GHC version 8.7.20180817 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} {{{ lastg-mbp:t lastg$ ./FibbSlow.stack.8.4 55 FibbSlow.stack.8.4: internal error: scavenge_one: strange object 13369548 (GHC version 8.4.3 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap: 6 }}} {{{ lastg-mbp:t lastg$ ./FibbSlow.stack.8.4 55 FibbSlow.stack.8.4: internal error: scavenge_one: strange object 13369548 (GHC version 8.4.3 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap: 6 }}} {{{ lastg-mbp:t lastg$ ./FibbSlow.stack.8.4 55 Segmentation fault: 11 }}} Source code for the binary: https://gist.github.com/last-g/cfddab60a8520eb51214ef2a7bc48ec2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 17:48:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 17:48:35 -0000 Subject: [GHC] #15513: How to pass "-hide-all-packages" to the GHC API? In-Reply-To: <048.48cd47e57c6c0c5d32e84baf3ee31f48@haskell.org> References: <048.48cd47e57c6c0c5d32e84baf3ee31f48@haskell.org> Message-ID: <063.fd080522a7cce1e5624c167a3ea25a39@haskell.org> #15513: How to pass "-hide-all-packages" to the GHC API? -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Resolution: | Keywords: environment | file API Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15541 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lspitzner): * related: => #15541 Old description: > In brittany, we have make use of the GHC API e.g. in the following > fashion: > > {{{#!hs > parseModuleFromString > :: [String] > -> System.IO.FilePath > -> (GHC.DynFlags -> IO (Either String a)) > -> String > -> IO (Either String (ExactPrint.Anns, GHC.ParsedSource, a)) > parseModuleFromString args fp dynCheck str = > mask_ $ ExactPrint.ghcWrapper $ ExceptT.runExceptT $ do > dflags0 <- lift $ ExactPrint.initDynFlagsPure > fp str > (dflags1, leftover, warnings) <- lift > $ GHC.parseDynamicFlagsCmdLine dflags0 (GHC.noLoc <$> args) > when (not $ null leftover) > $ ExceptT.throwE > $ "when parsing ghc flags: leftover flags: " > ++ show (leftover <&> \(L _ s) -> s) > when (not $ null warnings) > $ ExceptT.throwE > $ "when parsing ghc flags: encountered warnings: " > ++ show (warnings <&> warnExtractorCompat) > dynCheckRes <- ExceptT.ExceptT $ liftIO $ dynCheck dflags1 > let res = ExactPrint.parseModuleFromStringInternal dflags1 fp str > case res of > Left (span, err) -> ExceptT.throwE $ show span ++ ": " ++ err > Right (a , m ) -> pure (a, m, dynCheckRes) > }}} > > This code unfortunately picks up "package environment files", which I > take it is not at all necessary for this use-case: Brittany only requires > parsing functionality, so external packages should be irrelevant. > "Unfortunately", because the package environment files can easily become > stale, which in turn breaks the API. > > The users' guide mentions the "-hide-all-packages" flag, but my attempts > to pass this to the API so far have failed. What I have tried is calling > `parseDynamicFlagsCmdLine` with "-hide-all-packages" as an argument, and > using the resulting dynflags afterwards. This appears to be without > effect, I think even when it is the first thing executed inside of > `runGhc`. New description: In brittany, we have make use of the GHC API e.g. in the following fashion: {{{#!hs parseModuleFromString :: [String] -> System.IO.FilePath -> (GHC.DynFlags -> IO (Either String a)) -> String -> IO (Either String (ExactPrint.Anns, GHC.ParsedSource, a)) parseModuleFromString args fp dynCheck str = mask_ $ ExactPrint.ghcWrapper $ ExceptT.runExceptT $ do dflags0 <- lift $ ExactPrint.initDynFlagsPure fp str (dflags1, leftover, warnings) <- lift $ GHC.parseDynamicFlagsCmdLine dflags0 (GHC.noLoc <$> args) when (not $ null leftover) $ ExceptT.throwE $ "when parsing ghc flags: leftover flags: " ++ show (leftover <&> \(L _ s) -> s) when (not $ null warnings) $ ExceptT.throwE $ "when parsing ghc flags: encountered warnings: " ++ show (warnings <&> warnExtractorCompat) dynCheckRes <- ExceptT.ExceptT $ liftIO $ dynCheck dflags1 let res = ExactPrint.parseModuleFromStringInternal dflags1 fp str case res of Left (span, err) -> ExceptT.throwE $ show span ++ ": " ++ err Right (a , m ) -> pure (a, m, dynCheckRes) }}} This code unfortunately picks up "package environment files", which I take it is not at all necessary for this use-case: Brittany only requires parsing functionality, so external packages should be irrelevant. "Unfortunately", because the package environment files can easily become stale, which in turn breaks the API. The users' guide mentions the "-hide-all-packages" flag, but my attempts to pass this to the API so far have failed. What I have tried is calling `parseDynamicFlagsCmdLine` with "-hide-all-packages" as an argument, and using the resulting dynflags afterwards. This appears to be without effect, ~~I think even when it is the first thing executed inside of `runGhc`~~ (not entirely correct, see below). -- Comment: {{{#!hs dflags0 <- GHC.getSessionDynFlags (dflags1, [], []) <- GHC.parseDynamicFlagsCmdLine dflags0 [GHC.noLoc "-hide-all-packages"] GHC.setSessionDynFlags dflags1 }}} must be called before any other invocation of `setSessionDynFlags`. I'll leave this open as it is unconfirmed and as a reminder to add this snippet or a better version to the appropriate (API) docs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 18:40:30 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 18:40:30 -0000 Subject: [GHC] #11955: Haddock documentation for pattern synonyms printed with explicit forall quantifiers In-Reply-To: <046.a6a2b187c86fbb5c93bbd55a34566418@haskell.org> References: <046.a6a2b187c86fbb5c93bbd55a34566418@haskell.org> Message-ID: <061.70c57fecbaece7aec44d2a7c0dddf392@haskell.org> #11955: Haddock documentation for pattern synonyms printed with explicit forall quantifiers -------------------------------------+------------------------------------- Reporter: darchon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1-rc3 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjakobi): * cc: sjakobi (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 18:45:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 18:45:27 -0000 Subject: [GHC] #15295: Haddock options should be concatenated (was: Haddock options should be concatened) In-Reply-To: <046.234e50e311e74e13a22a289f266ad26f@haskell.org> References: <046.234e50e311e74e13a22a289f266ad26f@haskell.org> Message-ID: <061.20e4a6589b50086469099019b5d3fea0@haskell.org> #15295: Haddock options should be concatenated -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: haddock Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 18:51:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 18:51:32 -0000 Subject: [GHC] #5518: Some unicode symbols are not allow in literal characters or strings In-Reply-To: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> References: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> Message-ID: <059.85af744eb743b2dace9ad9dc461bf9cf@haskell.org> #5518: Some unicode symbols are not allow in literal characters or strings ---------------------------------+-------------------------------------- Reporter: ertai | Owner: ulysses4ever Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5066 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by ulysses4ever): * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 19:24:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 19:24:00 -0000 Subject: [GHC] #14341: Show instance for TypeReps is a bit broken In-Reply-To: <045.cd028c896befff283e5e70cbc43095b2@haskell.org> References: <045.cd028c896befff283e5e70cbc43095b2@haskell.org> Message-ID: <060.5057dfd2dfc0a2a930a5d59d38190344@haskell.org> #14341: Show instance for TypeReps is a bit broken -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.2.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4084 Wiki Page: | -------------------------------------+------------------------------------- Comment (by PhilippD): There's also a problem with displaying partially applied tuple type constructors: {{{ λ> typeRep @((,,)) () λ> typeRep @((,,,,,,,) Int Word) (Int,Word) }}} The problem seems to be that `showTypeable` doesn't check the arity of the constructor and just applies `showArgs` to the type arguments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 21:10:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 21:10:50 -0000 Subject: [GHC] #15544: Possible segmentation fault in cryptohash-sha256 testsuite Message-ID: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> #15544: Possible segmentation fault in cryptohash-sha256 testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ cabal get cryptohash-sha256-0.11.101.0 $ cabal new-run -w ghc-8.6.1 --enable-test --allow-newer=cryptohash- sha256:base,*:stm,*:tasty,async:base test:test-sha256 -- -j 8 --quickcheck-tests 9999 }}} Eventually the program will start spamming stderr with `test-sha256: lost signal due to full pipe: 11` repeatedly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 21:28:44 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 21:28:44 -0000 Subject: [GHC] #15544: Possible segmentation fault in cryptohash-sha256 testsuite In-Reply-To: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> References: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> Message-ID: <061.7f971c58d7445ff809a98bb906ec527f@haskell.org> #15544: Possible segmentation fault in cryptohash-sha256 testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => highest Comment: Sometimes the program also outright segfaults. The stderr message appears to be due to the timer manager control fd filling. I suspect this thread is killed due to the segfault and consequently the pipe fills, resulting in the messages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 21:38:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 21:38:11 -0000 Subject: [GHC] #13477: Turn cIntegerLibraryType into a dynflag In-Reply-To: <046.1be05c5fa445155bed193903c2e35749@haskell.org> References: <046.1be05c5fa445155bed193903c2e35749@haskell.org> Message-ID: <061.872ee67c4d8aea958d725d31e569fbd4@haskell.org> #13477: Turn cIntegerLibraryType into a dynflag -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: GHC API | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): It keeps happening that when I want to file a bug report, I find that I have already filed it… A `ghc`-the-library that allows users to choose the integer library they want would be great. For example asterius, a WebAssembly backend in the making, would then have one reason less to build on a patched `ghc` (see https://tweag.github.io/asterius/building/) There are two issues: * Using `S#` if `integer-gmp` is used. Can easily be made dependent on the `DynFlags`. * Using the right unit id in `gHC_INTEGER_TYPE`, which is used in all kind of `…Name` symbols, which are used in other top-level definitions like `CoreRules`. Would be more invasive to make that dependent on `DynFlags`. I wonder if maybe GHC should just assume that the unit name is `integer`, and the build script of `integer-gmp` resp. `integer-simple` passes `-this-unit-id integer` instead? What would break in this simple model? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 21:47:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 21:47:24 -0000 Subject: [GHC] #15545: Forced to enable TypeInType because of (i ~ i) Message-ID: <051.d941c2a1d44582666aa9c16bceab18dc@haskell.org> #15545: Forced to enable TypeInType because of (i ~ i) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I don't know if this is a bug but `i ~ i` holds by reflexivity so I would not have expected it to require `TypeInType` {{{ $ ghci -ignore-dot-ghci GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help Prelude> :set -XPolyKinds -XGADTs Prelude> import Data.Kind Prelude Data.Kind> data NP :: (k -> Type) -> (i -> Type) where NP :: f a -> NP f a :3:45: error: • Data constructor ‘NP’ constrains the choice of kind parameter: i ~ i Use TypeInType to allow this • In the definition of data constructor ‘NP’ In the data type declaration for ‘NP’ Prelude Data.Kind> }}} I would rather expect the warning I get after enabling `TypeInType` {{{ Prelude Data.Kind> :set -XTypeInType Prelude Data.Kind> data NP :: (k -> Type) -> (i -> Type) where NP :: f a -> NP f a :8:28: error: • Couldn't match ‘k’ with ‘i’ • In the data declaration for ‘NP’ }}} ---- '''ps''' making sure this is OK as well; it works after enabling `-XTypeInType` and quantifying with `-XRankNTypes` (is this using polymorphic recursion?) {{{ Prelude Data.Kind> :set -XTypeInType -XRankNTypes Prelude Data.Kind> data NP :: forall i k. (k -> Type) -> (i -> Type) where NP :: f a -> NP f a Prelude Data.Kind> :t NP NP :: forall i (f :: i -> *) (a :: i). f a -> NP f a }}} it also works for {{{#!hs data NP :: forall k. (k -> Type) -> (i -> Type) where NP :: f a -> NP f a data NP :: forall i. (k -> Type) -> (i -> Type) where NP :: f a -> NP f a data NP :: (k -> Type) -> forall i. (i -> Type) where NP :: f a -> NP f a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 21:59:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 21:59:00 -0000 Subject: [GHC] #15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite (was: Possible segmentation fault in cryptohash-sha256 testsuite) In-Reply-To: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> References: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> Message-ID: <061.083a6b4a58f764afd919ab5a7d5a2152@haskell.org> #15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 21:59:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 21:59:27 -0000 Subject: [GHC] #15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite In-Reply-To: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> References: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> Message-ID: <061.187e1276179786ca8b4c6ebc8d10e8ea@haskell.org> #15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > {{{ > $ cabal get cryptohash-sha256-0.11.101.0 > $ cabal new-run -w ghc-8.6.1 --enable-test --allow-newer=cryptohash- > sha256:base,*:stm,*:tasty,async:base test:test-sha256 -- -j 8 > --quickcheck-tests 9999 > }}} > > Eventually the program will start spamming stderr with `test-sha256: lost > signal due to full pipe: 11` repeatedly. New description: {{{ $ cabal get cryptohash-sha256-0.11.101.0 $ cabal new-run -w ghc-8.6.1 --enable-test --allow-newer=cryptohash- sha256:base,*:stm,*:tasty,async:base test:test-sha256 -- -j 8 --quickcheck-tests 9999 }}} Eventually the program will start spamming stderr with `test-sha256: lost signal due to full pipe: 11` repeatedly. This apparently only started with 8.6.1. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 22:21:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 22:21:54 -0000 Subject: [GHC] #15541: package environment files and the GHC API In-Reply-To: <048.226f5c575460b148605c8a51ca4e89c3@haskell.org> References: <048.226f5c575460b148605c8a51ca4e89c3@haskell.org> Message-ID: <063.fed3bbd4a65d5d30dfeff4b35b48f5c6@haskell.org> #15541: package environment files and the GHC API -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: GHC API | Version: 8.4.3 Resolution: | Keywords: package | environment Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #15513 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The motivation for this design is that package environments should be transparent to the user, giving tooling a means of configuring GHC for a project without further user intervention. This is much the same way GHC will automatically look at the environment's global and user package databases. That being said, package environments are often much more transient and it's not hard to see how this might go wrong. I see a few ways forward here: * Rip the `interpretPackageEnv` call out of `setSessionDynFlags` (or rather, `initPackages`) and require API users to do this manually. * Add a flag to `setSessionDynFlags` specifying whether package environments should be respected * Keep the status quo but document it lspitzner, perhaps you have an opinion on what this interface should look like? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 22:27:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 22:27:21 -0000 Subject: [GHC] #15541: package environment files and the GHC API In-Reply-To: <048.226f5c575460b148605c8a51ca4e89c3@haskell.org> References: <048.226f5c575460b148605c8a51ca4e89c3@haskell.org> Message-ID: <063.ba209d1b03e866026866a4e37afd5ff8@haskell.org> #15541: package environment files and the GHC API -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: GHC API | Version: 8.4.3 Resolution: | Keywords: package | environment Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #15513 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: dcoutts (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 22:27:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 22:27:37 -0000 Subject: [GHC] #15513: How to pass "-hide-all-packages" to the GHC API? In-Reply-To: <048.48cd47e57c6c0c5d32e84baf3ee31f48@haskell.org> References: <048.48cd47e57c6c0c5d32e84baf3ee31f48@haskell.org> Message-ID: <063.dc853af6b326cfa07cf6dd7feb768e6a@haskell.org> #15513: How to pass "-hide-all-packages" to the GHC API? -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Resolution: | Keywords: environment | file API Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15541 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: dcoutts (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 23:14:23 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 23:14:23 -0000 Subject: [GHC] #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# In-Reply-To: <048.a76989facca9d2ef0c59d6b7bfd86029@haskell.org> References: <048.a76989facca9d2ef0c59d6b7bfd86029@haskell.org> Message-ID: <063.a6ba96b33ebae274c0e8e7ac4717592d@haskell.org> #11143: Feature request: Add index/read/write primops with byte offset for ByteArray# -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: sjakobi Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: newcomers Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #4442 | Differential Rev(s): Phab:D4433 Wiki Page: | -------------------------------------+------------------------------------- Comment (by jberryman): I would also appreciate this. My use case is I'd like, for performance and coding simplicity, to be able to do potentially unaligned reads of Word64 when we're compiled for x86_64 arch. Library writers need to think about alignment when using the `Addr` interface to pinned ByteArrays, so I don't think it's a big deal to expose this (though docs could use improvement, see https://ghc.haskell.org/trac/ghc/ticket/14731) That said I would love it if the compiler didn't push this complexity down to library writers (both here and in the Addr load/store primops), and handled twiddling on architectures that don't support unaligned reads. I would like my code to be compatible but don't particularly care if there is a performance hit (99% of people are using x86). The alternative is I just have to write my own slow code and put it behind a CPP pragma. But it's not clear to me if vagarenko actually wants to do any unaligned reads (and I don't want to hijack this request). Perhaps they just want to do aligned reads on their heterogeneous structure. In that case you can write your own implementation easily by dividing the byte offset provided by the width of the payload you're requesting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 23:28:29 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 23:28:29 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.8515d41788733cda6edb45e576a481d7@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: core-libraries-committee@… (added) * milestone: => 8.8.1 Comment: I admit I'm a bit nervous about merging this. The fact that the new scheme results in so many warnings even in GHC's core libraries is deeply concerning. I suspect that this new scheme may break the guidance that the Core Libraries Committee (or, at very least, Ed Kmett) has long offered for dealing with additions to `Prelude`: adding a (seemingly redundant) import of `Prelude`. For instance, consider the case of the Semigroup/Monoid proposal (SMP), where `(<>)` was added to `Prelude`. Imagine that before SMP a user had a module with, {{{#!hs import Data.Semigroup (Semigroup, (<>)) squash :: Semigroup a => a -> a -> a squash = (<>) }}} However, post-SMP the import of `Data.Semigroup` is redundant, leading to a warning which would cause failures with `-Wall`. Of course, the user could drop the `import`, but only at the expense of compatibility with earlier GHC releases. One way around this is to guard the import with CPP, {{{#!hs #if MIN_VERSION_base(4,11,0) import Data.Semigroup (Semigroup, (<>)) #endif squash :: Semigroup a => a -> a -> a squash = (<>) }}} However, requiring this sort of refactoring stands in violation of the CLC's [[https://prime.haskell.org/wiki/Libraries/3-Release-Policy|Three Release Policy]] which states that no library change will cause `-Wall` failures that are avoidable only with CPP. This is why the CLC has instead recommended this solution instead: {{{#!hs import Data.Semigroup (Semigroup, (<>)) import Prelude squash :: Semigroup a => a -> a -> a squash = (<>) }}} Under the current redundancy check this throws no warnings (assuming something is used from `Prelude`). However, under the new scheme GHC deems the `Data.Semigroup` to be redundant. Moreover, under the new semantics I don't see any way to recover the previous level of compatibility short of CPP guards. Note that I'm not saying that either behavior is more correct; rather, I'm merely saying that a truly massive amount of code may be relying on the status quo and we should be very careful before making changes here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 20 23:45:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Aug 2018 23:45:48 -0000 Subject: [GHC] #14341: Show instance for TypeReps is a bit broken In-Reply-To: <045.cd028c896befff283e5e70cbc43095b2@haskell.org> References: <045.cd028c896befff283e5e70cbc43095b2@haskell.org> Message-ID: <060.5cad7ea8179c480318b7243c18e0af74@haskell.org> #14341: Show instance for TypeReps is a bit broken -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.2.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4084, Wiki Page: | Phab:D5080 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: Phab:D4084 => Phab:D4084, Phab:D5080 * milestone: => 8.6.1 Comment: I whipped up Phab:D5080 which solves the correctness problem mentioned in comment:3 simply. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 00:09:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 00:09:35 -0000 Subject: [GHC] #15535: Expose the StableName constructor In-Reply-To: <045.6f45bd0659fffa92c0b169d118d7bd0a@haskell.org> References: <045.6f45bd0659fffa92c0b169d118d7bd0a@haskell.org> Message-ID: <060.42220956466b5e54c1ed0c93ac21b0be@haskell.org> #15535: Expose the StableName constructor -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5078 Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"9c4e6c6b1affd410604f8f76ecf56abfcc5cccb6/ghc" 9c4e6c6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9c4e6c6b1affd410604f8f76ecf56abfcc5cccb6" Expose the StableName constructor * Move the definition of `StableName` from `System.Mem.StableName` to a new `GHC.StableName` module. * Expose the `StableName` data constructor from `GHC.StableName`. Once we have `UnliftedArray#`, this will enable `StableName`s to be stored in `UnliftedArray`s (from `primitive`) without unsafe coercions. Reviewers: hvr, bgamari, andrewthad, osa1 Reviewed By: osa1 Subscribers: osa1, rwbarton, carter GHC Trac Issues: #15535 Differential Revision: https://phabricator.haskell.org/D5078 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 00:18:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 00:18:18 -0000 Subject: [GHC] #15535: Expose the StableName constructor In-Reply-To: <045.6f45bd0659fffa92c0b169d118d7bd0a@haskell.org> References: <045.6f45bd0659fffa92c0b169d118d7bd0a@haskell.org> Message-ID: <060.117b1a2eca7d7294f1441b9db36ea294@haskell.org> #15535: Expose the StableName constructor -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: merge Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5078 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => merge Comment: If it's not too late to merge this for 8.6, that'd be great. Otherwise, we can wait for 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 00:19:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 00:19:33 -0000 Subject: [GHC] #15545: Forced to enable TypeInType because of (i ~ i) In-Reply-To: <051.d941c2a1d44582666aa9c16bceab18dc@haskell.org> References: <051.d941c2a1d44582666aa9c16bceab18dc@haskell.org> Message-ID: <066.4cfde2a11c473463c29c27ad435f62fa@haskell.org> #15545: Forced to enable TypeInType because of (i ~ i) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15195 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed * related: => #15195 * milestone: => 8.6.1 Comment: This is a rather cheeky solution, but this problem simply doesn't exist on GHC 8.6, since `TypeInType` is now simply a synonym for `DataKinds` and `PolyKinds`, and `PolyKinds` now grants access to all of the features that used to be exclusive to `TypeInType`. See #15195. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 01:24:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 01:24:15 -0000 Subject: [GHC] #15546: Display coaxiom branch incompatibilities in GHCi Message-ID: <044.c77ffe997f2d99b3fbec7a544251677f@haskell.org> #15546: Display coaxiom branch incompatibilities in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Keywords: TypeFamilies, | Operating System: Unknown/Multiple GHCi | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the only way to figure out how GHC figured out compatibility of branches in a closed type family is to compile it to `.hi` and then sieve through `--show-iface` output. Something as simple this should suffice: {{{#!hs > :i == type family (==) (a :: k) (b :: k) :: Bool where (==) (f a) (g b) = (f == g) && (a == b) (==) a a = 'True -- incompatible with: 0 (==) _1 _2 = 'False -- incompatible with: 0, 1 -- Defined in ‘Data.Type.Equality’ infix 4 == }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 01:30:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 01:30:29 -0000 Subject: [GHC] #15547: A function `nat2Word# :: KnownNat n => Proxy# n -> Word#` Message-ID: <047.1c203c591468a050bc440c6e00dd6bfe@haskell.org> #15547: A function `nat2Word# :: KnownNat n => Proxy# n -> Word#` -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It would be nice if there were the function (perhaps in `GHC.Prim`) `nat2Word# :: KnownNat n => Proxy# n -> Word#` that was essentially `(\ W# w# -> w#) . fromInteger . natVal`, except that it produces the `Word#` at compile-time rather than runtime and that it works with `Proxy#` (for [https://hackage.haskell.org/package/base-4.11.1.0/docs/GHC- Exts.html#t:Proxy-35- its no-runtime-representation, totally-free nature]) instead of `Proxy`. This would enable compile-time computations on `Nat`s to produce a literal `Word#` without any runtime expense at all, which seems nice if you're dealing with primitives ''because'' you want to avoid runtime expense. == Motivating example I'm learning primitive types and type-level arithmetic by making a simple set of fixed-width integer types where the type contains a `Nat` for the number of bits in the fixed-width integer. Going from the following `Nat`s to their corresponding `Word#`s at compile time even when optimizations are turned off during development would be very nice: ||= `Div (n + 63) 64` \\=||the highest index we should try to access via `indexWordArray#` || ||= `Mod (n - 1) 64 + 1` \\=||except when `n == 0`, the number of bits actually used in the \\ most-significant word || ||= `2^(Mod (n + 63) 64 + 1) - 1` \\=||the unsigned integer narrowing bitmask to use on the \\ most-significant word || -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 04:06:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 04:06:11 -0000 Subject: [GHC] #13477: Turn cIntegerLibraryType into a dynflag In-Reply-To: <046.1be05c5fa445155bed193903c2e35749@haskell.org> References: <046.1be05c5fa445155bed193903c2e35749@haskell.org> Message-ID: <061.f41461dd5d42d22c8706f031fee59a19@haskell.org> #13477: Turn cIntegerLibraryType into a dynflag -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: patch Priority: low | Milestone: Component: GHC API | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5079 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D5079 Comment: Ok, that wasn’t too hard: Phab:D5079 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 04:24:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 04:24:41 -0000 Subject: [GHC] #15548: Make TABLES_NEXT_TO_CODE a dynflag Message-ID: <046.9535ff5b262ce3a827e22266f139da22@haskell.org> #15548: Make TABLES_NEXT_TO_CODE a dynflag -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The GHC API is used by programs that do not necessarily want to compile the same way as the normal GHC, so we want as much configuration in `DynFlags` and as little as possible hard-coded. One such hard-coded flag is `TABLES_NEXT_TO_CODE`. It is currently used in these places: * It is (of course) used a lot in rts. That’s fine. * It is used via tablesNextToCode :: DynFlags -> Bool in the Cmm code, so that code is already prepared to read the information from `DynFlags`. * There is `ghciTablesNextToCode :: Bool` in the GHCi code, some refactoring there might be needed to add a `DynFlag` there. (The motivation is similar to #13477) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 04:25:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 04:25:03 -0000 Subject: [GHC] #15548: Make TABLES_NEXT_TO_CODE a dynflag In-Reply-To: <046.9535ff5b262ce3a827e22266f139da22@haskell.org> References: <046.9535ff5b262ce3a827e22266f139da22@haskell.org> Message-ID: <061.2e683d57185191a2974c26df9b31101f@haskell.org> #15548: Make TABLES_NEXT_TO_CODE a dynflag -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by nomeata: Old description: > The GHC API is used by programs that do not necessarily want to compile > the same way as the normal GHC, so we want as much configuration in > `DynFlags` and as little as possible hard-coded. > > One such hard-coded flag is `TABLES_NEXT_TO_CODE`. It is currently used > in these places: > > * It is (of course) used a lot in rts. That’s fine. > * It is used via tablesNextToCode :: DynFlags -> Bool in the Cmm code, > so that code is already prepared to read the information from `DynFlags`. > * There is `ghciTablesNextToCode :: Bool` in the GHCi code, some > refactoring there might be needed to add a `DynFlag` there. > > (The motivation is similar to #13477) New description: The GHC API is used by programs that do not necessarily want to compile the same way as the normal GHC, so we want as much configuration in `DynFlags` and as little as possible hard-coded. One such hard-coded flag is `TABLES_NEXT_TO_CODE`. It is currently used in these places: * It is (of course) used a lot in rts. That’s fine. * It is used via `tablesNextToCode :: DynFlags -> Bool` in the Cmm code, so that code is already prepared to read the information from `DynFlags`. * There is `ghciTablesNextToCode :: Bool` in the GHCi code, some refactoring there might be needed to add a `DynFlag` there. (The motivation is similar to #13477) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 05:56:43 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 05:56:43 -0000 Subject: [GHC] #15548: Make TABLES_NEXT_TO_CODE a dynflag In-Reply-To: <046.9535ff5b262ce3a827e22266f139da22@haskell.org> References: <046.9535ff5b262ce3a827e22266f139da22@haskell.org> Message-ID: <061.dafd9c6697a6937a977e474bb48aac21@haskell.org> #15548: Make TABLES_NEXT_TO_CODE a dynflag -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5082 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D5082 Comment: That was easy: Phab:D5082 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 07:52:24 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 07:52:24 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.657ad9b2ecadcc428803ad9199194d24@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Well I'm entirely open to changing the rules. They are documented here: [wiki:Commentary/Compiler/UnusedImports]. But for some time GHC has claimed to follow the rules, but has simply failed to do so. And we have bug reports asking that we fix that. It's unfortunate that this `SemiGroup` business has (inadvertently) relied on this bug in GHC. The truth is that the warning is spot-on: the import is redundant. What rules would we like instead? Perhaps we want to warn about some redundant imports bu not all? But which redundant imports should not be warned about? The obvious thing is to make a special case for the Prelude, since it is implicitly imported. For example * Never warn about an import declaration (or import item) that is unnecessary because of the implicit Prelude import. For example {{{ import Data.List( null ) -- Already imported by Prelude }}} Views? The status quo is bad; see #15393 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 07:59:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 07:59:03 -0000 Subject: [GHC] #15546: Display coaxiom branch incompatibilities in GHCi In-Reply-To: <044.c77ffe997f2d99b3fbec7a544251677f@haskell.org> References: <044.c77ffe997f2d99b3fbec7a544251677f@haskell.org> Message-ID: <059.a8fcad293d4700db529b791f287a82a5@haskell.org> #15546: Display coaxiom branch incompatibilities in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: TypeFamilies, | GHCi Operating System: 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): Isn't this incompatibility thing an implementation consideration? If so, we should not burden the user with it. By all means have a flag to augment :i with that info. We have a variety already: the blunderbus `-dppr-debug`, but also the more selective `-fprint-explicit-kinds` etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 09:09:32 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 09:09:32 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.4919dbc560e6b3e9d49cf98fcddafd1c@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by phadej): Thanks Simon for doing this! Ben: I want to point out, that this is a regression between 7.10 and 8.0. The change to less strict version as is currently where done pre-GHC- proposal process, but it really should been scrutinized in something like that. For AMP, the 7.10.3 (which works correctly) warns about {{{ {-# OPTIONS_GHC -Wall #-} import Control.Applicative (Applicative (..), (<$>)) import Prelude mult :: Applicative f => f a -> f b -> f (a, b) mult x y = (,) <$> x <*> y }}} but not about {{{ {-# OPTIONS_GHC -Wall #-} import Control.Applicative import Prelude mult :: Applicative f => f a -> f b -> f (a, b) mult x y = (,) <$> x <*> y }}} Similarly, GHC-8.4.3 doesn't warn, but the wip/T13064 does about: {{{ {-# OPTIONS_GHC -Wall #-} import Data.Semigroup (Semigroup, (<>)) import Prelude squash :: Semigroup a => a -> a -> a squash = (<>) }}} However, neither warns about (open imports) {{{ {-# OPTIONS_GHC -Wall #-} import Data.Semigroup import Prelude squash :: Semigroup a => a -> a -> a squash = (<>) }}} or (at least single qualified use) {{{ {-# OPTIONS_GHC -Wall #-} import Data.Semigroup (Semigroup (..)) import Prelude squash :: Data.Semigroup.Semigroup a => a -> a -> a squash = (<>) }}} S 3-release-policy is easily satisfied. You'll need to do "something" in your code, but it's not "use CPP". I hope that CLC agrees. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 09:11:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 09:11:47 -0000 Subject: [GHC] #12467: distclean does not clean 'compact' library In-Reply-To: <043.0965dcc9cbc3831b757e34a906f52bd0@haskell.org> References: <043.0965dcc9cbc3831b757e34a906f52bd0@haskell.org> Message-ID: <058.89a02b471ebbfc57df6088a94a0c33c8@haskell.org> #12467: distclean does not clean 'compact' library -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => closed * resolution: => fixed Comment: Apparently this was fixed, I now see {{{ "rm" -rf libraries/ghc-compact/dist-install }}} being run with `make distclean`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 09:34:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 09:34:14 -0000 Subject: [GHC] #12758: Bring sanity to our performance testsuite In-Reply-To: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> References: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> Message-ID: <061.dd94ce6392d378a43e89d780157947f5@haskell.org> #12758: Bring sanity to our performance testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.8.1 Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3758 Wiki Page: | -------------------------------------+------------------------------------- Comment (by davide): In the case of expected changes in performance metrics, we still need the tests to pass. This requires some **convenient** mechanism by which the author can explicitly inform the CI of that change. The current plan is for the author to indicate such changes in the commit message in the following form: {{{ Metric (Increase | Decrease) ['metric' | \['metrics',..\]] [\((test_env|way)='abc',...\)]: TestName01, TestName02, ... }}} e.g. {{{ # All metrics decreased for test T1234. Metric Decrease: T1234 # max_bytes_used decreased for test T1234. Metric Decrease 'max_bytes_used': T1234 # bytes allocated and peak_megabytes_allocated increased for tests T005 and T006. Metric Increase ['bytes allocated', 'peak_megabytes_allocated']: T005, T00 # All metrics decreased for test T200 in the x86_linux environment Metric Decrease (test_env = 'x86_linux'): T200 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 10:31:00 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 10:31:00 -0000 Subject: [GHC] #15546: Display coaxiom branch incompatibilities in GHCi In-Reply-To: <044.c77ffe997f2d99b3fbec7a544251677f@haskell.org> References: <044.c77ffe997f2d99b3fbec7a544251677f@haskell.org> Message-ID: <059.0cfb0892a35886446da6e7b2df8bac59@haskell.org> #15546: Display coaxiom branch incompatibilities in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: TypeFamilies, | GHCi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mniip): I'd say, even if rarely used, it's still a more important thing to be able to see than even `-fprint-explicit-kinds`, as `:i` will tell you any non- star kinds on its own anyway. But I don't insist. How about `-fprint-axiom-incomps`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 10:36:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 10:36:54 -0000 Subject: [GHC] #9854: Literal overflow check is too aggressive In-Reply-To: <044.0949ac05531a8c6732f39a917c7dcb0f@haskell.org> References: <044.0949ac05531a8c6732f39a917c7dcb0f@haskell.org> Message-ID: <059.88e6c6795c971f0e9b768e2b1c8231c4@haskell.org> #9854: Literal overflow check is too aggressive -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * cc: nh2 (added) Comment: I think we should always warn on literal integer overflow, and disabled only by explicit programmer annotation, not matter if it's common practice or not. Hex or not, you may just have misremembered what the range of your value is. Rust is also pushing people away from such common practice overflows into the, in my opinion very positive, direction of always warning on possible programmer errors and demanding explicit annotations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 10:44:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 10:44:42 -0000 Subject: [GHC] #15546: Display coaxiom branch incompatibilities in GHCi In-Reply-To: <044.c77ffe997f2d99b3fbec7a544251677f@haskell.org> References: <044.c77ffe997f2d99b3fbec7a544251677f@haskell.org> Message-ID: <059.3b3701940dc5aebc455e7ba0c0446a02@haskell.org> #15546: Display coaxiom branch incompatibilities in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: TypeFamilies, | GHCi Operating System: 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): > How about -fprint-axiom-incomps? Fine. When you say "more important to see" are you speaking about users or implementors? If the former, can you explain why they need to see this? They are just thinking "pick the first match" aren't they? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 13:03:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 13:03:29 -0000 Subject: [GHC] #15081: Finite list becomes infinite after maping fractional function for high numbers In-Reply-To: <044.f762bf620383822c5337aa8807210278@haskell.org> References: <044.f762bf620383822c5337aa8807210278@haskell.org> Message-ID: <059.3819d3864f5088320d734bc503e7e778@haskell.org> #15081: Finite list becomes infinite after maping fractional function for high numbers -------------------------------------+------------------------------------- Reporter: Onsed | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | libraries/base/tests/enumNumeric Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4650 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): @sighingnow, any further thoughts about comment:11? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 13:54:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 13:54:21 -0000 Subject: [GHC] #12674: GHC doesn't handle ./ prefixed paths correctly In-Reply-To: <047.897ae5e9c5c47ed13f84034ccb7c5729@haskell.org> References: <047.897ae5e9c5c47ed13f84034ccb7c5729@haskell.org> Message-ID: <062.71a58f10145598e5d7568c9c824df093@haskell.org> #12674: GHC doesn't handle ./ prefixed paths correctly -------------------------------------+------------------------------------- Reporter: dobenour | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Driver | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: T12674 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D5009 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 13:59:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 13:59:28 -0000 Subject: [GHC] #10869: Option to dump preprocessed source In-Reply-To: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> References: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> Message-ID: <061.d3a5d5b1d1f89c8130abcf65baf688dd@haskell.org> #10869: Option to dump preprocessed source -------------------------------------+------------------------------------- Reporter: phischu | Owner: RolandSenn Type: feature request | Status: patch Priority: low | Milestone: 8.8.1 Component: Driver | Version: 7.10.2 Resolution: | Keywords: easy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10869 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab: D4861 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 14:24:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 14:24:13 -0000 Subject: [GHC] #12674: GHC doesn't handle ./ prefixed paths correctly In-Reply-To: <047.897ae5e9c5c47ed13f84034ccb7c5729@haskell.org> References: <047.897ae5e9c5c47ed13f84034ccb7c5729@haskell.org> Message-ID: <062.767eab09bf5a5a78562210801206ed9b@haskell.org> #12674: GHC doesn't handle ./ prefixed paths correctly -------------------------------------+------------------------------------- Reporter: dobenour | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Driver | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: T12674 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5009 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * differential: Phab: D5009 => Phab:D5009 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 14:25:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 14:25:47 -0000 Subject: [GHC] #15261: Show -with-rtsopts options in runtime's --info In-Reply-To: <043.f2c7fda7e5ce90f13c2733f909af5e70@haskell.org> References: <043.f2c7fda7e5ce90f13c2733f909af5e70@haskell.org> Message-ID: <058.235bfd00836aa8975a4e0d2472ce99fe@haskell.org> #15261: Show -with-rtsopts options in runtime's --info -------------------------------------+------------------------------------- Reporter: osa1 | Owner: RolandSenn Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T15261a | T15261b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5053 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * differential: Phab: D5053 => Phab:D5053 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 14:27:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 14:27:08 -0000 Subject: [GHC] #10869: Option to dump preprocessed source In-Reply-To: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> References: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> Message-ID: <061.e9befdbbefd50fe0b97cd07050889094@haskell.org> #10869: Option to dump preprocessed source -------------------------------------+------------------------------------- Reporter: phischu | Owner: RolandSenn Type: feature request | Status: patch Priority: low | Milestone: 8.8.1 Component: Driver | Version: 7.10.2 Resolution: | Keywords: easy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10869 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4861 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * differential: Phab: D4861 => Phab:D4861 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 14:30:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 14:30:44 -0000 Subject: [GHC] #15549: Core Lint error with empty closed type family Message-ID: <050.9a179952570cbedc58a57ced12c92bb9@haskell.org> #15549: Core Lint error with empty closed type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Type checker) | Keywords: TypeFamilies, | Operating System: Unknown/Multiple TypeInType | Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program gives a Core Lint error on GHC 8.2.2 and later: {{{#!hs {-# LANGUAGE EmptyCase #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Data.Kind import Data.Void data family Sing (a :: k) data V1 :: Type -> Type data instance Sing (z :: V1 p) class Generic a where type Rep a :: Type -> Type to :: Rep a x -> a class PGeneric a where type To (z :: Rep a x) :: a class SGeneric a where sTo :: forall x (r :: Rep a x). Sing r -> Sing (To r :: a) ----- instance Generic Void where type Rep Void = V1 to x = case x of {} type family EmptyCase (a :: j) :: k where instance PGeneric Void where type To x = EmptyCase x instance SGeneric Void where sTo x = case x of }}} {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs -dcore-lint -fforce-recomp [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint errors : in result of Simplifier *** Bug.hs:38:7: warning: [in body of lambda with binder x_aZ8 :: Sing r_a12q] Kind application error in coercion ‘(Sing (D:R:RepVoid[0] _N) _N)_R’ Function kind = forall k. k -> * Arg kinds = [(V1 x_a12p, *), (r_a12q, Rep Void x_a12p)] Fun: V1 x_a12p (r_a12q, Rep Void x_a12p) Bug.hs:38:7: warning: [in body of lambda with binder x_aZ8 :: Sing r_a12q] Kind application error in coercion ‘D:R:SingV1z0[0] _N _N’ Function kind = V1 x_a12p -> * Arg kinds = [(r_a12q, Rep Void x_a12p)] Fun: V1 x_a12p (r_a12q, Rep Void x_a12p) Bug.hs:38:7: warning: [in body of lambda with binder x_aZ8 :: Sing r_a12q] Kind application error in coercion ‘D:R:SingV1z0[0] _N _N’ Function kind = V1 x_a12p -> * Arg kinds = [(r_a12q, Rep Void x_a12p)] Fun: V1 x_a12p (r_a12q, Rep Void x_a12p) : warning: In the type ‘R:SingV1z x_a12p r_a12q’ Kind application error in type ‘R:SingV1z x_a12p r_a12q’ Function kind = forall p -> V1 p -> * Arg kinds = [(x_a12p, *), (r_a12q, Rep Void x_a12p)] Fun: V1 x_a12p (r_a12q, Rep Void x_a12p) : warning: In the type ‘R:SingV1z x_a12p r_a12q’ Kind application error in type ‘R:SingV1z x_a12p r_a12q’ Function kind = forall p -> V1 p -> * Arg kinds = [(x_a12p, *), (r_a12q, Rep Void x_a12p)] Fun: V1 x_a12p (r_a12q, Rep Void x_a12p) *** Offending Program *** $csTo_a12n :: forall x (r :: Rep Void x). Sing r -> Sing (To r) [LclId, Arity=1, Str=x, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=True)}] $csTo_a12n = \ (@ x_a12p) (@ (r_a12q :: Rep Void x_a12p)) (x_aZ8 :: Sing r_a12q) -> case x_aZ8 `cast` ((Sing (D:R:RepVoid[0] _N) _N)_R ; D:R:SingV1z0[0] _N _N :: (Sing r_a12q :: *) ~R# (R:SingV1z x_a12p r_a12q :: *)) of nt_s13T { } }}} GHC 8.0.2 does not appear to suffer from this Core Lint error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 14:34:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 14:34:37 -0000 Subject: [GHC] #15550: Names of RULES aren't quoted in -ddump-splices Message-ID: <050.b5daffb0170f6fb061ff2380766e1195@haskell.org> #15550: Names of RULES aren't quoted in -ddump-splices -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template | Version: 8.4.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: -------------------------------------+------------------------------------- Compile the following program: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where $([d| myId :: a -> a myId x = x {-# NOINLINE [1] myId #-} {-# RULES "myId" forall x. myId x = x #-} |]) }}} {{{ $ /opt/ghc/8.4.3/bin/ghci Bug.hs GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(5,3)-(9,6): Splicing declarations [d| {-# RULES "myId" forall x_a1xu. myId_a1xr x_a1xu = x_a1xu #-} myId_a1xr :: a_a1xs -> a_a1xs myId_a1xr x_a1xt = x_a1xt {-# NOINLINE [1] myId_a1xr #-} |] ======> myId_a49f :: a_a49e -> a_a49e myId_a49f x_a49g = x_a49g {-# NOINLINE [1] myId_a49f #-} {-# RULES myId forall x_a49h. myId_a49f x_a49h = x_a49h #-} Ok, one module loaded. }}} Notice how in the bottom of the `-ddump-splices` output, the name of the rewrite rule for `myId` isn't surrounded by double quotes, thus making it syntactically invalid. That is, it's printed as: {{{#!hs {-# RULES myId forall x_a49h. myId_a49f x_a49h = x_a49h #-} }}} Whereas it should be: {{{#!hs {-# RULES "myId" forall x_a49h. myId_a49f x_a49h = x_a49h #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 14:38:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 14:38:07 -0000 Subject: [GHC] #15081: Finite list becomes infinite after maping fractional function for high numbers In-Reply-To: <044.f762bf620383822c5337aa8807210278@haskell.org> References: <044.f762bf620383822c5337aa8807210278@haskell.org> Message-ID: <059.37e8555cebbf706419c3b4bc9a2cde7f@haskell.org> #15081: Finite list becomes infinite after maping fractional function for high numbers -------------------------------------+------------------------------------- Reporter: Onsed | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | libraries/base/tests/enumNumeric Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4650 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): @thomie Thanks for your program in comment:11. However I think we have no way to improve the situation further. The double number `9007199254740992` and `9007199254740993` have same binary representation. You could check this problem with the following program. {{{#!cpp #include #include union double_uint64 { double x; uint64_t y; }; int main() { union double_uint64 z; z.x = 9007199254740992; printf("%lu\n", z.y); z.x = 9007199254740993; printf("%lu\n", z.y); } }}} In Haskell, we have {{{#!hs > (9007199254740993 :: Double) == (9007199254740992 :: Double) True }}} Thus, `[9007199254740992,9007199254740993..9007199254740994]::[Double]` is equivalent to `[9007199254740992,9007199254740992..9007199254740994]::[Double]`, the later will produce infinite list. For the second example, `[9007199254740993..9007199254740991]::[Double]` should be `[]`, but the program is equivalent to {{{#!hs takeWhile (<= 9007199254740991 + 1 / 2) [9007199254740993, 9007199254740993 + 1, 9007199254740993 + 2, 9007199254740993 + 3, ... ] }}} We have: {{{#!hs > :m +Data.Binary > :m +Data.ByteString.Lazy > unpack $ encode ((9007199254740991 + 1 / 2) :: Double) [1,1,0,0,0,0,0,0,0,7,0,0,0,0,0,0,16,0,0,0,0,0,0,0,1] > unpack $ encode ((9007199254740993) :: Double) [1,1,0,0,0,0,0,0,0,7,0,0,0,0,0,0,16,0,0,0,0,0,0,0,1] > unpack $ encode ((9007199254740993 + 1) :: Double) [1,1,0,0,0,0,0,0,0,7,0,0,0,0,0,0,16,0,0,0,0,0,0,0,1] > unpack $ encode ((9007199254740993 + 2) :: Double) [1,1,0,0,0,0,0,0,0,7,1,0,0,0,0,0,16,0,0,0,0,0,0,0,1] }}} Then we get the error. A possible improvement should be replacing the `1/2` with a smaller number (such as `0.1`), but when the base number `9007199254740991` grows up, we will get into trouble again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 14:40:04 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 14:40:04 -0000 Subject: [GHC] #15551: TH-reified type classes have redundant tyvars/class constraints on each method Message-ID: <050.f558426d191105778fc98c9fddcec266@haskell.org> #15551: TH-reified type classes have redundant tyvars/class constraints on each method -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template | Version: 8.4.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: -------------------------------------+------------------------------------- If you try to reify a type class in Template Haskell, as in the following example: {{{#!hs {-# LANGUAGE TemplateHaskell #-} module Bug where import Language.Haskell.TH class C a where method :: a $(pure []) main :: IO () main = putStrLn $(reify ''C >>= stringE . pprint) }}} You'll discover something strange: {{{ $ /opt/ghc/8.4.3/bin/runghc Bug.hs class Bug.C (a_0 :: *) where Bug.method :: forall (a_0 :: *) . Bug.C a_0 => a_0 }}} Notice how `method` has a completely redundant `forall (a_0 :: *) . Bug.C a_0 =>`! I find this very strange, and would have expected to simply see `Bug.method :: a_0` instead. Currently, I have to work around this oddity by manually stripping off the `forall (a_0 :: *) . Bug.C a_0 =>` myself, but it would be nice if I didn't have to do so. Does this proposal sound reasonable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 14:41:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 14:41:54 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.c1696415e20de3537d51285582d9c27b@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): **Replying to comment:24:** > Ben: I want to point out, that this is a regression between 7.10 and 8.0. Right, I don't dispute that that there is a regression here; rather, I want to point out that there may be a significant amount of code that (unfortunately) now relies on that regression. > or (at least single qualified use) > {{{#!hs > {-# OPTIONS_GHC -Wall #-} > import Data.Semigroup (Semigroup (..)) > import Prelude > > squash :: Data.Semigroup.Semigroup a => a -> a -> a > squash = (<>) > }}} Right; this is a reasonable option, albeit a bit ugly. However, it seems like this should serve as motivation to consider what mechanisms we could add to GHC to allow us to accomodate this sort of API reshuffling more easily and with fewer hacks in the future. For instance, wiki:Design/LocalWarningPragmas. **Replying to comment:23** > Never warn about an import declaration (or import item) that is unnecessary because of the implicit `Prelude` import. For example I suppose this is a possibility, although it seems to be me that we should rather try to introduce a mechanism to allow the user to state explicitly what they mean. That is: the import is known to be redundant but added for compatibility's sake. This could either be a general mechanism (e.g. wiki:Design/LocalWarningPragmas) or something more specifically designed to address import redundancy. (e.g. a `{-# USED #-}` pragma which could be attached to an import to silence the redundancy checker), -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 14:44:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 14:44:34 -0000 Subject: [GHC] #14180: Strange/bad error message binding unboxed type variable In-Reply-To: <045.2cd418235dffeabd04a0de461895e7c1@haskell.org> References: <045.2cd418235dffeabd04a0de461895e7c1@haskell.org> Message-ID: <060.cec38c3e5484829ef2365985c8a46bb7@haskell.org> #14180: Strange/bad error message binding unboxed type variable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): For what it's worth, the situation here appears to have changed slightly between GHC 8.4.3 and 8.6.1. In 8.4.3, one could work around this issue by replacing the `x` (in `MatchInt ('I# x) = '()`) with `_`. However, this is no longer be the case in 8.6.1, where even replacing `x` with `_` will yield this error: {{{ Bug.hs:6:17: error: • Couldn't match a lifted type with an unlifted type When matching kinds k0 :: * Int# :: TYPE 'IntRep Expected kind ‘Int#’, but ‘_’ has kind ‘k0’ • In the first argument of ‘ 'I#’, namely ‘_’ In the first argument of ‘MatchInt’, namely ‘( 'I# _)’ In the type family declaration for ‘MatchInt’ | 6 | MatchInt ('I# _) = '() | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 14:46:40 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 14:46:40 -0000 Subject: [GHC] #14180: Strange/bad error message binding unboxed type variable In-Reply-To: <045.2cd418235dffeabd04a0de461895e7c1@haskell.org> References: <045.2cd418235dffeabd04a0de461895e7c1@haskell.org> Message-ID: <060.8f0c4a5bc400f0940a034bdecd604b8f@haskell.org> #14180: Strange/bad error message binding unboxed type variable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): As far as why this error even happens in the first place, there appears to be some strangeness in the way the kind of the arrow `(->)` type constructor is generalized in type families. For example, this does not kind-check: {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind import GHC.Exts (Int#, TYPE) type family F :: Int# -> Int }}} {{{ Bug2.hs:10:18: error: • Expecting a lifted type, but ‘Int#’ is unlifted • In the kind ‘Int# -> Int’ | 10 | type family F :: Int# -> Int | ^^^^ }}} However, one can work around the issue by defining one's own function type: {{{#!hs type Arrow = ((->) :: TYPE p -> TYPE q -> Type) type family F :: Int# `Arrow` Int }}} This leads me to wonder: what's the point of not generalizing the kind of `(->)` to be the same as `Arrow`, then? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 14:58:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 14:58:27 -0000 Subject: [GHC] #15505: Assertion failures in tests T7224, T9201, LevPolyBounded In-Reply-To: <043.407a087db52d6ea6eac57ab6fce42849@haskell.org> References: <043.407a087db52d6ea6eac57ab6fce42849@haskell.org> Message-ID: <058.a06c3e3168b1187501b8e6b0cf26e501@haskell.org> #15505: Assertion failures in tests T7224, T9201, LevPolyBounded -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 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 simonpj): Problem is that * we call `zonkTcTypeToType` from `zonkTcMethInfoToMethInfo`, in `tcTyClDecl1` on class decls * when there is an unsolved (actually insoluble) residual constraint * the `CoVarHole` for that equality constraint is, of course (since it is solved) * but the zonker complains about an unfilled-in coercion hole. The assertion for an unfilled coercion hole is skipped if there are any type errors (and rightly so): see `TcHsSyn.zonkCoHole`. But at this moment we'd only called `zonkLocalEqualities` not `zonkEqualities`, so we hadn't actually added the error to in the Tc monad. Solution: call `solveEqualities` in `tcTyClDecl`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 15:06:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 15:06:01 -0000 Subject: [GHC] #15504: -XStrict doesn't prevent warnings from -Wunbanged-strict-patterns In-Reply-To: <047.80d1591e0d401bffffb0231b18ac57fb@haskell.org> References: <047.80d1591e0d401bffffb0231b18ac57fb@haskell.org> Message-ID: <062.2e28a838f9d3fcc0b1ff743c99a42b29@haskell.org> #15504: -XStrict doesn't prevent warnings from -Wunbanged-strict-patterns -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): `-Wunbanged-strict-patterns` works on the code the user wrote, not the code after `-XStrict` has notionally munged it. You could argue either way, I suppose, but my suggestion would just be to put the bang on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 15:19:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 15:19:59 -0000 Subject: [GHC] #14180: Strange/bad error message binding unboxed type variable In-Reply-To: <045.2cd418235dffeabd04a0de461895e7c1@haskell.org> References: <045.2cd418235dffeabd04a0de461895e7c1@haskell.org> Message-ID: <060.2b80eaf462f3f22fa980af1b4710dcc6@haskell.org> #14180: Strange/bad error message binding unboxed type variable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It's here in `tc_fun_type` {{{ tc_fun_type :: TcTyMode -> LHsType GhcRn -> LHsType GhcRn -> TcKind -> TcM TcType tc_fun_type mode ty1 ty2 exp_kind = case mode_level mode of TypeLevel -> do { arg_k <- newOpenTypeKind ; res_k <- newOpenTypeKind ; ty1' <- tc_lhs_type mode ty1 arg_k ; ty2' <- tc_lhs_type mode ty2 res_k ; checkExpectedKind (HsFunTy noExt ty1 ty2) (mkFunTy ty1' ty2') liftedTypeKind exp_kind } KindLevel -> -- no representation polymorphism in kinds. yet. do { ty1' <- tc_lhs_type mode ty1 liftedTypeKind ; ty2' <- tc_lhs_type mode ty2 liftedTypeKind ; checkExpectedKind (HsFunTy noExt ty1 ty2) (mkFunTy ty1' ty2') liftedTypeKind exp_kind } }}} In a kind signature, `(mode_level mode)` is `KindLevel`, so we insist that the arguments of `(->)` are of kind `Type`. A type synonym doesn't know what level it is at, so it escapes this check. You are right that this gives silly results. Now that types and kind are the same, perhaps we shouldn't have this `TypeLevel`/`KindLevel` distinction. But I don't know what the raminfications would be, esp for error messages. Or we could simplfy `tc_fun_type` to not check the distinction. But do you really want unboxed types in kinds?? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 16:08:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 16:08:34 -0000 Subject: [GHC] #15552: Infinite loop/panic with an existential type. Message-ID: <050.eb5168d400b4a4211e35d29d96945d09@haskell.org> #15552: Infinite loop/panic with an existential type. -------------------------------------+------------------------------------- Reporter: howtonotwin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #14723 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The symptoms of this bug are quite similar to #14723, but I don't know if the cause is exactly the same, ergo a new report. To reproduce: 1. Make `T.hs` {{{#!hs {-# LANGUAGE DataKinds, ExistentialQuantification, GADTs, PolyKinds, TypeOperators #-} module T where import Data.Kind data Elem :: k -> [k] -> Type where Here :: Elem x (x : xs) There :: Elem x xs -> Elem x (y : xs) data EntryOfVal (v :: Type) (kvs :: [Type]) = forall (k :: Type). EntryOfVal (Elem (k, v) kvs) }}} 2. Compile it with `ghc T.hs -ddump-tc-trace` {{{ # etc. checkExpectedKind * TYPE t_aXd[tau:1] <*>_N kcLHsQTyVars: not-cusk EntryOfVal [] [(k_aW0 :: Type)] [] [k_aW0[sk:1]] *ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-apple-darwin): kcConDecl Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} 3. Append the following to `T.hs` (not minimized, sorry) {{{#!hs type family EntryOfValKey (eov :: EntryOfVal v kvs) :: Type where EntryOfValKey ('EntryOfVal (_ :: Elem (k, v) kvs)) = k type family GetEntryOfVal (eov :: EntryOfVal v kvs) :: Elem (EntryOfValKey eov, v) kvs where GetEntryOfVal ('EntryOfVal e) = e type family FirstEntryOfVal (v :: Type) (kvs :: [Type]) :: EntryOfVal v kvs where FirstEntryOfVal v ((k, v) : _) = 'EntryOfVal Here FirstEntryOfVal v (_ : kvs) = 'EntryOfVal (There (GetEntryOfVal (FirstEntryOfVal v kvs))) }}} 4. Compile with a plain `ghc T.hs` 1. Wait until bored, then knock the compiler out of its infinite loop by killing it. 5. Compile again with `ghc T.hs -ddump-tc-trace` {{{ # etc. checkExpectedKind * TYPE t_aYg[tau:1] <*>_N kcLHsQTyVars: not-cuskghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-apple-darwin): kcConDecl Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Found while trying to answer [https://stackoverflow.com/q/51944931/5684257 this SO question]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 16:09:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 16:09:18 -0000 Subject: [GHC] #15508: concprog001 fails with various errors when compiled with -prof In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.ec48e1d4b3a03ab0735404066dab39e7@haskell.org> #15508: concprog001 fails with various errors when compiled with -prof -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Profiling | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5051 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * failure: None/Unknown => Runtime crash -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 16:11:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 16:11:13 -0000 Subject: [GHC] #15553: GHC.IO.Encoding not flushing partially converted input Message-ID: <045.cb27c38678a5b8fbb7ebb66aaf4a0469@haskell.org> #15553: GHC.IO.Encoding not flushing partially converted input -------------------------------------+------------------------------------- Reporter: msakai | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.4.3 Libraries | Keywords: | Operating System: Linux Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Conversion by `GHC.IO.Encoding` produces incomplete output for some encodings because it does not flush ''partially converted input'' at the end of the string. [https://manpages.debian.org/stretch/manpages-dev/iconv.3 iconv(3)] provides API for the flushing. > In each series of calls to iconv(), the last should be one with inbuf or *inbuf equal to NULL, in order to flush out any partially converted input. But `GHC.IO.Encoding` does not perform the flushing properly and it can cause incomplete conversion result. I found two cases that it actually produces incomplete output, but there might be more cases. = Case 1: EUC-JISX0213 For example, the following code is expected to output two bytes 0xa4 0xb1, but it outputs none. {{{#!hs enc <- mkTextEncoding "EUC-JISX0213" withFile "test.txt" WriteMode $ \h -> hSetEncoding h enc >> hPutStr h "\x3051" }}} The problem happens because of the following mapping between Unicode and EUC-JISX0213. ||Unicode||EUC-JISX0213|| ||U+3051 U+309A||0xa4 0xfa|| ||U+3051||0xa4 0xb1|| After seeing the codepoint U+3051, the converter is unable to determine which of the two byte sequence to output until it sees the next character or ''the end of the string''. But `GHC.IO.Encoding` does not call the above mentioned ''flushing'' API, therefore the converter is unable to recognize the end of the string. = Case 2: ISO-2022-JP Similarly, following code is expected to output byte sequence `0x1b 0x24 0x42` `0x24 0x22` `0x1b 0x28 0x42` but the last three bytes `0x1b 0x28 0x42` is not produced. {{{#!hs enc <- mkTextEncoding "ISO-2022-JP" withFile "test.txt" WriteMode $ \h -> hSetEncoding h enc >> hPutStr h "\x3042" }}} ISO-2022-JP is a stateful encoding and [https://www.ietf.org/rfc/rfc1468.txt RFC 1468] requires the state is reset to initial state at the end of the string. The missing three bytes `0x1b 0x28 0x42` are the escape sequence for that purpose. But again `GHC.IO.Encoding` does not call the above mentioned`flushing` API, therefore the converter cannot recognize the end of the string and cannot reset the state. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 16:12:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 16:12:06 -0000 Subject: [GHC] #15517: -O0 and pattern synonyms triggers panic in trimJoinCont In-Reply-To: <046.8e85deab87c1c94bb06eaa4a95b7f658@haskell.org> References: <046.8e85deab87c1c94bb06eaa4a95b7f658@haskell.org> Message-ID: <061.e36f02af81a6974f73999129c4236cd2@haskell.org> #15517: -O0 and pattern synonyms triggers panic in trimJoinCont -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ce6ce788251b6102f5c1b878ffec53ba7ad678b5/ghc" ce6ce78/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ce6ce788251b6102f5c1b878ffec53ba7ad678b5" Set strictness correctly for JoinIds We were failing to keep correct strictness info when eta-expanding join points; Trac #15517. The situation was something like \q v eta -> let j x = error "blah -- STR Lx bottoming! in case y of A -> j x eta B -> blah C -> j x eta So we spot j as a join point and eta-expand it. But we must also adjust the stricness info, else it vlaimes to bottom after one arg is applied but now it has become two. I fixed this in two places: - In CoreOpt.joinPointBinding_maybe, adjust strictness info - In SimplUtils.tryEtaExpandRhs, return consistent values for arity and bottom-ness }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 16:12:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 16:12:06 -0000 Subject: [GHC] #15487: "Ambiguos occurrence" error message uses strange qualification In-Reply-To: <049.ec049728f6597ec6e0ea496f9893f7ce@haskell.org> References: <049.ec049728f6597ec6e0ea496f9893f7ce@haskell.org> Message-ID: <064.b847ea05e7d28a58686248099837de8d@haskell.org> #15487: "Ambiguos occurrence" error message uses strange qualification -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"18c302cb3802e485e0837538d7d09e1ac21c3ee2/ghc" 18c302cb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="18c302cb3802e485e0837538d7d09e1ac21c3ee2" Improve ambiguous-occurrence error message Trac #15487 correctly reported that the qualification of a Name in an ambiguous-occurrence error message was wrong. This patch fixes it. It's easily done, in RnUtils.addNameClashErrRn The problem was that in complaining about M.x we must enusre that 'M' part is the same as that used in pprNameProvenance. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 16:12:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 16:12:06 -0000 Subject: [GHC] #15505: Assertion failures in tests T7224, T9201, LevPolyBounded In-Reply-To: <043.407a087db52d6ea6eac57ab6fce42849@haskell.org> References: <043.407a087db52d6ea6eac57ab6fce42849@haskell.org> Message-ID: <058.455586703d09a611cf34a2daa4a3c95e@haskell.org> #15505: Assertion failures in tests T7224, T9201, LevPolyBounded -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"43b08cfbac5ce7ad6fc245651329094896de06e0/ghc" 43b08cfb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="43b08cfbac5ce7ad6fc245651329094896de06e0" Add a solveEqualities to tcClassDecl1 Trac #15505 showed that, when we have a type error, we could have an unfilled-in coercion hole. We don't want an assertion error in that case. The underlying cause is that tcClassDecl1 should call solveEqualities to fully solve all top-level equalities (or fail in the attempt). I also refactored the ClassDecl case for tcTyClDecl1 into a new function tcClassDecl1. That makes it symmetrical with the others. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 16:13:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 16:13:45 -0000 Subject: [GHC] #15517: -O0 and pattern synonyms triggers panic in trimJoinCont In-Reply-To: <046.8e85deab87c1c94bb06eaa4a95b7f658@haskell.org> References: <046.8e85deab87c1c94bb06eaa4a95b7f658@haskell.org> Message-ID: <061.8696ec1bf1463998139f51ce51897109@haskell.org> #15517: -O0 and pattern synonyms triggers panic in trimJoinCont -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | simplCore/should_compile/T15517, | T15517a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => simplCore/should_compile/T15517, T15517a * status: new => closed * resolution: => fixed Comment: Thanks for reporting this! Now fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 16:14:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 16:14:27 -0000 Subject: [GHC] #15505: Assertion failures in tests T7224, T9201, LevPolyBounded In-Reply-To: <043.407a087db52d6ea6eac57ab6fce42849@haskell.org> References: <043.407a087db52d6ea6eac57ab6fce42849@haskell.org> Message-ID: <058.22d92650dce1f9e42476f937b91d3dae@haskell.org> #15505: Assertion failures in tests T7224, T9201, LevPolyBounded -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 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 simonpj): * status: new => closed * resolution: => fixed Comment: Thanks! This patch fixes all three cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 16:15:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 16:15:50 -0000 Subject: [GHC] #15487: "Ambiguos occurrence" error message uses strange qualification In-Reply-To: <049.ec049728f6597ec6e0ea496f9893f7ce@haskell.org> References: <049.ec049728f6597ec6e0ea496f9893f7ce@haskell.org> Message-ID: <064.a25e9197910958dd2b81377ac69e9ea8@haskell.org> #15487: "Ambiguos occurrence" error message uses strange qualification -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | rename/should_fail/T15487 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => rename/should_fail/T15487 * resolution: => fixed Comment: Great report. We now get {{{ T15487.hs:7:9: error: Ambiguous occurrence ‘null’ It could refer to either ‘Prelude.null’, imported from ‘Prelude’ at T15487.hs:1:8-13 (and originally defined in ‘Data.Foldable’) or ‘T15487.null’, defined at T15487.hs:5:1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 16:36:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 16:36:01 -0000 Subject: [GHC] #15546: Display coaxiom branch incompatibilities in GHCi In-Reply-To: <044.c77ffe997f2d99b3fbec7a544251677f@haskell.org> References: <044.c77ffe997f2d99b3fbec7a544251677f@haskell.org> Message-ID: <059.24f013ac9a98ed376dc8a6f515d82962@haskell.org> #15546: Display coaxiom branch incompatibilities in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: TypeFamilies, | GHCi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mniip): The other (actually this) day I discovered that type family compatibility checks do not reduce the LHS and expect the equality to trivially hold. Example: {{{#!hs type family If (a :: Bool) (b :: k) (c :: k) :: k where If False a b = b If True a b = a type family Eql (a :: k) (b :: k) :: Bool where Eql a a = True Eql _ _ = False type family Test (a :: Maybe k) (b :: Maybe k) :: Maybe k where Test (Just x) (Just y) = If (Eql x y) (Just x) Nothing Test a a = a Test Nothing _ = Nothing Test _ Nothing = Nothing }}} {{{#!hs axiom D:R:Test:: Test a ('Just x) ('Just y) = If (Eql x y) ('Just x) 'Nothing Test k a a = a (incompatible indices: [0]) Test k 'Nothing _ = 'Nothing Test k _ 'Nothing = 'Nothing }}} Clearly `unify(, ) = theta = [a = Just x, y = x]`. `theta(If (Eql x y) (Just x) Nothing) = Just x = theta(a)`. If you would like to discuss this restriction I can open another ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 16:48:04 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 16:48:04 -0000 Subject: [GHC] #15546: Display coaxiom branch incompatibilities in GHCi In-Reply-To: <044.c77ffe997f2d99b3fbec7a544251677f@haskell.org> References: <044.c77ffe997f2d99b3fbec7a544251677f@haskell.org> Message-ID: <059.45e04f3d019bdc4530a3337da83e9ac3@haskell.org> #15546: Display coaxiom branch incompatibilities in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: TypeFamilies, | GHCi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm sorry I'm lost. What does "that type family compatibility checks do not reduce the LHS and expect the equality to trivially hold" mean? What is "this restriction"? What is illustrated by the example? Is it a bug? Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 16:49:04 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 16:49:04 -0000 Subject: [GHC] #15552: Infinite loop/panic with an existential type. In-Reply-To: <050.eb5168d400b4a4211e35d29d96945d09@haskell.org> References: <050.eb5168d400b4a4211e35d29d96945d09@haskell.org> Message-ID: <065.5b403e3215eb0a015c51e456bfff5e38@haskell.org> #15552: Infinite loop/panic with an existential type. -------------------------------------+------------------------------------- Reporter: howtonotwin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: TypeInType, | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14723 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => TypeInType, TypeFamilies Comment: The `-ddump-tc-trace` panic is an old GHC 8.4.3 bug that has since been fixed. (I can't recall if there was ever a ticket to track this.) I wasn't able to reproduce the infinite loop until I added some more language extensions (`TypeInType` and `TypeFamilies`): {{{#!hs {-# LANGUAGE DataKinds, ExistentialQuantification, GADTs, PolyKinds, TypeOperators #-} {-# LANGUAGE TypeInType, TypeFamilies #-} module T where import Data.Kind data Elem :: k -> [k] -> Type where Here :: Elem x (x : xs) There :: Elem x xs -> Elem x (y : xs) data EntryOfVal (v :: Type) (kvs :: [Type]) = forall (k :: Type). EntryOfVal (Elem (k, v) kvs) type family EntryOfValKey (eov :: EntryOfVal v kvs) :: Type where EntryOfValKey ('EntryOfVal (_ :: Elem (k, v) kvs)) = k type family GetEntryOfVal (eov :: EntryOfVal v kvs) :: Elem (EntryOfValKey eov, v) kvs where GetEntryOfVal ('EntryOfVal e) = e type family FirstEntryOfVal (v :: Type) (kvs :: [Type]) :: EntryOfVal v kvs where FirstEntryOfVal v ((k, v) : _) = 'EntryOfVal Here FirstEntryOfVal v (_ : kvs) = 'EntryOfVal (There (GetEntryOfVal (FirstEntryOfVal v kvs))) }}} This still loops when compiled even on 8.6 and HEAD. I wonder if there is any relationship between this ticket and #15473... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 16:56:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 16:56:50 -0000 Subject: [GHC] #15543: Binary crashes under dtrace In-Reply-To: <045.599ac00709c714a8189c60aa1b140c4c@haskell.org> References: <045.599ac00709c714a8189c60aa1b140c4c@haskell.org> Message-ID: <060.6144ef1e86ebee30691aeab0d3876098@haskell.org> #15543: Binary crashes under dtrace ----------------------------------+---------------------------------------- Reporter: last_g | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: dtrace, crash Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Changes (by bgamari): * milestone: Research needed => Comment: Very interesting. Perhaps the generated dtrace tracepoints are incorrect, resulting in our executable image being corrupted? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 17:22:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 17:22:06 -0000 Subject: [GHC] #14180: Strange/bad error message binding unboxed type variable In-Reply-To: <045.2cd418235dffeabd04a0de461895e7c1@haskell.org> References: <045.2cd418235dffeabd04a0de461895e7c1@haskell.org> Message-ID: <060.4bff3bb65cb8c8f5cd705b307bdefcd8@haskell.org> #14180: Strange/bad error message binding unboxed type variable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:7 simonpj]: > But do you really want unboxed types in kinds?? ...Yes? I mean, that's what dfeuer was presumably trying to do in the original program. But moreover, I find it rather strange that the typing rule for `(->)` is less general in kinds than it is in types. I don't care so much about removing the `TypeLevel`/`KindLevel` distinction, especially if keeping it will improve error message quality elsewhere. But I do think that we shouldn't check for this distinction in `tc_fun_type`. ...However, it should be noted that I tried implementing that `tc_fun_type` suggestion, but even still that doesn't make the original program (the `MatchInt` one) typecheck, so I guess my hunch was misplaced. For some reason, GHC expects the type of all type variables to have kind `Type` (as opposed to how things work on the value level, where they can have kind `TYPE r` for some `RuntimeRep` `r`). I'm not sure where that is decided, but it's not `tc_fun_type` it seems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 17:32:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 17:32:47 -0000 Subject: [GHC] #15545: Forced to enable TypeInType because of (i ~ i) In-Reply-To: <051.d941c2a1d44582666aa9c16bceab18dc@haskell.org> References: <051.d941c2a1d44582666aa9c16bceab18dc@haskell.org> Message-ID: <066.8d93387cb68460d506b33e4fdfcdc26a@haskell.org> #15545: Forced to enable TypeInType because of (i ~ i) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15195 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): That is cheeky indeed :) cheers Ryan -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 18:06:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 18:06:06 -0000 Subject: [GHC] #15549: Core Lint error with EmptyCase (was: Core Lint error with empty closed type family) In-Reply-To: <050.9a179952570cbedc58a57ced12c92bb9@haskell.org> References: <050.9a179952570cbedc58a57ced12c92bb9@haskell.org> Message-ID: <065.5d5ab307dc72bed991e5ba54a0c05cf2@haskell.org> #15549: Core Lint error with EmptyCase -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeFamilies, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Never mind, empty closed type families have nothing to do with this. Here's an even more minimal way to reproduce the Core Lint error: {{{#!hs {-# LANGUAGE EmptyCase #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Proxy import Data.Void data family Sing (a :: k) data instance Sing (z :: Void) type family Rep a class SGeneric a where sTo :: forall (r :: Rep a). Sing r -> Proxy a type instance Rep Void = Void instance SGeneric Void where sTo x = case x of }}} {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs -dcore-lint [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint errors : in result of Simplifier *** Bug.hs:19:7: warning: [in body of lambda with binder x_ayn :: Sing r_azJ] Kind application error in coercion ‘(Sing (D:R:RepVoid[0]) _N)_R’ Function kind = forall k. k -> * Arg kinds = [(Void, *), (r_azJ, Rep Void)] Fun: Void (r_azJ, Rep Void) Bug.hs:19:7: warning: [in body of lambda with binder x_ayn :: Sing r_azJ] Kind application error in coercion ‘D:R:SingVoidz0[0] _N’ Function kind = Void -> * Arg kinds = [(r_azJ, Rep Void)] Fun: Void (r_azJ, Rep Void) Bug.hs:19:7: warning: [in body of lambda with binder x_ayn :: Sing r_azJ] Kind application error in coercion ‘D:R:SingVoidz0[0] _N’ Function kind = Void -> * Arg kinds = [(r_azJ, Rep Void)] Fun: Void (r_azJ, Rep Void) : warning: In the type ‘R:SingVoidz r_azJ’ Kind application error in type ‘R:SingVoidz r_azJ’ Function kind = Void -> * Arg kinds = [(r_azJ, Rep Void)] Fun: Void (r_azJ, Rep Void) : warning: In the type ‘R:SingVoidz r_azJ’ Kind application error in type ‘R:SingVoidz r_azJ’ Function kind = Void -> * Arg kinds = [(r_azJ, Rep Void)] Fun: Void (r_azJ, Rep Void) *** Offending Program *** $csTo_azH :: forall (r :: Rep Void). Sing r -> Proxy Void [LclId, Arity=1, Str=x, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=True)}] $csTo_azH = \ (@ (r_azJ :: Rep Void)) (x_ayn :: Sing r_azJ) -> case x_ayn `cast` ((Sing (D:R:RepVoid[0]) _N)_R ; D:R:SingVoidz0[0] _N :: (Sing r_azJ :: *) ~R# (R:SingVoidz r_azJ :: *)) of nt_s14C { } }}} However, `EmptyCase` does appear to play an important role. If I change the implementation of `sTo` to this: {{{#!hs instance SGeneric Void where sTo x = x `seq` undefined }}} Then the Core Lint error goes away, and the generated Core for `sTo` instead becomes: {{{ $csTo_r2IT :: forall (r :: Rep Void). Sing r -> Proxy Void [GblId, Arity=1, Caf=NoCafRefs] $csTo_r2IT = \ (@ (r_a1F4 :: Rep Void)) (x_X1DH :: Sing r_a1F4) -> break<0>(x_X1DH) case x_X1DH `cast` ((Sing (Bug.D:R:RepVoid[0]) (Sym (Coh _N (Bug.D:R:RepVoid[0]))))_R ; Bug.D:R:SingVoidz0[0] (Sym (Coh (Sym (Coh _N (Bug.D:R:RepVoid[0]))) (Bug.D:R:RepVoid[0]))) :: (Sing r_a1F4 :: *) ~R# (Bug.R:SingVoidz (r_a1F4 |> Bug.D:R:RepVoid[0]) :: *)) of { } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 19:56:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 19:56:21 -0000 Subject: [GHC] #15517: -O0 and pattern synonyms triggers panic in trimJoinCont In-Reply-To: <046.8e85deab87c1c94bb06eaa4a95b7f658@haskell.org> References: <046.8e85deab87c1c94bb06eaa4a95b7f658@haskell.org> Message-ID: <061.643c2fc93fb9ae6b18b2d82d0e73fa0f@haskell.org> #15517: -O0 and pattern synonyms triggers panic in trimJoinCont -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | simplCore/should_compile/T15517, | T15517a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 20:20:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 20:20:35 -0000 Subject: [GHC] #15540: GHCi does not follow the XDG Base Directory Specification In-Reply-To: <047.104e0b09441c5fa58dd1aeb68ec6fc11@haskell.org> References: <047.104e0b09441c5fa58dd1aeb68ec6fc11@haskell.org> Message-ID: <062.256df8719459d2e94fb7b20b0a8a8b48@haskell.org> #15540: GHCi does not follow the XDG Base Directory Specification -------------------------------------+------------------------------------- Reporter: rszibele | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.0.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => newcomer Comment: For the record, the specification says the following: > `$XDG_CACHE_HOME` defines the base directory relative to which user specific non-essential data files should be stored. If `$XDG_CACHE_HOME` is either not set or empty, a default equal to `$HOME/.cache` should be used. Indeed `.ghci_history` is rather non-essential. However, what is the argument for singling out `.ghci_history`? GHC puts all kinds of things in `~/.ghc`, including the user package database. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 20:21:32 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 20:21:32 -0000 Subject: [GHC] #15158: T8089 failing with ghci, threaded1, threaded2, profthreaded In-Reply-To: <048.e0a32f56c09af74c66cfdba0027fd931@haskell.org> References: <048.e0a32f56c09af74c66cfdba0027fd931@haskell.org> Message-ID: <063.1f18b39df2e5fe493901516440a47ad3@haskell.org> #15158: T8089 failing with ghci, threaded1, threaded2, profthreaded -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: libraries/base | Version: 8.5 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: T8089 Blocked By: | Blocking: Related Tickets: #8089, #7325, | Differential Rev(s): Phab:D4700 #15064 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed this will be fixed in 8.6.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 20:27:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 20:27:01 -0000 Subject: [GHC] #14917: Allow levity polymorphism in binding position In-Reply-To: <049.d67991f1b0cd65b675056d1b1f0986b9@haskell.org> References: <049.d67991f1b0cd65b675056d1b1f0986b9@haskell.org> Message-ID: <064.76d72c9c987010d9d4d7e1c5fd561872@haskell.org> #14917: Allow levity polymorphism in binding position -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Someday, I want to rewrite the RTS in Haskell...without getting RSI from wrist typing boilerplate You are not the only one ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 20:31:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 20:31:19 -0000 Subject: [GHC] #15533: Access the number of bits in the target machine's Int type at compile time In-Reply-To: <047.88dc19acc4ad07275cb32cbca32b73f1@haskell.org> References: <047.88dc19acc4ad07275cb32cbca32b73f1@haskell.org> Message-ID: <062.5699aa841db061868af863cb1b73907c@haskell.org> #15533: Access the number of bits in the target machine's Int type at compile time -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * component: Compiler => Template Haskell Comment: It sounds like this is really asking for a Template Haskell interface. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 20:58:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 20:58:19 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.a88608376b661a6e4e0d895cd94fc625@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 bgamari): * milestone: => 8.8.1 Comment: The current state of play is that there are some performance issues which need to be sorted out in the patch currently but I expect to be able to get to these by 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 21:02:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 21:02:47 -0000 Subject: [GHC] #15516: ghci: dynamic linking fails on osx In-Reply-To: <043.9e113393326f5d3476a9ce02881a262c@haskell.org> References: <043.9e113393326f5d3476a9ce02881a262c@haskell.org> Message-ID: <058.ac4747cbbd32dd2bdffb8842256eee9e@haskell.org> #15516: ghci: dynamic linking fails on osx -------------------------------------+------------------------------------- Reporter: kfiz | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Old description: > ghc: panic! (the 'impossible' happened) > (GHC version 8.4.3 for x86_64-apple-darwin): > Loading temp shared object failed: > dlopen(/var/folders/vj/cm0c8jrs739_t411zdcx72240000gp/T/ghc24522_0/libghc_9.dylib, > 5): Symbol not found: _DataziCsvUtils_rowBy_closure > Referenced from: > /var/folders/vj/cm0c8jrs739_t411zdcx72240000gp/T/ghc24522_0/libghc_9.dylib > Expected in: flat namespace > in > /var/folders/vj/cm0c8jrs739_t411zdcx72240000gp/T/ghc24522_0/libghc_9.dylib > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug New description: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/vj/cm0c8jrs739_t411zdcx72240000gp/T/ghc24522_0/libghc_9.dylib, 5): Symbol not found: _DataziCsvUtils_rowBy_closure Referenced from: /var/folders/vj/cm0c8jrs739_t411zdcx72240000gp/T/ghc24522_0/libghc_9.dylib Expected in: flat namespace in /var/folders/vj/cm0c8jrs739_t411zdcx72240000gp/T/ghc24522_0/libghc_9.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Comment: How does one reproduce this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 21:04:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 21:04:49 -0000 Subject: [GHC] #15269: Qualified Names in --show-iface output In-Reply-To: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> References: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> Message-ID: <061.69c58587f047cdbea6377eefaebe0b07@haskell.org> #15269: Qualified Names in --show-iface output -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature request | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4852 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.8.1 => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 21:08:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 21:08:45 -0000 Subject: [GHC] #15509: `showEFloat` inconsistency introduced in base-4.12 In-Reply-To: <042.b4d95dcfedcc55594395a53ebe2f16f7@haskell.org> References: <042.b4d95dcfedcc55594395a53ebe2f16f7@haskell.org> Message-ID: <057.877fc05c7e38268a73fa61a5d1adc970@haskell.org> #15509: `showEFloat` inconsistency introduced in base-4.12 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This was likely introduced by the fix to #15115. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 21:16:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 21:16:49 -0000 Subject: [GHC] #15509: `showEFloat` inconsistency introduced in base-4.12 In-Reply-To: <042.b4d95dcfedcc55594395a53ebe2f16f7@haskell.org> References: <042.b4d95dcfedcc55594395a53ebe2f16f7@haskell.org> Message-ID: <057.13fcce3487dfa2487e9a57c14fe280fe@haskell.org> #15509: `showEFloat` inconsistency introduced in base-4.12 -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 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:D5083 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D5083 Comment: See Phab:D5083. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 21:30:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 21:30:02 -0000 Subject: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections In-Reply-To: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> References: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> Message-ID: <060.af4445eb72b19c549c4d66c2320fe5c4@haskell.org> #7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.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 dfeuer): I've been thinking about the `StableName#` representation some, and I really don't like the redundancy between stable name objects and stable name table entries. I can think of two approaches to fixing this: get rid of the stable name table or get rid of stable name objects. === Get rid of the stable name table This is my preferred approach, if it's workable, because it seems almost absurdly simple. Suppose we have one counter to generate IDs (the results of `hashStableName#`) and one hash table per generation mapping heap pointers to stable name objects. A stable name object would look like {{{ StableNameObject: Header ID -- for hashStableName# Underlying object, treated as a weak reference }}} `makeStableName#` would check the hash table for the appropriate generation to see if there's already a stable name object (SNO). If not, it gets a fresh `ID` and builds the SNO. Garbage collecting the hash tables, roughly speaking: Perform a normal collection, leaving the underlying object pointers pointing to from-space. Traverse all the hash table entries in the table for the generation currently being collected. For each SNO pointer in the table, check the SNO for liveness. If it's alive, get the to-space address of its underlying object, edit the SNO accordingly, and insert it into the hash table for the next generation. If the underlying object is dead, null out that field. Is this too simple, or just simple enough? I don't really understand the idea of per-capability lists--how do you know which one a particular target should be inserted into? But presumably if we did that, we'd partition the ID space by high bit to give each capability its own counter. === Get rid of stable name objects 1. Change the stable name table to a representation that can grow without moving. Guess: an array of arrays, where each array is either empty or twice the size of the one to its left. 2. Add a heap object-style header to each stable name table entry. So each entry will look like {{{ SNTableEntry: Header Index (for hashStableName#) Underlying object }}} Now a `StableName#` becomes a pointer directly into the stable name table. The garbage collector can recognize the closure type and handle it specially. Note that stable name table entries pointing to old objects will always be put in the old-generation stable name table. I don't know enough about the garbage collector to say exactly how that should work. The free list can probably just run through the headers. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 22:07:55 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 22:07:55 -0000 Subject: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections In-Reply-To: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> References: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> Message-ID: <060.c9e807302bb64de8fc35af8a3a4df3d8@haskell.org> #7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 22:27:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 22:27:44 -0000 Subject: [GHC] #14461: Reuse free variable lists through nested closures In-Reply-To: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> References: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> Message-ID: <062.9207312b0d1314c1b9e6eb5855ba57e5@haskell.org> #14461: Reuse free variable lists through nested closures -------------------------------------+------------------------------------- Reporter: tdammers | Owner: alexbiehl Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: 7258 | Differential Rev(s): Wiki Page: NestedClosures | -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 22:52:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 22:52:47 -0000 Subject: [GHC] #14461: Reuse free variable lists through nested closures In-Reply-To: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> References: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> Message-ID: <062.4933e71461d7ebcb2da366fbe7c2a06f@haskell.org> #14461: Reuse free variable lists through nested closures -------------------------------------+------------------------------------- Reporter: tdammers | Owner: alexbiehl Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: 7258 | Differential Rev(s): Wiki Page: NestedClosures | -------------------------------------+------------------------------------- Comment (by simonpj): @alexbiehl your POC in comment:11 looks so promising that it seems a shame to let this lie. Do you (or anyone else) have time to carry it through? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 22:56:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 22:56:23 -0000 Subject: [GHC] #15051: -split-objs generates excessively many files on Windows In-Reply-To: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> References: <045.78b95fe068bf56380f1a356faf7d1c61@haskell.org> Message-ID: <060.9ae9e10b7ea366fc58884ca69e1798f8@haskell.org> #15051: -split-objs generates excessively many files on Windows -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Phyx- Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (CodeGen) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4915 Wiki Page: | Phab:D4916 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"23774c98f1368b41515cbd5223b87ea6dbf644e1/ghc" 23774c98/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="23774c98f1368b41515cbd5223b87ea6dbf644e1" function-section: enable on windows gc-sections was onced observed to be slow on Windows, which is the only reason it's not enabled yet. However, it seems to be better now. Test Plan: ./validate Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #15051 Differential Revision: https://phabricator.haskell.org/D4916 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 22:56:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 22:56:23 -0000 Subject: [GHC] #15529: runtime bug when profiling retainers In-Reply-To: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> References: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> Message-ID: <061.f171de407e2c1f62f111846785925576@haskell.org> #15529: runtime bug when profiling retainers -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5075 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2bacf6f8842d8e1288917e358ed41e4c61b7948e/ghc" 2bacf6f8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2bacf6f8842d8e1288917e358ed41e4c61b7948e" rts/RetainerProfile: Dump closure type if pop() fails While investigating #15529, I noticed that the `barf`ed error message in `pop()` doesn't print out the closure type that causes it to crash. Let's do so. Reviewers: bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15529 Differential Revision: https://phabricator.haskell.org/D5072 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 22:56:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 22:56:23 -0000 Subject: [GHC] #10869: Option to dump preprocessed source In-Reply-To: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> References: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> Message-ID: <061.646e39a326a5198284f447dea2bbbde6@haskell.org> #10869: Option to dump preprocessed source -------------------------------------+------------------------------------- Reporter: phischu | Owner: RolandSenn Type: feature request | Status: patch Priority: low | Milestone: 8.8.1 Component: Driver | Version: 7.10.2 Resolution: | Keywords: easy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10869 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4861 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ebcbfba7bbf07fa9fbb78b46951892997795bcb8/ghc" ebcbfba/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ebcbfba7bbf07fa9fbb78b46951892997795bcb8" Introduce flag -keep-hscpp-files Test Plan: `make test=T10869` Reviewers: mpickering, thomie, ezyang, bgamari Reviewed By: thomie, bgamari Subscribers: rwbarton, carter GHC Trac Issues: #10869 Differential Revision: https://phabricator.haskell.org/D4861 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 22:56:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 22:56:23 -0000 Subject: [GHC] #314: #line pragmas not respected inside nested comments In-Reply-To: <045.e2d94babc1a72770327e5dfb6388ae06@haskell.org> References: <045.e2d94babc1a72770327e5dfb6388ae06@haskell.org> Message-ID: <060.b215bd5743482ce95736e0a0dc809366@haskell.org> #314: #line pragmas not respected inside nested comments -------------------------------------+------------------------------------- Reporter: nobody | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 6.4 (Parser) | Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: read032 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4934 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"02518f9d99c2d038384263f9e039efcb09bc96ff/ghc" 02518f9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="02518f9d99c2d038384263f9e039efcb09bc96ff" Fix #line pragmas in nested comments When parsing a nested comment or nested doc comment in the lexer, if we see a line starting with '#' we attempt to parse a #line pragma. This fixes how ghc handles output of the C preproccesor (-cpp flag) when the original source has C comments or pragmas inside haskell comments. Updates haddock submodule. Test Plan: ./validate Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, carter GHC Trac Issues: #314 Differential Revision: https://phabricator.haskell.org/D4934 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 22:56:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 22:56:23 -0000 Subject: [GHC] #15426: `elemIndex` and `findIndex` still can't fuse In-Reply-To: <045.556cc5a15fe7d0c4bec73444eba7ef79@haskell.org> References: <045.556cc5a15fe7d0c4bec73444eba7ef79@haskell.org> Message-ID: <060.a8e6a83e9c1f6a8ed269619c1f6ed905@haskell.org> #15426: `elemIndex` and `findIndex` still can't fuse -------------------------------------+------------------------------------- Reporter: kabuhr | Owner: kabuhr Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: libraries/base | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/perf/should_run/T15426.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D5063 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"14817621aae2d45f8272a36b171b9ccce8763bba/ghc" 1481762/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="14817621aae2d45f8272a36b171b9ccce8763bba" base: Mark `findIndices` as INLINABLE instead of INLINE (fixes #15426) If `findIndices` is marked INLINE in `Data.OldList`, then the unfolded versions of `elemIndex` and `findIndex` included in the interface file are unfusible (even though `findIndices` itself remains fusible). By marking it INLINABLE instead, elemIndex` and `findIndex` will fuse properly. Test Plan: make TEST=T15426 Reviewers: hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15426 Differential Revision: https://phabricator.haskell.org/D5063 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 22:56:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 22:56:23 -0000 Subject: [GHC] #15261: Show -with-rtsopts options in runtime's --info In-Reply-To: <043.f2c7fda7e5ce90f13c2733f909af5e70@haskell.org> References: <043.f2c7fda7e5ce90f13c2733f909af5e70@haskell.org> Message-ID: <058.9f5fc3962b69eab029e627b3ff4d6966@haskell.org> #15261: Show -with-rtsopts options in runtime's --info -------------------------------------+------------------------------------- Reporter: osa1 | Owner: RolandSenn Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T15261a | T15261b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5053 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"dcf27e6f78529e7e471a4be64ca47398eb1b6b52/ghc" dcf27e6f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dcf27e6f78529e7e471a4be64ca47398eb1b6b52" Show -with-rtsopts options in runtime's --info (#15261) Add an additional line to the output of +RTS --info. It shows the value of the flag -with-rtsopts provided at compile/link time. Test Plan: make test TESTS="T15261a T15261b" Reviewers: hvr, erikd, dfeuer, thomie, austin, bgamari, simonmar, osa1, monoidal Reviewed By: osa1, monoidal Subscribers: osa1, rwbarton, carter GHC Trac Issues: #15261 Differential Revision: https://phabricator.haskell.org/D5053 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 22:56:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 22:56:23 -0000 Subject: [GHC] #15482: the_gc_thread variable from GC.c is not aligned to 64 In-Reply-To: <045.517cd029a074e1225f6142d10f834f62@haskell.org> References: <045.517cd029a074e1225f6142d10f834f62@haskell.org> Message-ID: <060.223d432daf0202f4aed667223835c0c6@haskell.org> #15482: the_gc_thread variable from GC.c is not aligned to 64 -------------------------------------+------------------------------------- Reporter: arrowd | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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): Phab:D5052 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"68a1fc29b4bb3eae54e4d96c9aec20e700040f34/ghc" 68a1fc29/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="68a1fc29b4bb3eae54e4d96c9aec20e700040f34" rts: Align the_gc_thread to 64 bytes In a previous attempt (c6cc93bca69abc258513af8cf2370b14e70fd8fb) I had tried aligning to 8 bytes under the assumption that the problem was that the_gc_thread, a StgWord8[], wasn't being aligned to 8-bytes as the gc_thread struct would expect. However, we actually need even stronger alignment due to the alignment attribute attached to gen_workspace, which claims it should be aligned to a 64-byte boundary. This fixes #15482. Reviewers: erikd, simonmar Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15482 Differential Revision: https://phabricator.haskell.org/D5052 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 22:56:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 22:56:23 -0000 Subject: [GHC] #15350: gcdExtInteger violates assertion In-Reply-To: <047.463f72a51535cf21b879b51cdb0841bf@haskell.org> References: <047.463f72a51535cf21b879b51cdb0841bf@haskell.org> Message-ID: <062.9096db678625246b3fad9cdb432663a1@haskell.org> #15350: gcdExtInteger violates assertion -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: Bodigrim Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5042 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c331592130ef592b92084e7417581a4039bfa7d2/ghc" c331592/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c331592130ef592b92084e7417581a4039bfa7d2" Correct limb length and assertion for gcdExtInteger Reviewers: hvr, bgamari, monoidal Reviewed By: monoidal Subscribers: monoidal, rwbarton, thomie, carter GHC Trac Issues: #15350 Differential Revision: https://phabricator.haskell.org/D5042 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 22:56:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 22:56:23 -0000 Subject: [GHC] #15508: concprog001 fails with various errors when compiled with -prof In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.9936b3ddff7e8cd81a95f15438877d8a@haskell.org> #15508: concprog001 fails with various errors when compiled with -prof -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Profiling | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5051 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2693eb11f55f2001701c90c24183e21c794a8be1/ghc" 2693eb1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2693eb11f55f2001701c90c24183e21c794a8be1" Properly tag fun field of PAPs generated by ap_0_fast Currently ap_0_fast doesn't maintain the invariant for PAP fun fields which says if the closure can be tagged, it should be. This is checked by `Sanity.c:checkPAP` and correctly implemented by `genautoapply`. This causes sanity check failures when we have a profiling code like f = {-# SCC scc #-} g where g is a PAP or a FUN, and `scc` is different than the current cost centre. Test Plan: Slow validate (not done yet) Reviewers: simonmar, bgamari, erikd Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15508 Differential Revision: https://phabricator.haskell.org/D5051 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 22:56:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 22:56:23 -0000 Subject: [GHC] #15189: Avoid word "transformer" in the documentation of ST In-Reply-To: <051.babfb617b882c0b638e02ac50b14cd85@haskell.org> References: <051.babfb617b882c0b638e02ac50b14cd85@haskell.org> Message-ID: <066.bb8cac0bcd8cca92427607c1a2c0afab@haskell.org> #15189: Avoid word "transformer" in the documentation of ST -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: ulysses4ever Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Documentation | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5019 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8546afc502306de16b62c6386fe419753393cb12/ghc" 8546afc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8546afc502306de16b62c6386fe419753393cb12" docs: "state transformer" -> "state monad" / "ST" (whichever is meant) FIxes #15189. Reviewers: hvr, bgamari, simonmar, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, thomie, carter GHC Trac Issues: #15189 Differential Revision: https://phabricator.haskell.org/D5019 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 22:58:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 22:58:49 -0000 Subject: [GHC] #15475: Plugin recompilation check still panics In-Reply-To: <049.1dcd6c48f70db9da972b9cd8df87f1a4@haskell.org> References: <049.1dcd6c48f70db9da972b9cd8df87f1a4@haskell.org> Message-ID: <064.9f01cd0f891493909aaab16136f95169@haskell.org> #15475: Plugin recompilation check still panics -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5048 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 13105a1ae870da6936a27cdd1d6a4bd25a661368. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 22:59:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 22:59:02 -0000 Subject: [GHC] #15527: TypeApplications error message doesn't parenthesize infix name In-Reply-To: <050.477d5429b1a8f48b2e52c0542d2adea3@haskell.org> References: <050.477d5429b1a8f48b2e52c0542d2adea3@haskell.org> Message-ID: <065.4486748567e74543eb552d44b171f946@haskell.org> #15527: TypeApplications error message doesn't parenthesize infix name -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5071 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with fb8b2cb11023dd453b22ba49b7535b6ae8a8b506. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 22:59:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 22:59:20 -0000 Subject: [GHC] #15279: CPP #includes may result in nonsensical SrcSpans In-Reply-To: <045.4d706fecf4a6cf42667f6871be2d3572@haskell.org> References: <045.4d706fecf4a6cf42667f6871be2d3572@haskell.org> Message-ID: <060.33ff1bae15a9f2d05626cfe7b3afce5c@haskell.org> #15279: CPP #includes may result in nonsensical SrcSpans -------------------------------------+------------------------------------- Reporter: wz1000 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: cpp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #14113 | Differential Rev(s): Phab:D4866 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.6.1 Comment: Merged with 033d6ac775fad0aee9335169a41d19f54eee1486. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 23:02:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 23:02:44 -0000 Subject: [GHC] #15499: Panic in occurence analysis phase (?), getRuntimeRep In-Reply-To: <048.4ced706f36b918299fae10c865c8eddf@haskell.org> References: <048.4ced706f36b918299fae10c865c8eddf@haskell.org> Message-ID: <063.cb276c23db1417222112ca62ab46a206@haskell.org> #15499: Panic in occurence analysis phase (?), getRuntimeRep -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: RyanGlScott Type: bug | Status: closed Priority: high | Milestone: 8.4.4 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5060 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: deepfire, it's rather unlikely that there will be a 8.4.4. However, I've merged the fix to 8.6.1 and the `ghc-8.4` branch just in case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 23:28:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 23:28:42 -0000 Subject: [GHC] #314: #line pragmas not respected inside nested comments In-Reply-To: <045.e2d94babc1a72770327e5dfb6388ae06@haskell.org> References: <045.e2d94babc1a72770327e5dfb6388ae06@haskell.org> Message-ID: <060.c7f986a8c33b41f0941689a077ce5f8c@haskell.org> #314: #line pragmas not respected inside nested comments -------------------------------------+------------------------------------- Reporter: nobody | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 6.4 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: read032 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4934 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: None => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 23:28:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 23:28:53 -0000 Subject: [GHC] #15426: `elemIndex` and `findIndex` still can't fuse In-Reply-To: <045.556cc5a15fe7d0c4bec73444eba7ef79@haskell.org> References: <045.556cc5a15fe7d0c4bec73444eba7ef79@haskell.org> Message-ID: <060.06701a9a58dda7aa5fa0b1f0e07683f5@haskell.org> #15426: `elemIndex` and `findIndex` still can't fuse -------------------------------------+------------------------------------- Reporter: kabuhr | Owner: kabuhr Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: libraries/base | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/perf/should_run/T15426.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://phabricator.haskell.org/D5063 -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 23:29:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 23:29:18 -0000 Subject: [GHC] #15261: Show -with-rtsopts options in runtime's --info In-Reply-To: <043.f2c7fda7e5ce90f13c2733f909af5e70@haskell.org> References: <043.f2c7fda7e5ce90f13c2733f909af5e70@haskell.org> Message-ID: <058.484a4748ebb16f40d474c79875e54244@haskell.org> #15261: Show -with-rtsopts options in runtime's --info -------------------------------------+------------------------------------- Reporter: osa1 | Owner: RolandSenn Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T15261a | T15261b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5053 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 23:29:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 23:29:26 -0000 Subject: [GHC] #15482: the_gc_thread variable from GC.c is not aligned to 64 In-Reply-To: <045.517cd029a074e1225f6142d10f834f62@haskell.org> References: <045.517cd029a074e1225f6142d10f834f62@haskell.org> Message-ID: <060.e21b2ad87cf67156614a8ba68aad9b68@haskell.org> #15482: the_gc_thread variable from GC.c is not aligned to 64 -------------------------------------+------------------------------------- Reporter: arrowd | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 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): Phab:D5052 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 23:29:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 23:29:34 -0000 Subject: [GHC] #15350: gcdExtInteger violates assertion In-Reply-To: <047.463f72a51535cf21b879b51cdb0841bf@haskell.org> References: <047.463f72a51535cf21b879b51cdb0841bf@haskell.org> Message-ID: <062.3e7c49665d1c2c3db5195e3ab5c5d19f@haskell.org> #15350: gcdExtInteger violates assertion -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: Bodigrim Type: bug | Status: merge Priority: high | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5042 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 23:29:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 23:29:54 -0000 Subject: [GHC] #15189: Avoid word "transformer" in the documentation of ST In-Reply-To: <051.babfb617b882c0b638e02ac50b14cd85@haskell.org> References: <051.babfb617b882c0b638e02ac50b14cd85@haskell.org> Message-ID: <066.ce14e5173fd7d490640b0bfe72fe12f9@haskell.org> #15189: Avoid word "transformer" in the documentation of ST -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: ulysses4ever Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Documentation | Version: 8.2.2 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5019 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 23:30:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 23:30:12 -0000 Subject: [GHC] #15508: concprog001 fails with various errors when compiled with -prof In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.eb94a7626812d32f362e0c79b43f818f@haskell.org> #15508: concprog001 fails with various errors when compiled with -prof -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.6.1 Component: Profiling | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5051 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 23:32:43 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 23:32:43 -0000 Subject: [GHC] #10869: Option to dump preprocessed source In-Reply-To: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> References: <046.34bba2c2c1e4ccec0498d1f1e04c25f9@haskell.org> Message-ID: <061.4284c9829ed271a51ac8a3ff93862a9f@haskell.org> #10869: Option to dump preprocessed source -------------------------------------+------------------------------------- Reporter: phischu | Owner: RolandSenn Type: feature request | Status: closed Priority: low | Milestone: 8.8.1 Component: Driver | Version: 7.10.2 Resolution: fixed | Keywords: easy Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T10869 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4861 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 23:33:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 23:33:38 -0000 Subject: [GHC] #15540: GHCi does not follow the XDG Base Directory Specification In-Reply-To: <047.104e0b09441c5fa58dd1aeb68ec6fc11@haskell.org> References: <047.104e0b09441c5fa58dd1aeb68ec6fc11@haskell.org> Message-ID: <062.c7acfbb38e4870cdd39602a81be588d3@haskell.org> #15540: GHCi does not follow the XDG Base Directory Specification -------------------------------------+------------------------------------- Reporter: rszibele | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.0.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rszibele): The package database would also belong in `$XDG_CACHE_HOME/ghc`, I used `.ghci_history` as an example. Supporting the XDG Base Directory Specification would allow users to easily back up their configuration files while at the same time not including cache in the backup. It also allows for deleting the cache of a user without having to check which files are essential and which files aren't, as one could simply delete all files in `$XDG_CACHE_HOME/`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 21 23:57:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Aug 2018 23:57:33 -0000 Subject: [GHC] #15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite In-Reply-To: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> References: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> Message-ID: <061.b2baf8329698ba211a31e946000deeaa@haskell.org> #15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Old description: > {{{ > $ cabal get cryptohash-sha256-0.11.101.0 > $ cabal new-run -w ghc-8.6.1 --enable-test --allow-newer=cryptohash- > sha256:base,*:stm,*:tasty,async:base test:test-sha256 -- -j 8 > --quickcheck-tests 9999 > }}} > > Eventually the program will start spamming stderr with `test-sha256: lost > signal due to full pipe: 11` repeatedly. This apparently only started > with 8.6.1. New description: {{{ $ cabal get cryptohash-sha256-0.11.101.0 $ cd cryptohash-sha256-0.11.101.0 $ cabal new-run -w ghc-8.6.1 --enable-test --allow- newer=*:base,*:stm,*:tasty test:test-sha256 -- -j 8 --quickcheck-tests 9999 }}} Eventually the program will start spamming stderr with `test-sha256: lost signal due to full pipe: 11` repeatedly. This apparently only started with 8.6.1. -- Comment (by sjakobi): Another variation I'm seeing when I add `--timeout 1s` is {{{ XL-vec inc: test-sha256: internal error: evacuate: strange closure type 0 (GHC version 8.6.0.20180810 for x86_64_unknown_linux) }}} Strangely I can't reproduce the bug when I try to run the apparently problematic testcase with `--pattern KATs.XL-vec.inc`. Also note that a similar issue has been reported for GHC-8.2.2 on 32-mips at https://github.com/haskell-hvr/cryptohash-sha256/issues/3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 00:07:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 00:07:03 -0000 Subject: [GHC] #15554: COMPLETE pragmas make overlapping-patterns warnings behave oddly Message-ID: <047.6c0d8acd4eda037d66735e85a80215a1@haskell.org> #15554: COMPLETE pragmas make overlapping-patterns warnings behave oddly -------------------------------------+------------------------------------- Reporter: staffehn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I can’t really quantify what’s wrong and what’s intended here, here’s a test file comparing different contrasting examples of similar functions which generate no or strange warnings in the cases that use a datatype with COMPLETE pragmas on pattern synonyms. {{{#!hs {- 1 -} {-# LANGUAGE PatternSynonyms, ViewPatterns #-} {- 2 -} {- 3 -} module M where {- 4 -} {- 5 -} data T = A | B | C {- 6 -} {- 7 -} isBC :: T -> Bool {- 8 -} isBC A = False {- 9 -} isBC B = True {- 10 -} isBC C = True {- 11 -} {- 12 -} pattern BC :: T {- 13 -} pattern BC <- (isBC -> True) {- 14 -} {-# COMPLETE A, BC #-} {- 15 -} {- 16 -} g1 :: T -> Int {- 17 -} g1 A = 1 {- 18 -} g1 BC = 2 {- 19 -} g1 _ = 3 {- 20 -} {- 21 -} -- M.hs:18:1: warning: [-Woverlapping-patterns] {- 22 -} -- Pattern match is redundant {- 23 -} -- In an equation for `g1': g1 BC = ... {- 24 -} -- | {- 25 -} -- 18 | {- 18 -} g1 BC = 2 {- 26 -} -- | ^^^^^^^^^ {- 27 -} {- 28 -} g2 :: T -> Int {- 29 -} g2 BC = 2 {- 30 -} g2 A = 1 {- 31 -} g2 _ = 3 {- 32 -} {- 33 -} -- g2: no warnings {- 34 -} {- 35 -} g3 :: T -> Int {- 36 -} g3 BC = 2 {- 37 -} g3 _ = 1 {- 38 -} g3 A = 3 {- 39 -} g3 A = 4 {- 40 -} g3 B = 4 {- 41 -} g3 B = 4 {- 42 -} g3 C = 4 {- 43 -} g3 C = 4 {- 44 -} g3 _ = 4 {- 45 -} g3 _ = 4 {- 46 -} {- 47 -} -- g3: no warnings {- 48 -} {- 49 -} data T' = A' | B' | C' {- 50 -} {- 51 -} isBC' :: T' -> Bool {- 52 -} isBC' A' = False {- 53 -} isBC' B' = True {- 54 -} isBC' C' = True {- 55 -} {- 56 -} pattern BC' :: T' {- 57 -} pattern BC' <- (isBC' -> True) {- 58 -} -- no COMPLETE pragma {- 59 -} {- 60 -} g3' :: T' -> Int {- 61 -} g3' BC' = 2 {- 62 -} g3' _ = 1 {- 63 -} g3' A' = 3 {- 64 -} g3' A' = 4 {- 65 -} g3' B' = 4 {- 66 -} g3' B' = 4 {- 67 -} g3' C' = 4 {- 68 -} g3' C' = 4 {- 69 -} g3' _ = 4 {- 70 -} g3' _ = 4 {- 71 -} {- 72 -} -- M.hs:63:1: warning: [-Woverlapping-patterns] {- 73 -} -- Pattern match is redundant {- 74 -} -- In an equation for g3': g3' A' = ... {- 75 -} -- | {- 76 -} -- 63 | {- 63 -} g3' A' = 3 {- 77 -} -- | ^^^^^^^^^^ {- 78 -} -- {- 79 -} -- M.hs:64:1: warning: [-Woverlapping-patterns] {- 80 -} -- Pattern match is redundant {- 81 -} -- In an equation for g3': g3' A' = ... {- 82 -} -- | {- 83 -} -- 64 | {- 64 -} g3' A' = 4 {- 84 -} -- | ^^^^^^^^^^ {- 85 -} -- {- 86 -} -- M.hs:65:1: warning: [-Woverlapping-patterns] {- 87 -} -- Pattern match is redundant {- 88 -} -- In an equation for g3': g3' B' = ... {- 89 -} -- | {- 90 -} -- 65 | {- 65 -} g3' B' = 4 {- 91 -} -- | ^^^^^^^^^^ {- 92 -} -- {- 93 -} -- M.hs:66:1: warning: [-Woverlapping-patterns] {- 94 -} -- Pattern match is redundant {- 95 -} -- In an equation for g3': g3' B' = ... {- 96 -} -- | {- 97 -} -- 66 | {- 66 -} g3' B' = 4 {- 98 -} -- | ^^^^^^^^^^ {- 99 -} -- {- 100 -} -- M.hs:67:1: warning: [-Woverlapping-patterns] {- 101 -} -- Pattern match is redundant {- 102 -} -- In an equation for g3': g3' C' = ... {- 103 -} -- | {- 104 -} -- 67 | {- 67 -} g3' C' = 4 {- 105 -} -- | ^^^^^^^^^^ {- 106 -} -- {- 107 -} -- M.hs:68:1: warning: [-Woverlapping-patterns] {- 108 -} -- Pattern match is redundant {- 109 -} -- In an equation for g3': g3' C' = ... {- 110 -} -- | {- 111 -} -- 68 | {- 68 -} g3' C' = 4 {- 112 -} -- | ^^^^^^^^^^ {- 113 -} -- {- 114 -} -- M.hs:69:1: warning: [-Woverlapping-patterns] {- 115 -} -- Pattern match is redundant {- 116 -} -- In an equation for g3': g3' _ = ... {- 117 -} -- | {- 118 -} -- 69 | {- 69 -} g3' _ = 4 {- 119 -} -- | ^^^^^^^^^ {- 120 -} -- {- 121 -} -- M.hs:70:1: warning: [-Woverlapping-patterns] {- 122 -} -- Pattern match is redundant {- 123 -} -- In an equation for g3': g3' _ = ... {- 124 -} -- | {- 125 -} -- 70 | {- 70 -} g3' _ = 4 {- 126 -} -- | ^^^^^^^^^ {- 127 -} {- 128 -} {- 129 -} data S = X {- 130 -} {- 131 -} pattern Y :: S {- 132 -} pattern Y = X {- 133 -} {-# COMPLETE Y #-} {- 134 -} {- 135 -} f1 :: S -> Int {- 136 -} f1 Y = 1 {- 137 -} f1 _ = 2 {- 138 -} {- 139 -} -- f1: no warnings {- 140 -} {- 141 -} f2 :: S -> Int {- 142 -} f2 X = 1 {- 143 -} f2 _ = 2 {- 144 -} {- 145 -} -- M.hs:143:1: warning: [-Woverlapping-patterns] {- 146 -} -- Pattern match is redundant {- 147 -} -- In an equation for `f2': f2 _ = ... {- 148 -} -- | {- 149 -} -- 143 | {- 143 -} f2 _ = 2 {- 150 -} -- | ^^^^^^^^ {- 151 -} {- 152 -} f3 :: S -> Int {- 153 -} f3 Y = 0 {- 154 -} f3 X = 1 {- 155 -} f3 _ = 2 {- 156 -} {- 157 -} -- f3: no warnings {- 158 -} {- 159 -} data S' = X' {- 160 -} {- 161 -} pattern Y' :: S' {- 162 -} pattern Y' = X' {- 163 -} -- no COMPLETE pragma {- 164 -} {- 165 -} f3' :: S' -> Int {- 166 -} f3' Y' = 1 {- 167 -} f3' X' = 0 {- 168 -} f3' _ = 2 {- 169 -} {- 170 -} -- M.hs:168:1: warning: [-Woverlapping-patterns] {- 171 -} -- Pattern match is redundant {- 172 -} -- In an equation for f3': f3' _ = ... {- 173 -} -- | {- 174 -} -- 168 | {- 168 -} f3' _ = 2 {- 175 -} -- | ^^^^^^^^^ }}} In particular: the warning for line 18 should probably be a warning for line 19, and there should be a similar warning for line 31. `g3` extends `g2` in a ridiculous way still without generating any warnings. `g3'` demonstrates the warnings one should expect. The `f` functions are perhaps a bit redundant, but I wanted to include a smaller datatype. I’m not sure if this is easily fixable, since I’m having doubts, that COMPLETE pragmas give enough information for generating good overlapping- patterns warnings. I didn’t think this matter through in detail, but, well, maybe it’s not that important to have this all that sophisticated anyways, since for example guards won’t give overlapping-patterns warnings either. But at least (IMO) it’d be nice to keep the warnings about the normal constructor’s patterns even when they’re mixed with pattern synonyms that have a COMPLETE pragma. Even further, I would always expect overlapping-patterns warnings when a pattern is simply duplicated and probably always if any additional pattern follows a complete listing of everything in a COMPLETE group. And there’s probably lots of cases one could consider naturally suggesting a warning; maybe someone can find a good principle/algorithm to use here. Going further, to prevent COMPLETE pragma setting that always give an overlapping-patterns or incomplete-patterns warnings, one could even consider warning directly at a COMPLETE pragma when it’s a strict subset of an existing COMPLETE group. By the way, my actual goal while finding this bug was to describe another (maybe) bug, which is that the incomplete-patterns warnings can suggest missing pattern synonyms that are not even in scope, which seems not very neat in some cases. In case someone really wants to rework all these warnings, I can make a separate ticket or give details on such a non-neat case that here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 00:35:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 00:35:03 -0000 Subject: [GHC] #15550: Names of RULES aren't quoted in -ddump-splices In-Reply-To: <050.b5daffb0170f6fb061ff2380766e1195@haskell.org> References: <050.b5daffb0170f6fb061ff2380766e1195@haskell.org> Message-ID: <065.3156983865fc2f6aab028d71d2d2d9de@haskell.org> #15550: Names of RULES aren't quoted in -ddump-splices -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: alanz (added) Comment: So I've identified the problem, which lies in `Convert`: when converting a Template Haskell `RuleP` into a GHC source `RuleD`, we take the `RuleP`'s name (which is not surrounded in double quotes) and repurpose that as the `SourceText` for the `RuleD`'s name. However, the `RuleD` name's `SourceText` must be intended to be the precise name of the rewrite rule, double quotes and all, since using the unquoted name from the `RuleP` causes it to be pretty-printed without double quotes. In light of this, one way to fix this issue is with this patch: {{{#!diff diff --git a/compiler/hsSyn/Convert.hs b/compiler/hsSyn/Convert.hs index 24b0b20..87b3400 100644 --- a/compiler/hsSyn/Convert.hs +++ b/compiler/hsSyn/Convert.hs @@ -705,7 +705,7 @@ cvtPragmaD (RuleP nm bndrs lhs rhs phases) ; rhs' <- cvtl rhs ; returnJustL $ Hs.RuleD noExt $ HsRules noExt (SourceText "{-# RULES") - [noLoc $ HsRule noExt (noLoc (SourceText nm,nm')) act + [noLoc $ HsRule noExt (noLoc (quotedSourceText,nm')) act bndrs' lhs' rhs'] } }}} However, this leads me to wonder: is this `SourceText` name supposed to reflect a //user-written// rule name? That is, the exact syntax that the user types in a source Haskell file? If so, then it feels somewhat strange to put a `SourceText` here, since this `RuleD` is generated through Template Haskell behind the scenes, not through source syntax. In fact, another way to fix this issue is by not using `SourceText` at all, and instead using `NoSourceText`: {{{#!diff diff --git a/compiler/hsSyn/Convert.hs b/compiler/hsSyn/Convert.hs index 24b0b20..87b3400 100644 --- a/compiler/hsSyn/Convert.hs +++ b/compiler/hsSyn/Convert.hs @@ -705,7 +705,7 @@ cvtPragmaD (RuleP nm bndrs lhs rhs phases) ; rhs' <- cvtl rhs ; returnJustL $ Hs.RuleD noExt $ HsRules noExt (SourceText "{-# RULES") - [noLoc $ HsRule noExt (noLoc (SourceText nm,nm')) act + [noLoc $ HsRule noExt (noLoc (NoSourceText,nm')) act bndrs' lhs' rhs'] } }}} (See [http://git.haskell.org/ghc.git/blob/21f0f56164f50844c2150c62f950983b2376f8b6:/compiler/hsSyn/HsDecls.hs#l2193 pprFullRuleName] to see why that gets pretty-printed correctly.) I honestly have no idea which is the correct choice to make. Other places in `Convert` seem to vary in their uses of `SourceText` and `NoSourceText`, so it's hard to tell if there's already an established convention in `Convert`. alanz, what are your thoughts on this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 00:41:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 00:41:27 -0000 Subject: [GHC] #15555: Finish separating the stable name and stable pointer tables Message-ID: <045.c599c4ef0bcb291ee1dd9d8857e04c44@haskell.org> #15555: Finish separating the stable name and stable pointer tables -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Runtime | Version: 8.4.3 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The stable name table and stable pointer table are both implemented in `rts/Stable.c`, with their code interleaved. As far as I can tell, they basically don't share ''anything''—or at least anything that they actually ''should''. They ''do'' share a mutex, which smells like a terrible idea. Doesn't that just introduce contention between `StableName` and `StablePtr` operations in different threads? They also share an initialization function, `initStableTables`, that appears to allocate both a stable name table and a stable pointer table as soon as either of them is needed. Unless I'm missing something, there's no point whatsoever in doing that. So I think we should actually divide `Stable.c` into `StableName.c` and `StablePtr.c` and give each its own mutex. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 00:53:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 00:53:48 -0000 Subject: [GHC] #15554: COMPLETE pragmas make overlapping-patterns warnings behave oddly In-Reply-To: <047.6c0d8acd4eda037d66735e85a80215a1@haskell.org> References: <047.6c0d8acd4eda037d66735e85a80215a1@haskell.org> Message-ID: <062.0282fc0e8825de748a12f38c833a5855@haskell.org> #15554: COMPLETE pragmas make overlapping-patterns warnings behave oddly -------------------------------------+------------------------------------- Reporter: staffehn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | PatternMatchWarnings, | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => PatternMatchWarnings, PatternSynonyms Comment: I think this is essentially the same bug as #13363. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 00:54:21 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 00:54:21 -0000 Subject: [GHC] #13363: Wildcard patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings In-Reply-To: <050.2a806a34373c70cf9df263507dff2e0a@haskell.org> References: <050.2a806a34373c70cf9df263507dff2e0a@haskell.org> Message-ID: <065.3fbc6b91e54334c947c1d3948e65e0f6@haskell.org> #13363: Wildcard patterns and COMPLETE sets can lead to misleading redundant pattern-match warnings -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: | PatternSynonyms, | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15554 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15554 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 00:54:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 00:54:30 -0000 Subject: [GHC] #15554: COMPLETE pragmas make overlapping-patterns warnings behave oddly In-Reply-To: <047.6c0d8acd4eda037d66735e85a80215a1@haskell.org> References: <047.6c0d8acd4eda037d66735e85a80215a1@haskell.org> Message-ID: <062.752c7ce196608adee24a682d661dff5a@haskell.org> #15554: COMPLETE pragmas make overlapping-patterns warnings behave oddly -------------------------------------+------------------------------------- Reporter: staffehn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | PatternMatchWarnings, | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13363 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13363 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 02:14:39 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 02:14:39 -0000 Subject: [GHC] #15549: Core Lint error with EmptyCase In-Reply-To: <050.9a179952570cbedc58a57ced12c92bb9@haskell.org> References: <050.9a179952570cbedc58a57ced12c92bb9@haskell.org> Message-ID: <065.4e6e03e4bf7e705eece547b109b77a5c@haskell.org> #15549: Core Lint error with EmptyCase -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeFamilies, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: goldfire (added) Comment: The culprit here appears to be [http://git.haskell.org/ghc.git/blob/21f0f56164f50844c2150c62f950983b2376f8b6:/compiler/simplCore/Simplify.hs#l2566 improveSeq]. In particular, in its use of `topNormaliseType_maybe`: {{{ improveSeq :: (FamInstEnv, FamInstEnv) -> SimplEnv -> OutExpr -> InId -> OutId -> [InAlt] -> SimplM (SimplEnv, OutExpr, OutId) -- Note [Improving seq] improveSeq fam_envs env scrut case_bndr case_bndr1 [(DEFAULT,_,_)] | Just (co, ty2) <- topNormaliseType_maybe fam_envs (idType case_bndr1) = do { case_bndr2 <- newId (fsLit "nt") ty2 ; let rhs = DoneEx (Var case_bndr2 `Cast` mkSymCo co) Nothing env2 = extendIdSubst env case_bndr rhs ; return (env2, scrut `Cast` co, case_bndr2) } }}} In the program in comment:1, `scrut` is `x` (from `sTo`), and `idType case_bndr1` is `Sing (Rep Void) r` (where `(r :: Rep Void)`). It's `topNormaliseType_maybe`'s job to reduce the two type families in `Sing (Rep Void) r` (in particular, `Rep Void ~# Void` and then `Sing Void ~# R:SingVoidz`) and return the coercion that witnesses this reduction. However, it appears to produce an entirely bogus coercion: {{{ Sing (D:R:RepVoid[0]) _N)_R ; D:R:SingVoidz0[0] _N :: (Sing (Rep Void) r) ~R# (R:SingVoidz r) }}} Why is this bogus? Because in the axiom `D:R:SingVoidz0[0]`, we have: {{{ COERCION AXIOMS axiom Bug.D:R:SingVoidz0 :: forall {z :: Void}. Sing Void z = Bug.R:SingVoidz -- Defined at ../Bug.hs:11:15 }}} Notice that the argument to `D:R:SingVoidz0[0]` is of type `Void`, but in the coercion above, we're giving it `r` as an argument, which is of type `Rep Void`, not `Void`! Unsurprisingly, utter pandemonium ensues when Core Lint inspects this garbage. The proper coercion would be something like what the second program in comment:1 produces: {{{ (Sing (D:R:RepVoid[0]) (GRefl nominal r (D:R:RepVoid[0])))_R ; D:R:SingVoidz0[0] <(r |> D:R:RepVoid[0])>_N :: (Sing (Rep Void) r :: *) ~R# (R:SingVoidz (r |> D:R:RepVoid[0]) :: *) }}} Alas, `topNormaliseType_maybe` doesn't produce this. goldfire, do you think the reason that this doesn't happen is due to the same underlying reasons as in #14729? I strongly suspect that this is the case, since I tried calling `normaliseType` on `Sing (Rep Void) r`, and it produces the same bogus coercion that `topNormaliseType_maybe` did. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 02:21:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 02:21:08 -0000 Subject: [GHC] #15540: GHCi does not follow the XDG Base Directory Specification In-Reply-To: <047.104e0b09441c5fa58dd1aeb68ec6fc11@haskell.org> References: <047.104e0b09441c5fa58dd1aeb68ec6fc11@haskell.org> Message-ID: <062.20470cf4b4bca7e9e38ff05511e09ebe@haskell.org> #15540: GHCi does not follow the XDG Base Directory Specification -------------------------------------+------------------------------------- Reporter: rszibele | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.0.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by potato44): > The package database would also belong in `$XDG_CACHE_HOME/ghc` I don't think this is quite right, I believe you are meant to be able to delete the cache directory without ill effect. I believe the correct directory would be `$XDG_DATA_HOME/ghc`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 02:22:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 02:22:35 -0000 Subject: [GHC] #15555: Finish separating the stable name and stable pointer tables In-Reply-To: <045.c599c4ef0bcb291ee1dd9d8857e04c44@haskell.org> References: <045.c599c4ef0bcb291ee1dd9d8857e04c44@haskell.org> Message-ID: <060.72067cd4ee8fddd1e4330d4b8b1d4563@haskell.org> #15555: Finish separating the stable name and stable pointer tables -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): One question: we currently expose `hs_lock_stable_tables` and `hs_unlock_stable_tables` from `includes/HsFFI.h`. As far as I can tell, these aren't documented in the user's guide, and aren't used as FFI imports in any packages that ship with GHC. Are these exposed intentionally? If so, they should be documented (and I'll have to implement versions that lock both the stable name table and the stable pointer table). Otherwise, I'd like to be rid of them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 02:42:53 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 02:42:53 -0000 Subject: [GHC] #6077: Respect XDG_CONFIG_HOME In-Reply-To: <045.4be78870b39bed231ff23249aec382c8@haskell.org> References: <045.4be78870b39bed231ff23249aec382c8@haskell.org> Message-ID: <060.996a197b6102a51d35013d3026a6498e@haskell.org> #6077: Respect XDG_CONFIG_HOME -------------------------------------+------------------------------------- Reporter: So8res | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: None | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 5966 | Blocking: Related Tickets: 15540 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by potato44): * related: => 15540 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 02:43:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 02:43:26 -0000 Subject: [GHC] #6077: Respect XDG_CONFIG_HOME In-Reply-To: <045.4be78870b39bed231ff23249aec382c8@haskell.org> References: <045.4be78870b39bed231ff23249aec382c8@haskell.org> Message-ID: <060.aa5f49bc6041546aec68a042704465c4@haskell.org> #6077: Respect XDG_CONFIG_HOME -------------------------------------+------------------------------------- Reporter: So8res | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: None | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 5966 | Blocking: Related Tickets: #15540 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by potato44): * related: 15540 => #15540 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 02:43:52 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 02:43:52 -0000 Subject: [GHC] #15540: GHCi does not follow the XDG Base Directory Specification In-Reply-To: <047.104e0b09441c5fa58dd1aeb68ec6fc11@haskell.org> References: <047.104e0b09441c5fa58dd1aeb68ec6fc11@haskell.org> Message-ID: <062.4e2942352f84c549ea1665055a33a6df@haskell.org> #15540: GHCi does not follow the XDG Base Directory Specification -------------------------------------+------------------------------------- Reporter: rszibele | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.0.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6077 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by potato44): * related: => #6077 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 02:51:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 02:51:44 -0000 Subject: [GHC] #15549: Core Lint error with EmptyCase In-Reply-To: <050.9a179952570cbedc58a57ced12c92bb9@haskell.org> References: <050.9a179952570cbedc58a57ced12c92bb9@haskell.org> Message-ID: <065.eb76a28b0553cbd9a2db1484418b0a71@haskell.org> #15549: Core Lint error with EmptyCase -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeFamilies, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, this looks like #14729. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 02:53:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 02:53:25 -0000 Subject: [GHC] #15549: Core Lint error with EmptyCase In-Reply-To: <050.9a179952570cbedc58a57ced12c92bb9@haskell.org> References: <050.9a179952570cbedc58a57ced12c92bb9@haskell.org> Message-ID: <065.e35b6d1462e164563c683619de7865f5@haskell.org> #15549: Core Lint error with EmptyCase -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeFamilies, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14729 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #14729 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 02:54:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 02:54:29 -0000 Subject: [GHC] #14729: normaliseType is not well-kinded In-Reply-To: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> References: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> Message-ID: <062.22d8b02905cdb5b291178dd2aea96c17@haskell.org> #14729: normaliseType is not well-kinded -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15549 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15549 Comment: See #15549 for a program which fails Core Lint due to this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 03:45:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 03:45:40 -0000 Subject: [GHC] #15555: Finish separating the stable name and stable pointer tables In-Reply-To: <045.c599c4ef0bcb291ee1dd9d8857e04c44@haskell.org> References: <045.c599c4ef0bcb291ee1dd9d8857e04c44@haskell.org> Message-ID: <060.7decdc78c4e98b2490eaea7b02c09c5e@haskell.org> #15555: Finish separating the stable name and stable pointer tables -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description: > The stable name table and stable pointer table are both implemented in > `rts/Stable.c`, with their code interleaved. As far as I can tell, they > basically don't share ''anything''—or at least anything that they > actually ''should''. They ''do'' share a mutex, which smells like a > terrible idea. Doesn't that just introduce contention between > `StableName` and `StablePtr` operations in different threads? They also > share an initialization function, `initStableTables`, that appears to > allocate both a stable name table and a stable pointer table as soon as > either of them is needed. Unless I'm missing something, there's no point > whatsoever in doing that. So I think we should actually divide `Stable.c` > into `StableName.c` and `StablePtr.c` and give each its own mutex. New description: The stable name table and stable pointer table are both implemented in `rts/Stable.c`, with their code interleaved. Presumably this is for historical reasons; they were once one table, and they were split for performance reasons (see #7674). As far as I can tell, they basically don't share ''anything''—or at least anything that they actually ''should''. They ''do'' share a mutex, which smells like a terrible idea. Doesn't that just introduce contention between `StableName` and `StablePtr` operations in different threads? They also share an initialization function, `initStableTables`, that appears to allocate both a stable name table and a stable pointer table as soon as either of them is needed. Unless I'm missing something, there's no point whatsoever in doing that. So I think we should actually divide `Stable.c` into `StableName.c` and `StablePtr.c` and give each its own mutex. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 03:51:19 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 03:51:19 -0000 Subject: [GHC] #15555: Finish separating the stable name and stable pointer tables In-Reply-To: <045.c599c4ef0bcb291ee1dd9d8857e04c44@haskell.org> References: <045.c599c4ef0bcb291ee1dd9d8857e04c44@haskell.org> Message-ID: <060.c70aa9501774a2021f1233fb14ef6ad3@haskell.org> #15555: Finish separating the stable name and stable pointer tables -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5084 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * differential: => Phab:D5084 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 03:53:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 03:53:59 -0000 Subject: [GHC] #7674: Separate StablePtr table from StableName table. In-Reply-To: <048.d2a5d56c1de3421f091c52024ec9dfdd@haskell.org> References: <048.d2a5d56c1de3421f091c52024ec9dfdd@haskell.org> Message-ID: <063.d932146a89688489dbc0e132f35f4d5e@haskell.org> #7674: Separate StablePtr table from StableName table. -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.2 Resolution: fixed | Keywords: rts | stable_ptr stable_name performance Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15555 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * related: => #15555 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 03:54:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 03:54:50 -0000 Subject: [GHC] #15555: Finish separating the stable name and stable pointer tables In-Reply-To: <045.c599c4ef0bcb291ee1dd9d8857e04c44@haskell.org> References: <045.c599c4ef0bcb291ee1dd9d8857e04c44@haskell.org> Message-ID: <060.a8c582d1bf11d85eed29716bcecf581e@haskell.org> #15555: Finish separating the stable name and stable pointer tables -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7674 | Differential Rev(s): Phab:D5084 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * related: => #7674 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 05:44:15 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 05:44:15 -0000 Subject: [GHC] #15555: Finish separating the stable name and stable pointer tables In-Reply-To: <045.c599c4ef0bcb291ee1dd9d8857e04c44@haskell.org> References: <045.c599c4ef0bcb291ee1dd9d8857e04c44@haskell.org> Message-ID: <060.488c80a014cc388674337d39d20a3a09@haskell.org> #15555: Finish separating the stable name and stable pointer tables -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7674 | Differential Rev(s): Phab:D5084 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 05:47:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 05:47:59 -0000 Subject: [GHC] #15508: concprog001 fails with various errors when compiled with -prof In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.c75d4e81ead41a2830e89887e480ea2c@haskell.org> #15508: concprog001 fails with various errors when compiled with -prof -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.6.1 Component: Profiling | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5051 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): bgamari, the commit above should be reverted as it breaks another program (not caught by the test suite, see my comments in the diff). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 05:54:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 05:54:10 -0000 Subject: [GHC] #15508: concprog001 fails with various errors when compiled with -prof In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.5dd5eee393f396aaf880bedbcd8d661d@haskell.org> #15508: concprog001 fails with various errors when compiled with -prof -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Profiling | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5051 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: merge => new Comment: Reverted the commit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 06:44:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 06:44:42 -0000 Subject: [GHC] #15508: concprog001 fails with various errors when compiled with -prof In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.2cef5abc1f803552f619b06214a26ea7@haskell.org> #15508: concprog001 fails with various errors when compiled with -prof -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Profiling | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5051 Wiki Page: | -------------------------------------+------------------------------------- Description changed by osa1: Old description: > I'm observing a few different runtime errors. I'm not sure if they're > because of different bugs so I'm filing one ticket for now. > > The reproduce with GHC HEAD: > > {{{ > prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce- > recomp -threaded > [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) > [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) > [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) > [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) > [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) > [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) > [7 of 7] Compiling Main ( Mult.hs, Mult.o ) > Linking Mult ... > > prog001 git:(master) $ ./Mult +RTS -N2 > Mult: internal error: scavenge_one: strange object 624722688 > (GHC version 8.7.20180809 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > zsh: abort (core dumped) ./Mult +RTS -N2 > }}} > > It's very easy to trigger other kind of panics in `concprog001`, just try > different compile and runtime flag combinations. Note that for the > examples below you'll need debug + profiling or debug + profiling + > threaded runtimes, which are not built by default. To build those apply > this patch: > > {{{ > diff --git a/mk/config.mk.in b/mk/config.mk.in > index 11050120d4..f083abad22 100644 > --- a/mk/config.mk.in > +++ b/mk/config.mk.in > @@ -297,6 +297,7 @@ GhcRTSWays=l > > # Usually want the debug version > GhcRTSWays += debug > +GhcRTSWays += thr_debug_p debug_p > > # We always have the threaded versions, but note that SMP support may be > disabled > # (see GhcWithSMP). > diff --git a/rts/ghc.mk b/rts/ghc.mk > index 532c9aa175..ff3f18f30c 100644 > --- a/rts/ghc.mk > +++ b/rts/ghc.mk > @@ -329,7 +329,6 @@ WARNING_OPTS += -Wstrict-prototypes > WARNING_OPTS += -Wmissing-prototypes > WARNING_OPTS += -Wmissing-declarations > WARNING_OPTS += -Winline > -WARNING_OPTS += -Waggregate-return > WARNING_OPTS += -Wpointer-arith > WARNING_OPTS += -Wmissing-noreturn > WARNING_OPTS += -Wnested-externs > }}} > > Examples: > > {{{ > prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce- > recomp -debug > [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) > [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) > [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) > [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) > [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) > [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) > [7 of 7] Compiling Main ( Mult.hs, Mult.o ) > Linking Mult ... > > prog001 git:(master) $ ./Mult +RTS -DS > Mult: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 210 > > (GHC version 8.7.20180809 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > zsh: abort (core dumped) ./Mult +RTS -DS > }}} > > (I tried to fix this in Phab:D5051 but it's causing a segfault in test > `T11108` when run with profiling. Not sure what the problem is yet.) > > Another way: > > {{{ > prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce- > recomp -threaded > [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) > [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) > [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) > [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) > [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) > [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) > [7 of 7] Compiling Main ( Mult.hs, Mult.o ) > Linking Mult ... > > prog001 git:(master) $ ./Mult +RTS -N2 > zsh: segmentation fault (core dumped) ./Mult +RTS -N2 > }}} > > Yet another way: > > {{{ > prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce- > recomp -threaded -debug > [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) > [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) > [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) > [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) > [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) > [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) > [7 of 7] Compiling Main ( Mult.hs, Mult.o ) > Linking Mult ... > > prog001 git:(master) $ ./Mult +RTS -N2 > Mult: internal error: invalid closure, info=0x947edc > (GHC version 8.7.20180809 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > zsh: abort (core dumped) ./Mult +RTS -N2 > }}} > > It seems to work fine when not compiled for profiling so marking this bug > as a profiler bug. New description: I'm observing a few different runtime errors. I'm not sure if they're because of different bugs so I'm filing one ticket for now. The reproduce with GHC HEAD: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: scavenge_one: strange object 624722688 (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2 prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: scavenge_stack: weird activation record found on stack: 0 (GHC version 8.7.20180821 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2 prog001 git:(master) $ ./Mult +RTS -N2 zsh: segmentation fault (core dumped) ./Mult +RTS -N2 }}} It's very easy to trigger other kind of panics in `concprog001`, just try different compile and runtime flag combinations. Note that for the examples below you'll need debug + profiling or debug + profiling + threaded runtimes, which are not built by default. To build those apply this patch: {{{ diff --git a/mk/config.mk.in b/mk/config.mk.in index 11050120d4..f083abad22 100644 --- a/mk/config.mk.in +++ b/mk/config.mk.in @@ -297,6 +297,7 @@ GhcRTSWays=l # Usually want the debug version GhcRTSWays += debug +GhcRTSWays += thr_debug_p debug_p # We always have the threaded versions, but note that SMP support may be disabled # (see GhcWithSMP). diff --git a/rts/ghc.mk b/rts/ghc.mk index 532c9aa175..ff3f18f30c 100644 --- a/rts/ghc.mk +++ b/rts/ghc.mk @@ -329,7 +329,6 @@ WARNING_OPTS += -Wstrict-prototypes WARNING_OPTS += -Wmissing-prototypes WARNING_OPTS += -Wmissing-declarations WARNING_OPTS += -Winline -WARNING_OPTS += -Waggregate-return WARNING_OPTS += -Wpointer-arith WARNING_OPTS += -Wmissing-noreturn WARNING_OPTS += -Wnested-externs }}} Examples: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -DS Mult: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 210 (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -DS }}} (I tried to fix this in Phab:D5051 but it's causing a segfault in test `T11108` when run with profiling. Not sure what the problem is yet.) Another way: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 zsh: segmentation fault (core dumped) ./Mult +RTS -N2 }}} Yet another way: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: invalid closure, info=0x947edc (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2 }}} It seems to work fine when not compiled for profiling so marking this bug as a profiler bug. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 07:08:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 07:08:32 -0000 Subject: [GHC] #13492: -p option report much less time than actual on high intensity of FFI calls application In-Reply-To: <045.f50d3dd52e457f79de74acb0151c7b37@haskell.org> References: <045.f50d3dd52e457f79de74acb0151c7b37@haskell.org> Message-ID: <060.4a2eb2967bc946c8b8967f850e4f163b@haskell.org> #13492: -p option report much less time than actual on high intensity of FFI calls application -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: simonmar, osa1 (added) * version: 8.0.2 => 8.5 Comment: I recently needed this and ended up using event logs as profiler did not help because of this issue. Unfortunately event logs also have its problems (e.g. can't load events for a few minutes because ghc-events requires more than 32G RAM for that...), so this feature would still be useful. See also the recent Haskell-cafe questions on this [https://mail.haskell.org/pipermail/haskell-cafe/2018-August/129818.html here] and my response [https://mail.haskell.org/pipermail/haskell- cafe/2018-August/129820.html here]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 07:41:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 07:41:25 -0000 Subject: [GHC] #14729: normaliseType is not well-kinded In-Reply-To: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> References: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> Message-ID: <062.3d61a826d7eb86f5f26e4a0dc3750445@haskell.org> #14729: normaliseType is not well-kinded -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15549 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It'd be great to fix this -- and document the invariant on `normaliseType`, namely that the result has the same kind as its argument. As I understand it, that's entirely consistent with our new (and now implemented in HEAD) story, that flattening does not change the kind of the type being flattened. Richard: are you up for doing this? I assume that the "my branch" part is now water under the bridge, because the new flattening stuff is done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 07:45:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 07:45:38 -0000 Subject: [GHC] #15552: Infinite loop/panic with an existential type. In-Reply-To: <050.eb5168d400b4a4211e35d29d96945d09@haskell.org> References: <050.eb5168d400b4a4211e35d29d96945d09@haskell.org> Message-ID: <065.36a15be6fa026bfcbb128c78e52244f7@haskell.org> #15552: Infinite loop/panic with an existential type. -------------------------------------+------------------------------------- Reporter: howtonotwin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: TypeInType, | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14723 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It's not #15473. Here's a slightly cut down version {{{ {-# LANGUAGE DataKinds, ExistentialQuantification, GADTs, PolyKinds, TypeOperators #-} {-# LANGUAGE TypeInType, TypeFamilies #-} module T15552 where import Data.Kind data Elem :: k -> [k] -> Type data EntryOfVal (v :: Type) (kvs :: [Type]) where EntryOfVal :: forall (v :: Type) (kvs :: [Type]) (k :: Type). Elem (k, v) kvs -> EntryOfVal v kvs type family EntryOfValKey (eov :: EntryOfVal v kvs) :: Type type family GetEntryOfVal (eov :: EntryOfVal v kvs) :: Elem (EntryOfValKey eov, v) kvs type family FirstEntryOfVal (v :: Type) (kvs :: [Type]) :: EntryOfVal v kvs where FirstEntryOfVal v (_ : kvs) = 'EntryOfVal (GetEntryOfVal (FirstEntryOfVal v kvs)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 08:13:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 08:13:25 -0000 Subject: [GHC] #15556: Inconsistent kind output for (->) Message-ID: <044.0a953cc57eae5a421ae06d0369692b61@haskell.org> #15556: Inconsistent kind output for (->) -------------------------------------+------------------------------------- Reporter: cvlad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The kind for (->) seems to be (uniquely?) verbose in ghc >= 8.2.2: {{{(->) :: TYPE q -> TYPE r -> *}}} Unlike all other things I was able to check. Is this intended? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 08:21:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 08:21:22 -0000 Subject: [GHC] #13492: -p option report much less time than actual on high intensity of FFI calls application In-Reply-To: <045.f50d3dd52e457f79de74acb0151c7b37@haskell.org> References: <045.f50d3dd52e457f79de74acb0151c7b37@haskell.org> Message-ID: <060.943c30d8073edddee84e6d4bcb654512@haskell.org> #13492: -p option report much less time than actual on high intensity of FFI calls application -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): I want this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 08:26:09 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 08:26:09 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.72a80c5f29250a94826e43bacd182682@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5321, #11598, | Differential Rev(s): Phab:D3752, #12506, #13386 | Phab:D4766 Wiki Page: | -------------------------------------+------------------------------------- Comment (by _recursion): Thanks for the update Ben. We're very much looking forward to it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 09:18:41 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 09:18:41 -0000 Subject: [GHC] #15508: concprog001 fails with various errors when compiled with -prof In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.e546b3dbc46559f754107a4b4596535f@haskell.org> #15508: concprog001 fails with various errors when compiled with -prof -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Profiling | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5051 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): So, as shown in the description this program crashes in many ways. I started debugging with one of those errors, and found out that at some point `cap->r.rCCCS` (a capability's "current cost centre" stack) actually points to a heap closure instead of a cost centre stack: {{{ >>> print cap->r.rCCCS $13 = (struct CostCentreStack_ *) 0x4200213000 >>> call printClosure(cap->r.rCCCS) integer-gmp:GHC.Integer.Type.S#((nil)#) }}} Then when this capability does allocation `accountAllocation` overwrites a info table pointer in this line {{{ CCS_ALLOC(cap->r.rCCCS,n); // Storage.c:802 }}} CCS_ALLOC defined as: {{{ #define CCS_ALLOC(ccs, size) (ccs)->mem_alloc += ((size)-sizeofW(StgProfHeader)) }}} mem_alloc is at this address: {{{ >>> print &cap->r.rCCCS->mem_alloc $15 = (StgWord64 *) 0x4200213048 }}} Which is also the info ptr of another closure: {{{ >>> print &((StgClosure*)0x4200213048)->header.info $20 = (const StgInfoTable **) 0x4200213048 }}} Originally this closure is; {{{ >>> call printClosure(0x4200213048) BLACKHOLE(0x42000dfa40) }}} So this assignment causes a memory corruption. Note that I'm using `+RTS -DS` during all this so any heap location that is not filled with 0 are actually in use. (collected space is filled with 0s with `-DS`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 09:35:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 09:35:08 -0000 Subject: [GHC] #15556: Inconsistent kind output for (->) In-Reply-To: <044.0a953cc57eae5a421ae06d0369692b61@haskell.org> References: <044.0a953cc57eae5a421ae06d0369692b61@haskell.org> Message-ID: <059.9fde2ab0786e245b70370c66270423ed@haskell.org> #15556: Inconsistent kind output for (->) -------------------------------------+------------------------------------- Reporter: cvlad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, that is its kind. See [https://www.microsoft.com/en- us/research/publication/levity-polymorphism/ Levity Polymorphism] (PLDI'17). Perhaps we should (somehow) suppress its levity-polymorphism, avoid avoid confusing people. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 10:29:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 10:29:48 -0000 Subject: [GHC] #11409: Cannot instantiate literals using TypeApplications In-Reply-To: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> References: <048.6352883c4ebf7b6ed5ee4d78320dfea2@haskell.org> Message-ID: <063.fb9baa0db7a0b4d1bfe0d1f77cc4335a@haskell.org> #11409: Cannot instantiate literals using TypeApplications -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11352 | Differential Rev(s): Phab:D4626 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * status: patch => new Comment: Replying to [comment:29 simonpj]: > Sandy Maguire (isovector) has authored > > * [https://github.com/ghc-proposals/ghc-proposals/pull/129 A GHC proposal] describing the proposed change > * [Phab:D4626] as a draft implementation patch > > Next steps: community feedback on the above proposal Quoting dfeuer's message from D4626: > The proposal was rejected by the committee, so this will not be merged. I'm therefore removing the resolution for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 10:31:49 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 10:31:49 -0000 Subject: [GHC] #14180: Strange/bad error message binding unboxed type variable In-Reply-To: <045.2cd418235dffeabd04a0de461895e7c1@haskell.org> References: <045.2cd418235dffeabd04a0de461895e7c1@haskell.org> Message-ID: <060.ef4f67e4ea80e955d3b0d80ef4eea8c5@haskell.org> #14180: Strange/bad error message binding unboxed type variable -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.2.3 Component: Compiler (Type | Version: 8.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > For some reason, GHC expects the type of all type variables to have kind Type It's here in `TcMType`: {{{ newMetaKindVar = do { uniq <- newUnique ; details <- newMetaDetails TauTv ; let kv = mkTcTyVar (mkKindName uniq) liftedTypeKind details ; traceTc "newMetaKindVar" (ppr kv) ; return (mkTyVarTy kv) } }}} When we see `forall a. blah`, we give `a` the kind `\kappa : *`. Richard may want to comment on why. It'd be good to add a Note to explain. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 10:35:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 10:35:37 -0000 Subject: [GHC] #15508: concprog001 fails with various errors when compiled with -prof In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.796cafeb31ed65800fa42384105681ab@haskell.org> #15508: concprog001 fails with various errors when compiled with -prof -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Profiling | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5051 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I wonder what would be a good sanity check for cost centre fields, e.g. a function `void checkCCS(CostCentreStack *ccs)` that can be used in `checkClosure` and to check `cap->r.rCCCS` maybe before every GC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 10:38:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 10:38:59 -0000 Subject: [GHC] #15552: Infinite loop/panic with an existential type. In-Reply-To: <050.eb5168d400b4a4211e35d29d96945d09@haskell.org> References: <050.eb5168d400b4a4211e35d29d96945d09@haskell.org> Message-ID: <065.d7bd0b010fe4306416fe0366224c731c@haskell.org> #15552: Infinite loop/panic with an existential type. -------------------------------------+------------------------------------- Reporter: howtonotwin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: TypeInType, | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14723 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It's not #15473. Something to do with zonking the type in `tcyFamInstEqn` {{{ tcTyFamInstEqn fam_tc mb_clsinfo (L loc (HsIB { hsib_ext = tv_names , hsib_body = FamEqn { feqn_tycon = L _ eqn_tc_name , feqn_pats = pats , feqn_rhs = hs_ty }})) = ASSERT( getName fam_tc == eqn_tc_name ) setSrcSpan loc $ tcFamTyPats fam_tc mb_clsinfo tv_names pats (kcTyFamEqnRhs mb_clsinfo hs_ty) $ \tvs pats res_kind -> do { traceTc "tcTyFamInstEqn {" (ppr eqn_tc_name <+> ppr pats) ; rhs_ty <- solveEqualities $ tcCheckLHsType hs_ty res_kind ; traceTc "tcTyFamInstEqn 1" (ppr eqn_tc_name <+> ppr pats) ; (ze, tvs') <- zonkTyBndrsX emptyZonkEnv tvs ; traceTc "tcTyFamInstEqn 2" (ppr eqn_tc_name <+> ppr pats) ; pats' <- zonkTcTypeToTypes ze pats ; traceTc "tcTyFamInstEqn 3" (ppr eqn_tc_name <+> ppr pats $$ ppr rhs_ty) ; rhs_ty' <- zonkTcTypeToType ze rhs_ty ; traceTc "tcTyFamInstEqn 4" (ppr fam_tc <+> pprTyVars tvs') ; return (mkCoAxBranch tvs' [] pats' rhs_ty' }}} We get to "3" but not to "4". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 10:52:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 10:52:18 -0000 Subject: [GHC] #11474: incorrect redundant-constraints warning In-Reply-To: <042.2e15408ecc3253cf7591957da36697cd@haskell.org> References: <042.2e15408ecc3253cf7591957da36697cd@haskell.org> Message-ID: <057.1cfa670e23a3f518a9337912451491cc@haskell.org> #11474: incorrect redundant-constraints warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | tests/typecheck/should_compile/T11474.hs Blocked By: | Blocking: Related Tickets: #10100 | Differential Rev(s): Phab:D4739 Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): AFAICT, the patch from D4739 looks ready, any objection to merging (for 8.8 I suppose) and calling this bug resolved? :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 10:53:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 10:53:33 -0000 Subject: [GHC] #15502: -ddump-splices truncates Integer literals to Int literals In-Reply-To: <047.99c2e69e35ad36d7625dca8406cf953c@haskell.org> References: <047.99c2e69e35ad36d7625dca8406cf953c@haskell.org> Message-ID: <062.7e067433831ee3526c18142306d22d5c@haskell.org> #15502: -ddump-splices truncates Integer literals to Int literals -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => high Comment: That indeed looks bad. I'm bumping up the priority because it surely can't be hard to find and fix. Is anyone up for that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 10:56:55 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 10:56:55 -0000 Subject: [GHC] #12674: GHC doesn't handle ./ prefixed paths correctly In-Reply-To: <047.897ae5e9c5c47ed13f84034ccb7c5729@haskell.org> References: <047.897ae5e9c5c47ed13f84034ccb7c5729@haskell.org> Message-ID: <062.48a4bdcf43bb9c84cfea6cb38e8ef3f0@haskell.org> #12674: GHC doesn't handle ./ prefixed paths correctly -------------------------------------+------------------------------------- Reporter: dobenour | Owner: RolandSenn Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Driver | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: T12674 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5009 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * status: patch => closed * resolution: => fixed Comment: D5009 has been merged, closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 11:25:39 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 11:25:39 -0000 Subject: [GHC] #11474: incorrect redundant-constraints warning In-Reply-To: <042.2e15408ecc3253cf7591957da36697cd@haskell.org> References: <042.2e15408ecc3253cf7591957da36697cd@haskell.org> Message-ID: <057.777f1ae0d49ed187271d619ef55154af@haskell.org> #11474: incorrect redundant-constraints warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | tests/typecheck/should_compile/T11474.hs Blocked By: | Blocking: Related Tickets: #10100 | Differential Rev(s): Phab:D4739 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > AFAICT, the patch from D4739 looks ready, any objection to merging (for 8.8 I suppose) and calling this bug resolved? :-) Good point. I think I see an easier way... stay tuned -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 11:47:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 11:47:01 -0000 Subject: [GHC] #13573: Add Foldable1 to base In-Reply-To: <051.5343934480dda921b1b6981f18b39763@haskell.org> References: <051.5343934480dda921b1b6981f18b39763@haskell.org> Message-ID: <066.806828ee24fcb985c6b28a32e88e30b0@haskell.org> #13573: Add Foldable1 to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10365 | Differential Rev(s): Phab:D4812 Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): Quoting dfeuer's message from D4812: > I believe this change needs a formal libraries list proposal. If that is indeed the case, is anyone interested in taking this to the libraries@ list? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 12:38:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 12:38:56 -0000 Subject: [GHC] #15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite In-Reply-To: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> References: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> Message-ID: <061.8e52ac167aeeeed47345b301cfb75ee6@haskell.org> #15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The fact that this happened on MIPS earlier is a very interesting data point. I'm not yet sure what to make of it; perhaps it's a missing memory barrier? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 12:40:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 12:40:44 -0000 Subject: [GHC] #14973: Location in GHCi debugger prompt printed twice when default prompt is used In-Reply-To: <043.77b079247cf81e1c9a49efb3c90c1743@haskell.org> References: <043.77b079247cf81e1c9a49efb3c90c1743@haskell.org> Message-ID: <058.f50082c37b3952ed29b6b9cc6da3f1a5@haskell.org> #14973: Location in GHCi debugger prompt printed twice when default prompt is used -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.5 Resolution: | Keywords: debugger Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4661 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 12:42:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 12:42:40 -0000 Subject: [GHC] #15556: Inconsistent kind output for (->) In-Reply-To: <044.0a953cc57eae5a421ae06d0369692b61@haskell.org> References: <044.0a953cc57eae5a421ae06d0369692b61@haskell.org> Message-ID: <059.4bfe142cf1273e1758cc453ec7d3252d@haskell.org> #15556: Inconsistent kind output for (->) -------------------------------------+------------------------------------- Reporter: cvlad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmmm, I'm a tad surprised this isn't caught by the runtime rep defaulting code (disabled by `-fprint-explicit-runtime-reps`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 12:54:21 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 12:54:21 -0000 Subject: [GHC] #15081: Finite list becomes infinite after maping fractional function for high numbers In-Reply-To: <044.f762bf620383822c5337aa8807210278@haskell.org> References: <044.f762bf620383822c5337aa8807210278@haskell.org> Message-ID: <059.c42f4b4cae47ef2dd856ad58750d0f4c@haskell.org> #15081: Finite list becomes infinite after maping fractional function for high numbers -------------------------------------+------------------------------------- Reporter: Onsed | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | libraries/base/tests/enumNumeric Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4650 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * status: patch => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 13:00:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 13:00:28 -0000 Subject: [GHC] #15081: Finite list becomes infinite after maping fractional function for high numbers In-Reply-To: <044.f762bf620383822c5337aa8807210278@haskell.org> References: <044.f762bf620383822c5337aa8807210278@haskell.org> Message-ID: <059.a5c86c4ae675a2ee6da65bcb06cc1df2@haskell.org> #15081: Finite list becomes infinite after maping fractional function for high numbers -------------------------------------+------------------------------------- Reporter: Onsed | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | libraries/base/tests/enumNumeric Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4650 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I know that this is probably going to be an unpopular point-of-view but I would argue that we should consider just dropping the `Enum` instance on floating point types. As was stated earlier, enumerating floating point numbers is inherently fragile. I'm sure removing the instance would break a non-trivial amount of code, but arguably that code is broken anyways. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 13:13:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 13:13:33 -0000 Subject: [GHC] #15556: Inconsistent kind output for (->) In-Reply-To: <044.0a953cc57eae5a421ae06d0369692b61@haskell.org> References: <044.0a953cc57eae5a421ae06d0369692b61@haskell.org> Message-ID: <059.c62eb887b2a616d10be87f7ed4074e73@haskell.org> #15556: Inconsistent kind output for (->) -------------------------------------+------------------------------------- Reporter: cvlad | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It //is// caught by runtime rep defaulting, as a matter of fact, after commit 40db277f1dedd4df7e75cc0eb35aa7e1e1ded02a: {{{ $ /opt/ghc/8.6.1/bin/ghci GHCi, version 8.6.0.20180810: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci λ> :k (->) (->) :: * -> * -> * λ> :set -fprint-explicit-runtime-reps λ> :k (->) (->) :: TYPE q -> TYPE r -> * }}} So I claim this bug is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 13:21:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 13:21:56 -0000 Subject: [GHC] #13492: -p option report much less time than actual on high intensity of FFI calls application In-Reply-To: <045.f50d3dd52e457f79de74acb0151c7b37@haskell.org> References: <045.f50d3dd52e457f79de74acb0151c7b37@haskell.org> Message-ID: <060.d65f6fc04530fe66274238b78ea051ab@haskell.org> #13492: -p option report much less time than actual on high intensity of FFI calls application -------------------------------------+------------------------------------- Reporter: varosi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.5 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Debugging | (amd64) information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I agree that our eventlog tooling has significant weaknesses. Using O(n) memory in a trace analysis tool is quite problematic. Ultimately I would actually like to see the eventlog supercede our ad-hoc `hp` (and perhaps some day `prof`) format for profiling but these issues will first need to be resolved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 13:39:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 13:39:27 -0000 Subject: [GHC] #15201: GHC 8.4 fails to build on Debian s390x In-Reply-To: <044.625246c98fa687e3f833d1f81c733f4b@haskell.org> References: <044.625246c98fa687e3f833d1f81c733f4b@haskell.org> Message-ID: <059.5ccaf941c88a6df783d4862855023c86@haskell.org> #15201: GHC 8.4 fails to build on Debian s390x -------------------------------------+------------------------------ Reporter: clint | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Other Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Changes (by alpmestan): * status: patch => new Comment: Since I don't see a phab revision attached anywhere in the ticket, I suspect the status change was accidental, Ben? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 13:48:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 13:48:44 -0000 Subject: [GHC] #15526: Explain or remove mystery import in Unsafe.Coerce In-Reply-To: <045.8c1bd79d636e4b29cdc257cdfcb27b40@haskell.org> References: <045.8c1bd79d636e4b29cdc257cdfcb27b40@haskell.org> Message-ID: <060.b3524a4dd63e4df429c7cd0490ed756c@haskell.org> #15526: Explain or remove mystery import in Unsafe.Coerce -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): There are a handful of other places that have similarly vague comments (without references to Notes), such as `GHC.Maybe`, `GHC.Stack.Types`, and `GHC.Err`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 13:56:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 13:56:03 -0000 Subject: [GHC] #15526: Explain or remove mystery import in Unsafe.Coerce In-Reply-To: <045.8c1bd79d636e4b29cdc257cdfcb27b40@haskell.org> References: <045.8c1bd79d636e4b29cdc257cdfcb27b40@haskell.org> Message-ID: <060.cb6bddec48700fe94efb82c8a3d42ac5@haskell.org> #15526: Explain or remove mystery import in Unsafe.Coerce -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 13:57:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 13:57:40 -0000 Subject: [GHC] #15540: GHCi does not follow the XDG Base Directory Specification In-Reply-To: <047.104e0b09441c5fa58dd1aeb68ec6fc11@haskell.org> References: <047.104e0b09441c5fa58dd1aeb68ec6fc11@haskell.org> Message-ID: <062.688a7dc6bf2d4ea820aedeeb3c6d7432@haskell.org> #15540: GHCi does not follow the XDG Base Directory Specification -------------------------------------+------------------------------------- Reporter: rszibele | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.0.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #6077 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gueux): * cc: gueux (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 15:08:41 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 15:08:41 -0000 Subject: [GHC] #15557: Reduce type families in equations' RHS when testing equation compatibility Message-ID: <044.c8824ce95594133c7a3e270ae939b58d@haskell.org> #15557: Reduce type families in equations' RHS when testing equation compatibility -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Type checker) | Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #8423 #15546 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The reference I found for closed type families with compatible equations is: https://www.microsoft.com/en-us/research/wp- content/uploads/2016/07/popl137-eisenberg.pdf There in Definition 8 in section 3.4 it states: Definition 8 (Compatibility implementation). The test for compatibility, written compat(p, q), checks that unify(lhsp, lhsq) = Ω implies Ω(rhsp) = Ω(rhsq). If unify(lhsp, lhsq) fails, compat(p, q) holds vacuously. Examine the following families: {{{#!hs type family If (a :: Bool) (b :: k) (c :: k) :: k where If False a b = b If True a b = a type family Eql (a :: k) (b :: k) :: Bool where Eql a a = True Eql _ _ = False type family Test (a :: Maybe k) (b :: Maybe k) :: Maybe k where Test (Just x) (Just y) = If (Eql x y) (Just x) Nothing Test a a = a Test Nothing _ = Nothing Test _ Nothing = Nothing }}} Applying the check to the equations 1 and 2 of `Test` we get: unify(<`Just x`, `Just y`>, <`a`, `a`>) = Ω = [`a` -> `Just x`, `y` -> `x`] Ω(`a`) = `Just x` = `If (Eql x x) (Just x) Nothing` = Ω(`If (Eql x y) (Just x) Nothing`) Therefore the equations must be compatible, and when tidying `forall a. p a -> p (Test a a)` the application should reduce to `forall a. p a -> p a` That doesn't happen: {{{#!hs > :t undefined :: p a -> p (Test a a) p a -> p (Test a a) }}} Examining the IfaceAxBranches (cf #15546) we see: {{{#!hs axiom D:R:Test:: Test a ('Just x) ('Just y) = If (Eql x y) ('Just x) 'Nothing Test k a a = a (incompatible indices: [0]) Test k 'Nothing _ = 'Nothing Test k _ 'Nothing = 'Nothing }}} GHC did not consider the two equations compatible. Digging into why, I came across this ticket: #8423, in which a potentially unbounded (and indefinite) number of type family reductions was necessary to evidence Ω(rhsp) = Ω(rhsq). I don't claim to fully understand goldfire's ticket:8423#comment:10, but the issue is clear: reducing type families while doing a compartibility check might depend on other compatibility checks already being done, including a check depending on itself in which case we are interested in the biggest fixed point (why?). The family here doesn't require any of that special consideration because `Eql x x` reduces right away without any compatibility checks, and `If` is essentially open (indeed making `If` open doesn't help anything). This brings the question: is something like goldfire's described algorithm (or a simplification thereof) something we would like to have in GHC or is that too complex? What is the status on the implementation of that algorithm? P.S: An interesting workaround is adding an `If t c c = c` equation (compatible), and then writing `Test` as: {{{#!hs type family Test (a :: Maybe k) (b :: Maybe k) :: Maybe k where Test (Just x) (Just y) = If (Eql (Just x) (Just y)) (Just x) Nothing Test a a = If (Eql a a) a Nothing Test Nothing a = If (Eql Nothing a) Nothing Nothing Test a Nothing = If (Eql a Nothing) Nothing Nothing }}} This lets GHC discover the necessary equalities without reducing type families, yet erase the workaround'ed type family applications immediately. P.P.S: In ticket:15546#comment:4 I mixed up left and right, it's the RHS that should be/are not reduced. This probably confused SPJ a lot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 15:10:49 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 15:10:49 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation In-Reply-To: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> References: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> Message-ID: <061.e6c10701af80c64163ce0dac0a5adc6b@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by danilo2): @simonpj I'll try to prepare you some version without criterion this weekend (sorry for that, I'm working almost literally 24h/day now). Thank you for looking into this issue! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 15:21:46 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 15:21:46 -0000 Subject: [GHC] #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation In-Reply-To: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> References: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> Message-ID: <061.122d4f09ad0b7ba08a32a1c621e87154@haskell.org> #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation -------------------------------------+------------------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Research Component: Compiler (Type | needed checker) | Version: 8.4.3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5087 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5087 Comment: Implementing a naïve `NonVoid(ty)` solver ends up being pretty darn simple: just check if there is at least one inhabitation candidate for `ty` (as determined through `inhabitationCandidates`) such that its term and type constraints are satisfiable. That's sufficient to avoid warnings in the original program and in the program in comment:4. See Phab:D5087. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 15:37:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 15:37:45 -0000 Subject: [GHC] #11474: incorrect redundant-constraints warning In-Reply-To: <042.2e15408ecc3253cf7591957da36697cd@haskell.org> References: <042.2e15408ecc3253cf7591957da36697cd@haskell.org> Message-ID: <057.ea97a677a9b4b39b3cf326e3d0c10e39@haskell.org> #11474: incorrect redundant-constraints warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | tests/typecheck/should_compile/T11474.hs Blocked By: | Blocking: Related Tickets: #10100 | Differential Rev(s): Phab:D4739 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 15:38:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 15:38:48 -0000 Subject: [GHC] #14729: normaliseType is not well-kinded In-Reply-To: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> References: <047.efda82c1cfd056232e208bfdc783f3d1@haskell.org> Message-ID: <062.9c4171541f82d7a3c6d59f6a876c9d37@haskell.org> #14729: normaliseType is not well-kinded -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15549 | 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 Wed Aug 22 15:39:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 15:39:13 -0000 Subject: [GHC] #15549: Core Lint error with EmptyCase In-Reply-To: <050.9a179952570cbedc58a57ced12c92bb9@haskell.org> References: <050.9a179952570cbedc58a57ced12c92bb9@haskell.org> Message-ID: <065.61103c99226d1ef6e4b55b9fdd6854bd@haskell.org> #15549: Core Lint error with EmptyCase -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: TypeFamilies, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14729 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: 8.6.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 15:45:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 15:45:14 -0000 Subject: [GHC] #14813: EmptyCase thinks pattern match involving type family is not exhaustive, when it actually is In-Reply-To: <050.3962023f385f083f5f659edfe4ce01db@haskell.org> References: <050.3962023f385f083f5f659edfe4ce01db@haskell.org> Message-ID: <065.58648276083d6b8f4354dbd1ab2baf0a@haskell.org> #14813: EmptyCase thinks pattern match involving type family is not exhaustive, when it actually is -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: => 8.8.1 Comment: Thanks, Simon! I'm afraid I'm not familiar enough with the solver interface in order to implement all of `tcNormalise` on my own, so I'm going to ask for more advice here. In particular: * `solveSimpleGivens` takes `[Ct]` as an arguments. How do I turn a `CHoleCan` into a `Ct`? * Moreover, how exactly do I build a `CHoleCan`? It takes a `CtEvidence` and a `Hole` as arguments. I have no idea what the `Hole` should be. Presumably, the `CtEvidence` should be a `CtWanted`, but that takes three other arguments in addition to `ctev_pred`, and I have no idea what any of them should be. * Also, where exactly should I be calling `tcNormalise`? In the pattern- match coverage checker? Somewhere else? (I wonder if it's possible to fix the buglet in the first program in comment:2 as well, which would seem to suggest we should be calling it somewhere //besides// the coverage checker.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 15:47:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 15:47:44 -0000 Subject: [GHC] #14111: strange error when using data families with levity polymorphism and unboxed sums and data families In-Reply-To: <045.61bc63eee0a790503467c9479892f97e@haskell.org> References: <045.61bc63eee0a790503467c9479892f97e@haskell.org> Message-ID: <060.0020687b0136498e2ab7e3208652364f@haskell.org> #14111: strange error when using data families with levity polymorphism and unboxed sums and data families -------------------------------------+------------------------------------- Reporter: carter | Owner: RyanGlScott Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 13737 | Blocking: Related Tickets: #14457 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * owner: (none) => RyanGlScott * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 15:48:11 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 15:48:11 -0000 Subject: [GHC] #15213: 32 bit Haddock runs out of memory compiling 32 bit GHC In-Reply-To: <044.953b3633442fb5d6beadb7e79e6f44ca@haskell.org> References: <044.953b3633442fb5d6beadb7e79e6f44ca@haskell.org> Message-ID: <059.8df8de775570054f6c1df51b5f400e9a@haskell.org> #15213: 32 bit Haddock runs out of memory compiling 32 bit GHC ----------------------------------------+---------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5003 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by alpmestan): * status: patch => merge Comment: The diff has been merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 16:14:21 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 16:14:21 -0000 Subject: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections In-Reply-To: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> References: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> Message-ID: <060.19cefd6fe3207bc90b35df013be2b49e@haskell.org> #7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.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 dfeuer): I've had more thoughts/details on garbage collection in the no-stable- name-table option. I don't think we actually need to store an underlying object pointer in an SNO at all. After running the collector (before compacting), traverse the keys and SNOs in the SN hash table to form the new one. If the key is dead, do nothing. If the SNO is dead, do nothing. If both have been evacuated, insert the new key and new SNO into the hash table for the next generation. The main remaining problem looks unfortunate, and has to do with `hashStableName#`. While that has never been documented as being injective, it actually ''is'' injective under certain circumstances, and indeed it appears that real code on Hackage relies on this (see, e.g., [http://hackage.haskell.org/package/stable-maps-0.0.5/docs/System-Mem- StableName-Map.html stable-maps]). In particular, the way it works now, we can implement a stable name map as `IntMap (StableName k, v)`. Because the map keeps the `StableName`s alive, their stable name table indices won't be reused. The only way to keep such code working is to make such a guarantee. That ''requires'' a way to allocate IDs uniquely. So we need a data structure that can keep track of which IDs are available and allocate them. Ugh. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 16:14:57 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 16:14:57 -0000 Subject: [GHC] #15053: Compiler panic on invalid syntax (unterminated pragma) In-Reply-To: <047.d617a7e8bd5e9dac7c56bae30af4b445@haskell.org> References: <047.d617a7e8bd5e9dac7c56bae30af4b445@haskell.org> Message-ID: <062.2ee352856004a5f947f4d7738f650b9b@haskell.org> #15053: Compiler panic on invalid syntax (unterminated pragma) -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: RolandSenn Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4883 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: (none) => RolandSenn Comment: I'll work on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 16:20:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 16:20:20 -0000 Subject: [GHC] #15551: TH-reified type classes have redundant tyvars/class constraints on each method In-Reply-To: <050.f558426d191105778fc98c9fddcec266@haskell.org> References: <050.f558426d191105778fc98c9fddcec266@haskell.org> Message-ID: <065.26a07903c9d7c196a9ac884c92ef5868@haskell.org> #15551: TH-reified type classes have redundant tyvars/class constraints on each method -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5088 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5088 Comment: I decided to be bold and just fix this. See Phab:D5088. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 16:33:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 16:33:27 -0000 Subject: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections In-Reply-To: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> References: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> Message-ID: <060.0c85a8590076c657715acfd9e8d5c7ee@haskell.org> #7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.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 dfeuer): Let me take that back... What I thought I saw in the wild wasn't what I saw. Maybe nobody is taking advantage of that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 17:32:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 17:32:44 -0000 Subject: [GHC] #15534: Allow associated types in Minimal pragmas In-Reply-To: <045.6db89ec9707d75439c8a339ed44a058a@haskell.org> References: <045.6db89ec9707d75439c8a339ed44a058a@haskell.org> Message-ID: <060.9a667d5feb9e80664b308ff27da36ce0@haskell.org> #15534: Allow associated types in Minimal pragmas -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Before we can entertain the thought of extending `MINIMAL` pragmas to encompass associated type families, we might want to rethink how we report warnings for missing things in classes. Consider this example: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Bug where class C a where type T1 a type T2 a m1 :: a m2 :: a instance C Int }}} Then the warnings we get are rather fragmented: {{{ $ /opt/ghc/8.4.3/bin/ghci Bug.hs GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:10:1: warning: [-Wmissing-methods] • No explicit associated type or default declaration for ‘T1’ • In the instance declaration for ‘C Int’ | 10 | instance C Int | ^^^^^^^^^^^^^^ Bug.hs:10:1: warning: [-Wmissing-methods] • No explicit associated type or default declaration for ‘T2’ • In the instance declaration for ‘C Int’ | 10 | instance C Int | ^^^^^^^^^^^^^^ Bug.hs:10:10: warning: [-Wmissing-methods] • No explicit implementation for ‘m1’ and ‘m2’ • In the instance declaration for ‘C Int’ | 10 | instance C Int | ^^^^^ }}} Unfortunately, the warnings for missing implementations for associated types are completely separate from those for missing implementations for methods. This is not an ideal state of affairs, because if we attached the following `MINIMAL` pragma to `C`: {{{#!hs {-# MINIMAL (T1 | m1) | (T2 | m2) #-} }}} Then presumably, we'd want a single warning to the effect of: {{{ • No explicit implementation for either ‘T1’ or ‘m1’, or ‘T2’ or ‘m2’ • In the instance declaration for ‘C Int’ }}} Achieving this in today's GHC is challenging, since the code for reporting warnings for missing associated types lives in `tcATDefault`, whereas the code for reporting warnings for missing methods lives in `tcMethods`. Perhaps step one is to consolidate these into the same function. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 18:01:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 18:01:43 -0000 Subject: [GHC] #15502: -ddump-splices truncates Integer literals to Int literals In-Reply-To: <047.99c2e69e35ad36d7625dca8406cf953c@haskell.org> References: <047.99c2e69e35ad36d7625dca8406cf953c@haskell.org> Message-ID: <062.46261e9df61ef8a7071fe896d5ebb936@haskell.org> #15502: -ddump-splices truncates Integer literals to Int literals -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5089 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5089 Comment: Phab:D5089 ought to do it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 18:15:11 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 18:15:11 -0000 Subject: [GHC] #15550: Names of RULES aren't quoted in -ddump-splices In-Reply-To: <050.b5daffb0170f6fb061ff2380766e1195@haskell.org> References: <050.b5daffb0170f6fb061ff2380766e1195@haskell.org> Message-ID: <065.b0c62bf7f6dbbfca55c295c5882acaa4@haskell.org> #15550: Names of RULES aren't quoted in -ddump-splices -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5090 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5090 Comment: I decided to just go with the `quotedSourceText` option for now in Phab:D5090. We can always revisit the `SourceText`-in-`Convert` question later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 18:32:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 18:32:38 -0000 Subject: [GHC] #15550: Names of RULES aren't quoted in -ddump-splices In-Reply-To: <050.b5daffb0170f6fb061ff2380766e1195@haskell.org> References: <050.b5daffb0170f6fb061ff2380766e1195@haskell.org> Message-ID: <065.1cc595ba52e801f6734ff68e1f3ef9c2@haskell.org> #15550: Names of RULES aren't quoted in -ddump-splices -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5090 Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): @RyanGlScott, I have been snowed,sorry. I think `NoSourceText` is probably the better option here, to be honest. But in the bigger scheme of things probably does not matter all that much. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 19:19:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 19:19:07 -0000 Subject: [GHC] #15492: Plugin recompilation check fails when profiling is enabled In-Reply-To: <049.6cd45f735e6cc5104c701afb7f68bb71@haskell.org> References: <049.6cd45f735e6cc5104c701afb7f68bb71@haskell.org> Message-ID: <064.1cd4565f4cb1979f054c1cad4b00f05c@haskell.org> #15492: Plugin recompilation check fails when profiling is enabled -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5048 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 13105a1ae870da6936a27cdd1d6a4bd25a661368. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 19:45:31 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 19:45:31 -0000 Subject: [GHC] #15201: GHC 8.4 fails to build on Debian s390x In-Reply-To: <044.625246c98fa687e3f833d1f81c733f4b@haskell.org> References: <044.625246c98fa687e3f833d1f81c733f4b@haskell.org> Message-ID: <059.18b3958130ce4f6980351ebcf1f2640d@haskell.org> #15201: GHC 8.4 fails to build on Debian s390x -------------------------------------+------------------------------ Reporter: clint | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Other Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Comment (by bgamari): Sounds like it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 19:45:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 19:45:50 -0000 Subject: [GHC] #15556: Inconsistent kind output for (->) In-Reply-To: <044.0a953cc57eae5a421ae06d0369692b61@haskell.org> References: <044.0a953cc57eae5a421ae06d0369692b61@haskell.org> Message-ID: <059.9292fbd57209fc7dde04407211a613bf@haskell.org> #15556: Inconsistent kind output for (->) -------------------------------------+------------------------------------- Reporter: cvlad | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Lovely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 19:55:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 19:55:01 -0000 Subject: [GHC] #15534: Allow associated types in Minimal pragmas In-Reply-To: <045.6db89ec9707d75439c8a339ed44a058a@haskell.org> References: <045.6db89ec9707d75439c8a339ed44a058a@haskell.org> Message-ID: <060.21ee75a4654c04e2dc4483aeab5cbed9@haskell.org> #15534: Allow associated types in Minimal pragmas -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Achieving this in today's GHC is challenging, since the code for reporting warnings for missing associated types lives in tcATDefault, whereas the code for reporting warnings for missing methods lives in tcMethods. I rather think that both should be done in `checkValidClass`. Which would make it much easier to do what you want here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 19:56:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 19:56:32 -0000 Subject: [GHC] #15548: Make TABLES_NEXT_TO_CODE a dynflag In-Reply-To: <046.9535ff5b262ce3a827e22266f139da22@haskell.org> References: <046.9535ff5b262ce3a827e22266f139da22@haskell.org> Message-ID: <061.9d73479ed02246a73fb2a08d30385682@haskell.org> #15548: Make TABLES_NEXT_TO_CODE a dynflag -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5082 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): There is one curious spot left, in `SysTools` {{{ tntc_gcc_args | mkTablesNextToCode targetUnregisterised = ["-DTABLES_NEXT_TO_CODE"] | otherwise = [] cpp_args= map Option (words cpp_args_str) gcc_args = map Option (words gcc_args_str ++ unreg_gcc_args ++ tntc_gcc_args) }}} This sets the default C arguments based on the initial settings (not the dynflags). I am wondering if anything actually relies on GHC setting the flag here, especially since `/usr/lib/ghc/include/ghcautoconf.h`, included by various header files, _also_ sets `TABLES_NEXT_TO_CODE`. I guess I should just try it out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 20:45:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 20:45:25 -0000 Subject: [GHC] #15543: Binary crashes under dtrace In-Reply-To: <045.599ac00709c714a8189c60aa1b140c4c@haskell.org> References: <045.599ac00709c714a8189c60aa1b140c4c@haskell.org> Message-ID: <060.5a03c3d0b3ee660041e0908da3870111@haskell.org> #15543: Binary crashes under dtrace ----------------------------------+---------------------------------------- Reporter: last_g | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: dtrace, crash Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------------- Comment (by last_g): Similar happens with System Tap but I don't know is it related or not. {{{ [lastg at devvm2623.lla2 ~/scratches/ghc_tests] sudo stap pc.stp -c '~/scratches/ghc_tests/test_cases/FibbSlow.8-4-3.O3 10' WARNING: function _start return probe is blacklisted: keyword at pc.stp:24:1 source: probe process.function("*").return { trace(-1, $$return) } ^ WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.8-4-3.O3").function("hs_atomic_add32").return inode-offset 0000000000098b90 registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.8-4-3.O3").function("m32_free_internal at rts/linker/M32Alloc.c:176").return inode-offset 00000000000bd6b0 registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.8-4-3.O3").function("hs_atomic_add32") inode-offset 0000000000098b90 registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.8-4-3.O3").function("atoi@/usr/include/stdlib.h:278") inode-offset 0000000000000808 registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.8-4-3.O3").function("atoi@/usr/include/stdlib.h:278") inode-offset 0000000000000238 registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.8-4-3.O3").function("m32_free_internal at rts/linker/M32Alloc.c:176") inode-offset 00000000000bd6b0 registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.8-4-3.O3").function("get_itbl at includes/rts/storage/ClosureMacros.h:84") inode-offset 0000000000000131 registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.8-4-3.O3").function("Bdescr at includes/rts/storage/Block.h:172") inode-offset 0000000000000018 registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.8-4-3.O3").function("bco_sizeW at includes/rts/storage/ClosureMacros.h:354") inode-offset 0000000000000040 registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.8-4-3.O3").function("XXH32_round at rts/xxhash.c:255") inode-offset 0000000000000250 registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.8-4-3.O3").function("XXH32_round at rts/xxhash.c:255") inode-offset 00000000000000da registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.8-4-3.O3").function("XXH_readLE64_align at rts/xxhash.c:580") inode-offset 00000000000001cc registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.8-4-3.O3").function("loadObj_ at rts/Linker.c:1446") inode-offset 0000000000000012 registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.8-4-3.O3").function("preloadObjectFile at rts/Linker.c:1319") inode-offset 0000000000000040 registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.8-4-3.O3").function("ghciRemoveSymbolTable at rts/Linker.c:227") inode-offset 0000000000000040 registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.8-4-3.O3").function("stat@/usr/include/x86_64 -linux-gnu/sys/stat.h:453") inode-offset 0000000000000040 registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.8-4-3.O3").function("appendToRunQueue at rts/Schedule.h:130") inode-offset 00000000000000d2 registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.8-4-3.O3").function("unlockClosure at rts/SMPClosureOps.h:108") inode-offset 0000000000000110 registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.8-4-3.O3").function("lockClosure at rts/SMPClosureOps.h:99") inode-offset 0000000000000018 registration error (rc -524) WARNING: Child process exited with signal 11 (Segmentation fault) WARNING: /usr/bin/staprun exited with status: 1 Pass 5: run failed. [man error::pass5] }}} and on `master` {{{ [lastg at devvm2623.lla2 ~/scratches/ghc_tests] sudo stap pc.stp -c '~/scratches/ghc_tests/test_cases/FibbSlow.master.O3 10' WARNING: function _start return probe is blacklisted: keyword at pc.stp:24:1 source: probe process.function("*").return { trace(-1, $$return) } ^ WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.master.O3").function("hs_atomic_add32").return inode-offset 00000000000805c0 registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.master.O3").function("m32_free_internal at rts/linker/M32Alloc.c:176").return inode-offset 000000000008f500 registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.master.O3").function("hs_atomic_add32") inode-offset 00000000000805c0 registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.master.O3").function("get_itbl at includes/rts/storage/ClosureMacros.h:84") inode-offset 0000000000000131 registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.master.O3").function("Bdescr at includes/rts/storage/Block.h:170") inode-offset 00000000000001b0 registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.master.O3").function("Bdescr at includes/rts/storage/Block.h:170") inode-offset 0000000000000191 registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.master.O3").function("XXH32_round at rts/xxhash.c:255") inode-offset 0000000000000251 registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.master.O3").function("thunk_sizeW_fromITBL at includes/rts/storage/ClosureMacros.h:313") inode-offset 0000000000000040 registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.master.O3").function("m32_free_internal at rts/linker/M32Alloc.c:176") inode-offset 000000000008f500 registration error (rc -524) WARNING: probe process("/home/lastg/scratches/ghc_tests/test_cases/FibbSlow.master.O3").function("ghciRemoveSymbolTable at rts/Linker.c:228") inode-offset 0000000000000040 registration error (rc -524) WARNING: Child process exited with signal 11 (Segmentation fault) WARNING: /usr/bin/staprun exited with status: 1 Pass 5: run failed. [man error::pass5] }}} In the same time, it gets the same warnings but works when attached to a running process with {{{ sudo stap pc.stp -x `pgrep Fib` }}}. I suppose there's something with process/RTS initialization. I also tested different compiler versions: it crashes on 8.2, 8.4 and master and works well on 8.0. {{{ pc.stp: }}} {{{ #! /usr/bin/env stap function trace(entry_p, extra) { %( $# > 1 %? if (tid() in trace) %) printf("%s%s%s %s\n", thread_indent (entry_p), (entry_p>0?"->":"<-"), ppfunc (), extra) } probe process.function("*") { trace(1, $$parms) } probe process.function("*").return { trace(-1, $$return) } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 20:53:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 20:53:13 -0000 Subject: [GHC] #14813: EmptyCase thinks pattern match involving type family is not exhaustive, when it actually is In-Reply-To: <050.3962023f385f083f5f659edfe4ce01db@haskell.org> References: <050.3962023f385f083f5f659edfe4ce01db@haskell.org> Message-ID: <065.e1a01cd346c64725c750ccd4f8e72ba2@haskell.org> #14813: EmptyCase thinks pattern match involving type family is not exhaustive, when it actually is -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): * A `CHoleCan` ''is'' a `Ct`! (`CHoleCan` is a data constructor of `Ct`.) * How exactly do I build a CHoleCan? Currently they are born in one place, in `TcExpr.tcUnboundId`: {{{ tcUnboundId rn_expr unbound res_ty = do { ty <- newOpenFlexiTyVarTy -- Allow Int# etc (Trac #12531) ; let occ = unboundVarOcc unbound ; name <- newSysName occ ; let ev = mkLocalId name ty ; loc <- getCtLocM HoleOrigin Nothing ; let can = CHoleCan { cc_ev = CtWanted { ctev_pred = ty , ctev_dest = EvVarDest ev , ctev_nosh = WDeriv , ctev_loc = loc} , cc_hole = ExprHole unbound } ... }}} Perhaps you can copy that? * Also, where exactly should I be calling tcNormalise? Call it in `pmTopNormaliseType`. (It might need to become monadic to access the ambient constraints. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 21:58:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 21:58:38 -0000 Subject: [GHC] #15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite In-Reply-To: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> References: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> Message-ID: <061.8eeff9a3a7c9882d1a4c8de0895cb61e@haskell.org> #15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): So I finally had a chance to reproduce this with a compiler built with debugging symbols. Interestingly, the first segfault I've seen crashed in this environment was in the SHA implementation itself: {{{ Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 16174.16189] 0x000000000062aaae in sha256_do_chunk () >>> disassemble Dump of assembler code for function sha256_do_chunk: 0x000000000062a5d0 <+0>: push %r15 0x000000000062a5d2 <+2>: push %r14 0x000000000062a5d4 <+4>: push %r13 0x000000000062a5d6 <+6>: push %r12 0x000000000062a5d8 <+8>: push %rbp 0x000000000062a5d9 <+9>: push %rbx 0x000000000062a5da <+10>: sub $0x158,%rsp 0x000000000062a5e1 <+17>: mov %fs:0x28,%rax ... 0x000000000062aaa7 <+1239>: pop %r13 0x000000000062aaa9 <+1241>: pop %r14 0x000000000062aaab <+1243>: pop %r15 0x000000000062aaad <+1245>: retq => 0x000000000062aaae <+1246>: movdqu (%rsi),%xmm0 0x000000000062aab2 <+1250>: lea 0x40(%r11),%rcx 0x000000000062aab6 <+1254>: mov %r11,%rax 0x000000000062aab9 <+1257>: movaps %xmm0,0x40(%rsp) ... >>> bt #0 0x000000000062aaae in sha256_do_chunk () #1 0x000000000062c05f in ghczuwrapperZC4ZCcryptohashzmsha256zm0zi11zi101zi0zminplaceZCCryptoziHashziSHA256ziFFIZChszucryptohashzusha256zuupdate () #2 0x00000000006278a5 in s7zn_info () #3 0x0000000000000000 in ?? () }}} At first I suspected this was an alignment issue but no, `movdqu` is an unaligned move. The value of `$rsi` is quite suspicious: {{{ >>> print /a $rsi $1 = 0x510000004200b85a }}} In fact, it seems that the crash occurs essentially as soon as we enter `sha256_do_chunk`. Tracing execution back into Haskell it looks like this crazy pointer comes from the C stack: {{{ Dump of assembler code for function s7zn_info: ... 0x0000000000627864 <+596>: xor %esi,%esi 0x0000000000627866 <+598>: mov %rax,%r8 0x0000000000627869 <+601>: xor %eax,%eax 0x000000000062786b <+603>: mov %r8,%r14 0x000000000062786e <+606>: mov %rdx,0x48(%rsp) (B) 0x0000000000627873 <+611>: mov %rcx,0x50(%rsp) 0x0000000000627878 <+616>: callq 0x7a2e00 0x000000000062787d <+621>: add $0x8,%rsp 0x0000000000627881 <+625>: sub $0x8,%rsp => 0x0000000000627885 <+629>: mov 0x48(%rsp),%rcx (A) 0x000000000062788a <+634>: mov 0x50(%rsp),%rdx 0x000000000062788f <+639>: add %rdx,%rcx 0x0000000000627892 <+642>: mov %rbx,%rdx 0x0000000000627895 <+645>: mov %r14,%rdi 0x0000000000627898 <+648>: mov %rcx,%rsi 0x000000000062789b <+651>: mov %rax,%rbx 0x000000000062789e <+654>: xor %eax,%eax 0x00000000006278a0 <+656>: callq 0x62c000 }}} Where the stack at point (A) looks like this, {{{ >>> x/16a $rsp+0x38 0x7f3f82107e18: 0x0 0x0 0x7f3f82107e28: 0xa800000042004d27 0xa900000000006b33 <==== yikes 0x7f3f82107e38: 0x42003e4301 0x42003e4310 0x7f3f82107e48: 0x42003e43a1 0x42003e4909 }}} Tracing further back I end up at point (B), {{{ Continuing. Thread 2 hit Hardware watchpoint 1: *(void**) 0x7f3f82107e28 Old value = (void *) 0xa800000042004d27 New value = (void *) 0x42004e0d80 0x000000000062786e in s7zn_info () }}} Continuing to trace things back, it seems that these pointers are loaded from a stack frame, {{{ >>> x/8a $rbx-1 0x4200088130: 0x6b0550 0x520000000000a02d 0x4200088140: 0xa800000042004d27 0xa900000000006b33 0x4200088150: 0x6a00000042004d26 0x797f38 0x4200088160: 0x4200088131 0x4200088118 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 22:04:11 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 22:04:11 -0000 Subject: [GHC] #15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite In-Reply-To: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> References: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> Message-ID: <061.c0953814bc6d5c9b63ab2a13bbc9e14e@haskell.org> #15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The previous debugging session ended up looking a bit messy. Starting afresh, this time with `+RTS -DS`. Things are looking much clearer now. We get the following segfault: {{{ Thread 2 received signal SIGSEGV, Segmentation fault. 0x00000000007c8370 in stg_IND_STATIC_info () at rts/StgMiscClosures.cmm:270 270 { >>> bt #0 0x00000000007c8370 in stg_IND_STATIC_info () at rts/StgMiscClosures.cmm:270 #1 0x00000000006ae1f0 in bytestringzm0zi10zi8zi2_DataziByteStringziLazzy_fromChunkszugo_info () at libraries/bytestring/Data/ByteString/Lazy.hs:267 #2 0x00000000007c5388 in ?? () at rts/Updates.cmm:31 #3 0x00000000006adc50 in bytestringzm0zi10zi8zi2_DataziByteStringziLazzy_toChunkszugo_info () at libraries/bytestring/Data/ByteString/Lazy.hs:271 #4 0x00000000007c5388 in ?? () at rts/Updates.cmm:31 #5 0x0000000000624d20 in s7zn_info () #6 0x0000000000000000 in ?? () }}} where `$rbx` points to memory cleared by the RTS: {{{ >>> x/8a $rbx 0x4200365960: 0xaaaaaaaaaaaaaaaa 0xaaaaaaaaaaaaaaaa 0x4200365970: 0xaaaaaaaaaaaaaaaa 0xaaaaaaaaaaaaaaaa 0x4200365980: 0xaaaaaaaaaaaaaaaa 0xaaaaaaaaaaaaaaaa 0x4200365990: 0xaaaaaaaaaaaaaaaa 0xaaaaaaaaaaaaaaaa }}} Tracing this back it looks like this once resided in a nursery that has since been freed. It sounds like something is being freed too soon (perhaps something like #14346/#15260). Looking at the package implementation it looks like there are a few `withForeignPtr` uses. This is quite suspicious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 22:06:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 22:06:50 -0000 Subject: [GHC] #14917: Allow levity polymorphism in binding position In-Reply-To: <049.d67991f1b0cd65b675056d1b1f0986b9@haskell.org> References: <049.d67991f1b0cd65b675056d1b1f0986b9@haskell.org> Message-ID: <064.51f78d12d2b4da56630a612c0b2077b3@haskell.org> #14917: Allow levity polymorphism in binding position -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Ericson2314): * cc: Ericson2314 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 22:16:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 22:16:20 -0000 Subject: [GHC] #15558: Locally handling an empty constraint Message-ID: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> #15558: Locally handling an empty constraint -------------------------------------+------------------------------------- Reporter: Ericson2314 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I need something like `\case {}` for constraints. See the code below. There's nothing I can replace the `undefined` with that will satisfy the type checker. The dead code warning also bubbled up out of the field incorrectly. I think this will require new language features tangentially related to Lambdas for `forall`. (Both `forall _.` and `=>` are invisible quantifiers.) I will link this ticket in that GHC proposal, but am making it's own issue in the first place in case this is a genuine bug that can be fixed by less intrusive means. {{{ {-# LANGUAGE RankNTypes #-} {-# LANGUAGE EmptyCase #-} {-# LANGUAGE LambdaCase #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE ScopedTypeVariables #-} module Asdf where import Data.Kind import Data.Type.Equality data Sing a where X :: Sing Int Y :: Sing [Bool] data Foo a = Foo a (forall b. [b] :~: a -> b) data Bar a = Bar a (forall b. [b] ~ a => b) f, f' :: forall a. Sing a -> Foo a f s = Foo a b where a :: a a = case s of X -> 0 Y -> [] b :: forall b. [b] :~: a -> b b = case s of X -> \case {} Y -> \Refl -> False f' = \case X -> Foo 0 (\case {}) Y -> Foo [] (\Refl -> False) g, g' :: forall a. Sing a -> Bar a g s = Bar a b where a :: a a = case s of X -> 0 Y -> [] b :: forall b. [b] ~ a => b b = case s of Y -> False g' = \case X -> Bar 0 undefined -- can't make this happy Y -> Bar [] False }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 22:32:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 22:32:06 -0000 Subject: [GHC] #15558: Locally handling an empty constraint In-Reply-To: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> References: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> Message-ID: <065.c57b281bad21784db355114fa33779e5@haskell.org> #15558: Locally handling an empty constraint -------------------------------------+------------------------------------- Reporter: Ericson2314 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ashley Yakeley): Hmm, this seemed to work with 8.4.3: {{{ bar :: Bar Int bar = Bar 0 undefined g' = \case X -> bar Y -> Bar [] False }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 22 22:37:41 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Aug 2018 22:37:41 -0000 Subject: [GHC] #15558: Locally handling an empty constraint In-Reply-To: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> References: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> Message-ID: <065.ed4994d90ca3fc681b9c92707f33827d@haskell.org> #15558: Locally handling an empty constraint -------------------------------------+------------------------------------- Reporter: Ericson2314 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ashley Yakeley): I've wanted something like this once in the past when I was using preprocessor conditional compilation. Logically, ex falso quodlibet, every type should match with every other type in "inaccessible" code... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 00:01:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 00:01:48 -0000 Subject: [GHC] #15558: Locally handling an empty constraint In-Reply-To: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> References: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> Message-ID: <065.d2fed74a8470c65c79c93bb177b4171b@haskell.org> #15558: Locally handling an empty constraint -------------------------------------+------------------------------------- Reporter: Ericson2314 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Ericson2314: Old description: > I need something like `\case {}` for constraints. See the code below. > There's nothing I can replace the `undefined` with that will satisfy the > type checker. The dead code warning also bubbled up out of the field > incorrectly. > > I think this will require new language features tangentially related to > Lambdas for `forall`. (Both `forall _.` and `=>` are invisible > quantifiers.) I will link this ticket in that GHC proposal, but am making > it's own issue in the first place in case this is a genuine bug that can > be fixed by less intrusive means. > > {{{ > {-# LANGUAGE RankNTypes #-} > {-# LANGUAGE EmptyCase #-} > {-# LANGUAGE LambdaCase #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE ScopedTypeVariables #-} > module Asdf where > > import Data.Kind > import Data.Type.Equality > > data Sing a where > X :: Sing Int > Y :: Sing [Bool] > > data Foo a = Foo a (forall b. [b] :~: a -> b) > data Bar a = Bar a (forall b. [b] ~ a => b) > > f, f' :: forall a. Sing a -> Foo a > > f s = Foo a b > where > a :: a > a = case s of > X -> 0 > Y -> [] > b :: forall b. [b] :~: a -> b > b = case s of > X -> \case {} > Y -> \Refl -> False > > f' = \case > X -> Foo 0 (\case {}) > Y -> Foo [] (\Refl -> False) > > g, g' :: forall a. Sing a -> Bar a > > g s = Bar a b > where > a :: a > a = case s of > X -> 0 > Y -> [] > b :: forall b. [b] ~ a => b > b = case s of > Y -> False > > g' = \case > X -> Bar 0 undefined -- can't make this happy > Y -> Bar [] False > > }}} New description: I need something like `\case {}` for constraints. See the code below. The undefined won't satisfy the type checker, nor is there anything total I found that I could replace it with that would. The dead code warning also bubbled up out of the field incorrectly. I think this will require new language features tangentially related to Lambdas for `forall`. (Both `forall _.` and `=>` are invisible quantifiers.) I will link this ticket in that GHC proposal, but am making it's own issue in the first place in case this is a genuine bug that can be fixed by less intrusive means. {{{ {-# LANGUAGE RankNTypes #-} {-# LANGUAGE EmptyCase #-} {-# LANGUAGE LambdaCase #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE ScopedTypeVariables #-} module Asdf where import Data.Kind import Data.Type.Equality data Sing a where X :: Sing Int Y :: Sing [Bool] data Foo a = Foo a (forall b. [b] :~: a -> b) data Bar a = Bar a (forall b. [b] ~ a => b) f, f' :: forall a. Sing a -> Foo a f s = Foo a b where a :: a a = case s of X -> 0 Y -> [] b :: forall b. [b] :~: a -> b b = case s of X -> \case {} Y -> \Refl -> False f' = \case X -> Foo 0 (\case {}) Y -> Foo [] (\Refl -> False) g, g' :: forall a. Sing a -> Bar a g s = Bar a b where a :: a a = case s of X -> 0 Y -> [] b :: forall b. [b] ~ a => b b = case s of Y -> False g' = \case X -> Bar 0 undefined -- can't make this happy Y -> Bar [] False }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 00:03:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 00:03:52 -0000 Subject: [GHC] #15558: Locally handling an empty constraint In-Reply-To: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> References: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> Message-ID: <065.7189c8afd205485dc64e7bdcbba51214@haskell.org> #15558: Locally handling an empty constraint -------------------------------------+------------------------------------- Reporter: Ericson2314 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Ericson2314: Old description: > I need something like `\case {}` for constraints. See the code below. The > undefined won't satisfy the type checker, nor is there anything total I > found that I could replace it with that would. The dead code warning also > bubbled up out of the field incorrectly. > > I think this will require new language features tangentially related to > Lambdas for `forall`. (Both `forall _.` and `=>` are invisible > quantifiers.) I will link this ticket in that GHC proposal, but am making > it's own issue in the first place in case this is a genuine bug that can > be fixed by less intrusive means. > > {{{ > {-# LANGUAGE RankNTypes #-} > {-# LANGUAGE EmptyCase #-} > {-# LANGUAGE LambdaCase #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE ScopedTypeVariables #-} > module Asdf where > > import Data.Kind > import Data.Type.Equality > > data Sing a where > X :: Sing Int > Y :: Sing [Bool] > > data Foo a = Foo a (forall b. [b] :~: a -> b) > data Bar a = Bar a (forall b. [b] ~ a => b) > > f, f' :: forall a. Sing a -> Foo a > > f s = Foo a b > where > a :: a > a = case s of > X -> 0 > Y -> [] > b :: forall b. [b] :~: a -> b > b = case s of > X -> \case {} > Y -> \Refl -> False > > f' = \case > X -> Foo 0 (\case {}) > Y -> Foo [] (\Refl -> False) > > g, g' :: forall a. Sing a -> Bar a > > g s = Bar a b > where > a :: a > a = case s of > X -> 0 > Y -> [] > b :: forall b. [b] ~ a => b > b = case s of > Y -> False > > g' = \case > X -> Bar 0 undefined -- can't make this happy > Y -> Bar [] False > > }}} New description: I need something like `\case {}` for constraints. See the code below. The `undefined` won't satisfy the type checker, nor is there anything total I found that would. The dead code warning also bubbled up out of the field incorrectly. I think this will require new language features tangentially related to Lambdas for `forall`. (Both `forall _.` and `=>` are invisible quantifiers.) I will link this ticket in that GHC proposal, but am making it's own issue in the first place in case this is a genuine bug that can be fixed by less intrusive means. {{{ {-# LANGUAGE RankNTypes #-} {-# LANGUAGE EmptyCase #-} {-# LANGUAGE LambdaCase #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE ScopedTypeVariables #-} module Asdf where import Data.Kind import Data.Type.Equality data Sing a where X :: Sing Int Y :: Sing [Bool] data Foo a = Foo a (forall b. [b] :~: a -> b) data Bar a = Bar a (forall b. [b] ~ a => b) f, f' :: forall a. Sing a -> Foo a f s = Foo a b where a :: a a = case s of X -> 0 Y -> [] b :: forall b. [b] :~: a -> b b = case s of X -> \case {} Y -> \Refl -> False f' = \case X -> Foo 0 (\case {}) Y -> Foo [] (\Refl -> False) g, g' :: forall a. Sing a -> Bar a g s = Bar a b where a :: a a = case s of X -> 0 Y -> [] b :: forall b. [b] ~ a => b b = case s of Y -> False g' = \case X -> Bar 0 undefined -- can't make this happy Y -> Bar [] False }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 00:06:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 00:06:21 -0000 Subject: [GHC] #15558: Locally handling an empty constraint In-Reply-To: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> References: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> Message-ID: <065.6f64300cab3ededbc3a7fdf19f2e4937@haskell.org> #15558: Locally handling an empty constraint -------------------------------------+------------------------------------- Reporter: Ericson2314 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm not quite sure I understand what this ticket is about, but it's worth noting that inaccessible code turned from an error to a warning in GHC 8.6.1, so your code does in fact compile as-is on 8.6.1: {{{ $ /opt/ghc/8.6.1/bin/ghci Bug.hs GHCi, version 8.6.0.20180810: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Asdf ( Bug.hs, interpreted ) Bug.hs:49:3: warning: [-Winaccessible-code] • Couldn't match type ‘[b]’ with ‘Int’ Inaccessible code in a pattern with constructor: X :: Sing Int, in a case alternative • In the pattern: X In a case alternative: X -> Bar 0 undefined In the expression: \case X -> Bar 0 undefined Y -> Bar [] False | 49 | X -> Bar 0 undefined -- can't make this happy | ^ }}} Does this satisfy your use case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 00:13:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 00:13:08 -0000 Subject: [GHC] #15558: Locally handling an empty constraint In-Reply-To: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> References: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> Message-ID: <065.d17125504164d68073c1534ec8db3b3a@haskell.org> #15558: Locally handling an empty constraint -------------------------------------+------------------------------------- Reporter: Ericson2314 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ericson2314): That's better, but I'd still like to remove the type error and the `undefined`: Being able to write `\ @_ -> undefined` would be better, and if we had a `witnessEq :: a ~ b => a :~ b`, I could do `\ @b -> case witnessEq @[b] @a of {}` which would be better still. Best of all with "absurd constraint lambda-case" would be: {{{ g' = \case X -> Bar 0 (\ @_b -> \@case {}) Y -> Bar [] False }}} Which avoids `witnessEq`. Generalizing to all constraints, that's avoidingg some dictionary singleton thing to do the normal term level empty case by doing empty case on the constraint directly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 00:16:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 00:16:37 -0000 Subject: [GHC] #15558: Locally handling an empty constraint In-Reply-To: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> References: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> Message-ID: <065.7d9b158300ae7271ab5522b5853bc0d8@haskell.org> #15558: Locally handling an empty constraint -------------------------------------+------------------------------------- Reporter: Ericson2314 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ericson2314): @RyanGlScott Also, I'm a bit queasy with what GHC thinks the inaccessable code is. Is it the entire `X -> Bar 0 ...`, or just the final field? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 01:11:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 01:11:51 -0000 Subject: [GHC] #15559: fromJust has no HasCallStack Message-ID: <046.0c0fc309394993486a792a626e8db1e1@haskell.org> #15559: fromJust has no HasCallStack -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Core | Version: 8.4.3 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The function `Data.Maybe.fromJust` does not have a `HasCallStack` constraint. I wonder why – is that intentional, or did just nobody bother yet? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 01:40:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 01:40:15 -0000 Subject: [GHC] #15559: fromJust has no HasCallStack In-Reply-To: <046.0c0fc309394993486a792a626e8db1e1@haskell.org> References: <046.0c0fc309394993486a792a626e8db1e1@haskell.org> Message-ID: <061.e417049e5bc2796c01d4210d59d814cb@haskell.org> #15559: fromJust has no HasCallStack -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: gridaphobe (added) Comment: When `HasCallStack` was introduced we intentionally did not introduce constraints to partial functions, no matter how small. IIRC this was in part because we expected third-party libraries to fill this need and in part it was out of concern for performance (since you would incur the cost of an additional argument, and potentially allocation, if the function isn't inlined). However, at this point it seems like `HasCallStack` is pretty well-accepted. It seems to me that we could start considering slowly adding `HasCallStack`s around in functions that are either (a) nearly certain to inline, or (b) not performance critical. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 01:56:02 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 01:56:02 -0000 Subject: [GHC] #15559: fromJust has no HasCallStack In-Reply-To: <046.0c0fc309394993486a792a626e8db1e1@haskell.org> References: <046.0c0fc309394993486a792a626e8db1e1@haskell.org> Message-ID: <061.bff162321db9c9d0105c8060026a643e@haskell.org> #15559: fromJust has no HasCallStack -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | 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 gridaphobe): There were also concerns about API stability, particularly since the original implementation exposed the implicit parameter. Now that we have the `HasCallStack` alias and a decent set of API functions around it, we could swap out the implementation, if necessary, with less potential for client breakage. I'd support starting to add `HasCallStack` constraints to common partial functions like `fromJust`, `head`, etc. Though, is this something that should be discussed with the Core Libraries Committee? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 06:43:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 06:43:18 -0000 Subject: [GHC] #15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite In-Reply-To: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> References: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> Message-ID: <061.fc518e99b083a5b46520ac6dbf131996@haskell.org> #15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by osa1: Old description: > {{{ > $ cabal get cryptohash-sha256-0.11.101.0 > $ cd cryptohash-sha256-0.11.101.0 > $ cabal new-run -w ghc-8.6.1 --enable-test --allow- > newer=*:base,*:stm,*:tasty test:test-sha256 -- -j 8 --quickcheck-tests > 9999 > }}} > > Eventually the program will start spamming stderr with `test-sha256: lost > signal due to full pipe: 11` repeatedly. This apparently only started > with 8.6.1. New description: {{{ $ cabal get cryptohash-sha256-0.11.101.0 $ cd cryptohash-sha256-0.11.101.0 $ cabal new-run -w ghc-8.6.1 --enable-test --allow- newer="*:base,*:stm,*:tasty" test:test-sha256 -- -j 8 --quickcheck-tests 9999 }}} Eventually the program will start spamming stderr with `test-sha256: lost signal due to full pipe: 11` repeatedly. This apparently only started with 8.6.1. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 07:43:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 07:43:32 -0000 Subject: [GHC] #15508: concprog001 fails with various errors when compiled with -prof In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.98d7ba056338bb1bc6562bc029c79a3b@haskell.org> #15508: concprog001 fails with various errors when compiled with -prof -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5051 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * component: Profiling => Compiler Old description: > I'm observing a few different runtime errors. I'm not sure if they're > because of different bugs so I'm filing one ticket for now. > > The reproduce with GHC HEAD: > > {{{ > prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce- > recomp -threaded > [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) > [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) > [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) > [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) > [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) > [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) > [7 of 7] Compiling Main ( Mult.hs, Mult.o ) > Linking Mult ... > > prog001 git:(master) $ ./Mult +RTS -N2 > Mult: internal error: scavenge_one: strange object 624722688 > (GHC version 8.7.20180809 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > zsh: abort (core dumped) ./Mult +RTS -N2 > > prog001 git:(master) $ ./Mult +RTS -N2 > Mult: internal error: scavenge_stack: weird activation record found on > stack: 0 > (GHC version 8.7.20180821 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > zsh: abort (core dumped) ./Mult +RTS -N2 > > prog001 git:(master) $ ./Mult +RTS -N2 > zsh: segmentation fault (core dumped) ./Mult +RTS -N2 > }}} > > It's very easy to trigger other kind of panics in `concprog001`, just try > different compile and runtime flag combinations. Note that for the > examples below you'll need debug + profiling or debug + profiling + > threaded runtimes, which are not built by default. To build those apply > this patch: > > {{{ > diff --git a/mk/config.mk.in b/mk/config.mk.in > index 11050120d4..f083abad22 100644 > --- a/mk/config.mk.in > +++ b/mk/config.mk.in > @@ -297,6 +297,7 @@ GhcRTSWays=l > > # Usually want the debug version > GhcRTSWays += debug > +GhcRTSWays += thr_debug_p debug_p > > # We always have the threaded versions, but note that SMP support may be > disabled > # (see GhcWithSMP). > diff --git a/rts/ghc.mk b/rts/ghc.mk > index 532c9aa175..ff3f18f30c 100644 > --- a/rts/ghc.mk > +++ b/rts/ghc.mk > @@ -329,7 +329,6 @@ WARNING_OPTS += -Wstrict-prototypes > WARNING_OPTS += -Wmissing-prototypes > WARNING_OPTS += -Wmissing-declarations > WARNING_OPTS += -Winline > -WARNING_OPTS += -Waggregate-return > WARNING_OPTS += -Wpointer-arith > WARNING_OPTS += -Wmissing-noreturn > WARNING_OPTS += -Wnested-externs > }}} > > Examples: > > {{{ > prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce- > recomp -debug > [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) > [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) > [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) > [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) > [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) > [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) > [7 of 7] Compiling Main ( Mult.hs, Mult.o ) > Linking Mult ... > > prog001 git:(master) $ ./Mult +RTS -DS > Mult: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 210 > > (GHC version 8.7.20180809 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > zsh: abort (core dumped) ./Mult +RTS -DS > }}} > > (I tried to fix this in Phab:D5051 but it's causing a segfault in test > `T11108` when run with profiling. Not sure what the problem is yet.) > > Another way: > > {{{ > prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce- > recomp -threaded > [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) > [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) > [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) > [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) > [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) > [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) > [7 of 7] Compiling Main ( Mult.hs, Mult.o ) > Linking Mult ... > > prog001 git:(master) $ ./Mult +RTS -N2 > zsh: segmentation fault (core dumped) ./Mult +RTS -N2 > }}} > > Yet another way: > > {{{ > prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce- > recomp -threaded -debug > [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) > [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) > [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) > [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) > [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) > [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) > [7 of 7] Compiling Main ( Mult.hs, Mult.o ) > Linking Mult ... > > prog001 git:(master) $ ./Mult +RTS -N2 > Mult: internal error: invalid closure, info=0x947edc > (GHC version 8.7.20180809 for x86_64_unknown_linux) > Please report this as a GHC bug: > http://www.haskell.org/ghc/reportabug > zsh: abort (core dumped) ./Mult +RTS -N2 > }}} > > It seems to work fine when not compiled for profiling so marking this bug > as a profiler bug. New description: I'm observing a few different runtime errors. I'm not sure if they're because of different bugs so I'm filing one ticket for now. The reproduce with GHC HEAD: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: scavenge_one: strange object 624722688 (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2 prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: scavenge_stack: weird activation record found on stack: 0 (GHC version 8.7.20180821 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2 prog001 git:(master) $ ./Mult +RTS -N2 zsh: segmentation fault (core dumped) ./Mult +RTS -N2 }}} It's very easy to trigger other kind of panics in `concprog001`, just try different compile and runtime flag combinations. Note that for the examples below you'll need debug + profiling or debug + profiling + threaded runtimes, which are not built by default. To build those apply this patch: {{{ diff --git a/mk/config.mk.in b/mk/config.mk.in index 11050120d4..f083abad22 100644 --- a/mk/config.mk.in +++ b/mk/config.mk.in @@ -297,6 +297,7 @@ GhcRTSWays=l # Usually want the debug version GhcRTSWays += debug +GhcRTSWays += thr_debug_p debug_p # We always have the threaded versions, but note that SMP support may be disabled # (see GhcWithSMP). diff --git a/rts/ghc.mk b/rts/ghc.mk index 532c9aa175..ff3f18f30c 100644 --- a/rts/ghc.mk +++ b/rts/ghc.mk @@ -329,7 +329,6 @@ WARNING_OPTS += -Wstrict-prototypes WARNING_OPTS += -Wmissing-prototypes WARNING_OPTS += -Wmissing-declarations WARNING_OPTS += -Winline -WARNING_OPTS += -Waggregate-return WARNING_OPTS += -Wpointer-arith WARNING_OPTS += -Wmissing-noreturn WARNING_OPTS += -Wnested-externs }}} Examples: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -DS Mult: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 210 (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -DS }}} (I tried to fix this in Phab:D5051 but it's causing a segfault in test `T11108` when run with profiling. Not sure what the problem is yet.) Another way: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 zsh: segmentation fault (core dumped) ./Mult +RTS -N2 }}} Yet another way: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -prof -fprof-auto -fforce-recomp -threaded -debug [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -N2 Mult: internal error: invalid closure, info=0x947edc (GHC version 8.7.20180809 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -N2 }}} ~~It seems to work fine when not compiled for profiling so marking this bug as a profiler bug.~~ This program fails sanity checks with non-threaded and non-profiling runtime too: {{{ prog001 git:(master) $ ghc-stage2 Mult.hs -fforce-recomp -debug -rtsopts [1 of 7] Compiling Stream ( Stream.hs, Stream.o ) [2 of 7] Compiling Converter ( Converter.hs, Converter.o ) [3 of 7] Compiling Thread ( Thread.hs, Thread.o ) [4 of 7] Compiling Utilities ( Utilities.hs, Utilities.o ) [5 of 7] Compiling Trit ( Trit.hs, Trit.o ) [6 of 7] Compiling Arithmetic ( Arithmetic.hs, Arithmetic.o ) [7 of 7] Compiling Main ( Mult.hs, Mult.o ) Linking Mult ... prog001 git:(master) $ ./Mult +RTS -DS Mult: internal error: checkClosure: stack frame (GHC version 8.7.20180821 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -DS }}} -- Comment: While messing around with different flags I realized that we don't need profiling or threaded flags, it fails some sanity checks in non-threaded non-profiled runtime. Updated the description and reverted the component from profiler to compiler (not sure if this is a codegen or RTS issue). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 10:01:14 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 10:01:14 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.86bc5ae980e5546319e8ebdc165d347f@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by phadej): Replying to [comment:25 bgamari]: > **Replying to comment:24:** > > I suppose this is a possibility, although it seems to be me that we should rather try to introduce a mechanism to allow the user to state explicitly what they mean. That is: the import is known to be redundant but added for compatibility's sake. This could either be a general mechanism (e.g. wiki:Design/LocalWarningPragmas) or something more specifically designed to address import redundancy. (e.g. a `{-# USED #-}` pragma which could be attached to an import to silence the redundancy checker), We shouldn't need to go through GHC-proposal process for a bug fix. We should fix a bug, and then the interested people will either polish https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/RelaxedUnusedImports into a proposal, or propose some other way around (e.g. more granular warning toggles, then per-module). I'm for sure **implicitly** depend on this bug behavior for warning free builds, but I don't like it. For example: the tool `weeder` (to purge dependencies) isn't as useful now, as one might have an import which isn't necessary, but it retains the dependency. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 10:12:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 10:12:29 -0000 Subject: [GHC] #14336: ghci leaks memory In-Reply-To: <051.dbf33557716163bb981beab6790198d1@haskell.org> References: <051.dbf33557716163bb981beab6790198d1@haskell.org> Message-ID: <066.db946b4ae780fad9f0a5aae7843d8ba6@haskell.org> #14336: ghci leaks memory -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by NeilMitchell): * status: new => closed * resolution: => fixed Comment: If this ever makes it into a released GHC (which it will with GHC 8.6) then I need to adjust ghcid to cope with it. Once I've done that, changing the behaviour for a future release has very little benefit to me. As a result, closing this ticket with Fixed as the initial ticket was fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 10:28:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 10:28:44 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.39a2216c6f419fa1733f311200234479@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: ekmett@… (added) Comment: I had forgotten all about [wiki:Commentary/Compiler/RelaxedUnusedImports]. Thanks: you are right to point to it as a possible design. We quite often fix a bug that forces libraries to change in some minor way; library authors are (perhaps reluctantly) used to this. In this case, the change affects only warnings, perhaps the least bad way to break a library. (Worse ways are: the library is now type incorrect; or (worse still) compiles cleanly but gives the wrong answers.) I think the awkward thing here is that library authors like to produce an updated version of the library that will work with many versions of GHC. For that they resort to CPP. Thus in `containers:Data.Map.Internal.hs` we see {{{ #if __GLASGOW_HASKELL__ >= 708 import qualified GHC.Exts as GHCExts #endif }}} The [https://prime.haskell.org/wiki/Libraries/3-Release-Policy three release policy says] ''Changes '''to basic libraries''' are planned and implemented so that, at any time, it is possible to write code that works with the latest three releases of GHC and base, without resorting to CPP, and without causing warnings even when compiled with -Wall.'' Note "to basic libraries". I don't see how it's possible to apply this policy to the compiler itself. Suppose a library compiles with GHC 12.0, and we want to make a change in the warnings the compiler produces. We could defer the change to 12.6; but then the author could just apply the policy starting at 12.6, so we'd have to defer to 12.12, and so on. I feel I must be missing something. Also as comment:24 points out, there is a non-CPP way to adapt too. Let's see what the CLC (cc'd) says. I'm adding Edward to cc as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 11:11:02 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 11:11:02 -0000 Subject: [GHC] #15552: Infinite loop/panic with an existential type. In-Reply-To: <050.eb5168d400b4a4211e35d29d96945d09@haskell.org> References: <050.eb5168d400b4a4211e35d29d96945d09@haskell.org> Message-ID: <065.07153af628b35cfeec90934b1039174e@haskell.org> #15552: Infinite loop/panic with an existential type. -------------------------------------+------------------------------------- Reporter: howtonotwin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: TypeInType, | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14723 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK I finally understand what is going on. Suppose we have {{{ alpha -> alpha where alpha is already unified: alpha := T{tc-tycon} Int -> Int and T is knot-tied }}} By "knot-tied" I mean that the occurrence of T is currently a `TcTyCon`, but the global env contains a mapping `"T" :-> T{knot-tied-tc}`. See `Note [Type checking recursive type and class declarations]` in `TcTyClsDecls`. Now we call `zonkTcTypeToType` on that `alpha -> alpha`. * The first time we encounter `alpha` we invoke `TcHsTyn.zonkTyVarOcc` (because that's what the `tcm_tyvar` field of `zonk_tycomapper` says. Here's the code {{{ zonkTyVarOcc env@(ZonkEnv zonk_unbound_tyvar tv_env _) tv | isTcTyVar tv = case tcTyVarDetails tv of SkolemTv {} -> lookup_in_env RuntimeUnk {} -> lookup_in_env MetaTv { mtv_ref = ref } -> do { cts <- readMutVar ref ; case cts of Flexi -> do { kind <- zonkTcTypeToType env (tyVarKind tv) ; zonk_unbound_tyvar (setTyVarKind tv kind) } Indirect ty -> do { zty <- zonkTcTypeToType env ty -- Small optimisation: shortern- out indirect steps -- so that the old type may be more easily collected. ; writeMutVar ref (Indirect zty) ; return zty } } }}} * `zonkTyVarOcc` sees that the tyvar is already unifies (the `Indirect` branch), so it * zonks the type it points to `T{tc-tycon} Int -> Int`, yielding `T {knot-tied-tc} Int -> Int` * '''and updates `alpha` to point to this zonked type'''. The second step is a "small optimisation": there's no point in re-doing the work of zonking the type inside the `Indirect` if we encounter the variable a second time. * But alas, when we encounter `alpha` for a second time, we end up looking at `T{knot-tied-tc}` and fall into a black hole. The whole point of `zonkTcTypeToType` is that it produces a type full of knot-tied tycons, and ''you must not look at the result''. To put it another way `zonkTcTypeToType . zonkTcTypeToType` is not the same as `zonkTcTypeToType`. (If `zonkTcTypeToType` had different argumennt and result types, this issue would have been a type error; but the optimisation in `zonkTyVarOcc` would also become type-incorrect.) Now I see the problem, I'm astonished that it has not bitten us before. It shows up in #15552 in a more complicated way than the one I describe here, involving unification inside kinds. What to do? I think the Right Thing is probably to follow the thought experiment of distinguishing `Type` from `TcType`. So then, instead of the current: {{{ data MetaDetails = Flexi | Indirect TcType }}} we'd have so say {{{ data MetaDetails = Flexi | IndirectTc TcType -- There may still be unification variables in here | Indirect Type -- No unification variables in here }}} This would mean that some 2-way branches become 3-way branches, so there might be a perf impact; I have no idea if it would be measurable. Interestingly, `zonkTcTypeToType` could stop altogether (hooray, efficient) when it finds `Indirect`, whereas `zonkTcType` can't (sigh), because it can't tell if an `IndirectTc` is from "this" zonk or some earlier one. The only way I can see to solve that would be to count unifications, and record the current unification-count in the `IndirectTc`, thus `IndirectTc UnifCount TcType`. That would of course carry its own costs. Any views? I'm going to wait a few days before doing anything drastic here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 11:28:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 11:28:47 -0000 Subject: [GHC] #15552: Infinite loop/panic with an existential type. In-Reply-To: <050.eb5168d400b4a4211e35d29d96945d09@haskell.org> References: <050.eb5168d400b4a4211e35d29d96945d09@haskell.org> Message-ID: <065.59f5dd4abaf6971a2c657e33eb3d8119@haskell.org> #15552: Infinite loop/panic with an existential type. -------------------------------------+------------------------------------- Reporter: howtonotwin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: TypeInType, | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14723 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): In unravelling #15552 I also realised that * `Note [Type checking recursive type and class declarations]` in `TcTyClsDecls` uses the global type envt during zonking to hold the knot- tied TyCons * But the `ZonkEnv` used in `TcHsSyn` plays a very, very similar role {{{ data ZonkEnv = ZonkEnv UnboundTyVarZonker (TyCoVarEnv TyVar) (IdEnv Var) -- What variables are in scope -- Maps an Id or EvVar to its zonked version; both have the same Name -- Note that all evidence (coercion variables as well as dictionaries) -- are kept in the ZonkEnv -- Only *type* abstraction is done by side effect -- Is only consulted lazily; hence knot-tying }}} Moreover, as you'll see in `TcHsSyn.zonkRecMonoBinds`, the `ZonkEnv` is used in a knot-tied way, to get sharing of all the `Ids`. My thought: we should use the same mechanism for both. The most straightforward thing is to add a `NameEnv TyCon` to `ZonkEnv` for those knot-tied `TyCons`. Then, in `TcTyClDecls` insetad of {{{ ; tcExtendRecEnv (zipRecTyClss tc_tycons rec_tyclss) $ ...mapM (tcTyClDecl roles) tyclds... }}} we'd create a `ZonkEnv`, and pass it into `tcTyClDecl`. A little bit more plumbing, but more honest and certainly more uniform. PS: it must be possible to get rid of that `UnboundTyVarZonker` field too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 11:29:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 11:29:35 -0000 Subject: [GHC] #15473: GHC 8.6+ loops infinitely on an UndecidableInstances error message In-Reply-To: <050.0e1359f1570b3b8da9f1e08c07e4c7b6@haskell.org> References: <050.0e1359f1570b3b8da9f1e08c07e4c7b6@haskell.org> Message-ID: <065.637e5ffcb806c342025f6aca1c1d1720@haskell.org> #15473: GHC 8.6+ loops infinitely on an UndecidableInstances error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"db6f1d9cfc74690798645a7cc5b25040c36bb35d/ghc" db6f1d9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="db6f1d9cfc74690798645a7cc5b25040c36bb35d" Turn infinite loop into a panic In these two functions * TcIface.toIfaceAppTyArgsX * Type.piResultTys we take a type application (f t1 .. tn) and try to find its kind. It turned out that, if (f t1 .. tn) was ill-kinded the function would go into an infinite loop. That's not good: it caused the loop in Trac #15473. This patch doesn't fix the bug in #15473, but it does turn the loop into a decent panic, which is a step forward. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 11:29:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 11:29:35 -0000 Subject: [GHC] #15473: GHC 8.6+ loops infinitely on an UndecidableInstances error message In-Reply-To: <050.0e1359f1570b3b8da9f1e08c07e4c7b6@haskell.org> References: <050.0e1359f1570b3b8da9f1e08c07e4c7b6@haskell.org> Message-ID: <065.2b2d8668ad22f1f94c146297177dd439@haskell.org> #15473: GHC 8.6+ loops infinitely on an UndecidableInstances error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"8c7f90abcc1e8f9f29b751f23174e8db89ba6983/ghc" 8c7f90a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8c7f90abcc1e8f9f29b751f23174e8db89ba6983" Fix a typo in TcValidity.checkFamInstRhs In error message generation we were using the wrong type constructor in inst_head. Result: the type became ill-kinded, and that sent the compiler into a loop. A separate patch fixes the loop. This patch fixes the actual bug -- Trac #15473. I also improved the "occurs more often" error message a bit. But it's still pretty terrible: * Variable ‘a’ occurs more often in the type family application ‘Undefined’ than in the instance head ‘LetInterleave xs t ts is y z’ It looks like nonsense, but all becomes clear if you use -fprint-explicit-kinds. Really we should fix this by spotting when invisible arguments are involved and at least suggesting -fprint-explicit-kinds. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 11:29:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 11:29:35 -0000 Subject: [GHC] #11474: incorrect redundant-constraints warning In-Reply-To: <042.2e15408ecc3253cf7591957da36697cd@haskell.org> References: <042.2e15408ecc3253cf7591957da36697cd@haskell.org> Message-ID: <057.d0416e9c7b6d60bed6cef8cd4c4cb1f5@haskell.org> #11474: incorrect redundant-constraints warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | tests/typecheck/should_compile/T11474.hs Blocked By: | Blocking: Related Tickets: #10100 | Differential Rev(s): Phab:D4739 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"4293a80a3ea835412737911bcb2a6703e9af378b/ghc" 4293a80a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4293a80a3ea835412737911bcb2a6703e9af378b" Accommodate API change in transSuperClasses In this patch commit 6eabb6ddb7c53784792ee26b1e0657bde7eee7fb Author: Simon Peyton Jones Date: Tue Dec 15 14:26:13 2015 +0000 Allow recursive (undecidable) superclasses I changed (transSuperClasses p) to return only the superclasses of p, but not p itself. (Previously it always returned p as well.) The use of transSuperClasses in TcErrors.warnRedundantConstraints really needs 'p' in the result -- but I faild to fix this call site, and instead crippled the test for Trac #10100. This patch sets things right * Accomodates the API change * Re-enables T10100 * And thereby fixes Trac #11474 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 11:29:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 11:29:35 -0000 Subject: [GHC] #10100: Bogus "redundant constraint" warning with functional dependencies In-Reply-To: <048.9dcc7a939a45b31fb0e7cae24622ba1c@haskell.org> References: <048.9dcc7a939a45b31fb0e7cae24622ba1c@haskell.org> Message-ID: <063.9da683cb3081c02eeec97b1be5441656@haskell.org> #10100: Bogus "redundant constraint" warning with functional dependencies -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T10100 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"4293a80a3ea835412737911bcb2a6703e9af378b/ghc" 4293a80a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4293a80a3ea835412737911bcb2a6703e9af378b" Accommodate API change in transSuperClasses In this patch commit 6eabb6ddb7c53784792ee26b1e0657bde7eee7fb Author: Simon Peyton Jones Date: Tue Dec 15 14:26:13 2015 +0000 Allow recursive (undecidable) superclasses I changed (transSuperClasses p) to return only the superclasses of p, but not p itself. (Previously it always returned p as well.) The use of transSuperClasses in TcErrors.warnRedundantConstraints really needs 'p' in the result -- but I faild to fix this call site, and instead crippled the test for Trac #10100. This patch sets things right * Accomodates the API change * Re-enables T10100 * And thereby fixes Trac #11474 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 11:29:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 11:29:49 -0000 Subject: [GHC] #15559: fromJust has no HasCallStack In-Reply-To: <046.0c0fc309394993486a792a626e8db1e1@haskell.org> References: <046.0c0fc309394993486a792a626e8db1e1@haskell.org> Message-ID: <061.c35f1bedd885f1c9a97701b21612db9b@haskell.org> #15559: fromJust has no HasCallStack -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | 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 ulysses4ever): Does it make sense to mark it `newcomer`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 11:41:50 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 11:41:50 -0000 Subject: [GHC] #15436: Compile-time panic, Prelude.!!: negative index In-Reply-To: <047.11105fbd3a2250b4dd24d6c191fbb08d@haskell.org> References: <047.11105fbd3a2250b4dd24d6c191fbb08d@haskell.org> Message-ID: <062.294fad87b88bbaf76f555e2a39d1c84a@haskell.org> #15436: Compile-time panic, Prelude.!!: negative index -------------------------------------+------------------------------------- Reporter: pbrisbin | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | simplCore/should_run/T15436 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5008 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): I was just about to finally file this bug I ran into back in May already w/ GHC 8.4.2 but didn't have time to investigate and instead workarounded via https://github.com/text-utf8/text- utf8/commit/5ba8f5d1d4c0f39399d8c32f069e4132c92ef099 It'd be great to have this fixed in GHC 8.4.4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 13:16:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 13:16:17 -0000 Subject: [GHC] #11474: incorrect redundant-constraints warning In-Reply-To: <042.2e15408ecc3253cf7591957da36697cd@haskell.org> References: <042.2e15408ecc3253cf7591957da36697cd@haskell.org> Message-ID: <057.c42d33a567d8ac72b33b39ab773b608c@haskell.org> #11474: incorrect redundant-constraints warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | tests/typecheck/should_compile/T11474.hs Blocked By: | Blocking: Related Tickets: #10100 | Differential Rev(s): Phab:D4739 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 13:35:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 13:35:31 -0000 Subject: [GHC] #13896: Use response file to invoke hsc2hs In-Reply-To: <046.8d005e1593e32147d596c190fbabb716@haskell.org> References: <046.8d005e1593e32147d596c190fbabb716@haskell.org> Message-ID: <061.c10264f71845462513c4b1f7fe68d126@haskell.org> #13896: Use response file to invoke hsc2hs ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: hsc2hs | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4612 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by ckoparkar): Ben, I'm sorry for not getting this done in time for 8.6. Working on this today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 13:44:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 13:44:08 -0000 Subject: [GHC] #15526: Explain or remove mystery import in Unsafe.Coerce In-Reply-To: <045.8c1bd79d636e4b29cdc257cdfcb27b40@haskell.org> References: <045.8c1bd79d636e4b29cdc257cdfcb27b40@haskell.org> Message-ID: <060.b0cf5ea5742c1a6eebe791b81d61947b@haskell.org> #15526: Explain or remove mystery import in Unsafe.Coerce -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5092 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ckoparkar): * differential: => Phab:D5092 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 13:45:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 13:45:26 -0000 Subject: [GHC] #15526: Explain or remove mystery import in Unsafe.Coerce In-Reply-To: <045.8c1bd79d636e4b29cdc257cdfcb27b40@haskell.org> References: <045.8c1bd79d636e4b29cdc257cdfcb27b40@haskell.org> Message-ID: <060.c173cb5b21e370a64baa206faaa87db8@haskell.org> #15526: Explain or remove mystery import in Unsafe.Coerce -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5092 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 14:01:58 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 14:01:58 -0000 Subject: [GHC] #15558: Locally handling an empty constraint In-Reply-To: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> References: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> Message-ID: <065.41d536eda251808df2e61416c0d76fd4@haskell.org> #15558: Locally handling an empty constraint -------------------------------------+------------------------------------- Reporter: Ericson2314 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): You're right, there's definitely something fishy going on with this warning. Here's a simplified example: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} module Bug where data T a where MkT :: T Int data Foo a = MkFoo ((a ~ Bool) => ()) f :: T a -> Foo a f MkT = MkFoo () g :: Foo Int g = f MkT }}} {{{ $ /opt/ghc/8.6.1/bin/ghci Bug.hs GHCi, version 8.6.0.20180810: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:11:3: warning: [-Winaccessible-code] • Couldn't match type ‘Int’ with ‘Bool’ Inaccessible code in a pattern with constructor: MkT :: T Int, in an equation for ‘f’ • In the pattern: MkT In an equation for ‘f’: f MkT = MkFoo () | 11 | f MkT = MkFoo () | ^^^ }}} While there //is// inaccessible code here, the warning is highlighting the wrong spot: it should be the argument to `MkFoo`, not the argument to `f`. (The fact that `g` typechecks at all is a testament to this fact.) I suspect that we're using the wrong `SrcSpan` somewhere in GHC, which causes the reported location to be incorrect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 14:06:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 14:06:19 -0000 Subject: [GHC] #15473: GHC 8.6+ loops infinitely on an UndecidableInstances error message In-Reply-To: <050.0e1359f1570b3b8da9f1e08c07e4c7b6@haskell.org> References: <050.0e1359f1570b3b8da9f1e08c07e4c7b6@haskell.org> Message-ID: <065.062910839dd6411448fcb03d58dd2701@haskell.org> #15473: GHC 8.6+ loops infinitely on an UndecidableInstances error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | typecheck/should_compile/T15473 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_compile/T15473 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 14:07:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 14:07:35 -0000 Subject: [GHC] #11474: incorrect redundant-constraints warning In-Reply-To: <042.2e15408ecc3253cf7591957da36697cd@haskell.org> References: <042.2e15408ecc3253cf7591957da36697cd@haskell.org> Message-ID: <057.f0a8b8d5b30f8e10e0afe59fc7e5adc4@haskell.org> #11474: incorrect redundant-constraints warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | tests/typecheck/should_compile/T11474.hs Blocked By: | Blocking: Related Tickets: #10100 | Differential Rev(s): Phab:D4739 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK done. Follows the idea of the patch, but with less code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 14:07:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 14:07:48 -0000 Subject: [GHC] #15473: GHC 8.6+ loops infinitely on an UndecidableInstances error message In-Reply-To: <050.0e1359f1570b3b8da9f1e08c07e4c7b6@haskell.org> References: <050.0e1359f1570b3b8da9f1e08c07e4c7b6@haskell.org> Message-ID: <065.73cec19822443607aec99d193304792b@haskell.org> #15473: GHC 8.6+ loops infinitely on an UndecidableInstances error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | typecheck/should_compile/T15473 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: closed => merge Comment: I'll be optimistic and mark commits db6f1d9cfc74690798645a7cc5b25040c36bb35d and 8c7f90abcc1e8f9f29b751f23174e8db89ba6983 as merge candidates, since they're both fairly small. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 14:25:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 14:25:39 -0000 Subject: [GHC] #15053: Compiler panic on invalid syntax (unterminated pragma) In-Reply-To: <047.d617a7e8bd5e9dac7c56bae30af4b445@haskell.org> References: <047.d617a7e8bd5e9dac7c56bae30af4b445@haskell.org> Message-ID: <062.3697cddf7c32b8c3e434cdf1676c78a4@haskell.org> #15053: Compiler panic on invalid syntax (unterminated pragma) -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: make test crash or panic | TEST=T15053 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4883 Wiki Page: | Phab:D5093 -------------------------------------+------------------------------------- Changes (by RolandSenn): * status: new => patch * testcase: => make test TEST=T15053 * differential: Phab:D4883 => Phab:D4883 Phab:D5093 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 14:41:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 14:41:40 -0000 Subject: [GHC] #14813: EmptyCase thinks pattern match involving type family is not exhaustive, when it actually is In-Reply-To: <050.3962023f385f083f5f659edfe4ce01db@haskell.org> References: <050.3962023f385f083f5f659edfe4ce01db@haskell.org> Message-ID: <065.ea29cddd046be686c79228526c657be2@haskell.org> #14813: EmptyCase thinks pattern match involving type family is not exhaustive, when it actually is -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5094 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5094 Comment: I barfed some code into my terminal, and by some miracle, it actually seems to //work//. See Phab:D5094 for the (slightly cleaned-up) barf. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 14:59:02 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 14:59:02 -0000 Subject: [GHC] #15518: -ddump-splices pretty-prints LambdaCase nonsensically In-Reply-To: <050.995ed236da7a975a0b6882f1ba885e96@haskell.org> References: <050.995ed236da7a975a0b6882f1ba885e96@haskell.org> Message-ID: <065.ff46522027d08170591e7630d6aadcba@haskell.org> #15518: -ddump-splices pretty-prints LambdaCase nonsensically -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5069 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: 8.8.1 => 8.6.1 Comment: This was marked as merge, but not milestoned properly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 14:59:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 14:59:17 -0000 Subject: [GHC] #15361: Error message displays redundant equality constraint In-Reply-To: <050.41dbf0633f06cf78daba7d213be8b850@haskell.org> References: <050.41dbf0633f06cf78daba7d213be8b850@haskell.org> Message-ID: <065.f41b8ce6e014b9be0c98b5eac84e581b@haskell.org> #15361: Error message displays redundant equality constraint -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14394 | Differential Rev(s): Phab:D5002 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: 8.8.1 => 8.6.1 Comment: This was marked as merge, but not milestoned properly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 15:00:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 15:00:22 -0000 Subject: [GHC] #11474: incorrect redundant-constraints warning In-Reply-To: <042.2e15408ecc3253cf7591957da36697cd@haskell.org> References: <042.2e15408ecc3253cf7591957da36697cd@haskell.org> Message-ID: <057.0a76d2aa3365618bc333eeb117d59f3d@haskell.org> #11474: incorrect redundant-constraints warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | tests/typecheck/should_compile/T11474.hs Blocked By: | Blocking: Related Tickets: #10100 | Differential Rev(s): Phab:D4739 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: 8.8.1 => 8.6.1 Comment: This was marked as merge, but not milestoned properly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 15:01:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 15:01:57 -0000 Subject: [GHC] Batch modify: #14973, #15087, #15165, #15213, #15535 In-Reply-To: <066.c040fa932a044f9726f8a5d7de00c33d@haskell.org> References: <066.c040fa932a044f9726f8a5d7de00c33d@haskell.org> Message-ID: <081.98a737a652a7ff7e356eb8458a3c6542@haskell.org> Batch modification to #14973, #15087, #15165, #15213, #15535 by RyanGlScott: milestone to 8.6.1 Comment: These were marked as merge, but not milestoned properly. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 16:02:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 16:02:17 -0000 Subject: [GHC] #14012: External interpreter fails on FreeBSD In-Reply-To: <046.2b65587ea7267566cfeb67b314c36291@haskell.org> References: <046.2b65587ea7267566cfeb67b314c36291@haskell.org> Message-ID: <061.b1b20888227eea08d8a9eb75d1c9c7fd@haskell.org> #14012: External interpreter fails on FreeBSD ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: RemoteGHCi Operating System: FreeBSD | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by arrowd): Running `ghc -fexternal-interpreter --interactive` with GHC 8.4.3 installed from ports works fine now. Does that mean that the problem is solved? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 16:03:30 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 16:03:30 -0000 Subject: [GHC] #15499: Panic in occurence analysis phase (?), getRuntimeRep In-Reply-To: <048.4ced706f36b918299fae10c865c8eddf@haskell.org> References: <048.4ced706f36b918299fae10c865c8eddf@haskell.org> Message-ID: <063.a93640400f6289155ccd97fa2798fcb2@haskell.org> #15499: Panic in occurence analysis phase (?), getRuntimeRep -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: RyanGlScott Type: bug | Status: merge Priority: high | Milestone: 8.4.4 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5060 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 16:29:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 16:29:18 -0000 Subject: [GHC] #14064: Compiling problem on FreeBSD 11 ("failed in phase") In-Reply-To: <043.996442976c5d50d07afa88e2354bce42@haskell.org> References: <043.996442976c5d50d07afa88e2354bce42@haskell.org> Message-ID: <058.917a802528eb5fe3aa62a1da17c1ccfb@haskell.org> #14064: Compiling problem on FreeBSD 11 ("failed in phase") -------------------------------------+------------------------------------- Reporter: ohho | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by arrowd): As of now, GHC port (8.4.3) builds fine on 10.3 too using GCC toolchain. This may be closed, probably. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 16:30:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 16:30:51 -0000 Subject: [GHC] #4022: GHC Bindist is Broken on FreeBSD/amd64 In-Reply-To: <042.be61d95849398bdf9c05d1a69af1e7e3@haskell.org> References: <042.be61d95849398bdf9c05d1a69af1e7e3@haskell.org> Message-ID: <057.79835c0a419b7074df8c244a2e9b548c@haskell.org> #4022: GHC Bindist is Broken on FreeBSD/amd64 -------------------------------------+------------------------------------- Reporter: pgj | Owner: pgj Type: bug | Status: new Priority: lowest | Milestone: Component: Core Libraries | Version: 6.13 Resolution: | Keywords: GMP,integer- | gmp, sharedlibs Operating System: FreeBSD | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #8156 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by arrowd): There are no bindists for FreeBSD anymore. What should be done to bring them back? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 17:52:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 17:52:51 -0000 Subject: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections In-Reply-To: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> References: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> Message-ID: <060.d72f5c2c67c9e3786e9c2b44cf51d75d@haskell.org> #7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.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 simonmar): I can't off-hand think of a reason why no-stable-name-table wouldn't work. Seems reasonable to me. A per-generation hash table is tricky because each entry is associated with two heap objects: the key and the `StableName` object, which may be in different generations. The hash table is keyed by the key (we really need a different name for that), so obviously it's the `StableName` object that might reside in a different generation. You would probably need something like a remembered set, to remember which hash table entries point to a StableName in a younger generation and therefore might need updating during a young-gen collection. I'm sure that's not the only design though. It's worth considering that you could do no-stable-name-table without per- generation hash tables, as an intermediate step. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 19:20:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 19:20:29 -0000 Subject: [GHC] #15059: ghcpkg05 fails In-Reply-To: <046.1f7d576a8754e183a4eb98c291d7d3d3@haskell.org> References: <046.1f7d576a8754e183a4eb98c291d7d3d3@haskell.org> Message-ID: <061.a1b1f40b26ec2ce8505778b0a1801bb5@haskell.org> #15059: ghcpkg05 fails -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 Comment: Bumping off to 8.8. Will close if it doesn't pop up again before the 8.8 release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 19:22:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 19:22:57 -0000 Subject: [GHC] #15293: Set up staging branch In-Reply-To: <046.acfc865b41ac65a2d16c8050d16d16b4@haskell.org> References: <046.acfc865b41ac65a2d16c8050d16d16b4@haskell.org> Message-ID: <061.74434555f597bf6a16d800a88837cd38@haskell.org> #15293: Set up staging branch -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: highest | Milestone: 8.8.1 Component: Continuous | Version: 8.4.3 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 Comment: This has largely been done although we are waiting to deploy until wee have switched away from Rackspace; this will likely happen this fall. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 19:28:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 19:28:57 -0000 Subject: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections In-Reply-To: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> References: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> Message-ID: <060.7be51888e106fa9cab2ca15c37184f95@haskell.org> #7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.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 dfeuer): You must have missed my edit where I describe such a "remembered set". When there are only two generations, there's only one such, and it can even be a static array (whose size is limited to a fixed fraction of the nursery size). When there are more generations, there are more options and they get harder to think about. Perhaps the way to start is with one hash table for underlying objects in the nursery and one for those in all other generations. I suspect that will give us a lot of the benefits with very few complications. My challenge is that I know very little about the details of garbage collection, so I don't really know how to write this stuff properly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 19:36:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 19:36:04 -0000 Subject: [GHC] #14899: Significant compilation time regression between 8.4 and HEAD due to coverage checking In-Reply-To: <050.9e589019d6eb1fc4987004e5aa20a3e4@haskell.org> References: <050.9e589019d6eb1fc4987004e5aa20a3e4@haskell.org> Message-ID: <065.5e047d11bea3e9cf65ad694e63eaf5fa@haskell.org> #14899: Significant compilation time regression between 8.4 and HEAD due to coverage checking -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 Comment: Unfortunately the summary here suggests that the status quo isn't acceptable for release but the future direction is rather unclear. I can see a few possibilities: 1. Teach the coverage checker to bail out (with a warning) if it sees a "large" pattern of this form 2. Allow a TH splice to explicitly request that coverage checking be disabled. This seems like a 3. Add a new `FromTH` `Origin` and a flag allowing the user to choose whether to run the coverage checker on TH splices. 4. Advise users to disable coverage checking in any module affected by the bug 5. Revert ffb2738f86c4e4c3f0eaacf0a95d7326fdd2e383 for 8.6 Frankly, all of these options seem pretty terrible given that this pattern is problematic only due to a (hopefully temporary) limitation of the coverage checker. That being said, we clearly need to do something for 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 19:36:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 19:36:11 -0000 Subject: [GHC] #15546: Display coaxiom branch incompatibilities in GHCi In-Reply-To: <044.c77ffe997f2d99b3fbec7a544251677f@haskell.org> References: <044.c77ffe997f2d99b3fbec7a544251677f@haskell.org> Message-ID: <059.62028d1ce87ee5730139ad108a74d060@haskell.org> #15546: Display coaxiom branch incompatibilities in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: TypeFamilies, | GHCi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D5097 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mniip): * owner: (none) => mniip * differential: => D5097 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 19:38:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 19:38:24 -0000 Subject: [GHC] #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' In-Reply-To: <047.e2e05ed138c24fadcd4842fa8e08b91d@haskell.org> References: <047.e2e05ed138c24fadcd4842fa8e08b91d@haskell.org> Message-ID: <062.3fadb2a2272f53c151a876cb954ceace@haskell.org> #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' ---------------------------------+---------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): goldfire, have you seen this with 8.6? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 19:39:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 19:39:18 -0000 Subject: [GHC] #15390: Figure out why CircleCI isn't generating haddocks In-Reply-To: <046.f1394806f5334f184ba374fa296a287b@haskell.org> References: <046.f1394806f5334f184ba374fa296a287b@haskell.org> Message-ID: <061.4e372ebb65ccd1f92d7b274f78e154ce@haskell.org> #15390: Figure out why CircleCI isn't generating haddocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: closed Priority: highest | Milestone: 8.6.1 Component: Continuous | Version: 8.4.3 Integration | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This has been sorted out in 9f937142f6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 19:39:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 19:39:41 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation In-Reply-To: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> References: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> Message-ID: <061.d1b5cacc210172b433f6a6b61abf8e9b@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: infoneeded Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded * milestone: 8.6.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 19:40:30 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 19:40:30 -0000 Subject: [GHC] #14506: Configure Harbormaster to trigger CircleCI builds In-Reply-To: <046.9f61d9ef87c94b26144834dd33459a90@haskell.org> References: <046.9f61d9ef87c94b26144834dd33459a90@haskell.org> Message-ID: <061.e1cebdcf33dfd780d2a4045b93f7f83a@haskell.org> #14506: Configure Harbormaster to trigger CircleCI builds -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Continuous | Version: 8.2.1 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 Comment: As indicated in comment:4 there has been motion here. However, we are currently blocked on the move away from Rackspace to deploy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 19:41:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 19:41:28 -0000 Subject: [GHC] #15176: Superclass `Monad m =>` makes program run 100 times slower In-Reply-To: <046.1ae5a16457a25527a576b82200e29a09@haskell.org> References: <046.1ae5a16457a25527a576b82200e29a09@haskell.org> Message-ID: <061.e7a271fa5e963ba8a74894ee5ed9e416@haskell.org> #15176: Superclass `Monad m =>` makes program run 100 times slower -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 Comment: This is still waiting on a suitable block of my time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 19:42:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 19:42:39 -0000 Subject: [GHC] #15546: Display coaxiom branch incompatibilities in GHCi In-Reply-To: <044.c77ffe997f2d99b3fbec7a544251677f@haskell.org> References: <044.c77ffe997f2d99b3fbec7a544251677f@haskell.org> Message-ID: <059.57e9c8cde021096031d5c3b53d0a139a@haskell.org> #15546: Display coaxiom branch incompatibilities in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: TypeFamilies, | GHCi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5097 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mniip): * differential: D5097 => Phab:D5097 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 19:57:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 19:57:21 -0000 Subject: [GHC] #15350: gcdExtInteger violates assertion In-Reply-To: <047.463f72a51535cf21b879b51cdb0841bf@haskell.org> References: <047.463f72a51535cf21b879b51cdb0841bf@haskell.org> Message-ID: <062.8557375c323ce2cc5a664024d075bfef@haskell.org> #15350: gcdExtInteger violates assertion -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: Bodigrim Type: bug | Status: closed Priority: high | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5042 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 19:58:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 19:58:08 -0000 Subject: [GHC] #15482: the_gc_thread variable from GC.c is not aligned to 64 In-Reply-To: <045.517cd029a074e1225f6142d10f834f62@haskell.org> References: <045.517cd029a074e1225f6142d10f834f62@haskell.org> Message-ID: <060.618e21b8012a0b5b9b195267850c1271@haskell.org> #15482: the_gc_thread variable from GC.c is not aligned to 64 -------------------------------------+------------------------------------- Reporter: arrowd | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5052 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with c3e50b053cd49c465bfd2d095e3f681510993d2b. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 20:01:30 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 20:01:30 -0000 Subject: [GHC] #14973: Location in GHCi debugger prompt printed twice when default prompt is used In-Reply-To: <043.77b079247cf81e1c9a49efb3c90c1743@haskell.org> References: <043.77b079247cf81e1c9a49efb3c90c1743@haskell.org> Message-ID: <058.89a25ba4272f518fea2723b33b1a86ec@haskell.org> #14973: Location in GHCi debugger prompt printed twice when default prompt is used -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.5 Resolution: fixed | Keywords: debugger Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4661 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: 4293a80a is already present in `ghc-8.6`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 20:02:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 20:02:11 -0000 Subject: [GHC] #15087: Internal Error with Bibliography Profiling In-Reply-To: <047.4e3533cfbf44e6814004409e34e96335@haskell.org> References: <047.4e3533cfbf44e6814004409e34e96335@haskell.org> Message-ID: <062.97153f0ccfdc327e1c91b527dadf13a7@haskell.org> #15087: Internal Error with Bibliography Profiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15063, #15165, | Differential Rev(s): Phab:D4928 #7836 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 30a4bcc3fc3a434b3b6ab64289934281591ce09a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 20:02:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 20:02:32 -0000 Subject: [GHC] #15165: GHC 8.2.2: internal error with +RTS -hb In-Reply-To: <043.05bd633e0b8fc1db67420a68577349a9@haskell.org> References: <043.05bd633e0b8fc1db67420a68577349a9@haskell.org> Message-ID: <058.4fc0c5036de0d234aab3cc369bec4734@haskell.org> #15165: GHC 8.2.2: internal error with +RTS -hb -------------------------------------+------------------------------------- Reporter: kfiz | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Profiling | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15063, #15087, | Differential Rev(s): Phab:D4928 #7836 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 30a4bcc3fc3a434b3b6ab64289934281591ce09a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 20:03:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 20:03:22 -0000 Subject: [GHC] #15213: 32 bit Haddock runs out of memory compiling 32 bit GHC In-Reply-To: <044.953b3633442fb5d6beadb7e79e6f44ca@haskell.org> References: <044.953b3633442fb5d6beadb7e79e6f44ca@haskell.org> Message-ID: <059.5fcc65dab4bcc6cc303dc606c4d86fdd@haskell.org> #15213: 32 bit Haddock runs out of memory compiling 32 bit GHC ----------------------------------------+---------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5003 Wiki Page: | ----------------------------------------+---------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 18cb44dfae3f0847447da33c9d7a25d2709d838f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 20:04:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 20:04:19 -0000 Subject: [GHC] #15269: Qualified Names in --show-iface output In-Reply-To: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> References: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> Message-ID: <061.6f3452bbca6ef0e38b3d910ddb8cb542@haskell.org> #15269: Qualified Names in --show-iface output -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature request | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4852 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Sure, it's simple enough and useful while debugging. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 20:05:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 20:05:44 -0000 Subject: [GHC] #15517: -O0 and pattern synonyms triggers panic in trimJoinCont In-Reply-To: <046.8e85deab87c1c94bb06eaa4a95b7f658@haskell.org> References: <046.8e85deab87c1c94bb06eaa4a95b7f658@haskell.org> Message-ID: <061.f97dc30bd606d4744045039cca6c506b@haskell.org> #15517: -O0 and pattern synonyms triggers panic in trimJoinCont -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | simplCore/should_compile/T15517, | T15517a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * milestone: 8.6.1 => 8.8.1 Comment: Merged with b81fc821597cb7578f93cbea772304f1effd46cf. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 20:07:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 20:07:15 -0000 Subject: [GHC] #15535: Expose the StableName constructor In-Reply-To: <045.6f45bd0659fffa92c0b169d118d7bd0a@haskell.org> References: <045.6f45bd0659fffa92c0b169d118d7bd0a@haskell.org> Message-ID: <060.01e0f69e080552e8f840c8b1e1ebcbb7@haskell.org> #15535: Expose the StableName constructor -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: merge Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5078 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Yes, I suppose we can do this given that it only touches the `GHC` namespace. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 20:09:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 20:09:10 -0000 Subject: [GHC] #15442: GhcStage3HcOpts passed to ghc-stage1 In-Reply-To: <046.95a723aa50c2e570df3f28b2b19c6980@haskell.org> References: <046.95a723aa50c2e570df3f28b2b19c6980@haskell.org> Message-ID: <061.fda4ef0e46f1d82bf1b3f59db4f794f9@haskell.org> #15442: GhcStage3HcOpts passed to ghc-stage1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Build System | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.8.1 Comment: Sadly I won't have time to look into this for 8.6. I suspect we'll likely just end up fixing it in Hadrian. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 21:12:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 21:12:44 -0000 Subject: [GHC] #9688: Improve the interaction between CSE and the join point transformation In-Reply-To: <045.ad5940048773c77749dabb4d904f5fb8@haskell.org> References: <045.ad5940048773c77749dabb4d904f5fb8@haskell.org> Message-ID: <060.96d1ac42a1bca920f1feea43fa5124a2@haskell.org> #9688: Improve the interaction between CSE and the join point transformation -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: CSE, | JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * cc: AndreasK (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 21:16:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 21:16:11 -0000 Subject: [GHC] #15501: Fix unknown symbols/addresses in perf output In-Reply-To: <045.068b84fc1146deb53c7717bbca530550@haskell.org> References: <045.068b84fc1146deb53c7717bbca530550@haskell.org> Message-ID: <060.90ae45431a22702647b6c4e98fd7b3e2@haskell.org> #15501: Fix unknown symbols/addresses in perf output -------------------------------------+------------------------------------- Reporter: last_g | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research Component: Compiler | needed (CodeGen) | Version: 8.5 Resolution: | Keywords: perf, | symbols, elf, linux Operating System: Linux | Architecture: Type of failure: Debugging | Unknown/Multiple information is incorrect | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D4713 Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > After https://phabricator.haskell.org/D4713 will be merged some addresses > in perf output won't be mapped to the symbols. > This needs investigation and fix. > > A draft idea about the root cause: > > The issue comes from the current perf symbolization algorithm. > > The basic logic is (kind of) simple: > > # Take all the @function symbols and put into a sorted list; > # the next steps are a hack to support handwritten assembly > # Take all the NOTYPE symbols with the size equals to 0 and put into the > same ordered list; > # Run the symbols__fixup_end procedure which sets a symbol end address to > be the beginning of the next symbol for every 0 sized symbol; > # If the last symbol is zero sized: set its size to be ~4k. > (The actual logic is more complicated because it also involves > sections&map groups) > > In GHC compiled binaries there are no @function symbols and most internal > symbols are NOTYPE and 0 sized so we are ending up in the hack's code. > > This logic effectively means that every address in our code space is > attributed to some internal symbol (correct or not). Adding @function > symbols with size directive stops this from happening. > As the first guess, those addresses can come from _con_info entries which > we don't mark as @function but in that case, there should be no unknown > addresses in D4730 but we have some there too. New description: After https://phabricator.haskell.org/D4713 will be merged some addresses in perf output won't be mapped to the symbols. This needs investigation and fix. A draft idea about the root cause: The issue comes from the current perf symbolization algorithm. The basic logic is (kind of) simple: {{{ # Take all the @function symbols and put into a sorted list; # the next steps are a hack to support handwritten assembly # Take all the NOTYPE symbols with the size equals to 0 and put into the same ordered list; # Run the symbols__fixup_end procedure which sets a symbol end address to be the beginning of the next symbol for every 0 sized symbol; # If the last symbol is zero sized: set its size to be ~4k. (The actual logic is more complicated because it also involves sections&map groups) }}} In GHC compiled binaries there are no @function symbols and most internal symbols are NOTYPE and 0 sized so we are ending up in the hack's code. This logic effectively means that every address in our code space is attributed to some internal symbol (correct or not). Adding @function symbols with size directive stops this from happening. As the first guess, those addresses can come from _con_info entries which we don't mark as @function but in that case, there should be no unknown addresses in D4730 but we have some there too. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 21:22:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 21:22:16 -0000 Subject: [GHC] #14012: External interpreter fails on FreeBSD In-Reply-To: <046.2b65587ea7267566cfeb67b314c36291@haskell.org> References: <046.2b65587ea7267566cfeb67b314c36291@haskell.org> Message-ID: <061.a1a667b08c67ca0a92065eff67cc5c68@haskell.org> #14012: External interpreter fails on FreeBSD ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: RemoteGHCi Operating System: FreeBSD | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): Possibly; I'll need to check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 21:35:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 21:35:32 -0000 Subject: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections In-Reply-To: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> References: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> Message-ID: <060.8c3f8d4581e4da761863815c4fd73403@haskell.org> #7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.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 dfeuer): Another thing: we don't really want to have to allocate memory dynamically for the nursery hash table. Ideally, it would be backed by a fixed array to avoid memory management overhead. The non-nursery hash table can be a bit more expensive to maintain, since it only gets replaced during major collections. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 21:45:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 21:45:05 -0000 Subject: [GHC] #15560: Full laziness destroys opportunities for join points Message-ID: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> #15560: Full laziness destroys opportunities for join points -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14287 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Even if we already know a binding is a join point we STILL float it to the top and turn it into a function. The simple example below results in a join point after the first simplifier run. Then we run the float out pass immediately undoing this by making it a top level binding. It then stays at the top till we are done resulting in the core I've put in the comments. {{{ #!haskell data T = A | B | C | D | E | F | G {-# NOINLINE n #-} n :: T -> T n A = B n B = C n _ = A f :: Int -> T -> T -> T f sel x y = -- function large enough to avoid being simply inlined let j z = n . n . n . n . n . n $ z in case sel of -- j is always tailcalled 0 -> j x _ -> j y -- j is floated to top level instead of ending up as joinpoint. -- T.f_j -- = \ (eta_B1 [OS=OneShot] :: T) -> n (n (n (n (n (n eta_B1))))) -- -- RHS size: {terms: 14, types: 6, coercions: 0, joins: 0/0} -- f :: Int -> T -> T -> T -- f = \ (sel_aYP :: Int) (x_aYQ :: T) (y_aYR :: T) -> -- case sel_aYP of { GHC.Types.I# ds_d2fL -> -- case ds_d2fL of { -- __DEFAULT -> T.f_j y_aYR; -- 0# -> T.f_j x_aYQ -- } -- } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 21:55:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 21:55:15 -0000 Subject: [GHC] #15560: Full laziness destroys opportunities for join points In-Reply-To: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> References: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> Message-ID: <062.c705c23b8ef167f9f29b47e525176ea1@haskell.org> #15560: Full laziness destroys opportunities for join points -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14287 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Generally, I think we should not float join points -- in general floating them will stop them being join points. It'd be easy to change `SetLevels` thus -- but intuition is a poor guide and it'd be really worth trying it and measuring the effect. However, if the binding can go all the way to the top level, then there seems no downside to floating it: we end up with a smaller (and hence perhaps more inlinable) function; and the jump to the join point is still a nice, efficient jump. What's not to like? (Your Description suggests that you think that doing so is Bad. Why?) All that said, there is a Huge Mess in `SetLevels` around join points with stuff about the "join ceiling". I want to expunge all that, but have lacked the time. The trouble is that we do want some limited, local floating -- I have a whole WIP tree pending on that, but it's in limbo. If anyone would like to work on this, I'll commit my WIP to a branch and offer advice/support on taking it forward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 22:08:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 22:08:55 -0000 Subject: [GHC] #15560: Full laziness destroys opportunities for join points In-Reply-To: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> References: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> Message-ID: <062.e2edf0e7df29077d6818dbdec148e9f0@haskell.org> #15560: Full laziness destroys opportunities for join points -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14287 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): > However, if the binding can go all the way to the top level, then there seems no downside to floating it: we end up with a smaller (and hence perhaps more inlinable) function; and the jump to the join point is still a nice, efficient jump. What's not to like? There are no top level join points as far as I know. (I might be mistaken though?) Turning them into a top level binding means the calling convention changes into the same that is used with regular functions. So we have the overhead of register saving, stack checks, layout penalty, the works. Limiting them to the top of the RHS instead seems like an advantage. Maybe that should already happen and I just hit a bug there? I haven't looked too far into the SetLevel machinery. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 22:34:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 22:34:16 -0000 Subject: [GHC] #14506: Configure Harbormaster to trigger CircleCI builds In-Reply-To: <046.9f61d9ef87c94b26144834dd33459a90@haskell.org> References: <046.9f61d9ef87c94b26144834dd33459a90@haskell.org> Message-ID: <061.716bdc0348ed08298f8e40ac17c54209@haskell.org> #14506: Configure Harbormaster to trigger CircleCI builds -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Continuous | Version: 8.2.1 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Why does the bridge poll CircleCI to work out the build status rather than CircleCI reporting directly back to phab or at least reporting to the bridge when there is a status update? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 22:47:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 22:47:16 -0000 Subject: [GHC] #15561: TypeInType: Type error conditioned on ordering of GADT and type family definitions Message-ID: <044.c6bf48ac2fb309fb3e7c35891aadba68@haskell.org> #15561: TypeInType: Type error conditioned on ordering of GADT and type family definitions -------------------------------------+------------------------------------- Reporter: Bj0rn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: TypeInType, | Operating System: Unknown/Multiple TypeFamilies, GADTs | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this code which successfully compiles: {{{#!hs {-# LANGUAGE TypeInType, TypeFamilies, GADTs #-} module Bug where class HasIndex a where type Index a emptyIndex :: IndexWrapper a instance HasIndex [a] where type Index [a] = Int emptyIndex = Wrap 0 data IndexWrapper a where Wrap :: Index a -> IndexWrapper a type family UnwrapAnyWrapperLikeThing (a :: t) :: k type instance UnwrapAnyWrapperLikeThing ('Wrap a :: IndexWrapper [b]) = a }}} The mere act of moving the definition of `IndexWrapper` anywhere below the definition of `UnwrapAnyWrapperLikeThing` makes the type family instance at the bottom of the example fail compilation, with this error: {{{ Bug.hs:17:15: error: • Illegal type synonym family application in instance: Index [b] • In the type instance declaration for ‘UnwrapAnyWrapperLikeThing’ | 17 | type instance UnwrapAnyWrapperLikeThing ('Wrap a :: IndexWrapper [b]) = a | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} This is the smallest example that I could come up with; my real scenario of course has more things going on, but I can share if it would help. The problem for me (other than that I'm pretty sure reordering definitions in Haskell should never affect anything) is that I would like just the definition of the type family (`UnwrapAnyWrapperLikeThing` in this example) in module `A` and all of the other definitions in module `B` that imports `A`. Ideally, I would have liked to add a `HasIndex a` constraint to the `Wrap` constructor, but that disqualifies use of `'Wrap` on the type level. This does make me feel like I'm on shaky ground to begin with. I have reproduced this bug on 8.2.2, 8.4.3 and 8.6.0.20180810 (NixOS). I should note that 8.0.2 rejects even the code that I pasted here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 22:52:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 22:52:32 -0000 Subject: [GHC] #15473: GHC 8.6+ loops infinitely on an UndecidableInstances error message In-Reply-To: <050.0e1359f1570b3b8da9f1e08c07e4c7b6@haskell.org> References: <050.0e1359f1570b3b8da9f1e08c07e4c7b6@haskell.org> Message-ID: <065.12e526e424532624b45dbaff90c62760@haskell.org> #15473: GHC 8.6+ loops infinitely on an UndecidableInstances error message -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | typecheck/should_compile/T15473 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: All merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 22:53:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 22:53:24 -0000 Subject: [GHC] #11474: incorrect redundant-constraints warning In-Reply-To: <042.2e15408ecc3253cf7591957da36697cd@haskell.org> References: <042.2e15408ecc3253cf7591957da36697cd@haskell.org> Message-ID: <057.6bc3d3a05fd697d3f99a6cb4850ad50d@haskell.org> #11474: incorrect redundant-constraints warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | tests/typecheck/should_compile/T11474.hs Blocked By: | Blocking: Related Tickets: #10100 | Differential Rev(s): Phab:D4739 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged in 02829747cdf72fe83e511232cef12cd01df5dce6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 22:53:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 22:53:42 -0000 Subject: [GHC] #15269: Qualified Names in --show-iface output In-Reply-To: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> References: <046.9c9db94f7af907089e8c0a7271f2099c@haskell.org> Message-ID: <061.26870edc67165b17971d2853396ecc23@haskell.org> #15269: Qualified Names in --show-iface output -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4852 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged in c69c9d399746966f5d4ffbf73f49cd768a097dbd. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 22:54:03 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 22:54:03 -0000 Subject: [GHC] #15361: Error message displays redundant equality constraint In-Reply-To: <050.41dbf0633f06cf78daba7d213be8b850@haskell.org> References: <050.41dbf0633f06cf78daba7d213be8b850@haskell.org> Message-ID: <065.ca7cc5a58026c57760ecdf37d11b45a7@haskell.org> #15361: Error message displays redundant equality constraint -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14394 | Differential Rev(s): Phab:D5002 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged in 89ad5fed345d54ed73ecb3057346f3ef81864c8c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 22:54:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 22:54:34 -0000 Subject: [GHC] #15518: -ddump-splices pretty-prints LambdaCase nonsensically In-Reply-To: <050.995ed236da7a975a0b6882f1ba885e96@haskell.org> References: <050.995ed236da7a975a0b6882f1ba885e96@haskell.org> Message-ID: <065.660ef7609d956198f16725e93ddaa8f8@haskell.org> #15518: -ddump-splices pretty-prints LambdaCase nonsensically -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5069 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with e57a15d820b44751fcfc14c056ae284caab697a6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 22:55:12 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 22:55:12 -0000 Subject: [GHC] #15535: Expose the StableName constructor In-Reply-To: <045.6f45bd0659fffa92c0b169d118d7bd0a@haskell.org> References: <045.6f45bd0659fffa92c0b169d118d7bd0a@haskell.org> Message-ID: <060.0ecb3c85165795b45e285ca381e15c43@haskell.org> #15535: Expose the StableName constructor -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5078 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged in 768cc53d73e46954b01df69c6b215a41b3533f56. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 22:58:12 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 22:58:12 -0000 Subject: [GHC] #15561: TypeInType: Type error conditioned on ordering of GADT and type family definitions In-Reply-To: <044.c6bf48ac2fb309fb3e7c35891aadba68@haskell.org> References: <044.c6bf48ac2fb309fb3e7c35891aadba68@haskell.org> Message-ID: <059.97937e79acd13cc746dd0d4f030b4593@haskell.org> #15561: TypeInType: Type error conditioned on ordering of GADT and type family definitions -------------------------------------+------------------------------------- Reporter: Bj0rn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: TypeInType, | TypeFamilies, GADTs 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 mpickering): Perhaps related to #12088 and https://ghc.haskell.org/trac/ghc/wiki/InterleavingTypeInstanceChecking -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 23:30:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 23:30:28 -0000 Subject: [GHC] #605: Optimisation: strict enumerations In-Reply-To: <047.930f12dd9816334e7bac59b319734f38@haskell.org> References: <047.930f12dd9816334e7bac59b319734f38@haskell.org> Message-ID: <062.bf1ebcae0f4cf786b0ecbb6d12031db8@haskell.org> #605: Optimisation: strict enumerations -------------------------------------+------------------------------------- Reporter: simonmar | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: None Resolution: None | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: Related Tickets: #6135 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 23 23:41:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Aug 2018 23:41:23 -0000 Subject: [GHC] #849: Offer control over branch prediction In-Reply-To: <046.9c1a3dec0191543ee72b98b43c5f5f89@haskell.org> References: <046.9c1a3dec0191543ee72b98b43c5f5f89@haskell.org> Message-ID: <061.447d2468acd2e36e6c667ea86582a746@haskell.org> #849: Offer control over branch prediction -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: N/A Blocked By: | Blocking: Related Tickets: #14672 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 00:19:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 00:19:52 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation In-Reply-To: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> References: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> Message-ID: <061.8177088f33757c1766d247248bc16b6f@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: infoneeded Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by danilo2): @simonpj I removed Criterion as dependency here and get the same results. Compile it and pass the resulting eecutable a number - `0`, `1` or `2` to execute `test0`, `test1` or `test2` respectively. https://github.com/wdanilo/ghc-bug-peg- optimization/blob/master/src/Main.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 00:42:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 00:42:20 -0000 Subject: [GHC] #855: Improvements to SpecConstr In-Reply-To: <046.89327e0966303574a45f2952dca0e6f5@haskell.org> References: <046.89327e0966303574a45f2952dca0e6f5@haskell.org> Message-ID: <061.27a5a86eb0b2f3879d6c7015a7b2ee63@haskell.org> #855: Improvements to SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: N/A Blocked By: | Blocking: 915 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 00:56:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 00:56:05 -0000 Subject: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections In-Reply-To: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> References: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> Message-ID: <060.729007a70c551f7781355f4fbca7a435@haskell.org> #7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.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 dfeuer): Ah, now I think I understand what you mean about per-capability tables. One hash table for the nursery associated with each capability. Assuming it's cheap to determine which nursery the underlying object pointer is in (if it is in one), we can perform the lookup/insertion in the matching hash table. Since it's rare to create a stable name for an object in another thread's nursery, there will be very little contention for the nursery table locks. Side note: if we do implement the generational scheme, we'll want to edit the users' guide to note that it's somewhat more efficient to create a stable name for an object very soon after the object is created than to do so later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 00:57:04 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 00:57:04 -0000 Subject: [GHC] #4022: GHC Bindist is Broken on FreeBSD/amd64 In-Reply-To: <042.be61d95849398bdf9c05d1a69af1e7e3@haskell.org> References: <042.be61d95849398bdf9c05d1a69af1e7e3@haskell.org> Message-ID: <057.ba8a0864de7192915a009210988fafdf@haskell.org> #4022: GHC Bindist is Broken on FreeBSD/amd64 -------------------------------------+------------------------------------- Reporter: pgj | Owner: pgj Type: bug | Status: new Priority: lowest | Milestone: Component: Core Libraries | Version: 6.13 Resolution: | Keywords: GMP,integer- | gmp, sharedlibs Operating System: FreeBSD | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #8156 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The FreeBSD bindists went on a bit of a hiatus while (a) we fixed GHC's FreeBSD support (the `unix` library had compatibility issues previously) and (b) we enable support in GHC's continuous integration infrastructure. However, (a) is now done and while (b) isn't quite there yet I will build a bindist manually for 8.6.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 02:34:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 02:34:22 -0000 Subject: [GHC] #15559: fromJust has no HasCallStack In-Reply-To: <046.0c0fc309394993486a792a626e8db1e1@haskell.org> References: <046.0c0fc309394993486a792a626e8db1e1@haskell.org> Message-ID: <061.e700d4bd9eb80aa3157acb31dd155f4f@haskell.org> #15559: fromJust has no HasCallStack -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => newcomer Comment: Sure, this seems like a good task for a newcomer. However, I should emphasize to that we don't want to simply scatter `HasCallStack`s on every partial function. We should be thoughtful and deliberate (and probably consult with the CLC) when making changes like this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 03:13:51 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 03:13:51 -0000 Subject: [GHC] #12695: Build failure due to MAP_NORESERVE being removed in FreeBSD 11.x and later In-Reply-To: <043.b25e91253b49ad08042d636adf423d59@haskell.org> References: <043.b25e91253b49ad08042d636adf423d59@haskell.org> Message-ID: <058.c6409c3a7ecc436b4d8d67484c067c77@haskell.org> #12695: Build failure due to MAP_NORESERVE being removed in FreeBSD 11.x and later -------------------------------------+------------------------------------- Reporter: abbe | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: FreeBSD | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #15348 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * related: => #15348 * milestone: => 8.6.1 Comment: Note that the two-step allocator is now supported on FreeBSD. See #15348. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 03:24:49 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 03:24:49 -0000 Subject: [GHC] #15525: Unicode 8.0 and later characters are invariably lexical errors In-Reply-To: <047.28ba0e189446e80c83f61ac8574b1084@haskell.org> References: <047.28ba0e189446e80c83f61ac8574b1084@haskell.org> Message-ID: <062.2cd9fddbb94c0c8b51de9cbff64160e3@haskell.org> #15525: Unicode 8.0 and later characters are invariably lexical errors -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Parser) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5518 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"14d88380ecb909e7032598aaad4efebb72561784/ghc" 14d88380/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="14d88380ecb909e7032598aaad4efebb72561784" Update unicode tables to v. 12 of the standard Reviewers: hvr, bgamari, Azel Reviewed By: bgamari Subscribers: thomie, Azel, rwbarton, carter GHC Trac Issues: #5518, #15525 Differential Revision: https://phabricator.haskell.org/D5066 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 03:24:49 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 03:24:49 -0000 Subject: [GHC] #5518: Some unicode symbols are not allow in literal characters or strings In-Reply-To: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> References: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> Message-ID: <059.7facd73dcab410f1726beacf78803fb1@haskell.org> #5518: Some unicode symbols are not allow in literal characters or strings ---------------------------------+-------------------------------------- Reporter: ertai | Owner: ulysses4ever Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5066 Wiki Page: | ---------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"14d88380ecb909e7032598aaad4efebb72561784/ghc" 14d88380/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="14d88380ecb909e7032598aaad4efebb72561784" Update unicode tables to v. 12 of the standard Reviewers: hvr, bgamari, Azel Reviewed By: bgamari Subscribers: thomie, Azel, rwbarton, carter GHC Trac Issues: #5518, #15525 Differential Revision: https://phabricator.haskell.org/D5066 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 09:52:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 09:52:10 -0000 Subject: [GHC] #15561: TypeInType: Type error conditioned on ordering of GADT and type family definitions In-Reply-To: <044.c6bf48ac2fb309fb3e7c35891aadba68@haskell.org> References: <044.c6bf48ac2fb309fb3e7c35891aadba68@haskell.org> Message-ID: <059.725a880004c9ed937d5a93277b381f95@haskell.org> #15561: TypeInType: Type error conditioned on ordering of GADT and type family definitions -------------------------------------+------------------------------------- Reporter: Bj0rn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: TypeInType, | TypeFamilies, GADTs 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): Yes, I think it's #12088 again. Here is what I think is going on. * The declaration {{{ type instance UnwrapAnyWrapperLikeThing ('Wrap a :: IndexWrapper [b]) = a }}} mentions `IndexWrapper`, so the latter must be typechecked first (and it is). * `IndexWrapper` is mutually recursive with `HasIndex` and `Index`, so they must be typechecked together (and they are). * Returning to {{{ type instance UnwrapAnyWrapperLikeThing ('Wrap a :: IndexWrapper [b]) = a }}} we can see that `a :: Index [b]`. Now, if we have already processed {{{ instance HasIndex [a] where type Index [a] = Int }}} then that mens `a :: Int`, and all is well. (This does involve some type family reduction in the patterns of a `type instance`. Where does that happen?) * But if we have not yet processed the instance for `HasIndex` then we complain that the LHS {{{ type instance UnwrapAnyWrapperLikeThing ('Wrap (a :: Index [b]) :: IndexWrapper [b]) = a }}} mentions `Index [b]` on the LHS. For now, a robust solution is to force GHC to deal with the instance of `HasIndex` first,(mis)-using a Template Haskell splice. For example, this compiles fine, but fails if you remove the splice {{{ type family UnwrapAnyWrapperLikeThing (a :: t) :: k class HasIndex a where type Index a emptyIndex :: IndexWrapper a data IndexWrapper a where Wrap :: Index a -> IndexWrapper a instance HasIndex [a] where type Index [a] = Int emptyIndex = Wrap 0 $([d| |]) -- Empty Template Haskell top level splice type instance UnwrapAnyWrapperLikeThing ('Wrap a :: IndexWrapper [b]) = a }}} More grist for the #12088 mill! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 09:54:42 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 09:54:42 -0000 Subject: [GHC] #12088: Type/data family instances in kind checking In-Reply-To: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> References: <048.155fdb7e7ce6e09c92258c376a6950ab@haskell.org> Message-ID: <063.82171ee74a15b8af758afcdeed1e1a11@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: TypeInType, Resolution: | CUSKs Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348, #12239, | Differential Rev(s): Phab:D2272 #12643, #13790, #15561 | Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/InterleavingTypeInstanceChecking| -------------------------------------+------------------------------------- Changes (by simonpj): * wikipage: https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference => https://ghc.haskell.org/trac/ghc/wiki/InterleavingTypeInstanceChecking * related: #11348, #12239, #12643, #13790 => #11348, #12239, #12643, #13790, #15561 Comment: See also #15561 for another example -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 09:55:42 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 09:55:42 -0000 Subject: [GHC] #15552: Infinite loop/panic with an existential type. In-Reply-To: <050.eb5168d400b4a4211e35d29d96945d09@haskell.org> References: <050.eb5168d400b4a4211e35d29d96945d09@haskell.org> Message-ID: <065.c632023f02d06016fb4a07ebc0d2afab@haskell.org> #15552: Infinite loop/panic with an existential type. -------------------------------------+------------------------------------- Reporter: howtonotwin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: TypeInType, | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14723 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"184a569c5f5fe6e2eed73b2cff35722918c44efd/ghc" 184a569c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="184a569c5f5fe6e2eed73b2cff35722918c44efd" Clean up TcHsSyn.zonkEnv Triggered by Trac #15552, I'd been looking at ZonkEnv in TcHsSyn. This patch does some minor refactoring * Make ZonkEnv into a record with named fields, and use them. (I'm planning to add a new field, for TyCons, so this prepares the way.) * Replace UnboundTyVarZonker (a higer order function) with the simpler and more self-descriptive ZonkFlexi data type, below. It's just much more perspicuous and direct, and (I suspect) a tiny bit faster too -- no unknown function calls. data ZonkFlexi -- See Note [Un-unified unification variables] = DefaultFlexi -- Default unbound unificaiton variables to Any | SkolemiseFlexi -- Skolemise unbound unification variables -- See Note [Zonking the LHS of a RULE] | RuntimeUnkFlexi -- Used in the GHCi debugger There was one knock-on effect in the GHCi debugger -- the RuntimeUnkFlexi case. Somehow previously, these RuntimeUnk variables were sometimes getting SystemNames (and hence printed as 'a0', 'a1', etc) and sometimes not (and hence printed as 'a', 'b' etc). I'm not sure precisely why, but the new behaviour seems more uniform, so I just accepted the (small) renaming wibbles in some ghci.debugger tests. I had a quick look at perf: any changes are tiny. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 09:55:42 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 09:55:42 -0000 Subject: [GHC] #15546: Display coaxiom branch incompatibilities in GHCi In-Reply-To: <044.c77ffe997f2d99b3fbec7a544251677f@haskell.org> References: <044.c77ffe997f2d99b3fbec7a544251677f@haskell.org> Message-ID: <059.6b005f7bec0166a11a3ea8fe6c07e218@haskell.org> #15546: Display coaxiom branch incompatibilities in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: TypeFamilies, | GHCi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5097 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"4b79329f24dfdf907f223ff9fc41c77d9df86e04/ghc" 4b79329f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4b79329f24dfdf907f223ff9fc41c77d9df86e04" Add comments about pretty-printing via IfaceSyn Provoked by discussion on Phab:D5097 (Trac #15546), I'm adding a big Note explaing the strategy of pretty-printing via IfaceSyn }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 09:56:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 09:56:58 -0000 Subject: [GHC] #15560: Full laziness destroys opportunities for join points In-Reply-To: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> References: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> Message-ID: <062.6c5e88d335228dc05c3396e405553e34@haskell.org> #15560: Full laziness destroys opportunities for join points -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14287 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Turning them into a top level binding means the calling convention changes into the same that is used with regular functions. So we have the overhead of register saving, stack checks, layout penalty, the works Can you be more specific. I think that the jumps to the join points will turn into jumps to the top-level function code, no arity checks nothing. You could look at the code and see, but I think it'll be no less efficient. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 10:21:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 10:21:28 -0000 Subject: [GHC] #15557: Reduce type families in equations' RHS when testing equation compatibility In-Reply-To: <044.c8824ce95594133c7a3e270ae939b58d@haskell.org> References: <044.c8824ce95594133c7a3e270ae939b58d@haskell.org> Message-ID: <059.8b3cc15c4a0f410369922c209dbb16c3@haskell.org> #15557: Reduce type families in equations' RHS when testing equation compatibility -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8423 #15546 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > That doesn't happen: I think you mean more than `:t` reports the wrong result. Consider {{{ f :: Proxy b -> Proxy b -> Int f = error "urk" g :: Proxy a -> Proxy (Test a a) -> Int g x y = f x y }}} This indeed fails with {{{ T15557.hs:25:13: error: • Couldn't match type ‘a’ with ‘Test a a’ }}} I'd need to look back carefully at the paper to see what should happen, but no time for that today. Richard may opine on his return. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 10:39:07 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 10:39:07 -0000 Subject: [GHC] #15562: `-XStrict -XNoStrict` is not neutral Message-ID: <042.ba188334cc4bb9cd167859c3f14e424e@haskell.org> #15562: `-XStrict -XNoStrict` is not neutral -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I assumed we already had a ticket about this, but it appears we have not. I'm not saying this is a necessarily a bug in the implementation; but we should make sure this is properly documented in the user's guide, and ideally justify why it's done this way rather than the alternatives: As described in StrictPragma, > `Strict` implies `StrictData` Currently however the inverse case does not hold, i.e. `NoStrict` does *not* imply `NoStrictData` This has the surprising property (assuming these were left-most flags on the CLI) that - `-XStrict -XNoStrict` == `-XStrictData` - `-XStrictData -XNoStrict` == `-XStrictData` However, if `-XNoStrict` was to naively imply `-XNoStrictData`, we'd have the properties - `-XStrict -XNoStrict` == *id* - `-XStrictData -XNoStrict` == *id* This might be a bit less confusing; another variant would be - `-XStrict -XNoStrict` == *id* - `-XStrictData -XNoStrict` == `-XStrictData` Btw, I'm not sure what the following means: - `-XStrict -XNoStrictData` == ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 10:42:21 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 10:42:21 -0000 Subject: [GHC] #15562: `-XStrict -XNoStrict` is not neutral In-Reply-To: <042.ba188334cc4bb9cd167859c3f14e424e@haskell.org> References: <042.ba188334cc4bb9cd167859c3f14e424e@haskell.org> Message-ID: <057.01e77dc9f35c10d2de9d51587e2a2757@haskell.org> #15562: `-XStrict -XNoStrict` is not neutral -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by hvr: Old description: > I assumed we already had a ticket about this, but it appears we have not. > > I'm not saying this is a necessarily a bug in the implementation; but we > should make sure this is properly documented in the user's guide, and > ideally justify why it's done this way rather than the alternatives: > > As described in StrictPragma, > > > `Strict` implies `StrictData` > > Currently however the inverse case does not hold, i.e. `NoStrict` does > *not* imply `NoStrictData` > > > This has the surprising property (assuming these were left-most flags on > the CLI) that > > - `-XStrict -XNoStrict` == `-XStrictData` > > - `-XStrictData -XNoStrict` == `-XStrictData` > > > However, if `-XNoStrict` was to naively imply `-XNoStrictData`, we'd have > the properties > > - `-XStrict -XNoStrict` == *id* > > - `-XStrictData -XNoStrict` == *id* > > This might be a bit less confusing; another variant would be > > - `-XStrict -XNoStrict` == *id* > > - `-XStrictData -XNoStrict` == `-XStrictData` > > Btw, I'm not sure what the following means: > > - `-XStrict -XNoStrictData` == ? New description: I assumed we already had a ticket about this, but it appears we have not. I'm not saying this is a necessarily a bug in the implementation; but we should make sure this is properly documented in the user's guide, and ideally justify why it's done this way rather than the alternatives: As described in StrictPragma, > `Strict` implies `StrictData` Currently however the inverse case does not hold, i.e. `NoStrict` does *not* imply `NoStrictData` This has the surprising property (assuming these were left-most flags on the CLI) that - `-XStrict -XNoStrict` == `-XStrictData` - `-XStrictData -XNoStrict` == `-XStrictData` However, if `-XNoStrict` was to naively imply `-XNoStrictData`, we'd have the properties - `-XStrict -XNoStrict` == ∅ - `-XStrictData -XNoStrict` == ∅ This might be a bit less confusing; another variant would be - `-XStrict -XNoStrict` == ∅ - `-XStrictData -XNoStrict` == `-XStrictData` (strictly speaking, it's not ∅ unless it's these are the left-most flags; also, any `-XNo` still has a cancellation effect on any flags occuring to the left on the CLI) Btw, I'm not sure what the following means: - `-XStrict -XNoStrictData` == ? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 11:40:07 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 11:40:07 -0000 Subject: [GHC] #15484: MultiLayerModules and T13701 timeout on i386 Linux In-Reply-To: <046.f49e8907dc2fd082faa408fb71333802@haskell.org> References: <046.f49e8907dc2fd082faa408fb71333802@haskell.org> Message-ID: <061.1e9c38492c462c96ba4a176a6a2d4f69@haskell.org> #15484: MultiLayerModules and T13701 timeout on i386 Linux -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): https://circleci.com/gh/ghc/ghc/8827 shows that on a recent commit from master (a little earlier this week), we still have those two failures, both timeouts. I guess I'll use an even higher multiplier for those. I'll put together a diff and then maybe try to use my circleci<->phab bridge to run an i386 validate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 11:53:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 11:53:44 -0000 Subject: [GHC] #15484: MultiLayerModules and T13701 timeout on i386 Linux In-Reply-To: <046.f49e8907dc2fd082faa408fb71333802@haskell.org> References: <046.f49e8907dc2fd082faa408fb71333802@haskell.org> Message-ID: <061.8420a811c6dfe0ed255594795e513a28@haskell.org> #15484: MultiLayerModules and T13701 timeout on i386 Linux -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:5103 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * status: new => patch * differential: => Phab:5103 Comment: Got a differential up, will now proceed to testing it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 12:00:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 12:00:58 -0000 Subject: [GHC] #15525: Unicode 8.0 and later characters are invariably lexical errors In-Reply-To: <047.28ba0e189446e80c83f61ac8574b1084@haskell.org> References: <047.28ba0e189446e80c83f61ac8574b1084@haskell.org> Message-ID: <062.2d2abcbfef04bfbc25e3970118c423ba@haskell.org> #15525: Unicode 8.0 and later characters are invariably lexical errors -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (Parser) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #5518 | Differential Rev(s): Phab:D5066 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ChaiTRex): * differential: => Phab:D5066 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 12:07:02 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 12:07:02 -0000 Subject: [GHC] #5518: Some unicode symbols are not allow in literal characters or strings In-Reply-To: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> References: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> Message-ID: <059.9eb62259a5e868baf35eb916e6adfb4b@haskell.org> #5518: Some unicode symbols are not allow in literal characters or strings ---------------------------------+-------------------------------------- Reporter: ertai | Owner: ulysses4ever Type: bug | Status: merge Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5066 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by ChaiTRex): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 12:24:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 12:24:52 -0000 Subject: [GHC] #15563: Typo in the documentation for Numeric.Natural. Message-ID: <042.7abd2e76bb8c52c1b059eca61d92e958@haskell.org> #15563: Typo in the documentation for Numeric.Natural. -------------------------------------+------------------------------------- Reporter: asr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The [https://downloads.haskell.org/~ghc/8.4.3/docs/html/libraries/base-4.11.1.0 /Numeric-Natural.html documentation] for `Numeric.Natural` says {{{ >>> 2^20 :: Natural 1267650600228229401496703205376 }}} Please replace the `20` by `100`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 13:08:18 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 13:08:18 -0000 Subject: [GHC] #15560: Full laziness destroys opportunities for join points In-Reply-To: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> References: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> Message-ID: <062.e556b90c05ef9580bbd16f5cc68276f5@haskell.org> #15560: Full laziness destroys opportunities for join points -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14287 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 13:13:08 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 13:13:08 -0000 Subject: [GHC] #5518: Some unicode symbols are not allow in literal characters or strings In-Reply-To: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> References: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> Message-ID: <059.6c2d6fe7d72625f0254535c004153c57@haskell.org> #5518: Some unicode symbols are not allow in literal characters or strings ---------------------------------+-------------------------------------- Reporter: ertai | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5066 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by ChaiTRex): * owner: ulysses4ever => (none) * status: merge => new Comment: Sorry, found out merge is only for 8.6.1 for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 13:13:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 13:13:55 -0000 Subject: [GHC] #5518: Some unicode symbols are not allow in literal characters or strings In-Reply-To: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> References: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> Message-ID: <059.55648f9c4915b0c2289f03ca87654e7e@haskell.org> #5518: Some unicode symbols are not allow in literal characters or strings ---------------------------------+-------------------------------------- Reporter: ertai | Owner: ulysses4ever Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5066 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by ChaiTRex): * owner: (none) => ulysses4ever -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 13:14:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 13:14:14 -0000 Subject: [GHC] #5518: Some unicode symbols are not allow in literal characters or strings In-Reply-To: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> References: <044.6fbadc432280f36044c2cd22497ebb12@haskell.org> Message-ID: <059.ee708436d61bc55a1bf1ba87c3d715ef@haskell.org> #5518: Some unicode symbols are not allow in literal characters or strings ---------------------------------+-------------------------------------- Reporter: ertai | Owner: ulysses4ever Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5066 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by ChaiTRex): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 13:22:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 13:22:59 -0000 Subject: [GHC] #15560: Full laziness destroys opportunities for join points In-Reply-To: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> References: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> Message-ID: <062.515832f9cc3670982f5a5a670c152269@haskell.org> #15560: Full laziness destroys opportunities for join points -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14287 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): If j becomes a top level binding we use the general calling convention. Which at the assembly level is still a jump as you said. However there are a subtle differences between jumping to top level bindings versus jumping into a basic block which can have a major performance impact. Things I can immediatly think of are: * If we jump a top level symbol we can't place the jump target immediately after the caller. This means we: * Can't eliminate one of the jump instructions, so they take up resource for branch prediction and need to be executed by the CPU. * The code won't be placed sequentially in memory leading to worse cache utilization. * Top level bindings require an additional info table compared to a regular jump target. This means more code size which is never a good thing. * Being a top level function that uses the stack `j` now performs a stack check. For very small functions this can be a lot of overhead. It's quite possible that in the general case more inlining is offsetting this cost, but in some cases this makes a major difference. For example the program below has ~7% speedup when disabling full laziness(780 vs 730ms). {{{ #!haskell --Simpler core to read without worker/wrapper {-# OPTIONS_GHC -fno-full-laziness -fno-worker-wrapper #-} {-# LANGUAGE MagicHash, BangPatterns #-} module Main where import System.Environment import GHC.Prim data T = A | B | C -- If we inline the functions case of known constructors kicks in. -- Which is good! But means j becomes small enough to be inlined -- and won't become an join point. So for this example we don't -- want that. {-# NOINLINE n #-} {-# NOINLINE f #-} n :: T -> T n A = B n B = C n _ = A toInt :: T -> Int toInt A = 1 toInt B = 2 toInt C = 3 f :: Int -> T -> T -> T f sel x y = -- function large enough to avoid being simply inlined let j z = n . n . n . n . n . n $ z in case sel of -- j is always tailcalled 0 -> j x _ -> j y main = do print $ sum . map toInt . map (\n -> f n A B) $ [0..50000000] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 13:35:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 13:35:56 -0000 Subject: [GHC] #15562: `-XStrict -XNoStrict` is not neutral In-Reply-To: <042.ba188334cc4bb9cd167859c3f14e424e@haskell.org> References: <042.ba188334cc4bb9cd167859c3f14e424e@haskell.org> Message-ID: <057.a75c7148c5c39cff4ec4ede55c7558d0@haskell.org> #15562: `-XStrict -XNoStrict` is not neutral -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I think this extends far beyond `Strict`—in fact, I'd wager that it affects every language extension that implies other language extensions. As another data point, `TypeFamilies` implies `ExplicitNamespaces`, `KindSignatures`, and `MonoLocalBinds`. Here's a GHCi session which shows that `-XTypeFamilies -XNoTypeFamilies` is similarly un-neutral: {{{ $ /opt/ghc/8.4.3/bin/ghci GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci λ> :set options currently set: none. base language is: Haskell2010 with the following modifiers: -XNoDatatypeContexts -XNondecreasingIndentation GHCi-specific dynamic flag settings: other dynamic, non-language, flag settings: -fignore-optim-changes -fignore-hpc-changes -fimplicit-import-qualified warning settings: λ> :set -XTypeFamilies λ> :set options currently set: none. base language is: Haskell2010 with the following modifiers: -XNoDatatypeContexts -XExplicitNamespaces -XKindSignatures -XMonoLocalBinds -XNondecreasingIndentation -XTypeFamilies GHCi-specific dynamic flag settings: other dynamic, non-language, flag settings: -fignore-optim-changes -fignore-hpc-changes -fimplicit-import-qualified warning settings: λ> :set -XNoTypeFamilies λ> :set options currently set: none. base language is: Haskell2010 with the following modifiers: -XNoDatatypeContexts -XExplicitNamespaces -XKindSignatures -XMonoLocalBinds -XNondecreasingIndentation GHCi-specific dynamic flag settings: other dynamic, non-language, flag settings: -fignore-optim-changes -fignore-hpc-changes -fimplicit-import-qualified warning settings: }}} So ultimately, the question here is: if enabling language extension `A` implies `B`, should `NoA` imply `NoB`? I'm not sure that it should. After all, someone legitimately might want to combine `NoTypeFamilies` with `KindSignatures`, but if `NoTypeFamilies` implied `NoKindSignatures`, then this order: {{{#!hs {-# LANGUAGE NoTypeFamilies #-} {-# LANGUAGE KindSignatures #-} }}} Would enable `KindSignatures`, but this order: {{{#!hs {-# LANGUAGE KindSignatures #-} {-# LANGUAGE NoTypeFamilies #-} }}} Would disable `KindSignatures`! (This is especially noteworthy since many folks like to list language extensions in alphabetical order, so they're more likely to hit this scenario.) Therefore, my inclination is to say that this is //not// a bug. Of course, if this behavior isn't documented, then it should be. Do others have differing viewpoints? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 13:38:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 13:38:48 -0000 Subject: [GHC] #15563: Typo in the documentation for Numeric.Natural. In-Reply-To: <042.7abd2e76bb8c52c1b059eca61d92e958@haskell.org> References: <042.7abd2e76bb8c52c1b059eca61d92e958@haskell.org> Message-ID: <057.097540550c96e2e6129da6b70f6398a1@haskell.org> #15563: Typo in the documentation for Numeric.Natural. -------------------------------------+------------------------------------- Reporter: asr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | 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 RyanGlScott): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 14:24:01 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 14:24:01 -0000 Subject: [GHC] #10346: Cross-module SpecConstr In-Reply-To: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> References: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> Message-ID: <061.37e1ac3d3477d0ba8416c7d2cbea4631@haskell.org> #10346: Cross-module SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: SpecConstr, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #13016 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ckoparkar): * owner: ckoparkar => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 15:58:03 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 15:58:03 -0000 Subject: [GHC] #15560: Full laziness destroys opportunities for join points In-Reply-To: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> References: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> Message-ID: <062.f13fc03db2b2392ee2cca13dbfd749f5@haskell.org> #15560: Full laziness destroys opportunities for join points -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14287 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Wow, that's an impressively large effect. Thanks -- I had no idea. If you stare at the assembly code, can you guess which of your bullets is causing the effect here? E.g. do we in fact end up eliminating one of the jump instruction? Your point about the stack check is a good one. Info tables. Suppose a function is: * top level * not exported * always called with know, saturated calls Then it does not need either slow entry code or an info table. So rather than avoid creating such functions (by not floating join points) maybe we should apply the optimisation uniformly to all top-level functions? Hmm. What about heap checks? If a join point `j` does heap allocations, where do we do the heap-overflow check? Maybe we should absorb the heap allocation into the jump site (as if the code was inlined)? That could avoid doing two heap checks where only one is needed. (Would only work for non-recursive join points.) Also I'm unclear about how we save live variables around a GC call at the start of a join point. (On function entry we use the function's info table; on a case return point we use its info table.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 16:20:37 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 16:20:37 -0000 Subject: [GHC] #15558: Locally handling an empty constraint In-Reply-To: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> References: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> Message-ID: <065.aad00650a2bbe2ad6177a503b45093f6@haskell.org> #15558: Locally handling an empty constraint -------------------------------------+------------------------------------- Reporter: Ericson2314 | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ff29fc84c03c800cfa04c2a00eb8edf6fa5f4183/ghc" ff29fc84/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ff29fc84c03c800cfa04c2a00eb8edf6fa5f4183" Better error reporting for inaccessible code This patch fixes Trac #15558. There turned out to be two distinct problems * In TcExpr.tc_poly_expr_nc we had tc_poly_expr_nc (L loc expr) res_ty = do { traceTc "tcPolyExprNC" (ppr res_ty) ; (wrap, expr') <- tcSkolemiseET GenSigCtxt res_ty $ \ res_ty -> setSrcSpan loc $ -- NB: setSrcSpan *after* skolemising, -- so we get better skolem locations tcExpr expr res_ty Putting the setSrcSpan inside the tcSkolemise means that the location on the Implication constraint is the /call/ to the function rather than the /argument/ to the call, and that is really quite wrong. I don't know what Richard's comment NB means -- I moved the setSrcSpan outside, and the "binding site" info in error messages actually improved. The reason I found this is that it affects the span reported for Trac #15558. * In TcErrors.mkGivenErrorReporter we carefully munge the location for an insoluble Given constraint (Note [Inaccessible code]). But the 'implic' passed in wasn't necesarily the immediately- enclosing implication -- but for location-munging purposes it jolly well should be. Solution: use the innermost implication. This actually simplifies the code -- no need to pass an implication in to mkGivenErrorReporter. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 16:42:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 16:42:22 -0000 Subject: [GHC] #14506: Configure Harbormaster to trigger CircleCI builds In-Reply-To: <046.9f61d9ef87c94b26144834dd33459a90@haskell.org> References: <046.9f61d9ef87c94b26144834dd33459a90@haskell.org> Message-ID: <061.db86ed088e4ea9e052ffbad6c07b2755@haskell.org> #14506: Configure Harbormaster to trigger CircleCI builds -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Continuous | Version: 8.2.1 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): As answered on #ghc, this is because it is the only way available in the `circlehs` bindings (Ben's fork, to be precise), which I expanded in my own fork to reflect more information on the Haskell side. But I haven't yet looked for a "callback"-style endpoint for getting notifications about build progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 16:43:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 16:43:56 -0000 Subject: [GHC] #15558: Locally handling an empty constraint In-Reply-To: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> References: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> Message-ID: <065.e17986a7b8bb7d78bdab9fccd68b2e23@haskell.org> #15558: Locally handling an empty constraint -------------------------------------+------------------------------------- Reporter: Ericson2314 | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: gadt/T15558 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => gadt/T15558 * resolution: => fixed Comment: Good points. Now fixed. For comment:8, the error is now attributed to the `()` argument to `MkFoo` as it should be. Thank you for a nice clean example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 16:48:40 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 16:48:40 -0000 Subject: [GHC] #11470: Support changing cross compiler target at runtime In-Reply-To: <045.fac441a3726b1539e9f173129f6fb28c@haskell.org> References: <045.fac441a3726b1539e9f173129f6fb28c@haskell.org> Message-ID: <060.ba56dab6ec37063bf504b8f737bca5e1@haskell.org> #11470: Support changing cross compiler target at runtime -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: feature request | 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: #11378 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ericson2314): @angerman there's not a different ticket you've been exploring `-target` under is there? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 16:52:49 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 16:52:49 -0000 Subject: [GHC] #15557: Reduce type families in equations' RHS when testing equation compatibility In-Reply-To: <044.c8824ce95594133c7a3e270ae939b58d@haskell.org> References: <044.c8824ce95594133c7a3e270ae939b58d@haskell.org> Message-ID: <059.44e0ceb43bbfb93be548cd6c541fc5b8@haskell.org> #15557: Reduce type families in equations' RHS when testing equation compatibility -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8423 #15546 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mniip): Yes, of course, being unable to unify `a ~ Test a a` is a more "severe" way to put it, but the fact that it doesn't reduce in `:t` is a more quick test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 16:55:00 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 16:55:00 -0000 Subject: [GHC] #15560: Full laziness destroys opportunities for join points In-Reply-To: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> References: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> Message-ID: <062.83da779cc84e1be63e1684d9c7f93ab3@haskell.org> #15560: Full laziness destroys opportunities for join points -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14287 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Replying to [comment:6 simonpj]: > Hmm. What about heap checks? If a join point `j` does heap allocations, where do we do the heap-overflow check? Maybe we should absorb the heap allocation into the jump site (as if the code was inlined)? That could avoid doing two heap checks where only one is needed. (Would only work for non-recursive join points.) > > Also I'm unclear about how we save live variables around a GC call at the start of a join point. (On function entry we use the function's info table; on a case return point we use its info table.) I was under the impression that join points never allocate and that they rather re-use the closure of their enclosing scope. Also, currently full laziness will never float join points (or any other binding) that closes over local variables to top-level, so we can probably disregard heap overflow checks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 16:59:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 16:59:52 -0000 Subject: [GHC] #15558: Locally handling an empty constraint In-Reply-To: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> References: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> Message-ID: <065.279b6a21298153f05e5bb7c44d47220b@haskell.org> #15558: Locally handling an empty constraint -------------------------------------+------------------------------------- Reporter: Ericson2314 | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: gadt/T15558 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ericson2314): What about the issue of what to put there when the inaccessible code has an uninhabitted type? Is writing the code with the "type warning" the best one can do? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 17:05:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 17:05:56 -0000 Subject: [GHC] #8949: switch -msse2 to be on by default In-Reply-To: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> References: <044.ed86a749988b5b707f5059998e60c5c2@haskell.org> Message-ID: <059.43f45f45aaffc97e5aa5d3144ea0b11a@haskell.org> #8949: switch -msse2 to be on by default --------------------------------------------+------------------------------ Reporter: errge | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler (CodeGen) | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Runtime performance bug | Test Case: Blocked By: 13624 | Blocking: Related Tickets: #13540, #13624 | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by carter): I know this was fixed in the windows linker afaik. Has the alignment issue been addressed on other platforms yet or what are the blockers ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 17:08:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 17:08:20 -0000 Subject: [GHC] #13624: loadObj() does not respect alignment In-Reply-To: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> References: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> Message-ID: <063.01de03569e7334e8276565dbe4e17567@haskell.org> #13624: loadObj() does not respect alignment -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Runtime System | Version: 8.0.1 (Linker) | Keywords: linker, Resolution: | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: 8949 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): What are the platforms that need this fix? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 17:08:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 17:08:44 -0000 Subject: [GHC] #13624: loadObj() does not respect alignment In-Reply-To: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> References: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> Message-ID: <063.c20ff4b033a2cf73450dbdd5882f9c0b@haskell.org> #13624: loadObj() does not respect alignment -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Runtime System | Version: 8.0.1 (Linker) | Keywords: linker, Resolution: | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: 8949 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): And what are the challenges to doing this correctly? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 17:18:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 17:18:19 -0000 Subject: [GHC] #10859: Generated Eq instance associates && wrongly In-Reply-To: <046.4f10604a3fa32deb15c9056d38ba731c@haskell.org> References: <046.4f10604a3fa32deb15c9056d38ba731c@haskell.org> Message-ID: <061.e20c57c0f2aff0ac7329ca98e3f9fe5e@haskell.org> #10859: Generated Eq instance associates && wrongly -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonpj Type: bug | Status: patch Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: deriving, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10858 | Differential Rev(s): Phab:D5104 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ckoparkar): * status: new => patch * differential: => Phab:D5104 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 17:23:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 17:23:36 -0000 Subject: [GHC] #15562: `-XStrict -XNoStrict` is not neutral In-Reply-To: <042.ba188334cc4bb9cd167859c3f14e424e@haskell.org> References: <042.ba188334cc4bb9cd167859c3f14e424e@haskell.org> Message-ID: <057.b1aeeb4a9f6013e3a36d5587dc9e2eff@haskell.org> #15562: `-XStrict -XNoStrict` is not neutral -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Well, with the current semantics, automatically reordering your `LANGUAGE` pragmas can change the effective set of enabled extensions. So that's something IDEs and refactoring tools will hopefully be aware of. At least for now we have a simple heuristic such tooling can use to avoid changing the meaning of pragmas: groups of negative and positive pragmas do not commute. I.e. you are only allowed to reorder pragmas within a sequence of either positive or negative pragmas. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 18:37:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 18:37:43 -0000 Subject: [GHC] #15557: Reduce type families in equations' RHS when testing equation compatibility In-Reply-To: <044.c8824ce95594133c7a3e270ae939b58d@haskell.org> References: <044.c8824ce95594133c7a3e270ae939b58d@haskell.org> Message-ID: <059.741be4b877902d3f0293b34bc02d4e7e@haskell.org> #15557: Reduce type families in equations' RHS when testing equation compatibility -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8423 #15546 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mniip): After giving it a little thought: Equation compatibility check can be regarded as a quantified implicational constraint: {{{ [p] forall ps. TF lhs_p = rhs_p [q] forall qs. TF lhs_q = rhs_q }}} {{{ compat(TF, p, q) = forall ps qs. (lhs_p ~ lhs_q) => (rhs_p ~ rhs_q) }}} Since `lhs_k` in Haskell are always a simple tycon/tyvar superposition, one can, as the CTFwOE paper implies, just run unification on `lhs_p ~ lhs_q`. If the unification fails the implication holds vacuously, otherwise we have a substitution to apply to `rhs_p`/`rhs_q`. In such case we are left with: {{{ compat(TF, p, q) = forall as. Omega(rhs_p) ~ Omega(rhs_q) }}} This constraint is still quantified but at least not implicational. Now we can kind-of express compatibility checking in the language of constraint solving: we have implicational axioms: {{{ (apart(lhs_1, lhs_i), ..., apart(lhs_i-1, lhs_i)) => TF lhs_i ~ rhs_i (compat(TF, 1, i), ..., compat(TF, i-1, i)) => TF lhs_i ~ rhs_i }}} ...But also every other combination of `apart` and `compat` constraints, provided either is given for each j in [0 .. i-1]. Again `lhs_k` are simple enough that `apart` constraints can be easily immediately discharged to either trivially false or trivially true constraints. We are then left with, really, one implication constraint for each equation: {{{ (compat(TF, c_1, i), ..., compat(TF, c_k, i)) => TF lhs_i ~ rhs_i }}} Where c_1,...,c_k are exactly the indices of equations that come before ith but whose lhs are not apart from ith equation's. This is where @goldfire's comment comes in: if we are left with a system of constraint implications that has multiple solutions, e.g: {{{ compat(A, 0, 1) => compat(B, 0, 1) compat(B, 0, 1) => compat(A, 0, 1) }}} Here the two either simultaneously hold or simultaneously don't hold. Here it is actually type-safe to pick the most truthy solution: the greatest fixed point rather than the least. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 19:55:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 19:55:36 -0000 Subject: [GHC] #15564: Plugin recompilation check panics with inline-java Message-ID: <056.17d573a7924d7195f7d3c759e2148800@haskell.org> #15564: Plugin recompilation check panics with inline-java -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Keywords: plugins, | Operating System: Unknown/Multiple plugin recompilation | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15475 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When building https://github.com/tweag/inline-java with the beta release of ghc 8.6.1, I'm getting a panic like the one in #15475. {{{ stack --nix --no-terminal build --test --bench --no-run-tests --no-run- benchmarks ... Log files have been written to: /home/centos/inline-java/.stack-work/logs/ -- While building custom Setup.hs for package inline-java-0.8.4 using: /home/centos/.stack/setup-exe-cache/x86_64-linux-nix/Cabal- simple_mPHDZzAJ_2.4.0.0_ghc-8.6.0.20180810 --builddir=.stack- work/dist/x86_64-linux-nix/Cabal-2.4.0.0 build lib:inline-java test:spec --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always" Process exited with code: ExitFailure 1 Logs have been written to: /home/centos/inline-java/.stack-work/logs /inline-java-0.8.4.log Configuring inline-java-0.8.4... Preprocessing library for inline-java-0.8.4.. Building library for inline-java-0.8.4.. [4 of 4] Compiling Language.Java.Inline.Plugin ( src/Language/Java/Inline/Plugin.hs, .stack-work/dist/x86_64-linux- nix/Cabal-2.4.0.0/build/Language/Java/Inline/Plugin.o ) Preprocessing test suite 'spec' for inline-java-0.8.4.. Building test suite 'spec' for inline-java-0.8.4.. [1 of 3] Compiling Language.Java.InlineSpec ( tests/Language/Java/InlineSpec.hs, .stack-work/dist/x86_64-linux- nix/Cabal-2.4.0.0/build/spec/spec-tmp/Language/Java/InlineSpec.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.6.0.20180810 for x86_64-unknown-linux): mkPluginUsage: file not found Language.Java.Inline.Plugin /nix/store /5zgi3snmw1iq704jjaildk7x333s10cw-gradle-4.9/lib/libHSinline-java-0.8.4 -JByd5xgK6QcDkJNlDDk6Qy-ghc8.6.0.20180810.so Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1164:37 in ghc:Outputable pprPanic, called at compiler/deSugar/DsUsage.hs:215:15 in ghc:DsUsage Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [centos at ip-172-31-4-204 inline-java]$ stack --nix --no-terminal exec -- env | grep LD_LIBRARY_PATH LD_LIBRARY_PATH=/nix/store/d5xr4h3bhl8iiyds5b59njawq3pnr4xr-openjdk- 8u181b13/lib/openjdk/jre/lib/amd64/server/lib:/nix/store /rc9ksilfsx1pqya4lj8barzzywnvlncl-git-2.18.0/lib:/nix/store /d5xr4h3bhl8iiyds5b59njawq3pnr4xr-openjdk-8u181b13/lib:/nix/store /5zgi3snmw1iq704jjaildk7x333s10cw-gradle-4.9/lib }}} The fact that ghc tries to locate a library in {{/nix/store /5zgi3snmw1iq704jjaildk7x333s10cw-gradle-4.9/lib}} to check for recompilation makes me think that this is an actual bug in GHC. But I would be happy to get some assistance to confirm this. I tried disabling recompilation checking by defining the plugin as: {{{ plugin :: Plugin plugin = defaultPlugin { installCoreToDos = install , pluginRecompile = purePlugin } }}} but the error persists. This is what my dependencies look like in stack.yaml: {{{ packages: - . - jni - jvm - jvm-batching - jvm-streaming - examples/classpath - location: singletons extra-dep: true - location: criterion extra-dep: true - location: polyparse-1.12 extra-dep: true extra-deps: - distributed-closure-0.3.5 - git: https://github.com/haskell/cabal # commit: ac461b381104a39a349d7416ecf1399805c6d000 commit: fe10982db1f2fa7d828fc5f8ddaa5beedceaddec subdirs: - Cabal # - git: https://github.com/goldfirere/singletons.git # commit: 5f867ace69ab12fc98fa71df1cdf7985afa3cb91 - git: https://github.com/haskell/stm.git commit: 4a1deb98fc95e55d8a6762a7dfec1a7dfa8b49b2 - git: https://github.com/goldfirere/th-desugar commit: 0f0a45f7b1f290a6005e6d9d849247f8c3d35429 - git: https://github.com/simonmar/async.git commit: 725ba4bb9679c5d9c7fe0e2d45fda4f470851d40 - git: https://github.com/erikd/vector-algorithms.git commit: 89e87b374d94e8a0c90fc58079ea1343c3ffa7c9 - cpphs-1.20.8 }}} I'll see to share my modifications to singletons, criterion and polyparse, if necessary. I just fixed some dependency bounds and added MonadFail instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 19:57:17 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 19:57:17 -0000 Subject: [GHC] #15557: Reduce type families in equations' RHS when testing equation compatibility In-Reply-To: <044.c8824ce95594133c7a3e270ae939b58d@haskell.org> References: <044.c8824ce95594133c7a3e270ae939b58d@haskell.org> Message-ID: <059.d341bc2960e60b0771eb0caa762647b4@haskell.org> #15557: Reduce type families in equations' RHS when testing equation compatibility -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8423 #15546 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mniip): Correction: an `apart` constraint might sometimes not get discharged if the same tyvar occurs multiple times, e.g: {{{ type family Eq a b where Eq a a = True Eq a b = False }}} {{{ TF a a ~ True apart(, ) => TF a b ~ False }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 20:05:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 20:05:44 -0000 Subject: [GHC] #15564: Plugin recompilation check panics with inline-java In-Reply-To: <056.17d573a7924d7195f7d3c759e2148800@haskell.org> References: <056.17d573a7924d7195f7d3c759e2148800@haskell.org> Message-ID: <071.5f3d299c5157285c5b4756b387899389@haskell.org> #15564: Plugin recompilation check panics with inline-java -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: plugins, | plugin recompilation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15475 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): This is fixed on the branch I think. If you are using nix can you confirm using the version of beta1 I built which also includes the patch D5048 (https://phabricator.haskell.org/D5048)? {{{ cachix use mpickering nix-shell -I nixpkgs=https://github.com/mpickering/head.hackage/archive/master.tar.gz -p haskellPackages.ghc }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 20:16:02 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 20:16:02 -0000 Subject: [GHC] #15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite In-Reply-To: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> References: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> Message-ID: <061.c947ae036e5fcc8bf4d6c0e9cbf1d9fa@haskell.org> #15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: simonmar (added) Comment: It is looking very much like this is due to the SRT rework. Specifically, I bisected this down to one of the following: {{{ There are only 'skip'ped commits left to test. The first bad commit could be any of: f2d27c1ad69321872a87a37144fe41e815301f5b 0c7db226012b5cfafc9a38bfe372661672ec8900 b701e4754d1d6286e233c73d7360926f3eaae577 4ffaf4b67773af4c72d92bb8b6c87b1a7d34ac0f 5f15d53a98ad2f26465730d8c3463ccc58f6d94a 99f8cc84a5b23878b3b0732955cb651bc973e9f2 f27e4f624fe1270e8027ff0a14f03514f5be31b7 126b4125d95f7e4d272a9307cb8b634b11bd337f 5d3b15ecbf17b7747c2f7313a981c60a2d22904d 3310f7f14c0ba34a57fe5a77f47d2a66fe838a43 819b9cfd21a1773091cec4e34716a0fd7c7d05c6 01bb17fd4dc6d92cf08632bbb62656428db6e7fa 797a46239d958841219f0f7769b0016b1b23d5ca 838b69032566ce6ab3918d70e8d5e098d0bcee02 efe405447b9fa88cebce718a6329091755deb9ad 2b0918c9834be1873728176e4944bec26271234a 2bbdd00c6d70bdc31ff78e2a42b26159c8717856 5a7c657e02b1e801c84f26ea383f326234cd993c fbd28e2c6b5f1302cd2d36d79149e3b0a9f01d84 ae292c6d1362f34117be75a2553049cec7022244 eb8e692cab7970c495681e14721d05ecadd21581 d78dde9ff685830bc9d6bb24a158eb31bb8a7028 We cannot bisect more! }}} Unfortunately bisecting through these has been extremely messy due to non- building commits. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 20:36:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 20:36:05 -0000 Subject: [GHC] #15565: ancient ghc release history on web page is incomplete Message-ID: <049.81a2a5214fd613fff8e9277a3dbe662c@haskell.org> #15565: ancient ghc release history on web page is incomplete -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Documentation | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (just for historical completeness) 2.10 is missing from https://downloads.haskell.org/~ghc/ . There is https://www.haskell.org/ghc/download_ghc_210.html , but the source link on that page is 404, and the wayback machine claims not to have ftp://ftp.dcs.gla.ac.uk/pub/ . Release dates are missing on https://www.haskell.org/ghc/download.html (under "Older releases"). Dates are present at https://www.haskell.org/ghc/ (under "News") but only from 6.10 onwards. I used mail archive locations mentioned at https://www.reddit.com/r/haskell/comments/6y2qbw/what_happened_to/ to find that 0.29 was announced on 29 Jul 1996. The "first full release" (0.10) was at 11 Dec 92. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 21:21:18 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 21:21:18 -0000 Subject: [GHC] #14794: -Weverything should not enable -Wmissing-exported-signatures In-Reply-To: <049.1806d387ab94f5c229447f9562a2a543@haskell.org> References: <049.1806d387ab94f5c229447f9562a2a543@haskell.org> Message-ID: <064.0bb4c9520d74dfcb22f7fb1eb89aa264@haskell.org> #14794: -Weverything should not enable -Wmissing-exported-signatures -------------------------------------+------------------------------------- Reporter: MaxGabriel | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by taylorfausak): 👍 I agree! I would like it if `-Weverything` did not enable `-Wmissing- exported-signatures`. Here is a way to reproduce the problem with Stack: {{{ #!/usr/bin/env stack -- stack --resolver ghc-8.4.3 script {-# OPTIONS_GHC -Weverything -Wno-implicit-prelude -Wno-safe #-} module Main ( main ) where main :: IO () main = pure shouldWarn shouldWarn = () }}} With -Wall instead of -Weverything, I get this warning: {{{ .../Example.hs:10:1: warning: [-Wmissing-signatures] Top-level binding with no type signature: shouldWarn :: () | 10 | shouldWarn = () | ^^^^^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 21:58:03 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 21:58:03 -0000 Subject: [GHC] #15560: Full laziness destroys opportunities for join points In-Reply-To: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> References: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> Message-ID: <062.ecded0348c9ede89261ebc1aa31b0009@haskell.org> #15560: Full laziness destroys opportunities for join points -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14287 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I was under the impression that join points never allocate and that they rather re-use the closure of their enclosing scope Correct. But consider {{{ f x = let j y = Just (y,y) in case x of A -> j (True, False) B -> j (False, True) C -> j (True, True) }}} Suppose branch `A` is taken. Then GHC must allocate the object `(True, False)` and jump to `j`. Then `j` must allocate `(y,y)` and return it. I suspect that there's a heap check at the beginning of the `A` branch; and then a second heap check at the start of the body of `j`. But instead we could make `j` not do a heap check (ever) and instead put on the caller (of `j`) the responsibility for making sure that there's enough heap space for `j` to do its allocation. That way we'd get one heap check, at the beginning of the `A` branch, which would ensure there was enough space for both pairs. (As you say, no closure is allocated for `j` itself, but that's an entirely different matter.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 24 22:24:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Aug 2018 22:24:50 -0000 Subject: [GHC] #15564: Plugin recompilation check panics with inline-java In-Reply-To: <056.17d573a7924d7195f7d3c759e2148800@haskell.org> References: <056.17d573a7924d7195f7d3c759e2148800@haskell.org> Message-ID: <071.c7653d0e3a3f942d94cbcb929bc6c8f9@haskell.org> #15564: Plugin recompilation check panics with inline-java -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: plugins, | plugin recompilation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15475 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): I'm checking it. It is likely that your assessment is correct. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 25 07:36:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Aug 2018 07:36:52 -0000 Subject: [GHC] #4022: GHC Bindist is Broken on FreeBSD/amd64 In-Reply-To: <042.be61d95849398bdf9c05d1a69af1e7e3@haskell.org> References: <042.be61d95849398bdf9c05d1a69af1e7e3@haskell.org> Message-ID: <057.711921d87a836cccc9d7a5db1f47acc3@haskell.org> #4022: GHC Bindist is Broken on FreeBSD/amd64 -------------------------------------+------------------------------------- Reporter: pgj | Owner: pgj Type: bug | Status: new Priority: lowest | Milestone: Component: Core Libraries | Version: 6.13 Resolution: | Keywords: GMP,integer- | gmp, sharedlibs Operating System: FreeBSD | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #8156 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by arrowd): I'm maintaining GHC port for FreeBSD, so feel free to ping me if you need something. I'm also poking with stack, making it support installations of recent GHC versions. That's why we need working bindists for FreeBSD. Would it be possible to produce a bindist for 8.4.3 too, at least? And another thought - maybe I can add some logic to create bindist right into FreeBSD port? So you just do `make -C /usr/ports/lang/ghc bindist` on a fresh system and get a tarball. Would that ease anything for you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 25 07:37:59 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Aug 2018 07:37:59 -0000 Subject: [GHC] #4022: GHC Bindist is Broken on FreeBSD/amd64 In-Reply-To: <042.be61d95849398bdf9c05d1a69af1e7e3@haskell.org> References: <042.be61d95849398bdf9c05d1a69af1e7e3@haskell.org> Message-ID: <057.1fdf97a8b5733f771c630196abf8effe@haskell.org> #4022: GHC Bindist is Broken on FreeBSD/amd64 -------------------------------------+------------------------------------- Reporter: pgj | Owner: pgj Type: bug | Status: new Priority: lowest | Milestone: Component: Core Libraries | Version: 6.13 Resolution: | Keywords: GMP,integer- | gmp, sharedlibs Operating System: FreeBSD | Architecture: x86_64 Type of failure: Building GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #8156 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by arrowd): * cc: arrowd@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 25 07:39:05 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Aug 2018 07:39:05 -0000 Subject: [GHC] #14012: External interpreter fails on FreeBSD In-Reply-To: <046.2b65587ea7267566cfeb67b314c36291@haskell.org> References: <046.2b65587ea7267566cfeb67b314c36291@haskell.org> Message-ID: <061.052ed3106b1343185d79ca1dd5e9f042@haskell.org> #14012: External interpreter fails on FreeBSD ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: RemoteGHCi Operating System: FreeBSD | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by arrowd): * cc: arrowd@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 25 07:40:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Aug 2018 07:40:39 -0000 Subject: [GHC] #14064: Compiling problem on FreeBSD 11 ("failed in phase") In-Reply-To: <043.996442976c5d50d07afa88e2354bce42@haskell.org> References: <043.996442976c5d50d07afa88e2354bce42@haskell.org> Message-ID: <058.59c1a0e966f3c25c43552d558a41f002@haskell.org> #14064: Compiling problem on FreeBSD 11 ("failed in phase") -------------------------------------+------------------------------------- Reporter: ohho | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: GHC doesn't work | (amd64) at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by arrowd): * cc: arrowd@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 25 08:18:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Aug 2018 08:18:22 -0000 Subject: [GHC] #13165: Speed up the RTS hash table In-Reply-To: <047.5597063b110123c6100b4b707918365d@haskell.org> References: <047.5597063b110123c6100b4b707918365d@haskell.org> Message-ID: <062.1595b90f8beeae61a02127e453e383e5@haskell.org> #13165: Speed up the RTS hash table -------------------------------------+------------------------------------- Reporter: dobenour | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mboes): * cc: mboes (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 25 10:24:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Aug 2018 10:24:47 -0000 Subject: [GHC] #14483: getExecutablePath from System.Environment in base should follow symlinks properly. In-Reply-To: <047.aa439e87f7f99b82b43f48b72f8056c1@haskell.org> References: <047.aa439e87f7f99b82b43f48b72f8056c1@haskell.org> Message-ID: <062.8d5c54bba333e7fd7ffe3bbd21445364@haskell.org> #14483: getExecutablePath from System.Environment in base should follow symlinks properly. -------------------------------------+------------------------------------- Reporter: angerman | Owner: alpmestan Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.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): D4227 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina ): In [changeset:"c523525b0e434d848f6e47ea3f9a37485965fa79/ghc" c523525/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c523525b0e434d848f6e47ea3f9a37485965fa79" ghc, ghc-pkg: use getExecutablePath on Windows when base >= 4.11.0 Summary: This completes the work started in D4227 by using just 'getExecutablePath' in ghc and ghc-pkg when building with base >= 4.11.0. On the long term, we will be able to simply kill the existing code that follows (or not) symlinks and just get this behaviour for free from getExecutable. For now we however have to require base >= 4.11.0 to be able to just use getExecutablePath under Windows, and use the current code when building with an older base. Original code by @alpmestan commandeering since patch has been stale and bug remains open. Test Plan: Validate Reviewers: angerman, bgamari, erikd, alpmestan Reviewed By: bgamari Subscribers: carter, rwbarton, thomie GHC Trac Issues: #14483 Differential Revision: https://phabricator.haskell.org/D4229 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 25 10:30:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Aug 2018 10:30:42 -0000 Subject: [GHC] #14460: Symlink resolving fails against SMB mounts In-Reply-To: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> References: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> Message-ID: <060.1900ceac70d4b74b05868b006251ae76@haskell.org> #14460: Symlink resolving fails against SMB mounts -------------------------------------+------------------------------------- Reporter: astert | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4216 Wiki Page: | Phab:D4229 Phab:D4227 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed * milestone: 8.4.1 => 8.6.1 Comment: In c523525/ghc: ghc, ghc-pkg: use getExecutablePath on Windows when base >= 4.11.0 Summary: This completes the work started in D4227 by using just 'getExecutablePath' in ghc and ghc-pkg when building with base >= 4.11.0. On the long term, we will be able to simply kill the existing code that follows (or not) symlinks and just get this behaviour for free from getExecutable. For now we however have to require base >= 4.11.0 to be able to just use getExecutablePath under Windows, and use the current code when building with an older base. Original code by @alpmestan commandeering since patch has been stale and bug remains open. Test Plan: Validate Reviewers: angerman, bgamari, erikd, alpmestan Reviewed By: bgamari Subscribers: carter, rwbarton, thomie GHC Trac Issues: #14483 Differential Revision: https://phabricator.haskell.org/D4229 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 25 10:31:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Aug 2018 10:31:11 -0000 Subject: [GHC] #14460: Symlink resolving fails against SMB mounts In-Reply-To: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> References: <045.32edffe3e1a889f69e5c215d88b0d164@haskell.org> Message-ID: <060.b3118fd07d6779a02ef6305331f3b126@haskell.org> #14460: Symlink resolving fails against SMB mounts -------------------------------------+------------------------------------- Reporter: astert | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4216 Wiki Page: | Phab:D4229 Phab:D4227 -------------------------------------+------------------------------------- Changes (by Phyx-): * milestone: 8.6.1 => 8.8.1 Comment: This missed the deadline unfortunately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 25 11:29:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Aug 2018 11:29:54 -0000 Subject: [GHC] #14483: getExecutablePath from System.Environment in base should follow symlinks properly. In-Reply-To: <047.aa439e87f7f99b82b43f48b72f8056c1@haskell.org> References: <047.aa439e87f7f99b82b43f48b72f8056c1@haskell.org> Message-ID: <062.6e857cbcaff647cb57dc4de934da8dc5@haskell.org> #14483: getExecutablePath from System.Environment in base should follow symlinks properly. -------------------------------------+------------------------------------- Reporter: angerman | Owner: alpmestan Type: bug | Status: closed Priority: normal | Milestone: 8.4.1 Component: Compiler | Version: 8.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): D4227 Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): Thanks for picking this up, I've had to turn my attention to 2 urgent tasks lately, sorry for the delay! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 25 11:36:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Aug 2018 11:36:21 -0000 Subject: [GHC] #15460: Literals overflow In-Reply-To: <045.4d90b83e8c6931283f442559046619d4@haskell.org> References: <045.4d90b83e8c6931283f442559046619d4@haskell.org> Message-ID: <060.e954560f9ce58f9b41e624c0f53648aa@haskell.org> #15460: Literals overflow -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.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: | -------------------------------------+------------------------------------- Comment (by RolandSenn): With GHC 8.4.2 I could reproduce the error. However GHC 8.6.0-20180810 (8.6.1-beta1) seems to work: {{{ roland at goms:~/Projekte/ghctest/T15460$ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.4.2 roland at goms:~/Projekte/ghctest/T15460$ ghc -O2 T15460.hs [1 of 1] Compiling Main ( T15460.hs, T15460.o ) Linking T15460 ... roland at goms:~/Projekte/ghctest/T15460$ ./T15460 "Oups" roland at goms:~/Projekte/ghctest/T15460$ switchghc 8.6.1 The Glorious Glasgow Haskell Compilation System, version 8.6.0.20180810 roland at goms:~/Projekte/ghctest/T15460$ rm *.hi | rm *.o roland at goms:~/Projekte/ghctest/T15460$ ghc -O2 T15460.hs [1 of 1] Compiling Main ( T15460.hs, T15460.o ) Linking T15460 ... roland at goms:~/Projekte/ghctest/T15460$ ./T15460 "Ok" }}} Do you want a patch containing only a testcase? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 25 12:37:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Aug 2018 12:37:32 -0000 Subject: [GHC] #15541: package environment files and the GHC API In-Reply-To: <048.226f5c575460b148605c8a51ca4e89c3@haskell.org> References: <048.226f5c575460b148605c8a51ca4e89c3@haskell.org> Message-ID: <063.f9169db58a14a8e9a1f5b13cd430afe8@haskell.org> #15541: package environment files and the GHC API -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: GHC API | Version: 8.4.3 Resolution: | Keywords: package | environment Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #15513 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lspitzner): > The motivation for this design is that package environments should be transparent to the user, giving tooling a means of configuring GHC for a project without further user intervention. I consider the whole feature to be a mistake, see [https://hexagoxel.de/postsforpublish/posts/2018-08-25-ghc-pkg-env- misfeature.html this summary post]. As a consequence, if I had to choose between the options you presented, I'd vote for the first (rip out this side-effect from `setSessionDynFlags`). Some further opinionated thoughts: - If you expose `getFoo` and `setFoo`, `getFoo >>= setFoo` **must behave as identity**, free of (side- / other) effects. No amount of API docs excuses a violation. - It is likely to surprise and generally inadvisable to have any actions exposed in an API depend on `CWD`, especially by default. - The actions in the API should all have a single, clearly defined purpose. In brittany we encountered exactly the same question when it came to user config handling in its API. Perhaps have a look at how the brittany API is designed when it comes to `Config` values: https://hackage.haskell.org/package/brittany-0.11.0.0/docs/Language- Haskell-Brittany.html. Note how `parsePrintModule` is explicit about its inputs, promises to be semantically pure, and that there are separate actions that explicitly handle the filesystem reading of config files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 25 12:55:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Aug 2018 12:55:54 -0000 Subject: [GHC] #15560: Full laziness destroys opportunities for join points In-Reply-To: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> References: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> Message-ID: <062.5b7678557f068db3fe911ac0d41b3a28@haskell.org> #15560: Full laziness destroys opportunities for join points -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14287 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): Replying to [comment:6 simonpj]: > Wow, that's an impressively large effect. Thanks -- I had no idea. If you stare at the assembly code, can you guess which of your bullets is causing the effect here? E.g. do we in fact end up eliminating one of the jump instruction? It's hard to tell really. I've looked at vtune and it seems the top level variant has more cache misses and decoder stalls. So it seems to be primarily a case of code size and worse code layout. While we also execute about 2,5% more instructions which definitely will come at a cost given the difference I would expect layout/code size to be larger factors. > > Your point about the stack check is a good one. > > Info tables. Suppose a function is: > * top level > * not exported > * always called with know, saturated calls > > Then it does not need either slow entry code or an info table. So rather than avoid creating such functions (by not floating join points) maybe we should apply the optimisation uniformly to all top-level functions? I assume you are talking about removing the stack check here with the optimisation? Then we would still get the cache fragmentation/layout penalty. So ideally we would do both. * Remove the stack check if it's a floated join point called from many places to avoid code bloat. * Push them back into the rhs if there is only a single call site. > I suspect that there's a heap check at the beginning of the A branch; and then a second heap check at the start of the body of j. But instead we could make j not do a heap check (ever) and instead put on the caller (of j) the responsibility for making sure that there's enough heap space for j to do its allocation. Ideally we would combine the checks for all branches into a single one to begin with. But that seems like a different issue to me as this would be beneficial with or without join points. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 25 15:12:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Aug 2018 15:12:46 -0000 Subject: [GHC] #15566: Implement minimumOn, maximumOn to mirror sortOn Message-ID: <046.9955d151a0d096fa05b640c0d0259990@haskell.org> #15566: Implement minimumOn, maximumOn to mirror sortOn -------------------------------------+------------------------------------- Reporter: Garciat | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Research needed Component: | Version: 8.5 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: -------------------------------------+------------------------------------- By importing Data.List, we currently get: {{{#!hs sortBy :: (a -> a -> Ordering) -> [a] -> [a] maximumBy :: Foldable t => (a -> a -> Ordering) -> t a -> a minimumBy :: Foldable t => (a -> a -> Ordering) -> t a -> a sortOn :: Ord b => (a -> b) -> [a] -> [a] }}} I believe sortOn to be a very useful 'shortcut'. In that spirit, I propose we add: {{{#!hs maximumOn :: (Foldable t, Ord b) => (a -> b) -> t a -> a minimumOn :: (Foldable t, Ord b) => (a -> b) -> t a -> a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 25 15:16:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Aug 2018 15:16:58 -0000 Subject: [GHC] #15566: Implement minimumOn, maximumOn to mirror sortOn In-Reply-To: <046.9955d151a0d096fa05b640c0d0259990@haskell.org> References: <046.9955d151a0d096fa05b640c0d0259990@haskell.org> Message-ID: <061.5eb0b089918e8fc5404d96b0842ee087@haskell.org> #15566: Implement minimumOn, maximumOn to mirror sortOn -------------------------------------+------------------------------------- Reporter: Garciat | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Research | needed Component: libraries/base | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 25 16:27:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Aug 2018 16:27:37 -0000 Subject: [GHC] #15566: Implement minimumOn, maximumOn to mirror sortOn In-Reply-To: <046.9955d151a0d096fa05b640c0d0259990@haskell.org> References: <046.9955d151a0d096fa05b640c0d0259990@haskell.org> Message-ID: <061.b226dbd0b0d5f0b9b7000936ab755193@haskell.org> #15566: Implement minimumOn, maximumOn to mirror sortOn -------------------------------------+------------------------------------- Reporter: Garciat | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Research | needed Component: libraries/base | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Garciat): This is just food for thought: {{{#!hs import Data.Foldable import Data.Semigroup newtype Tagged t a = Tagged (t, a) instance Eq t => Eq (Tagged t a) where Tagged (x, _) == Tagged (y, _) = x == y instance Ord t => Ord (Tagged t a) where compare (Tagged (x, _)) (Tagged (y, _)) = compare x y maximumOn :: (Foldable t, Ord b) => (a -> b) -> t a -> a maximumOn f xs = case foldMap tag xs of Nothing -> error "maximumOn: empty structure" Just (Max (Tagged (_, x))) -> x where tag x = Just . Max . Tagged $ (f x, x) minimumOn :: (Foldable t, Ord b) => (a -> b) -> t a -> a minimumOn f xs = case foldMap tag xs of Nothing -> error "minimumOn: empty structure" Just (Min (Tagged (_, x))) -> x where tag x = Just . Min . Tagged $ (f x, x) }}} I can anticipate the partiality of the functions being a potential problem for the general case. I guess that suggests these should be `Foldable` methods w/ defaults, instead of standalone functions? And that makes the proposal that much hairy due to evolution, etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 25 19:14:51 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Aug 2018 19:14:51 -0000 Subject: [GHC] #15567: security of package environment files Message-ID: <047.60670edf186a46d75607f123c7e6182a@haskell.org> #15567: security of package environment files -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc will read package environment files owned by other users than the current user, in directories below the current directory. So using ghc in shared directories like /tmp is now a security concern. {{{ joey at darkstar:/tmp/test/sub>ls -l ../../.ghc.environment.x86_64-linux-8.2.2 -rw-r--r-- 1 mail mail 9 Aug 25 15:03 ../../.ghc.environment.x86_64-linux-8.2.2 joey at darkstar:/tmp/test/sub>cat ../.ghc.environment.x86_64-linux-8.2.2 outdated joey at darkstar:/tmp/test/sub>ghc --make foo : cannot satisfy -package-id outdated (use -v for more information) }}} I suppose this could at least be used to trick ghc into building against an older version of some package that was updated with a security fix. It might be possible to exploit in other ways, perhaps by pointing to a backdoored build of a package? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 25 19:23:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Aug 2018 19:23:35 -0000 Subject: [GHC] #15567: security of package environment files In-Reply-To: <047.60670edf186a46d75607f123c7e6182a@haskell.org> References: <047.60670edf186a46d75607f123c7e6182a@haskell.org> Message-ID: <062.14fbe196ff1b297c02019273cdb081b8@haskell.org> #15567: security of package environment files -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by joeyhess: Old description: > ghc will read package environment files owned by other users than the > current user, in directories below the current directory. So using ghc in > shared directories like /tmp is now a security concern. > > {{{ > joey at darkstar:/tmp/test/sub>ls -l > ../../.ghc.environment.x86_64-linux-8.2.2 > -rw-r--r-- 1 mail mail 9 Aug 25 15:03 > ../../.ghc.environment.x86_64-linux-8.2.2 > joey at darkstar:/tmp/test/sub>cat ../.ghc.environment.x86_64-linux-8.2.2 > outdated > joey at darkstar:/tmp/test/sub>ghc --make foo > : cannot satisfy -package-id outdated > (use -v for more information) > }}} > > I suppose this could at least be used to trick ghc into building against > an older version of some package that was updated with a security fix. It > might be possible to exploit in other ways, perhaps by pointing to a > backdoored build of a package? New description: ghc will read package environment files owned by other users than the current user, in directories below the current directory. So using ghc in shared directories like /tmp is now a security concern. {{{ joey at darkstar:/tmp/test/sub>ls -l ../../.ghc.environment.x86_64-linux-8.2.2 -rw-r--r-- 1 mail mail 9 Aug 25 15:03 ../../.ghc.environment.x86_64-linux-8.2.2 joey at darkstar:/tmp/test/sub>cat ../../.ghc.environment.x86_64-linux-8.2.2 outdated joey at darkstar:/tmp/test/sub>ghc --make foo : cannot satisfy -package-id outdated (use -v for more information) }}} I suppose this could at least be used to trick ghc into building against an older version of some package that was updated with a security fix. It might be possible to exploit in other ways, perhaps by pointing to a backdoored build of a package? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 25 20:01:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Aug 2018 20:01:37 -0000 Subject: [GHC] #15567: security of package environment files In-Reply-To: <047.60670edf186a46d75607f123c7e6182a@haskell.org> References: <047.60670edf186a46d75607f123c7e6182a@haskell.org> Message-ID: <062.f73b36b34e3a2d39a84a9d2de2a5cb70@haskell.org> #15567: security of package environment files -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by svenpanne): Just another indication that one should explicitly ''opt-in'' into reading environment files, and not be forced to ''opt-out''... I really hope that GHC's default behavior will be fixed in this respect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Aug 25 20:40:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Aug 2018 20:40:07 -0000 Subject: [GHC] #15363: Do some cleaning up of the testsuite driver In-Reply-To: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> References: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> Message-ID: <060.5d3da26365c776b8a311e5cf15fea3a5@haskell.org> #15363: Do some cleaning up of the testsuite driver -------------------------------------+------------------------------------- Reporter: lantti | Owner: lantti Type: task | Status: patch Priority: low | Milestone: 8.8.1 Component: Test Suite | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lantti): * status: new => patch Comment: I was playing around some more with the Windows process groups but eventually went the Job Objects way. The Windows console process groups are supported by subprocess module and os module, resulting in an almost total elimination of the diverging code path and working to my satisfaction on a light load, but unfortunately not working under mintty without additional winpty wrapping and still breaking apart on heavier loads due to Windows Console signals not being guaranteed to be delivered in such cases. The Job Objects on the other hand require a long diverging code path, but were absolutely robust against my limited stress tests. A preliminary patch is submitted to Phabricator: https://phabricator.haskell.org/D5107 Some simple tests that I used to evaluate that: https://github.com/lantti/ghc/tree/testsuite-tests/testsuite/tests/aaa The patch follows the approach from timeout.hs for Windows and uses subprocess module for Posix. As the Windows code path doesn't use subprocess anymore the IO redirection and environment string generation are handled by this patch too. All in all the diverging code paths didn't get shorter, unlike I had hoped. According to my few test runs the testsuite runs slightly faster on Posix now, on Windows I don't have any coherent results of it running faster or slower. Also interrupting the test run on Windows is as sketchy as it used to be, it only works because mintty kills our process tree for us. No signals get delivered to our testsuite driver and none of our cleanup or results collecting code runs. Some related observations I made while working on this: - in addition to the signals/console incompatibility between mintty-mingw and native Windows programs, current versions of mintty-mingw have problems handling unicode environment variables, the variables get mangled already before they are passed to the python interpreter. - our Posix code (before and after the patch) leave child process management to the test process in cases of normal termination and keyboard interrupt, meaning that if the test program itself does not signal and wait for its children to terminate then nobody will. The only case where the testsuite driver takes action and signals the process group is after a timeout. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 26 00:03:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Aug 2018 00:03:42 -0000 Subject: [GHC] #15363: Do some cleaning up of the testsuite driver In-Reply-To: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> References: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> Message-ID: <060.1b3d965031edd90985e5792cb564bb10@haskell.org> #15363: Do some cleaning up of the testsuite driver -------------------------------------+------------------------------------- Reporter: lantti | Owner: lantti Type: task | Status: patch Priority: low | Milestone: 8.8.1 Component: Test Suite | 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 lantti): Sorry, never mind. The patch is still unusable. My IO redirection seems to occasionally lock up on Windows. For example test "conc070" seems to be unable to run properly under the new code and eventually timeouts. Somehow I missed this earlier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 26 00:07:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Aug 2018 00:07:10 -0000 Subject: [GHC] #15568: Kind variables in type family aren't quantified in toposorted order Message-ID: <050.0d422903bc51c8d2d5b53b7c9ad7b27a@haskell.org> #15568: Kind variables in type family aren't quantified in toposorted order -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple TypeApplications, TypeFamilies | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Recently, I noticed that an error message I was experiencing differs between GHC 8.4.3 and GHC 8.6.1+. Take this program: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Proxy import GHC.Exts (Any) type family F (a :: j) :: k f :: Proxy a -> Proxy (F (a :: j) :: k) f _ = Proxy :: Proxy (Any :: k) }}} On 8.4.3, you'll get: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs -fprint-explicit-kinds [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:11:7: error: • Couldn't match type ‘Any k’ with ‘F j k a’ Expected type: Proxy k (F j k a) Actual type: Proxy k (Any k) • In the expression: Proxy :: Proxy (Any :: k) In an equation for ‘f’: f _ = Proxy :: Proxy (Any :: k) • Relevant bindings include f :: Proxy j a -> Proxy k (F j k a) (bound at Bug.hs:11:1) | 11 | f _ = Proxy :: Proxy (Any :: k) | ^^^^^^^^^^^^^^^^^^^^^^^^^ }}} But on 8.6.1 and HEAD, you'll instead get: {{{ $ /opt/ghc/8.6.1/bin/ghc Bug.hs -fprint-explicit-kinds [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:11:7: error: • Couldn't match type ‘Any k’ with ‘F k j a’ Expected type: Proxy k (F k j a) Actual type: Proxy k (Any k) • In the expression: Proxy :: Proxy (Any :: k) In an equation for ‘f’: f _ = Proxy :: Proxy (Any :: k) • Relevant bindings include f :: Proxy j a -> Proxy k (F k j a) (bound at Bug.hs:11:1) | 11 | f _ = Proxy :: Proxy (Any :: k) | ^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Notice that on 8.4.3, it displays `F j k a`, but on 8.6.1, it displays `F k j a`! After some digging, it turns out that this is because on 8.6.1, the order of `F`'s kind variables are quantified completely differently! On 8.4.3, we have: {{{ λ> :kind F F :: forall j k. j -> k }}} But on 8.6.1, we have: {{{ λ> :kind F F :: forall k j. j -> k }}} I would prefer the old behavior of 8.4.3, since `j k` is what you get after performing a left-to-right, reverse topological sort on the kind variables of `F`, which is consistent with how type signatures quantify their type variables. Currently, this quirk doesn't matter that much (except for error messages, as shown above), but if/when visible kind application is implemented, it'll be more noticeable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 26 02:06:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Aug 2018 02:06:28 -0000 Subject: [GHC] #15564: Plugin recompilation check panics with inline-java In-Reply-To: <056.17d573a7924d7195f7d3c759e2148800@haskell.org> References: <056.17d573a7924d7195f7d3c759e2148800@haskell.org> Message-ID: <071.ef9d0c9b812f40a84cb8534635086dd1@haskell.org> #15564: Plugin recompilation check panics with inline-java -------------------------------------+------------------------------------- Reporter: | Owner: (none) facundo.dominguez | Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: duplicate | Keywords: plugins, | plugin recompilation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15475 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * status: new => closed * resolution: => duplicate Comment: Using the ghc with the fixes worked, indeed. Thanks for the heads up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 26 02:37:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Aug 2018 02:37:02 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation In-Reply-To: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> References: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> Message-ID: <061.7d0435f4220fac95babbd84b404badd6@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by danilo2): * status: infoneeded => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 26 06:58:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Aug 2018 06:58:56 -0000 Subject: [GHC] #15567: security of package environment files In-Reply-To: <047.60670edf186a46d75607f123c7e6182a@haskell.org> References: <047.60670edf186a46d75607f123c7e6182a@haskell.org> Message-ID: <062.c1ff8326a5fa8a295e1b2eb44e7e31c3@haskell.org> #15567: security of package environment files -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Sven, we don't have to throw the baby out with the bathwater -- for ghc env files to achieve the goal they were invented for they have to be honoured by default, otherwise they become too tedious to use that we can just as well give up on them -- it's like asking to have to opt into `.ghci` files; we can just simply fix the code to follow a similar logic like we did for `.ghci` files: only read them if the permission/ownership are sensible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 26 09:58:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Aug 2018 09:58:57 -0000 Subject: [GHC] #15541: package environment files and the GHC API In-Reply-To: <048.226f5c575460b148605c8a51ca4e89c3@haskell.org> References: <048.226f5c575460b148605c8a51ca4e89c3@haskell.org> Message-ID: <063.771ea9415ffeeadab7923d07cee5c1ee@haskell.org> #15541: package environment files and the GHC API -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: GHC API | Version: 8.4.3 Resolution: | Keywords: package | environment Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #15513 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * priority: high => highest Comment: These issues with package environment files are quite serious so I am bumping the priority -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 26 11:29:15 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Aug 2018 11:29:15 -0000 Subject: [GHC] #15541: package environment files and the GHC API In-Reply-To: <048.226f5c575460b148605c8a51ca4e89c3@haskell.org> References: <048.226f5c575460b148605c8a51ca4e89c3@haskell.org> Message-ID: <063.5ea75a50afc869b7bc3a432f60e0e2cf@haskell.org> #15541: package environment files and the GHC API -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: GHC API | Version: 8.4.3 Resolution: | Keywords: package | environment Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #15513 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 26 11:57:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Aug 2018 11:57:24 -0000 Subject: [GHC] #15541: package environment files and the GHC API In-Reply-To: <048.226f5c575460b148605c8a51ca4e89c3@haskell.org> References: <048.226f5c575460b148605c8a51ca4e89c3@haskell.org> Message-ID: <063.9daed31cab877f931a7add5933c37c31@haskell.org> #15541: package environment files and the GHC API -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: GHC API | Version: 8.4.3 Resolution: | Keywords: package | environment Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #15513 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lspitzner): It is unfortunate and unintended that the scope of these ticket(s) got progressively larger. This was a consequence of my thought-process (1. this is cabal misfeature 2. I can at least fix one usecase if only the API was documented 3. no wait, this transcends my usecase and should be fixed for both ghc UI and API). Sorry about that. So while I'd like to have a ticket "turn package-environment feature off by default" for both UI and API, I don't want to create yet another ticket. I trust you can handle this appropriately. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 26 13:32:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Aug 2018 13:32:23 -0000 Subject: [GHC] #15568: Kind variables in type family aren't quantified in toposorted order In-Reply-To: <050.0d422903bc51c8d2d5b53b7c9ad7b27a@haskell.org> References: <050.0d422903bc51c8d2d5b53b7c9ad7b27a@haskell.org> Message-ID: <065.11a6034c386ebd68b7c404c22fe6f7f6@haskell.org> #15568: Kind variables in type family aren't quantified in toposorted order -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | TypeApplications, TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I figured out what caused this regression. The primary culprit is commit fa29df02a1b0b926afb2525a258172dcbf0ea460 (Refactor ConDecl: Trac #14529). In particular, this commit made a rather suspicious-looking change to `bindHsQTyVars`: {{{#!diff diff --git a/compiler/rename/RnTypes.hs b/compiler/rename/RnTypes.hs index dd66cd3..727744d 100644 --- a/compiler/rename/RnTypes.hs +++ b/compiler/rename/RnTypes.hs @@ -898,23 +905,24 @@ bindHsQTyVars doc mb_in_doc mb_assoc body_kv_occs hsq_bndrs thing_inside ; let -- See Note [bindHsQTyVars examples] for what -- all these various things are doing - bndrs, kv_occs, implicit_bndr_kvs, - implicit_body_kvs, implicit_kvs :: [Located RdrName] - bndrs = map hsLTyVarLocName hs_tv_bndrs - kv_occs = body_kv_occs ++ bndr_kv_occs - implicit_bndr_kvs = filter_occs rdr_env bndrs bndr_kv_occs - implicit_body_kvs = filter_occs rdr_env (implicit_bndr_kvs ++ bndrs) body_kv_occs + bndrs, kv_occs, implicit_kvs :: [Located RdrName] + bndrs = map hsLTyVarLocName hs_tv_bndrs + kv_occs = nubL (body_kv_occs ++ bndr_kv_occs) + implicit_kvs = filter_occs rdr_env bndrs kv_occs -- Deleting bndrs: See Note [Kind- variable ordering] - implicit_kvs = implicit_bndr_kvs ++ implicit_body_kvs - }}} The value of `implicit_kvs` is what's important here, since it determines the order in which kind variables appear in type family kind signatures. In the commit before, we had: {{{#!hs implicit_kvs = implicit_bndr_kvs ++ implicit_body_kvs }}} Which makes sense, as you'd expect the binder kind variables to appear before any kind variables from the body. But after that commit, we now have: {{{#!hs kv_occs = nubL (body_kv_occs ++ bndr_kv_occs) implicit_kvs = filter_occs rdr_env bndrs kv_occs }}} Now, we're putting all of the body kind variables before the binder ones! (Note that the first commit in which you can actually see the `forall k j.` order instead of the old `forall j k.` order is actually 12794287174146f982257cdeffd491e3e23838dc (`Quantify unfixed kind variables in CUSKs`), but that's only because that commit changed the way kind variables were quantified to use `quantifyTyVars` instead of `tyCoVarsOfTypeWellScoped`, causing GHC to be more sensitive to the order of the kind variables in `implicit_kvs`.) I think fixing this is a simple matter of defining `kv_occs = nubL (bndr_kv_occs ++ body_kv_occs)` instead. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 26 13:51:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Aug 2018 13:51:07 -0000 Subject: [GHC] #15568: Kind variables in type family aren't quantified in toposorted order In-Reply-To: <050.0d422903bc51c8d2d5b53b7c9ad7b27a@haskell.org> References: <050.0d422903bc51c8d2d5b53b7c9ad7b27a@haskell.org> Message-ID: <065.3a6936010b41b5869070afee95f4dfce@haskell.org> #15568: Kind variables in type family aren't quantified in toposorted order -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | TypeApplications, TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5108 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5108 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 26 17:39:26 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Aug 2018 17:39:26 -0000 Subject: [GHC] #15569: Constant folding optimises 1 into 3 Message-ID: <050.faecf73a66ba46b12a33656ce184ee72@haskell.org> #15569: Constant folding optimises 1 into 3 -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 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: -------------------------------------+------------------------------------- A recent Hadrian issue [1] led me to finding a rather embarrassing bug: {{{#!hs {-# NOINLINE sub #-} -- This is just subtraction in disguise minus :: Int -> Int -> Int minus x y = (8 - y) - (8 - x) {-# NOINLINE minus #-} main :: IO () main = print (2 `minus` 1) }}} When compiled using `ghc-8.6.0.20180810` without optimisation this prints `1`, as expected, but when compiled with `-O` this prints `3`. Here is the incorrect rewrite rule [2]: {{{#!hs (L y :-: v) :-: (L x :-: w) -> return $ mkL (y-x) `add` (w `add` v) }}} This should be changed to: {{{#!hs (L y :-: v) :-: (L x :-: w) -> return $ mkL (y-x) `add` (w `sub` v) }}} Happy to submit the fix, but I'm not yet fully convinced that there are no other lurking bugs. This whole constant folding business is very error- prone. [1] https://github.com/snowleopard/hadrian/issues/641 [2] https://github.com/ghc/ghc/blob/master/compiler/prelude/PrelRules.hs#L1786 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 26 17:41:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Aug 2018 17:41:08 -0000 Subject: [GHC] #15569: Constant folding optimises 1 into 3 In-Reply-To: <050.faecf73a66ba46b12a33656ce184ee72@haskell.org> References: <050.faecf73a66ba46b12a33656ce184ee72@haskell.org> Message-ID: <065.a2be859cb1abbda3deb3834c4ea16e20@haskell.org> #15569: Constant folding optimises 1 into 3 -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9136 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by snowleopard): * related: => #9136 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 26 17:41:51 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Aug 2018 17:41:51 -0000 Subject: [GHC] #15567: security of package environment files In-Reply-To: <047.60670edf186a46d75607f123c7e6182a@haskell.org> References: <047.60670edf186a46d75607f123c7e6182a@haskell.org> Message-ID: <062.5593edeca02f858619340e80664b1950@haskell.org> #15567: security of package environment files -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by svenpanne): The environment files were not "invented" in any way, they are just an idea copied from Python (probably) in a bad way. The crucial point is: To keep things reproducible and don't accidentally break perfectly fine Haskell scripts/tools/etc., which just happen to be run in the "wrong" working directory, ''opt-out'' is the wrong way to go. I totally understand the motivation of having a "virtual environment"-like feature, which is a great thing in itself, but by all means: Make this explicit, otherwise it's a horrible misfeature, something which other language infrastructures have already learned. I think I'm not alone in this view, see https://github.com/haskell/cabal/issues/4542. I really challenge the idea that virtual environments would be useless when you have to opt-in: This is what e.g. Python people happily do. Clearly documenting e.g. `cabal new-repl`, `cabal new-run` and a few words about how to use `direnv`for people wanting some automatism should be doable. Combine this with ''opt-in'' as the default, and everybody will be happy... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 26 17:49:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Aug 2018 17:49:56 -0000 Subject: [GHC] #15569: Constant folding optimises 1 into 3 In-Reply-To: <050.faecf73a66ba46b12a33656ce184ee72@haskell.org> References: <050.faecf73a66ba46b12a33656ce184ee72@haskell.org> Message-ID: <065.261aa31d6e6e3a627ffe6e0b8eb8298b@haskell.org> #15569: Constant folding optimises 1 into 3 -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9136 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by snowleopard: Old description: > A recent Hadrian issue [1] led me to finding a rather embarrassing bug: > > {{{#!hs > {-# NOINLINE sub #-} > -- This is just subtraction in disguise > minus :: Int -> Int -> Int > minus x y = (8 - y) - (8 - x) > {-# NOINLINE minus #-} > > main :: IO () > main = print (2 `minus` 1) > }}} > > When compiled using `ghc-8.6.0.20180810` without optimisation this prints > `1`, as expected, but when compiled with `-O` this prints `3`. > > Here is the incorrect rewrite rule [2]: > > {{{#!hs > (L y :-: v) :-: (L x :-: w) -> return $ mkL (y-x) `add` (w `add` v) > }}} > > This should be changed to: > > {{{#!hs > (L y :-: v) :-: (L x :-: w) -> return $ mkL (y-x) `add` (w `sub` v) > }}} > > Happy to submit the fix, but I'm not yet fully convinced that there are > no other lurking bugs. This whole constant folding business is very > error-prone. > > [1] https://github.com/snowleopard/hadrian/issues/641 > > [2] > https://github.com/ghc/ghc/blob/master/compiler/prelude/PrelRules.hs#L1786 New description: A recent Hadrian issue [1] led me to finding a rather embarrassing bug: {{{#!hs -- This is just subtraction in disguise minus :: Int -> Int -> Int minus x y = (8 - y) - (8 - x) {-# NOINLINE minus #-} main :: IO () main = print (2 `minus` 1) }}} When compiled using `ghc-8.6.0.20180810` without optimisation this prints `1`, as expected, but when compiled with `-O` this prints `3`. Here is the incorrect rewrite rule [2]: {{{#!hs (L y :-: v) :-: (L x :-: w) -> return $ mkL (y-x) `add` (w `add` v) }}} This should be changed to: {{{#!hs (L y :-: v) :-: (L x :-: w) -> return $ mkL (y-x) `add` (w `sub` v) }}} Happy to submit the fix, but I'm not yet fully convinced that there are no other lurking bugs. This whole constant folding business is very error- prone. [1] https://github.com/snowleopard/hadrian/issues/641 [2] https://github.com/ghc/ghc/blob/master/compiler/prelude/PrelRules.hs#L1786 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 26 17:51:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Aug 2018 17:51:09 -0000 Subject: [GHC] #15569: Constant folding optimises 1 into 3 In-Reply-To: <050.faecf73a66ba46b12a33656ce184ee72@haskell.org> References: <050.faecf73a66ba46b12a33656ce184ee72@haskell.org> Message-ID: <065.5d2c6d5ada2fe5ce349f98002ada1707@haskell.org> #15569: Constant folding optimises 1 into 3 -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9136 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * priority: normal => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 26 21:37:59 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Aug 2018 21:37:59 -0000 Subject: [GHC] #8733: I/O manager causes unnecessary syscalls in send/recv loops In-Reply-To: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> References: <044.69f5a67a5034cd0a8c4c8812f6707e4f@haskell.org> Message-ID: <059.d5074eb992df305ebfc093ccd289142b@haskell.org> #8733: I/O manager causes unnecessary syscalls in send/recv loops -------------------------------------+------------------------------------- Reporter: tibbe | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 26 22:10:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Aug 2018 22:10:28 -0000 Subject: [GHC] #15569: Constant folding optimises 1 into 3 In-Reply-To: <050.faecf73a66ba46b12a33656ce184ee72@haskell.org> References: <050.faecf73a66ba46b12a33656ce184ee72@haskell.org> Message-ID: <065.b1eda3421125b74d910ac54b831c7acb@haskell.org> #15569: Constant folding optimises 1 into 3 -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9136 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Here is a quick fix: https://phabricator.haskell.org/D5109. Adding the above example as a single test and closing this ticket seems a bit unsatisfactory. I think we need to either 1) do some automated correctness checking or 2) refactor the code so that it's more obvious that there are no remaining bugs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Aug 26 22:11:20 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Aug 2018 22:11:20 -0000 Subject: [GHC] #15570: Core transformations generate bad indexCharOffAddr# call Message-ID: <048.6749470bd8e5b16854763831c1951d1e@haskell.org> #15570: Core transformations generate bad indexCharOffAddr# call -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following functions, which only differ in a bang pattern on the local binding `q` in the inner loop: {{{#!hs {-# LANGUAGE BangPatterns #-} {-# LANGUAGE MagicHash #-} module Bug where import GHC.Prim import GHC.Types f :: Int -> String f n_ = go n_ "" where go n cs | n < 62 = let !c = chooseChar62 n in c : cs | otherwise = go q (c : cs) where (q, r) = quotRem n 62 !c = chooseChar62 r chooseChar62 :: Int -> Char {-# INLINE chooseChar62 #-} chooseChar62 (I# n) = C# (indexCharOffAddr# chars62 n) chars62 = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"# g :: Int -> String g n_ = go n_ "" where go n cs | n < 62 = let !c = chooseChar62 n in c : cs | otherwise = go q (c : cs) where (!q, r) = quotRem n 62 -- !!! Note the bang on q !c = chooseChar62 r chooseChar62 :: Int -> Char {-# INLINE chooseChar62 #-} chooseChar62 (I# n) = C# (indexCharOffAddr# chars62 n) chars62 = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"# }}} When building with `-O -fPIC -dynamic -ddump-simpl`, this is the Core I see, with a HEAD checkout from earlier this week built by hadrian: {{{#!hs -- chararacter array, used by both chars62_r30r :: Addr# chars62_r30r = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"# -- Used at the end of Bug.$wgo, in the -9223372036854775808# branch, -- therefore only used by generated Core for f, but not g! lvl_r30s :: Char lvl_r30s = case indexCharOffAddr# chars62_r30r -9223372036854775808# of v_B2 { __DEFAULT -> GHC.Types.C# v_B2 } -- Core for f Rec { Bug.$wgo :: Int# -> [Char] -> (# Char, [Char] #) Bug.$wgo = \ (ww_s2WU :: Int#) (w_s2WR :: [Char]) -> case GHC.Real.even3 of { I# y_a2QI -> -- GHC.Real.even3 == -1 case y_a2QI of { __DEFAULT -> case quotRemInt# ww_s2WU 62# of { (# ipv_a2QN, ipv1_a2QO #) -> case indexCharOffAddr# chars62_r30r ipv1_a2QO of wild2_X4 { __DEFAULT -> case <# ww_s2WU 62# of { __DEFAULT -> Bug.$wgo ipv_a2QN (GHC.Types.: @ Char (GHC.Types.C# wild2_X4) w_s2WR); 1# -> case indexCharOffAddr# chars62_r30r ww_s2WU of wild3_X1G { __DEFAULT -> (# GHC.Types.C# wild3_X1G, w_s2WR #) } } } }; 62# -> case ww_s2WU of wild2_a2QQ { __DEFAULT -> case quotRemInt# wild2_a2QQ 62# of { (# ipv_a2QT, ipv1_a2QU #) -> case indexCharOffAddr# chars62_r30r ipv1_a2QU of wild4_X4 { __DEFAULT -> case <# wild2_a2QQ 62# of { __DEFAULT -> Bug.$wgo ipv_a2QT (GHC.Types.: @ Char (GHC.Types.C# wild4_X4) w_s2WR); 1# -> case indexCharOffAddr# chars62_r30r wild2_a2QQ of wild5_X1G { __DEFAULT -> (# GHC.Types.C# wild5_X1G, w_s2WR #) } } } }; -9223372036854775808# -> case lvl_r30s of { C# v1_B2 -> (# GHC.Types.C# v1_B2, w_s2WR #) } } } } end Rec } Bug.f_go :: Int -> [Char] -> [Char] Bug.f_go = \ (w_s2WQ :: Int) (w1_s2WR :: [Char]) -> case w_s2WQ of { I# ww1_s2WU -> case Bug.$wgo ww1_s2WU w1_s2WR of { (# ww3_s2Xa, ww4_s2Xb #) -> GHC.Types.: @ Char ww3_s2Xa ww4_s2Xb } } f :: Int -> String f = \ (n__aXG :: Int) -> case n__aXG of { I# ww1_s2WU -> case Bug.$wgo ww1_s2WU (GHC.Types.[] @ Char) of { (# ww3_s2Xa, ww4_s2Xb #) -> GHC.Types.: @ Char ww3_s2Xa ww4_s2Xb } } -- Core for g Rec { Bug.$wgo1 :: Int# -> [Char] -> (# Char, [Char] #) Bug.$wgo1 = \ (ww_s2X4 :: Int#) (w_s2X1 :: [Char]) -> case GHC.Real.even3 of { I# y_a2QI -> case y_a2QI of { __DEFAULT -> case quotRemInt# ww_s2X4 62# of { (# ipv_a2QN, ipv1_a2QO #) -> case indexCharOffAddr# chars62_r30r ipv1_a2QO of wild2_X4 { __DEFAULT -> case <# ww_s2X4 62# of { __DEFAULT -> Bug.$wgo1 ipv_a2QN (GHC.Types.: @ Char (GHC.Types.C# wild2_X4) w_s2X1); 1# -> case indexCharOffAddr# chars62_r30r ww_s2X4 of wild3_XY { __DEFAULT -> (# GHC.Types.C# wild3_XY, w_s2X1 #) } } } }; 62# -> case ww_s2X4 of wild2_a2QQ { __DEFAULT -> case quotRemInt# wild2_a2QQ 62# of { (# ipv_a2QT, ipv1_a2QU #) -> case indexCharOffAddr# chars62_r30r ipv1_a2QU of wild4_X4 { __DEFAULT -> case <# wild2_a2QQ 62# of { __DEFAULT -> Bug.$wgo1 ipv_a2QT (GHC.Types.: @ Char (GHC.Types.C# wild4_X4) w_s2X1); 1# -> case indexCharOffAddr# chars62_r30r wild2_a2QQ of wild5_XY { __DEFAULT -> (# GHC.Types.C# wild5_XY, w_s2X1 #) } } } }; -9223372036854775808# -> case GHC.Real.overflowError of wild4_00 { } } } } end Rec } Bug.g_go :: Int -> [Char] -> [Char] Bug.g_go = \ (w_s2X0 :: Int) (w1_s2X1 :: [Char]) -> case w_s2X0 of { I# ww1_s2X4 -> case Bug.$wgo1 ww1_s2X4 w1_s2X1 of { (# ww3_s2Xd, ww4_s2Xe #) -> GHC.Types.: @ Char ww3_s2Xd ww4_s2Xe } } g :: Int -> String g = \ (n__a29X :: Int) -> case n__a29X of { I# ww1_s2X4 -> case Bug.$wgo1 ww1_s2X4 (GHC.Types.[] @ Char) of { (# ww3_s2Xd, ww4_s2Xe #) -> GHC.Types.: @ Char ww3_s2Xd ww4_s2Xe } } }}} Of particular interest is: {{{#!hs -- chararacter array, used by both chars62_r30r :: Addr# chars62_r30r = "0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"# lvl_r30s :: Char lvl_r30s = case indexCharOffAddr# chars62_r30r -9223372036854775808# of v_B2 { __DEFAULT -> GHC.Types.C# v_B2 } }}} which is only used in the Core for `f`, not `g`! We're trying to access index `minBound :: Int` of that array of chars. While this is only used when we pass `minBound` to our function, it is still wrong I think. Moreover, as [https://github.com/snowleopard/hadrian/issues/861 hadrian issue 861] showed, this can lead to... linker errors! Which got fixed by changing the implementation of `iToBase62` in Unique.hs from `f` to `g` :-) Note that when I build the same commit with the make build system, then GHC generates Core close to `g`'s above for _both functions_. I tried describing some of the transformations that occur in [https://github.com/snowleopard/hadrian/issues/641#issuecomment-415881512 this comment] on hadrian's issue tracker. The gist of it is that the lack of strictness in `q` leads GHC to not spotting it early and when we inline `quotRem`/`quotRemInt` and start floating things in/out and distributing `case ... of` branches around, we end up with a dedicated branch in the inner loop for `minBound` which actually makes use of the result of `indexAddrOffAddr#`, as you can see here: {{{#!hs -9223372036854775808# -> -- lvl_r30s is our bad value case lvl_r30s of { C# v1_B2 -> (# GHC.Types.C# v1_B2, w_s2WR #) } }}} whereas this is what this branch looks like for `g`: {{{#!hs -9223372036854775808# -> case GHC.Real.overflowError of wild4_00 { } }}} The `overflowError` is still there and GHC therefore realised that there's no point in computing anything since we always raise an overflow error in that branch. This `overflowError` just disappears in `f`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 00:32:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 00:32:31 -0000 Subject: [GHC] #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL In-Reply-To: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> References: <046.d4cadd0de18785a85fd44eaf74dce48e@haskell.org> Message-ID: <061.3049120515a5f4af78ae43467893ab07@haskell.org> #14021: 8.2.1 deb8 bindist fails to install on Windows 10 WSL -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.3 Component: Build System | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13304 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ivanbakel): I am encountering this issue one Parabola Linux, which pointed me to my use of NTFS probably being the culprit, since it seemed the only thing in common with WSL. This seems to have something to do with the way the modification time is treated in a tar extraction. Tested on my machine with the command used by stack: * Extracting the tarball on ext4 preserves the modification time - the package `.cabal` files are correctly older than the `setup-config` files * Extracting the tarball on ntfs mounted with ntfs-3g makes the modification time equal to the extraction time, and possibly due to the extraction order the `.cabal` file ends up newer than the `setup-config` file If the `setup-config` file is older than the `.cabal` file by modification time, the `reconfigure` step triggers in `Distribution.Simple.getBuildConfig`, and that causes the error in the report, though I don't know why. Otherwise, the package install is successful. There's a temporary work- around where you can just `touch` the `setup-config` file for each package to get around this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 03:25:41 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 03:25:41 -0000 Subject: [GHC] #15569: Constant folding optimises 1 into 3 In-Reply-To: <050.faecf73a66ba46b12a33656ce184ee72@haskell.org> References: <050.faecf73a66ba46b12a33656ce184ee72@haskell.org> Message-ID: <065.837ab774cbb8705933855833ba9ffb15@haskell.org> #15569: Constant folding optimises 1 into 3 -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9136 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: hsyl20 (added) Comment: Yes, I think we are going to need to revert Phab:D2858 for now. The fact that this snuck through CI until now is deeply concerning and I'm also far from convinced that there aren't more bugs lurking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 06:54:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 06:54:53 -0000 Subject: [GHC] #15508: concprog001 fails with various errors (was: concprog001 fails with various errors when compiled with -prof) In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.046a31308dc93d4e00a0c002d0d4e7fe@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5051 Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 09:13:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 09:13:19 -0000 Subject: [GHC] #14915: T2783 fails with the threaded1 way In-Reply-To: <048.6a264df023f86951375f2289b1ed8d61@haskell.org> References: <048.6a264df023f86951375f2289b1ed8d61@haskell.org> Message-ID: <063.2bc8851de3523516d7cc36ecfcf105cd@haskell.org> #14915: T2783 fails with the threaded1 way -----------------------------------+-------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: T2783 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Comment (by AndreasK): I just hit this issue when I introduced a loop in a branch of GHC by mistake (based on 8.4.1). I'm running windows so doesn't seem to be an os specific issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 09:28:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 09:28:19 -0000 Subject: [GHC] #14915: T2783 fails with the threaded1 way In-Reply-To: <048.6a264df023f86951375f2289b1ed8d61@haskell.org> References: <048.6a264df023f86951375f2289b1ed8d61@haskell.org> Message-ID: <063.54b13a3386be03847dfc3c113558b235@haskell.org> #14915: T2783 fails with the threaded1 way -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: T2783 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * os: Linux => Unknown/Multiple -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 10:02:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 10:02:56 -0000 Subject: [GHC] #15571: Eager AP_STACK blackholing causes incorrect size info for sanity checks Message-ID: <043.9213207e6a514a137db4ef0469470bf7@haskell.org> #15571: Eager AP_STACK blackholing causes incorrect size info for sanity checks -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Runtime | Version: 8.5 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15508 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- While debugging #15508 I found a case where eager blackholing in AP_STACK causes `closure_sizeW()` to return incorrect size, which in turn causes incorrect slop zeroing by `OVERWRITING_CLOSURE()`, which breaks sanity checks. To reproduce, cd into `testsuite/tests/concurrent/prog001`, then: {{{ $ ghc-stage2 Mult.hs -fforce-recomp -debug -rtsopts $ ./Mult +RTS -DS Mult: internal error: checkClosure: stack frame (GHC version 8.7.20180825 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Mult +RTS -DS }}} Here's how the problem occurs: 1. Allocate an AP_STACK in a generation during a GC. 2. Evaluate the AP_STACK. The entry code first WHITEHOLEs and then eagerly BLACKHOLEs it. At this point size of the STACK becomes 2 because that's the size of (eager or not) BLACKHOLE. 3. To start a GC the thread does `threadPaused`, which in line 342 actually BLACKHOLEs the eager blackhole (is this part really correct?) and zeros the slop, but because the eager blackhole has the same size as BLACKHOLE it doesn't actually zero the stack frames in the original AP_STACK's payload. 4. In the next GC, in pre-GC sanity check we check the whole heap. When checking the generation that the BLACKHOLE (the AP_STACK that became a BLACKHOLE in step (2)) resides in we check the closure, and then check `closure + 2` (2 is the size of BLACKHOLE) instead of `closure + `, and end up checking a stack frame of the original AP_STACK. This causes the sanity check to fail because we don't expect to see a stack frame outside of a stack. In summary, normally when blackhole an object we zero the space after the blackhole (i.e. some part of the original object's payload) so that in sanity checks we can skip over that space, but we can't do this when eagerly blackholing (because the payload of the original object will be used) which causes sanity check failures. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 10:03:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 10:03:18 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.3d4d9e8bb48a6ce49a7c53e453b57d8d@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: => #15571 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 10:19:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 10:19:47 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.24c00cffe90c806763f7b8078b201bef@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:84 simonpj]: > 2. I think you mean that `NDFV` keeps a set of forall-bound variables, and checks in that set before adding to the accumulator. But foralls are rare (I think), so the set will typically be empty. Well, considering the `del...` function for `FV` / `NDFV`: {{{#!hs delNDFV :: Var -> NDFV -> NDFV delNDFV var fv fv_cand !in_scope acc = fv fv_cand (extendVarSet in_scope var) acc }}} ...it turns out that *all* "deletions" from the "set" are implemented as adding to the `in_scope` set. Despite the name, the data structure doesn't really care whether they are really forall-bound variables. They might be though - I don't know if there are other reasons to delete from a free-var set. > 3. That leaves the accumulator-style as the main candidate. > > As Richard says, though, the way to find out is to try it one thing at a time. Yes, absolutely. Will do exactly that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 10:26:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 10:26:50 -0000 Subject: [GHC] #14915: T2783 fails with the threaded1 way In-Reply-To: <048.6a264df023f86951375f2289b1ed8d61@haskell.org> References: <048.6a264df023f86951375f2289b1ed8d61@haskell.org> Message-ID: <063.bb9338b5acaed1854c7bb11166ad8936@haskell.org> #14915: T2783 fails with the threaded1 way -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: T2783 Blocked By: | Blocking: Related Tickets: #15241 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: => #15241 Comment: Also reported in #15241. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 10:27:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 10:27:18 -0000 Subject: [GHC] #15241: Validate failures in sanity way In-Reply-To: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> References: <043.d11008dde218db35b7a51fc1896a3cac@haskell.org> Message-ID: <058.428f3fc78539f3245ad2d318a5cc9e50@haskell.org> #15241: Validate failures in sanity way -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14915 | Differential Rev(s): Phab:D4839 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: => #14915 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 10:38:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 10:38:21 -0000 Subject: [GHC] #15560: Full laziness destroys opportunities for join points In-Reply-To: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> References: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> Message-ID: <062.a5fa2e7f00f6b9658fe709ff25b8720d@haskell.org> #15560: Full laziness destroys opportunities for join points -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14287 #13286 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * related: #14287 => #14287 #13286 Comment: It seems this was changed deliberately in #13286. The ticket does mention examples where join points become top level functions as having improved but doesn't contain any performance metrics to judge the impact. I can see how it might be beneficial for exported functions, but I'm not yet convinced that this is better in general. I've also looked at the core output of the two testsuite files and at least at O2 there seems to be the same amount of floating happening with 8.0.2 and 8.4. I also don't think we will get much benefit out of the original example. Looking at the floated code: {{{ $wg_s6x5 [InlPrag=[0], Occ=LoopBreaker] :: Int# -> Int# -> Int# -> Int# $wg_s6x5 (ww5_s6wV :: Int#) (ww6_s6wZ :: Int#) (ww7_s6x3 :: Int#) = case remInt# ww6_s6wZ 2# of { __DEFAULT -> case ww6_s6wZ of wild5_Xen { __DEFAULT -> jump $wg_s6x5 (*# ww5_s6wV ww5_s6wV) (quotInt# (-# wild5_Xen 1#) 2#) (*# ww5_s6wV ww7_s6x3); 1# -> *# ww5_s6wV ww7_s6x3 }; 0# -> $wg_s6x5 (*# ww5_s6wV ww5_s6wV) (quotInt# ww6_s6wZ 2#) ww7_s6x3 $wf_s6xg [InlPrag=[0], Occ=LoopBreaker] :: Int# -> Int# -> Int# $wf_s6xg (ww3_X6Hi :: Int#) (ww4_s6xe :: Int#) = case remInt# ww4_s6xe 2# of { __DEFAULT -> case ww4_s6xe of wild3_Xe3 { __DEFAULT -> $wg_s6x5 (*# ww3_X6Hi ww3_X6Hi) (quotInt# (-# wild3_Xe3 1#) 2#) ww3_X6Hi; 1# -> ww3_X6Hi }; 0# -> $wf_s6xg (*# ww3_X6Hi ww3_X6Hi) (quotInt# ww4_s6xe 2#) GHC.Real.$w$s^1 [InlPrag=[0]] :: Int -> Int# -> Int# GHC.Real.$w$s^1 = \ (w_s6xh :: Int) (ww_s6xl :: Int#) -> case tagToEnum# @ Bool (<# ww_s6xl 0#) of { False -> case ww_s6xl of wild1_XdK { __DEFAULT -> case w_s6xh of { I# ww2_s6xa -> $wf_s6xg ww2_s6xa wild1_XdK }; 0# -> 1# }; True -> case GHC.Real.^2 of wild1_00 { } } }}} * For exponent < 0 we throw an exception so we can probably ignore that case when it comes to performance. * For exponent == 0 there is an advantage IF `GHC.Real.$w$s^1` get's inlined. But an exponent of zero seems like an unlikely case to me. * For exponents > 0 it depends heavily on how much get's inlined. * If all get inlined (essentially undoing the floating) we save nothing as the unfloated variant would have been inlined as well. * If we inline `GHC.Real.$w$s^1` and `$wf_s6xg` we save at best one call overhead if we don't jump into `wg_s6x5`, otherwise we save nothing. * If nothing get's inlined we are worse off as we now have at least as much overhead if not more should we jump into the floated functions. On the bright side the floated bindings work only on unboxed int's so might not cause an additional stack check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 10:57:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 10:57:43 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.494cf46fa9a924fa8d86245ebb18e0da@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nfrisby Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Changes (by sgraf): * related: #8763 => #8763 #13286 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 11:05:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 11:05:57 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.f4d8ad534c8b7959889dec5aac19044a@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Changes (by sgraf): * owner: nfrisby => sgraf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 11:11:40 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 11:11:40 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.91ceb1d1689024c65103349c450e48af@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): OK, so; replacing the `delNDFV` function with an implementation that doesn't touch the `in_scope` set at all, and instead removes items from the `acc` set, we get practically identical performance as with `NDFV` in its previous incarnation. Which means that 2. is not the culprit; the `in_scope` set seems to not make a difference, suggesting that we aren't really deleting a substantial number of elements from the set here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 11:29:02 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 11:29:02 -0000 Subject: [GHC] #14915: T2783 fails with the threaded1 way In-Reply-To: <048.6a264df023f86951375f2289b1ed8d61@haskell.org> References: <048.6a264df023f86951375f2289b1ed8d61@haskell.org> Message-ID: <063.6a0d40a46b5e44f9971c1bce56965da6@haskell.org> #14915: T2783 fails with the threaded1 way -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: T2783 Blocked By: | Blocking: Related Tickets: #15241 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: simonmar (added) Comment: It seems to me that the assertion is wrong. Here's the stack of the TSO when we call `threadPaused()`: (the full stack is larger, only showing the relevant part here) {{{ >>> call printStack(tso->stackobj) RET_FUN (0x7af578) (type=5) <------------------------ 0x42000060a0 stk[91] (0x42000060b0) = 0x7af578 stg_ap_pp_info <------------------------------------- 0x42000060c0 stk[88] (0x42000060c8) = 0x42000084f9 stk[87] (0x42000060d0) = 0x4200008428 NORMAL_UPDATE_FRAME(0x71da08,0x4200008428) <--------- 0x42000060d8 RET_SMALL (0x668d50) <------------------------------- 0x42000060e8 stk[83] (0x42000060f0) = 0x42000084e9 stk[82] (0x42000060f8) = 0x4200008428 NORMAL_UPDATE_FRAME(0x71da08,0x4200008428) <--------- 0x4200006100 assertion fails here ... }}} So we have multiple update frames in this stack that updates same closure at 0x4200008428 which is originally a THUNK: {{{ >>> call printClosure(0x4200008428) THUNK(0x404cf8) }}} which becomes a BLACKHOLE as expected when we see it the first time in stack frame at 0x42000060d8. Then two iterations later we see the same closure in the update frame at 0x4200006100 but the assertion assumes that it's either not a BLACKHOLE or if it is then it's BLACKHOLEd by another thread. It seems to me that this assertion gives a false positive when we have a `<>` and should be updated (removed?). simonmar, am I right that this case can legitimately happen when we have a loop? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 11:33:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 11:33:48 -0000 Subject: [GHC] #15569: Constant folding optimises 1 into 3 In-Reply-To: <050.faecf73a66ba46b12a33656ce184ee72@haskell.org> References: <050.faecf73a66ba46b12a33656ce184ee72@haskell.org> Message-ID: <065.67d5516230e9f913842b40b7b0753229@haskell.org> #15569: Constant folding optimises 1 into 3 -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9136 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): Ouch, my bad :/ I triple checked those rules but it wasn't enough. Some automated correctness checking would be good indeed... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 13:09:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 13:09:20 -0000 Subject: [GHC] #15566: Implement minimumOn, maximumOn to mirror sortOn In-Reply-To: <046.9955d151a0d096fa05b640c0d0259990@haskell.org> References: <046.9955d151a0d096fa05b640c0d0259990@haskell.org> Message-ID: <061.a891eb30c2a9e7b6498a83b2fcaf7cf3@haskell.org> #15566: Implement minimumOn, maximumOn to mirror sortOn -------------------------------------+------------------------------------- Reporter: Garciat | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Research | needed Component: libraries/base | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Garciat): Well, `maximumBy` and `minimumBy` are already partial by their use of `Foldable.foldl1`, so I'm thinking it's probably alright to do the more obvious: {{{#!hs import Data.Foldable import Data.Function (on) maximumOn :: (Foldable t, Ord b) => (a -> b) -> t a -> a maximumOn f = maximumBy (compare `on` f) minimumOn :: (Foldable t, Ord b) => (a -> b) -> t a -> a minimumOn f = minimumBy (compare `on` f) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 13:39:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 13:39:27 -0000 Subject: [GHC] #15502: -ddump-splices truncates Integer literals to Int literals In-Reply-To: <047.99c2e69e35ad36d7625dca8406cf953c@haskell.org> References: <047.99c2e69e35ad36d7625dca8406cf953c@haskell.org> Message-ID: <062.9fc592d13d626dd4ec556cc2436ee310@haskell.org> #15502: -ddump-splices truncates Integer literals to Int literals -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5089 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"7a3cda534d1447c813aa37cdd86e20b8d782cb02/ghc" 7a3cda53/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7a3cda534d1447c813aa37cdd86e20b8d782cb02" Fix #15502 by not casting to Int during TH conversion Summary: When turning an `IntegerL` to an `IntegralLit` during TH conversion, we were stupidly casting an `Integer` to an `Int` in order to determine how it should be pretty-printed. Unsurprisingly, this causes problems when the `Integer` doesn't lie within the bounds of an `Int`, as demonstrated in #15502. The fix is simple: don't cast to an `Int`. Test Plan: make test TEST=T15502 Reviewers: bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #15502 Differential Revision: https://phabricator.haskell.org/D5089 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 13:39:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 13:39:27 -0000 Subject: [GHC] #15550: Names of RULES aren't quoted in -ddump-splices In-Reply-To: <050.b5daffb0170f6fb061ff2380766e1195@haskell.org> References: <050.b5daffb0170f6fb061ff2380766e1195@haskell.org> Message-ID: <065.b67d8dbf2827a6f8d5ed2ddba0fe6e72@haskell.org> #15550: Names of RULES aren't quoted in -ddump-splices -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5090 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"5e6cf2a9301a5473ff9c5319b96de941b1ad72dd/ghc" 5e6cf2a9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5e6cf2a9301a5473ff9c5319b96de941b1ad72dd" Fix #15550 by quoting RULE names during TH conversion Summary: When converting a `RuleP` to a GHC source `RuleD` during TH conversion, we were stupidly not double-quoting the name of the rule. Easily fixed. Test Plan: make test TEST=T15550 Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #15550 Differential Revision: https://phabricator.haskell.org/D5090 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 13:39:28 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 13:39:28 -0000 Subject: [GHC] #10859: Generated Eq instance associates && wrongly In-Reply-To: <046.4f10604a3fa32deb15c9056d38ba731c@haskell.org> References: <046.4f10604a3fa32deb15c9056d38ba731c@haskell.org> Message-ID: <061.43ca487148631bb69362ef665a6269d0@haskell.org> #10859: Generated Eq instance associates && wrongly -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonpj Type: bug | Status: patch Priority: lowest | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: deriving, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10858 | Differential Rev(s): Phab:D5104 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"2d953a60489ba30433e5f2fe27c50aa9da75f802/ghc" 2d953a6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2d953a60489ba30433e5f2fe27c50aa9da75f802" Fix #10859 by using foldr1 while deriving Eq instances Summary: Previously, we were using foldl1 instead, which led to the derived code to be wrongly associated. Test Plan: ./validate Reviewers: RyanGlScott, nomeata, simonpj, bgamari Reviewed By: RyanGlScott, nomeata Subscribers: rwbarton, carter GHC Trac Issues: #10859 Differential Revision: https://phabricator.haskell.org/D5104 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 13:39:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 13:39:27 -0000 Subject: [GHC] #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation In-Reply-To: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> References: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> Message-ID: <061.180c86938d6ea9d71aead0feef538415@haskell.org> #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation -------------------------------------+------------------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Research Component: Compiler (Type | needed checker) | Version: 8.4.3 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5087 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"744b034dc2ea5b7b82b5586a263c12f231e803f1/ghc" 744b034d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="744b034dc2ea5b7b82b5586a263c12f231e803f1" Take strict fields into account in coverage checking Summary: The current pattern-match coverage checker implements the formalism presented in the //GADTs Meet Their Match// paper in a fairly faithful matter. However, it was discovered recently that there is a class of unreachable patterns that //GADTs Meet Their Match// does not handle: unreachable code due to strict argument types, as demonstrated in #15305. This patch therefore goes off-script a little and implements an extension to the formalism presented in the paper to handle this case. Essentially, when determining if each constructor can be matched on, GHC checks if its associated term and type constraints are satisfiable. This patch introduces a new form of constraint, `NonVoid(ty)`, and checks if each constructor's strict argument types satisfy `NonVoid`. If any of them do not, then that constructor is deemed uninhabitable, and thus cannot be matched on. For the full story of how this works, see `Note [Extensions to GADTs Meet Their Match]`. Along the way, I did a little bit of much-needed refactoring. In particular, several functions in `Check` were passing a triple of `(ValAbs, ComplexEq, Bag EvVar)` around to represent a constructor and its constraints. Now that we're adding yet another form of constraint to the mix, I thought it appropriate to turn this into a proper data type, which I call `InhabitationCandidate`. Test Plan: make test TEST=T15305 Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15305 Differential Revision: https://phabricator.haskell.org/D5087 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 13:39:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 13:39:27 -0000 Subject: [GHC] #15551: TH-reified type classes have redundant tyvars/class constraints on each method In-Reply-To: <050.f558426d191105778fc98c9fddcec266@haskell.org> References: <050.f558426d191105778fc98c9fddcec266@haskell.org> Message-ID: <065.62880b7ba3d89917ad9fe35ec3e3dbe3@haskell.org> #15551: TH-reified type classes have redundant tyvars/class constraints on each method -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5088 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"6e765aebbe0a565f2476b522a49faf8edb9a93ee/ghc" 6e765ae/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6e765aebbe0a565f2476b522a49faf8edb9a93ee" Don't reify redundant class method tyvars/contexts Summary: Currently, reifying classes produces class methods with redundant tyvars and class contexts in their type signatures, such as in the following: ```lang=haskell class C a where method :: forall a. C a => a ``` Fixing this is very straightforward: just apply `tcSplitMethodTy` to the type of each class method to lop off the redundant parts. It's possible that this could break some TH code in the wild that assumes the existence of these tyvars and class contexts, so I'll advertise this change in the release notes just to be safe. Test Plan: make test TEST="TH_reifyDecl1 T9064 T10891 T14888" Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #15551 Differential Revision: https://phabricator.haskell.org/D5088 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 13:43:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 13:43:38 -0000 Subject: [GHC] #10859: Generated Eq instance associates && wrongly In-Reply-To: <046.4f10604a3fa32deb15c9056d38ba731c@haskell.org> References: <046.4f10604a3fa32deb15c9056d38ba731c@haskell.org> Message-ID: <061.8cf1ade96a42aa26f6012134e8ebdca8@haskell.org> #10859: Generated Eq instance associates && wrongly -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonpj Type: bug | Status: merge Priority: lowest | Milestone: 8.6.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: deriving, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10858 | Differential Rev(s): Phab:D5104 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => merge * milestone: => 8.6.1 Comment: If it's not too late, this can be merged to 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 13:44:41 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 13:44:41 -0000 Subject: [GHC] #15551: TH-reified type classes have redundant tyvars/class constraints on each method In-Reply-To: <050.f558426d191105778fc98c9fddcec266@haskell.org> References: <050.f558426d191105778fc98c9fddcec266@haskell.org> Message-ID: <065.bceadac6365db51c029fe2633872c404@haskell.org> #15551: TH-reified type classes have redundant tyvars/class constraints on each method -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5088 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => merge * milestone: 8.8.1 => 8.6.1 Comment: If it's not too late, this can be merged to 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 13:46:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 13:46:04 -0000 Subject: [GHC] #15551: TH-reified type classes have redundant tyvars/class constraints on each method In-Reply-To: <050.f558426d191105778fc98c9fddcec266@haskell.org> References: <050.f558426d191105778fc98c9fddcec266@haskell.org> Message-ID: <065.be74d997d4305fe0a2438f5795e3a607@haskell.org> #15551: TH-reified type classes have redundant tyvars/class constraints on each method -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5088 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: merge => closed * resolution: => fixed * milestone: 8.6.1 => 8.8.1 Comment: I'm going to request that this //not// be merged to GHC 8.6.1, since it has the potential to break code which assumes the existence of these redundant tyvars/class constraints when reified. (I'll update the Migration Guide for 8.8 to address this.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 13:46:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 13:46:52 -0000 Subject: [GHC] #15551: TH-reified type classes have redundant tyvars/class constraints on each method In-Reply-To: <050.f558426d191105778fc98c9fddcec266@haskell.org> References: <050.f558426d191105778fc98c9fddcec266@haskell.org> Message-ID: <065.49a140c2fc048eb0ea5757d3c2fa2857@haskell.org> #15551: TH-reified type classes have redundant tyvars/class constraints on each method -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5088 Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): I'm sorry, I updated the wrong ticket. I agree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 13:48:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 13:48:22 -0000 Subject: [GHC] #15502: -ddump-splices truncates Integer literals to Int literals In-Reply-To: <047.99c2e69e35ad36d7625dca8406cf953c@haskell.org> References: <047.99c2e69e35ad36d7625dca8406cf953c@haskell.org> Message-ID: <062.7eb7d9525271dffed8ec431caa2d37df@haskell.org> #15502: -ddump-splices truncates Integer literals to Int literals -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5089 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => merge Comment: If it's not too late, this can be merged to 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 13:49:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 13:49:35 -0000 Subject: [GHC] #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation In-Reply-To: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> References: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> Message-ID: <061.9c5e30ba212654e73168bbddb56ce307@haskell.org> #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation -------------------------------------+------------------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Research Component: Compiler (Type | needed checker) | Version: 8.4.3 Resolution: fixed | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5087 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 13:50:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 13:50:33 -0000 Subject: [GHC] #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation In-Reply-To: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> References: <046.1c1862324fae7717e5abc0471fd56871@haskell.org> Message-ID: <061.e6b32a420523c08b1fc2eb4a96f0d251@haskell.org> #15305: Erroneous "non-exhaustive pattern match" using nested GADT with strictness annotation -------------------------------------+------------------------------------- Reporter: jkoppel | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.4.3 checker) | Keywords: Resolution: fixed | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: error/warning at compile-time | pmcheck/should_compile/T15305 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5087 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => pmcheck/should_compile/T15305 * milestone: Research needed => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 13:53:14 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 13:53:14 -0000 Subject: [GHC] #15550: Names of RULES aren't quoted in -ddump-splices In-Reply-To: <050.b5daffb0170f6fb061ff2380766e1195@haskell.org> References: <050.b5daffb0170f6fb061ff2380766e1195@haskell.org> Message-ID: <065.89efc7f9bf29c5b0c71ea78be03373ab@haskell.org> #15550: Names of RULES aren't quoted in -ddump-splices -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5090 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => merge Comment: If it's not too late, this can be merged to 8.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 14:01:23 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 14:01:23 -0000 Subject: [GHC] #15566: Implement minimumOn, maximumOn to mirror sortOn In-Reply-To: <046.9955d151a0d096fa05b640c0d0259990@haskell.org> References: <046.9955d151a0d096fa05b640c0d0259990@haskell.org> Message-ID: <061.00cdab121b7115b05ad13aff2b60193d@haskell.org> #15566: Implement minimumOn, maximumOn to mirror sortOn -------------------------------------+------------------------------------- Reporter: Garciat | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Research | needed Component: libraries/base | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D5110 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Garciat): * differential: => D5110 Comment: Went ahead and drafted a Phab diff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 17:15:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 17:15:58 -0000 Subject: [GHC] #15569: Constant folding optimises 1 into 3 In-Reply-To: <050.faecf73a66ba46b12a33656ce184ee72@haskell.org> References: <050.faecf73a66ba46b12a33656ce184ee72@haskell.org> Message-ID: <065.07f4e90e848547e39d97f124e6659258@haskell.org> #15569: Constant folding optimises 1 into 3 -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9136 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 17:41:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 17:41:48 -0000 Subject: [GHC] #15484: MultiLayerModules and T13701 timeout on i386 Linux In-Reply-To: <046.f49e8907dc2fd082faa408fb71333802@haskell.org> References: <046.f49e8907dc2fd082faa408fb71333802@haskell.org> Message-ID: <061.d18715ecea7b2a476cd108df362682ff@haskell.org> #15484: MultiLayerModules and T13701 timeout on i386 Linux -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:5103 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * owner: (none) => alpmestan -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 17:45:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 17:45:33 -0000 Subject: [GHC] #15383: T3171 doesn't terminate with Interrupted message on Darwin In-Reply-To: <046.1d648bf17453b21fb35b42043bd02c26@haskell.org> References: <046.1d648bf17453b21fb35b42043bd02c26@haskell.org> Message-ID: <061.4d283301fb242445680bf9abf89c09e3@haskell.org> #15383: T3171 doesn't terminate with Interrupted message on Darwin ---------------------------------+-------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15463 | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by alpmestan): * cc: alpmestan (added) Comment: It fails every now and then (not always!) on i386 linux indeed: https://circleci.com/gh/ghc/ghc-diffs/269 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 17:50:40 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 17:50:40 -0000 Subject: [GHC] #15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite In-Reply-To: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> References: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> Message-ID: <061.7eac5fc5b47f756815479cc8a41c1c23@haskell.org> #15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 18:23:42 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 18:23:42 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation In-Reply-To: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> References: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> Message-ID: <061.f47b598331a2e0284e1922648d19b7bb@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: 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): * Attachment "Main.hs" added. Variant of Main.hs I used for debugging -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 18:27:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 18:27:45 -0000 Subject: [GHC] #15572: TH improperly converts promoted data cons in ConT Message-ID: <050.0e46c20217a7ed360417cc67421971cd@haskell.org> #15572: TH improperly converts promoted data cons in ConT -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Template | Version: 8.4.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: -------------------------------------+------------------------------------- If you compile the following program: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where import Language.Haskell.TH $([d| type AbsoluteUnit1 = '() |]) $(pure [TySynD (mkName "AbsoluteUnit2") [] (ConT '())]) }}} {{{ $ /opt/ghc/8.6.1/bin/ghci Bug.hs GHCi, version 8.6.0.20180810: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:8:3-33: Splicing declarations [d| type AbsoluteUnit1_a1HN = '() |] ======> type AbsoluteUnit1_a4qs = '() Bug.hs:9:3-54: Splicing declarations pure [TySynD (mkName "AbsoluteUnit2") [] (ConT '())] ======> type AbsoluteUnit2 = () }}} You'll notice an unusual discrepancy between the two `-ddump-splices` logs. In the first one: {{{#!hs type AbsoluteUnit1_a4qs = '() }}} The `'()` constructor is properly preceded with a single quote. In the second one, however: {{{#!hs type AbsoluteUnit2 = () }}} `'()` incorrectly appears without a single quote! The culprit is in the way `Convert` [http://git.haskell.org/ghc.git/blob/154d4e219cc0cebbef8a845609bd63ec45fdbea6:/compiler/hsSyn/Convert.hs#l1307 handles] `ConT`: {{{#!hs ConT nm -> do { nm' <- tconName nm ; mk_apps (HsTyVar noExt NotPromoted (noLoc nm')) tys'} }}} This code naïvely assumes that `ConT` will never contain a promoted data constructor name by hardcoding `NotPromoted`. We really ought to be checking if `nm'` is a data con `RdrName` here and using `Promoted` if so, and `NotPromoted` otherwise. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 18:35:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 18:35:24 -0000 Subject: [GHC] #15572: TH improperly converts promoted data cons in ConT In-Reply-To: <050.0e46c20217a7ed360417cc67421971cd@haskell.org> References: <050.0e46c20217a7ed360417cc67421971cd@haskell.org> Message-ID: <065.d3dffc2877cbfbe850257adbcd876856@haskell.org> #15572: TH improperly converts promoted data cons in ConT -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5112 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5112 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 19:37:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 19:37:05 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation In-Reply-To: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> References: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> Message-ID: <061.6aad26ae4eb87d79062a5547f6777370@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: 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): Thanks, that's much easier to reproduce. So, it seems that the performance gap stems from the fact that the call to `runTokenParser` in `test0` is specialised to the specific grammar. That is not the case for `test1`, because its definition doesn't get eta- expanded for some reason. Note that the correct arity 1 is detected: {{{ -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} test1 [InlPrag=NOINLINE] :: Text -> Result [LclIdX, Arity=1, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 20 60}] test1 = runTokenParser testGrammar1 }}} If `test1` would be eta-expanded, the call to `runTokenParser` becomes saturated and could (in theory) be specialised to `testGrammar1`. Except manual eta-expansion (e.g. `test1 t = runTokenParser testGrammar1 t` shows that it's not enough for SpecConstr to pick this up. Ironically, the problem seems to be related to the `INLINE` pragma on `testGrammar1`. If you omit it, the call in `test1` specialises properly. Even CSE can unify `testGrammar1` and the floated out grammar binding from `test0`, which wasn't possible before because of the different pragmas I suppose. So, the fix to apply in your situation seems to be to eta-expand `test1` and omit the `INLINE` pragma. As to /why/ that fixes performance, I'm really at a loss. It's probably related to the fact that the unfolding attached to `testGrammar1` isn't `CONLIKE`, whereas the RHS at the time when SpecConstr runs is. I can't find any relevant code in SpecConstr that looks at unfoldings of /local/ ids, though. Perhaps I'll find time to look into this some more tomorrow. P.S.: `test2` fails to specialise completely in a similar way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 21:46:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 21:46:51 -0000 Subject: [GHC] #15559: fromJust has no HasCallStack In-Reply-To: <046.0c0fc309394993486a792a626e8db1e1@haskell.org> References: <046.0c0fc309394993486a792a626e8db1e1@haskell.org> Message-ID: <061.837e2106919c1cd1b5c1b3ba2c61ff8f@haskell.org> #15559: fromJust has no HasCallStack -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I really like GHC's internal `HasDebugCallStack`, which disappears (that is, becomes `()`) when `DEBUG` is not defined via CPP and becomes `HasCallStack` when `DEBUG` is defined. As far as I know, there's no standard way to mark a build meant for debugging, but perhaps there should be. Then, we could do the same for all applications instead of just GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 22:04:44 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 22:04:44 -0000 Subject: [GHC] #15546: Display coaxiom branch incompatibilities in GHCi In-Reply-To: <044.c77ffe997f2d99b3fbec7a544251677f@haskell.org> References: <044.c77ffe997f2d99b3fbec7a544251677f@haskell.org> Message-ID: <059.077af1460c68e948633e0327ae32e005@haskell.org> #15546: Display coaxiom branch incompatibilities in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: TypeFamilies, | GHCi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5097 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Compatibility is a user-facing issue. See [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #compatibility-and-apartness-of-type-family-equations the manual]. Here is an example: {{{#!hs type family b1 && b2 where True && b2 = b2 False && b2 = False b1 && True = b1 b2 && False = False b && b = b }}} {{{ λ> :kind! forall b. b && True forall b. b && True :: Bool = b }}} Note that the first two equations unify with the target `b && True`. Normally, this means that any later equations wouldn't apply. But because the first two equations are both compatible with the third, we don't let the fact that they unify hold up reduction via the third equation, as we can see. I thus agree that the ability to print out incompatibilities is sometimes helpful for users, not just implementors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 22:13:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 22:13:15 -0000 Subject: [GHC] #15552: Infinite loop/panic with an existential type. In-Reply-To: <050.eb5168d400b4a4211e35d29d96945d09@haskell.org> References: <050.eb5168d400b4a4211e35d29d96945d09@haskell.org> Message-ID: <065.17a8627bae0efd6c8c7d35ccea9b4385@haskell.org> #15552: Infinite loop/panic with an existential type. -------------------------------------+------------------------------------- Reporter: howtonotwin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: TypeInType, | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14723 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Patch looks fine. As for the larger plan: I like all of it, including separating `TcType` from `Type`. Could we also remove `TcTyVar` from the `Var` type? Then we could statically guarantee that no `TcTyVar`s are in Core. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 22:47:30 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 22:47:30 -0000 Subject: [GHC] #7741: Add SIMD support to x86/x86_64 NCG In-Reply-To: <047.ec0118457b1e4a3b6ea3c008b0b9e4f2@haskell.org> References: <047.ec0118457b1e4a3b6ea3c008b0b9e4f2@haskell.org> Message-ID: <062.5e9708b035062f9a66a79a98c2294373@haskell.org> #7741: Add SIMD support to x86/x86_64 NCG -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: abhir00p Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: SIMD Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #3557 | Differential Rev(s): Wiki Page: wiki:SIMD | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 22:58:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 22:58:26 -0000 Subject: [GHC] #15529: runtime bug when profiling retainers In-Reply-To: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> References: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> Message-ID: <061.96cca149fc147a391d489f46b99c67c4@haskell.org> #15529: runtime bug when profiling retainers -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5075 Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): I've tried reducing the program so that we could add a testcase. However, the result still has 4 dependencies and it's very fragile. It converts a list to hashset and back; it has a function that ignores its argument; it uses verboseCheckWith with a property that is const True. If any of those are simplified, the panic disappears. I don't see a way to add a sensible test case based on it. For the record, the reduced program is below (needs QuickCheck, text, quickcheck-instances, unordered-containers). {{{ #!hs {-# OPTIONS -Wall #-} module Main (main) where import qualified Data.HashSet as HS import qualified Data.Text.Lazy as T import Test.QuickCheck import Test.QuickCheck.Instances () data T = Ter T.Text [T.Text] deriving (Show) letters :: HS.HashSet Char letters = HS.fromList ['a'..'z'] arbitraryT :: () -> Gen T arbitraryT _ = do a <- elements (HS.toList letters) b <- arbitrary return $ Ter (T.singleton a) b data GroupTemplateDeclaration = GTD T T deriving (Show) instance Arbitrary GroupTemplateDeclaration where arbitrary = do a <- arbitraryT () b <- arbitraryT () return $ GTD a b qcr :: (GroupTemplateDeclaration -> Bool) -> IO () qcr prop = verboseCheckWith (stdArgs { chatty = False }) (property . prop) main :: IO () main = qcr (const True) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 23:01:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 23:01:27 -0000 Subject: [GHC] #15529: runtime bug when profiling retainers In-Reply-To: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> References: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> Message-ID: <061.73837bda7ca2a2a02caff2a9cbb711b6@haskell.org> #15529: runtime bug when profiling retainers -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5075 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"2cf98e2207421200fc73c25a08f6435859cdff92/ghc" 2cf98e22/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2cf98e2207421200fc73c25a08f6435859cdff92" rts: Handle SMALL_MUT_ARR_PTRS in retainer profilter Summary: These can be treated similarly to MUT_ARRY_PTRS. Fixes #15529. Reviewers: erikd, simonmar Reviewed By: simonmar Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #15529 Differential Revision: https://phabricator.haskell.org/D5075 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 23:10:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 23:10:13 -0000 Subject: [GHC] #15529: runtime bug when profiling retainers In-Reply-To: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> References: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> Message-ID: <061.ce21a4e21fa465cf9cc174dacdcf5c49@haskell.org> #15529: runtime bug when profiling retainers -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5075 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Aug 27 23:24:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Aug 2018 23:24:03 -0000 Subject: [GHC] #15573: Make bindings with multiple occurrences a join point instead of duplicating code during inlining. Message-ID: <047.1a585298cd8c2f68091841eb66a2d291@haskell.org> #15573: Make bindings with multiple occurrences a join point instead of duplicating code during inlining. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: JoinPoints | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have some intermediate core of the form: {{{ -- RHS size: {terms: 9, types: 2, coercions: 0, joins: 0/0} cseAlts_s1dD [Occ=Once!T[1]] :: T -> Int# [LclId, CallArity=1, Str=] cseAlts_s1dD = \ (lamVar_s1dw [Occ=Once!, Dmd=, OS=OneShot] :: T) -> case lamVar_s1dw of wild_Xc [Dmd=] { __DEFAULT -> 1#; B -> 2#; C -> 3# } -- RHS size: {terms: 14, types: 3, coercions: 0, joins: 0/0} $wfmerge_s1cZ [InlPrag=NOUSERINLINE[0]] :: T -> T -> Int# [LclId, Arity=2, CallArity=2, Str=] $wfmerge_s1cZ = \ (w_s1cU [Occ=Once!, Dmd=] :: T) (w_s1cV [Occ=Once*, Dmd=] :: T) -> case w_s1cU of wild_XA [Dmd=] { __DEFAULT -> -1#; A -> 2#; B -> cseAlts_s1dD w_s1cV; C -> cseAlts_s1dD w_s1cV } }}} Which after the simplifier ran got inlined into the branches to give us: {{{ fmerge = \ (w_s1cU :: T) (w_s1cV :: T) -> case w_s1cU of { __DEFAULT -> GHC.Types.I# -1#; A -> GHC.Types.I# 2#; B -> case w_s1cV of { __DEFAULT -> GHC.Types.I# 1#; B -> GHC.Types.I# 2#; C -> GHC.Types.I# 3# }; C -> case w_s1cV of { __DEFAULT -> GHC.Types.I# 1#; B -> GHC.Types.I# 2#; C -> GHC.Types.I# 3# } } }}} What I would really like GHC to do instead though is to make `cseAlts_s1dD` a join point when possible. This would eliminate both the call overhead AND the call duplication. The current behavior seems fine when we can't make it a join point. But when we can we should try to take advantage of that opportunity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 01:31:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 01:31:45 -0000 Subject: [GHC] #15562: `-XStrict -XNoStrict` is not neutral In-Reply-To: <042.ba188334cc4bb9cd167859c3f14e424e@haskell.org> References: <042.ba188334cc4bb9cd167859c3f14e424e@haskell.org> Message-ID: <057.9f803f8ac2fdbd1923e609714768b2aa@haskell.org> #15562: `-XStrict -XNoStrict` is not neutral -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): comment:3 requires that enabling one extension never disables another. However, this is not true! `RebindableSyntax` implies `NoImplicitPrelude`. Accordingly, `ImplicitPrelude` and `RebindableSyntax` do not commute. And, earlier this summer, `TypeOperators` implied `NoStarIsType`. This feature was removed because it made for a bad migration story, not because it violated this principle. My vote would be simply not to make any guarantees of this sort. It's not hard for a tool to consult `DynFlags.impliedXFlags` and figure out what reorderings are OK. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 01:53:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 01:53:02 -0000 Subject: [GHC] #15557: Reduce type families in equations' RHS when testing equation compatibility In-Reply-To: <044.c8824ce95594133c7a3e270ae939b58d@haskell.org> References: <044.c8824ce95594133c7a3e270ae939b58d@haskell.org> Message-ID: <059.8edd637cbb66d4381544d319db4cdbe3@haskell.org> #15557: Reduce type families in equations' RHS when testing equation compatibility -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8423 #15546 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm not sure what you're suggesting here. comment:3 and comment:4 seem (I didn't fully dig through them) to be a restatement of some of the arguments in #8423. Is that correct? The algorithm in comment:10:ticket:8423 is long lost on some probably- obliterated git branch. Do you think it would address your use case? Maybe what you're suggesting is that (for closed type families at least) we can reduce fully-known (i.e. not in the same recursive group) type families on the RHS. That may indeed be true. For open type families, though, we're stuck, because they're never fully known. And if there is a way for these type families not to terminate, I'm lost as to what the answer is. My bottom line: I'm sure there is room for improvement in this direction, but the path forward is narrow and bordered by heffalump traps. The CTFwOE team got mired in many of them. I'd want a solid proof before implementing any new ideas in this area. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 02:24:48 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 02:24:48 -0000 Subject: [GHC] #15569: Constant folding optimises 1 into 3 In-Reply-To: <050.faecf73a66ba46b12a33656ce184ee72@haskell.org> References: <050.faecf73a66ba46b12a33656ce184ee72@haskell.org> Message-ID: <065.e16bedfce8f13229cfff69c3bb000f49@haskell.org> #15569: Constant folding optimises 1 into 3 -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9136 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): In an attempt to find a safer implementation for constant folding I came up with this: https://gist.github.com/snowleopard/2dd93951cfd42e03aa04a4aa696ca029 This may be an overkill, but does shift most of the verification load to the compiler: we still need to manually verify a few key functions like `eval`, but the constant folding rules can't be written incorrectly. NB: I covered most of the rules, but not all. Also I haven't really shown what to do with negative variables (non-literals) in the end, but this bit doesn't look too complicated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 07:41:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 07:41:10 -0000 Subject: [GHC] #15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite In-Reply-To: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> References: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> Message-ID: <061.070c39fb9344369a31a7fb4b38e67c51@haskell.org> #15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 07:41:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 07:41:18 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.529354a42c866b3c1b24791baa06fb74@haskell.org> #15508: concprog001 fails with various errors -------------------------------------+------------------------------------- Reporter: osa1 | Owner: osa1 Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #15571 | Differential Rev(s): Phab:D5051 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * owner: (none) => osa1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 07:48:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 07:48:23 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.9ab88a784153511ee01edb181e6d2034@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, so does that take us back to (3), namely the accumulator style? Can you switch the style? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 08:18:51 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 08:18:51 -0000 Subject: [GHC] #15560: Full laziness destroys opportunities for join points In-Reply-To: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> References: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> Message-ID: <062.2a8df30c5e221577690c30ea06cc7fbd@haskell.org> #15560: Full laziness destroys opportunities for join points -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14287 #13286 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Ideally we would combine the checks for all branches into a single one to begin with. Do you mean that in {{{ case x of True -> e1 False -> e2 }}} instead of a heap-check at the start of `e1` and another at the start of `e2`, we could have a single one before the case? No, we can't do this: evaluating `x` might force a thunk, and hence allocate an arbitrary amount of stuff. If the `case` is strutinising an unlifted type (which does not require evaluating) then yes it's different, and indeed in that case we sometimes ''do'' move the heap check up. See the long `Note [Compiling case expressions]` in `StgCmmExpr.hs`. (Another possibility that looks unattractive, and that I have not explored: put the heap check after returning from evaluating `x` but before doing the case-analysis to decide which branch to take. That might reduce code size, but would never eliminate a heap check altogether; indeed it might put one in the code path that was not there before, for a branch that did not allocate at all.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 08:26:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 08:26:35 -0000 Subject: [GHC] #15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite In-Reply-To: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> References: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> Message-ID: <061.e37ba1f4e9160aaf7719e069626a19b1@haskell.org> #15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I can't reproduce any failures in this program without using debug runtime and enabling sanity checks with `-debug -rtsopts -with-rtsopts=-DS` (tried with `--timeout 1s` too). When I enable sanity checks I get: (this is with GHC HEAD) {{{ test-sha256: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 851 (GHC version 8.7.20180827 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) cabal new-run --with-ghc=ghc-stage2 --enable- test --allow-newer -- -j 8 999 }}} every once in a few runs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 08:37:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 08:37:22 -0000 Subject: [GHC] #15560: Full laziness destroys opportunities for join points In-Reply-To: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> References: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> Message-ID: <062.d93c5b7ee37fda971a56d6c9c6c00557@haskell.org> #15560: Full laziness destroys opportunities for join points -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14287 #13286 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I assume you are talking about removing the stack check here with the optimisation? I wasn't very clear. My idea is to ''ignore'' whether a top-level binding started life as a join point, and instead optimise ''all'' top-level bindings the same way. There are three things in play: 1. '''Eliminating the closure and info-table for some top-level functions'''. Consider a top-level binding {{{ f = \xy. e }}} When can we do without a closure and info table for `f`? Answer: if * All calls to `f` are known, saturated calls (no partial applications). * `f` is not exported NB 1: it's fine if the call to `f` is in a lazy context, e.g. {{{ g y = let t = f (y+1) in Just t }}} NB 2: for a ''nested'', let-bound function, we do need a function closure, even if all the calls are known, saturated calls. Why? Because we need a heap-allocated container for its free variables. So we need the info table. But if all the calls are known, saturated, we do ''not'' need any slow-entry code, so the code pointer for the info table could be "crash" (will never happen). 2. '''Eliminating stack checks'''. Join points already don't have a stack check; regular let-bindings do (of course). Idea: extend to the stack- check elimination to more functions; that is, absorb any stack use for that function into its call site. When can we do this? Answer: * All calls to `f` are known, saturated calls (no partial applications). * `f` is not exported * `f` is not recursive; or `f` is top-level and tail-calls itself (or is part of a top-level tail-recursive nest). NB 1: this works for ''non-top-level'' functions too. Example: {{{ g x = let f y = blah t = f 4 + f 5 in Just t }}} Currently the thunk for `t` will do a stack check, and `f` will do its own stack check too. We could absorb `f`'s check into `t`. NB 2: why not recursive functions? Consider {{{ let f x = if x==0 then 0 else 1 + f (x-1) }}} Clearly the stack grows, so we can't eliminate the stack check. But if `f` is a join point there is no problem, and similarly at top level (i.e. not a join point) if it tail-calls itself or some other top-level function with the same property.... let's call these "top-level join points". 3. '''Eliminating heap checks'''. Idea: absorb the heap check for a function into its caller. When can we do this? * All calls to `f` are known, saturated calls (no partial applications). * `f` is not exported * `f` is not recursive. Reason: if it's recursive, one of its call sites is in its own RHS, so we can't statically bound how much heap it uses. NB 1: absorbing the heap check is ''not'' currently done even for join points. (Reason: it only works for ''non-recursive'' functions.) NB: None of these optimisations rely on `f` being a join point. All of this is STG-level/code-gen level optimisation, not Core. These would be interesting ideas to try out. If you feel motivated, I could advise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 09:16:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 09:16:54 -0000 Subject: [GHC] #15546: Display coaxiom branch incompatibilities in GHCi In-Reply-To: <044.c77ffe997f2d99b3fbec7a544251677f@haskell.org> References: <044.c77ffe997f2d99b3fbec7a544251677f@haskell.org> Message-ID: <059.bb228d716cbe3ceff7aa407401884e7b@haskell.org> #15546: Display coaxiom branch incompatibilities in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: TypeFamilies, | GHCi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5097 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I thus agree that the ability to print out incompatibilities is sometimes helpful for users, not just implementors. OK, thanks. Now I understand. I agree. mnip: in the code, can you add a Note with an example of what the incompatibility stuff looks like when printed out; and some version of Richard's comments in comment:9 to explain why it might be useful for users to see this information? Also are the equations 0-indexed or 1-indexed? The Note, and the manual entry about the flag, should say. Also can you modify the manual section that Richard points to in comment:9 so that it mentions the existence of the flag to show compatibilities? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 09:20:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 09:20:56 -0000 Subject: [GHC] #15552: Infinite loop/panic with an existential type. In-Reply-To: <050.eb5168d400b4a4211e35d29d96945d09@haskell.org> References: <050.eb5168d400b4a4211e35d29d96945d09@haskell.org> Message-ID: <065.0b96527ac3da836ffc73b6e828a61b8b@haskell.org> #15552: Infinite loop/panic with an existential type. -------------------------------------+------------------------------------- Reporter: howtonotwin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: TypeInType, | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14723 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > As for the larger plan: I like all of it What is the "all of it" that you like, specifically? There are, I think, two pieces: 1. Eliminate the bug. How? Current brand leader: add a third contructor to `MetaDetails` (comment:3). Do we have any other alternatives on the table? 2. Clean up knot tying by using `ZonkEnv` (comment:4). This is pure refactoring, and hence not urgent, but it smells right to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 09:25:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 09:25:49 -0000 Subject: [GHC] #15573: Make bindings with multiple occurrences a join point instead of duplicating code during inlining. In-Reply-To: <047.1a585298cd8c2f68091841eb66a2d291@haskell.org> References: <047.1a585298cd8c2f68091841eb66a2d291@haskell.org> Message-ID: <062.633023705693dea23652d1a33b1ed52f@haskell.org> #15573: Make bindings with multiple occurrences a join point instead of duplicating code during inlining. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This relates to #15560: in the current ticket you are proposing the to use float-in (the opposite of float-out) to make `cseAlts_s1dD` a local binging again. I'd prefer instead to make the top-level version (in the Description) more efficient so that it's just as efficient as the join-point version. One reason I want to do that is because it improves inlining opportunities, by making the function (`fmerge` in this case) smaller. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 09:51:32 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 09:51:32 -0000 Subject: [GHC] #15573: Make bindings with multiple occurrences a join point instead of duplicating code during inlining. In-Reply-To: <047.1a585298cd8c2f68091841eb66a2d291@haskell.org> References: <047.1a585298cd8c2f68091841eb66a2d291@haskell.org> Message-ID: <062.acb3f015fc259883a4936640a0659cc1@haskell.org> #15573: Make bindings with multiple occurrences a join point instead of duplicating code during inlining. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15560 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * related: => #15560 Comment: Replying to [comment:1 simonpj]: > This relates to #15560: in the current ticket you are proposing the to use float-in (the opposite of float-out) to make `cseAlts_s1dD` a local binging again. > > I'd prefer instead to make the top-level version (in the Description) more efficient so that it's just as efficient as the join-point version. While we can (and should!) improve on the current cost even with your suggestions there will likely still be an overhead caused by code layout and calling convention. Even if far smaller. > One reason I want to do that is because it improves inlining opportunities, by making the function (`fmerge` in this case) smaller. Indeed this sounds good. However I'm not sure if we can make calling top level functions efficient enough to **never** warant inlining. And assuming we still end up inlining in some cases this optimization would be good to have. But I agree that the ideas discussed in #15560 have the chance to remove the need for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 09:58:43 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 09:58:43 -0000 Subject: [GHC] #15560: Full laziness destroys opportunities for join points In-Reply-To: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> References: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> Message-ID: <062.f4b9b3022db940d1e9b88fc93b37664f@haskell.org> #15560: Full laziness destroys opportunities for join points -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14287 #13286 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): Replying to [comment:11 simonpj]: > > Ideally we would combine the checks for all branches into a single one to begin with. > > (Another possibility that looks unattractive, and that I have not explored: put the heap check after returning from evaluating `x` but before doing the case-analysis to decide which branch to take. That might reduce code size, but would never eliminate a heap check altogether; indeed it might put one in the code path that was not there before, for a branch that did not allocate at all.) The obvious solution seems to me is to simply limit this to cases where all branches allocate. This would reduce code size while coming with few penalties. It would probably make sense to special case two other scenarios: * If the difference in allocation is huge. * If the non allocating branches are bottoming (eg pattern match failures). But I'm not sure how easy it ease to check these conditions during StgToCmm generation. I'm not really familiar with that part of codegen yet. > I wasn't very clear. My idea is to ignore whether a top-level binding started life as a join point, and instead optimise all top-level bindings the same way. That sounds like something we should do! Making them join points would still have additional advantages for code layout and possible register allocation. So a late "float in" pass of sorts after we are done inlining might still make sense. But your suggest changes should still reduce overhead of these calls quite a bit compared to what we have now. > These would be interesting ideas to try out. If you feel motivated, I could advise. I'm interested as I might need these optimizations for other things I'm working on anyway. I guess a good way to start would be to look into 1) starting at the StgToCmm code? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 10:02:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 10:02:03 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.e769808805f82327a36825624b5d4e9f@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:87 simonpj]: > OK, so does that take us back to (3), namely the accumulator style? Can you switch the style? I think that would just bring us back to using plain old VarSets, which we have already profiled. I could of course make a VarSet flavor that has the additional interesting function and in_scope checks, though I have doubts on whether it would reveal anything new. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 10:09:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 10:09:18 -0000 Subject: [GHC] #15560: Full laziness destroys opportunities for join points In-Reply-To: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> References: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> Message-ID: <062.378aef941d5d7b115782ce35ddb250ad@haskell.org> #15560: Full laziness destroys opportunities for join points -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14287 #13286 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > (comment:11) Another possibility that looks unattractive, ... The obvious solution seems to me is to simply limit this to cases where all branches allocate Perhaps, but I think the other 1,2,3 possibilities look as if they'll have more payoff per hour invested. Once they are done, maybe come back to this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 10:09:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 10:09:53 -0000 Subject: [GHC] #15560: Full laziness destroys opportunities for join points In-Reply-To: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> References: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> Message-ID: <062.91f3d31e5b93e4aa7515798666a5abee@haskell.org> #15560: Full laziness destroys opportunities for join points -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14287 #13286 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I guess a good way to start would be to look into 1) starting at the StgToCmm code? Yes, sounds good to me! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 10:14:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 10:14:18 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.0af4b73520a0000d207ab3de1b780957@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I think that would just bring us back to using plain old VarSets, which we have already profiled. Maybe so, but then I believe you are saying: * (a) `FV` is faster than `VarSet` * (b) None of (1), (2), (3) from comment:83 are responsible These can't both be true. We can successively transform `FV` into `VarSet` by changing (1), (2), (3), and at some point the perf must change, if (a) is true. Or have I misunderstood something? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 10:17:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 10:17:57 -0000 Subject: [GHC] #15560: Full laziness destroys opportunities for join points In-Reply-To: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> References: <047.749103193d66a2bfa9b7c261530a5e01@haskell.org> Message-ID: <062.2d8c1e46c44378cf7de47f4c393a3267@haskell.org> #15560: Full laziness destroys opportunities for join points -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14287 #13286 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): Replying to [comment:14 simonpj]: > > (comment:11) Another possibility that looks unattractive, ... The obvious solution seems to me is to simply limit this to cases where all branches allocate > > Perhaps, but I think the other 1,2,3 possibilities look as if they'll have more payoff per hour invested. Once they are done, maybe come back to this. Hard to judge given that the heap check issue also arises in code not using join points at all. But it certainly seems like an orthogonal issue. I will open a seperate ticket for this so we don't get too much noise on this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 11:08:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 11:08:21 -0000 Subject: [GHC] #15558: Locally handling an empty constraint In-Reply-To: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> References: <050.9e62fddfd8cdd1b00cc8acc9acab3225@haskell.org> Message-ID: <065.3a89322292c24a53b5c0a9f08370813c@haskell.org> #15558: Locally handling an empty constraint -------------------------------------+------------------------------------- Reporter: Ericson2314 | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: gadt/T15558 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Is writing the code with the "type warning" the best one can do? I don't know. I'd love to improve it further. The patch does the best I can within the current setup -- but doubtless one could do better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 11:09:43 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 11:09:43 -0000 Subject: [GHC] #15557: Reduce type families in equations' RHS when testing equation compatibility In-Reply-To: <044.c8824ce95594133c7a3e270ae939b58d@haskell.org> References: <044.c8824ce95594133c7a3e270ae939b58d@haskell.org> Message-ID: <059.970756c315870da02d98894ac0093bf6@haskell.org> #15557: Reduce type families in equations' RHS when testing equation compatibility -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8423 #15546 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Nevertheless, Richard, do you agree with comment:1. That is, we currently have an outright bug? And if so, can you see how to fix it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 11:11:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 11:11:47 -0000 Subject: [GHC] #15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite In-Reply-To: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> References: <046.896ae06fe4a7986fa271ab3587c71083@haskell.org> Message-ID: <061.43754add7cdfc78914340c5d4e1f0203@haskell.org> #15544: Non-deterministic segmentation fault in cryptohash-sha256 testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I tried to reproduce this on another x86_64 system and failed. bgamari, are you reproducing this with only the command shown in the description? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 13:11:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 13:11:44 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.5a64710b3b25b0d19580c6b30df736ae@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Oh no. What I was trying to say is that (3) seems to be responsible; I could write an `FV` flavor to verify it, but it would amount to pretty much just `VarSet`, just wrapped in a record together with two other fields that we won't use. In theory it should be interesting to take our FV and *only* change (3), but keep (1) and (2), except that we already suspected that neither of them does anything significant here, and we have already ruled them out as culprits individually. But I'll do it anyway, even if it's just to make sure I didn't miss anything in embarrassing ways. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 13:15:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 13:15:34 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.a27eff0645fcfc7465f8d5fda24dd1d5@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > What I was trying to say is that (3) seems to be responsible So you think that using `VarSet`, but with an accumulator style, will be fastest of all? And yet comment:71 suggests that switching to accumulator style should not have any effect on `VarSet`. Maybe I was benchmarking the wrong thing. Anyway, yes please try! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 13:27:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 13:27:45 -0000 Subject: [GHC] #15274: Numerous validation failures when building GHC with LLVM In-Reply-To: <046.83a071bfa50c4ead83f977af9cb85f1c@haskell.org> References: <046.83a071bfa50c4ead83f977af9cb85f1c@haskell.org> Message-ID: <061.a6bf9fbc7098cb273459f39f0c1cbbd3@haskell.org> #15274: Numerous validation failures when building GHC with LLVM -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (LLVM) | Version: 8.4.3 Resolution: | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: alpmestan (added) * owner: (none) => alpmestan Comment: A huge majority of the tests are failing with something along the lines of `ghc-stage2: ghc-iserv terminated (-11)`. As of a recent commit, we're seeing 59 failures: https://circleci.com/gh/ghc/ghc/8923 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 13:30:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 13:30:12 -0000 Subject: [GHC] #15557: Reduce type families in equations' RHS when testing equation compatibility In-Reply-To: <044.c8824ce95594133c7a3e270ae939b58d@haskell.org> References: <044.c8824ce95594133c7a3e270ae939b58d@haskell.org> Message-ID: <059.0b2f2bf3d509af09fdd35bfe4b48b5b9@haskell.org> #15557: Reduce type families in equations' RHS when testing equation compatibility -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.4.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8423 #15546 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I agree with the PS in comment:6. I see this as a pure feature request, not a bug. The behavior in comment:1 is consistent with the design of closed type families in the paper and the manual. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 13:50:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 13:50:19 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.2328fb150851ecae2c17ef981e9b4ce2@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Indeed, yes, that is confusing. I'll also re-run my other profiles to rule out external factors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 14:08:43 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 14:08:43 -0000 Subject: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections In-Reply-To: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> References: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> Message-ID: <060.81d249ee3f00402f49552ae3c9edcb94@haskell.org> #7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.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 simonmar): I didn't mention per-capability hash tables, only per-generation. per- capability might be worthwhile to avoid locking overhead, but my nagging concern about all this is that I'm not sure what we're optimising for. Are there any heavy users of StableNames that would benefit from optimisation here, or are people avoiding StableNames because they aren't efficient enough? Or is the main concern implementation complexity? Adding per- generation tables would increase complexity, it's not clear to me that going to per-generation hash tables would result in a simpler implementation, even if the no-stable-table idea was implemented too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 14:43:25 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 14:43:25 -0000 Subject: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections In-Reply-To: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> References: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> Message-ID: <060.843fb40debe6316dd28dbc9f55a8cd46@haskell.org> #7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.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 dfeuer): There's another way to go "generational" that takes into account the fact that (I imagine) stable names tend to live a long time. We could have just one hash table, but also keep a list of all the stable names whose underlying objects are in the nursery. When we perform a minor collection, we go through that list and delete the dead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 15:25:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 15:25:46 -0000 Subject: [GHC] #15574: C wrappers for Haskell foreign exports don't have finalizers (causes memory leak). Message-ID: <046.a98f28fe84752578e5e0f9b9ec2b941f@haskell.org> #15574: C wrappers for Haskell foreign exports don't have finalizers (causes memory leak). -------------------------------------+------------------------------------- Reporter: Valoisa | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1 (FFI) | Keywords: | Operating System: Windows Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For each foreign export RTS creates a static C wrapper, which is initialized on {{{DLL_PROCESS_ATTACH}}}, but it has no finalizer/destructor to be called during {{{DLL_PROCESS_DETACH}}}. So it will stay alive till the program termination. That's why if one uses a Haskell DLL in their C/C++ project, **consumed memory is not fully released after freeing the library**. [[br]][[br]] There are four files attached to this ticket. * **HaskellExports.hs** contains exact one foreign export function; * **CWrapper.cpp** is supposed to contain wrappers to the Haskell functions, described in ''HaskellExports.hs'', but it doesn't because they make no difference; * **main.cpp**: here in an endless loop the DLL (built with the help of the script below) is loaded and freed at once. Launched program is crashed in a while (because it runs out of memory); * **build.sh** is a script for building the library. [[br]] The main program was built with MSVC 2015. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 15:27:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 15:27:19 -0000 Subject: [GHC] #15574: C wrappers for Haskell foreign exports don't have finalizers (causes memory leak). In-Reply-To: <046.a98f28fe84752578e5e0f9b9ec2b941f@haskell.org> References: <046.a98f28fe84752578e5e0f9b9ec2b941f@haskell.org> Message-ID: <061.867e31d23fcfa14a42399b24d8e313d4@haskell.org> #15574: C wrappers for Haskell foreign exports don't have finalizers (causes memory leak). -------------------------------------+------------------------------------- Reporter: Valoisa | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (FFI) | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Valoisa): * Attachment "HaskellExports.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 15:28:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 15:28:10 -0000 Subject: [GHC] #15574: C wrappers for Haskell foreign exports don't have finalizers (causes memory leak). In-Reply-To: <046.a98f28fe84752578e5e0f9b9ec2b941f@haskell.org> References: <046.a98f28fe84752578e5e0f9b9ec2b941f@haskell.org> Message-ID: <061.1e662852e29266665ac152e5e2f902d9@haskell.org> #15574: C wrappers for Haskell foreign exports don't have finalizers (causes memory leak). -------------------------------------+------------------------------------- Reporter: Valoisa | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (FFI) | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Valoisa): * Attachment "HaskellExports.2.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 15:29:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 15:29:22 -0000 Subject: [GHC] #15574: C wrappers for Haskell foreign exports don't have finalizers (causes memory leak). In-Reply-To: <046.a98f28fe84752578e5e0f9b9ec2b941f@haskell.org> References: <046.a98f28fe84752578e5e0f9b9ec2b941f@haskell.org> Message-ID: <061.309f600d33be891d5f0d46d991b3db7d@haskell.org> #15574: C wrappers for Haskell foreign exports don't have finalizers (causes memory leak). -------------------------------------+------------------------------------- Reporter: Valoisa | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (FFI) | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Valoisa): * Attachment "CWrapper.cpp" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 15:30:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 15:30:15 -0000 Subject: [GHC] #15574: C wrappers for Haskell foreign exports don't have finalizers (causes memory leak). In-Reply-To: <046.a98f28fe84752578e5e0f9b9ec2b941f@haskell.org> References: <046.a98f28fe84752578e5e0f9b9ec2b941f@haskell.org> Message-ID: <061.2dde6aca52b47092d695e67f32b1cd69@haskell.org> #15574: C wrappers for Haskell foreign exports don't have finalizers (causes memory leak). -------------------------------------+------------------------------------- Reporter: Valoisa | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (FFI) | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Valoisa): * Attachment "main.cpp" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 15:31:05 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 15:31:05 -0000 Subject: [GHC] #15574: C wrappers for Haskell foreign exports don't have finalizers (causes memory leak). In-Reply-To: <046.a98f28fe84752578e5e0f9b9ec2b941f@haskell.org> References: <046.a98f28fe84752578e5e0f9b9ec2b941f@haskell.org> Message-ID: <061.74b8278aa848a5251f7cdf4c1329c65a@haskell.org> #15574: C wrappers for Haskell foreign exports don't have finalizers (causes memory leak). -------------------------------------+------------------------------------- Reporter: Valoisa | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (FFI) | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Valoisa): * Attachment "build.sh" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 15:35:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 15:35:35 -0000 Subject: [GHC] #15574: C wrappers for Haskell foreign exports don't have finalizers (causes memory leak). In-Reply-To: <046.a98f28fe84752578e5e0f9b9ec2b941f@haskell.org> References: <046.a98f28fe84752578e5e0f9b9ec2b941f@haskell.org> Message-ID: <061.1f0ff4172ac425bf276ac465cecc7525@haskell.org> #15574: C wrappers for Haskell foreign exports don't have finalizers (causes memory leak). -------------------------------------+------------------------------------- Reporter: Valoisa | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (FFI) | Version: 8.0.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Valoisa): {{{HaskellExports.2.hs}}}​ is the same as {{{HaskellExports.hs}}}​, it was attached accidentally (no idea how to remove it). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 15:40:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 15:40:08 -0000 Subject: [GHC] #15363: Do some cleaning up of the testsuite driver In-Reply-To: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> References: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> Message-ID: <060.c33a3058e459f67eff1c3633af877885@haskell.org> #15363: Do some cleaning up of the testsuite driver -------------------------------------+------------------------------------- Reporter: lantti | Owner: lantti Type: task | Status: patch Priority: low | Milestone: 8.8.1 Component: Test Suite | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5107 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * differential: => Phab:D5107 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 15:40:30 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 15:40:30 -0000 Subject: [GHC] #15570: Core transformations generate bad indexCharOffAddr# call In-Reply-To: <048.6749470bd8e5b16854763831c1951d1e@haskell.org> References: <048.6749470bd8e5b16854763831c1951d1e@haskell.org> Message-ID: <063.a5ed3ecffaea72be5f687840dd5fdc8c@haskell.org> #15570: Core transformations generate bad indexCharOffAddr# call -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: alpmestan Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * owner: (none) => alpmestan * milestone: => 8.6.1 Comment: I'm going to try and characterise where both builds differ, using `-dverbose-core2core`. The best theory at this point is that libraries are built with different enough options that this affects the optimisation pipeline on this example. This won't be the end of the story though, as we simply ''never'' want to end up with the Core for `f` mentionned above. But at that point we will also have a lot more information about how the Core evolves. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 15:55:10 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 15:55:10 -0000 Subject: [GHC] #14461: Reuse free variable lists through nested closures In-Reply-To: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> References: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> Message-ID: <062.9e9386ab4f8c18edc19adf149447fc2c@haskell.org> #14461: Reuse free variable lists through nested closures -------------------------------------+------------------------------------- Reporter: tdammers | Owner: alexbiehl Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: 7258 | Differential Rev(s): Wiki Page: NestedClosures | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: dfeuer (removed) * cc: dfeuer., andreask (added) Comment: AndreasK: maybe you'd be interested. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 16:33:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 16:33:57 -0000 Subject: [GHC] #15570: Core transformations generate bad indexCharOffAddr# call In-Reply-To: <048.6749470bd8e5b16854763831c1951d1e@haskell.org> References: <048.6749470bd8e5b16854763831c1951d1e@haskell.org> Message-ID: <063.0312c95f8eca025015ca720cd022c0d1@haskell.org> #15570: Core transformations generate bad indexCharOffAddr# call -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: alpmestan Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This is all very mysterious. What I get from HEAD (for `f`) is this: {{{ Rec { -- RHS size: {terms: 33, types: 19, coercions: 0, joins: 0/0} Bug.$wgo [InlPrag=NOUSERINLINE[2], Occ=LoopBreaker] :: Int# -> [Char] -> (# Char, [Char] #) [GblId, Arity=2, Caf=NoCafRefs, Str=, Unf=OtherCon []] Bug.$wgo = \ (ww_s2QZ :: Int#) (w_s2QW :: [Char]) -> case quotRemInt# ww_s2QZ 62# of { (# ipv_a2OJ, ipv1_a2OK #) -> case indexCharOffAddr# chars62_r2NR ipv1_a2OK of wild_X4 { __DEFAULT -> case <# ww_s2QZ 62# of { __DEFAULT -> Bug.$wgo ipv_a2OJ (GHC.Types.: @ Char (GHC.Types.C# wild_X4) w_s2QW); 1# -> case indexCharOffAddr# chars62_r2NR ww_s2QZ of wild1_XM { __DEFAULT -> (# GHC.Types.C# wild1_XM, w_s2QW #) } } } } end Rec } -- RHS size: {terms: 13, types: 15, coercions: 0, joins: 0/0} Bug.f_go [InlPrag=NOUSERINLINE[2]] :: Int -> [Char] -> [Char] [GblId, Arity=2, Caf=NoCafRefs, Str=m2, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=2,unsat_ok=True,boring_ok=False) Tmpl= \ (w_s2QV [Occ=Once!] :: Int) (w1_s2QW [Occ=Once] :: [Char]) -> case w_s2QV of { I# ww1_s2QZ [Occ=Once] -> case Bug.$wgo ww1_s2QZ w1_s2QW of { (# ww3_s2R5 [Occ=Once], ww4_s2R6 [Occ=Once] #) -> GHC.Types.: @ Char ww3_s2R5 ww4_s2R6 } }}] Bug.f_go = \ (w_s2QV :: Int) (w1_s2QW :: [Char]) -> case w_s2QV of { I# ww1_s2QZ -> case Bug.$wgo ww1_s2QZ w1_s2QW of { (# ww3_s2R5, ww4_s2R6 #) -> GHC.Types.: @ Char ww3_s2R5 ww4_s2R6 } } -- RHS size: {terms: 12, types: 14, coercions: 0, joins: 0/0} f :: Int -> String [GblId, Arity=1, Caf=NoCafRefs, Str=m2, 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= \ (n__aXh [Occ=Once] :: Int) -> Bug.f_go n__aXh (GHC.Types.[] @ Char)}] f = \ (n__aXh :: Int) -> case n__aXh of { I# ww1_s2QZ -> case Bug.$wgo ww1_s2QZ (GHC.Types.[] @ Char) of { (# ww3_s2R5, ww4_s2R6 #) -> GHC.Types.: @ Char ww3_s2R5 ww4_s2R6 } } }}} which looks very plausible. You are getting something quite different with your Hadrian build. Can you give precise repro instructions? (Including `build.mk` etc.) I'm very puzzled about this mysterious case of `GHC.Real.even3`. Where on earth does that come from? And if it is equal to `-1` why doesn't the case get eliminated? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 16:47:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 16:47:53 -0000 Subject: [GHC] #15570: Core transformations generate bad indexCharOffAddr# call In-Reply-To: <048.6749470bd8e5b16854763831c1951d1e@haskell.org> References: <048.6749470bd8e5b16854763831c1951d1e@haskell.org> Message-ID: <063.763fe5cb82272b10860587835f5f4ac6@haskell.org> #15570: Core transformations generate bad indexCharOffAddr# call -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: alpmestan Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): Here are the instructions: {{{#!sh # will likely also work with HEAD, as this commit isn't old $ git checkout c523525b0e434d848f6e47ea3f9a37485965fa79 $ curl -O https://phabricator- files.haskell.org/file/data/mgom5atdizvefddx4ax2/PHID-FILE- tbprgcge7cciumnotpbj/D5106.diff $ git apply D5106.diff # build ghc $ hadrian/build.sh -c -j4 --flavour=quick # compile test program, assuming it's in ./bug.hs $ _build/stage1/bin/ghc -O -fPIC -dynamic -ddump-simpl bug.hs -o bug.o }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 20:00:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 20:00:15 -0000 Subject: [GHC] #15572: TH improperly converts promoted data cons in ConT In-Reply-To: <050.0e46c20217a7ed360417cc67421971cd@haskell.org> References: <050.0e46c20217a7ed360417cc67421971cd@haskell.org> Message-ID: <065.6b6fefe425a720c565683941a1b03422@haskell.org> #15572: TH improperly converts promoted data cons in ConT -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5112 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"c46a5f2002f6694ea58f79f505d57f3b7bd450e7/ghc" c46a5f20/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c46a5f2002f6694ea58f79f505d57f3b7bd450e7" Fix #15572 by checking for promoted names in ConT Summary: When converting `ConT`s to `HsTyVar`s in `Convert`, we were failing to account for the possibility of promoted data constructor names appearing in a `ConT`, which could result in improper pretty-printing results (as observed in #15572). The fix is straightforward: use `Promoted` instead of `NotPromoted` when the name of a `ConT` is a data constructor name. Test Plan: make test TEST=T15572 Reviewers: goldfire, bgamari, simonpj, monoidal Reviewed By: goldfire, simonpj Subscribers: monoidal, rwbarton, carter GHC Trac Issues: #15572 Differential Revision: https://phabricator.haskell.org/D5112 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 21:11:05 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 21:11:05 -0000 Subject: [GHC] #11350: Allow visible type application in patterns In-Reply-To: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> References: <051.b16517d65bfaaca2db1f23781a666611@haskell.org> Message-ID: <066.119db59c747464155382bb70ba4f6da7@haskell.org> #11350: Allow visible type application in patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11385, #13159, | Differential Rev(s): #13158 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Is there any daylight between this ticket and #15530? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 22:12:16 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 22:12:16 -0000 Subject: [GHC] #15568: Kind variables in type family aren't quantified in toposorted order In-Reply-To: <050.0d422903bc51c8d2d5b53b7c9ad7b27a@haskell.org> References: <050.0d422903bc51c8d2d5b53b7c9ad7b27a@haskell.org> Message-ID: <065.4692c27e28fddad3e315817d3bea3b37@haskell.org> #15568: Kind variables in type family aren't quantified in toposorted order -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | TypeApplications, TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5108 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"102284e72f8d29599803aa72ccec180db28e72c8/ghc" 102284e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="102284e72f8d29599803aa72ccec180db28e72c8" Rename kind vars in left-to-right order in bindHsQTyVars Summary: When renaming kind variables in an `LHsQTyVars`, we were erroneously putting all of the kind variables in the binders //after// the kind variables in the body, resulting in #15568. The fix is simple: just swap the order of these two around. Test Plan: make test TEST=T15568 Reviewers: simonpj, bgamari, goldfire Reviewed By: goldfire Subscribers: goldfire, rwbarton, carter GHC Trac Issues: #15568 Differential Revision: https://phabricator.haskell.org/D5108 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 22:17:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 22:17:54 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (allocates 50% more) (was: forM_ [1..N] does not get fused (10 times slower than go function)) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.0cf098d06390158c44f82cd5065c07c3@haskell.org> #8763: forM_ [1..N] does not get fused (allocates 50% more) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7206 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): updated summary to match current state of this ticket. The speed issue seems to have been resolved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 22:20:30 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 22:20:30 -0000 Subject: [GHC] #15568: Kind variables in type family aren't quantified in toposorted order In-Reply-To: <050.0d422903bc51c8d2d5b53b7c9ad7b27a@haskell.org> References: <050.0d422903bc51c8d2d5b53b7c9ad7b27a@haskell.org> Message-ID: <065.31ad0b708ecead9c0777bce20abea058@haskell.org> #15568: Kind variables in type family aren't quantified in toposorted order -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: | TypeApplications, TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5108 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 22:50:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 22:50:39 -0000 Subject: [GHC] #9279: Local wrapper function remains in final program; result = extra closure allocation In-Reply-To: <047.2731319b9773852326eb9e6a852376dc@haskell.org> References: <047.2731319b9773852326eb9e6a852376dc@haskell.org> Message-ID: <062.c650b507154cd8abe3b41f1725b467d7@haskell.org> #9279: Local wrapper function remains in final program; result = extra closure allocation -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => LateLamLift -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 22:50:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 22:50:54 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.edefe0706d8bbf030101a5295a0dc8dc@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => LateLamLift -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 22:51:25 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 22:51:25 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.e490f99aca40e84b0c07d72a8593376e@haskell.org> #9374: Investigate Static Argument Transformation -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: | StaticArgumentTransformation, | LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: StaticArgumentTransformation => StaticArgumentTransformation, LateLamLift -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 22:51:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 22:51:37 -0000 Subject: [GHC] #5945: Lambda lifting In-Reply-To: <046.7bd8108156aaaf0a3ac04ae912e0c715@haskell.org> References: <046.7bd8108156aaaf0a3ac04ae912e0c715@haskell.org> Message-ID: <061.dde80ab5e12823a4fabdc547103d93f0@haskell.org> #5945: Lambda lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11284, #9476 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => LateLamLift -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Aug 28 22:52:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Aug 2018 22:52:19 -0000 Subject: [GHC] #11284: Lambda-lifting fails in simple Text example In-Reply-To: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> References: <046.c8fcc117f2d6aac596767173f5e9481b@haskell.org> Message-ID: <061.c2acb162611b3b8b58a86a30aafe39bc@haskell.org> #11284: Lambda-lifting fails in simple Text example -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #5945, #11318 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => LateLamLift -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 03:39:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 03:39:00 -0000 Subject: [GHC] #14461: Reuse free variable lists through nested closures In-Reply-To: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> References: <047.eeba948e2bfec115d2840d5095e639e4@haskell.org> Message-ID: <062.1b1ab36cb254bd33fb3957b5a69b27ec@haskell.org> #14461: Reuse free variable lists through nested closures -------------------------------------+------------------------------------- Reporter: tdammers | Owner: alexbiehl Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: 7258 | Differential Rev(s): Wiki Page: NestedClosures | -------------------------------------+------------------------------------- Changes (by potato44): * cc: dfeuer. (removed) * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 06:05:53 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 06:05:53 -0000 Subject: [GHC] #15566: Implement minimumOn, maximumOn to mirror sortOn In-Reply-To: <046.9955d151a0d096fa05b640c0d0259990@haskell.org> References: <046.9955d151a0d096fa05b640c0d0259990@haskell.org> Message-ID: <061.1a797f2ded19ca160167c943093b5620@haskell.org> #15566: Implement minimumOn, maximumOn to mirror sortOn -------------------------------------+------------------------------------- Reporter: Garciat | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Research | needed Component: libraries/base | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D5110 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Will we want the total variants, with `Foldable1` constraints (#13573) {{{#!hs maximumOn, minimumOn :: Foldable1 f1 => Ord cmp => (a -> cmp) -> (f1 a -> a) maximumOn = maximumBy . comparing minimumOn = minimumBy . comparing }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 06:06:17 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 06:06:17 -0000 Subject: [GHC] #15566: Implement minimumOn, maximumOn to mirror sortOn In-Reply-To: <046.9955d151a0d096fa05b640c0d0259990@haskell.org> References: <046.9955d151a0d096fa05b640c0d0259990@haskell.org> Message-ID: <061.43056ff445e30b4f71808c3b71dfe74a@haskell.org> #15566: Implement minimumOn, maximumOn to mirror sortOn -------------------------------------+------------------------------------- Reporter: Garciat | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Research | needed Component: libraries/base | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13573 | Differential Rev(s): D5110 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * related: => #13573 Comment: Will we want the total variants, with `Foldable1` constraints (#13573) {{{#!hs maximumOn, minimumOn :: Foldable1 f1 => Ord cmp => (a -> cmp) -> (f1 a -> a) maximumOn = maximumBy . comparing minimumOn = minimumBy . comparing }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 06:06:57 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 06:06:57 -0000 Subject: [GHC] #13573: Add Foldable1 to base In-Reply-To: <051.5343934480dda921b1b6981f18b39763@haskell.org> References: <051.5343934480dda921b1b6981f18b39763@haskell.org> Message-ID: <066.0dfd9a9428d04b2e357d83c274ba36a5@haskell.org> #13573: Add Foldable1 to base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10365, #15566 | Differential Rev(s): Phab:D4812 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * related: #10365 => #10365, #15566 Comment: Also {{{#!hs maximumBy :: Foldable1 f1 => (a -> a -> Ordering) -> (f1 a -> a) maximumBy cmp = foldl1_ max' where max' x y = case cmp x y of GT -> x _ -> y minimumBy :: Foldable1 f1 => (a -> a -> Ordering) -> (f1 a -> a) minimumBy cmp = foldl1_ min' where min' x y = case cmp x y of GT -> y _ -> x }}} and per #15566 {{{#!hs maximumOn, minimumOn :: Foldable1 f1 => Ord cmp => (a -> cmp) -> (f1 a -> a) maximumOn = maximumBy . comparing minimumOn = minimumBy . comparing }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 06:40:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 06:40:50 -0000 Subject: [GHC] #14743: `UnsafeReenter` test hangs In-Reply-To: <043.cf7e44020eaed9a14557dc6193e09fc7@haskell.org> References: <043.cf7e44020eaed9a14557dc6193e09fc7@haskell.org> Message-ID: <058.8bccc340f554e60e8a87dac378f8aa54@haskell.org> #14743: `UnsafeReenter` test hangs -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): This still happens with GHC HEAD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 07:04:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 07:04:08 -0000 Subject: [GHC] #14912: UnsafeReenter test fails with threaded1 and threaded2 In-Reply-To: <048.0d06801876b264a33d0020ade629babb@haskell.org> References: <048.0d06801876b264a33d0020ade629babb@haskell.org> Message-ID: <063.f65834f48acf72c9db78f1bc21ebfdde@haskell.org> #14912: UnsafeReenter test fails with threaded1 and threaded2 -----------------------------------+-------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14743 | Differential Rev(s): Wiki Page: | -----------------------------------+-------------------------------------- Changes (by osa1): * cc: simonmar (added) * related: => #14743 Comment: This still happens with GHC HEAD, but only with threaded runtime. {{{ $ ghc-stage2 UnsafeReenter.hs UnsafeReenterC.c -fforce-recomp -threaded [1 of 1] Compiling Main ( UnsafeReenter.hs, UnsafeReenter.o ) Linking UnsafeReenter ... $ ./UnsafeReenter In Haskell in C ^C^C }}} Interestingly, if I add `-N2` the program terminates, but not with the error message as expected! {{{ $ ./UnsafeReenter +RTS -N2 In Haskell in C Back in Haskell Finished }}} I checked Haskell 2010 and this program actually has an undefined behavior: (section 8.4.3) > safe call is less efficient, but guarantees to leave the Haskell system in a > state that allows callbacks from the external code. In contrast, an unsafe > call, while carrying less overhead, must not trigger a callback into the > Haskell system. If it does, the system behaviour is undefined. So both outputs above are actually fine. But perhaps we still want to catch Haskell calls from unsafe FFI calls in the current implementation? Simon, any ideas? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 08:09:39 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 08:09:39 -0000 Subject: [GHC] #15418: Performance drop 60 times on non-profiling binary In-Reply-To: <045.a055029aec148ca416c29df30694b018@haskell.org> References: <045.a055029aec148ca416c29df30694b018@haskell.org> Message-ID: <060.fec4e57c46ee15448f31597ed355a206@haskell.org> #15418: Performance drop 60 times on non-profiling binary -------------------------------------+------------------------------------- Reporter: hth313 | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14414, #9599 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => infoneeded Comment: It's very hard (if not impossible) to fix this without a reproducer. Marking as "infoneeded". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 09:05:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 09:05:23 -0000 Subject: [GHC] #15363: Do some cleaning up of the testsuite driver In-Reply-To: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> References: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> Message-ID: <060.bc7a49e436b73f7e7a86c77885d42d81@haskell.org> #15363: Do some cleaning up of the testsuite driver -------------------------------------+------------------------------------- Reporter: lantti | Owner: lantti Type: task | Status: patch Priority: low | Milestone: 8.8.1 Component: Test Suite | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5107 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): First of all, thanks a lot for the effort, it is very much appreciated. Then, to summarize (correct me if I'm wrong): - The original problem to be solved here is that the testsuite driver (written in Python) shells out to a custom timeout program ({{{timeout.hs}}}); so the idea was to rewrite the whole timeout functionality in Python - Vanilla Python and its libraries (particularly {{{subprocess}}}) are inadequate on Windows, because the process model is different, which makes certain things that we rely on nontrivial (specifically, reliably killing entire process trees). This is why {{{timeout.hs}}} exists in the first place, and why the proposed patch introduces {{{winbindings.py}}}. - The patch does not improve testsuite performance; the goal is to improve maintainability. This raises to the following issues: 1. Between {{{winbindings.py}}} and {{{timeout.hs}}}, I don't see a significant reduction in overall complexity. We remove Windows-specific Haskell code, and replace it with Windows-specific Python code; both are a maintenance liability. 2. {{{timeout.hs}}} works; {{{winbindings.py}}} and the rewritten test driver parts are mostly untested as of yet. There is a nonzero change of this patch introducing new, possibly subtle, bugs. 3. GHC developers are more likely to want to work on complicated Haskell code than complicated Python code, and be competent at it. So Python code in this context has a higher barrier to participation, and a smaller contributor pool to draw from. 4. Managing Python versions, especially on Windows, is a nontrivial effort. The less we rely on it, the better. 5. Given 3. and 4., and also for other reasons, we would prefer moving (parts of) the test driver from Python to Haskell, not the other way around. Ideally, we would want to see the test driver rewritten in Haskell entirely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 09:35:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 09:35:28 -0000 Subject: [GHC] #15563: Typo in the documentation for Numeric.Natural. In-Reply-To: <042.7abd2e76bb8c52c1b059eca61d92e958@haskell.org> References: <042.7abd2e76bb8c52c1b059eca61d92e958@haskell.org> Message-ID: <057.b1d965ac88e2bbcdf1c11e5fe7647b17@haskell.org> #15563: Typo in the documentation for Numeric.Natural. -------------------------------------+------------------------------------- Reporter: asr | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Documentation | 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 osa1): * status: new => merge Comment: Fixed with 36c1431d9d2d06049190cc0888dbfaee8e2179d6 (Github PR 189). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 09:36:12 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 09:36:12 -0000 Subject: [GHC] #15285: "strange closure type" in T7919 with the threaded2 way In-Reply-To: <048.67a85438785d72c47b85ee0ad004eab2@haskell.org> References: <048.67a85438785d72c47b85ee0ad004eab2@haskell.org> Message-ID: <063.ca86348b68369ab430a6763ff2ced9e9@haskell.org> #15285: "strange closure type" in T7919 with the threaded2 way -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: T7919 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Looked at this ticket briefly today and managed to get at least 3 different faiures with threaded runtime when sanity checks are enabled. {{{ $ ./T7919 +RTS -DS -N >/dev/null Memory leak detected: gen 0 blocks : 204 blocks ( 0.8 MB) gen 1 blocks : 2309 blocks ( 9.0 MB) nursery : 3074 blocks ( 12.0 MB) retainer : 0 blocks ( 0.0 MB) arena blocks : 0 blocks ( 0.0 MB) exec : 0 blocks ( 0.0 MB) GC free pool : 77 blocks ( 0.3 MB) free : 1895 blocks ( 7.4 MB) total : 7559 blocks ( 29.5 MB) in system : 7560 blocks (30 MB) Unreachable blocks: T7919: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 992 (GHC version 8.7.20180827 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./T7919 +RTS -DS -N > /dev/null $ ./T7919 +RTS -DS -N >/dev/null T7919: internal error: ASSERTION FAILED: file rts/sm/BlockAlloc.c, line 901 (GHC version 8.7.20180827 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./T7919 +RTS -DS -N > /dev/null rts git:(master) $ ./T7919 +RTS -DS -N >/dev/null T7919: internal error: ASSERTION FAILED: file rts/sm/BlockAlloc.c, line 899 (GHC version 8.7.20180827 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./T7919 +RTS -DS -N > /dev/null }}} Some other failures without sanity checks (but with debug runtime): {{{ $ ./T7919 +RTS -N >/dev/null T7919: internal error: ASSERTION FAILED: file rts/sm/Sanity.c, line 991 (GHC version 8.7.20180827 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./T7919 +RTS -N > /dev/null $ ./T7919 +RTS -N >/dev/null T7919: internal error: ASSERTION FAILED: file rts/sm/GCUtils.c, line 105 (GHC version 8.7.20180827 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./T7919 +RTS -N > /dev/null }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 10:23:31 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 10:23:31 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation In-Reply-To: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> References: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> Message-ID: <061.69834eb9840bf2b49c6edbb3232862e8@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: 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): (NB: this comment does not respond to `test2`, which I'm still investigating.) I can see what is happening in `test0` vs `test1`. In `test0` we get {{{ lvl_sdWb :: Char -> Bool [LclId, Arity=1] lvl_sdWb = \ (c_X402 :: Char) -> case c_X402 of { GHC.Types.C# ipv_sbcB [Dmd=] -> case ipv_sbcB of { __DEFAULT -> GHC.Types.False; 'e'# -> GHC.Types.True; 's'# -> GHC.Types.True; 't'# -> GHC.Types.True } } $wtest0_sdEs = \ (ww_sdEo :: GHC.Prim.ByteArray#) (ww_sdEp :: GHC.Prim.Int#) (ww_sdEq :: GHC.Prim.Int#) -> case $sunion_scrz lvl_scJr lvl_sdWa of dt_X4yi [Dmd=] { __DEFAULT -> case $sunion_scrz lvl_scJp dt_X4yi of dt_X4yq { __DEFAULT -> $wrunTokenParser_sdDw (Main.Many @ Char (Main.Tokens @ Char dt_X4yq lvl_sdWb)) ww_sdEo ww_sdEp ww_sdEq } } }}} So `SpecConstr` will specialise `$wrunTokenParser` thus: {{{ RULES "SC:$wrunTokenParser1" [2] forall (sc_se8A :: GHC.Prim.Int#) (sc_se8z :: GHC.Prim.Int#) (sc_se8y :: GHC.Prim.ByteArray#) (sc_se8x :: Set Char). $wrunTokenParser_sdDw (Main.Many @ Char (Main.Tokens @ Char sc_se8x lvl_sdWb)) sc_se8y sc_se8z sc_se8A = $s$wrunTokenParser_se8G sc_se8A sc_se8z sc_se8y sc_se8x] }}} Notice, in particular, `lvl_sdWb`, which is a top-level constant (not forall'd by the RULE): the specialised `runTokenParser` knows exactly what that function is, and that makes the inner loop fast. The fact that it is specialised for `Many` and `Tokens` is incidental, because `runTokenParser` is not recursive; it's the loop inside (which comes from `span`) that is rendered fast by knowing the function given to `span`. In contrast, `test1` doesn't get any specialisation. {{{ test1 = runTokenParser testGrammar1 }}} Even if you manually eta-expand it, by writing {{{ test3 src = runTokenParser testGrammar1 src }}} we still get nothing useful {{{ Main.$wtest3 = \ (ww_sdIT :: GHC.Prim.ByteArray#) (ww1_sdIU :: GHC.Prim.Int#) (ww2_sdIV :: GHC.Prim.Int#) -> $wrunTokenParser_resz testGrammar1_r23E ww_sdIT ww1_sdIU ww2_sdIV }}} What happened in `test0` (the fast case) is that the programmer manually inlined `testGrammar1_r23E`: {{{ testGrammar1_r23E = case Main.$sunion lvl17_resE lvl19_resH of dt_X4B6 { __DEFAULT -> case Main.$sunion lvl18_resG dt_X4B6 of dt1_X4Be { __DEFAULT -> Main.Many @ Char (Main.Tokens @ Char dt1_X4Be lvl10_ress) } } }}} But GHC is super-cautious about doing so in `test3`, in case we duplicate the work of computing `testGrammar1`: Those `union`s might be expensive! And `test3` might be applied to many different `src` arguments. In contrast, in `test1` you manually put the grammar inside the `\src`. --------------- '''Analysis''' There are two problems: 1. In `test3`, GHC's caution about inlining `testGrammar1` is (in general) reasonable. Perhaps the Right Thing is to ignore the problem of work-duplication if the user supplies an INLINE pragma, which you do in this case, presumably for that exact reason. Let's see: danilo2, what led you to the INLINE pragma on `testGrammar1`? 2. `test1` is not eta-expanded, because it's a partial application: see `Note [Do not eta-expand PAPs]` in `SimplUtils`. And because it is not eta-expanded, `runTokenParser` doesn't get enough arguments and `SpecConstr` doesn't consider under-saturated calls. Moreover, even `test0` is fragile: it's entirely possible that the full- laziness pass will float out all those let-bindings (for `s1`, `s2` etc) to top level, since they are independent of `src` ------------- '''Workarounds''' A robust improvement is to use `oneShot`: {{{ test3 = oneShot (runTokenParser testGrammar1) }}} The magic `oneShot` function eta-expands its argument to a one-shot lambda: {{{ test3 = \src[one-shot] -> runTokenParser testGrammar1 src }}} Now at least, if `testGrammar1` is inlined, it won't get floated out again. Next thing: make this the ''only'' occurrence of `testGrammar1`; then there is no duplication issue when inlining it, so we get {{{ test3 = \src[one-shot] -> runTokenParser (...code for the grammar...) src }}} In the test case, `testGrammar1` is used in two different tests, so it currently won't get inlined (lest we have work duplication); but in your real code it is probably used only once, I guess. Last thing: remove the INLINE pragma on `testGrammar1`. It may seem silly but if a binding has an INLINE pragma, even if it is used exactly once it is not inlined. Why not? See `Note [Stable unfoldings and preInlineUnconditionally]`. This really is silly: see Fix 1 below. -------------- '''Fixing it properly''' * '''Fix 1''': concerning `Note [Stable unfoldings and preInlineUnconditionally]`, perhaps we should not do this for arity-0 bindings. * '''Fix 2''': perhaps we should honour INLINE pragmas on 0-arity bindings, and simply inline them at every usage site regardless. It's not so clear how to solve the eta-expansion problem. Ideas * we could try to make `SpecConstr` deal with under-saturated calls; and/or * we could eta-expand PAPs provided no coercions were involved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 12:22:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 12:22:22 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation In-Reply-To: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> References: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> Message-ID: <061.31329398446b1cb59492b1d6123fb719@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK I have figured out `test2`. Consider {{{ f x p = case x of A y -> ..(f y p2)... B z -> map z something main = f (A (B isEven)) blah }}} `SpecConstr` will see the call `f (A (B isEven))` but, looking at `f`, it only see a single-level pattern-match on `x`, so it'll only do a single- level specialisation: {{{ f_spec y p = ...(f y p2)... {-# RULE f (A y) p = f_spec y p #-} }}} This is good so far as it goes, but we are left with {{{ f_spec y p = ...(f y p2)... main = f_spec (B isEven) something }}} which is not good (because we have not specialised on `B`. Even if we ran `SpecConstr` a second time, it won't see any reason to specialise `f_spec` (since it does not directly scrutinise `y`), and neither will it see any reason to further specialise `f`. It would be much better to specialise on that full call in the first place, giving {{{ f_spec1 p = ...(f (B isEven) p2)... {-# RULE f (A (B isEven)) p = f_spec1 p #-} }}} Now we have a call in the body of `f_spec1` that we can specialise, and `SpecConstr` does just that, giving {{{ f_spec2 p = map isEven something {-# RULE f (B isEven) p = f_spec2 p #-} }}} And all is good. The final code is {{{ f_spec2 p = map isEven something f_spec1 y p = ...(f_spec2 y p2)... main = f_spec1 blah }}} But specialising on the full call pattern risks over-specialising, duplicating code to no purpose, ''and'' making the specialisation less useful to other callers. I'm not sure what to do about this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 12:23:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 12:23:14 -0000 Subject: [GHC] #15572: TH improperly converts promoted data cons in ConT In-Reply-To: <050.0e46c20217a7ed360417cc67421971cd@haskell.org> References: <050.0e46c20217a7ed360417cc67421971cd@haskell.org> Message-ID: <065.2a77250d73cb2257b10f817fd2df4f49@haskell.org> #15572: TH improperly converts promoted data cons in ConT -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T15572 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5112 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => th/T15572 * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 12:27:53 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 12:27:53 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation In-Reply-To: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> References: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> Message-ID: <061.2d7d9fa2e7cc3af4322946e51d2ad7e1@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => SpecConstr Comment: OK, re comment:12, this is an old problem: see Trac #4448. The current (horrible) solution is to take control explicitly, like this {{{ import GHC.Type( SPEC(..) ) runTokenParser :: SPEC -> Grammar Char -> Text -> Result runTokenParser = \sp grammar stream -> case grammar of Tokens _ tst -> let head = Text.head stream in if tst head then Success (Text.tail stream) (Text.singleton head) else Fail Many (Tokens _ tst) -> let (!consumed, !rest) = Text.span tst stream in Success rest consumed X !grammar -> runTokenParser sp grammar stream }}} Notice that `SPEC` argument. It's not actually used, but it tells `SpecConstr` to specialise the call regardless of whether the function scrutinises the argument (see Trac #4448 for a simpler example). That indeed makes `test2` work nicely. I don't claim that it's nice. At all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 12:38:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 12:38:29 -0000 Subject: [GHC] #15474: Error message mentions Any In-Reply-To: <047.c27fe3661bd6607bc87bf78cbba746cc@haskell.org> References: <047.c27fe3661bd6607bc87bf78cbba746cc@haskell.org> Message-ID: <062.d198a47e13b59e7da49ca7486a8ad887@haskell.org> #15474: Error message mentions Any -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, this is awkward. What is happening is that we end up with this: {{{ type Forall = forall (t :: Any). Proxy @Any t }}} I think that perhaps in this case we should kind-generalise the RHS of `Forall` to get {{{ type Forall k = forall (t :: k) . Proxy @k t }}} I'm not sure why we don't do this. We certainly do some kind- generalisation; e.g. if you write {{{ type T x = x }}} we end up with {{{ type T k (x :: k) = x }}} So why doesn't something like that happen for `Forall`? Interesting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 12:44:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 12:44:25 -0000 Subject: [GHC] #15474: Error message mentions Any In-Reply-To: <047.c27fe3661bd6607bc87bf78cbba746cc@haskell.org> References: <047.c27fe3661bd6607bc87bf78cbba746cc@haskell.org> Message-ID: <062.4bde91104bd8bf9c2834b1b3d528e2c0@haskell.org> #15474: Error message mentions Any -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > So why doesn't something like that happen for Forall? Ah, I think it's because * The kind of `Forall`'s RHS is just `Type` * And we do kind-generalise that kind; it has no free kind variables, so no kind-generalisation actually happens. And in any case the decl {{{ type Forall k = forall (t :: k). Proxy @k t }}} gives `Forall` the ambiguous kind `Forall :: forall k. Type`, which will do no one any good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 12:56:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 12:56:29 -0000 Subject: [GHC] #15474: Error message mentions Any In-Reply-To: <047.c27fe3661bd6607bc87bf78cbba746cc@haskell.org> References: <047.c27fe3661bd6607bc87bf78cbba746cc@haskell.org> Message-ID: <062.778fadd63cd26dac68dac4dcec8556b1@haskell.org> #15474: Error message mentions Any -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14198 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #14198 Comment: Another option, discussed in #14198, is to reject the declaration of `Forall` entirely after kind-generalizing its RHS, side the kind variable `k` is free-floating. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 12:56:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 12:56:43 -0000 Subject: [GHC] #15570: Core transformations generate bad indexCharOffAddr# call In-Reply-To: <048.6749470bd8e5b16854763831c1951d1e@haskell.org> References: <048.6749470bd8e5b16854763831c1951d1e@haskell.org> Message-ID: <063.2de2c578e5d30592892bffbf6794bd16@haskell.org> #15570: Core transformations generate bad indexCharOffAddr# call -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: alpmestan Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): Hm, actually you're on Windows right? In which case you'll want to use `hadrian/build.bat` I think. [https://github.com/snowleopard/hadrian/blob/master/doc/windows.md This page] documents pre-requisites. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 12:57:12 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 12:57:12 -0000 Subject: [GHC] #14198: Inconsistent treatment of implicitly bound kind variables as free-floating In-Reply-To: <050.fc7092bf8815668ee061af436c2c49de@haskell.org> References: <050.fc7092bf8815668ee061af436c2c49de@haskell.org> Message-ID: <065.ea03e7701e7cd92eca03c199c721d3f2@haskell.org> #14198: Inconsistent treatment of implicitly bound kind variables as free-floating -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14268 | Blocking: Related Tickets: #7873, #15474 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #7873 => #7873, #15474 Comment: See #15474 for another ticket about `type Foo3` in the original comment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 13:12:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 13:12:08 -0000 Subject: [GHC] #15363: Do some cleaning up of the testsuite driver In-Reply-To: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> References: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> Message-ID: <060.422304513c44da17d8f5fbbe9c10fe76@haskell.org> #15363: Do some cleaning up of the testsuite driver -------------------------------------+------------------------------------- Reporter: lantti | Owner: lantti Type: task | Status: patch Priority: low | Milestone: 8.8.1 Component: Test Suite | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5107 Wiki Page: | -------------------------------------+------------------------------------- Comment (by lantti): I agree with this summary. To add some more (possibly superfluous) details, the original problem is not only Windows specific. In order to maintain a consistent interface the current POSIX code path also shells out an external process (a separate python interpreter) to handle the timeout and interrupting functionality even when {{{subprocess}}} functionality would be adequate on POSIX. To issue 1.: I have nothing to add. To issue 2.: I'd like to add that even {{{timeout.hs}}} itself is not fully functional at the moment, failing to handle interrupts signals, although {{{winbindings.py}}} doesn't do any better job either. Interrupting the test run on Windows works only because {{{mintty}}} simply kills our whole process tree without consulting our code at all, resulting in different but still effective end to the test run (compared to POSIX). The results for the tests already run won't get displayed in that case but fortunately this functionality doesn't strike me as essential. To issues 3,4,5: If this is the direction we should be going I'll happily align my efforts with it instead. I was under the impression that currently hs->py was the preferred way as according to the git logs (e5063a042c9a1701ea7273da7bacb530d5c077d3) GHC used to have a testsuite language and appropriate interpreter implemented all in Haskell. The stated motivation to move away from the Haskell code was maintainability but presumably we have a lot better Haskell libraries now than back then and the maintainability would perhaps not become such an issue anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 14:00:04 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 14:00:04 -0000 Subject: [GHC] #15575: Investigate Haskell rewrite of testsuite driver Message-ID: <047.17065377223303ab628d71f18b4e3b0e@haskell.org> #15575: Investigate Haskell rewrite of testsuite driver -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Research needed Component: Test Suite | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15363 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, the testsuite driver is written in Python. This is a bit of a liability: - Having to program in "not Haskell" might scare away potential contributors here - Even developers who are proficient in Python probably prefer working with Haskell - Managing Python as a dependency poses an additional burden and complicates deployment, setting up dev environments, CI, etc.; especially on Windows. - We miss out on the benefits of type checks and typed programming for a substantial bit of infrastructure - We miss out on a nice dog-fooding opportunity So in order to judge the scope of this task, and define it better, it would be good to investigate a bit: - What would it take to get high-level feature parity with the current solution? - Does the Haskell ecosystem cover the concerns that we would like to address with existing libraries? (Process management, for example) - Can we come up with a smart and frictionless way of migrating all the existing test cases in a reliable automated fashion? - What are risks and unknowns? #15363 is the recent case that sparked this - rather than the proposed patch there, which ports existing Haskell code to Python, we would prefer going in the other direction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 14:02:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 14:02:43 -0000 Subject: [GHC] #15575: Investigate Haskell rewrite of testsuite driver In-Reply-To: <047.17065377223303ab628d71f18b4e3b0e@haskell.org> References: <047.17065377223303ab628d71f18b4e3b0e@haskell.org> Message-ID: <062.6b37564e78c3a906323950992720f19a@haskell.org> #15575: Investigate Haskell rewrite of testsuite driver -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Research | needed Component: Test Suite | 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: #15363 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * cc: tdammers, lantti (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 14:24:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 14:24:51 -0000 Subject: [GHC] #15566: Implement minimumOn, maximumOn to mirror sortOn In-Reply-To: <046.9955d151a0d096fa05b640c0d0259990@haskell.org> References: <046.9955d151a0d096fa05b640c0d0259990@haskell.org> Message-ID: <061.2979d0ed770b1457ab6ccb7b32d79ce2@haskell.org> #15566: Implement minimumOn, maximumOn to mirror sortOn -------------------------------------+------------------------------------- Reporter: Garciat | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Research | needed Component: libraries/base | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13573 | Differential Rev(s): Phab:D5110 Wiki Page: | -------------------------------------+------------------------------------- Changes (by potato44): * differential: D5110 => Phab:D5110 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 14:46:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 14:46:06 -0000 Subject: [GHC] #15569: Constant folding optimises 1 into 3 In-Reply-To: <050.faecf73a66ba46b12a33656ce184ee72@haskell.org> References: <050.faecf73a66ba46b12a33656ce184ee72@haskell.org> Message-ID: <065.cbd7ce60b4ac39e293f69181195ded32@haskell.org> #15569: Constant folding optimises 1 into 3 -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9136 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"65eec9cfd4410c0e30b0ed06116c15f8ce3de49d/ghc" 65eec9cf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="65eec9cfd4410c0e30b0ed06116c15f8ce3de49d" Fix a constant folding rule Summary: One of the constant folding rules introduced in D2858 is: ``` (L y :-: v) :-: (L x :-: w) -> return $ mkL (y-x) `add` (w `add` v) ``` Or, after removing syntactic noise: `(y - v) - (x - w) ==> (y - x) + (w + v)`. This is incorrect, since the sign of `v` is changed from negative to positive. As a consequence, the following program prints `3` when compiled with `-O`: ``` -- This is just subtraction in disguise minus :: Int -> Int -> Int minus x y = (8 - y) - (8 - x) {-# NOINLINE minus #-} main :: IO () main = print (2 `minus` 1) ``` The correct rule is: `(y - v) - (x - w) ==> (y - x) + (w - v)`. This commit does the fix. I haven't found any other issues with the constant folding code, but it's difficult to be certain without some automated checking. Reviewers: bgamari, tdammers Subscribers: hsyl20, tdammers, rwbarton, carter GHC Trac Issues: #15569 Differential Revision: https://phabricator.haskell.org/D5109 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 16:15:19 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 16:15:19 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation In-Reply-To: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> References: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> Message-ID: <061.a3f6f3fefd19f00876d3d978398c852a@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 16:35:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 16:35:23 -0000 Subject: [GHC] #15552: Infinite loop/panic with an existential type. In-Reply-To: <050.eb5168d400b4a4211e35d29d96945d09@haskell.org> References: <050.eb5168d400b4a4211e35d29d96945d09@haskell.org> Message-ID: <065.c2678a95551cd41a2aca0c27bd40ec96@haskell.org> #15552: Infinite loop/panic with an existential type. -------------------------------------+------------------------------------- Reporter: howtonotwin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: TypeInType, | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14723 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Another idea for (1): just eliminate the "optimisation" in `TcHsType.zonkTyVarOcc`. Types generally have no sharing, so we may not be gaining much by increasing sharing her. NB: in `TcMType.zonkTcTyVar` we could apply this optimisation; for some reason we don't even try to do that too. Another idea: maintain (statefully) a map from (meta) `TyVar` to `TyVar`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 16:37:11 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 16:37:11 -0000 Subject: [GHC] #15552: Infinite loop/panic with an existential type. In-Reply-To: <050.eb5168d400b4a4211e35d29d96945d09@haskell.org> References: <050.eb5168d400b4a4211e35d29d96945d09@haskell.org> Message-ID: <065.4fd4b166d7aeef4fba560d3c65d1849a@haskell.org> #15552: Infinite loop/panic with an existential type. -------------------------------------+------------------------------------- Reporter: howtonotwin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: TypeInType, | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14723 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): (written concurrently with commen:8) After some discussion, Simon and I agreed that (1) from comment:7 would nab this bug. But many other questions/observations came up: A. This bug is caused by an optimization. What if we don't do the optimization? How much is performance affected? We hypothesize: not much. This is because while the optimization increases sharing in both time and space, this sharing is soon lost (in space, at least) in further passes. B. Interestingly, the other zonker (`zonkTcType` and friends in !TcMType) does not do this optimization. It could, and it wouldn't be plagued by this bug, as `TyCon`s aren't zonked there. So we've done the optimization in precisely the places we shouldn't. C. The optimization doesn't quite go far enough. Consider `alpha := beta -> beta` and `beta := Maybe (Int, Bool)`. Zonking `alpha` replaces the contents of the cell with `Maybe (Int, Bool) -> Maybe (Int, Bool)` instead of `beta -> beta`. But the next time we zonk `alpha`, we'll still walk over the large type `Maybe (Int, Bool) -> Maybe (Int, Bool)`. Simon and I puzzled on (C) for quite some time. We came up with a few approaches to implementing a better way to avoid redundant zonking. The key observation is that once we zonk `alpha` (and update its contents according to the current optimization), we don't have to do this again in the same zonk. a. We can track epoch numbers in the `TcM` monad (in a new mutable cell). The epoch would increase at every unification. Every `Indirect` node would store the epoch number of the type stored in the node -- that is, the type is fully zonked with respect to the stored epoch number. When zonking, if we encounter an `Indirect` whose epoch number matches the current epoch number, we know that the type is already zonked, and we can avoid traversing it. b. The idea in (a) doesn't apply only to filled-in metavariables, but to all types. The type-checker occasionally zonks types. However, if a type has already been zonked and there have been no unifications, then zonking it again is a waste of time. If we store an epoch number with every type, then we can check this against the global epoch number and skip some zonks. c. The idea in (b) is a bit heavy, though, requiring alternating proper `Type` nodes with epoch numbers in every type. Instead, we could just do this in `TcTyVar`s, where we store the epoch number of their kind. d. An alternative to epoch numbers is to have each individual zonk track which variables' contents are already zonked. This could be done by adding an `IORef TyVarEnv` to the local environment to the zonk (replacing the `()` environment of a `zonkTcType` or adding to the `ZonkEnv` of a `zonkTcTypeToType`). Every time we zonk a variable, add the variable to the env't, mapping it to its fully-zonked contents (or, in the case of a `TyVar`, a version of the `TyVar` with a zonked kind). With any of these ideas, it's not obvious that the work will be worth it, as it's hard to know how much redundant zonking we're doing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 16:41:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 16:41:23 -0000 Subject: [GHC] #15576: Hadrian puts its build tree in the wrong place Message-ID: <046.775a5c9a9255ff4303e7bb0241f9c28d@haskell.org> #15576: Hadrian puts its build tree in the wrong place -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have a source tree in my slow, network-mounted backed-up filestore `/home/simonpj/ghc`, and a separate link-tree in my fast, physically- connected, non-backed up filestore `/playpen/ghc`. Every file in `/playpen/ghc` is a symlink to the corresponding source file in `/home/simonpj/ghc`. But when I do {{{ $ cd /playpen/ghc $ hadrian/build.sh -c -j4 --flavour=quick }}} I find a new `_build` director in `/home/simonpj/ghc`. This is bad! It should be in `/playpen/ghc`. Otherwise (a) it's slower, (b) it creates backup churn and (c) as it happens, I ran out of space on the backed-up filestore. Can this be fixed? It's a bad Hadrian shortcoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 16:57:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 16:57:42 -0000 Subject: [GHC] #15530: Type applications in patterns In-Reply-To: <046.ac75a1c05d26e58243b1cc5f1128ff00@haskell.org> References: <046.ac75a1c05d26e58243b1cc5f1128ff00@haskell.org> Message-ID: <061.add10adf95e7b6643bc18ea30b26212b@haskell.org> #15530: Type applications in patterns -------------------------------------+------------------------------------- Reporter: nomeata | Owner: mnguyen Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mnguyen): * owner: (none) => mnguyen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 17:27:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 17:27:10 -0000 Subject: [GHC] #15418: Performance drop 60 times on non-profiling binary In-Reply-To: <045.a055029aec148ca416c29df30694b018@haskell.org> References: <045.a055029aec148ca416c29df30694b018@haskell.org> Message-ID: <060.30950d8ebb6d665c856af4f5ae2b5866@haskell.org> #15418: Performance drop 60 times on non-profiling binary -------------------------------------+------------------------------------- Reporter: hth313 | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14414, #9599 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hth313): Would it work if I could provide object files and a command line, so that you can relink it, to make it possible to try different run-times? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 17:44:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 17:44:45 -0000 Subject: [GHC] #15562: `-XStrict -XNoStrict` is not neutral In-Reply-To: <042.ba188334cc4bb9cd167859c3f14e424e@haskell.org> References: <042.ba188334cc4bb9cd167859c3f14e424e@haskell.org> Message-ID: <057.24b311fd80372110469712f9fe1dfaa4@haskell.org> #15562: `-XStrict -XNoStrict` is not neutral -------------------------------------+------------------------------------- Reporter: hvr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:4 goldfire]: > My vote would be simply not to make any guarantees of this sort. It's not hard for a tool to consult `DynFlags.impliedXFlags` and figure out what reorderings are OK. While I agree now with that it's hopeless to give any guarantees; I disagree that consulting `DynFlags.impliedXFlags` is "not hard" for tools -- tools most often avoid to link against `lib:ghc` so they wouldn't have access to it; instead they tend to query e.g. `ghc --supported-languages` which unfortunately does not expose the relationships between those flags. It would be very useful for tooling if `ghc`'s CLI had some flag to dump an extended version of `--supported-languages` that's easy to parse -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 17:45:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 17:45:59 -0000 Subject: [GHC] #15576: Hadrian puts its build tree in the wrong place In-Reply-To: <046.775a5c9a9255ff4303e7bb0241f9c28d@haskell.org> References: <046.775a5c9a9255ff4303e7bb0241f9c28d@haskell.org> Message-ID: <061.37d85a833ab894384c0b2a5e2d1e1a1d@haskell.org> #15576: Hadrian puts its build tree in the wrong place -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): You can change the build directory via the command line using `--build- root=PATH` (or shorter `-oPATH`). Can you try this? {{{ hadrian/build.sh -c -j4 --flavour=quick -o/playpen/ghc }}} This is documented here: https://github.com/snowleopard/hadrian#command- line-flags. We can also add support for specifying the build directory in `UserSettings` so that you don't need to specify it each time via the command line. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 17:59:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 17:59:26 -0000 Subject: [GHC] #15363: Do some cleaning up of the testsuite driver In-Reply-To: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> References: <045.a430f790c6974ee2b2076746bbbf1d29@haskell.org> Message-ID: <060.6187081db7798ce2bb2c704273b7111a@haskell.org> #15363: Do some cleaning up of the testsuite driver -------------------------------------+------------------------------------- Reporter: lantti | Owner: lantti Type: task | Status: closed Priority: low | Milestone: 8.8.1 Component: Test Suite | Version: 8.4.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5107 Wiki Page: | -------------------------------------+------------------------------------- Changes (by lantti): * status: patch => closed * resolution: => wontfix Comment: Considering that the current scripts are not seriously broken and that the whole testsuite is evaluated for a eventual rewrite, I close this as wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 18:08:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 18:08:30 -0000 Subject: [GHC] #8279: bad alignment in code gen yields substantial perf issue In-Reply-To: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> References: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> Message-ID: <060.a163774b45568c916fa633a2b72ba082@haskell.org> #8279: bad alignment in code gen yields substantial perf issue -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8082 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): I hit this today in `CSD` (kernel is basically a counting loop), with a delta of 12%. Supplying `-fllvm` swapped symptoms for me, still a delta of ~-8%. This was 1a0a971b76c0b717794af9af4e27dcb488924800 vs https://github.com/sgraf812/ghc/tree/25bba2b92b9bcdc090ae9418a0425ea0a829491e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 18:08:58 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 18:08:58 -0000 Subject: [GHC] #8279: bad alignment in code gen yields substantial perf issue In-Reply-To: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> References: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> Message-ID: <060.aca233b995b6c18a5ba4627a692e2a7c@haskell.org> #8279: bad alignment in code gen yields substantial perf issue -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8082 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 18:59:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 18:59:35 -0000 Subject: [GHC] #15577: TypeApplications-related infinite loop (GHC 8.6+ only) Message-ID: <050.727e460d0083534afd4869db4aa81c30@haskell.org> #15577: TypeApplications-related infinite loop (GHC 8.6+ only) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: | Operating System: Unknown/Multiple TypeApplications, TypeInType | Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program will loop infinitely when compiled on GHC 8.6 or HEAD: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind import Data.Type.Equality data family Sing :: forall k. k -> Type class Generic1 (f :: k -> Type) where type Rep1 f :: k -> Type class PGeneric1 (f :: k -> Type) where type From1 (z :: f a) :: Rep1 f a type To1 (z :: Rep1 f a) :: f a class SGeneric1 (f :: k -> Type) where sFrom1 :: forall (a :: k) (z :: f a). Sing z -> Sing (From1 z) sTo1 :: forall (a :: k) (r :: Rep1 f a). Sing r -> Sing (To1 r :: f a) class (PGeneric1 f, SGeneric1 f) => VGeneric1 (f :: k -> Type) where sTof1 :: forall (a :: k) (z :: f a). Sing z -> To1 (From1 z) :~: z sFot1 :: forall (a :: k) (r :: Rep1 f a). Sing r -> From1 (To1 r :: f a) :~: r foo :: forall (f :: Type -> Type) (a :: Type) (r :: Rep1 f a). VGeneric1 f => Sing r -> From1 (To1 r :: f a) :~: r foo x | Refl <- sFot1 -- Uncommenting the line below makes it work again: -- @Type @f @a @r x = Refl }}} This is a regression from GHC 8.4, since compiling this program with 8.4 simply errors: {{{ $ /opt/ghc/8.4.3/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:35:20: error: • Expecting one more argument to ‘f’ Expected a type, but ‘f’ has kind ‘* -> *’ • In the type ‘f’ In a stmt of a pattern guard for an equation for ‘foo’: Refl <- sFot1 @f @a @r x In an equation for ‘foo’: foo x | Refl <- sFot1 @f @a @r x = Refl | 35 | @f @a @r x | ^ Bug.hs:35:23: error: • Expected kind ‘f1 -> *’, but ‘a’ has kind ‘*’ • In the type ‘a’ In a stmt of a pattern guard for an equation for ‘foo’: Refl <- sFot1 @f @a @r x In an equation for ‘foo’: foo x | Refl <- sFot1 @f @a @r x = Refl • Relevant bindings include x :: Sing r1 (bound at Bug.hs:32:5) foo :: Sing r1 -> From1 (To1 r1) :~: r1 (bound at Bug.hs:32:1) | 35 | @f @a @r x | ^ Bug.hs:35:26: error: • Couldn't match kind ‘* -> *’ with ‘*’ When matching kinds f1 :: * -> * Rep1 f1 a1 :: * Expected kind ‘f1’, but ‘r’ has kind ‘Rep1 f1 a1’ • In the type ‘r’ In a stmt of a pattern guard for an equation for ‘foo’: Refl <- sFot1 @f @a @r x In an equation for ‘foo’: foo x | Refl <- sFot1 @f @a @r x = Refl • Relevant bindings include x :: Sing r1 (bound at Bug.hs:32:5) foo :: Sing r1 -> From1 (To1 r1) :~: r1 (bound at Bug.hs:32:1) | 35 | @f @a @r x | ^ Bug.hs:35:28: error: • Couldn't match kind ‘*’ with ‘GHC.Types.RuntimeRep’ When matching kinds a1 :: * 'GHC.Types.LiftedRep :: GHC.Types.RuntimeRep • In the fourth argument of ‘sFot1’, namely ‘x’ In a stmt of a pattern guard for an equation for ‘foo’: Refl <- sFot1 @f @a @r x In an equation for ‘foo’: foo x | Refl <- sFot1 @f @a @r x = Refl • Relevant bindings include x :: Sing r1 (bound at Bug.hs:32:5) foo :: Sing r1 -> From1 (To1 r1) :~: r1 (bound at Bug.hs:32:1) | 35 | @f @a @r x | ^ Bug.hs:36:5: error: • Could not deduce: From1 (To1 r1) ~ r1 from the context: r0 ~ From1 (To1 r0) bound by a pattern with constructor: Refl :: forall k (a :: k). a :~: a, in a pattern binding in pattern guard for an equation for ‘foo’ at Bug.hs:33:5-8 ‘r1’ is a rigid type variable bound by the type signature for: foo :: forall (f1 :: * -> *) a1 (r1 :: Rep1 f1 a1). VGeneric1 f1 => Sing r1 -> From1 (To1 r1) :~: r1 at Bug.hs:(29,1)-(31,43) Expected type: From1 (To1 r1) :~: r1 Actual type: r1 :~: r1 • In the expression: Refl In an equation for ‘foo’: foo x | Refl <- sFot1 @f @a @r x = Refl • Relevant bindings include x :: Sing r1 (bound at Bug.hs:32:5) foo :: Sing r1 -> From1 (To1 r1) :~: r1 (bound at Bug.hs:32:1) | 36 | = Refl | ^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 19:23:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 19:23:36 -0000 Subject: [GHC] #15577: TypeApplications-related infinite loop (GHC 8.6+ only) In-Reply-To: <050.727e460d0083534afd4869db4aa81c30@haskell.org> References: <050.727e460d0083534afd4869db4aa81c30@haskell.org> Message-ID: <065.87d3b5ef54416afb6fd8a0afe697a3e6@haskell.org> #15577: TypeApplications-related infinite loop (GHC 8.6+ only) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | TypeApplications, TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Here's a somewhat smaller example: {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind import Data.Proxy import Data.Type.Equality type family F (x :: f (a :: k)) :: f a f :: forall k (f :: k -> Type) (a :: k) (r :: f a). Proxy r -> F r :~: r f = undefined g :: forall (f :: Type -> Type) (a :: Type) (r :: f a). Proxy r -> F r :~: r g r | Refl <- f -- Uncommenting the line below makes it work again -- @Type @f @a @r r = Refl }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 19:55:04 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 19:55:04 -0000 Subject: [GHC] #15418: Performance drop 60 times on non-profiling binary In-Reply-To: <045.a055029aec148ca416c29df30694b018@haskell.org> References: <045.a055029aec148ca416c29df30694b018@haskell.org> Message-ID: <060.7b8729a8c32987c4203cf3f39ef17080@haskell.org> #15418: Performance drop 60 times on non-profiling binary -------------------------------------+------------------------------------- Reporter: hth313 | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14414, #9599 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): To be honest I don't think that'd be helpful. Normally for this I'd start with comparing Core outputs of the program, with and without profiling flags. I think it's very likely that this will be enough to see why profiled version is faster. Btw, looking at the previous comments I realized that we didn't check different optimisation parameters. One of the reasons why sometimes profiling builds are faster is because profiling sometimes inhibits some optimisations (as it changes Core of the program), and optimisations sometimes make some programs slower. Could you try building your program without profiling, and with different optimisation settings? Please report numbers for: - -O0 - -O1 (default when using cabal) - -O2 If you're using cabal add these to `ghc-options` in your .cabal file. Depending on the numbers you can then try to disable individual optimisation passes (see the user manual or man page) etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 20:35:12 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 20:35:12 -0000 Subject: [GHC] #7674: Separate StablePtr table from StableName table. In-Reply-To: <048.d2a5d56c1de3421f091c52024ec9dfdd@haskell.org> References: <048.d2a5d56c1de3421f091c52024ec9dfdd@haskell.org> Message-ID: <063.3685a9495910228070385c2eb79312ae@haskell.org> #7674: Separate StablePtr table from StableName table. -------------------------------------+------------------------------------- Reporter: EyalLotem | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.2 Resolution: fixed | Keywords: rts | stable_ptr stable_name performance Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15555 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"f48e276a5ba68d8b6fcb4a558022581fb30f9326/ghc" f48e276a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f48e276a5ba68d8b6fcb4a558022581fb30f9326" Finish stable split Long ago, the stable name table and stable pointer tables were one. Now, they are separate, and have significantly different implementations. I believe the time has come to finish the split that began in #7674. * Divide `rts/Stable` into `rts/StableName` and `rts/StablePtr`. * Give each table its own mutex. * Add FFI functions `hs_lock_stable_ptr_table` and `hs_unlock_stable_ptr_table` and document them. These are intended to replace the previously undocumented `hs_lock_stable_tables` and `hs_lock_stable_tables`, which are now documented as deprecated synonyms. * Make `eqStableName#` use pointer equality instead of unnecessarily comparing stable name table indices. Reviewers: simonmar, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15555 Differential Revision: https://phabricator.haskell.org/D5084 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 20:35:12 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 20:35:12 -0000 Subject: [GHC] #15555: Finish separating the stable name and stable pointer tables In-Reply-To: <045.c599c4ef0bcb291ee1dd9d8857e04c44@haskell.org> References: <045.c599c4ef0bcb291ee1dd9d8857e04c44@haskell.org> Message-ID: <060.df8303d448531b7217dadc90a785090b@haskell.org> #15555: Finish separating the stable name and stable pointer tables -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7674 | Differential Rev(s): Phab:D5084 Wiki Page: | -------------------------------------+------------------------------------- Comment (by David Feuer ): In [changeset:"f48e276a5ba68d8b6fcb4a558022581fb30f9326/ghc" f48e276a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f48e276a5ba68d8b6fcb4a558022581fb30f9326" Finish stable split Long ago, the stable name table and stable pointer tables were one. Now, they are separate, and have significantly different implementations. I believe the time has come to finish the split that began in #7674. * Divide `rts/Stable` into `rts/StableName` and `rts/StablePtr`. * Give each table its own mutex. * Add FFI functions `hs_lock_stable_ptr_table` and `hs_unlock_stable_ptr_table` and document them. These are intended to replace the previously undocumented `hs_lock_stable_tables` and `hs_lock_stable_tables`, which are now documented as deprecated synonyms. * Make `eqStableName#` use pointer equality instead of unnecessarily comparing stable name table indices. Reviewers: simonmar, bgamari, erikd Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15555 Differential Revision: https://phabricator.haskell.org/D5084 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 20:36:49 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 20:36:49 -0000 Subject: [GHC] #15555: Finish separating the stable name and stable pointer tables In-Reply-To: <045.c599c4ef0bcb291ee1dd9d8857e04c44@haskell.org> References: <045.c599c4ef0bcb291ee1dd9d8857e04c44@haskell.org> Message-ID: <060.e80fa716587fc0764d53a24b0ffeef5c@haskell.org> #15555: Finish separating the stable name and stable pointer tables -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7674 | Differential Rev(s): Phab:D5084 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 21:15:04 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 21:15:04 -0000 Subject: [GHC] #15576: Hadrian puts its build tree in the wrong place In-Reply-To: <046.775a5c9a9255ff4303e7bb0241f9c28d@haskell.org> References: <046.775a5c9a9255ff4303e7bb0241f9c28d@haskell.org> Message-ID: <061.f7733070e70c2155c68d0c5506926d1a@haskell.org> #15576: Hadrian puts its build tree in the wrong place -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I don't particularly want to ''change'' the build directory; I just want it to be right here at the root of my build tree, where it has always been. (That is `-o$PWD`, I suppose.) Is that not a good default place for it to be? I suppose I can get used to doing something in UserSettings in every build tree; but I'd prefer the old behaviour. Is it difficult to achieve for some reason? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 21:51:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 21:51:34 -0000 Subject: [GHC] #15576: Hadrian puts its build tree in the wrong place In-Reply-To: <046.775a5c9a9255ff4303e7bb0241f9c28d@haskell.org> References: <046.775a5c9a9255ff4303e7bb0241f9c28d@haskell.org> Message-ID: <061.fa280791f526c8101c69ea3e3e0edfc5@haskell.org> #15576: Hadrian puts its build tree in the wrong place -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Ah, now I'm confused. If you run Hadrian from `/playpen/ghc` I don't understand why build results appear in `/home/simonpj/ghc`. > Is it difficult to achieve for some reason? Actually, I would say achieving the current behaviour seems difficult! I think the magic symlink-traversal code in `build.sh` and `build.cabal.sh` has something to do with it. I believe it was added by Herbert, but I don't recall why. Can you try building and running Hadrian directly using Cabal? {{{ cd hadrian cabal new-build --disable-profiling --disable-documentation -j exe:hadrian cabal new-run hadrian -- -c -j4 --flavour=quick --directory=".." }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 22:09:12 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 22:09:12 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation In-Reply-To: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> References: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> Message-ID: <061.492585bb26f70daf431fc3caf0a17401@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by danilo2): @simonpj, @sgraf, first of all, thank you very much for your time, taking look at this issue and investigating it so deeply. Thanks to it I have hope we will fix it! 1. First of all I'm simply amazed by the amount of workarounds here. I know I was writing this before in other tickets, but I care a lot about predictive performance in GHC. All the described things show me that its worse than I thought, see the following points. 2. In order to write high performance code we need invariants. Rules that we can follow and we can trust that they allow us get **exactly** the behavior we want. One of the most important invariants to me (probably the most important one) was always that if I use the INLINE pragma, the code will be inlined if the call is saturated and it will have exactly the same behavior if I just copy paste it there. I always understood that the INLINE pragma is exactly for this - to very precisely guide GHC how to optimize the code. Learning that GHC does not really inline all explicitly marked saturated calls and sometimes it gets better specialization when removing the INLINE pragma is just insane. it breaks the most primitive invariant that we can rely on and without it we cannot predict just anything about the performance of code we write. For me this is critical error. 3. Moreover I strongly disagree with the sentence that the "fix would be to remove INLINE pragma" because this leaves us in a world where GHC performance is completely unknown and we have to randomly enable / disable things hoping that it will magically get better. I suspect @sgraf that you didn't mean "fix" but instead a "dirty workaround for now", but I preferred to emphasize my worries regarding this matter. 4. Answering your question @simonpj, I completely understand that GHC is super-cautious about inlining things and making the code bigger, but that is exactly the reason why we can fine tune the behavior by telling GHC that we in reality want it to be inlined, right? Exactly this led me to use INLINE pragma here. When writing this code I know I will have here some very tight loops to be optimized and I know that no matter what it sohuld be inlined. 5. I'm surprised that `test1` is not eta expanded. How can I be sure my functions get eta expanded? I have read the `Note [Do not eta-expand PAPs]` but it's still not clear to me. What are the "invariants here". If I write high performance code should I always manually eta-expand functions? Should I rewrite it to `test1 = \t -> runTokenParser testGrammar1 t`? Please correct me if my thinking is wrong here. 6. Regarding the `test2`, specialization and over-specialising things. I see the problem and I don't know what approach would be good here. The only thing that is clear to me is that the change to code is so small, that nobody should expect such drastic performance changes and we should have a clear way of preventing such things from happening (again - invariant of how to write high performance code when we want to wrap some data in a compile-known constructor just to refactor things). 7. Looking at the source code I don't see any mention of the `SPEC` in GHC.Type. Where it cames from and where can I learn more about it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 22:16:55 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 22:16:55 -0000 Subject: [GHC] #8279: bad alignment in code gen yields substantial perf issue In-Reply-To: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> References: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> Message-ID: <060.f660367183b3a889ca5befab9f098af0@haskell.org> #8279: bad alignment in code gen yields substantial perf issue -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8082 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): re Simon PJ's and Simon Mar's comment , we don't quite know that that better alignment would improve speed at the cost of binary size , but the Intel documentation is a pretty strong hint that it proably will and is thus worth checking out, right? Couldn't we break this into two tasks: First to provide a patch with instructions on how to apply it e.g. to 8.6.1 or head or whatever and a task to benchmark the resulting compiler. The benchmarking task could be done by people with much less, or at leasts different, expertise than it takes to produce such a patch right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 22:46:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 22:46:13 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation In-Reply-To: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> References: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> Message-ID: <061.1a60006879f485686efa77b4b3de1657@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I strongly disagree with the sentence that the "fix would be to remove INLINE pragma" I didn't say that! I said that a ''workaround'' is to remove the INLINE pragma :-). I agree that it's insane that adding INLINE makes things worse, and I propose to change GHC so that INLINE is honoured even for 0-ary values, and even if doing so would cause work duplication. I think that this alone will help you a lot, addressing 2,3,4. As to (5), yes, eta expansion is a particularly tricky transformation for GHC. In performance critical code, do it by hand. Re (6) you could put it another way: `SpecConstr` gives you absolutely stunning performance gains! Without you'd have had less good perf, but reliably so, and you would not be submitting this ticket :-). So there is a positive side here. The trouble is that it's difficult for `SpecConstr` to give ''reliably'' good perf, and that's why this horrible SPEC business is there. I'm sure it's possible to do better -- but it needs someone to really study the problem carefully. It's not just an easy fix. Re (7) SPEC is not well documented. The best documentation is probably `Note [Forcing specialisation]` in `SpecConstr` itself. It is a HORRIBLE hack, but we were never able to come up with anything more civilized. Again, it would reward some sustained attention. (I'm not addressing you here, rather any GHC hackers or research students looking for an interesting challenge.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 22:52:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 22:52:13 -0000 Subject: [GHC] #15484: MultiLayerModules and T13701 timeout on i386 Linux In-Reply-To: <046.f49e8907dc2fd082faa408fb71333802@haskell.org> References: <046.f49e8907dc2fd082faa408fb71333802@haskell.org> Message-ID: <061.423d14c5912ebed9421005152019aca2@haskell.org> #15484: MultiLayerModules and T13701 timeout on i386 Linux -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5103 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * differential: Phab:5103 => Phab:D5103 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 23:05:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 23:05:02 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation In-Reply-To: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> References: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> Message-ID: <061.e783c2c24cdf328cf6514511226e01c4@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by danilo2): @simonpj I know, I'm sorry I was not clear enough. That sentence was regarding the post of @sgraf (citing it: `So, the fix to apply in your situation seems to be to eta-expand test1 and omit the INLINE pragma.`) :) Yes, making GHC always listen to INLINE will help me regarding 2,3,4! 5. This is very interesting. Would you be so nice and tell me jsut a little more aobut it - where can I learn about it and why such design decisions were made? 6. :) 7. Very interesting. Thank you for sharing the knowledge! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Aug 29 23:38:04 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Aug 2018 23:38:04 -0000 Subject: [GHC] #15418: Performance drop 60 times on non-profiling binary In-Reply-To: <045.a055029aec148ca416c29df30694b018@haskell.org> References: <045.a055029aec148ca416c29df30694b018@haskell.org> Message-ID: <060.e7102dff0a41abb51afe3b94c303aba4@haskell.org> #15418: Performance drop 60 times on non-profiling binary -------------------------------------+------------------------------------- Reporter: hth313 | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14414, #9599 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hth313): Here are the numbers for different optimization level (no profiling enabled). == `-O0` {{{ 15,092,192,977,712 bytes allocated in the heap 108,592,404,512 bytes copied during GC 186,703,440 bytes maximum residency (1432 sample(s)) 709,040 bytes maximum slop 451 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 13967958 colls, 0 par 301.484s 311.887s 0.0000s 0.0044s Gen 1 1432 colls, 0 par 100.350s 100.731s 0.0703s 0.2282s INIT time 0.000s ( 0.002s elapsed) MUT time 2260.896s (2283.741s elapsed) GC time 401.834s (412.618s elapsed) EXIT time 0.000s ( 0.002s elapsed) Total time 2662.730s (2696.363s elapsed) %GC time 15.1% (15.3% elapsed) Alloc rate 6,675,314,555 bytes per MUT second Productivity 84.9% of total user, 84.7% of total elapsed real 44m56.321s user 44m22.736s sys 0m31.989s }}} == `-O1` {{{ 2,608,631,901,600 bytes allocated in the heap 6,337,722,720 bytes copied during GC 80,513,992 bytes maximum residency (61 sample(s)) 434,080 bytes maximum slop 235 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 1993189 colls, 0 par 43.959s 45.610s 0.0000s 0.0021s Gen 1 61 colls, 0 par 2.810s 2.938s 0.0482s 0.1433s INIT time 0.000s ( 0.002s elapsed) MUT time 835.425s (843.204s elapsed) GC time 46.769s ( 48.548s elapsed) EXIT time 0.000s ( 0.001s elapsed) Total time 882.194s (891.755s elapsed) %GC time 5.3% (5.4% elapsed) Alloc rate 3,122,521,195 bytes per MUT second Productivity 94.7% of total user, 94.6% of total elapsed real 14m51.787s user 14m42.200s sys 0m7.372s }}} == `-O2` {{{ 2,608,768,497,856 bytes allocated in the heap 6,313,467,672 bytes copied during GC 80,449,120 bytes maximum residency (62 sample(s)) 487,840 bytes maximum slop 235 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 1993104 colls, 0 par 47.643s 49.406s 0.0000s 0.0017s Gen 1 62 colls, 0 par 2.746s 2.880s 0.0465s 0.1499s INIT time 0.000s ( 0.002s elapsed) MUT time 801.664s (809.891s elapsed) GC time 50.389s ( 52.286s elapsed) EXIT time 0.000s ( 0.009s elapsed) Total time 852.053s (862.189s elapsed) %GC time 5.9% (6.1% elapsed) Alloc rate 3,254,192,077 bytes per MUT second Productivity 94.1% of total user, 93.9% of total elapsed real 14m22.223s user 14m12.060s sys 0m7.559s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 06:26:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 06:26:28 -0000 Subject: [GHC] #15418: Performance drop 60 times on non-profiling binary In-Reply-To: <045.a055029aec148ca416c29df30694b018@haskell.org> References: <045.a055029aec148ca416c29df30694b018@haskell.org> Message-ID: <060.2cc9b04bca877771865eca21a787ac54@haskell.org> #15418: Performance drop 60 times on non-profiling binary -------------------------------------+------------------------------------- Reporter: hth313 | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #14414, #9599 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): OK, so profiling build is faster than any of these .. Becuase we can't see the source you'll have to debug this yourself. Here's what I'd do next: - Add `-ddump-simpl -ddump-to-file -dsuppress-uniques` to `ghc-options` in your .cabal, and build without profiling. Copy generated .dump-simpl files to another directory, and build again this time with profiling (make sure to use same optimisation settings in both!), copy the .dump-simpl files again to another directory. Do directory diff (perhaps using kdiff3) and see the differences. You should see lots of minor changes (like the extra `scc` expression in the profiled version) and those should not matter, focus on larger changes. Looking at results in comment:13, you should see some code in non-profiled version that allocates more. One example where this happens is when GHC unboxes strict arguments/fields but not in the whole program so you still need the boxed version of the value. In that case at some point you re-box the value, causing more allocation. There are other reasons too, hard to list all.. - Looking at the numbers in comment:13, it looks like profiling version has less max residency. Perhaps in non-profiled version some closures are floated to the top-level, causing increased residency. Keep this in mind when comparing Core outputs. Failing all that, try to extract some minimal reproducer from your code base and share it :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 07:43:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 07:43:55 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation In-Reply-To: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> References: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> Message-ID: <061.434f6e901e77457bba56b0496903f387@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > This is very interesting. Would you be so nice and tell me jsut a little more aobut it - where can I learn about it and why such design decisions were made? I'm afraid I have never written a paper about eta-expansion, despite its importance to GHC. There are extensive Notes in * `CoreArity.hs` (which is all about arity and eta expansion) * `SimplUtils.hs` (around `tryEtaExpandRhs` and `tryEtaReduce`) I think that's the best I can do without a big investment -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 07:57:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 07:57:05 -0000 Subject: [GHC] #15578: Honour INLINE pragmas on 0-arity bindings Message-ID: <046.e84edd9f62d6ef84f8f7c7aedfa45ace@haskell.org> #15578: Honour INLINE pragmas on 0-arity bindings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently if we see {{{ x = factorial 200 {-# INLINE x #-} f y = ...x... }}} we won't inline `x`, lest we duplicate the work of `factorial 200`. But * Occasionally it's very important to inline `x`: see Trac #15519 for a real-world example. * Suppose `x` is used exactly once, not inside a lambda, thus {{{ x = blah {-# INLINE x #-} g = ...x... }}} Then, if there is ''no'' INLINE pragma, `x` will get inlined (by `preInlineUnconditionally`. But if there ''is'' an INLINE pragma, currently `x` is ''not'' inlined by `preInlineUnconditionally`: see `Note [Stable unfoldings and preInlineUnconditionally]` in `SimplUtils`. This is insane! * INLINE says "inline me at every saturated call", where "saturated" is determined by the number of arguments syntactically to the left of the "=" in the source bindings. In this case, there are no arguments to the left, so every occurrence is saturated. So it's inconsistent not to inline. Bottom line: if a 0-ary binding has an INLINE pragma, I think we should inline it at every use site * Regardless of the work duplication * Including inside lambdas Note, however, that there is a real risk that full laziness will float it right back out again. Consider again {{{ x = factorial 200 {-# INLINE x #-} f y = ...x... }}} After inlining we get {{{ f y = ...(factorial 200)... }}} but it's entirely possible that full laziness will do {{{ lvl23 = factorial 200 f y = l...lvl23... }}} That's a problem for another day. Presumably the reason the user wanted to inline it was to get some rule to fire, and this change gives at least some chance that will happen, and makes INLINE behave consistently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 07:58:58 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 07:58:58 -0000 Subject: [GHC] #15578: Honour INLINE pragmas on 0-arity bindings In-Reply-To: <046.e84edd9f62d6ef84f8f7c7aedfa45ace@haskell.org> References: <046.e84edd9f62d6ef84f8f7c7aedfa45ace@haskell.org> Message-ID: <061.c8f6ee259fc1c52329b81821c52c3f82@haskell.org> #15578: Honour INLINE pragmas on 0-arity bindings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Currently if we see > {{{ > x = factorial 200 > {-# INLINE x #-} > > f y = ...x... > }}} > we won't inline `x`, lest we duplicate the work of `factorial 200`. But > > * Occasionally it's very important to inline `x`: see Trac #15519 for a > real-world example. > * Suppose `x` is used exactly once, not inside a lambda, thus > {{{ > x = blah > {-# INLINE x #-} > g = ...x... > }}} > Then, if there is ''no'' INLINE pragma, `x` will get inlined (by > `preInlineUnconditionally`. But if there ''is'' an INLINE pragma, > currently `x` is ''not'' inlined by `preInlineUnconditionally`: see `Note > [Stable unfoldings and preInlineUnconditionally]` in `SimplUtils`. This > is insane! > > * INLINE says "inline me at every saturated call", where "saturated" is > determined by the number of arguments syntactically to the left of the > "=" in the source bindings. In this case, there are no arguments to the > left, so every occurrence is saturated. So it's inconsistent not to > inline. > > Bottom line: if a 0-ary binding has an INLINE pragma, I think we should > inline it at every use site > * Regardless of the work duplication > * Including inside lambdas > > Note, however, that there is a real risk that full laziness will float it > right back out again. Consider again > {{{ > x = factorial 200 > {-# INLINE x #-} > f y = ...x... > }}} > After inlining we get > {{{ > f y = ...(factorial 200)... > }}} > but it's entirely possible that full laziness will do > {{{ > lvl23 = factorial 200 > f y = l...lvl23... > }}} > That's a problem for another day. Presumably the reason the user wanted > to inline it was to get some rule to fire, and this change gives at least > some chance that will happen, and makes INLINE behave consistently. New description: Currently if we see {{{ x = factorial 200 {-# INLINE x #-} f y = ...x... }}} we won't inline `x`, lest we duplicate the work of `factorial 200`. But this caution has some bad consequences: * Suppose `x` is used exactly once, not inside a lambda, thus {{{ x = blah {-# INLINE x #-} g = ...x... }}} Then, if there is ''no'' INLINE pragma, `x` will get inlined (by `preInlineUnconditionally`. But if there ''is'' an INLINE pragma, currently `x` is ''not'' inlined by `preInlineUnconditionally`: see `Note [Stable unfoldings and preInlineUnconditionally]` in `SimplUtils`. This is insane! * INLINE says "inline me at every saturated call", where "saturated" is determined by the number of arguments syntactically to the left of the "=" in the source bindings. In this case, there are no arguments to the left, so every occurrence is saturated. So it's inconsistent not to inline. * Occasionally it's very important to inline `x`: see Trac #15519 for a real-world example. Ignoring the users explicit instruction to do so seems silly. Bottom line: if a 0-ary binding has an INLINE pragma, I think we should inline it at every use site * Regardless of the work duplication * Including inside lambdas Note, however, that there is a real risk that full laziness will float it right back out again. Consider again {{{ x = factorial 200 {-# INLINE x #-} f y = ...x... }}} After inlining we get {{{ f y = ...(factorial 200)... }}} but it's entirely possible that full laziness will do {{{ lvl23 = factorial 200 f y = l...lvl23... }}} That's a problem for another day. Presumably the reason the user wanted to inline it was to get some rule to fire, and this change gives at least some chance that will happen, and makes INLINE behave consistently. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 08:07:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 08:07:07 -0000 Subject: [GHC] #15578: Honour INLINE pragmas on 0-arity bindings In-Reply-To: <046.e84edd9f62d6ef84f8f7c7aedfa45ace@haskell.org> References: <046.e84edd9f62d6ef84f8f7c7aedfa45ace@haskell.org> Message-ID: <061.893663dcb2cc39fcae899e595e6f82f2@haskell.org> #15578: Honour INLINE pragmas on 0-arity bindings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Currently if we see > {{{ > x = factorial 200 > {-# INLINE x #-} > > f y = ...x... > }}} > we won't inline `x`, lest we duplicate the work of `factorial 200`. But > this caution has some bad consequences: > > * Suppose `x` is used exactly once, not inside a lambda, thus > {{{ > x = blah > {-# INLINE x #-} > g = ...x... > }}} > Then, if there is ''no'' INLINE pragma, `x` will get inlined (by > `preInlineUnconditionally`. But if there ''is'' an INLINE pragma, > currently `x` is ''not'' inlined by `preInlineUnconditionally`: see `Note > [Stable unfoldings and preInlineUnconditionally]` in `SimplUtils`. This > is insane! > > * INLINE says "inline me at every saturated call", where "saturated" is > determined by the number of arguments syntactically to the left of the > "=" in the source bindings. In this case, there are no arguments to the > left, so every occurrence is saturated. So it's inconsistent not to > inline. > > * Occasionally it's very important to inline `x`: see Trac #15519 for a > real-world example. Ignoring the users explicit instruction to do so > seems silly. > > Bottom line: if a 0-ary binding has an INLINE pragma, I think we should > inline it at every use site > * Regardless of the work duplication > * Including inside lambdas > > Note, however, that there is a real risk that full laziness will float it > right back out again. Consider again > {{{ > x = factorial 200 > {-# INLINE x #-} > f y = ...x... > }}} > After inlining we get > {{{ > f y = ...(factorial 200)... > }}} > but it's entirely possible that full laziness will do > {{{ > lvl23 = factorial 200 > f y = l...lvl23... > }}} > That's a problem for another day. Presumably the reason the user wanted > to inline it was to get some rule to fire, and this change gives at least > some chance that will happen, and makes INLINE behave consistently. New description: Currently if we see {{{ x = factorial 200 {-# INLINE x #-} f y = ...x... }}} we won't inline `x`, lest we duplicate the work of `factorial 200`. But this caution has some bad consequences: * Suppose `x` is used exactly once, not inside a lambda, thus {{{ x = blah {-# INLINE x #-} g = ...x... }}} Then, if there is ''no'' INLINE pragma, `x` will get inlined (by `preInlineUnconditionally`. But if there ''is'' an INLINE pragma, currently `x` is ''not'' inlined by `preInlineUnconditionally`: see `Note [Stable unfoldings and preInlineUnconditionally]` in `SimplUtils`. This is insane! * INLINE says "inline me at every saturated call", where "saturated" is determined by the number of arguments syntactically to the left of the "=" in the source bindings. In this case, there are no arguments to the left, so every occurrence is saturated. So it's inconsistent not to inline. * Occasionally it's very important to inline `x`: see Trac #15519 for a real-world example. Ignoring the users explicit instruction to do so seems silly. Bottom line: if a 0-ary binding has an INLINE pragma, I think we should inline it at every use site * Regardless of the work duplication * Including inside lambdas Note, however, that there is a real risk that full laziness will float it right back out again. Consider again {{{ x = factorial 200 {-# INLINE x #-} f y = ...x... }}} After inlining we get {{{ f y = ...(factorial 200)... }}} but it's entirely possible that full laziness will do {{{ lvl23 = factorial 200 f y = ...lvl23... }}} That's a problem for another day. Presumably the reason the user wanted to inline it was to get some rule to fire, and this change gives at least some chance that will happen, and makes INLINE behave consistently. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 08:18:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 08:18:41 -0000 Subject: [GHC] #15578: Honour INLINE pragmas on 0-arity bindings In-Reply-To: <046.e84edd9f62d6ef84f8f7c7aedfa45ace@haskell.org> References: <046.e84edd9f62d6ef84f8f7c7aedfa45ace@haskell.org> Message-ID: <061.79a242cdbb9441429f301f1495ca0409@haskell.org> #15578: Honour INLINE pragmas on 0-arity bindings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Looking at `CoreUnfold.mkInlineUnfolding`, a function with an INLINE pragma has its unfolding built with `mkInlineUnfoldingWithArity` (the arity being the syntactic arity in the source code). This function gives the unfolding an `UnfoldingGuidance` of {{{ guide = UnfWhen { ug_arity = arity , ug_unsat_ok = needSaturated , ug_boring_ok = boring_ok } boring_ok = inlineBoringOk expr' }}} And in fact, in `callSiteInline`, you can see that if `ug_arity = 0` then `x` will inline if `boring_ok` is True. What is `boring_ok`? It says whether to inline in an utterly boring context. In {{{ \ y x -> Just (f x y) }}} we don't inline `f` ''even if `f` has an INLINE pragma'' because the context of the call us utterly boring: nothing is known about `x` or `y` or the calling context. So there is really no point in inlining. I don't think this applies to 0-ary INLINE pragmas, as Trac #15519 shows. So I think it may be enough to say, in `mkInlineUnfoldingWithArity`, {{{ boring_ok | arity == 0 = True | otherwise = inlineBoringOk expr' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 08:24:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 08:24:00 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation In-Reply-To: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> References: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> Message-ID: <061.1bd8dc30a2c861c9be4e8cb0e695cdc8@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I have created #15578 for the proposed INLINE-of-0-ary things change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 08:29:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 08:29:05 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation In-Reply-To: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> References: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> Message-ID: <061.ba3a8c01339247a6844142213cc5433f@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Replying to [comment:15 danilo2]: > I strongly disagree with the sentence that the "fix would be to remove INLINE pragma" because this leaves us in a world where GHC performance is completely unknown and we have to randomly enable / disable things hoping that it will magically get better. I suspect @sgraf that you didn't mean "fix" but instead a "dirty workaround for now", but I preferred to emphasize my worries regarding this matter. Yes, exactly. I'm not happy with doing this (or rather having to anticipate doing this), either. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 08:29:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 08:29:16 -0000 Subject: [GHC] #15578: Honour INLINE pragmas on 0-arity bindings In-Reply-To: <046.e84edd9f62d6ef84f8f7c7aedfa45ace@haskell.org> References: <046.e84edd9f62d6ef84f8f7c7aedfa45ace@haskell.org> Message-ID: <061.e9273ef9792af9947010729e0f661ad6@haskell.org> #15578: Honour INLINE pragmas on 0-arity bindings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 08:32:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 08:32:48 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation In-Reply-To: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> References: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> Message-ID: <061.ed3bdb24f08efafb178dde6f93ba0ccb@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Yes, exactly. I'm not happy with doing this (or rather having to anticipate doing this), either. I've got lost. What exactly is "this"? Are you happy with what I propose in #15578? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 08:33:03 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 08:33:03 -0000 Subject: [GHC] #15578: Honour INLINE pragmas on 0-arity bindings In-Reply-To: <046.e84edd9f62d6ef84f8f7c7aedfa45ace@haskell.org> References: <046.e84edd9f62d6ef84f8f7c7aedfa45ace@haskell.org> Message-ID: <061.23a490e3f908b34051ad8353c937acd4@haskell.org> #15578: Honour INLINE pragmas on 0-arity bindings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15519 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * related: => #15519 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 08:40:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 08:40:49 -0000 Subject: [GHC] #15576: Hadrian puts its build tree in the wrong place In-Reply-To: <046.775a5c9a9255ff4303e7bb0241f9c28d@haskell.org> References: <046.775a5c9a9255ff4303e7bb0241f9c28d@haskell.org> Message-ID: <061.d784bdd6e960a169881faae43af847aa@haskell.org> #15576: Hadrian puts its build tree in the wrong place -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I double-checked. * I removed `/home/simonpj/ghc/_build` entirely * I removed `/playpen/ghc/_build` entirely * I did `cd /playpen/ghc` * And then `hadrian/build.sh -c -j20 --flavour=quick` Result: * a `_build` directory immediately appeared in `/home/simonpj/ghc`, populated with `generated`, `hadrian`, `stage0`, `stage1`. * The `hadrian/` directory contains `.shake.database`. * No `_build` directory appeared in `/playpen/ghc` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 08:48:33 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 08:48:33 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation In-Reply-To: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> References: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> Message-ID: <061.80d228f7a7362f20fcb605543c3aafef@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Replying to [comment:21 simonpj]: > > Yes, exactly. I'm not happy with doing this (or rather having to anticipate doing this), either. > > I've got lost. What exactly is "this"? Are you happy with what I propose in #15578? Sorry, I could have been clearer. TLDR; I'm quite happy, the comment was unrelated to anything you wrote. In comment:10, I wrote (with a little more context): > So, the fix to apply in your situation seems to be to eta-expand test1 and omit the INLINE pragma. That's what @danilo2's comment:15 alludes to when he writes > I strongly disagree with the sentence that the "fix would be to remove INLINE pragma" [...] I suspect @sgraf that you didn't mean "fix" but instead a "dirty workaround for now", but I preferred to emphasize my worries regarding this matter. So, by "this" in comment:20, I meant the workaround of manually eta- expanding and (more importantly) omitting the INLINE pragma. I'm quite happy about #15578 :) Not sure about consequences for library authors being used to the old behavior (if they were even aware of it), though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 08:51:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 08:51:08 -0000 Subject: [GHC] #15474: Error message mentions Any In-Reply-To: <047.c27fe3661bd6607bc87bf78cbba746cc@haskell.org> References: <047.c27fe3661bd6607bc87bf78cbba746cc@haskell.org> Message-ID: <062.2d941e245fd892dba0aee553fed132fd@haskell.org> #15474: Error message mentions Any -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14198 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, rejection is probably best for now -- we can always do something else later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 08:51:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 08:51:31 -0000 Subject: [GHC] #15474: Error message mentions Any In-Reply-To: <047.c27fe3661bd6607bc87bf78cbba746cc@haskell.org> References: <047.c27fe3661bd6607bc87bf78cbba746cc@haskell.org> Message-ID: <062.1a0465db26dc2433ad31fb750eb8b19e@haskell.org> #15474: Error message mentions Any -------------------------------------+------------------------------------- Reporter: monoidal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: #14198 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeInType * priority: low => normal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 08:51:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 08:51:54 -0000 Subject: [GHC] #14198: Inconsistent treatment of implicitly bound kind variables as free-floating In-Reply-To: <050.fc7092bf8815668ee061af436c2c49de@haskell.org> References: <050.fc7092bf8815668ee061af436c2c49de@haskell.org> Message-ID: <065.df4db824178539a6b6c65e38492a94f4@haskell.org> #14198: Inconsistent treatment of implicitly bound kind variables as free-floating -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14268 | Blocking: Related Tickets: #7873, #15474 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 08:56:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 08:56:15 -0000 Subject: [GHC] #15579: topNormaliseType is wrong Message-ID: <046.5b7180305b5f494ab9ca559038fad023@haskell.org> #15579: topNormaliseType is wrong -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I’m very puzzled about topNormaliseTYpe_maybe. Here it is: {{{ topNormaliseType_maybe env ty = topNormaliseTypeX stepper mkTransCo ty where stepper = unwrapNewTypeStepper `composeSteppers` tyFamStepper tyFamStepper rec_nts tc tys -- Try to step a type/data family = let (args_co, ntys) = normaliseTcArgs env Representational tc tys in -- NB: It's OK to use normaliseTcArgs here instead of -- normalise_tc_args (which takes the LiftingContext described -- in Note [Normalising types]) because the reduceTyFamApp below -- works only at top level. We'll never recur in this function -- after reducing the kind of a bound tyvar. case reduceTyFamApp_maybe env Representational tc ntys of Just (co, rhs) -> NS_Step rec_nts rhs (args_co `mkTransCo` co) _ -> NS_Done }}} I have two puzzlements 1. First, it seems utterly wrong to normalise the arguments using Representational. Consider {{{ F (N Int) where newtype N x = [x] }}} We don’t want to reduce `(N Int)` to `[Int]`, and then try reducing `(F [Int])`!! That is totally bogus. Surely we should use (the role-aware) `normalise_tc_args` here? 2. I have literally no clue what `Note [Normalising types]` is all about. Moreover there is no Lifting Context passed to `normalise_tc_args`, so I don’t know what this stuff about `LiftingContext` is about. Is this historical baggage? Richard and I discussed this. (1) is a bug; for (2) the comment is misleading and should be deleted. Richard will do these things -- and will add examples to the mysterious `Note [Normalising types]` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 08:56:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 08:56:44 -0000 Subject: [GHC] #15579: topNormaliseType is wrong In-Reply-To: <046.5b7180305b5f494ab9ca559038fad023@haskell.org> References: <046.5b7180305b5f494ab9ca559038fad023@haskell.org> Message-ID: <061.6b76dfea0b0e0bc513fae7d983788008@haskell.org> #15579: topNormaliseType is wrong -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: (none) => goldfire * priority: high => highest Comment: Making 'highest' because it's easy to do, and fixes an outright bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 09:09:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 09:09:27 -0000 Subject: [GHC] #15576: Hadrian puts its build tree in the wrong place In-Reply-To: <046.775a5c9a9255ff4303e7bb0241f9c28d@haskell.org> References: <046.775a5c9a9255ff4303e7bb0241f9c28d@haskell.org> Message-ID: <061.467339cf04d3a9bce7b4f7ac81c34ce9@haskell.org> #15576: Hadrian puts its build tree in the wrong place -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK I did what you ask in comment:3. The first `cabal new-build` completed fine; no `_build` directories anywhere. The second command `cabal new-run` command is still running. The start of its output is below. (NB: `~/5builds/HEAD-3` is the build tree that I was previously calling `/playpen/ghc`; but it really IS the build tree.) Results so far: `_build` is created in `/playpen/ghc` (or in fact `~/5builds/HEAD-3`); there is no `_build` in `/users/simonpj/ghc`. Note the messages from configure about `.git`... {{{ simonpj at cam-05-unx:~/5builds/HEAD-3/hadrian$ cabal new-run hadrian -- -c -j4 --flavour=quick --directory=".." Up to date | Running boot... | Run Configure ".": hadrian/cfg/system.config.in (and 4 more) => hadrian/cfg/system.config (and 4 more) configure: WARNING: cannot determine snapshot version: no .git directory and no VERSION file configure: WARNING: cannot determine snapshot revision: no .git directory and no 'GIT_COMMIT_ID' file Warning: libraries/text/text.cabal:4:1: The field "bug-reports" is specified more than once at positions 4:1, 42:1 | Copy file: settings => _build/stage1/lib/settings | Copy file: utils/hsc2hs/template-hsc.h => _build/stage1/lib/template- hsc.h | Copy file: driver/ghci-usage.txt => _build/stage1/lib/ghci-usage.txt | Copy file: llvm-passes => _build/stage1/lib/llvm-passes | Copy file: llvm-targets => _build/stage1/lib/llvm-targets Warning: utils/hpc/hpc-bin.cabal:11:2: Tabs used as indentation at 11:2 | Copy file: driver/ghc-usage.txt => _build/stage1/lib/ghc-usage.txt | Copy file: driver/ghc-usage.txt => _build/stage0/lib/ghc-usage.txt | Copy file: llvm-passes => _build/stage0/lib/llvm-passes | Copy file: llvm-targets => _build/stage0/lib/llvm-targets | Copy file: driver/ghci-usage.txt => _build/stage0/lib/ghci-usage.txt | Copy file: settings => _build/stage0/lib/settings | Successfully generated _build/stage1/bin/ghc-split. | Make '_build/stage1/bin/ghc-split' executable. ...more }}} It appears that my build-tree link script does not add a symlink to `.git`. I have no idea why; there is a symlink to other dot-files like `.gitignore`. Here's the script {{{ #!/usr/bin/perl if (-l "Makefile") { $source_tree = `ls -l Makefile`; $source_tree =~ s/^.*->\s*(.*)\/Makefile\s*$/$1/; print "Linking to source dir: $source_tree\n"; system("lndir $source_tree"); if ($? == 0) { system("kill-dangling-symlinks"); } else { print "errors from lndir; NOT removing dangling symlinks\n"; } } else { print "Linked Makefile not found."; exit(1); } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 10:16:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 10:16:32 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.d7dd5606b8ebaf71410627ef384f6eb4@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Test run results: - `wip/T14880-baseline`: pre-patch GHC HEAD. `("bytes allocated", "1144547520")` - `wip/T14880`: patch fully applied. `("bytes allocated", "1207856632")` - `wip/T14880-just-tvs`: only implement the "use VarSets, not FV" part of #14880 `("bytes allocated", "1176403280")` - `wip/T14880-nondet-fv`: baseline (same as `wip/T14880-baseline`), but using the `NDFV` replacement instead of `FV` (getting rid of the list that `FV` drags around to maintain insertion order). `("bytes allocated", "1144547040")` - `wip/T14880-nondet-no-in-scope`: same as `wip/T14880-nondet-fv`, but instead of adding to the `in_scope` set, remove items from the accumulator. `("bytes allocated", "4064821552")` - `wip/T14880-nondet-fv-2`: same as `wip/T14880-nondet-fv`, but with the `NDFV` type rewritten to update sets in place rather than building a computation accumulator-style. `("bytes allocated", "1222408136")` So it seems that somehow my results got mixed up somewhere, because there is a whopping 400% increase in memory use when removing the in-scope feature. There must be something else going on there though, because neither the fully applied patch nor the `just-tvs` version deviate this severely, despite also not using this in-scope pre-filtering. Disregarding the `nondet-no-in-scope` figure, we thus get: - applying full patch: 1145M -> 1208M - only introducing VarSet: 1145M -> 1176M (worse than baseline, better than full patch) - making FV nondeterministic: 1145M -> 1145M (no effect) - rewriting (ND)FV to not use accumulator style: 1145M -> 1222M (worse than full patch) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 10:26:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 10:26:20 -0000 Subject: [GHC] #15576: Hadrian puts its build tree in the wrong place In-Reply-To: <046.775a5c9a9255ff4303e7bb0241f9c28d@haskell.org> References: <046.775a5c9a9255ff4303e7bb0241f9c28d@haskell.org> Message-ID: <061.5b778e4c1c8a186658b6301e065ec7e2@haskell.org> #15576: Hadrian puts its build tree in the wrong place -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): Aha, it looks like it works. Presumably missing `.git` files are only important for making releases etc. where we want to record the build commit. Did the build eventually complete with GHC in `/playpen/ghc/_build/stage1/bin`? I'll investigate the issue with `build.sh` logic that negates your symlink-based setup. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 10:45:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 10:45:46 -0000 Subject: [GHC] #15576: Hadrian puts its build tree in the wrong place In-Reply-To: <046.775a5c9a9255ff4303e7bb0241f9c28d@haskell.org> References: <046.775a5c9a9255ff4303e7bb0241f9c28d@haskell.org> Message-ID: <061.6d43f00c8517900525610fad3a6bdff5@haskell.org> #15576: Hadrian puts its build tree in the wrong place -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Did the build eventually complete with GHC in /playpen/ghc/_build/stage1/bin? Yes, it did. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 10:46:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 10:46:19 -0000 Subject: [GHC] #15576: Hadrian puts its build tree in the wrong place In-Reply-To: <046.775a5c9a9255ff4303e7bb0241f9c28d@haskell.org> References: <046.775a5c9a9255ff4303e7bb0241f9c28d@haskell.org> Message-ID: <061.9bbf325487720355a3ada324f5df91ac@haskell.org> #15576: Hadrian puts its build tree in the wrong place -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): But how can I build stage2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 10:50:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 10:50:36 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.76311bcab6302f833f42daae555fb8fd@haskell.org> #13064: Incorrect redudant imports warning -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15393 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Dear Core Libraries Committee, and Edward. Could you give an opinion on the change I propose in this ticket? Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 10:57:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 10:57:39 -0000 Subject: [GHC] #15576: Hadrian puts its build tree in the wrong place In-Reply-To: <046.775a5c9a9255ff4303e7bb0241f9c28d@haskell.org> References: <046.775a5c9a9255ff4303e7bb0241f9c28d@haskell.org> Message-ID: <061.25d9c2a55b467207755bc31649ace593@haskell.org> #15576: Hadrian puts its build tree in the wrong place -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by snowleopard): It is Stage2 GHC. Here is how Hadrian build tree is organised: * `stage0` contains everything built by the Stage0 (bootstrapping) GHC, including the Stage1 GHC, which lives in `_build/stage0/bin/ghc.exe`. * `stage1` contains everything built by the Stage1 GHC, including the Stage2 GHC in `_build/stage1/bin/ghc.exe`. * `stage2` contains everything built by the Stage2 GHC, for example Haddock. Stage3 GHC will also be here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 11:01:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 11:01:20 -0000 Subject: [GHC] #12758: Bring sanity to our performance testsuite In-Reply-To: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> References: <046.023630bbf855f7a4ed786cb14a3639ea@haskell.org> Message-ID: <061.0df02c374d544b873ca176add40fc7fe@haskell.org> #12758: Bring sanity to our performance testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: high | Milestone: 8.8.1 Component: Test Suite | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3758, Wiki Page: | Phab:D5059 -------------------------------------+------------------------------------- Changes (by osa1): * differential: Phab:D3758 => Phab:D3758, Phab:D5059 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 11:05:45 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 11:05:45 -0000 Subject: [GHC] #15285: "strange closure type" in T7919 with the threaded2 way In-Reply-To: <048.67a85438785d72c47b85ee0ad004eab2@haskell.org> References: <048.67a85438785d72c47b85ee0ad004eab2@haskell.org> Message-ID: <063.aa6108495acf601548d56ff25c045398@haskell.org> #15285: "strange closure type" in T7919 with the threaded2 way -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: T7919 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5115 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D5115 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 11:11:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 11:11:53 -0000 Subject: [GHC] #15285: "strange closure type" in T7919 with the threaded2 way In-Reply-To: <048.67a85438785d72c47b85ee0ad004eab2@haskell.org> References: <048.67a85438785d72c47b85ee0ad004eab2@haskell.org> Message-ID: <063.b56a0a0e5cf4a2b28ce414d17869cb51@haskell.org> #15285: "strange closure type" in T7919 with the threaded2 way -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: T7919 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5115 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I found a data race in the garbage collector and submitted a patch for this. I can't confirm that it fixes the original report (as I couldn't reproduce it) but it fixed the assertion failures I reported in comment:1. Alp, were you able to reproduce the original error locally? If yes could you try again with my patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 11:30:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 11:30:44 -0000 Subject: [GHC] #15529: runtime bug when profiling retainers In-Reply-To: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> References: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> Message-ID: <061.d4a49fdba06c12c640b23017d84c7db2@haskell.org> #15529: runtime bug when profiling retainers -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5075 Wiki Page: | -------------------------------------+------------------------------------- Comment (by flip101): The merge does this mean this bug is fixed and closed? I want to remove the repository with my code, i guess it's ok because monoidal was able to find a reduced test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 11:37:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 11:37:48 -0000 Subject: [GHC] #15529: runtime bug when profiling retainers In-Reply-To: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> References: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> Message-ID: <061.ff9797a4e723c7c69e6a37d8afd327dd@haskell.org> #15529: runtime bug when profiling retainers -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5075 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Yes, this was fixed in master and the patch will be merged to 8.6.1 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 11:42:45 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 11:42:45 -0000 Subject: [GHC] #15529: runtime bug when profiling retainers In-Reply-To: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> References: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> Message-ID: <061.ddecb34f6d5ec01272e22e1d13e989ad@haskell.org> #15529: runtime bug when profiling retainers -------------------------------------+------------------------------------- Reporter: flip101 | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5075 Wiki Page: | -------------------------------------+------------------------------------- Comment (by flip101): Thank you for the fix, i will test it soon :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 13:32:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 13:32:17 -0000 Subject: [GHC] #14672: Make likelyhood of branches/conditions available throughout the compiler. In-Reply-To: <047.de2c13e36902d9be8400d9448aa09671@haskell.org> References: <047.de2c13e36902d9be8400d9448aa09671@haskell.org> Message-ID: <062.8ccc57efc691541d9d538fd87b209625@haskell.org> #14672: Make likelyhood of branches/conditions available throughout the compiler. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #849 #15124 | Differential Rev(s): Phab:D4316 #8326 | Phab:D4324 Phab:D4327 Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * related: #849 #15124 => #849 #15124 #8326 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 13:32:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 13:32:28 -0000 Subject: [GHC] #15577: TypeApplications-related infinite loop (GHC 8.6+ only) In-Reply-To: <050.727e460d0083534afd4869db4aa81c30@haskell.org> References: <050.727e460d0083534afd4869db4aa81c30@haskell.org> Message-ID: <065.a439c93d422aebb2da94a38ee488dda8@haskell.org> #15577: TypeApplications-related infinite loop (GHC 8.6+ only) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | TypeApplications, TypeInType 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 RyanGlScott): * cc: simonpj (added) Comment: This regression was introduced in commit a32c8f7514c8192fa064537fb93d5a5c224991a0 (`Use dischargeFunEq consistently`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 13:33:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 13:33:39 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.a14c1e204650b5781f3cbf01cf68cd66@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: 8317 Related Tickets: #1498 | Differential Rev(s): Phab:D343 Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): Replying to [comment:42 michalt]: > What is the status of this ticket? > > I've tried the patch suggested in comment:34, but my results of nofib were quite different, with some clear regressions (below I've removed anything where the difference was <2%) > > NOTE: I don't have much experience with investigations like this, so the whole analysis might be quite wrong. ;) Please let me know if something seems off. I'll attach the dump of STG/cmm/asm from both versions of `k-nucleotide` (with and without the patch). When I experimented with the order in which we generate uniques I also got a regression of ~18% for one of the shootout benchmarks, I think it was k-nucleotide but could have been another one. So while I don't doubt that there is a regression for k-nucleotide with this patch it doesn't have to be because the code we generate is worse for the general case. One really has to look at the Asm/Cmm for that. > it is not clear to me what to do if we have combination of the above (more than one branch that allocates heap and at least one branch that does not). In the long run we should do some static analysis to help us determine the hot code path. Eg distinguish between: * Alternatives leading to recursion * Alternatives being called once. * Bottoming alternatives. There are some ideas and work on that in #14672. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 13:46:58 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 13:46:58 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.93a567d306cbcbe1b40c9e69ded79e54@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I have two takeaways from this: - An accumulator style is the Right Way to go when building up a set. This idea should probably be abstracted over right in the `VarSet` interface. But do we get these gains without eta-expanding everything? (See Note [FV eta expansion] in FV.) - The extra work to track order has no effect. I find this surprising, but not overly so, because we can avoid the extra work via laziness. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 13:50:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 13:50:35 -0000 Subject: [GHC] #15124: Improve block layout for the NCG In-Reply-To: <047.b2a760b384d29a2bc137285a934c2d79@haskell.org> References: <047.b2a760b384d29a2bc137285a934c2d79@haskell.org> Message-ID: <062.89b2e8851fbc6ba6c047e0262bb19f00@haskell.org> #15124: Improve block layout for the NCG -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (NCG) | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8082 #14672 | Differential Rev(s): Phab:D4726 Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): Snapshot of the performance gains by the linked patch. (Speedup - so **higher is better**). Last I checked nofib performance was neither here no there in terms of runtime. (Slightly slower on sandy bridge, slightly faster on haswell). Compile time with the patch went down on both though. || Library ||Sandy Bridge (Linux) || Haswell (Linux) || Skylake (Win) || || aeson || +2.6%/+2.8% || +2.3%/-0% || +1.2%/+1.0% || containers || +1.4%/+1.2% || +1.1%/+1.7% || +1.7%/+1.0% || megaparsec || +3.2%/+3.6% || +13.6%/+13.7% 1) || +8.0%/+6.6% || perf-xml || +0.2%/+0.0% || || +1.1%/+0.8% || text || +3.0%/+3.0% || NA || NA || Vector || +2.5%/+3.6% || +2.5%/+2.9% || +1.3%/3.8% 1 ) Inflated by background noise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 14:21:25 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 14:21:25 -0000 Subject: [GHC] #15580: Specialize min/max functions for GHC provided instances. Message-ID: <047.4f3756d2728f5fb98b5d1152e78741ea@haskell.org> #15580: Specialize min/max functions for GHC provided instances. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: CodeGen | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In particular for Int/Word/Float/Double we should aim to provide branchless code where reasonable. Especially when using SSE we should just use `minss` instead of {{{ ucomisd %xmm1,%xmm0 jp .Lc5vv jbe .Lc5vw }}} which is worse in all kinds of ways. If someone feels like tackling this I'm happy to help with code review, answering questions, etc. I won't get around to doing it myself any time soon. As a starting point the instance declarations are in ghc- prim/GHC/Classes.hs. I would look into solving this via adding a new MachOP/PrimOP but maybe there are even better ways. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 14:47:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 14:47:27 -0000 Subject: [GHC] #15581: Unable to commit [negative number] bytes of memory Message-ID: <042.24290784ed1d220ed7617e764f1f77a0@haskell.org> #15581: Unable to commit [negative number] bytes of memory -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In issues like https://github.com/haskell/text/issues/221 we observe: {{{ ": internal error: Unable to commit -1604321280 bytes of memory (GHC version 8.2.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Unable to commit a **negative** amount of bytes? That looks like integer overflow somewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 14:58:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 14:58:18 -0000 Subject: [GHC] #13896: Use response file to invoke hsc2hs In-Reply-To: <046.8d005e1593e32147d596c190fbabb716@haskell.org> References: <046.8d005e1593e32147d596c190fbabb716@haskell.org> Message-ID: <061.1094435a67510d6cfc2b3abdb26c5503@haskell.org> #13896: Use response file to invoke hsc2hs ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: hsc2hs | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4612 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by ckoparkar): The Cabal PR: https://github.com/haskell/cabal/pull/5553 which @hvr has approved. It should land in Cabal-2.4. bgamari: Once that is merged, we can mark this ticket as "fixed" right ? Are there any other "hsc2hs" invocation sites that we should handle ? I couldn't grep for any obvious ones. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 15:12:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 15:12:40 -0000 Subject: [GHC] #15333: Weird cachegrind results for binary-trees In-Reply-To: <044.7a98f83472ccde2b3f7411c5c885bd25@haskell.org> References: <044.7a98f83472ccde2b3f7411c5c885bd25@haskell.org> Message-ID: <059.0aac54c4ac8ec3ea593f108daa82c9b9@haskell.org> #15333: Weird cachegrind results for binary-trees -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research Component: NoFib benchmark | needed suite | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by sgraf: Old description: > I'm currently investigating an alleged regression in my branch of the > late lambda lift and hit a confusing data point. Note that I'm very much > relying on cachegrinds counted instructions/memory accesses for my > findings. > > Check out the most recent version of `nofib` and run the following > script: > > {{{#!sh > #! /bin/sh > sed -i 's/import Debug.Trace//g' Main.hs # Make the following line > idempotent > echo "import Debug.Trace" | cat - Main.hs > Main.tmp && mv Main.tmp > Main.hs # add the import for trace > > # bt1: Vanilly > sed -i 's/trace "" \$ bit/bit/g' Main.hs # strip `trace $ ` prefixes in > the call to `bit` > ghc -O2 -XBangPatterns Main.hs -o bt1 > > # bt2: Additional trace call > sed -i 's/bit/trace "" $ bit/g' Main.hs # prepend `trace $ ` to the call > to `bit` > ghc -O2 -XBangPatterns Main.hs -o bt2 > > valgrind --tool=cachegrind ./bt1 12 2>&1 > /dev/null # without trace > valgrind --tool=cachegrind ./bt2 12 2>&1 > /dev/null # with trace > }}} > > This will compile two versions of `binary-trees`, the original, unchanged > version and one with an extra `trace "" $` call before the only call to > the `bit` function. One would expect the version with the `trace` call > (`bt2`) to allocate more than the version without (`bt1`). Indeed, the > output of `+RTS -s` suggests that: > > {{{ > $ ./bt1 12 +RTS -s > ... > 43,107,560 bytes allocated in the heap > ... > $ ./bt2 12 +RTS -s > ... > 43,116,888 bytes allocated in the heap > ... > }}} > > That's fine. A few benchmark runs by hand also suggested the tracing > version is a little slower (probably due to IO). > > Compare that to the output of the above cachegrind calls: > > {{{ > $ valgrind --tool=cachegrind ./bt1 12 > /dev/null > ... > I refs: 118,697,583 > ... > D refs: 43,475,212 > ... > $ valgrind --tool=cachegrind ./bt2 12 > /dev/null > ... > I refs: 116,340,710 > ... > D refs: 42,523,369 > ... > }}} > > It's the other way round here! How's that possible? > > Even if this isn't strictly a bug in GHC or NoFib, it's relevant > nonetheless, as our benchmark infrastructure currently relies on > instruction counts. I couldn't reproduce this by writing my own no-op > `trace _ a = a; {-# NOINLINE trace #-}`, btw. > > I checked this on GHC 8.2.2, 8.4.3 and a semi-recent HEAD commit > (bb539cfe335eeec7989332b859b1f3162c5e105a). New description: I'm currently investigating an alleged regression in my branch of the late lambda lift and hit a confusing data point. Note that I'm very much relying on cachegrinds counted instructions/memory accesses for my findings. Check out the most recent version of `nofib`, enter `shootout/binary- trees` and run the following script: {{{#!sh #! /bin/sh sed -i 's/import Debug.Trace//g' Main.hs # Make the following line idempotent echo "import Debug.Trace" | cat - Main.hs > Main.tmp && mv Main.tmp Main.hs # add the import for trace # bt1: Vanilly sed -i 's/trace "" \$ bit/bit/g' Main.hs # strip `trace $ ` prefixes in the call to `bit` ghc -O2 -XBangPatterns Main.hs -o bt1 # bt2: Additional trace call sed -i 's/bit/trace "" $ bit/g' Main.hs # prepend `trace $ ` to the call to `bit` ghc -O2 -XBangPatterns Main.hs -o bt2 valgrind --tool=cachegrind ./bt1 12 2>&1 > /dev/null # without trace valgrind --tool=cachegrind ./bt2 12 2>&1 > /dev/null # with trace }}} This will compile two versions of `binary-trees`, the original, unchanged version and one with an extra `trace "" $` call before the only call to the `bit` function. One would expect the version with the `trace` call (`bt2`) to allocate more than the version without (`bt1`). Indeed, the output of `+RTS -s` suggests that: {{{ $ ./bt1 12 +RTS -s ... 43,107,560 bytes allocated in the heap ... $ ./bt2 12 +RTS -s ... 43,116,888 bytes allocated in the heap ... }}} That's fine. A few benchmark runs by hand also suggested the tracing version is a little slower (probably due to IO). Compare that to the output of the above cachegrind calls: {{{ $ valgrind --tool=cachegrind ./bt1 12 > /dev/null ... I refs: 118,697,583 ... D refs: 43,475,212 ... $ valgrind --tool=cachegrind ./bt2 12 > /dev/null ... I refs: 116,340,710 ... D refs: 42,523,369 ... }}} It's the other way round here! How's that possible? Even if this isn't strictly a bug in GHC or NoFib, it's relevant nonetheless, as our benchmark infrastructure currently relies on instruction counts. I couldn't reproduce this by writing my own no-op `trace _ a = a; {-# NOINLINE trace #-}`, btw. I checked this on GHC 8.2.2, 8.4.3 and a semi-recent HEAD commit (bb539cfe335eeec7989332b859b1f3162c5e105a). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 15:21:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 15:21:29 -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.1f9937b4a748a76c8ad907a0e5b34c79@haskell.org> #15072: Teach the testsuite driver about response files -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.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: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ckoparkar): bgamari: I was considering picking this up. Before we "teach the testsuite driver to invoke GHC with a response file", we'll have to update the GHC executable itself to understand response file args right ? `ghc @ARGS_FILE` doesn't work, and I couldn't find any flag that allows us to specify this (I'm still looking). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 15:45:45 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 15:45:45 -0000 Subject: [GHC] #15333: Weird cachegrind results for binary-trees In-Reply-To: <044.7a98f83472ccde2b3f7411c5c885bd25@haskell.org> References: <044.7a98f83472ccde2b3f7411c5c885bd25@haskell.org> Message-ID: <059.59dfe1d462cc4599e2e2514cb52aff30@haskell.org> #15333: Weird cachegrind results for binary-trees -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research Component: NoFib benchmark | needed suite | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): I think I figured this out. This is due to nursery size, specifically the points in time after which the GC kicks in. For benchmarks with a working set of varying size, GC Gen 0 collection performance heavily depends on the size of the working set within the nursery ''at the time collection is triggered''. There obviously is no way to predict this reliably. In this case, the default nursery size seemed to be particularly unfortunate, as `+RTS -S` reveals: {{{ Alloc Copied Live GC GC TOT TOT Page Flts bytes bytes bytes user elap user elap 1097344 490864 548288 0.001 0.001 0.002 0.002 0 0 (Gen: 0) 1044752 645640 706848 0.001 0.001 0.003 0.003 0 0 (Gen: 0) 1046272 592608 650032 0.001 0.001 0.004 0.004 0 0 (Gen: 1) 1079040 17808 699952 0.000 0.000 0.005 0.005 0 0 (Gen: 0) 1046272 17808 717104 0.000 0.000 0.006 0.006 0 0 (Gen: 0) 1046272 17808 734256 0.000 0.000 0.006 0.006 0 0 (Gen: 0) 1079040 17808 784176 0.000 0.000 0.007 0.007 0 0 (Gen: 0) 1046272 17808 801328 0.000 0.000 0.007 0.007 0 0 (Gen: 0) 1078160 111840 912488 0.000 0.000 0.007 0.007 0 0 (Gen: 0) 1036312 96056 911464 0.000 0.000 0.008 0.008 0 0 (Gen: 0) 1036288 6608 915560 0.000 0.000 0.008 0.008 0 0 (Gen: 0) 1036288 6608 919656 0.000 0.000 0.009 0.009 0 0 (Gen: 0) 1036288 6608 923752 0.000 0.000 0.009 0.009 0 0 (Gen: 0) 1036288 6608 927848 0.000 0.000 0.009 0.009 0 0 (Gen: 0) 1036288 6608 931944 0.000 0.000 0.010 0.010 0 0 (Gen: 0) 1036288 6608 936040 0.000 0.000 0.010 0.010 0 0 (Gen: 0) 1036288 6608 940136 0.000 0.000 0.011 0.011 0 0 (Gen: 0) 1044920 29264 966864 0.000 0.000 0.011 0.011 0 0 (Gen: 0) 1045504 25496 963536 0.000 0.000 0.011 0.011 0 0 (Gen: 0) 1045504 6160 964560 0.000 0.000 0.012 0.012 0 0 (Gen: 0) 1045504 6160 965584 0.000 0.000 0.012 0.012 0 0 (Gen: 0) 1045504 6160 966608 0.000 0.000 0.013 0.013 0 0 (Gen: 0) 1045504 6160 967632 0.000 0.000 0.013 0.013 0 0 (Gen: 0) 1045504 6160 968656 0.000 0.000 0.014 0.014 0 0 (Gen: 0) 1045504 6160 969680 0.000 0.000 0.014 0.014 0 0 (Gen: 0) 1047464 59208 1023728 0.000 0.000 0.015 0.015 0 0 (Gen: 0) 1047808 57968 1022896 0.000 0.000 0.015 0.015 0 0 (Gen: 0) 1047808 52912 1023120 0.000 0.000 0.016 0.016 0 0 (Gen: 0) 1047808 52944 1023376 0.000 0.000 0.016 0.016 0 0 (Gen: 0) 1047808 52944 1023632 0.000 0.000 0.017 0.017 0 0 (Gen: 0) 1047808 52944 1023888 0.000 0.000 0.017 0.017 0 0 (Gen: 0) 1047808 52944 1024144 0.000 0.000 0.018 0.018 0 0 (Gen: 0) 1047808 52944 1024400 0.000 0.000 0.018 0.018 0 0 (Gen: 0) 1048296 176376 1148064 0.000 0.000 0.018 0.018 0 0 (Gen: 0) 1048384 175792 1147856 0.000 0.000 0.019 0.019 0 0 (Gen: 0) 1048384 174288 1147856 0.000 0.000 0.019 0.019 0 0 (Gen: 0) 1048384 174288 1147856 0.000 0.000 0.020 0.020 0 0 (Gen: 0) 1048384 174288 1147856 0.000 0.000 0.020 0.020 0 0 (Gen: 0) 1048384 174288 1147856 0.000 0.000 0.021 0.021 0 0 (Gen: 0) 1048384 174288 1147856 0.000 0.000 0.021 0.021 0 0 (Gen: 0) 1048384 174288 1147856 0.000 0.000 0.022 0.022 0 0 (Gen: 0) 116160 3488 44576 0.000 0.000 0.022 0.022 0 0 (Gen: 1) 0 0.000 0.000 }}} This is the log for `bt1` (e.g. without the call to `trace`). Note the higher numbers in the `Copied bytes` column compared to `bt2` (with the redundant `trace` call), in particular the whole second half: {{{ Alloc Copied Live GC GC TOT TOT Page Flts bytes bytes bytes user elap user elap 1097448 488888 546312 0.001 0.001 0.002 0.002 0 0 (Gen: 0) 1044664 645424 706840 0.001 0.001 0.004 0.004 0 0 (Gen: 0) 1046272 591480 648904 0.001 0.001 0.005 0.005 0 0 (Gen: 1) 1079040 17488 698824 0.000 0.000 0.006 0.006 0 0 (Gen: 0) 1046272 17488 715976 0.000 0.000 0.007 0.007 0 0 (Gen: 0) 1046272 17488 733128 0.000 0.000 0.008 0.008 0 0 (Gen: 0) 1079040 17488 783048 0.000 0.000 0.008 0.008 0 0 (Gen: 0) 1046272 17488 800200 0.000 0.000 0.009 0.009 0 0 (Gen: 0) 1078376 108336 908176 0.000 0.000 0.010 0.010 0 0 (Gen: 0) 1036312 96600 911232 0.000 0.000 0.011 0.011 0 0 (Gen: 0) 1036288 7088 915248 0.000 0.000 0.012 0.012 0 0 (Gen: 0) 1036288 7120 919344 0.000 0.000 0.012 0.012 0 0 (Gen: 0) 1036288 7120 923440 0.000 0.000 0.013 0.013 0 0 (Gen: 0) 1036288 7120 927536 0.000 0.000 0.014 0.014 0 0 (Gen: 0) 1036288 7120 931632 0.000 0.000 0.014 0.014 0 0 (Gen: 0) 1036288 7120 935728 0.000 0.000 0.015 0.015 0 0 (Gen: 0) 1036288 7120 939824 0.000 0.000 0.015 0.015 0 0 (Gen: 0) 1045264 24608 961384 0.000 0.000 0.015 0.015 0 0 (Gen: 0) 1045504 20824 958056 0.000 0.000 0.016 0.016 0 0 (Gen: 0) 1045504 1488 959080 0.000 0.000 0.016 0.016 0 0 (Gen: 0) 1045504 1488 960104 0.000 0.000 0.016 0.016 0 0 (Gen: 0) 1045504 1488 961128 0.000 0.000 0.017 0.017 0 0 (Gen: 0) 1045504 1488 962152 0.000 0.000 0.017 0.017 0 0 (Gen: 0) 1045504 1488 963176 0.000 0.000 0.017 0.017 0 0 (Gen: 0) 1045504 1488 964200 0.000 0.000 0.018 0.018 0 0 (Gen: 0) 1047600 53192 1016904 0.000 0.000 0.018 0.018 0 0 (Gen: 0) 1047808 51952 1016072 0.000 0.000 0.019 0.019 0 0 (Gen: 0) 1047808 46896 1016296 0.000 0.000 0.019 0.019 0 0 (Gen: 0) 1047808 46928 1016552 0.000 0.000 0.019 0.019 0 0 (Gen: 0) 1047808 46928 1016808 0.000 0.000 0.020 0.020 0 0 (Gen: 0) 1047808 46928 1017064 0.000 0.000 0.020 0.020 0 0 (Gen: 0) 1047808 46928 1017320 0.000 0.000 0.020 0.020 0 0 (Gen: 0) 1047808 46928 1017576 0.000 0.000 0.021 0.021 0 0 (Gen: 0) 1048176 168760 1139640 0.000 0.000 0.021 0.021 0 0 (Gen: 0) 1048384 168176 1139432 0.000 0.000 0.022 0.022 0 0 (Gen: 0) 1048384 166672 1139432 0.000 0.000 0.022 0.022 0 0 (Gen: 0) 1048384 166672 1139432 0.000 0.000 0.023 0.023 0 0 (Gen: 0) 1048384 166672 1139432 0.000 0.000 0.023 0.023 0 0 (Gen: 0) 1048384 166672 1139432 0.000 0.000 0.023 0.023 0 0 (Gen: 0) 1048384 166672 1139432 0.000 0.000 0.024 0.024 0 0 (Gen: 0) 1048384 166672 1139432 0.000 0.000 0.024 0.024 0 0 (Gen: 0) 123776 2504 43592 0.000 0.000 0.024 0.025 0 0 (Gen: 1) 0 0.000 0.000 }}} I see no easy way around this other than 'deactivating' the GC by choosing a big enough nursery, such as `-A11M` in this case. Taking the GC out of the equation in this way may be somewhat misrepresentative, but at least we get cachegrind numbers that can be trusted. There are other cases I hit this, like `bspt`. I improved allocation a bit, triggering GC at later points when the working set was bigger. Result was an alleged regression of 6% in counted instructions, even though the relevant optimized snippet in isolation got faster. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 16:02:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 16:02:11 -0000 Subject: [GHC] #15519: Minor code refactoring leads to drastic performance degradation In-Reply-To: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> References: <046.ad6b341bd87e1814116aa36115f7bc12@haskell.org> Message-ID: <061.947c3fe375606ad3f092987f9c9ceb95@haskell.org> #15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: SpecConstr Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by danilo2): @sgraf I would be truly surprised if 1% of library authors who ever used the INLINE pragma are aware how in reality it gets resolved. Moreover, you cannot rely on it because you don't have any clear guidance how to write high performance code with the current behavior, so I'm pretty sure there is nobody consciously relying on this behavior. I'd love to see this fixed according to SPJ proposal! :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 16:15:38 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 16:15:38 -0000 Subject: [GHC] #15285: "strange closure type" in T7919 with the threaded2 way In-Reply-To: <048.67a85438785d72c47b85ee0ad004eab2@haskell.org> References: <048.67a85438785d72c47b85ee0ad004eab2@haskell.org> Message-ID: <063.458a4ecd0ac7701be0e7a82cb1dee611@haskell.org> #15285: "strange closure type" in T7919 with the threaded2 way -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: T7919 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5115 Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): I think this was an error that I first saw on Circle CI, the slow validate job, and that I then managed to reproduce locally yes. I will trigger another slow validate job against your diff, will post the link to the circle ci build once it has started. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 16:21:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 16:21:16 -0000 Subject: [GHC] #15333: Nursery size adulterates cachegrind metrics in nofib (was: Weird cachegrind results for binary-trees) In-Reply-To: <044.7a98f83472ccde2b3f7411c5c885bd25@haskell.org> References: <044.7a98f83472ccde2b3f7411c5c885bd25@haskell.org> Message-ID: <059.4489b38fbf7c9e42c98ba3909c7292dc@haskell.org> #15333: Nursery size adulterates cachegrind metrics in nofib -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Research Component: NoFib benchmark | needed suite | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 16:33:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 16:33:17 -0000 Subject: [GHC] #15285: "strange closure type" in T7919 with the threaded2 way In-Reply-To: <048.67a85438785d72c47b85ee0ad004eab2@haskell.org> References: <048.67a85438785d72c47b85ee0ad004eab2@haskell.org> Message-ID: <063.cdfb73ad6f21d1c3b00e548156ffc49c@haskell.org> #15285: "strange closure type" in T7919 with the threaded2 way -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: T7919 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5115 Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): There you go: https://circleci.com/gh/ghc/ghc-diffs/283 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 16:44:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 16:44:27 -0000 Subject: [GHC] #14672: Make likelyhood of branches/conditions available throughout the compiler. In-Reply-To: <047.de2c13e36902d9be8400d9448aa09671@haskell.org> References: <047.de2c13e36902d9be8400d9448aa09671@haskell.org> Message-ID: <062.607c7442db511781182b5aea322e3637@haskell.org> #14672: Make likelyhood of branches/conditions available throughout the compiler. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #849 #15124 | Differential Rev(s): Phab:D4316 #8326 | Phab:D4324 Phab:D4327 Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): Sidenote: During work on #15124 I've seen that changes with nice improvements in library benchmarks showed almost no effect. So I want to reevaluate this patch based not only on nofib where it made not much difference in the last round of benchmarks I ran. But also look at other library benchmarks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 17:03:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 17:03:10 -0000 Subject: [GHC] #15582: Phabricator shows "drafts" by default Message-ID: <047.61fc7947b23ebca53c25e719451940d3@haskell.org> #15582: Phabricator shows "drafts" by default -------------------------------------+------------------------------------- Reporter: monoidal | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Continuous | Version: 8.4.3 Integration | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- By default, going to https://phabricator.haskell.org/differential/ shows "Drafts". This category isn't very useful. Is it possible to create a query for "All open" (Statuses: "Any Open Status") and make it the default? I've done this already on my account, but I think it makes sense to do this globally. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 17:05:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 17:05:46 -0000 Subject: [GHC] #15583: Treating Constraint as Type when using (type C = Constraint) Message-ID: <051.c99c4ad81b9077682747190361356939@haskell.org> #15583: Treating Constraint as Type when using (type C = Constraint) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15412 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This may be similar/same as #15412? I can't get to the latest GHC right now. Again the "culprit" is using `type C = Constraint`. The code example should not compile, but the error it gives is unexpected. If we define the associated type family `Ob_ (cat :: Cat ob) :: ob -> C` using `C` {{{#!hs {-# Language KindSignatures, PolyKinds, DataKinds, TypeInType, TypeFamilies, FlexibleInstances #-} import Data.Kind type T = Type type C = Constraint type Cat ob = ob -> ob -> T class Category_ (cat :: Cat ob) where type Ob_ (cat :: Cat ob) :: ob -> C id_ :: Ob_ cat a => cat a a class NoCls (a::k) instance NoCls (a::k) instance Category_ (->) where type Ob_ (->) = NoCls -- id_ :: NoCls a => (a -> a) -XInstanceSigs id_ = () }}} the definition of `id_` fails (as we expect), but the expected type (`Ob_ (->) a -> a -> a`) is wrong: {{{#!hs $ ghci -ignore-dot-ghci 348.hs GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 348.hs, interpreted ) 348.hs:22:9: error: • Couldn't match expected type ‘Ob_ (->) a -> a -> a’ with actual type ‘()’ • In the expression: () In an equation for ‘id_’: id_ = () In the instance declaration for ‘Category_ (->)’ • Relevant bindings include id_ :: Ob_ (->) a -> a -> a (bound at 348.hs:22:3) | 22 | id_ = () | ^^ Failed, no modules loaded. Prelude> }}} If we simply replace `Ob_` with `type Ob_ (cat :: Cat ob) :: ob -> Constraint`, the expected type (`a -> a`) matches my intuition: {{{ 348.hs:22:9: error: • Couldn't match expected type ‘a -> a’ with actual type ‘()’ • In the expression: () In an equation for ‘id_’: id_ = () In the instance declaration for ‘Category_ (->)’ • Relevant bindings include id_ :: a -> a (bound at 348.hs:22:3) | 22 | id_ = () | ^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 17:06:30 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 17:06:30 -0000 Subject: [GHC] #15583: Treating Constraint as Type when using (type C = Constraint) In-Reply-To: <051.c99c4ad81b9077682747190361356939@haskell.org> References: <051.c99c4ad81b9077682747190361356939@haskell.org> Message-ID: <066.3620b09a00f0f94e079c9c6bc2879861@haskell.org> #15583: Treating Constraint as Type when using (type C = Constraint) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15412 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > This may be similar/same as #15412? I can't get to the latest GHC right > now. Again the "culprit" is using `type C = Constraint`. > > The code example should not compile, but the error it gives is > unexpected. If we define the associated type family `Ob_ (cat :: Cat ob) > :: ob -> C` using `C` > > {{{#!hs > {-# Language KindSignatures, PolyKinds, DataKinds, TypeInType, > TypeFamilies, FlexibleInstances #-} > > import Data.Kind > > type T = Type > type C = Constraint > > type Cat ob = ob -> ob -> T > > class Category_ (cat :: Cat ob) where > type Ob_ (cat :: Cat ob) :: ob -> C > > id_ :: Ob_ cat a => cat a a > > class NoCls (a::k) > instance NoCls (a::k) > > instance Category_ (->) where > type Ob_ (->) = NoCls > > -- id_ :: NoCls a => (a -> a) -XInstanceSigs > id_ = () > }}} > > the definition of `id_` fails (as we expect), but the expected type (`Ob_ > (->) a -> a -> a`) is wrong: > > {{{#!hs > $ ghci -ignore-dot-ghci 348.hs > GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( 348.hs, interpreted ) > > 348.hs:22:9: error: > • Couldn't match expected type ‘Ob_ (->) a -> a -> a’ > with actual type ‘()’ > • In the expression: () > In an equation for ‘id_’: id_ = () > In the instance declaration for ‘Category_ (->)’ > • Relevant bindings include > id_ :: Ob_ (->) a -> a -> a (bound at 348.hs:22:3) > | > 22 | id_ = () > | ^^ > Failed, no modules loaded. > Prelude> > }}} > > If we simply replace `Ob_` with `type Ob_ (cat :: Cat ob) :: ob -> > Constraint`, the expected type (`a -> a`) matches my intuition: > > {{{ > 348.hs:22:9: error: > • Couldn't match expected type ‘a -> a’ with actual type ‘()’ > • In the expression: () > In an equation for ‘id_’: id_ = () > In the instance declaration for ‘Category_ (->)’ > • Relevant bindings include id_ :: a -> a (bound at 348.hs:22:3) > | > 22 | id_ = () > | ^^ > }}} New description: This may be similar/same as #15412? I can't get to the latest GHC right now. Again the "culprit" is using `type C = Constraint`. The code example should not compile, but the error it gives is unexpected. If we define the associated type family `Ob_ (cat :: Cat ob) :: ob -> C` using `C` {{{#!hs {-# Language KindSignatures, PolyKinds, DataKinds, TypeInType, TypeFamilies, FlexibleInstances #-} import Data.Kind type T = Type type C = Constraint type Cat ob = ob -> ob -> T class Category_ (cat :: Cat ob) where type Ob_ (cat :: Cat ob) :: ob -> C id_ :: Ob_ cat a => cat a a class NoCls (a::k) instance NoCls (a::k) instance Category_ (->) where type Ob_ (->) = NoCls -- id_ :: NoCls a => (a -> a) -XInstanceSigs id_ = () }}} the definition of `id_` fails (as we expect), but the expected type (`Ob_ (->) a -> a -> a`) is wrong: {{{ $ ghci -ignore-dot-ghci 348.hs GHCi, version 8.5.20180128: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 348.hs, interpreted ) 348.hs:22:9: error: • Couldn't match expected type ‘Ob_ (->) a -> a -> a’ with actual type ‘()’ • In the expression: () In an equation for ‘id_’: id_ = () In the instance declaration for ‘Category_ (->)’ • Relevant bindings include id_ :: Ob_ (->) a -> a -> a (bound at 348.hs:22:3) | 22 | id_ = () | ^^ Failed, no modules loaded. Prelude> }}} If we simply replace `Ob_` with `type Ob_ (cat :: Cat ob) :: ob -> Constraint`, the expected type (`a -> a`) matches my intuition: {{{ 348.hs:22:9: error: • Couldn't match expected type ‘a -> a’ with actual type ‘()’ • In the expression: () In an equation for ‘id_’: id_ = () In the instance declaration for ‘Category_ (->)’ • Relevant bindings include id_ :: a -> a (bound at 348.hs:22:3) | 22 | id_ = () | ^^ }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 17:06:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 17:06:47 -0000 Subject: [GHC] #15412: "Instance head is not headed by a class" when `Constraint` replaced with `type C = Constraint` In-Reply-To: <051.c4281f14deae6a8271fa4ba5fd050a12@haskell.org> References: <051.c4281f14deae6a8271fa4ba5fd050a12@haskell.org> Message-ID: <066.db64c5fecb1471c9eb8b7925cff73a3c@haskell.org> #15412: "Instance head is not headed by a class" when `Constraint` replaced with `type C = Constraint` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/typecheck/should_compile/T15412 Blocked By: | Blocking: Related Tickets: #15583 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * related: => #15583 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 17:20:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 17:20:20 -0000 Subject: [GHC] #15584: nonVoid is too conservative w.r.t. strict argument types Message-ID: <050.6cca1c180a42ae3c8a5210a8b2be904f@haskell.org> #15584: nonVoid is too conservative w.r.t. strict argument types -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Keywords: | Operating System: Unknown/Multiple PatternMatchWarnings | Architecture: | Type of failure: Incorrect Unknown/Multiple | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: #15305 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the implementation of the pattern-match coverage checker, the `nonVoid` function checks is some `Type` is inhabitable by at least one constructor. However, `nonVoid` currently does not recursively call itself on the strict argument types of each constructor that is considered. This means that certain exhaustive functions are mistakenly flagged as non- exhaustive, such as in the following example: {{{#!hs {-# LANGUAGE EmptyCase #-} {-# OPTIONS -Wincomplete-patterns #-} module Bug where import Data.Void data V = MkV !Void data S = MkS !V f :: S -> a f x = case x of {} }}} {{{ $ /opt/ghc/head/bin/ghci Bug.hs GHCi, version 8.7.20180827: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:11:7: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: (MkS _) | 11 | f x = case x of {} | ^^^^^^^^^^^^ }}} The natural solution would be to call `nonVoid` recursively on strict argument types, so as to be able to tell that `S` in uninhabitable. But we can't just do this willy nilly, since we could run into infinite loops with recursive examples like this one: {{{#!hs data Abyss = MkAbyss !Abyss stareIntoTheAbyss :: Abyss -> a stareIntoTheAbyss x = case x of {} }}} Better solution: put a recursive type checker into `nonVoid`, and bail out if recursion is detected. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 17:28:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 17:28:04 -0000 Subject: [GHC] #15584: nonVoid is too conservative w.r.t. strict argument types In-Reply-To: <050.6cca1c180a42ae3c8a5210a8b2be904f@haskell.org> References: <050.6cca1c180a42ae3c8a5210a8b2be904f@haskell.org> Message-ID: <065.25470d86b05e9360a3680c910cf8a888@haskell.org> #15584: nonVoid is too conservative w.r.t. strict argument types -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #15305 | Differential Rev(s): Phab:D5116 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5116 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 17:32:50 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 17:32:50 -0000 Subject: [GHC] #15583: Treating Constraint as Type when using (type C = Constraint) In-Reply-To: <051.c99c4ad81b9077682747190361356939@haskell.org> References: <051.c99c4ad81b9077682747190361356939@haskell.org> Message-ID: <066.8daec146afb26cd9a2c953bb2d5c7e99@haskell.org> #15583: Treating Constraint as Type when using (type C = Constraint) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: duplicate | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15412 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate Comment: Yep, this is a duplicate of #15412. Now that that's been fixed, you get the error message you'd expect on the original program: {{{ $ /opt/ghc/8.6.1/bin/ghci Bug.hs GHCi, version 8.6.0.20180823: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:22:9: error: • Couldn't match expected type ‘a -> a’ with actual type ‘()’ • In the expression: () In an equation for ‘id_’: id_ = () In the instance declaration for ‘Category_ (->)’ • Relevant bindings include id_ :: a -> a (bound at Bug.hs:22:3) | 22 | id_ = () | ^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 18:14:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 18:14:56 -0000 Subject: [GHC] #15581: Unable to commit [negative number] bytes of memory In-Reply-To: <042.24290784ed1d220ed7617e764f1f77a0@haskell.org> References: <042.24290784ed1d220ed7617e764f1f77a0@haskell.org> Message-ID: <057.0caa118e72045b9c6b2d23dff0f2864b@haskell.org> #15581: Unable to commit [negative number] bytes of memory -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sibi): * cc: sibi (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 19:06:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 19:06:44 -0000 Subject: [GHC] #15581: Unable to commit [negative number] bytes of memory In-Reply-To: <042.24290784ed1d220ed7617e764f1f77a0@haskell.org> References: <042.24290784ed1d220ed7617e764f1f77a0@haskell.org> Message-ID: <057.94e642fb87a5b027332ecc89899e52cb@haskell.org> #15581: Unable to commit [negative number] bytes of memory -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): This is fixed in 8.6.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 19:09:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 19:09:26 -0000 Subject: [GHC] #15585: Testing Message-ID: <046.c0357035dc12cfe2fb184030f77d141f@haskell.org> #15585: Testing -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Hello world -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 19:09:33 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 19:09:33 -0000 Subject: [GHC] #15585: Testing In-Reply-To: <046.c0357035dc12cfe2fb184030f77d141f@haskell.org> References: <046.c0357035dc12cfe2fb184030f77d141f@haskell.org> Message-ID: <061.72acbf300bbc2acecfc77c31c39c051d@haskell.org> #15585: Testing -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This is a comment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 19:09:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 19:09:51 -0000 Subject: [GHC] #15585: Testing In-Reply-To: <046.c0357035dc12cfe2fb184030f77d141f@haskell.org> References: <046.c0357035dc12cfe2fb184030f77d141f@haskell.org> Message-ID: <061.288e4cbcbce5ecb96020300fe6ee7e4f@haskell.org> #15585: Testing -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 20:37:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 20:37:05 -0000 Subject: [GHC] #15565: ancient ghc release history on web page is incomplete In-Reply-To: <049.81a2a5214fd613fff8e9277a3dbe662c@haskell.org> References: <049.81a2a5214fd613fff8e9277a3dbe662c@haskell.org> Message-ID: <064.2f58a4afdff7d369639007b9717a1c05@haskell.org> #15565: ancient ghc release history on web page is incomplete -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Documentation | 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 bpfoley): For what it's worth, there's a mirror at http://www.mmnt.net/db/0/0/ftp.mimuw.edu.pl/mirror/ftp.dcs.gla.ac.uk/pub/haskell/glasgow/2.10/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Aug 30 21:29:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Aug 2018 21:29:44 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.453e8f92b35f1287083ab479ab5cc11a@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:94 goldfire]: > I have two takeaways from this: > > - An accumulator style is the Right Way to go when building up a set. This idea should probably be abstracted over right in the `VarSet` interface. But do we get these gains without eta-expanding everything? (See Note [FV eta expansion] in FV.) IIRC, I eta-reduced the relevant functions (`tyCoVarsOfXXXX`), but found no significant difference. I only did this for the `VarSet` approach though; I believe the reasoning in that note only holds for FV. Baking accumulator style into `VarSet` is logical, but if we do this, we also need to add the `in_scope` filtering thing found in `FV`, because, as the `nondet-no-in-scope` version shows, not doing this absolutely devastates performance. However, `VarSet` plus accumulator style is exactly `NDFV`, which is `FV` minus the list, which in turn makes no significant difference anyway. So effectively, this takeaway says we should be using `FV`. > - The extra work to track order has no effect. I find this surprising, but not overly so, because we can avoid the extra work via laziness. Well, when I wrote "no effect", I was actually lying a little bit - getting rid of the list reduces overall allocations by about 500 bytes. Which, I think, is about what you'd expect from removing something that never gets evaluated anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 00:18:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 00:18:47 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.2e53d1be688745e1a2445143588c63ec@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I guess my "bake into `VarSet`" idea was essentially to take the `FV` module and combine it into the `VarSet` module, making clear that the FV- derived functions are the right way to incrementally build up a `VarSet`. It's kind of like we know to build up a `String` using higher-order functions, not `++` -- but we should make it very clear, right in the `VarSet` module. Going even further, I imagine this would generalize to any `Map` and might be good to incorporate into `containers`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 02:48:40 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 02:48:40 -0000 Subject: [GHC] #15586: Compilation panic! (the 'impossible' happened) Message-ID: <047.72896e9fea2026e837542aaf516ad2e4@haskell.org> #15586: Compilation panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: subaruru | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- See attached zip for entire project causing error. I'd imagine it's pretty reproducible, just call stack build. I'm running standard lts-12.8 and it's just two small files that don't do anything yet! Also included is panicmessage.txt showing the exact output, crucially: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): piResultTy * v_XabT Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/types/Type.hs:947:35 in ghc:Type }}} Oh and sysinfo {{{ uname -a Linux @@@ 4.16.11-100.fc26.x86_64 #1 SMP Tue May 22 20:02:12 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 02:50:00 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 02:50:00 -0000 Subject: [GHC] #15586: Compilation panic! (the 'impossible' happened) In-Reply-To: <047.72896e9fea2026e837542aaf516ad2e4@haskell.org> References: <047.72896e9fea2026e837542aaf516ad2e4@haskell.org> Message-ID: <062.783699fe288f63d926281a4e08104281@haskell.org> #15586: Compilation panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: subaruru | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by subaruru): * Attachment "STree.zip" added. Project causing error; additionally panicmessage.txt and configyaml.txt -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 06:15:37 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 06:15:37 -0000 Subject: [GHC] #15285: "strange closure type" in T7919 with the threaded2 way In-Reply-To: <048.67a85438785d72c47b85ee0ad004eab2@haskell.org> References: <048.67a85438785d72c47b85ee0ad004eab2@haskell.org> Message-ID: <063.dc4c37270e74fed31e6c1acc158d72ee@haskell.org> #15285: "strange closure type" in T7919 with the threaded2 way -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: T7919 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5115 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): So validate got killed before completion as it took too long, but I can see that T7919 passed: {{{ =====> T7919(normal) 4146 of 6532 [0, 2, 0] =====> T7919(hpc) 4146 of 6532 [0, 2, 0] =====> T7919(optasm) 4146 of 6532 [0, 2, 0] =====> T7919(ghci) 4146 of 6532 [0, 2, 0] =====> T7919(threaded1) 4146 of 6532 [0, 2, 0] =====> T7919(threaded2) 4146 of 6532 [0, 2, 0] =====> T7919(dyn) 4146 of 6532 [0, 2, 0] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 06:38:00 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 06:38:00 -0000 Subject: [GHC] #15285: "strange closure type" in T7919 with the threaded2 way In-Reply-To: <048.67a85438785d72c47b85ee0ad004eab2@haskell.org> References: <048.67a85438785d72c47b85ee0ad004eab2@haskell.org> Message-ID: <063.8342520d377b732f4804172948deb8e6@haskell.org> #15285: "strange closure type" in T7919 with the threaded2 way -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: T7919 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5115 Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): And it's not expected to fail in threaded2 (and possibly other ways) ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 06:52:01 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 06:52:01 -0000 Subject: [GHC] #15285: "strange closure type" in T7919 with the threaded2 way In-Reply-To: <048.67a85438785d72c47b85ee0ad004eab2@haskell.org> References: <048.67a85438785d72c47b85ee0ad004eab2@haskell.org> Message-ID: <063.f2390c753d96a0b452912e4fd89d056b@haskell.org> #15285: "strange closure type" in T7919 with the threaded2 way -------------------------------------+------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Runtime System | Version: 8.5 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: T7919 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5115 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Yeah it should pass in all ways. I'll run a slow validate locally also just to make sure the patch doesn't introduce new failures. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 07:56:33 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 07:56:33 -0000 Subject: [GHC] #15586: Compilation panic! (the 'impossible' happened) In-Reply-To: <047.72896e9fea2026e837542aaf516ad2e4@haskell.org> References: <047.72896e9fea2026e837542aaf516ad2e4@haskell.org> Message-ID: <062.60f5635ca0dc91db97112ba5ce8bc6b5@haskell.org> #15586: Compilation panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: subaruru | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): There are quite a few other tickets about `piResultTy`, now fixed. I wonder if someone could check if the example here, `STree`, is already fixed? Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 08:06:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 08:06:19 -0000 Subject: [GHC] #15578: Honour INLINE pragmas on 0-arity bindings In-Reply-To: <046.e84edd9f62d6ef84f8f7c7aedfa45ace@haskell.org> References: <046.e84edd9f62d6ef84f8f7c7aedfa45ace@haskell.org> Message-ID: <061.0db4348f2d53a80df40f189bdafc670b@haskell.org> #15578: Honour INLINE pragmas on 0-arity bindings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15519 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Perf test suite passes after applying the proposed change. Nofib shows no significant overall differences except for 8.6% more allocations and total memory use for `cacheprof`, and 1.6% more for `maillist`. `maillist` deviates 14.3% on GC(1) count, but this does not affect GC time. `cacheprof` deviates 5.8% on GC Work. Full nofib-analyse output attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 08:06:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 08:06:25 -0000 Subject: [GHC] #15578: Honour INLINE pragmas on 0-arity bindings In-Reply-To: <046.e84edd9f62d6ef84f8f7c7aedfa45ace@haskell.org> References: <046.e84edd9f62d6ef84f8f7c7aedfa45ace@haskell.org> Message-ID: <061.5b3ee52df47e40e77591a021cdaeab5f@haskell.org> #15578: Honour INLINE pragmas on 0-arity bindings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15519 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * Attachment "nofib-analyse" added. nofib analyse output: "clean" is current HEAD, "patched" is the same with the proposed change applied -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 08:20:02 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 08:20:02 -0000 Subject: [GHC] #15578: Honour INLINE pragmas on 0-arity bindings In-Reply-To: <046.e84edd9f62d6ef84f8f7c7aedfa45ace@haskell.org> References: <046.e84edd9f62d6ef84f8f7c7aedfa45ace@haskell.org> Message-ID: <061.082c0ebcaa47863f8565dbb130fbcb29@haskell.org> #15578: Honour INLINE pragmas on 0-arity bindings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15519 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Great! Can you also confirm that this change makes `test3` (described in comment:11 of #15519, under "Workarounds") work as fast as `test0`; and does so * WITHOUT removing the INLINE pragma on `testGrammar` * Without removing the other uses of `testGrammar1` in (say) `test1` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 08:38:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 08:38:35 -0000 Subject: [GHC] #15578: Honour INLINE pragmas on 0-arity bindings In-Reply-To: <046.e84edd9f62d6ef84f8f7c7aedfa45ace@haskell.org> References: <046.e84edd9f62d6ef84f8f7c7aedfa45ace@haskell.org> Message-ID: <061.049994b554779624aed5fb577d503e16@haskell.org> #15578: Honour INLINE pragmas on 0-arity bindings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15519 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Great! Here's a Note to add, and refer to from the `boring_ok` change {{{ Note [Honour INLINE on 0-ary bindings] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Consider x = {-# INLINE x #-} f y = ...x... The semantics of an INLINE pragma is inline x at every call site, provided it is saturated; that is, applied to at least as many arguments as appear on the LHS of the Haskell source definition. (This soure-code-derived arity is stored in the `ug_arity` field of the `UnfoldingGuidance`.) In the example, x's ug_arity is 0, so we should inline it at every use site. It's rare to have such an INLINE pragma (usually INLINE Is on functions), but it's occasionally very important (Trac #15578, #15519). In #15519 we had something like x = case (g a b) of I# r -> T r {-# INLINE x #-} f y = ...(h x).... where h is strict. So we got f y = ...(case g a b of I# r -> h (T r))... and that in turn allowed SpecConstr to ramp up performance. How do we deliver on this? By adjusting the ug_boring_ok flag in mkInlineUnfoldingWithArity; see Note [INLINE pragmas and boring contexts] NB: there is a real risk that full laziness will float it right back out again. Consider again x = factorial 200 {-# INLINE x #-} f y = ...x... After inlining we get f y = ...(factorial 200)... but it's entirely possible that full laziness will do lvl23 = factorial 200 f y = ...lvl23... That's a problem for another day. Note [INLINE pragmas and boring contexts] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ An INLNE pragma uses mkInlineUnfoldingWithArity to build the unfolding. That sets the ug_boring_ok flag to False if the function is not tiny (inlineBorkingOK), so that even INLINE functions are not inlined in an utterly boring context. E.g. \x y. Just (f y x) Nothing is gained by inlining f here, even if it has an INLINE pragma. But for 0-ary bindings, we want to inline regardless; see Note [Honour INLINE on 0-ary bindings]. I'm a bit worried that it's possible for the same kind of problem to arise for non-0-ary functions too, but let's wait and see. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 09:08:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 09:08:15 -0000 Subject: [GHC] #15586: Compilation panic! (the 'impossible' happened) In-Reply-To: <047.72896e9fea2026e837542aaf516ad2e4@haskell.org> References: <047.72896e9fea2026e837542aaf516ad2e4@haskell.org> Message-ID: <062.ca79d6fdb06203cfe6acfe52fbcc4d7f@haskell.org> #15586: Compilation panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: subaruru | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Unfortunately there's no easy way to test this package with newer GHCs as some of its dependencies (zippers, probably lens too) use custom Setup.hs which requires building Cabal which doesn't build with newer GHCs (tested with 8.6.1 beta and HEAD). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 09:25:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 09:25:23 -0000 Subject: [GHC] #5793: make nofib awesome In-Reply-To: <045.7d57713ed957ba5bcc7ab6a047de30d4@haskell.org> References: <045.7d57713ed957ba5bcc7ab6a047de30d4@haskell.org> Message-ID: <060.9571ef443daf59a2e2d9de8e9ae9fcfd@haskell.org> #5793: make nofib awesome -------------------------------------+------------------------------------- Reporter: dterei | Owner: michalt Type: task | Status: new Priority: normal | Milestone: ⊥ Component: NoFib benchmark | Version: suite | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9571 | Blocking: Related Tickets: #15357 #15333 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * related: #15357 => #15357 #15333 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 09:50:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 09:50:10 -0000 Subject: [GHC] #15587: traceEvent tests failing in slow validate Message-ID: <043.5a7481e85ed8eb1897c26ebcfa11c5fb@haskell.org> #15587: traceEvent tests failing in slow validate -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Test Suite | Version: 8.5 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D5119 | Wiki Page: -------------------------------------+------------------------------------- traceEvent tests are failing in slow validate when testing in GHCi way: {{{ =====> traceEvent(ghci) 1 of 2 [0, 0, 0] cd "rts/traceEvent.run" && "/home/omer/haskell/ghc/inplace/test spaces /ghc-stage2" traceEvent.hs -dcore-lint -dcmm-lint -no-user-package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -eventlog< traceEvent.genscript Actual stderr output differs from expected: diff -uw "rts/traceEvent.run/traceEvent.stderr.normalised" "rts/traceEvent.run/traceEvent.run.stderr.normalised" --- rts/traceEvent.run/traceEvent.stderr.normalised 2018-08-31 12:48:13.548375420 +0300 +++ rts/traceEvent.run/traceEvent.run.stderr.normalised 2018-08-31 12:48:13.548375420 +0300 @@ -1 +0,0 @@ -traceEvent: Event size exceeds EVENT_PAYLOAD_SIZE_MAX, bail out *** unexpected failure for traceEvent(ghci) =====> traceBinaryEvent(ghci) 2 of 2 [0, 1, 0] cd "rts/traceBinaryEvent.run" && "/home/omer/haskell/ghc/inplace/test spaces/ghc-stage2" traceBinaryEvent.hs -dcore-lint -dcmm-lint -no-user- package-db -rtsopts -fno-warn-missed-specialisations -fshow-warning-groups -fdiagnostics-color=never -fno-diagnostics-show-caret -dno-debug-output --interactive -v0 -ignore-dot-ghci -fno-ghci-history +RTS -I0.1 -RTS -eventlog< traceBinaryEvent.genscript Actual stderr output differs from expected: diff -uw "rts/traceBinaryEvent.run/traceBinaryEvent.stderr.normalised" "rts/traceBinaryEvent.run/traceBinaryEvent.run.stderr.normalised" --- rts/traceBinaryEvent.run/traceBinaryEvent.stderr.normalised 2018-08-31 12:48:13.712373185 +0300 +++ rts/traceBinaryEvent.run/traceBinaryEvent.run.stderr.normalised 2018-08-31 12:48:13.712373185 +0300 @@ -1 +0,0 @@ -traceBinaryEvent: Event size exceeds EVENT_PAYLOAD_SIZE_MAX, bail out *** unexpected failure for traceBinaryEvent(ghci) Unexpected results from: TEST="traceBinaryEvent traceEvent" }}} I think GHCi doesn't generate eventlogs so there's no way to make these pass. I submitted Phab:D5119 to skip these tests in GHCi way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 09:51:31 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 09:51:31 -0000 Subject: [GHC] #15587: traceEvent tests failing in slow validate In-Reply-To: <043.5a7481e85ed8eb1897c26ebcfa11c5fb@haskell.org> References: <043.5a7481e85ed8eb1897c26ebcfa11c5fb@haskell.org> Message-ID: <058.33c3fe025157b453c5c8be0ef8716f03@haskell.org> #15587: traceEvent tests failing in slow validate -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Test Suite | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5119 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 09:52:13 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 09:52:13 -0000 Subject: [GHC] #15586: Compilation panic! (the 'impossible' happened) In-Reply-To: <047.72896e9fea2026e837542aaf516ad2e4@haskell.org> References: <047.72896e9fea2026e837542aaf516ad2e4@haskell.org> Message-ID: <062.f6941651b68dc6b9c5675d409db1395d@haskell.org> #15586: Compilation panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: subaruru | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5118 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * differential: => Phab:D5118 Comment: Small testcase: {{{ {-# LANGUAGE GADTs #-} module STree where data STree a where STreeIM :: { l :: v a , stree :: a } -> STree a insert :: STree a -> STree a insert s = s { stree = undefined } }}} It crashes 8.4 but works on 8.0, 8.2 and master; I didn't check 8.6 but I presume it's fixed there. I couldn't find a similar program looking for `piResultTy` so I added a testcase in Phab:D5118. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 10:48:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 10:48:44 -0000 Subject: [GHC] #15586: Compilation panic! (the 'impossible' happened) In-Reply-To: <047.72896e9fea2026e837542aaf516ad2e4@haskell.org> References: <047.72896e9fea2026e837542aaf516ad2e4@haskell.org> Message-ID: <062.0f0b563d20a804e87a24b89e4de63414@haskell.org> #15586: Compilation panic! (the 'impossible' happened) -------------------------------------+------------------------------------- Reporter: subaruru | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15499 | Differential Rev(s): Phab:D5118 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * os: Linux => Unknown/Multiple * architecture: x86_64 (amd64) => Unknown/Multiple * related: => #15499 Comment: For the sake of historical curiosity: this was caused by the same bug that triggered #15499, as it requires a record update on a data constructor where an existential type variable comes before a universal one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 10:58:42 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 10:58:42 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.901edbc75ed3162736b2835a52a7ecba@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): Over the last week, I polished this some more and played around with heuristics regarding known and unknown calls. I'm pretty confident the transformation can handle every idea outlined in Wiki:LateLamLift. Here are is an excerpt from a benchmarks run: {{{ -------------------------------------------------------------------------------- Program Allocs Instrs -------------------------------------------------------------------------------- cryptarithm1 -2.8% -7.9% cryptarithm2 -4.0% -2.4% exact-reals -2.1% -0.0% k-nucleotide -0.0% +2.4% kahan -0.4% -2.0% lcss -0.1% -5.8% mate -8.4% -3.5% n-body -20.2% -0.0% queens -17.7% -0.8% typecheck -2.7% -1.8% -------------------------------------------------------------------------------- Min -20.2% -7.9% Max +0.0% +2.4% Geometric Mean -0.8% -0.3% }}} I had to fight with a surprising amount of benchmark wibbles (+-12% in instructions, c.f. #15333) related to GC parameters and code layout (probably), although I was using cachegrind for measurements. The above numbers are from running NoFib with `make EXTRA_RUNTEST_OPTS='-cachegrind +RTS -V0 -A128M -H1G -RTS' NoFibRuns=1`. I looked at the regression in `k-nucleotide` (+2.4% counted instructions), but couldn't reproduce so far. I'll probably refactor the one huge module into 2 or 3 smaller ones and then prepare a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 11:02:33 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 11:02:33 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.28d1146c2faf27546e6262848fea9b11@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by simonpj): This sounds great, thank you! There are some knobs you can turn in LLF, aren't there. E.g. if a function has 200 free vars, we probably don't want to lambda-lift it an turn it into a function with 200 parameters. Did you experiment with different settings of the threshold for number-of- free-vars? There may be more knobs too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 11:18:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 11:18:28 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.dc4c847af548e0c6d087116d16e89ab1@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): I think Nicolas played around with those parameters, concluding that this wiki:LateLamLift#llf-nr10-r6 was the best configuration. I played around with settings like the number of vars to abstract over when I was still testdriving the Core transformation. IIRC, the desired cutoff was 5 arguments in total, because any excess arguments are passed on the stack. But now that the transformation works reliably, I think I can play around with it some more again. There are some knobs to turn: There's `-fstg-lift-lams-args(-any)` (default: number of available registers for argument passing, currently hard-coded to 5) which takes an upper bound for the number of arguments the function may have ''after'' lifting. Also no distinction if the function is recursive or not (yet?). As well as `-f(no-)stg-lift-lams-known` (default: no) which controls if we are willing to turn known calls into unknown calls. This happens when we lift a function that abstracts over a known function: {{{ let f x = ... mapF xs = ... f x ... in mapF [1,2,3] ==> mapF_up f xs = ... f x ... let f x = ... in mapF_up f [1,2,3] }}} Lifting `mapF` turns the call to `f` into an unknown call. Wrt. the other heuristics I employ, peek here if you're interested: https://github.com/sgraf812/ghc/blob/1e45f1fe3133a263694d05d01b84a245d4244098/compiler/simplStg/StgLiftLams.hs#L413-L420 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 11:59:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 11:59:59 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (allocates 50% more) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.0a9e4388f79528705d5cff4d55a784e8@haskell.org> #8763: forM_ [1..N] does not get fused (allocates 50% more) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7206 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Thanks for the curation, George! Now that I spent some time with late lambda lifting and have an implementation at hand, I revisited this issue. Indeed, the original `$wg` binding from comment:44 gets lifted to top- level, but there is no reduction in allocation to be had (it's just swapping each mention of the local binding in closures for its single free variable, after all) and instructions executed are roughly the same. That's because part of the original problem persists: The hot loop `go_up` is still not a join point. I still think the implementation from comment:60 is the way to go. With the improvements to constant folding in Phab:D4605, the mentioned increase in closure size should be constant-folded away in the majority of cases. I'll conduct some benchmarks next week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 12:15:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 12:15:43 -0000 Subject: [GHC] #8763: forM_ [1..N] does not get fused (allocates 50% more) In-Reply-To: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> References: <042.6416bb310965de24a032dfcecd66fba0@haskell.org> Message-ID: <057.f556c05498691c2b64bb26fdfa2a62cc@haskell.org> #8763: forM_ [1..N] does not get fused (allocates 50% more) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7206 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): That sounds great! Thanks to you an everybody else who has improved this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 13:27:46 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 13:27:46 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.032496cecdfd0bd0ae488f15b006f4d4@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by simonpj): OK, it sounds as if you are exploring the space really well -- thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 14:26:08 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 14:26:08 -0000 Subject: [GHC] #14974: 2-fold memory usage regression GHC 8.2.2 -> GHC 8.4.1 compiling `mmark` package In-Reply-To: <042.6f9317183740e6c428dbe334554fec22@haskell.org> References: <042.6f9317183740e6c428dbe334554fec22@haskell.org> Message-ID: <057.87cc33fbb85451cb522818c77712e1d2@haskell.org> #14974: 2-fold memory usage regression GHC 8.2.2 -> GHC 8.4.1 compiling `mmark` package -------------------------------------+------------------------------------- Reporter: hvr | Owner: davide Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by davide): * owner: (none) => davide -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 15:11:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 15:11:27 -0000 Subject: [GHC] #15588: Panic when abusing kind inference Message-ID: <047.7d52b9af2da71c932638f19d9140b7f4@haskell.org> #15588: Panic when abusing kind inference -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I say {{{#!hs {-# LANGUAGE ScopedTypeVariables, TypeInType, TypeOperators, TypeFamilies, AllowAmbiguousTypes #-} import Data.Proxy import Data.Type.Equality import Data.Type.Bool import Data.Kind data SameKind :: forall k. k -> k -> Type type family IfK (e :: Proxy (j :: Bool)) (f :: m) (g :: n) :: If j m n where IfK (_ :: Proxy True) f _ = f IfK (_ :: Proxy False) _ g = g y :: forall ck (c :: ck). ck :~: Proxy True -> () y Refl = let x :: forall a b (d :: a). SameKind (IfK c b d) d x = undefined in () }}} HEAD says {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20180827 for x86_64-apple-darwin): ASSERT failed! Bad coercion hole co_a3iZ: If j_a3j0[tau:2] m_a3j1[tau:2] a_a3gV[sk:3] a_a3gV[sk:3] nominal If j_a3j0[tau:2] m_a3j1[tau:2] a_a3jj[sk:3] ~# a_a3jj[sk:3] 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/TcMType.hs:316:25 in ghc:TcMType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} It's as yet unclear whether the program should be accepted. My best guess is that it should, but that (even with this panic fixed) GHC isn't up to the task. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 15:14:46 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 15:14:46 -0000 Subject: [GHC] #13862: Optional "-v" not allowed with :load in GHCi In-Reply-To: <044.9738400eba372a90ccdc97dcca61b7c9@haskell.org> References: <044.9738400eba372a90ccdc97dcca61b7c9@haskell.org> Message-ID: <059.fab3818a6558bfe728b4e43200f2162c@haskell.org> #13862: Optional "-v" not allowed with :load in GHCi -------------------------------------+------------------------------------- Reporter: vanto | Owner: RolandSenn Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * owner: (none) => RolandSenn Comment: I'll work on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 15:27:48 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 15:27:48 -0000 Subject: [GHC] #15589: Always promoting metavariables during type inference may be wrong Message-ID: <047.51146f5adc8f94aa92119170150b76d8@haskell.org> #15589: Always promoting metavariables during type inference may be wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, when checking a type signature, GHC promotes all the metavariables that arise during checking as soon as it's done checking the signature. This may be incorrect sometimes. Consider {{{#!hs {-# LANGUAGE ScopedTypeVariables, TypeInType, TypeOperators, TypeFamilies, AllowAmbiguousTypes #-} import Data.Proxy import Data.Type.Equality import Data.Type.Bool import Data.Kind data SameKind :: forall k. k -> k -> Type type family IfK (e :: Proxy (j :: Bool)) (f :: m) (g :: n) :: If j m n where IfK (_ :: Proxy True) f _ = f IfK (_ :: Proxy False) _ g = g y :: forall (cb :: Bool) (c :: Proxy cb). cb :~: True -> () y Refl = let x :: forall a b (d :: a). SameKind (IfK c b d) d x = undefined in () }}} This panics currently (#15588), but I'm pretty sure it will erroneously be rejected even after the panic is fixed. Let's walk through it. * We can derive `IfK :: forall (j :: Bool) (m :: Type) (n :: Type). Proxy j -> m -> n -> If j m n`, where `If :: forall k. Bool -> k -> k -> k` is imported from `Data.Type.Bool` and is a straightforward conditional choice operator. * In the type of `x`, we see that we need the kind of `IfK c b d` to match the kind of `d`. That is, if `b :: kappa[3]`, we have `[W] If cb kappa[3] a ~ a`. Here, the `forall` in `x`'s type is at level 3; the RHS of `y` is at level 2. * If we could reduce `If cb kappa[3] a` to `kappa[3]`, then we would solve `kappa[3] := a`, but we can't make this reduction, because `cb` is a skolem. * Instead, we finish checking the type of `x` and promote `kappa[3]` to `kappa[2]`. * Later, we'll make an implication constraint with `[G] cb ~ True`. When solving that implication constraint, we'll get `[W] If True kappa[2] a ~ a` and simplify to `[W] kappa[2] ~ a`, but that will be insoluble because we'll be solving at level 3, and now `kappa[2]` is at level 2. We're too late. Yet, I claim that this program should be accepted, and it would be if GHC tracked a set of ambient givens and used them in local calls to the solver. With these "ambient givens" (instead of putting them only in implication constraints), we would know `cb ~ True` the first time we try to solve, and then we'll succeed. An alternative story is to change how levels are used with variables. Currently, levels are, essentially, the number of type variables available from an outer scope. Accordingly, we must make sure that the level of a variable is never higher than the ambient level. (If it were, we wouldn't know what extra variable(s) were in scope.) Instead, we could just store the list of variables that were in scope. We wouldn't then need to promote in this case -- promotion would happen only during floating. But tracking these lists is a real pain. (If we decide to pursue this further, I can add more details, but it's all in Chapter 6 in [https://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1074&context=compsci_pubs my thesis] -- section 6.5 to be specific.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 18:04:24 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 18:04:24 -0000 Subject: [GHC] #15589: Always promoting metavariables during type inference may be wrong In-Reply-To: <047.51146f5adc8f94aa92119170150b76d8@haskell.org> References: <047.51146f5adc8f94aa92119170150b76d8@haskell.org> Message-ID: <062.f9084e875ff8a77ddb6351b3ac27deaf@haskell.org> #15589: Always promoting metavariables during type inference may be wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Here's another idea, IMHO far better than "storing the list of variables in scope". * Give every `Implication` a unique identity. The already have one, in the form of the EvBindsVar (see `ebv_uniq`), but we should probably promote it to the `Implication` itself, replacing the `ic_tclvl` field. * Instead of a level, store in a (meta) TcTyVar the ''identity of its enclosing implication''. Call that the ''implication parent'' of the TcTyVar. * A `TcTyVar` is touchable iff its implication parent is the current implication. * Levels are already immutable; when promoting a tyvar we make a new one, and we can still do that fine. Implication identities completely replace level numbers. Now, in the example, we'll give `x` the type {{{ x :: forall a (b :: kappa[i34]) (d :: a). SameKind (IfK c b d) d plus the leftover implication constraint forall[i34] a b d. If cb kappa[i34] a ~ a }}} Here `i34` is the identity of the parent implication, which arises from the `forall` in the type signature. That implication constraint is emitted unsolved; and x's type is in the environment with this now-forever-untouchable `kappa[i34]`. It can only be touched (and hence solved) when we have another go at solving that implication constraint -- which we will. And Bob's your uncle. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 18:04:39 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 18:04:39 -0000 Subject: [GHC] #15589: Always promoting metavariables during type inference may be wrong In-Reply-To: <047.51146f5adc8f94aa92119170150b76d8@haskell.org> References: <047.51146f5adc8f94aa92119170150b76d8@haskell.org> Message-ID: <062.78ca92688336c071a5aac8d5986500e7@haskell.org> #15589: Always promoting metavariables during type inference may be wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 18:05:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 18:05:43 -0000 Subject: [GHC] #15552: Infinite loop/panic with an existential type. In-Reply-To: <050.eb5168d400b4a4211e35d29d96945d09@haskell.org> References: <050.eb5168d400b4a4211e35d29d96945d09@haskell.org> Message-ID: <065.605e809c2ec8e777caa6f63abf367bb3@haskell.org> #15552: Infinite loop/panic with an existential type. -------------------------------------+------------------------------------- Reporter: howtonotwin | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: TypeInType, | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14723 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"565ef4cc036905f9f9801c1e775236bb007b026c/ghc" 565ef4c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="565ef4cc036905f9f9801c1e775236bb007b026c" Remove knot-tying bug in TcHsSyn.zonkTyVarOcc There was a subtle knot-tying bug in TcHsSyn.zonkTyVarOcc, revealed in Trac #15552. I fixed it by * Eliminating the short-circuiting optimisation in zonkTyVarOcc, instead adding a finite map to get sharing of zonked unification variables. See Note [Sharing when zonking to Type] in TcHsSyn * On the way I /added/ the short-circuiting optimisation to TcMType.zonkTcTyVar, which has no such problem. This turned out (based on non-systematic measurements) to be a modest win. See Note [Sharing in zonking] in TcMType On the way I renamed some of the functions in TcHsSyn: * Ones ending in "X" (like zonkTcTypeToTypeX) take a ZonkEnv * Ones that do not end in "x" (like zonkTcTypeToType), don't. Instead they whiz up an empty ZonkEnv. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 18:07:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 18:07:52 -0000 Subject: [GHC] #15552: Infinite loop/panic with an existential type. In-Reply-To: <050.eb5168d400b4a4211e35d29d96945d09@haskell.org> References: <050.eb5168d400b4a4211e35d29d96945d09@haskell.org> Message-ID: <065.6423fdec74fb82b6f9f39a85f507ad0b@haskell.org> #15552: Infinite loop/panic with an existential type. -------------------------------------+------------------------------------- Reporter: howtonotwin | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: TypeInType, | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14723 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge Comment: OK I think I'm done with this. Perf is fine; and the bug is fixed. Lots of Notes to explain. It fixes an outright bug, so merge if poss. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 18:18:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 18:18:43 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.d2ea255fa9fba83ca8032ceccf204eaf@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15076 | Differential Rev(s): Phab:D4769 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, I think I have finally nailed what is going on. '''I have pushed my work to `wip/T1448-accum`. NB Missing "0" in the branch name, sorry.''' The key insight is in the commit message of the top patch on that branch, which is the only patch that isn't in master, I think: {{{ commit a4e7a912ff426ef9cb968ea21d1a514f203a7ea5 Author: Simon Peyton Jones Date: Fri Aug 31 14:18:55 2018 +0100 Use an accumulator version of tyCoVarsOfType In TyCoRep we now have tyCoVarsOfType implemented 1) Using FV -- this is the baseline version in GHC today 2) Using VarSets via unionVarSet 3) Using VarSets in accumulator-style In this patch (3) is enabled. When compiling perf/compiler/T5631 we get Compiler allocs (1) 1,144M (2) 1,175M (3) 1,142M The key new insight in (3) is this: ty_co_vars_of_type (TyVarTy v) is acc | v `elemVarSet` is = acc | v `elemVarSet` acc = acc <---- NB! | otherwise = ty_co_vars_of_type (tyVarKind v) is (extendVarSet acc v) Notice the second line! If the variable is already in the accumulator, don't re-add it. This makes big difference. Without it, allocation is 1,169M or so. One cause is that we only take the free vars of its kind once; that problem will go away when we do the main part of #14088 and close over kinds /afterwards/. But still, another cause is perhaps that every insert into a set overwrites the previous item, and so allocates a new path to the item; it's not a no-op even if the item is there already. Why use (3) rather than (1)? Because it just /has/ to be better; * FV carries around an InterestingVarFun, which does nothing useful here, but is tested at every variable * FV carries around a [Var] for the deterministic version. For this very hot operation (finding free vars) I think it makes sense to have special purpose code. On the way I also simplified the (less used) coVarsOfType/Co family to use FV, by making serious use of the InterestingVarFun! }}} It was this check against the accumulator, which FV has always performed, which is responsible for how FV mysteriously out-performed all other contenders. Once that is done, a stripped-down version of FV (implemented as (3) in the code above) slightly out-performs FV. All of this is relative to `wip/T14880-baseline`. Therefore I suggest 1. Apply my patch to HEAD (and check for no regressions) 2. Apply the rest of the #14880 patch to that By "the rest" I mean everything in the original patch [http://git.haskell.org/ghc.git/log/refs/heads/wip/T14880] ''except'' the implementation of `tcvs_of_type`. Specifically, doing `closeOverKinds` at the end, rather than at each leaf. Doubtless other stuff too. There are a number of other tickets that are waiting for this one to be finished: #14040, #15076, #14887. Tobias can you do this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 18:38:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 18:38:56 -0000 Subject: [GHC] #15577: TypeApplications-related infinite loop (GHC 8.6+ only) In-Reply-To: <050.727e460d0083534afd4869db4aa81c30@haskell.org> References: <050.727e460d0083534afd4869db4aa81c30@haskell.org> Message-ID: <065.15e56b8a36858507502dfd7f9a5c7a61@haskell.org> #15577: TypeApplications-related infinite loop (GHC 8.6+ only) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | TypeApplications, TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I know what is happening here. In `TcCanonical.canCFunEqCan` we have {{{ canCFunEqCan ev fn tys fsk = do { (tys', cos, kind_co) <- flattenArgsNom ev fn tys -- cos :: tys' ~ tys ; let lhs_co = mkTcTyConAppCo Nominal fn cos -- :: F tys' ~ F tys new_lhs = mkTyConApp fn tys' flav = ctEvFlavour ev ; (ev', fsk') -- See Note [canCFunEqCan] <- if isTcReflCo kind_co then ..normal, homo-kinded case.. else ..hetero-kinded case.. ... }}} The note is a good explanation; read it. In the example above, we get a Given `CFunEqCan` ''that is homo-kinded''. But `kind_co` turns out not to be `ReflCo` but rather some giant (but still reflexive) coercion. ''So we fall ito the heter-kinded case''. Then, as the Note says, we make a new homo-kinded `CFunEqCan`. But when we end up processing that (as we do), we think it too is hetero- kinded, and so we do it all over again. Forever. For now I have fixed it by using `isTcReflexiveCo` instead of `isTcReflCo`. But isn't it suspicious that `flattenArgsNom` returns a complicated giant coercion? And that gets right back into `flatten_args_fast` and `flatten_args_slow`, which we were discussing last week. I'll leave that for Richard and Ningning to ponder. Meanwhile I think I have fixed the loop. Validating now.... Here for completeness is part of the log {{{ canCFunEqCan: non-refl Kind co: (Sym (GRefl nominal (a_a28l[sk:1] |> ({co_a29i} ; ((Sym (GRefl nominal f_a28k[sk:1] {co_a28p}) ; GRefl nominal f_a28k[sk:1] {co_a28p}) ->_N <*>_N)) ; ((Sym (GRefl nominal f_a28k[sk:1] {co_a28p}) ; GRefl nominal f_a28k[sk:1] {co_a28p}) ->_N <*>_N)) (Sym ((Sym (GRefl nominal f_a28k[sk:1] {co_a28p}) ; GRefl nominal f_a28k[sk:1] {co_a28p}) ->_N <*>_N))) ; (Sym (GRefl nominal a_a28l[sk:1] (({co_a29i} ; ((Sym (GRefl nominal f_a28k[sk:1] {co_a28p}) ; GRefl nominal f_a28k[sk:1] {co_a28p}) ->_N <*>_N)) ; ((Sym (GRefl nominal f_a28k[sk:1] {co_a28p}) ; GRefl nominal f_a28k[sk:1] {co_a28p}) ->_N <*>_N))) ; GRefl nominal a_a28l[sk:1] (({co_a29i} ; ((Sym (GRefl nominal f_a28k[sk:1] {co_a28p}) ; GRefl nominal f_a28k[sk:1] {co_a28p}) ->_N <*>_N)) ; ((Sym (GRefl nominal f_a28k[sk:1] {co_a28p}) ; GRefl nominal f_a28k[sk:1] {co_a28p}) ->_N <*>_N)))) (Sym (GRefl nominal (r_a28m[sk:1] |> Sym {co_a28w} ; GRefl nominal f_a28k[sk:1] {co_a28p}) (Sym (Sym (GRefl nominal f_a28k[sk:1] {co_a28p}) ; GRefl nominal f_a28k[sk:1] {co_a28p}))) ; (Sym (GRefl nominal r_a28m[sk:1] (Sym {co_a28w} ; GRefl nominal f_a28k[sk:1] {co_a28p})) ; GRefl nominal r_a28m[sk:1] (Sym {co_a28w} ; GRefl nominal f_a28k[sk:1] {co_a28p}))) RHS: fsk_a29k[fsk:2] :: (a_a28l[sk:1] |> ({co_a29i} ; ((Sym (GRefl nominal f_a28k[sk:1] {co_a28p}) ; GRefl nominal f_a28k[sk:1] {co_a28p}) ->_N <*>_N)) ; ((Sym (GRefl nominal f_a28k[sk:1] {co_a28p}) ; GRefl nominal f_a28k[sk:1] {co_a28p}) ->_N <*>_N)) (r_a28m[sk:1] |> Sym {co_a28w} ; GRefl nominal f_a28k[sk:1] {co_a28p}) LHS: F (f_a28k[sk:1] |> {co_a28p}) (a_a28l[sk:1] |> ({co_a29i} ; ((Sym (GRefl nominal f_a28k[sk:1] {co_a28p}) ; GRefl nominal f_a28k[sk:1] {co_a28p}) ->_N <*>_N)) ; ((Sym (GRefl nominal f_a28k[sk:1] {co_a28p}) ; GRefl nominal f_a28k[sk:1] {co_a28p}) ->_N <*>_N)) (r_a28m[sk:1] |> Sym {co_a28w} ; GRefl nominal f_a28k[sk:1] {co_a28p}) r_a28x[tau:1] :: (a_a28l[sk:1] |> ({co_a29i} ; ((Sym (GRefl nominal f_a28k[sk:1] {co_a28p}) ; GRefl nominal f_a28k[sk:1] {co_a28p}) ->_N <*>_N)) ; ((Sym (GRefl nominal f_a28k[sk:1] {co_a28p}) ; GRefl nominal f_a28k[sk:1] {co_a28p}) ->_N <*>_N)) (r_a28m[sk:1] |> Sym {co_a28w} ; GRefl nominal f_a28k[sk:1] {co_a28p}) New LHS F (f_a28k[sk:1] |> {co_a28p}) (a_a28l[sk:1] |> ({co_a29i} ; ((Sym (GRefl nominal f_a28k[sk:1] {co_a28p}) ; GRefl nominal f_a28k[sk:1] {co_a28p}) ->_N <*>_N)) ; ((Sym (GRefl nominal f_a28k[sk:1] {co_a28p}) ; GRefl nominal f_a28k[sk:1] {co_a28p}) ->_N <*>_N)) (r_a28m[sk:1] |> Sym {co_a28w} ; GRefl nominal f_a28k[sk:1] {co_a28p}) r_a28x[tau:1] :: (a_a28l[sk:1] |> ({co_a29i} ; ((Sym (GRefl nominal f_a28k[sk:1] {co_a28p}) ; GRefl nominal f_a28k[sk:1] {co_a28p}) ->_N <*>_N)) ; ((Sym (GRefl nominal f_a28k[sk:1] {co_a28p}) ; GRefl nominal f_a28k[sk:1] {co_a28p}) ->_N <*>_N)) (r_a28m[sk:1] |> Sym {co_a28w} ; GRefl nominal f_a28k[sk:1] {co_a28p}) }}} This shows stuff right at the start of the hetero-kinded 'else' branch above * `kind_co` is the giant coercion returned by `flattenArgsNom` * `RHS` is the fsk, and I show its kind, which is `(a |> ..) (r |> ..)` * `LHS` is the original function application, `(F tys)` in the code above; again I show its kind, which is identical to that of fks. * `New LHS` is the new function application after flattening, `(F tys')` in the code. You'll note that it is '''identical''' to `(F tys)`! All this work for nothing. Surely `flattenArgsNom` can be a bit cleverer? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 18:51:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 18:51:55 -0000 Subject: [GHC] #14827: Recognize when inlining would create a join point In-Reply-To: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> References: <047.6cf87b3d4f17f642526f7aa129d1b9d9@haskell.org> Message-ID: <062.6cc62694358a750468823c0c4b13f58f@haskell.org> #14827: Recognize when inlining would create a join point -------------------------------------+------------------------------------- Reporter: ersetzen | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I've got lost in this ticket. 1. comment:13 shows (correctly) that if you specify phases wrong you can get bad results. Yes, it's possible we could warn about this. 2. comment:11, I think, shows a case where an INLINE pragmas makes things worse. I have not dug into it. 3. The original thing in the Description got tangled with stuff about loopification, so I'm not sure of its status. Are (1) and (2) connected? If not, can you make a separate ticket for (1)? Is (30 dealt with now? That is, are we left with (2) only? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 19:29:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 19:29:57 -0000 Subject: [GHC] #15589: Always promoting metavariables during type inference may be wrong In-Reply-To: <047.51146f5adc8f94aa92119170150b76d8@haskell.org> References: <047.51146f5adc8f94aa92119170150b76d8@haskell.org> Message-ID: <062.927791804962eb6a9b26bd78d85d83f9@haskell.org> #15589: Always promoting metavariables during type inference may be wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): But how do we instantiate the type of `x` at an occurrence? We'll generate `alpha`, `beta`, and `delta` to instantiate for `a`, `b`, and `d`, respectively. We figured out a while ago that `a`'s kind -- hence `alpha`'s -- is `Type`. But what will `beta`'s kind be? It can't quite be `kappa[i34]`, because `kappa[i34]` might turn out to mention `a`, not `alpha`. Instead, it has to be `kappa[i34][a |-> alpha]`, as some kind of suspended substitution. My thesis (and Adam's) does this by including a list of variables at every occurrence of a unification variable. Thus, it would be `beta_[alpha]`, where it's understood that `alpha` is the instantiation of variables that might appear in `beta`'s kind. Similarly, `delta` would really be `delta_[alpha,beta]`, because `delta` is preceded by two instantiated variables. Really, all comment:1 does is to come up with a concise (and very convenient) way to store lists of variables, by naming the lists and storing the names. But I don't think it eliminates all the attendant complication of instantiation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 20:01:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 20:01:20 -0000 Subject: [GHC] #15590: Existentials in newtypes Message-ID: <046.bbb94a5d16ee9949a5e64de8def54494@haskell.org> #15590: Existentials in newtypes -------------------------------------+------------------------------------- Reporter: NioBium | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Please allow existential quantification of phantom type arguments in newtypes. {{{ type role A nominal representational phantom -- Or inferred roles. newtype B a b where B :: A a b c -> B a b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 22:11:21 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 22:11:21 -0000 Subject: [GHC] #15569: Constant folding optimises 1 into 3 In-Reply-To: <050.faecf73a66ba46b12a33656ce184ee72@haskell.org> References: <050.faecf73a66ba46b12a33656ce184ee72@haskell.org> Message-ID: <065.53b98864f209a8cfea0c7c2d36e866dd@haskell.org> #15569: Constant folding optimises 1 into 3 -------------------------------------+------------------------------------- Reporter: snowleopard | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9136 | Differential Rev(s): Phab:D5109 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ChaiTRex): * differential: => Phab:D5109 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 22:12:41 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 22:12:41 -0000 Subject: [GHC] #15581: Unable to commit [negative number] bytes of memory In-Reply-To: <042.24290784ed1d220ed7617e764f1f77a0@haskell.org> References: <042.24290784ed1d220ed7617e764f1f77a0@haskell.org> Message-ID: <057.51ae363afb53780aa4c640a10b7ab1e1@haskell.org> #15581: Unable to commit [negative number] bytes of memory -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * status: new => closed * resolution: => fixed * milestone: 8.8.1 => 8.6.1 Comment: Great! Diffs: * https://phabricator.haskell.org/D4373 * https://phabricator.haskell.org/D4390 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Aug 31 22:12:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 31 Aug 2018 22:12:58 -0000 Subject: [GHC] #15581: Unable to commit [negative number] bytes of memory In-Reply-To: <042.24290784ed1d220ed7617e764f1f77a0@haskell.org> References: <042.24290784ed1d220ed7617e764f1f77a0@haskell.org> Message-ID: <057.4eaf5cca85fa4eea3a392beb18709d50@haskell.org> #15581: Unable to commit [negative number] bytes of memory -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * status: new => closed * resolution: => fixed * milestone: 8.8.1 => 8.6.1 Comment: Great! Diffs: * https://phabricator.haskell.org/D4373 * https://phabricator.haskell.org/D4390 -- Ticket URL: GHC The Glasgow Haskell Compiler