From ghc-devs at haskell.org Mon Oct 1 00:36:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 00:36:11 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.7527a2bebbaddef165633d4fed8281ab@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): @Ben, i dropped the ball on that comparison, i'll add it to my queue :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 00:36:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 00:36:37 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.bc1651ced704a903aa8d31182d559e78@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): and or ask for some help from other mac users -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 02:59:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 02:59:39 -0000 Subject: [GHC] #15691: Marking Pred(S n) = n as injective In-Reply-To: <051.d7e7ce03c23f4752318f13248c7822e5@haskell.org> References: <051.d7e7ce03c23f4752318f13248c7822e5@haskell.org> Message-ID: <066.d92a2b417862b0fd1f24b7a8d286d282@haskell.org> #15691: Marking Pred(S n) = n as injective -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.6.1 checker) | Keywords: TypeFamilies, Resolution: invalid | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): There are no current plans to implement "Constrained Type Families". The natural way to do it requires dependent types (because it requires the appearance of dictionaries, which are terms, in types). We could hack something together that didn't use dependent types, but it would be a hack. I would love to see Constrained Type Families indeed implemented once we have dependent types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 03:05:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 03:05:51 -0000 Subject: [GHC] #15648: Core Lint error with source-level unboxed equality In-Reply-To: <050.b1c8c377aa63cdac74b3d157d20320e2@haskell.org> References: <050.b1c8c377aa63cdac74b3d157d20320e2@haskell.org> Message-ID: <065.5bf27647fd2651a7eef2b5e8813e4e58@haskell.org> #15648: Core Lint error with source-level unboxed equality -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15209 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I worry a malicious user of TH might get around the `checkValidType` check. Why do we need * If `x :: t1 ~# t2`, then `x` is a `CoVar` ? We clearly need the other direction of implication (that all `CoVar`s have coercion types), but I don't see the harm in allowing non-`CoVar`s to have coercion types. They'd be useless, but also harmless, I think. I wonder if there is just some code that looks at an `Id`'s type to determine whether it's a coercion variable instead of checking `isCoVar`. This might be from the fact that `CoVar`'s distinguished nature in `IdDetails` is a relatively new innovation. It used to be that looking at the type was the only way to tell coercion variables from others. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 03:09:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 03:09:25 -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.ec1b20c7b2d28bd57e29de65525b1868@haskell.org> #15471: Polymorphism, typed splices and type inference don't mix -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: 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 vote for the zonker, if only because the zonker is still in the `TcM` monad, making (3) above easier. Otherwise, the desugarer has to call the type checker, which is awkward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 03:37:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 03:37:32 -0000 Subject: [GHC] #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory In-Reply-To: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> References: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> Message-ID: <063.0b9775cdbf72eae91306aa66a90dbc4c@haskell.org> #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: None | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by wereHamster): Is there documentation how to install /usr/local/opt/gmp/lib/libgmp.10.dylib? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 06:59:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 06:59:52 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.5b05a7235081e3024e9ec79cb9e7579f@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Ok, so I tried to tackle this again today. The very first thing I did was to refactor `data FractionalLit` as suggested, then follow the type errors. Firstly I wasn't 100% sure how to best approach a workflow, so I tried using GHCi and loading the BasicTypes module in, but that failed because of missing dependencies, so then I tried to use `make fast -j3` in the `ghc/compiler` directory and that seemed to work out ok in terms of speed. I was initially worried it was going to take too long, but it's fine. So, adjusting `FractionalLit` is fine. I made the change, then it complained bout `mkFractionalLit` being incorrect, as I'd expect. I'm not 100% sure of the intent of `mkFractionalLit`, though — it looks like it's a simple constructor; when I compare it to `mkIntegralLit`, etc, and when I looked up the use-sites it appears to passing a Rational value still makes sense, so I thought I'd keep that. Then I realised I'm going to have to effectively implement something like an adjusted version of `fromBaseRational 10` from https://hackage.haskell.org/package/numeric- prelude-0.4.3/docs/src/Number-Positional.html#fromBaseRational to find the mantissa and exponent. Am I barking up the right tree here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 07:37:41 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 07:37:41 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.f2961000b09dfa9908668f4521fac79e@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Chatted a bit more with osa1 about this now on IRC. Seems TH has the same issue(s), because the use-sites for `mkFractionalLit` includes the `cvtOverLit :: Lit -> CvtM (HsOverLit GhcPs)` function from hsSync/Convert.hs... the `cvtOverLit (RationalL r)` clause, which reads: ``` cvtOverLit (RationalL r) = do { force r; return $ mkHsFractional (mkFractionalLit r) } ``` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 07:55:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 07:55:52 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.7e42a245cacf462e34dde6749e0e4cc5@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): AFAICS, the only use-sites for `mkFractionalLit` are in HsSync/Convert.hs for the above function and also `cvtLit`. Does anyone have any thoughts about what a good approach to doing this might be? Should I be changing `mkFractionalLit` to `Integer -> Integer -> FractionalLit` or leave it as `Real a => a -> FractionalLit` as it already is? (the latter would imply doing some conversion to the number, the former would indicate the same conversion being moved up into the TH related code). Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 09:03:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 09:03:03 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.32808776ad68fb5c2cb5da4472525925@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: bgamari, osa1 Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #15630 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): A quick test suggests that the patch from comment:24 makes things better, but not by the amount we would expect from actually solving the excessive inlining / Core blowup issue. On my machine, compilation time between GHC 8.4.2 and HEAD with the patch applied goes down from 2:00 minutes to 1:45 approximately; significantly faster, but not the orders-of-magnitude improvement we would expect from a proper fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 11:25:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 11:25:39 -0000 Subject: [GHC] #15630: panic! Simplifier ticks exhausted In-Reply-To: <049.c44dcaac100e8732d769d68c9db99cf2@haskell.org> References: <049.c44dcaac100e8732d769d68c9db99cf2@haskell.org> Message-ID: <064.c3f7ed6cb34b77dd1dadb47e508fe052@haskell.org> #15630: panic! Simplifier ticks exhausted ---------------------------------+-------------------------------------- Reporter: micahshahn | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by tdammers): Did some quick testing; `{-# NOINLINE (<+>) #-}` does "fix" the problem (bringing compilation time for the example here down from 8 minutes to less than one second); however, the patch from https://ghc.haskell.org/trac/ghc/ticket/13253#comment:24 doesn't seem to make a difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 11:48:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 11:48:06 -0000 Subject: [GHC] #15497: Coercion Quantification In-Reply-To: <047.3a4a4e067b87a899efdf8c3f044fd1ac@haskell.org> References: <047.3a4a4e067b87a899efdf8c3f044fd1ac@haskell.org> Message-ID: <062.fd134fa56d148e115ed4502caf2400a0@haskell.org> #15497: Coercion Quantification -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5054 Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase2| -------------------------------------+------------------------------------- Changes (by simonpj): * owner: ningning => (none) * status: closed => new * resolution: fixed => Comment: I came across `Note [Emitting the residual implication in simplifyInfer]` in `TcSimplify`. It says “We can't form types like (forall co. blah), so we can't generalise over the coercion variable, …” But when you commit coercion quantification, we ''can'' quantify over coercions in types. So it is possible that this bit of cruft could be tidied up, with a significant simplification. I'll re-open the ticket to keep this idea on the radar. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 11:48:29 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 11:48:29 -0000 Subject: [GHC] #15497: Coercion Quantification In-Reply-To: <047.3a4a4e067b87a899efdf8c3f044fd1ac@haskell.org> References: <047.3a4a4e067b87a899efdf8c3f044fd1ac@haskell.org> Message-ID: <062.424fcc4fa946317bd01b85a854ac8cf5@haskell.org> #15497: Coercion Quantification -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5054 Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase2| -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 12:55:24 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 12:55:24 -0000 Subject: [GHC] #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory In-Reply-To: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> References: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> Message-ID: <063.9ac8993e2c50a435e56cf14df68bb0d3@haskell.org> #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: None | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by borsboom): On my system, where I was able to install ghc-8.6.1, the file seems to have been installed by Homebrew's [https://formulae.brew.sh/formula/gmp gmp formula]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 13:08:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 13:08:49 -0000 Subject: [GHC] #15648: Core Lint error with source-level unboxed equality In-Reply-To: <050.b1c8c377aa63cdac74b3d157d20320e2@haskell.org> References: <050.b1c8c377aa63cdac74b3d157d20320e2@haskell.org> Message-ID: <065.65222b674871bcb40b6e3f003332cff2@haskell.org> #15648: Core Lint error with source-level unboxed equality -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15209 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Richard asks why this typechecks: {{{ legitToJank :: LegitEquality a b -> JankyEquality a b legitToJank Legit = Jank }}} given that {{{ Jank :: $ueqT a b -> JankyEquality a b }}} Turns it it's because `tcSplitSigmaTy` ultimately uses `isPredTy` to decide which the invisible arguments are. And `isPredTy` has a special case to return `True` for `t1 ~# t2` and `t1 ~R# t2`. I'm not sure of the consequences of making `isPredTy` return `False` for `t1 ~# t2`. (E.g. it is used in `isEvVar`.) I'm a bit confused about what the Right Thing to do is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 13:09:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 13:09:39 -0000 Subject: [GHC] #15661: Nullary constraint in GHCi breaks `:t` command In-Reply-To: <045.4edb5a5e645d42b94af8bcdcf6c12464@haskell.org> References: <045.4edb5a5e645d42b94af8bcdcf6c12464@haskell.org> Message-ID: <060.2677a5b2d30f1b02d712c2d907064347@haskell.org> #15661: Nullary constraint in GHCi breaks `:t` command -------------------------------------+------------------------------------- Reporter: taktoa | 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: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This behaviour is just what you'd expect. Remember: `:type ` takes an ''arbitrary expression'' (not just a variable), finds its most general type, and shows that type. Here the expression happens to be just a single variable `x`. Fine, so we instantiate `x`, which gives rise to a "wanted" `(Show Foo)`. Then we attempt to solve and generalise, but `(Show Foo)` is not soluble. Hence the error. If you just want to see `x's` type, use `:info`, thus {{{ ghci> :info x x :: Show Foo => () -- Defined at :3:26 }}} I think everything seems fine here. But it clearly wasn't what you expected. Does my explanation help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 13:10:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 13:10:34 -0000 Subject: [GHC] #15685: Pattern signature not inferred In-Reply-To: <051.c5171c2fbdeaddb4c2ac22c9d434e0a0@haskell.org> References: <051.c5171c2fbdeaddb4c2ac22c9d434e0a0@haskell.org> Message-ID: <066.6c92f2b221d75dec681dbee2750cd237@haskell.org> #15685: Pattern signature not inferred -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK I see what is happening. * There really is an error in the pattern synonym (see below). * But instead of failing, we just added some constraints to solve "later", and continued. * "Continued" means that we did a `zonkTcTypeToType` (in `tc_patsyn_finish`) which defaulted a unification variable to `Any`. I'll fix that; essentially we should not attempt to continue if there are any unsolved constraints from this pattern synonym. The error is a classic GADT one. Here is a simpler example: {{{ data T a b where T1 :: (a~Int) => b -> T a b pattern TX <- T1 True }}} We start with an overall pattern type of `T alpha beta`. Then, under the pattern match of `T1` we need `beta ~ Bool`, and that fails with {{{ T15685.hs:21:17: error: * Couldn't match expected type `b' with actual type `Bool' `b' is untouchable inside the constraints: a ~ Int bound by a pattern with constructor: T1 :: forall a b. (a ~ Int) => b -> T a b, in a pattern synonym declaration at T15685.hs:21:14-20 `b' is a rigid type variable bound by the inferred type of TX :: T a b at T15685.hs:21:9-10 Possible fix: add a type signature for `TX' }}} And indeed if we add a signature {{{ pattern TX :: T a Bool -- or pattern TX :: () => (a~Int) => T a Bool }}} then all is well. The example in the ticket is more complicated, because the untouchable variable is a ''kind'' variable. So the error that is now reported (after fixing the `Any` stuff) is {{{ T15685.hs:17:25: error: * Kind mismatch: cannot unify (f :: k -> *) with: NP a0 :: [*] -> * Their kinds differ. Expected type: f a Actual type: NP a0 b0 * In the pattern: Nil In the pattern: Here Nil In the declaration for pattern synonym `HereNil' }}} There is actually ''another'', separate kind-level error, which says that `k ~ [*]` is insoluble, because `k` is untoucahble. But currently we suppress the kind-level error in favour of the type-level error. TL;DR: * You need a pattern signature. That's by-design. * But the `Any` business is bogus, and I'll fix that. * The same fix also gets rid of the confusing error about `f ~~ NP f0`. This was is also the result of "carrying on" too much; it comes from the 'builder' for `HereNil` which we should not even attempt to typecheck if there is an earlier error. * The remaining kind error is correct; but not a very good error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 13:28:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 13:28:21 -0000 Subject: [GHC] #15661: Nullary constraint in GHCi breaks `:t` command In-Reply-To: <045.4edb5a5e645d42b94af8bcdcf6c12464@haskell.org> References: <045.4edb5a5e645d42b94af8bcdcf6c12464@haskell.org> Message-ID: <060.8f86d210f34ce210c70c944a6be09bfd@haskell.org> #15661: Nullary constraint in GHCi breaks `:t` command -------------------------------------+------------------------------------- Reporter: taktoa | 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: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Alternatively, you can use `:type +v x`, which finds the type signature without solving and generalizing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 13:57:10 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 13:57:10 -0000 Subject: [GHC] #15648: Core Lint error with source-level unboxed equality In-Reply-To: <050.b1c8c377aa63cdac74b3d157d20320e2@haskell.org> References: <050.b1c8c377aa63cdac74b3d157d20320e2@haskell.org> Message-ID: <065.86d5b89981e865afc2eb11da6d170e7c@haskell.org> #15648: Core Lint error with source-level unboxed equality -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15209 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): `isPredTy` should almost certainly return `False` for `t1 ~# t2`. Code that wants to consider `t1 ~# t2` alongside other predicates can use `isPredTy ty || isConstraintType ty`. I think I made `isPredTy` recognize `t1 ~# t2` during the `-XTypeInType` implementation, but I don't think it's necessary anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 13:59:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 13:59:52 -0000 Subject: [GHC] #15648: Core Lint error with source-level unboxed equality In-Reply-To: <050.b1c8c377aa63cdac74b3d157d20320e2@haskell.org> References: <050.b1c8c377aa63cdac74b3d157d20320e2@haskell.org> Message-ID: <065.9e857dd08604004fadcec8bd6e8ddde8@haskell.org> #15648: Core Lint error with source-level unboxed equality -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15209 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > isPredTy should almost certainly return False for t1 ~# t2. That's a clear statement, and I think I agree -- but what argument(s) can you make to support that position. After all, `t1 ~# t2` certainly is a constraint (predicate). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 14:28:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 14:28:06 -0000 Subject: [GHC] #15648: Core Lint error with source-level unboxed equality In-Reply-To: <050.b1c8c377aa63cdac74b3d157d20320e2@haskell.org> References: <050.b1c8c377aa63cdac74b3d157d20320e2@haskell.org> Message-ID: <065.b58f9e94a1d5c784ef991f2c08b345af@haskell.org> #15648: Core Lint error with source-level unboxed equality -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15209 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): But it's not a constraint -- it's something else. Constraints are types of kind `Constraint`. Indeed, `isPredTy` should probably just check the kind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 14:44:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 14:44:47 -0000 Subject: [GHC] #15113: Do not make CAFs from literal strings In-Reply-To: <046.d042ad82da8658ea11bcd44bf2d86387@haskell.org> References: <046.d042ad82da8658ea11bcd44bf2d86387@haskell.org> Message-ID: <061.aa58615fac137e18bc892c66fec3f671@haskell.org> #15113: Do not make CAFs from literal strings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4717 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I managed to get nofib running. Here's an example output for runtime SRT traversals: {{{ NoFib Results -------------------------------------------------------------------------------- Program Size Allocs Runtime Elapsed TotalMem SRTScavs -------------------------------------------------------------------------------- ... circsim 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% clausify 0.0% 0.0% 0.013 0.013 0.0% 0.0% comp_lab_zift 0.0% 0.0% 0.068 0.068 0.0% 0.0% compress 0.0% 0.0% 0.054 0.054 0.0% 0.0% compress2 0.0% 0.0% 0.047 0.047 0.0% 0.0% constraints 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% ... Scavenged SRTs ------------------------------------------------------------------------------- Program nofib-log nofib-log ------------------------------------------------------------------------------- CS 627 0.0% CSD 622 0.0% FS 629 0.0% S 16363319 0.0% VS 2529 0.0% VSD 310 0.0% VSM 628 0.0% anna 7951 0.0% ansi 310 0.0% atom 2102 0.0% awards 310 0.0% ... }}} (all 0.0% becuase I used same file twice to run nofib-analyse) I have another program to parse compile-time numbers and generate this: {{{ PGM | SRTs | SRT size fluid | 5 | 25 wave4main | 25 | 112 integer | 17 | 74 ... }}} The code is here: https://github.com/osa1/nofib/tree/print_srt_stuff I also have a GHC branch that implements a new flag `-favoid- cafs=[0|1|2|3]` where 0 means compile as before, 1 means avoid making CAFs for top-level `unpackCString#`s, 2 means in addition to 1 avoid making CAFs for non-top-level `unpackCString#`s, 3 means in addition to 2 avoid making CAFs for CONLIKEs too. Code is here: https://github.com/osa1/ghc/tree/print_srt_stuff However for some reason the flag doesn't actually change number of SRTs or SRT sizes. I don't know why yet, I'll debug further. I think it may be because it's too late to change CAFFY-ness of values in CoreToStg (remember that CAFFY-enss of values are computed in CorePrep, which is before CoreToStg). I'll debug further. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 15:28:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 15:28:08 -0000 Subject: [GHC] #15663: T9675 inexplicably regressed in allocations due to text submodule bump In-Reply-To: <046.4bbf528148a8a5d4e7c394f0e92d23d3@haskell.org> References: <046.4bbf528148a8a5d4e7c394f0e92d23d3@haskell.org> Message-ID: <061.864092e4662d261816960ec26e3b81a4@haskell.org> #15663: T9675 inexplicably regressed in allocations due to text submodule bump -------------------------------------+------------------------------------- Reporter: bgamari | Owner: alpmestan 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): All I know is that [[https://phabricator.haskell.org/harbormaster/build/53314/|this Harbormaster build]] is the first failing build. This is all very confusing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 16:48:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 16:48:47 -0000 Subject: [GHC] #15637: Ambiguous type variables in GeneralisedNewtypeDeriving In-Reply-To: <047.85b8022e5c3b5dfb006bf88861742a5a@haskell.org> References: <047.85b8022e5c3b5dfb006bf88861742a5a@haskell.org> Message-ID: <062.015a4bdb6d621784c8b7b25afac405cc@haskell.org> #15637: Ambiguous type variables in GeneralisedNewtypeDeriving -------------------------------------+------------------------------------- Reporter: i-am-tom | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5148 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"309438e948359a0ae71ffac4a41ebcd855cf5657/ghc" 309438e9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="309438e948359a0ae71ffac4a41ebcd855cf5657" Fix #15637 by using VTA more in GND Summary: The code that GND was generating before could crumple over if it derived an instance for a class with an ambiguous type variable in the class head, such as the example in #15637. The solution is straightforward: simply instantiate all variables bound by the class head explicitly using visible type application, which will nip any ambiguity in the bud. Test Plan: make test TEST=T15637 Reviewers: bgamari, simonpj, goldfire Reviewed By: simonpj Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #15637 Differential Revision: https://phabricator.haskell.org/D5148 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 16:48:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 16:48:47 -0000 Subject: [GHC] #15591: Inconsistent kind variable binder visibility between associated and non-associated type families In-Reply-To: <050.8a27896ec689dcb3ecd15da9e935f56e@haskell.org> References: <050.8a27896ec689dcb3ecd15da9e935f56e@haskell.org> Message-ID: <065.64f909468c61336935bf1d4ce65f1db5@haskell.org> #15591: Inconsistent kind variable binder visibility between associated and non- associated type families -------------------------------------+------------------------------------- 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: #15592 | Differential Rev(s): Phab:D5159 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"a57fa24746421c0e13d0c09b72cbabea3622779f/ghc" a57fa247/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a57fa24746421c0e13d0c09b72cbabea3622779f" Quantify class variables first in associated families' kinds Summary: Previously, `kcLHsQTyVars` would always quantify class-bound variables invisibly in the kinds of associated types, resulting in #15591. We counteract this by explicitly passing the class-bound variables to `kcLHsQTyVars` and quantifying over the ones that are mentioned in the associated type such that (1) they are specified, and (2) they come before other kind variables. See `Note [Kind variable ordering for associated types]`. Test Plan: make test TEST=T15591 Reviewers: goldfire, simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15591 Differential Revision: https://phabricator.haskell.org/D5159 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 16:50:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 16:50:09 -0000 Subject: [GHC] #15637: Ambiguous type variables in GeneralisedNewtypeDeriving In-Reply-To: <047.85b8022e5c3b5dfb006bf88861742a5a@haskell.org> References: <047.85b8022e5c3b5dfb006bf88861742a5a@haskell.org> Message-ID: <062.dab9f1c6addcc75e199ba589440a05a2@haskell.org> #15637: Ambiguous type variables in GeneralisedNewtypeDeriving -------------------------------------+------------------------------------- Reporter: i-am-tom | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T15637 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5148 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => deriving/should_compile/T15637 * resolution: => fixed * milestone: 8.6.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 16:51:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 16:51:22 -0000 Subject: [GHC] #15591: Inconsistent kind variable binder visibility between associated and non-associated type families In-Reply-To: <050.8a27896ec689dcb3ecd15da9e935f56e@haskell.org> References: <050.8a27896ec689dcb3ecd15da9e935f56e@haskell.org> Message-ID: <065.9dbbf80cf68e5f01b3cdaa0741be1e6b@haskell.org> #15591: Inconsistent kind variable binder visibility between associated and non- associated type families -------------------------------------+------------------------------------- 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: | ghci/scripts/T15591 Blocked By: | Blocking: Related Tickets: #15592 | Differential Rev(s): Phab:D5159 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => ghci/scripts/T15591 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 16:59:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 16:59:58 -0000 Subject: [GHC] #14419: Check kinds for ambiguity In-Reply-To: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> References: <047.d18eb04be9d12ce25dfa15e5d81080b3@haskell.org> Message-ID: <062.d5bc95f0989a7c5b66d9273d2a0a378c@haskell.org> #14419: Check kinds for ambiguity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Simon, Ryan, and I had a confab about all this. We discovered several new insights: * The subkinding relationship is different than the subtyping relationship. Definition: `t1 <= t2` iff there exists a way to transform a `t1` into a `t2`. That is, there exists an expression of type `t2` with a `t1`-shaped hole. (Note that `tcSubType` and friends return an `HsWrapper`, which is precisely an expression with a hole in it.) In kinds, however, the expression language is different: it is the language of types, not terms. And, critically, there is no type-level lambda. Thus, the expression-with-a-hole is more limited, meaning fewer pairs of kinds are in the subkinding relationship. * To wit, the subkinding relationship has these rules: {{{ ----------- Refl t <= t t[t'/a] <= s ----------- Inst forall a. t <= s }}} And that's it. (The `t`s above might be polytypes.) This is in contrast to the traditional subtyping relationship (e.g. bottom of Fig. 5 from the [https://www.microsoft.com/en-us/research/wp- content/uploads/2016/02/putting.pdf Practical Type Inference] paper), which has rules for skolemization and contravariance of functions. * An ambiguity check is really a check to see whether a definition can be used unambiguously, without the need for visible type application. In terms, this notion is equivalent to a reflexive sub-type check. That is, `t` is unambiguous iff `t <= t`. However, this is ''not'' true in kinds. To wit, if `F` is a type family, then `forall a. F a -> Type` is a subkind of itself according to the relation above. We thus can't use a subkinding check to implement kind-level ambiguity. * The subkinding relation is implemented in `TcHsType.checkExpectedKind` and friends, which checks a type-checked type against an expected kind. We have two tasks: 1. Document `checkExpectedKind` and friends in light of the observation that they are computing a subkinding relation. This is a simpler way to understand those functions. 2. Write a kind-level ambiguity check. This check can simply look at a kind to ensure that all quantified kind variables appear under a sequence of injective type constructors. (That is, for each quantified variable, check that there exists a path from the root of the kind tree to an occurrence of the variable passing through only injective types.) I believe we had such a check for types, once upon a time, but removed it when Simon discovered the relationship between ambiguity and the subtyping relation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 17:26:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 17:26:20 -0000 Subject: [GHC] #11498: GHC requires kind-polymorphic signatures on class head In-Reply-To: <047.c869cb625243c8891f031146b4e58720@haskell.org> References: <047.c869cb625243c8891f031146b4e58720@haskell.org> Message-ID: <062.5a2ce593670cd9517fd1ac15599906e7@haskell.org> #11498: GHC requires kind-polymorphic signatures on class head -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2-rc2 checker) | Resolution: duplicate | Keywords: CUSKs Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #13365 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13365 Comment: OK, I now understand what is going on here. The fact that the second version of `C` doesn't typecheck in comment:2 is expected behavior. Once again, this all comes back to the fact that `C` doesn't have a complete user-specified kind (CUSK). As a result, the kind of `a` (in `class C a`) is chosen to be some fresh kind variable `k0`. When you try to declare a method of type `forall k. Proxy (a :: k) -> Proxy (b :: k)`, GHC complains because the kind `k` is bound in the method's type signature and //not// by the class (which binds `k0`), and thus `k` is not the same as `k0`. GHC perhaps ought to warn about the lack of a CUSK here, but that is the subject of #13365. Therefore, I'm opting to close this ticket and a duplicate of that one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 17:32:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 17:32:04 -0000 Subject: [GHC] #8226: Remove the old style -- # Haddock comments. In-Reply-To: <047.96b6209768296ad11c174e077e349059@haskell.org> References: <047.96b6209768296ad11c174e077e349059@haskell.org> Message-ID: <062.ae173ffa85fc2147ef8aa32b663cf670@haskell.org> #8226: Remove the old style -- # Haddock comments. -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: adinapoli Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * status: new => closed * resolution: => fixed Comment: This was fixed a couple years ago in 2f733b3a4b95a35dfdd43915afec9f0f615edacd. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 20:01:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 20:01:37 -0000 Subject: [GHC] #15671: Link errors due to forcibly exporting findPtr In-Reply-To: <044.6372bc7500582c14ea27cfe705ed9ef3@haskell.org> References: <044.6372bc7500582c14ea27cfe705ed9ef3@haskell.org> Message-ID: <059.0e80567f38089f4b9c0c9d159a048b8f@haskell.org> #15671: Link errors due to forcibly exporting findPtr -------------------------------------+------------------------------------- Reporter: Phyx- | 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: T10955dyn | T10955 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5138 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): @bgamari It's another thing DynamicWay hides. In that case the symbol is always just in the Rts Dynlib. But when not-rts way, the rts is always statically linked into any shared library. Such errors would be caught on Linux too if we decide to run the rts tests also in non-DynWay always. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 20:08:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 20:08:49 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.12613d474b2a3310e16c3ef51fc145fb@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Right, so just to summarize what JulianLeviston said in my words and give a concrete example, in this program: {{{ {-# LANGUAGE TemplateHaskell #-} module Lib where import Language.Haskell.TH foo :: Q Exp foo = [| 1e1000000 |] }}} we use the same problematic code path when parsing the quasi-quotation and end up calculating a huge `Integer` when parsing (which can be seen easily with `-ddump-parsed-ast`). This much is probably obvious if you're familiar with TH internals. This will be fixed when we update the parser. The actual problem is we desugar this quasi-quote to: {{{ foo = litE (rationalL (GHC.Real.:% @ Integer 1)) }}} where `litE` is simply `return . LitE` and `rationalL` is `RationalL`. `RationalL` takes a `Rational` argument, which is what we're trying to avoid doing in compile-time. Furthermore, because these are [http://hackage.haskell.org/package/template-haskell-2.13.0.0/docs /Language-Haskell-TH-Syntax.html#t:Lit public types] they are hard (if not impossible) to change. I see two options: - Do the computation when generating the TH quasi-quote expressions (during desugaring, in `DsMeta`). This way the TH syntax wouldn't change (we would generate exactly the same desugared expr for this program), and the example above would take forever to compile. - Add one more literal constructor to TH syntax that looks like our new `FractionalLit` for this purpose. Then we could use our new desugaring (comment:23) in `Convert.hs` when we actually splice the expression. So both quasi-quote compilation and splicing remain fast. Any thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 1 21:18:51 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Oct 2018 21:18:51 -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.761dd4e14c24442fd644066d4b4331a7@haskell.org> #12146: syntax repair suggestion is too eager to suggest TemplateHaskell -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | 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: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 03:17:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 03:17:03 -0000 Subject: [GHC] #15617: Unboxed tuples/sum error message on `a = show 5` in expression evaluation and interactive modes In-Reply-To: <047.252f036686da3cb5c2c5a5709f59083c@haskell.org> References: <047.252f036686da3cb5c2c5a5709f59083c@haskell.org> Message-ID: <062.45f8341ca9336930f180f265d5a32756@haskell.org> #15617: Unboxed tuples/sum error message on `a = show 5` in expression evaluation and interactive modes -------------------------------------+------------------------------------- Reporter: ChaiTRex | Owner: | JulianLeviston 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: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): I'm leaving this here for myself as WIP notes for later. Execution path: 1. ghc/Main.hs main function 1. (mode, argv3, flagWarnings) <- parseModeFlags argv2 1. case mode of ... Right postStartupMode -> 1. case postStartupMode of -> 1. Right postLoadMode -> main' postLoadMode dflags argv3 flagWarnings 1. this hits the main' function after getting a postLoadMode of DoInteractive or DoEval 1. this is the meat, where we're pulling apart the flags then throwing them at ghciUI which calls interactiveUI defaultGhciSettings for both cases 1. This function comes from GHCi.UI -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 03:18:55 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 03:18:55 -0000 Subject: [GHC] #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory In-Reply-To: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> References: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> Message-ID: <063.f1db65d989d94907349d403b660d8bf7@haskell.org> #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: None | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.8.1 => 8.6.1 Comment: Hmm, oh dear. It looks like I overlooked this while bumping tickets to 8.8. This should indeed be fixed. It is likely fall-out from the recent switch to CI-based binary distribution builds. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 06:50:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 06:50:26 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect Message-ID: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Sometimes. Here is the thread that explains the bug: https://github.com/haskell/containers/issues/568 I originally reported this as a bug on `containers` issue tracker, but we seem to have concluded that this is probably a bug in the GHC optimizer itself. I think the shortest repro so far is this: {{{#!hs import qualified Data.Set as S main = print $ let {-# noinline f #-} f () = T2 in S.fromList [f (), f ()] data T = T1 | T2 | T3 | T4 | T5 | T6 | T7 | T8 | T9 deriving (Show, Read, Eq, Ord, Bounded, Enum) }}} which prints {{{#!hs fromList [T2,T2] }}} The person who derived this from my original repro says: > And as I said earlier, comment out the T9 constructor => prints fromList [T2] as it should. Another interesting quote: > Can confirm. Tested with ghc-8.6.1, containers-0.6.0.1 and leancheck-0.7.5 (so it does not seem to depend on the testing framework). Error occurs: > > * with ghc -O1 and -O2 (but not with -O0) > * and if data type has at least 9 elements > > So, likely a bug in ghc's optimizer. > > in some cases, input has duplicates, but not always. This is a bad one, makes GHC 8.6.1 totally unusable for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 07:07:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 07:07:35 -0000 Subject: [GHC] #14475: Upload documentation dumps In-Reply-To: <046.875271090aacfb7d8f31943e1b69bd4b@haskell.org> References: <046.875271090aacfb7d8f31943e1b69bd4b@haskell.org> Message-ID: <061.5433f7b12ac822bee7d32888d28534a3@haskell.org> #14475: Upload documentation dumps -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gander Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gander): Sorry, am caught napping on this. Just noticed an email request to upload the latest documents. So, can I do this manually,for now? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 08:53:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 08:53:31 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.30bc124e06096c0cccf97811c0dc1ee7@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dfeuer): * priority: normal => highest * cc: dfeuer (added) * failure: None/Unknown => Incorrect result at runtime -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 09:04:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 09:04:29 -0000 Subject: [GHC] #14758: Retainer profiler can overflow the C stack In-Reply-To: <046.e63d54b73cd1d189e95bd3a35572589a@haskell.org> References: <046.e63d54b73cd1d189e95bd3a35572589a@haskell.org> Message-ID: <061.71fe9d782fdcc472ee7b9c4cac64887d@haskell.org> #14758: Retainer profiler can overflow the C stack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.6.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15287 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * priority: high => normal * keywords: => newcomer * version: 8.4.1-alpha1 => 8.6.1 Comment: Just a status update: we discussed this a few weeks ago in a meeting. This is easy to fix, just replace recursive calls to `retainClosure` (directly or indirectly via `retainStack`) with stack pushes. For this we need to add new stack element types handle those in `retainClosure` (which is where we pop the stack). Not too hard to do. In the end we weren't sure that retainer profiler is too useful in practice, so we did not prioritize this (I'm updating the ticket priority now to reflect this). If you're using retainer profiler for anything useful and suffering from this bug, let us know. Also, this seems like a great newcomer ticket to me. The changes are only in one file (`RetainerProfile.c`) and you only need to know GHC heap object layout and some C. If anyone's interested in working on this let me know and I can give more detailed instructions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 09:04:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 09:04:47 -0000 Subject: [GHC] #14758: Retainer profiler can overflow the C stack In-Reply-To: <046.e63d54b73cd1d189e95bd3a35572589a@haskell.org> References: <046.e63d54b73cd1d189e95bd3a35572589a@haskell.org> Message-ID: <061.36736a4ddace991473279e68a5e3ea0d@haskell.org> #14758: Retainer profiler can overflow the C stack -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.6.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15287 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 09:05:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 09:05:17 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.814bac81829c2c378bb5cfbb66d0b6e4@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That's terrible! The following all produce the same (wrong) restul {{{ S.fromList (map f [ () | _ <- [1..10] ]) -- T2,T2 S.fromList [f (), f ()] -- T2,T2 S.fromList [f (), f (), f()] -- T2,T2 }}} However this works fine {{{ f () `S.insert` (f () `S.insert` S.empty) }}} The comparison operations generated by `deriving` look ok to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 09:09:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 09:09:31 -0000 Subject: [GHC] #15697: Typed holes inferring a more polymorphic type Message-ID: <048.345bb247cde0795438cac611fa5cc658@haskell.org> #15697: Typed holes inferring a more polymorphic type -------------------------------------+------------------------------------- Reporter: sreenidhi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider these two snippets. {{{#!hs testFailure :: Char testFailure = let x = id _ in x }}} Suggestions provided were {{{ /home/sreenidhi/Experiments/TypedHole.hs:3:14: error: • Found hole: _ :: a Where: ‘a’ is a rigid type variable bound by the inferred type of x :: a at /home/sreenidhi/Experiments/TypedHole.hs:3:7-14 • In the first argument of ‘id’, namely ‘_’ In the expression: id _ In an equation for ‘x’: x = id _ • Relevant bindings include x :: a (bound at /home/sreenidhi/Experiments/TypedHole.hs:3:7) testFailure :: Char (bound at /home/sreenidhi/Experiments/TypedHole.hs:2:1) }}} whereas for this one {{{#!hs testSuccess :: Char testSuccess = _ }}} It correctly suggests {{{ /home/sreenidhi/Experiments/TypedHole.hs:7:15: error: • Found hole: _ :: Char • In the expression: _ In an equation for ‘testSuccess’: testSuccess = _ • Relevant bindings include testSuccess :: Char (bound at /home/sreenidhi/Experiments/TypedHole.hs:7:1) Valid hole fits include testSuccess :: Char (bound at /home/sreenidhi/Experiments/TypedHole.hs:7:1) testFailure :: Char (defined at /home/sreenidhi/Experiments/TypedHole.hs:2:1) maxBound :: forall a. Bounded a => a with maxBound @Char (imported from ‘Prelude’ at /home/sreenidhi/Experiments/TypedHole.hs:1:1 (and originally defined in ‘GHC.Enum’)) minBound :: forall a. Bounded a => a with minBound @Char (imported from ‘Prelude’ at /home/sreenidhi/Experiments/TypedHole.hs:1:1 (and originally defined in ‘GHC.Enum’)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 09:09:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 09:09:41 -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.a2aa9f6815e9a9e8c7f91fa482b7deb7@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 osa1): * cc: osa1 (added) Comment: I'm confused about comment:3. On Linux, with gdb, when I get a segfault because of stack overflow and run `bt` I get thousands of stack frames, not just 3. Why do we get only 3 frames if this is a stack overflow? Is this because of calling conventions on darwin? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 09:10:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 09:10:18 -0000 Subject: [GHC] #15697: Typed holes inferring a more polymorphic type In-Reply-To: <048.345bb247cde0795438cac611fa5cc658@haskell.org> References: <048.345bb247cde0795438cac611fa5cc658@haskell.org> Message-ID: <063.789a657f718efeced6f575e8fbc5857a@haskell.org> #15697: Typed holes inferring a more polymorphic type -------------------------------------+------------------------------------- Reporter: sreenidhi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sreenidhi): * Attachment "TypedHole.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 09:32:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 09:32:36 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.e249cdedc8cd0f7d5ca76c5535e55e01@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: bgamari, osa1 Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #15630 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): I went wild on the debug logging when compiling bad.hs, with GHC HEAD and the patch from comment:24 in place. One thing that sticks out is that at some point, total Core size goes from about 7,700 to 685,000: {{{ Result size of Simplifier iteration=4 = {terms: 7,759, types: 9,295, coercions: 847, joins: 9/84} Result size of Simplifier = {terms: 7,759, types: 9,295, coercions: 847, joins: 9/84} !!! Simplifier [Main]: finished in 1123.65 milliseconds, allocated 1251.533 megabytes *** SpecConstr [Main]: Result size of SpecConstr = {terms: 685,052, types: 613,224, coercions: 22,309, joins: 1,571/11,551} }}} Subsequent simplifier runs bring this down to 70,000 eventually, and then it jumps up to 96,000 again at the CorePrep stage, but it never goes back down to anywhere near those 7,000. If, however we enable the `{-#NOINLINE#-}` pragma on `mhelper`, then that same SpecConstr step maintains Core size exactly (suggesting that it doesn't do anything at all). `mhelper` is ` :: MonadIO m => ...`; if we inline it, then `m` can be specialized to `Handler`, which is a synonym for `ReaderT () IO`. I don't know why this particular specialization blows up right there and then, but that's what I've figured so far. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 09:49:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 09:49:19 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.72685f3f5bfadba45ecac3b7af54bfc3@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) Comment: The problem is in this Core generated for this program: {{{ -- RHS size: {terms: 5, types: 2, coercions: 0, joins: 0/0} f_r6li f_r6li = \ ds_d3M6 -> case ds_d3M6 of { () -> T2 } -- RHS size: {terms: 2, types: 0, coercions: 0, joins: 0/0} lvl_r6lj lvl_r6lj = f_r6li () main2 main2 = case dataToTag# lvl_r6lj of a#_a2rY { __DEFAULT -> case dataToTag# lvl_r6lj of b#_a2rZ { __DEFAULT -> ... }}} We get the tag of a CAF (`lvl_r6lj`) before evaluating it, so we get tag of a thunk. The need for evaluating argument of `dataToTag#` is explained in `Note [dataToTag#]` in primops.txt.pp. It seems like we're inlining `getTag`, and then somehow eliminating the case expression in `getTag` (to evaluate its argument). If I change the `INLINE` annotation of `getTag` to `NOINLINE` this works as expected. I don't know why we're elminating the `case` in `getTag` after inlining it yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 10:02:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 10:02:54 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.2f0e650f99f2851d09e809149a0266f8@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Ah, so it turns out we have a special case in CorePrep (which runs after simplifications) about `dataToTag#`, and we generate a case expression around its argument after all the simplifications. It's explained in `Note [dataToTag magic]` in CorePrep, and I can see in STG that it works as expected: {{{ lvl_r6ru = \u [] f_r6rt (); lvl1_r6rv = CCS_DONT_CARE :! [lvl_r6ru []]; main2 = \u [] case case lvl_r6ru of sat_s6xD { __DEFAULT -> dataToTag# [sat_s6xD]; } of a#_s6xE { __DEFAULT -> case case lvl_r6ru of sat_s6xF { __DEFAULT -> dataToTag# [sat_s6xF]; } of ... }}} So perhaps this is not because we get tag of a thunk. I don't know why not inlining `getTag` fixes this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 10:22:55 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 10:22:55 -0000 Subject: [GHC] #15697: Typed holes inferring a more polymorphic type In-Reply-To: <048.345bb247cde0795438cac611fa5cc658@haskell.org> References: <048.345bb247cde0795438cac611fa5cc658@haskell.org> Message-ID: <063.d0fa430d64dc092aa3c2a98765a7345e@haskell.org> #15697: Typed holes inferring a more polymorphic type -------------------------------------+------------------------------------- Reporter: sreenidhi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypedHoles Operating System: 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: => TypedHoles * cc: Tritlo (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 11:38:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 11:38:38 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.d77502b437e5466982f2732ad4ca2c12@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: bgamari, osa1 Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #15630 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): On further investigation, the `MonadIO` constraint is not the one that makes the specializer blow up; removing the `MonadIO` constraints and changing `Handler` to `type Handler = IO` retains the blowup. Which leaves us with the `Semigroup`, `Monoid`, `Functor`, `Applicative` and `Monad` instances for `FormResult`. So I implemented non-polymorphic `formMap` and `formAp` to replace `fmap` and `<*>`, and used `FormSuccess` directly instead of `pure`, allowing me to delete the `Functor` and `Applicative` instances for `FormResult`. Things still blow up in the `SpecConst` step, until I add a `NOINLINE formMap` pragma - and suddenly everything is "fine". Interestingly, changing the `Monoid` and `Semigroup` instances such that all methods are implemented in a pathologically trivial way (`mappend x y = FormMissing`, etc.) doesn't make things faster, so it's not that specializing on either of those is the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 12:15:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 12:15:56 -0000 Subject: [GHC] #15698: SingleEntry update flag for Stg bindings is not used Message-ID: <043.d776803be041dc275cbbbd639883a34b@haskell.org> #15698: SingleEntry update flag for Stg bindings is not used -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was looking at code generation for bindings with different update flags. Update flag type is defined as: {{{ data UpdateFlag = ReEntrant | Updatable | SingleEntry }}} I realized that we don't care about the difference between `ReEntrant` and `SingleEntry`, we only care about whether a binding is updatable or not, which is defined as {{{ isUpdatable :: UpdateFlag -> Bool isUpdatable ReEntrant = False isUpdatable SingleEntry = False isUpdatable Updatable = True }}} So we could remove `SingleEntry` and replace all uses of it with `ReEntrant` and everything would work the same. This raises the question of whether we're missing an optimisation in the code generator. Looking at code generation differences of updatable and non-updatable bindings, it seems like for a thunk (a binding with no arguments) we generate a thunk header and push an update frame regardless of the update flag. As far as I can see, update flag is only used when generating AP and selector thunks (we don't generate AP or selector thunks if the binding is not updatable). My question is: it seems to me that if a thunk is single entry then we should be able to give it a non-thunk type (maybe FUN?) and avoid pushing an update frame in `closureCodeBody`. Am I missing anything or is this possible? Is this worth trying? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 12:22:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 12:22:37 -0000 Subject: [GHC] #10793: Incorrect blocked on MVar detection In-Reply-To: <051.7658851bb71506c4b1bae1ee7211ff06@haskell.org> References: <051.7658851bb71506c4b1bae1ee7211ff06@haskell.org> Message-ID: <066.d609d30de89653394d9301e082388420@haskell.org> #10793: Incorrect blocked on MVar detection -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10241 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => closed * resolution: => duplicate Comment: Having read the ticket description again, I think this describes exactly the same problem as #10241 (multiple threads blocked, unblocking one unblocks others, but instead all of them are considered unblockable). Please re-open if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 12:27:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 12:27:13 -0000 Subject: [GHC] #2940: Do CSE after CorePrep In-Reply-To: <046.ba154de3cf0c400fb0723e1948282304@haskell.org> References: <046.ba154de3cf0c400fb0723e1948282304@haskell.org> Message-ID: <061.d27279c17416c9f475788b4efa988777@haskell.org> #2940: Do CSE after CorePrep -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.10.1 Resolution: fixed | Keywords: CSE Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9291 | Differential Rev(s): Phab:D2871 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => closed * differential: => Phab:D2871 * resolution: => fixed * related: => #9291 Comment: We now do CSE after CorePrep (in STG). Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 12:37:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 12:37:27 -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.13ba7cf1f0a2c8212be76162da04be04@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: | -------------------------------------+------------------------------------- Comment (by osa1): The problem is `-with-rtsopts` is really dumb, it just puts whatever you pass to it in a file which is linked with the program to provide the options to the RTS. It does not do any checks on the input. For example, `-with-rtsopts=-blah-blah` is also accepted. Ideally I guess the compiler would have access to RTS argument parsers for all RTS variants, and check with the parser of the correct RTS variant (e.g. when building prof+debug way it would use the prof+debug runtime's parser). It seems like too much work and it's not clear whether the added complexity (for having access to RTS parsers in the compiler) would worth it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 12:48:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 12:48:29 -0000 Subject: [GHC] #15697: Typed holes inferring a more polymorphic type In-Reply-To: <048.345bb247cde0795438cac611fa5cc658@haskell.org> References: <048.345bb247cde0795438cac611fa5cc658@haskell.org> Message-ID: <063.74d940900eedfbd13eed0fa079d7aa21@haskell.org> #15697: Typed holes inferring a more polymorphic type -------------------------------------+------------------------------------- Reporter: sreenidhi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): So, the suggestions here are correct (based on the type), but why is it not inferring that `x` is of type char? It doesn't even look like it is inferring that `a` must end up being Char. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 12:59:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 12:59:45 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.dc4655c6744e958bfcb2aeea2226baec@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: bgamari, osa1 Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #15630 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): I've managed to simplify it further: {{{#!haskell module LessBad where import Data.ByteString (ByteString) import qualified Data.ByteString.Char8 as Char8 data HugeStruct = HugeStruct !ByteString !ByteString !ByteString !ByteString !ByteString !ByteString !ByteString !ByteString !ByteString -- 9th data FormResult a = FormMissing | FormFailure [ByteString] | FormSuccess a deriving Show formMap _ FormMissing = FormMissing formMap _ (FormFailure errs) = FormFailure errs formMap f (FormSuccess a) = FormSuccess $ f a infixl 4 `formMap` formAp :: FormResult (a -> b) -> FormResult a -> FormResult b (FormSuccess f) `formAp` (FormSuccess g) = FormSuccess $ f g (FormFailure x) `formAp` (FormFailure y) = FormFailure $ x ++ y (FormFailure x) `formAp` _ = FormFailure x _ `formAp` (FormFailure y) = FormFailure y _ `formAp` _ = FormMissing infixl 4 `formAp` mreq :: String -> IO (FormResult ByteString, ()) mreq v = mhelper v (\m l -> FormFailure [Char8.pack "fail"]) FormSuccess askParams :: IO (Maybe [(String, ByteString)]) askParams = do return $ Just [] mhelper :: String -> (() -> () -> FormResult b) -- on missing -> (ByteString -> FormResult b) -- on success -> IO (FormResult b, ()) mhelper v onMissing onFound = do mp <- askParams (res, x) <- case mp of Nothing -> return (FormMissing, ()) Just p -> do return $ case lookup v p of Nothing -> (onMissing () (), ()) Just t -> (onFound t, ()) return (res, x) -- Either of these fixes the blowup -- {-# NOINLINE mreq #-} -- {-# NOINLINE mhelper #-} -- {-# NOINLINE formMap #-} sampleForm2 :: IO (FormResult HugeStruct) sampleForm2 = do (x01, _) <- mreq "UNUSED" (x02, _) <- mreq "UNUSED" (x03, _) <- mreq "UNUSED" (x04, _) <- mreq "UNUSED" (x05, _) <- mreq "UNUSED" (x06, _) <- mreq "UNUSED" (x07, _) <- mreq "UNUSED" (x08, _) <- mreq "UNUSED" (x09, _) <- mreq "UNUSED" let hugeStructRes = HugeStruct `formMap` x01 `formAp` x02 `formAp` x03 `formAp` x04 `formAp` x05 `formAp` x06 `formAp` x07 `formAp` x08 `formAp` x09 return hugeStructRes }}} There are hardly any constraints left to specialize here, except the `Monad` instance for `IO`. And indeed, changing all those `IO` into `Monad m => m` gets compilation times down from almost a minute to under one second. So for some reason, specializing the monadic binds and / or returns for `IO` here increases code size by a factor of almost 50: {{{ Result size of Simplifier = {terms: 6,615, types: 5,827, coercions: 39, joins: 8/70} !!! Simplifier [LessBad]: finished in 950.46 milliseconds, allocated 1067.498 megabytes *** SpecConstr [LessBad]: Result size of SpecConstr = {terms: 286,335, types: 251,655, coercions: 39, joins: 960/5,435} !!! SpecConstr [LessBad]: finished in 10107.67 milliseconds, allocated 10077.732 megabytes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 13:51:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 13:51:53 -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.a6c4244aa3d26bb923309524206e6c1f@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): Phab:D5190 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * differential: => Phab:D5190 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 14:00:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 14:00:37 -0000 Subject: [GHC] #13704: -main-is flag should change exports in default module header In-Reply-To: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> References: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> Message-ID: <061.3768c8320ff1cdcc049c68ea368ae62c@haskell.org> #13704: -main-is flag should change exports in default module header -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"abfb91fb0ea27eb618f297b1d3ba60cfa021afe0/ghc" abfb91fb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="abfb91fb0ea27eb618f297b1d3ba60cfa021afe0" resolve T13704 Summary: allow -main-is to change export list for default module header, allowing one to change the entry point to one's program. Test Plan: ./validate Reviewers: bgamari, nomeata, mpickering Reviewed By: mpickering Subscribers: mpickering, rwbarton, carter GHC Trac Issues: #13704 Differential Revision: https://phabricator.haskell.org/D5189 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 14:00:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 14:00:37 -0000 Subject: [GHC] #12005: Constraint instances not shown in `:info` In-Reply-To: <051.e0728f3c0e56a4361f8b5139b7d323c2@haskell.org> References: <051.e0728f3c0e56a4361f8b5139b7d323c2@haskell.org> Message-ID: <066.622f31648e42f584f51ec24ae8a40b39@haskell.org> #12005: Constraint instances not shown in `:info` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5182 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"21efbc7599e39ec93b8b13b7d7b84811226e6f6f/ghc" 21efbc75/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="21efbc7599e39ec93b8b13b7d7b84811226e6f6f" GHCi should not filter instances involving cTuples Summary: See the new T12005 test case for an example of this. Test Plan: make TEST=T12005 Reviewers: bgamari, osa1 Reviewed By: osa1 Subscribers: osa1, rwbarton, carter GHC Trac Issues: #12005 Differential Revision: https://phabricator.haskell.org/D5182 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 14:02:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 14:02:03 -0000 Subject: [GHC] #12005: Constraint instances not shown in `:info` In-Reply-To: <051.e0728f3c0e56a4361f8b5139b7d323c2@haskell.org> References: <051.e0728f3c0e56a4361f8b5139b7d323c2@haskell.org> Message-ID: <066.e7f266f82ed750972461acf88f7fa9cc@haskell.org> #12005: Constraint instances not shown in `:info` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5182 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 14:03:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 14:03:09 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.fad3cb7a5d0e5dbb3bd3b388713eb379@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by j.waldmann): * cc: j.waldmann (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 14:03:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 14:03:53 -0000 Subject: [GHC] #13704: -main-is flag should change exports in default module header In-Reply-To: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> References: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> Message-ID: <061.b366bcc37e401ccaa4cf6916e9b8eeea@haskell.org> #13704: -main-is flag should change exports in default module header -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: (none) Type: feature request | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 14:24:55 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 14:24:55 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.f382bb0a618bbb453edd6e1eb1eefe2e@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Here's an example which doesn't depend on any code from `containers`. It also makes the derived `Ord` code explicit: {{{#!hs {-# LANGUAGE MagicHash #-} module Main where import qualified Data.Foldable as Foldable import GHC.Exts (dataToTag#, tagToEnum#, (==#), (<#)) main :: IO () main | not_ordered a b = print $ Foldable.foldl' (flip wumbo) (singleton a) b | otherwise = pure () where {-# NOINLINE f #-} f () = T2 {-# NOINLINE a #-} a = f () {-# NOINLINE b #-} b = [f ()] data T = T1 | T2 | T3 | T4 | T5 | T6 | T7 | T8 | T9 deriving (Eq, Show) instance Ord Main.T where compare a b = case dataToTag# a of a' -> case dataToTag# b of b' -> if tagToEnum# (a' <# b') :: Bool then LT else if tagToEnum# (a' ==# b') :: Bool then EQ else GT data Set a = Bin !a !(Set a) !(Set a) | Tip deriving Show not_ordered :: Ord a => a -> [a] -> Bool not_ordered _ [] = False not_ordered x (y : _) = x >= y wumbo :: Ord a => a -> Set a -> Set a wumbo x0 = go x0 x0 where go :: Ord a => a -> a -> Set a -> Set a go orig _ Tip = singleton orig go orig x t@(Bin y l r) = case compare x y of LT -> error "not used here" GT -> Bin y l (go orig x r) EQ -> t {-# INLINE wumbo #-} singleton :: a -> Set a singleton x = Bin x Tip Tip }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 14:43:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 14:43:38 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.26470121cb86bb31d3564af0b6a71c2f@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That's really helpful Ryan, thank you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 14:45:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 14:45:34 -0000 Subject: [GHC] #15697: Typed holes inferring a more polymorphic type In-Reply-To: <048.345bb247cde0795438cac611fa5cc658@haskell.org> References: <048.345bb247cde0795438cac611fa5cc658@haskell.org> Message-ID: <063.807ee174679236bc9b7c9f8a54bb9858@haskell.org> #15697: Typed holes inferring a more polymorphic type -------------------------------------+------------------------------------- Reporter: sreenidhi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ulysses4ever): * cc: ulysses4ever (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 14:47:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 14:47:27 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.2e2131f78067c07ac8dc1ffa9f812ad6@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: | Phab:D5141, Phab:D5147, Phab:D5150 -------------------------------------+------------------------------------- Comment (by simonpj): Richard, any progress on this? We are keen to nail it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 14:51:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 14:51:57 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.7db0b7f6a69ad951aa5d0d71515945ba@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: | Phab:D5141, Phab:D5147, Phab:D5150 -------------------------------------+------------------------------------- Comment (by simonpj): Tobias will nail Step 1 and commit it. Then over to Richard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 15:04:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 15:04:17 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.00c4136d6fa7666a411bb24c5d7a883c@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Apologies, I meant to mention in comment:6 what `wumbo` actually is: it's a stripped down version of `insert` intended to highlight that it appears to behave differently between GHC 8.4.3 and 8.6.1. The semantics of `wumbo` differs from that of `insert`, but here is the important bit: {{{ $ /opt/ghc/8.4.3/bin/ghc -O2 -fforce-recomp Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... Bin T2 Tip Tip $ /opt/ghc/8.6.1/bin/ghc -O2 -fforce-recomp Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... Bin T2 Tip (Bin T2 Tip Tip) }}} GHC 8.4.3's answer is definitely the correct one, since the only way you'd get 8.6.1's answer is by hitting the `GT` case of `wumbo` (which shouldn't happen if you're comparing `T2` to `T2`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 15:06:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 15:06:20 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.8ce21ebacd6a3c765e10fd7474a77b4b@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): I'm minimizing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 15:10:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 15:10:06 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.5af420cc537d2b300ce85588cbe8813f@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: bgamari, osa1 Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #15630 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Just to verify that `SpecConstr` is indeed to blame, I did a run with `-O1` instead of `-O2`; no blowup happens then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 15:23:15 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 15:23:15 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.87c1f3e1de81bf0408bdb1be0d3c24a1@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.6.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 15:23:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 15:23:59 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.937d17a86a487a2f837111417233fbd6@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.6.2 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: | Phab:D5141, Phab:D5147, Phab:D5150 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.8.1 => 8.6.2 Comment: It would be great if we could get this into a shape where it could be merged to 8.6.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 15:38:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 15:38:44 -0000 Subject: [GHC] #15697: Typed holes inferring a more polymorphic type In-Reply-To: <048.345bb247cde0795438cac611fa5cc658@haskell.org> References: <048.345bb247cde0795438cac611fa5cc658@haskell.org> Message-ID: <063.94bbcb391ef7bfb4cb94eaaf89c39ffc@haskell.org> #15697: Typed holes inferring a more polymorphic type -------------------------------------+------------------------------------- Reporter: sreenidhi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypedHoles Operating System: 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 suppose the correct behavior here depends on whether or not you want valid hole fit suggestions to suggest the most general type of local definitions or not. Consider the following modified example: {{{#!hs testFailure :: Char testFailure = let x :: _ x = id in x 'a' }}} You might think that the reported type of the hole would be `Char -> Char`, but it's actually `forall a. a -> a`. Indeed, `forall a. a -> a` is the most general type that you can give `x`, so from a certain perspective, it's the most "correct" answer. But perhaps it's not the one you'd desire. One idea would be to allow tweaking the generalization behavior for local definitions //à la// `MonoLocalBinds`. For instance, in the following example: {{{#!hs testFailure2 :: Bool -> (Bool, Char) testFailure2 x = let f y = (x, y) in f 'a' }}} If `MonoLocalBinds` isn't enabled, then the inferred type of `f` will be `forall b. b -> (Bool, b)`. But if `MonoLocalBinds` //is// enabled, then the inferred type of `f` will be `Char -> (Bool, Char)`. I imagine we could allow valid hole fits to tweak generalization in a similar fashion (whether generalizing should be the default here or not is unclear to me). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 15:39:40 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 15:39:40 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.78dc6f8a6525b6ef150ede058b400fe4@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Didn't we just recently start using some pointer tagging for types with more than 7 constructors? I'm thinking something could be a drop off in that code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 15:45:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 15:45:02 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.3d8674cdfbf7f9702f3a5e61c63506e2@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): Here's a smaller version. `ghc T15696 && ./T15696` prints `EQ` correctly, `ghc -O T15696 && ./T15696` prints `LT`. {{{ #!hs {-# LANGUAGE MagicHash #-} module Main where import GHC.Exts (dataToTag#, tagToEnum#, (==#), (<#)) main :: IO () main = print $ compare a T2 where {-# NOINLINE f #-} f = T2 {-# NOINLINE a #-} a = f data T = T1 | T2 | T3 | T4 | T5 | T6 | T7 | T8 | T9 deriving (Eq, Show, Ord) {- instance Ord Main.T where compare a b = case dataToTag# a of a' -> case dataToTag# b of b' -> if tagToEnum# (a' <# b') :: Bool then LT else if tagToEnum# (a' ==# b') :: Bool then EQ else GT -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 15:55:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 15:55:09 -0000 Subject: [GHC] #15697: Typed holes inferring a more polymorphic type In-Reply-To: <048.345bb247cde0795438cac611fa5cc658@haskell.org> References: <048.345bb247cde0795438cac611fa5cc658@haskell.org> Message-ID: <063.fe3de12004c008247cca5be4df966b43@haskell.org> #15697: Typed holes inferring a more polymorphic type -------------------------------------+------------------------------------- Reporter: sreenidhi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sreenidhi): I fully agree with your analysis about `testFailure` - for example I might want to write {{{#!hs test1 :: Char test1 = let x :: _ -- now x really has to be forall a. a -> a x = id in const (x 'c') (x 5) }}} But consider the following {{{#!hs test2 :: Char test2 = let x :: _ -- error: Found type wildcard ‘_’ standing for ‘Char’ x = id 'c' in x test3 :: Char test3 = let x = id _ -- error: Found hole: _ :: a in x }}} Isn't it expected that the two errors to point to the same type? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 16:00:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 16:00:29 -0000 Subject: [GHC] #15697: Typed holes inferring a more polymorphic type In-Reply-To: <048.345bb247cde0795438cac611fa5cc658@haskell.org> References: <048.345bb247cde0795438cac611fa5cc658@haskell.org> Message-ID: <063.567d555bb0e9e0501672eb26eca769d4@haskell.org> #15697: Typed holes inferring a more polymorphic type -------------------------------------+------------------------------------- Reporter: sreenidhi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:5 sreenidhi]: > Isn't it expected that the two errors to point to the same type? Again, that depends on whether you're generalizing or not. If you're generalizing, then `forall a. a` is what you'd expect as the type of that hole. (You could fill it with, say, `undefined` or `let y = y in y`.) If you're not generalizing, then `Char` would be what you would expect. The bottom line is that we have a design choice here—there are situations where one behavior might be preferable over the other. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 16:07:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 16:07:19 -0000 Subject: [GHC] #15697: Typed holes inferring a more polymorphic type In-Reply-To: <048.345bb247cde0795438cac611fa5cc658@haskell.org> References: <048.345bb247cde0795438cac611fa5cc658@haskell.org> Message-ID: <063.1efa47b2c97b33e07c199a9552b92fc2@haskell.org> #15697: Typed holes inferring a more polymorphic type -------------------------------------+------------------------------------- Reporter: sreenidhi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tritlo): Thanks for breaking it down, Ryan. I think this would be covered by what I call "more specific fits", like I touched on (i.e. suggesting `pi :: Floating a => a` for `_ :: Fractional a => a`). In those fits, we could also include fits that would be suggested if `MonoLocalBinds` were enabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 16:14:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 16:14:56 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.5e3a7382235a9f200c8345a9f9b114a7@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Avoiding the use of type classes: {{{ main :: IO () main = print $ cmpT a T2 where {-# NOINLINE f #-} f = T2 {-# NOINLINE a #-} a = f data T = T1 | T2 | T3 | T4 | T5 | T6 | T7 | T8 | T9 -- deriving (Eq, Show, Ord) cmpT a b = case dataToTag# a of a' -> case dataToTag# b of b' -> if tagToEnum# (a' <# b') :: Bool then LT else if tagToEnum# (a' ==# b') :: Bool then EQ else GT }}} With `-O` we get `LT` for GHC 8.4 and 8.2 and earlier versions. Without `-O` it returns `EQ` as it should. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 16:17:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 16:17:34 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.a6649769bfe573b0a2dd92ba1def94fd@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Omer, might you look at this. With `-ddump-stg` I see {{{ Main.cmpT :: forall a1 a2. a1 -> a2 -> GHC.Types.Ordering [GblId, Arity=2, Caf=NoCafRefs, Str=, Unf=OtherCon []] = [] \r [a2_s3tf b_s3tg] case case a2_s3tf of sat_s3th [Occ=Once] { __DEFAULT -> dataToTag# [sat_s3th]; } of a'_s3ti { __DEFAULT -> case case b_s3tg of sat_s3tj [Occ=Once] { __DEFAULT -> dataToTag# [sat_s3tj]; } of b'_s3tk { __DEFAULT -> case <# [a'_s3ti b'_s3tk] of { __DEFAULT -> case ==# [a'_s3ti b'_s3tk] of { __DEFAULT -> GHC.Types.GT []; 1# -> GHC.Types.EQ []; }; 1# -> GHC.Types.LT []; }; }; }; }}} which looks right. In another variant (I made `dataToTag#` lazy) I saw {{{ Main.cmpT :: forall a1 a2. a1 -> a2 -> GHC.Types.Ordering [GblId, Arity=2, Caf=NoCafRefs, Str=, Unf=OtherCon []] = [] \r [a2_s3tf b_s3tg] case a2_s3tf of x1_s3th [Occ=Once] { __DEFAULT -> case dataToTag# [x1_s3th] of a'_s3ti { __DEFAULT -> case b_s3tg of x2_s3tj [Occ=Once] { __DEFAULT -> case dataToTag# [x2_s3tj] of b'_s3tk { __DEFAULT -> case <# [a'_s3ti b'_s3tk] of { __DEFAULT -> case ==# [a'_s3ti b'_s3tk] of { __DEFAULT -> GHC.Types.GT []; 1# -> GHC.Types.EQ []; }; 1# -> GHC.Types.LT []; }; }; }; }; }; }}} But both stubbornly return `LT` instead of `EQ`. This must be a code-gen or RTS issue. I have not looked at the Cmm. Might you do so? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 16:29:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 16:29:35 -0000 Subject: [GHC] #14251: LLVM Code Gen messes up registers In-Reply-To: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> References: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> Message-ID: <062.93e9dbd11ae85ea742678159befebd66@haskell.org> #14251: LLVM Code Gen messes up registers -------------------------------------+------------------------------------- Reporter: angerman | Owner: kavon Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler (LLVM) | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D5190 Wiki Page: | -------------------------------------+------------------------------------- Changes (by kavon): * status: new => patch * differential: => D5190 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 16:30:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 16:30:27 -0000 Subject: [GHC] #14251: LLVM Code Gen messes up registers In-Reply-To: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> References: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> Message-ID: <062.d8a570c3b47e5d7fcd969b31400c4769@haskell.org> #14251: LLVM Code Gen messes up registers -------------------------------------+------------------------------------- Reporter: angerman | Owner: kavon Type: bug | Status: patch Priority: highest | Milestone: 8.6.1 Component: Compiler (LLVM) | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5190 Wiki Page: | -------------------------------------+------------------------------------- Changes (by kavon): * differential: D5190 => Phab:D5190 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 16:53:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 16:53:41 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.a45f1ddf20f05b0550caa3bd5bc491e6@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Weirdly enough, I get different answers than the ones simonpj reported for the program in comment:13. To be explicit, if I'm using this program: {{{#!hs {-# LANGUAGE MagicHash #-} module Main where import GHC.Exts (dataToTag#, tagToEnum#, (==#), (<#)) main :: IO () main = print $ compare a T2 where {-# NOINLINE f #-} f = T2 {-# NOINLINE a #-} a = f data T = T1 | T2 | T3 | T4 | T5 | T6 | T7 | T8 | T9 deriving (Eq, Show) instance Ord Main.T where compare a b = case dataToTag# a of a' -> case dataToTag# b of b' -> if tagToEnum# (a' <# b') :: Bool then LT else if tagToEnum# (a' ==# b') :: Bool then EQ else GT }}} Then I consistently get `LT` regardless of optimization level: {{{ $ /opt/ghc/8.6.1/bin/ghc -O0 -fforce-recomp Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... LT $ /opt/ghc/8.6.1/bin/ghc -O2 -fforce-recomp Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... LT }}} If I replace all uses of `dataToTag#` with `getTag`, however: {{{#!hs {-# LANGUAGE MagicHash #-} module Main where import GHC.Base (getTag) import GHC.Exts (tagToEnum#, (==#), (<#)) main :: IO () main = print $ compare a T2 where {-# NOINLINE f #-} f = T2 {-# NOINLINE a #-} a = f data T = T1 | T2 | T3 | T4 | T5 | T6 | T7 | T8 | T9 deriving (Eq, Show) instance Ord Main.T where compare a b = case getTag a of a' -> case getTag b of b' -> if tagToEnum# (a' <# b') :: Bool then LT else if tagToEnum# (a' ==# b') :: Bool then EQ else GT }}} Only then do I get `EQ` without optimization: {{{ $ /opt/ghc/8.6.1/bin/ghc -O0 -fforce-recomp Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... EQ $ /opt/ghc/8.6.1/bin/ghc -O2 -fforce-recomp Bug.hs && ./Bug [1 of 1] Compiling Main ( Bug.hs, Bug.o ) Linking Bug ... LT }}} What's more, I consistently get the same sets of results in each version of GHC dating back to 8.2.2. This makes me believe that the bug that was exposed here has actually been lurking for quite a while (but perhaps a difference in inlining behavior in 8.6 only just recently exposed it). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 17:05:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 17:05:12 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.6cb8fab8a432a7f2e8b2e4ec9dae8166@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The fact that using `dataToTag#` directly produces incorrect results is perhaps not terribly surprising, giving that it [http://git.haskell.org/ghc.git/blob/21efbc7599e39ec93b8b13b7d7b84811226e6f6f:/compiler/prelude/primops.txt.pp#l2966 must always be applied to an evalauted argument] (see `Note [dataToTag#]`). The fact that the version using `getTag` breaks is more worrisome, since `getTag` actually forces its argument (with a bang pattern). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 17:06:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 17:06:17 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.094f95790a9072245dc81b8120f818e9@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 17:08:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 17:08:38 -0000 Subject: [GHC] #14375: Implement with# primop In-Reply-To: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> References: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> Message-ID: <061.2f70616f1289818aeca7814217f54be8@haskell.org> #14375: Implement with# primop -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14346 | Differential Rev(s): ​Phab:D4110, Wiki Page: | Phab:D4189 -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 17:08:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 17:08:39 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.474394b9629a994c612942803e766b7a@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It's also worth noting that you can trim `T` down to just two constructors: {{{#!hs {-# LANGUAGE MagicHash #-} module Main where import GHC.Base (getTag) import GHC.Exts (tagToEnum#, (==#), (<#)) main :: IO () main = print $ compare a T2 where {-# NOINLINE f #-} f = T2 {-# NOINLINE a #-} a = f data T = T1 | T2 deriving (Eq, Show) instance Ord Main.T where compare a b = case getTag a of a' -> case getTag b of b' -> if tagToEnum# (a' <# b') :: Bool then LT else if tagToEnum# (a' ==# b') :: Bool then EQ else GT }}} And the bug will still trigger. (If you define `data T = T2`, then the bug will go away.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 17:15:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 17:15:20 -0000 Subject: [GHC] #14251: LLVM Code Gen messes up registers In-Reply-To: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> References: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> Message-ID: <062.d3e118fc8e815f7a6ebcfb6f8fa1a57a@haskell.org> #14251: LLVM Code Gen messes up registers -------------------------------------+------------------------------------- Reporter: angerman | Owner: kavon Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler (LLVM) | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5190 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.6.2 Comment: Thanks kavon! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 17:18:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 17:18:28 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.40e9ffb02dd3a69a0c2d840823001dde@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:16 RyanGlScott]: > The fact that using `dataToTag#` directly produces incorrect results is perhaps not terribly surprising... Except that we have special code to make sure that always happens regardless. The STG Simon pasted looks right from that standpoint: it always applies `dataToTag#` under a case on its argument. So my bet is that Simon is right: something is going wrong in code generation or the RTS. Side note: it looks like I was wrong about tagging large types. I believe there was some talk of that, but it doesn't look like it's happened as yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 18:26:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 18:26:09 -0000 Subject: [GHC] #14375: Implement with# primop In-Reply-To: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> References: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> Message-ID: <061.56d87cd4fa89a876bd5c931a5a1832c3@haskell.org> #14375: Implement with# primop -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14346 | Differential Rev(s): ​Phab:D4110, Wiki Page: | Phab:D4189 -------------------------------------+------------------------------------- Comment (by dfeuer): I don't understand why this has to wait for the continuation arguments machinery. Yes, that will make it more efficient, but shouldn't we get the correctness now and worry about efficiency later? If we write {{{#!hs with# a m s = case m s of (# s', r #) -> (# touch# a s', r #) {-# NOINLINE with# #-} }}} won't that at least let users write reliable backwards-compatible code? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 18:35:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 18:35:50 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.9f842f12b80f2df75ddf23956ecf4ce4@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:11 dfeuer]: > Didn't we just recently start using some pointer tagging for types with more than 7 constructors? I'm thinking something could be a drop off in that code. Nope. That code is not ripe yet. This summer was very busy for me. Another thing: With Peter I discovered last Haskell eXchange (Oct. 2017) that enumerated types with derived `Ord` instances could use `getTag` to derive a constant-time `compare` (and `(==)` too). We were not aware of this optimization already being in the codebase. We'll surely revisit this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 18:37:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 18:37:59 -0000 Subject: [GHC] #15592: Type families without CUSKs cannot be given visible kind variable binders In-Reply-To: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> References: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> Message-ID: <065.f089ce2e691e1661303a1b8e57fecb3d@haskell.org> #15592: Type families without CUSKs cannot be given visible kind variable binders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | TypeApplications, TypeFamilies, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15591 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Ah, I now understand why non-CUSKed declarations seem to have totally different behavior with respect to visibility than CUSKed ones: their visibilities are determined in a completely different part of the code! In particular, in `kcTyClGroup` (as opposed to `kcLHsQTyVars`, which was the case for #15591). [http://git.haskell.org/ghc.git/blob/21efbc7599e39ec93b8b13b7d7b84811226e6f6f:/compiler/typecheck/TcTyClsDecls.hs#l554 This line] is quite relevant: {{{#!hs ; kvs <- kindGeneralize (mkTyConKind tc_binders tc_res_kind) }}} It appears that all kind variables are simply made invisible, which is clearly not what we want. Now we just need to figure out how to bend this code to our will... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 19:02:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 19:02:20 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.3b8dbdb761af3403457d2320df980ef5@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D5196 Comment: Simon, please review. There are a few ways to fix this and I probably did the most conservative thing by always introducing a case around `dataToTag#`. Perhaps we want to change how we record evaluated-ness of CAFs in their Ids instead. We may also want to pay more attention to #14677 if we rely on strictness annotations of data constructor fields to decide on evaluatedness of values elsewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 19:10:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 19:10:38 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.16af7cb0823e8d604bdb36d34a5be23f@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): One other thing to note is, as other commenters above already mentioned, this is _not_ a new bug! The bug was there since years. I think something else (maybe changes in simplifier) revealed it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 19:43:51 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 19:43:51 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.93313794e4f99346bc728c27026a56e4@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 20:14:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 20:14:50 -0000 Subject: [GHC] #15699: Run sanity checker in more testsuite runs Message-ID: <046.83812391c36d90b4b11d632d4b46c47a@haskell.org> #15699: Run sanity checker in more testsuite runs -------------------------------------+------------------------------------- Reporter: bgamari | 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: -------------------------------------+------------------------------------- Every testsuite run should run at least a subset of tests with the sanity checker enabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 20:33:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 20:33:57 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.7229b9075102114079a22f37e0ab2b8c@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Thinking about this more. I think the only case where we can actually avoid entering the argument of `dataToTag#` is when the argument is a static closure. For anything else (a dynamic closure, a CAF) we need to enter it. I don't know how often people do `dataToTag# C` (for some constructor `C`), perhaps it's fine to always enter it. If it is then we can remove the special case for `dataToTag#` in CorePrep and in the codegen (in Cmm) we can just enter the argument. If we decide to do that then perhaps we should also revisit the `getTag` and remove the bang pattern on its argument. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 20:52:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 20:52:09 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.3e313579166f350cf1b3a787113b181b@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:24 osa1]: > Thinking about this more. I think the only case where we can actually avoid entering the argument of `dataToTag#` is when the argument is a static closure. For anything else (a dynamic closure, a CAF) we need to enter it. I'm a tad confused. If the tag bits are non-zero, can't we just use them and avoid dereferencing the pointer? Or is that already folded into "enter it"? Or am I just wrong? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 21:34:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 21:34:38 -0000 Subject: [GHC] #10791: Add a --disable-large-memory-space configure option In-Reply-To: <044.dad24b52dfdb3ab9a4e1b09182a3fa05@haskell.org> References: <044.dad24b52dfdb3ab9a4e1b09182a3fa05@haskell.org> Message-ID: <059.f3ba37a22b0da41fe25d92369373b7e6@haskell.org> #10791: Add a --disable-large-memory-space configure option -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1170 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ericson2314): This code is very hard to read, and the behavior very hard to intuit. - Folding together the `=yes` and no-flag case *outside* the `"$ac_cv_sizeof_void_p" -eq 8` branch falsely implies the default is unconditionally/constantly true. - `=yes` will be silently ignored on non-Darwin if the test doesn't pass. - Ignoring `--enable/disable-large-address-space` on 32-bit is more harmful than helpful. The fact is, most (all?) people blindly cargo cult and copy paste configure flags, and this will give them a false intuition. (Postel's law hurts us by hiding bugs with gratuitous complexity.) Crucially and unlike many such similar things, it's not necessary for backwards compatibility since this flag is new. Granted, I could be persuaded on the 3rd point that on 32-bit the large and small address spaces both morally exist but are the same, rather than the large one not existing, so the laxer handling of the flags is justified. But, at the very least a warning is due on the ignored/superfluous flags, and the code restructured to properly separate sanitizing user input, checking whether expectations are met, and providing a default value. Sorry to lash out on random 3 year old issue, but this is a perfect example of the sort of "diff golf" / incremental change that leads to impenetrable and every-growing configure scripts (or build systems in general). 5 minutes of what might seem silly OCD by the original author cleaning up what's there can save far more time for the next person. And in fact, writing a truth table a is great first step, without which I would have spent longer being confused. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 21:56:32 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 21:56:32 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.8478b1ba1bb48ea6aa8524821e2bab68@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Ah... I am not entirely wrong, but I am partly wrong, because types with many constructors get tagged 1 when evaluated. I think we should at least be able to add a rule that recognizes when `dataToTag#` is used with a type with only a few constructors: see the logic in the `cgAlts gc_plan bndr (AlgAlt tycon) alts` case in `compiler/codeGen/StgCmmExpr.hs`. That way we only have to call `getConstrTag` when 1. The type is unknown, 2. The type has too many constructors, or 3. The tag bits are 0. I imagine you can do this quite easily by copying a bit of the `splitTyConApp_maybe` logic from `tagToEnumRule` to `dataToTagRule` in `PrelRules.hs` and adding a `DataToTagUsingTagOp` to supplement `DataToTagOp`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 22:05:00 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 22:05:00 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.e2187ed1fd805f866e1bbe38eb4d1b82@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Aha! Actually, I believe even one fall-back should be able to use tag bits, as long as they're greater than 1. So: === When the type is recognized as having a small number of constructors Check the tag bits. If they '''are 0''', enter the closure. Otherwise, subtract 1 to get the tag. === When the type is unknown Check the tag bits. If they '''are less than or equal to 1''', enter the closure. Otherwise, subtract 1 to get the tag. === When the type has too many constructors Enter the closure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 22:05:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 22:05:57 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.a9375ae286c046d96c9347689228078b@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 22:52:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 22:52:35 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.a407755222f4406f82435753b0eefdf5@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I guess what I'm suggesting would be implemented most easily by replacing the `dataToTag#` primop a little bit. {{{#!hs unKnownType, smallType, largeType :: Int# unKnownType = 0# smallType = 1# largeType = 2# dataToTag# x = dataToTagUsing# unknownType x -- Takes the "strategy" to use dataToTagUsing# :: Int# -> a -> Int# }}} This arrangement is designed so we shouldn't have to do any painful restructuring of the `caseRules` or `dataToTagRule`. The only potential problem I see is if any user-written `RULES` match on `dataToTag#`, because that won't work anymore. Should we worry about that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 2 22:53:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Oct 2018 22:53:19 -0000 Subject: [GHC] #15700: Plugins cause GHC to panic: cannot find dynamic libraries Message-ID: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> #15700: Plugins cause GHC to panic: cannot find dynamic libraries -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Windows Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With GHC 8.6.1 on Windows 7 x64, I seem to be getting a similar problem as in ticket #15492. Trying to use any type-checking plugin at all causes an error. Here with the natnormalise plugin: {{{ ghc.EXE: panic! (the 'impossible' happened) (GHC version 8.6.1 for x86_64-unknown-mingw32): mkPluginUsage: no dylibs, tried: C:\Code\Haskell\dylibs_bug\.stack-work\install\df4dd97d\lib\x86_64 -windows-ghc-8.6.1\libHSghc-typelits- natnormalise-0.6.3-2vTVlu0GX1Q1cNTbomjNL6-ghc8.6.1.dll C:\Users\Sam\AppData\Local\Programs\stack\x86_64-windows\msys2-20180531\mingw64\bin \libHSghc-typelits-natnormalise-0.6.3-2vTVlu0GX1Q1cNTbomjNL6-ghc8.6.1.dll C:\Users\Sam\AppData\Local\Programs\stack\x86_64-windows\msys2-20180531\mingw64\lib \libHSghc-typelits-natnormalise-0.6.3-2vTVlu0GX1Q1cNTbomjNL6-ghc8.6.1.dll GHC.TypeLits.Normalise Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler\utils\Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler\\deSugar\\DsUsage.hs:179:15 in ghc:DsUsage }}} That's with stack. I also checked with Cabal 2.4.0.1 to make sure, and indeed I get: {{{ ghc.exe: panic! (the 'impossible' happened) (GHC version 8.6.1 for x86_64-unknown-mingw32): mkPluginUsage: no dylibs, tried: C:\Users\Sam\AppData\Roaming\cabal\store\ghc-8.6.1\ghc- typelits-_-0.6.2-faf29727b3dbdfa09cfb6f0c881a2a227b5d2bb0\lib\libHSghc- typelits-_-0.6.2-faf29727b3dbdfa09cfb6f0c881a2a227b5d2bb0-ghc8.6.1.dll C:\Program Files\ghc\mingw\lib\libHSghc- typelits-_-0.6.2-faf29727b3dbdfa09cfb6f0c881a2a227b5d2bb0-ghc8.6.1.dll GHC.TypeLits.Normalise Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler\utils\Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler\\deSugar\\DsUsage.hs:179:15 in ghc:DsUsage }}} No problems with GHC 8.4.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 00:40:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 00:40:05 -0000 Subject: [GHC] #14375: Implement with# primop In-Reply-To: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> References: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> Message-ID: <061.e008abd526b76fe7a3b2bfdbcb00d32f@haskell.org> #14375: Implement with# primop -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14346 | Differential Rev(s): ​Phab:D4110, Wiki Page: | Phab:D4189 -------------------------------------+------------------------------------- Comment (by bgamari): Yes, we could and probably should introduce such a thing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 01:00:57 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 01:00:57 -0000 Subject: [GHC] #9251: ghc does not expose branchless max/min operations as primops In-Reply-To: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> References: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> Message-ID: <060.e031742ffa151e3d4707bbd33ce74296@haskell.org> #9251: ghc does not expose branchless max/min operations as primops -------------------------------------+------------------------------------- Reporter: carter | Owner: osa1 Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9246 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I believe it is just waiting for someone to come along with a patch. Feel free to finish up osa1's patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 02:08:04 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 02:08:04 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.8c8300bf8651e592a353ab246a2b1e96@haskell.org> #9136: Constant folding in Core could be better -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 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:D2858 Wiki Page: | -------------------------------------+------------------------------------- Comment (by spacekitteh): Do these rules fire for floating point operations? Because they are neither associative nor distributive. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 02:17:16 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 02:17:16 -0000 Subject: [GHC] #9136: Constant folding in Core could be better In-Reply-To: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> References: <046.597f40143bfc9d7f6c9f647fe93147a2@haskell.org> Message-ID: <061.b6dbd0a005bcaecab8de9904b30c79c2@haskell.org> #9136: Constant folding in Core could be better -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 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:D2858 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): Replying to [comment:30 spacekitteh]: > Do these rules fire for floating point operations? Because they are neither associative nor distributive. No, only for Int# and Word#. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 09:06:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 09:06:35 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.060de69cc77f71319ddbeeee3fd0ff29@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Before deciding on a ''solution'', let's record what the ''problem'' is. The original thinking was this. * `dataToTag#` is a primop, so it has no business doing anything as complicated as evaluating its argument; we already have `case` expressions that the code-gen knows how to compile. * So `dataToTag#` expects an evaluated argument; in fact, stronger than that, it expects a pointer ''to the data value itself'', so that it can extract the tag directly from the info table. * But if it so happens that the value in question already ''is'' evaluated, that's a waste. Example {{{ f x = case x of y -> ...(dataToTag# y)... }}} It seems a bit silly for `dataToTag#` to re-evaluate `y`. * Hence, in `CorePrep` (see `Note [dataToTag magic]`) we add a `case` around the argument to `dataToTag#` ''unless'' the argument is already evaluated. * The "already-evaluated" test is `exprIsHNF`. * '''But alas''', while `exprIsHNF` guarantees that the thing will evaluate in O(1) time, it does ''not'' guarantee that we have a pointer to the data value itself. Omer accurately diagnoses this problem in the Note in his draft Phab:D5196: {{{ Note [Always introduce case around dataToTag# arg] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We used to only generate a case expression around dataToTag# argument when it's not known to be evaluated (checked with `exprIsHNF`), but this is incorrect. Here's an example: data T = T1 | T2 main = print (I# (dataToTag# a)) where {-# NOINLINE f #-} f = T2 {-# NOINLINE a #-} a = f `f` is a static closure f_r1zz :: Main.T [GblId, Caf=NoCafRefs, Unf=OtherCon []] = CCS_DONT_CARE Main.T2! []; but `a` is an _updatable_ CAF! a_r1zA :: Main.T [GblId, Unf=OtherCon []] = [] \u [] f_r1zz; An updatable CAF is not in HNF (entering the closure does the `newCAF()` stuff and updates the closure with an IND_STATIC, the usual CAF evaluation routines), but according to `exprIsHNF` `a` is! }}} * I thought of having a more conservative test in `CorePrep`. But the rot goes further. Consider this, from `Note [dataToTag magic]` {{{ data T = MkT !Bool f v = case v of MkT y -> dataToTag# y }}} We certainly know that `y` will be evaluated, because `MkT` is a strict constructor. But does it guarantee to point directly to the data value? No! The case-to-let transformation in the Simplifier (`Simplify.doCaseToLet`) uses `exprIsHNF` and hence will drop the eval on `MkT`'s argument for things like Omer's `a` binding. And that is right in a way: the argument to `MkT a` certainly isn't bottom! But nor does it point to the data value. So that is a problem. But I think there is another. Look in comment:13 and comment:14. Here we have the extra `case` expressions correctly inserted, but we ''still'' get the wrong answer. '''So I think there may be ''two'' bugs'''. I'd like to understand the second before looking for a fix. Omer: could you investigate why comments 13 and 14 go wrong? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 09:35:09 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 09:35:09 -0000 Subject: [GHC] #2783: RTS -K/-M options not honored In-Reply-To: <049.63d82e75e6191178fe162ae9a73c2fd3@haskell.org> References: <049.63d82e75e6191178fe162ae9a73c2fd3@haskell.org> Message-ID: <064.ac6f5f57f2b2bdde2048d50157d83597@haskell.org> #2783: RTS -K/-M options not honored -----------------------------------+------------------------------ Reporter: j.waldmann | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 6.10.2 Component: Runtime System | Version: 6.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -----------------------------------+------------------------------ Changes (by bgamari): * owner: igloo => (none) * type: merge => bug * status: closed => new * resolution: fixed => Comment: It looks like this should be re-opened. The associated test has been fragile in the CircleCI slow-validate way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 09:37:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 09:37:26 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.d484a38e5b98a04b4242ab2eed3fdb5f@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Sure. The problem in comment:13 is exactly what I explained in my patch (and you also copied it here in comment:30). I get this STG with GHC HEAD, -O0: {{{ f_r1C3 :: Main.T [GblId, Caf=NoCafRefs, Unf=OtherCon []] = CCS_DONT_CARE Main.T2! []; a_r1C4 :: Main.T [GblId, Unf=OtherCon []] = [] \u [] f_r1C3; sat_s1OH :: GHC.Types.Ordering [LclId] = [] \u [] case dataToTag# [a_r1C4] of a'_s1OD { __DEFAULT -> case <# [a'_s1OD 1#] of sat_s1OE [Occ=Once] { __DEFAULT -> case tagToEnum# [sat_s1OE] of { GHC.Types.False -> case a'_s1OD of { __DEFAULT -> GHC.Types.GT []; 1# -> GHC.Types.EQ []; }; GHC.Types.True -> GHC.Types.LT []; }; }; }; }}} Notice that we do `dataToTag# [a_r1C4]` and `a_r1C4` is an updatable CAF. The result is I get `LT` instead of `EQ`. (this is one of the regression tests I added) I get very similar STG (with the same bug) and same results with these configurations: GHC HEAD, GHC 8.2.2, GHC 8.0.2. All tried with -O0, -O1, -O2. I'm guessing that you added a NOINLINE for `cmpT` in comment:14. When I do that I get the right answer with all optimisation settings (GHC HEAD), and that makes sense becuase the arguments are now known to be evaluated and `exprIsHNF` correctly returns `False` for the arguments, so we do case on the args. I don't know how you get incorrect result in the STG shown in comment:14. Could it be that you used an older binary of the test program or something like that? If you give more detailed instructions to reproduce I can take a look. I agree that if the STG in comment:14 is producing wrong result then there's at least one more bug. However I get identical STG when I add NOINLINE aroung `cmpT` (with GHC HEAD, with -O2) and it works as expected. You said you also made `dataToTag#` lazier, but because I get identical STG as you I haven't tried to change the primop laziness (it shouldn't matter in STG). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 10:02:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 10:02:36 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.57f05089b379f500685b2eb1096eb828@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I get this STG with GHC HEAD, -O0: That's what you get for monoidal's code in comment:18. Note the missing eval before the `dataToTag#`. But it is ''not'' what you get for the code in comment:13. The evals are there, as comment:14 shows. And yet we get the wrong answer. But why? That is the second bug. Can you see why that happens? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 10:06:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 10:06:10 -0000 Subject: [GHC] #7897: MakeTypeRep fingerprints be proper, robust fingerprints In-Reply-To: <046.71438f4eb0adc834d5130a615d3ff9d8@haskell.org> References: <046.71438f4eb0adc834d5130a615d3ff9d8@haskell.org> Message-ID: <061.c3df1ab0cdfc1007e1422d8f0983131c@haskell.org> #7897: MakeTypeRep fingerprints be proper, robust fingerprints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): Another use case for this is in the `safecopy` package (see https://github.com/acid-state/acid- state/issues/102#issuecomment-426327014), where it would be useful to be able to notice that the developer has changed a type used for binary serialization purposes. That said, perhaps a TH/Generics solution would be possible, so it may not be worth changing the current semantics of fingerprints. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 10:06:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 10:06:44 -0000 Subject: [GHC] #7897: MakeTypeRep fingerprints be proper, robust fingerprints In-Reply-To: <046.71438f4eb0adc834d5130a615d3ff9d8@haskell.org> References: <046.71438f4eb0adc834d5130a615d3ff9d8@haskell.org> Message-ID: <061.31e67a3017ca9abd3ac264db33e88d15@haskell.org> #7897: MakeTypeRep fingerprints be proper, robust fingerprints -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 10:11:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 10:11:29 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.2cd0de8699c67937e3b1d9f8df2460b2@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I'm confused > That's what you get for monoidal's code in comment:18 I didn't even look at comment:18. I tried your code in comment:13 and what happens there is exactly what I explained in my patch. > The evals are there, as comment:14 shows. comment:14 shows that evals are there if I don't inline `cmpT`, and that makes sense as I explained in comment:31. We can't assume that args are evaluated so we eval them. > And yet we get the wrong answer. I get the right answer when I get the STG in comment:14. Could you try to reproduce the error in comment:14 and give me more detailed instructions (showing the source and invoked GHC commands)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 10:14:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 10:14:51 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.a542965f15245b95f04e67ad2427c0cb@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Oops sorry. I'd modified the code slightly! Try this {{{ {-# LANGUAGE MagicHash #-} module Main where import GHC.Exts (dataToTag#, tagToEnum#, (==#), (<#)) import GHC.Base ( getTag ) main :: IO () main = print $ cmpT a T2 where {-# NOINLINE f #-} f = T2 {-# NOINLINE a #-} a = f data T = T1 | T2 | T3 | T4 | T5 | T6 | T7 | T8 | T9 -- deriving (Eq, Show, Ord) cmpT a b = case getTag a of a' -> case getTag b of b' -> if tagToEnum# (a' <# b') :: Bool then LT else if tagToEnum# (a' ==# b') :: Bool then EQ else GT }}} Compile with -O and run. It prints `LT` when it should print `EQ`. But the evals are there! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 10:21:17 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 10:21:17 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.33a1becb874515a7e379114c3f9d5038@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): OK. This is the STG I get: {{{ Main.main_f [InlPrag=NOINLINE] :: Main.T [GblId, Caf=NoCafRefs, Unf=OtherCon []] = CCS_DONT_CARE Main.T2! []; Main.main_a [InlPrag=NOINLINE] :: Main.T [GblId, Unf=OtherCon []] = [] \u [] Main.main_f; Main.main1 :: GHC.Base.String [GblId] = [] \u [] case dataToTag# [Main.main_a] of a'_s3tm { __DEFAULT -> case <# [a'_s3tm 1#] of { __DEFAULT -> case a'_s3tm of { __DEFAULT -> GHC.Show.$fShowOrdering1; 1# -> GHC.Show.$fShowOrdering3; }; 1# -> GHC.Show.$fShowOrdering5; }; }; }}} Exactly the same problem, no evals around the CAF (`main_a`). Are you maybe confused because in the STG dump you also see the STG for `cmpT`? It's actually inlined in `main` so the top-level for `cmpT` is not used. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 10:37:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 10:37:02 -0000 Subject: [GHC] #15701: HEAD: Build failure in ghc-prim Message-ID: <047.259a5f30d5fea93b5893eed77622ff9a@haskell.org> #15701: HEAD: Build failure in ghc-prim -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | 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: -------------------------------------+------------------------------------- Building GHC at changeset:21efbc7599e39ec93b8b I see the following message: {{{ checking whether GCC supports __atomic_ builtins... no configure: creating ./config.status config.status: error: cannot find input file: `ghc-prim.buildinfo.in' libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist- install/package-data.mk' failed }}} And indeed there is no file `ghc-prim.buildinfo.in` in libraries/ghc-prim. There is no 8.7 for version so I am leaving it empty. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 10:41:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 10:41:08 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.db51f938b3c01ac22eb4712bcd314de3@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Are you maybe confused because in the STG dump you also see the STG for cmpT? It's actually inlined in main so the top-level for cmpT is not used. That is exactly what I was doing. Thanks! I backed up some more to look at comment:6, which does not have a top- level no-inline CAF. I see this: {{{ $sgo_r5Tk :: Main.T -> Main.T -> Main.Set Main.T -> Main.Set Main.T [GblId, Arity=3, Str=, Unf=OtherCon []] = sat-only [] \r [orig_s5Wj ds_s5Wk ds1_s5Wl] case ds1_s5Wl of wild_s5Wm [Occ=Once] { Main.Bin y_s5Wn l_s5Wo [Occ=Once] r_s5Wp [Occ=Once] -> case case ds_s5Wk of sat_s5Wq [Occ=Once] { __DEFAULT -> dataToTag# [sat_s5Wq]; } of a'_s5Wr { __DEFAULT -> case dataToTag# [y_s5Wn] of b'_s5Ws { __DEFAULT -> case <# [a'_s5Wr b'_s5Ws] of { __DEFAULT -> ... }}} Here we take apart a `Bin`, and call `dataToTag#` on the contents; and because of the `exprIsHNF` stuff there is no guarantee that the argument to `Bin` points directly to the data value. But in looking at this I found something else! In coment:6 there is no top-level CAF with a NOINLINE, so how do things go wrong. Here's how. * We start with {{{ thk = f () g x = ...(case thk of v -> Bin v Tip Tip)... }}} So far so good; the argument to `Bin` (which is strict) is evaluated. * Now we do float-out. And in doing so we do a reverse binder-swap (see `Note [Binder-swap during float-out]` in `SetLevels`) thus {{{ g x = ...(case thk of v -> Bin thk Nil Nil)... }}} The goal of the reverse binder-swap is to allow more floating -- and it does! We float the `Bin` to top level: {{{ lvl = Bin thk Tip Tip g x = ...(case thk of v -> lvl))... }}} * Now you can see that the argument of `Bin`, namely `thk`, points to the thunk, not to the value as it did before; and that gives rise to the bug. Is this wrong? Not really. We are still guaranteed that the argument to `Bin` in `lvl` will be evaluated (by that `case thk`) before `lvl` is used. But we are no longer guaranteed that the argument to `Bin` points directly to the evaluated value. So now I understand. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 10:48:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 10:48:36 -0000 Subject: [GHC] #15701: HEAD: Build failure in ghc-prim In-Reply-To: <047.259a5f30d5fea93b5893eed77622ff9a@haskell.org> References: <047.259a5f30d5fea93b5893eed77622ff9a@haskell.org> Message-ID: <062.cae6303f73aaa4b95b97ab93f53e10dd@haskell.org> #15701: HEAD: Build failure in ghc-prim -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | 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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Have you tried running `make maintainer-clean` before building? I believe that this error results from a lingering `ghc-prim` build artifact that is only removed with `maintainer-clean` (`clean` or `dist-clean` won't remove it). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 10:56:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 10:56:25 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.562912d3b9aba2d528fd0f414c8715cf@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, moving on to solutions. Your patch seems OK. But I wonder if `CorePrep` is the right place to do it. After all, some other STG manipulation might break it again. I think the right thing is for the code generator to do the job; that is, in effect implement `dataToTag#` properly. That is, in `StgCmmPrim`, in {{{ cgOpApp (StgPrimOp primop) args res_ty = do }}} add a special case for `DataToTagOp`, when we are compiling `dataToTag# x`. Then behave exactly as if we'd seen `case x of y -> dataToTag## y`, where by `dataToTag## y` I mean generate the code the looks in the info table. (We have that code here {{{ -- #define dataToTagzh(r,a) r=(GET_TAG(((StgClosure *)a)->header.info)) -- Note: argument may be tagged! emitPrimOp dflags [res] DataToTagOp [arg] = emitAssign (CmmLocal res) (getConstrTag dflags (cmmUntag dflags arg)) }}} ). And by "behave exactly as if we'd see case ..." I roughly mean call `StgCmmExpr.cgCase`. But that need some `alts` which we don't conveniently have. The easiest thing would be to take `-- the general case` equation for `cgCase` and split off the bit that does the eval, so that we can call it from `dataToTag#`. Doing this is not trivial, but it feels like the Right Thing, and will remove the magic from `dataToTag#`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 11:32:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 11:32:44 -0000 Subject: [GHC] #15701: HEAD: Build failure in ghc-prim In-Reply-To: <047.259a5f30d5fea93b5893eed77622ff9a@haskell.org> References: <047.259a5f30d5fea93b5893eed77622ff9a@haskell.org> Message-ID: <062.aaf15b7cb43eb677eb8621a9b4a008df@haskell.org> #15701: HEAD: Build failure in ghc-prim -------------------------------------+------------------------------------- Reporter: trommler | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * status: new => closed * resolution: => invalid Comment: Replying to [comment:1 RyanGlScott]: > Have you tried running `make maintainer-clean` before building? This fixes my build. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 11:55:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 11:55:51 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.7a74d642a24c8ef2bb5387a8bac13ce0@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Right, fixing this in Cmm is also what I suggested in comment:24. I think two key questions are: - Can we optimise this? That is, can we know for certain that the argument of a `dataToTag#` points directly to a value (without going through blackholes or other indirections like IND_STATIC)? - Is this worth optimising? Unless the answer to both of those is yes, then I think it makes sense to do this in Cmm (when compiling the primop). Then we can remove a bunch of notes about `getTag` and hacks in CorePrep, and simplify `getTag` to `getTag = dataToTag#`. I think we can also update the primop as `can_fail = False`. It seems to me that Core is not the right place to answer (1). Even in STG I don't know if we can answer that question with certainty. I think it's doable in Cmm where we know about "lambda form" of ids (`LambdaFormInfo`) which tells us about how to enter an object. If "lambda form" of an argument is `LFCon` then we optimise, otherwise we enter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 12:01:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 12:01:30 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.2c41d87c4f24f39b70091d9e15ad70d4@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): What I've been suggesting is that even when we don't statically know if it's been evaluated or tagged, we should surely be using tag bits when we find them. It looks like an oversight that we haven't done so in the past, and I foresee substantial benefits to fixing that. Perhaps we can win back more performance than we lose. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 12:03:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 12:03:28 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.2732020e90456a5b2eafaea4f7a450fc@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Right, agreed that looking at tag bits would work for small types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 12:03:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 12:03:47 -0000 Subject: [GHC] #15698: SingleEntry update flag for Stg bindings is not used In-Reply-To: <043.d776803be041dc275cbbbd639883a34b@haskell.org> References: <043.d776803be041dc275cbbbd639883a34b@haskell.org> Message-ID: <058.3e5c443ded01749660e63b6755ca0919@haskell.org> #15698: SingleEntry update flag for Stg bindings is not used -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: task | Status: new Priority: lowest | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > it seems like for a thunk (a binding with no arguments) we generate a thunk header and push an update frame regardless of the update flag I don't think so. See {{{ setupUpdate closure_info node body | not (lfUpdatable (closureLFInfo closure_info)) = body }}} That is, it's a no-op if the thunk is non-updatable (single-entry). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 12:09:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 12:09:28 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.e7ad349096800a24cf827d27c03e3092@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I agree with comment:38. Yes, the code generator is the right place to do it. Yes, we could ooptimise for `LFCon`, but the simplifier will have done that already. The only case I think we could reliably optimise, that would not be done already, is {{{ case x of y A -> blah DEFAULT -> ...(dataToTag# y)... }}} In this case we really do know that `y` points to the value. It would not be hard to let the code gen spot this; but I doubt it would happen much. > Right, agreed that looking at tag bits would work for small types. This should happen automatically if we use the code for `cgCase`. It already has a fast-path for the case when the scrutinee is evaluated. But you point is perhaps that for small types we don't need to index the info table: the tag is in the bits. Yes, that's a good idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 12:33:46 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 12:33:46 -0000 Subject: [GHC] #14671: Make the Template Haskell class Lift work over typed expressions In-Reply-To: <046.7f4fa9b815f39c9531e53be8b5e6ebfa@haskell.org> References: <046.7f4fa9b815f39c9531e53be8b5e6ebfa@haskell.org> Message-ID: <061.85b588a1e6aa9ff74893ccc767011b6d@haskell.org> #14671: Make the Template Haskell class Lift work over typed expressions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.2.2 Resolution: | Keywords: | TemplateHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5198 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5198 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 13:04:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 13:04:35 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.01bc2325ab0fbc89f260b22c7d6d1e3f@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Ah, I see what you're saying. The 0 tag is handled by the `case` wrapper (or C-- equivalent). So for small types, we don't need any extra test; we can just use the tag bits directly. I suppose also that my attempt to use tag bits for unknown types is more trouble than it's worth; we should just assume that those have too many constructors. As for the type-driven rewriting, I think we basically have two options: 1. Do it in PrelRules. I think this requires something like the `dataToTagWith#` primop I mentioned earlier. 2. Do it sometime later (tidy core, core prep, or lowering to STG). This lets us stick with `dataToTag#` throughout core2core, which is nice, but I don't know enough to know if any of those make sense or where/how to slot in the rule. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 13:40:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 13:40:34 -0000 Subject: [GHC] #15693: Abstracting out pattern into a pattern synonym fails with scary error In-Reply-To: <051.5637636d2d1e053a5f3f7fb9b58522eb@haskell.org> References: <051.5637636d2d1e053a5f3f7fb9b58522eb@haskell.org> Message-ID: <066.0d227177e4b466415539c05839f06f4f@haskell.org> #15693: Abstracting out pattern into a pattern synonym fails with scary error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Initial thoughts. 1. Always start by writing a pattern signature if GADTs are involved. 2. I started to do this, and discovered en route that the signature inferred for `ASSO` is absurd {{{ pattern ASSO :: forall kind (a :: kind) (b :: Ctx kind). () => forall ks k (f :: k -> ks) (a1 :: k) (ctx :: Ctx ks) ks1 k1 (f1 :: k1 -> ks1) (a2 :: k1) (ctx1 :: Ctx ks1) a3. (kind ~ (k -> ks), a ~~ f, b ~~ (a1 ':&: ctx), ks ~ (k1 -> ks1), f a1 ~~ f1, ctx ~~ (a2 ':&: ctx1), ks1 ~ *, f1 a2 ~~ a3, ctx1 ~~ 'E) => forall k ks a1 a2 ctx. (kind ~ (k -> ks), b ~ (a1 :&: (a2 :&: ctx))) => a a1 a2 -> ApplyT kind a b }}} There is no need to quantify over so much, or to have all those redundant constraints. 3. I manually simplifed the signature to {{{ pattern ASSO :: forall kind (a :: kind) (b :: Ctx kind). () => forall k ks a1 a2 ctx. (kind ~ (k -> ks), b ~ (a1 :&: (a2 :&: ctx))) => a a1 a2 -> ApplyT kind a b }}} Is that a correct sigature? Anyway it crashes GHC {{{ WARNING: file compiler/types/TyCoRep.hs, line 2486 in_scope InScope {a_aWo a1_aWp a2_aWq k_aWr ks_aWs ctx_aWt a_aYo} tenv [aWo :-> a_aWo[sk:0], aWp :-> a1_aWp[sk:0], aWq :-> a2_aWq[sk:0], aWr :-> k_aWr[sk:0], aWs :-> ks_aWs[sk:0], aWt :-> ctx_aWt[sk:0]] cenv [] tys [a_aWo[sk:1] a1_aWp[sk:1] a2_aWq[sk:1] -> ApplyT (k_aWr[sk:1] -> ks_aWs[sk:1]) (a_aWo[sk:1] |> _N ->_N Sym {co_aYt}) (a1_aWp[sk:1] ':&: (a2_aWq[sk:1] ':&: ctx_aWt[sk:1]) |> (Ctx (_N ->_N Sym {co_aYu}))_N)] cos [] needInScope [aYo :-> a_aYo[sk:1], aYt :-> co_aYt, aYu :-> co_aYu] ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.7.20181003 for x86_64-unknown-linux): ASSERT failed! Type-correct unfilled coercion hole {co_aYt} Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:1805:99 in ghc:TcHsSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug simonpj at cam-05-unx:~/tmp$ ~/5builds/HEAD-4/inplace/bin/ghc-stage1 -c T15693.hs -ddump-types WARNING: file compiler/types/TyCoRep.hs, line 2486 in_scope InScope {kind_aWo a_aWp b_aWq k_aWr ks_aWs a1_aWt a2_aWu ctx_aWv k_aYw k_aYz} tenv [aWo :-> kind_aWo[sk:0], aWp :-> a_aWp[sk:0], aWq :-> b_aWq[sk:0], aWr :-> k_aWr[sk:0], aWs :-> ks_aWs[sk:0], aWt :-> a1_aWt[sk:0], aWu :-> a2_aWu[sk:0], aWv :-> ctx_aWv[sk:0]] cenv [] tys [kind_aWo[sk:1] ~ (k_aWr[sk:2] -> ks_aWs[sk:2]), b_aWq[sk:1] ~ (a1_aWt[sk:2] ':&: (a2_aWu[sk:2] ':&: ctx_aWv[sk:2]) |> (Ctx (Sym {co_aYy}))_N)] cos [] needInScope [aYw :-> k_aYw[sk:2], aYy :-> co_aYy, aYz :-> k_aYz[sk:2]] WARNING: file compiler/types/TyCoRep.hs, line 2486 in_scope InScope {kind_aWo a_aWp b_aWq k_aWr ks_aWs a1_aWt a2_aWu ctx_aWv k_aYw k_aYz} tenv [aWo :-> kind_aWo[sk:0], aWp :-> a_aWp[sk:0], aWq :-> b_aWq[sk:0], aWr :-> k_aWr[sk:0], aWs :-> ks_aWs[sk:0], aWt :-> a1_aWt[sk:0], aWu :-> a2_aWu[sk:0], aWv :-> ctx_aWv[sk:0]] cenv [] tys [(a_aWp[sk:1] |> {co_aYy}) a1_aWt[sk:2] a2_aWu[sk:2] -> ApplyT kind_aWo[sk:1] a_aWp[sk:1] b_aWq[sk:1]] cos [] needInScope [aYw :-> k_aYw[sk:2], aYy :-> co_aYy, aYz :-> k_aYz[sk:2]] WARNING: file compiler/types/TyCoRep.hs, line 2486 in_scope InScope {kind_aWo a_aWp b_aWq k_aZT k_aZU k_aZV ks_aZW a1_aZX a2_aZY ctx_aZZ} tenv [aWr :-> k_aZV[tau:4], aWs :-> ks_aZW[tau:4], aWt :-> a1_aZX[tau:4], aWu :-> a2_aZY[tau:4], aWv :-> ctx_aZZ[tau:4], aYw :-> k_aZU[tau:4], aYz :-> k_aZT[tau:4]] cenv [] tys [kind_aWo[sk:0] ~ (k_aWr[sk:0] -> ks_aWs[sk:0]), b_aWq[sk:0] ~ (a1_aWt[sk:0] ':&: (a2_aWu[sk:0] ':&: ctx_aWv[sk:0]) |> (Ctx (Sym {co_aYy}))_N)] cos [] needInScope [aWo :-> kind_aWo[sk:0], aWq :-> b_aWq[sk:0], aYy :-> co_aYy] ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.7.20181003 for x86_64-unknown-linux): ASSERT failed! Type-correct unfilled coercion hole {co_aYy} Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:1805:99 in ghc:TcHsSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} 4. I GADT-ified it thus {{{ pattern ASSO :: a a1 a2 -> ApplyT (k -> ks) a (a1 :&: (a2 :&: ctx)) }}} (NB: as the manual says, this isn't quite the same as the form with equality constraints.) But that crashed GHC too {{{ WARNING: file compiler/types/TyCoRep.hs, line 2486 in_scope InScope {a_aWo a1_aWp a2_aWq k_aWr ks_aWs ctx_aWt a_aYo} tenv [aWo :-> a_aWo[sk:0], aWp :-> a1_aWp[sk:0], aWq :-> a2_aWq[sk:0], aWr :-> k_aWr[sk:0], aWs :-> ks_aWs[sk:0], aWt :-> ctx_aWt[sk:0]] cenv [] tys [a_aWo[sk:1] a1_aWp[sk:1] a2_aWq[sk:1] -> ApplyT (k_aWr[sk:1] -> ks_aWs[sk:1]) (a_aWo[sk:1] |> _N ->_N Sym {co_aYt}) (a1_aWp[sk:1] ':&: (a2_aWq[sk:1] ':&: ctx_aWt[sk:1]) |> (Ctx (_N ->_N Sym {co_aYu}))_N)] cos [] needInScope [aYo :-> a_aYo[sk:1], aYt :-> co_aYt, aYu :-> co_aYu] ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.7.20181003 for x86_64-unknown-linux): ASSERT failed! Type-correct unfilled coercion hole {co_aYt} Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:1805:99 in ghc:TcHsSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} So we have multiple issues here * GHC should not crash * We should not infer such a redundant signature. What signature do you expect? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 13:51:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 13:51:06 -0000 Subject: [GHC] #15693: Abstracting out pattern into a pattern synonym fails with scary error In-Reply-To: <051.5637636d2d1e053a5f3f7fb9b58522eb@haskell.org> References: <051.5637636d2d1e053a5f3f7fb9b58522eb@haskell.org> Message-ID: <066.e7cce2c17c100edd4ddb4c48744a6330@haskell.org> #15693: Abstracting out pattern into a pattern synonym fails with scary error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah.. I guess #15694 is reporting the crashes, I missed that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 14:34:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 14:34:50 -0000 Subject: [GHC] #15592: Type families without CUSKs cannot be given visible kind variable binders In-Reply-To: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> References: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> Message-ID: <065.7d5b1c6459e1fe03f89616921d4ba481@haskell.org> #15592: Type families without CUSKs cannot be given visible kind variable binders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | TypeApplications, TypeFamilies, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14880 | Blocking: Related Tickets: #15591 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * blockedby: => 14880 Comment: Hold off on this, please. I've tinkered some in this area en route to #14880 and don't want to duplicate effort. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 14:48:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 14:48:03 -0000 Subject: [GHC] #12556: `stimes` adds extra power to Semigroup In-Reply-To: <051.3e20872f4a86540267ac1fdaeb10ec66@haskell.org> References: <051.3e20872f4a86540267ac1fdaeb10ec66@haskell.org> Message-ID: <066.3a05c5a168a36b88945e21a1c78491fd@haskell.org> #12556: `stimes` adds extra power to Semigroup -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.0.1 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 chris-martin): I see three options: 1. Add a `Semigroup` law "`stimes 0 x` = ⊥". This would require introducing some strictness on the first argument and changing some (many?) instances. 2. Add a `Semigroup` law "If `stimes 0 x` = `i` ≠ ⊥, then `i` must be an identity". I'd guess all of the instances already adhere to this. 3. Add a `Semigroup` "un-law" that simply warns "For `n` less than 1, `stimes n x` is not defined and may produce anything." This certainly requires no code changes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 15:11:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 15:11:13 -0000 Subject: [GHC] #15592: Type families without CUSKs cannot be given visible kind variable binders In-Reply-To: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> References: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> Message-ID: <065.d2559e71c44b96d8dc4d78f18ebcaf24@haskell.org> #15592: Type families without CUSKs cannot be given visible kind variable binders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | TypeApplications, TypeFamilies, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14880 | Blocking: Related Tickets: #15591 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ha ha. I looked at this too. Consider {{{ data T f (a::k1) b = MkT (f a b) }}} Then we should get {{{ T :: forall {k2} k1. (k1 -> k2 -> *) -> k1 -> k2 -> * }}} That is: `k2` is `Inferred` but `k1` is `Specified`. But ''neither'' is among the `tc_binders` of the `TcTyCon` that we make before kind-generalisation! Those `tc_binders` are only the `Required` ones, positionally written by the user. (It took me a while to work this out; we should write it down.) OK so `kindGeneralize` will now generalise over both `k1` and `k1`, in some random order. We must * Mark the `Inferred` ones as `Inferred` and similarly `Specified`. * Put the former before the latter How can we distinguish? Well, the `Specified` ones are among the `tcScopedTyVars` of the `TcTyCon`, but the `Inferred` ones are not. So I did this, in `kcTyClGroup`: {{{ ; kvs <- kindGeneralize (mkTyConKind tc_binders tc_res_kind) ; scoped_tvs' <- zonkTyVarTyVarPairs scoped_tvs ; let (specified_kvs, inferred_kvs) = partition is_specified kvs user_specified_tkvs = mkVarSet (map snd scoped_tvs') is_specified kv = kv `elemVarSet` user_specified_tkvs all_binders = mkNamedTyConBinders Inferred inferred_kvs ++ mkNamedTyConBinders Specified specified_kvs ++ tc_binders }}} This works. I will not commit: over to you Richard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 15:17:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 15:17:50 -0000 Subject: [GHC] #15667: Readonly permissions bits are wrong In-Reply-To: <044.f1da98646cee33a60ff58118ea841bfc@haskell.org> References: <044.f1da98646cee33a60ff58118ea841bfc@haskell.org> Message-ID: <059.8b9292b2e43913139569002ab0ced5ad@haskell.org> #15667: Readonly permissions bits are wrong -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"deceb21b7ec64ae60377addc2679692ca500b6ae/ghc" deceb21/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="deceb21b7ec64ae60377addc2679692ca500b6ae" Drop accidental write-attributes request Summary: The new filesystem code accidentally asks for write attributes permissions when doing read-only access. I believe this is what's causing the GHC 8.6.1 tarballs to fail when installed to a privileged location. I haven't been able to reproduce the issue yet, but this permission bit is wrong anyway. Test Plan: I'm still trying to workout how to test that this works, changing the permissions on the folder doesn't seem to reproduce the error on a tarball I made from before the change. Reviewers: bgamari, tdammers Reviewed By: bgamari Subscribers: tdammers, monoidal, rwbarton, carter GHC Trac Issues: #15667 Differential Revision: https://phabricator.haskell.org/D5177 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 15:17:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 15:17:50 -0000 Subject: [GHC] #13477: Turn cIntegerLibraryType into a dynflag In-Reply-To: <046.1be05c5fa445155bed193903c2e35749@haskell.org> References: <046.1be05c5fa445155bed193903c2e35749@haskell.org> Message-ID: <061.cc8fe77dfb131bbc84d1afca042bedb0@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: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"fc2ff6dd7496a33bf68165b28f37f40b7d647418/ghc" fc2ff6dd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fc2ff6dd7496a33bf68165b28f37f40b7d647418" Make GHC (the library) flexible in the choice of integer library Summary: We have more and more users of GHC as a library, for example the Haskell-to-WebAssembly-compiler https://github.com/tweag/asterius. These need to make different decisions about various aspects of code generation than the host compiler, and ideally GHC-the-library allows them to set the `DynFlags` as needed. This patch adds a new `DynFlag` that configures which `integer` library to use. This flag is initialized by `cIntegerLibraryType` (as before), and is only used in `CorePrep` to decide whether to use `S#` or not. The other code paths that were varying based on `cIntegerLibraryType` are no now longer varying: The trick is to use `integer-wired-in` as the `-this-unit-id` when compiling either `integer-gmp` or `integer-simple`. Test Plan: Validate is happy. Reviewers: hvr, bgamari Reviewed By: bgamari Subscribers: TerrorJack, adamse, simonpj, rwbarton, carter GHC Trac Issues: #13477 Differential Revision: https://phabricator.haskell.org/D5079 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 15:18:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 15:18:37 -0000 Subject: [GHC] #15592: Type families without CUSKs cannot be given visible kind variable binders In-Reply-To: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> References: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> Message-ID: <065.12210eaa853e7627f4b37e1a1eb0133f@haskell.org> #15592: Type families without CUSKs cannot be given visible kind variable binders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | TypeApplications, TypeFamilies, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14880 | Blocking: Related Tickets: #15591 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): That looks quite sensible and is independent from what I've done. (I was thinking we might have to put these into the `tc_binders`, but that's hard to get right for a non-CUSK.) If what you have works, feel free to commit. It won't get in my way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 15:20:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 15:20:00 -0000 Subject: [GHC] #15667: Readonly permissions bits are wrong In-Reply-To: <044.f1da98646cee33a60ff58118ea841bfc@haskell.org> References: <044.f1da98646cee33a60ff58118ea841bfc@haskell.org> Message-ID: <059.e16bf3abcb7f9c7ceb59df5fad1b24f5@haskell.org> #15667: Readonly permissions bits are wrong -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 15:20:16 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 15:20:16 -0000 Subject: [GHC] #15592: Type families without CUSKs cannot be given visible kind variable binders In-Reply-To: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> References: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> Message-ID: <065.46b496c5b7f32990b6730e355172a792@haskell.org> #15592: Type families without CUSKs cannot be given visible kind variable binders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | TypeApplications, TypeFamilies, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14880 | Blocking: Related Tickets: #15591 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): By a series of strange coincidences, I ended up with almost exactly the same code as in comment:7 while working on this this morning. (Don't worry, I won't work on this any further until the dust has settled on #14880.) There's one thing I haven't worked out, though: how to make this work for associated types (in light of #15591). Consider: {{{#!hs class C a where type T (x :: f a) }}} Ideally, the kind of `T` would be: {{{#!hs T :: forall {k} (a :: k) (f :: k -> Type). f a -> Type }}} Alas, the code in comment:7 is not enough to accomplish this. It will instead give this as the kind for `T`: {{{#!hs T :: forall {k} {a :: k} (f :: k -> Type). f a -> Type }}} Note that `a` is now invisible. Ack. In order to fix this, we'd need to be aware of the fact that `a` is mentioned explicitly in `C` within `kcTyClGroup`. Currently, `kcTyClGroup` doesn't have access to this information, however. Another gotcha is that if you only use the code in comment:7, it'll cause some programs to no longer typecheck. In particular, this program: {{{#!hs class C a where type T (x :: (f :: k -> Type) a) }}} {{{ Bug.hs:8:3: error: • These kind and type variables: (x :: (f :: k -> Type) a) are out of dependency order. Perhaps try this ordering: k (a :: k) (f :: k -> *) (x :: f a) NB: Implicitly declared variables come before others. • In the associated type family declaration for ‘T’ | 8 | type T (x :: (f :: k -> Type) a) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} I'm unclear if this is desirable or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 15:23:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 15:23:06 -0000 Subject: [GHC] #13477: Turn cIntegerLibraryType into a dynflag In-Reply-To: <046.1be05c5fa445155bed193903c2e35749@haskell.org> References: <046.1be05c5fa445155bed193903c2e35749@haskell.org> Message-ID: <061.cd724512f185008a204809fe7d123366@haskell.org> #13477: Turn cIntegerLibraryType into a dynflag -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: merge 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 monoidal): * status: patch => merge Comment: Not sure if we'd like to merge this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 15:27:28 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 15:27:28 -0000 Subject: [GHC] Batch modify: #15499, #15667, #8763, #12005, #13704, #14907, ... In-Reply-To: <107.aacbffc3325fcbb1cbc6f70e2644a23b@haskell.org> References: <107.aacbffc3325fcbb1cbc6f70e2644a23b@haskell.org> Message-ID: <122.07c3c7b2192930bfc86105e340772f55@haskell.org> Batch modification to #15499, #15667, #8763, #12005, #13704, #14907, #15053, #15196, #15481, #15552, #15578, #13477 by RyanGlScott: milestone to 8.6.2 Comment: Moving to the 8.6.2 milestone, since these tickets were all recently marked as merge. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 15:50:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 15:50:48 -0000 Subject: [GHC] #11335: Add instance (Ix a, Read a, Read b) => Read (UArray a b) In-Reply-To: <047.806baf8de1314a2dee16052aba8af5c1@haskell.org> References: <047.806baf8de1314a2dee16052aba8af5c1@haskell.org> Message-ID: <062.694c2748addbc8f743ecd9a926003680@haskell.org> #11335: Add instance (Ix a, Read a, Read b) => Read (UArray a b) -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.8.3 (other) | Resolution: | Keywords: array Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5156 Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * differential: => Phab:D5156 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 15:52:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 15:52:18 -0000 Subject: [GHC] #11335: Add instance (Ix a, Read a, Read b) => Read (UArray a b) In-Reply-To: <047.806baf8de1314a2dee16052aba8af5c1@haskell.org> References: <047.806baf8de1314a2dee16052aba8af5c1@haskell.org> Message-ID: <062.07a3db58ce75109ae94d27246bae3cc5@haskell.org> #11335: Add instance (Ix a, Read a, Read b) => Read (UArray a b) -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries | Version: 7.8.3 (other) | Resolution: | Keywords: array Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5156 Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 15:53:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 15:53:27 -0000 Subject: [GHC] #15360: Template Haskell splicing drops lots of type arguments In-Reply-To: <047.e6d2b23e630646579ceaa92c2d2bfbeb@haskell.org> References: <047.e6d2b23e630646579ceaa92c2d2bfbeb@haskell.org> Message-ID: <062.4e85e53c7da6707fa10cc4cb63742435@haskell.org> #15360: Template Haskell splicing drops lots of type arguments -------------------------------------+------------------------------------- Reporter: goldfire | Owner: mnguyen 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:D5188 Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * status: new => patch * differential: => Phab:D5188 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 16:08:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 16:08:48 -0000 Subject: [GHC] #15592: Type families without CUSKs cannot be given visible kind variable binders In-Reply-To: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> References: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> Message-ID: <065.1f7d6c9684117f9a52f57cd99f90edcf@haskell.org> #15592: Type families without CUSKs cannot be given visible kind variable binders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | TypeApplications, TypeFamilies, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14880 | Blocking: Related Tickets: #15591 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > In order to fix this, we'd need to be aware of the fact that a is mentioned explicitly in C within kcTyClGroup. Currently, kcTyClGroup doesn't have access to this information, however. Hmm. I wonder if we should simply add `a` to the `tyConScopedTyVars` of `T`? And that info ''is'' available in `kcLHsTQTVars` which builds the `TcTyCon`. Richard? Maybe that'd fix the gotcha too? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 17:18:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 17:18:06 -0000 Subject: [GHC] #15592: Type families without CUSKs cannot be given visible kind variable binders In-Reply-To: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> References: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> Message-ID: <065.d755772ad17ba8afc492efda6a80aef9@haskell.org> #15592: Type families without CUSKs cannot be given visible kind variable binders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | TypeApplications, TypeFamilies, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14880 | Blocking: Related Tickets: #15591 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:10 simonpj]: > Hmm. I wonder if we should simply add `a` to the `tyConScopedTyVars` of `T`? And that info ''is'' available in `kcLHsTQTVars` which builds the `TcTyCon`. I too am a bit confused as to why we don't add `a` (or any kind variables, for that matter) to `tcTyConScopedTyVars` in the non-CUSK case of `kcLHsQTyVars`. The only reasoning I could find for this design choice is [http://git.haskell.org/ghc.git/blob/fc2ff6dd7496a33bf68165b28f37f40b7d647418:/compiler/typecheck/TcHsType.hs#l1609 this terse comment]: {{{#!hs ; let -- NB: Don't add scoped_kvs to tyConTyVars, because they -- must remain lined up with the binders tc_binders = zipWith mk_tc_binder hs_tvs tc_tvs tycon = mkTcTyCon name (ppr user_tyvars) tc_binders res_kind (mkTyVarNamePairs (scoped_kvs ++ tc_tvs)) flav }}} (Here, they call `tcTyConScopedTyVars` "`tyConTyVars`".) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 17:28:48 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 17:28:48 -0000 Subject: [GHC] #15700: Plugins cause GHC to panic: cannot find dynamic libraries In-Reply-To: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> References: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> Message-ID: <059.4dfa760e6a85ad3e9616d5149247b9b5@haskell.org> #15700: Plugins cause GHC to panic: cannot find dynamic libraries -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15492 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: Phyx- (added) * priority: normal => high * related: => #15492 * milestone: 8.6.1 => 8.6.2 Comment: Oh bother. I had hoped that #15492 would have nailed all these issues, but I suppose not. I wonder if 13105a1ae870da6936a27cdd1d6a4bd25a661368 missed a Windows-specific case. Phyx-, any ideas? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 17:41:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 17:41:56 -0000 Subject: [GHC] #1087: bang patterns with infix ops In-Reply-To: <043.4fb3c1ae2ad64ed8ff4df25b60f8faf7@haskell.org> References: <043.4fb3c1ae2ad64ed8ff4df25b60f8faf7@haskell.org> Message-ID: <058.5d54658573533a0d8e918c855aad1157@haskell.org> #1087: bang patterns with infix ops -------------------------------------+------------------------------------- Reporter: dons | Owner: int-index Type: bug | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: 6.6 (Parser) | Resolution: | Keywords: bang patterns Operating System: 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 Wed Oct 3 19:27:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 19:27:47 -0000 Subject: [GHC] #15700: Plugins cause GHC to panic: cannot find dynamic libraries In-Reply-To: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> References: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> Message-ID: <059.006fb8ce89157db0df27601fd08ba2a8@haskell.org> #15700: Plugins cause GHC to panic: cannot find dynamic libraries -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15492 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Unfortunately plugins don't work on Windows. The implementation relies on DynWay. So until that's working there's no chance on getting this to work. See #5987, #5291 and #5620. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 19:33:19 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 19:33:19 -0000 Subject: [GHC] #15700: Plugins cause GHC to panic: cannot find dynamic libraries In-Reply-To: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> References: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> Message-ID: <059.a657b3bb7510b659e1cb62f12a2dafd7@haskell.org> #15700: Plugins cause GHC to panic: cannot find dynamic libraries -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15492 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I'm a bit confused—sheaf is reporting that this worked without issue on Windows on GHC 8.4.3. Are we perhaps thinking of different things? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 19:46:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 19:46:32 -0000 Subject: [GHC] #15700: Plugins cause GHC to panic: cannot find dynamic libraries In-Reply-To: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> References: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> Message-ID: <059.07d711dd4e879c2f38bbe8ff4ec8a9c3@haskell.org> #15700: Plugins cause GHC to panic: cannot find dynamic libraries -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15492 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Don't know, I only briefly looked at the implementation. as it currently is, it requires DynWay. but even before 13105a1ae870da6936a27cdd1d6a4bd25a661368 the only way it could work without being a shared library is if the plugin is "local", in which case it would load the object file. The comments around the code before the change suggest this shouldn't be possible, but who knows, it didn't abort before so maybe it did eventually find something to load. So maybe that's what was happening before, it thought the plugin was local instead of an external one. Dunno, never looked at plugins for longer then 30mins. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 19:55:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 19:55:05 -0000 Subject: [GHC] #15700: Plugins cause GHC to panic: cannot find dynamic libraries In-Reply-To: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> References: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> Message-ID: <059.bb7ed39e542563581728417fab7f52f6@haskell.org> #15700: Plugins cause GHC to panic: cannot find dynamic libraries -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15492 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => infoneeded * priority: high => normal * milestone: 8.6.2 => Comment: Hm, OK. In any case, I'm unclear on what exact steps sheaf took to trigger this bug, so having that spelled out would help us figure out if this really is a regression or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 19:59:25 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 19:59:25 -0000 Subject: [GHC] #15700: Plugins cause GHC to panic: cannot find dynamic libraries In-Reply-To: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> References: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> Message-ID: <059.94c839cd64ecf65e93fb95fa9187c3e1@haskell.org> #15700: Plugins cause GHC to panic: cannot find dynamic libraries -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15492 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Well, none of the plugin tests in the testsuite work at all, so any of them would do. In fact I have a patch to disable them since they all fail https://phabricator.haskell.org/D5174 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 20:12:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 20:12:23 -0000 Subject: [GHC] #15700: Plugins cause GHC to panic: cannot find dynamic libraries In-Reply-To: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> References: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> Message-ID: <059.74396d0e876e21d52bdfcec6ecd176c2@haskell.org> #15700: Plugins cause GHC to panic: cannot find dynamic libraries -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15492 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sheaf): Using any plugin at all triggers the bug, including an empty file e.g. {{{ {-# OPTIONS_GHC -fplugin GHC.TypeLits.Normalise #-} module Bug where }}} I don't know how plugins are set-up to work on Windows, but it doesn't seem like any DLL files are generated when I use plugins in GHC 8.4.3. From what I understand of comment:4, maybe GHC 8.4.3 on Windows could run plugins without using DLLs, whereas GHC 8.6.1 is insisting on using them when it could perhaps do without? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 21:36:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 21:36:33 -0000 Subject: [GHC] #15702: "-main-is" flag is broken for recent ghc-head Message-ID: <049.697286957b75ccd5dd90acb66c29b835@haskell.org> #15702: "-main-is" flag is broken for recent ghc-head -------------------------------------+------------------------------------- Reporter: terrorjack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect (amd64) | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here is a minimal reproduction: Main.hs: {{{ main :: IO () main = putStrLn "Main" }}} Main2.hs: {{{ module Main2 where import Main main2 :: IO () main2 = do putStrLn "Main2" main }}} Run ghc with something like `/home/terrorjack/.stack/programs/x86_64-linux/ghc-8.7.20181003/bin/ghc -main-is Main2.main2 Main.hs Main2.hs`, and it reports the following error: {{{ [1 of 2] Compiling Main ( Main.hs, Main.o ) Main.hs:1:1: error: Not in scope: ‘main2’ Perhaps you meant ‘main’ (line 2) | 1 | main :: IO () | ^ }}} Meanwhile, the exact same flags work for ghc-8.6.1, and also a previous ghc-head build on d90946cea1357d3e99805c27dab1e811785a4088, so some accidental breakage might be in a recent commit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 21:42:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 21:42:30 -0000 Subject: [GHC] #15702: "-main-is" flag is broken for recent ghc-head In-Reply-To: <049.697286957b75ccd5dd90acb66c29b835@haskell.org> References: <049.697286957b75ccd5dd90acb66c29b835@haskell.org> Message-ID: <064.e902e39ae37cb38f7d84680099fa6b00@haskell.org> #15702: "-main-is" flag is broken for recent ghc-head -------------------------------------+------------------------------------- Reporter: terrorjack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): I haven't checked, but this is most likely caused by the fix in #13704. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 21:53:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 21:53:10 -0000 Subject: [GHC] #13704: -main-is flag should change exports in default module header In-Reply-To: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> References: <046.8df7b1cc503568d79287602e2c8a7dee@haskell.org> Message-ID: <061.d0676dc0a4ac7037394b406b8c71141b@haskell.org> #13704: -main-is flag should change exports in default module header -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: merge => new Comment: Moving out of 'merge' for now due to #15702. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 22:18:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 22:18:34 -0000 Subject: [GHC] #15702: "-main-is" flag is broken for recent ghc-head In-Reply-To: <049.697286957b75ccd5dd90acb66c29b835@haskell.org> References: <049.697286957b75ccd5dd90acb66c29b835@haskell.org> Message-ID: <064.8949e353977ec17e027697b37a1ddd50@haskell.org> #15702: "-main-is" flag is broken for recent ghc-head -------------------------------------+------------------------------------- Reporter: terrorjack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by cdsmith): Arguably, I think this should never have worked in the first place. Here, Main.hs is relying on the default header to export `main` because of its name, even though `main` is no longer the entry point for this program. Adding an explicit export would fix it. If this was done in existing code, though, this does mean there's a backward-compatibility problem for that patch. That's unfortunate. The error message is also weird. There's a special error message for the `main` case that says something like "The IO action main is not defined in module Main", but `-main-is` seems to disable it and fall back to a generic "Not in scope". (This was pre-existing behavior, though. It's not new in GHC head.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 22:33:57 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 22:33:57 -0000 Subject: [GHC] #15702: "-main-is" flag is broken for recent ghc-head In-Reply-To: <049.697286957b75ccd5dd90acb66c29b835@haskell.org> References: <049.697286957b75ccd5dd90acb66c29b835@haskell.org> Message-ID: <064.8ee2f6b3d461039d3e81c791311634fc@haskell.org> #15702: "-main-is" flag is broken for recent ghc-head -------------------------------------+------------------------------------- Reporter: terrorjack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by cdsmith): On further thought, though, if -main-is specifies a module as it does here, then we probably shouldn't be changing the default exports on other modules that are not the one given. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 23:03:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 23:03: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.5aae880def66c6aeebf866307e631049@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: #15525 | Differential Rev(s): Phab:D5066 Wiki Page: | ---------------------------------+-------------------------------------- Changes (by ulysses4ever): * status: patch => merge * related: => #15525 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 3 23:14:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Oct 2018 23:14:13 -0000 Subject: [GHC] #15483: ghc -M requires -dep-suffix for no good reason In-Reply-To: <051.2a35f99f194ba90ad12a8198bda71c04@haskell.org> References: <051.2a35f99f194ba90ad12a8198bda71c04@haskell.org> Message-ID: <066.43bd6221eb66a5e2eff9e0f12c01eb75@haskell.org> #15483: ghc -M requires -dep-suffix for no good reason -------------------------------------+------------------------------------- Reporter: ulysses4ever | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Driver | 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 ulysses4ever): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 01:37:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 01:37:06 -0000 Subject: [GHC] #15009: Float equalities past local equalities In-Reply-To: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> References: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> Message-ID: <062.9b2ba13c4a54a253ecc117569f1df98b@haskell.org> #15009: Float equalities past local equalities -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: gadt/T15009 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nfrisby): Replying to [comment:5 simonpj]: > I took a look. Turns out that it is what I guessed: > > > I don't say that it's perfectly implemented (eg I'm a bit worried about whether it's sensitive to whether the constraint looks like a ~ b or b ~ a) > > We end up with > {{{ > Implic { > TcLevel = 2 > Skolems = a_a2do[sk:2] p_a2dt[sk:2] > No-eqs = True > Status = Unsolved > Given = > Wanted = > WC {wc_impl = > Implic { > TcLevel = 3 > Skolems = b_a2dp[ssk:3] > No-eqs = True > Status = Unsolved > Given = $d~_a2dq :: (b_a2dp[ssk:3] :: *) ~ (a_a2do[tau:2] :: *) > Wanted = > WC {wc_simple = > [WD] hole{co_a2dE} {1}:: (p_a2dt[sk:2] :: *) > GHC.Prim.~# (Bool :: *) (CNonCanonical) > [WD] hole{co_a2dR} {1}:: (a_a2do[sk:2] :: *) > GHC.Prim.~# (Bool :: *) (CNonCanonical)} > a pattern with constructor: > MkT1 :: forall b a. ((b :: *) ~ (a :: *)) => b -> T1 a > }}} How is it that {{{a_a2do}}} occurs both as {{{a_a2do[sk:2]}}} and also as {{{a_a2do[tau:2]}}} in this implication tree? I'm still working on a response to your suggested edit of the Note, but while I was rereading your comments I noticed the above. I'm surprised to see the same type variable (by unique at least) occurring with two different forms of `Details`. Seems like I'm missing some relevant concept. The Notes in TcType didn't seem relevant or didn't discuss it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 02:09:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 02:09:54 -0000 Subject: [GHC] #15703: Significant compilation time blowup when refactoring singletons-heavy code Message-ID: <050.85b00ed8f7678528686f0902895081dc@haskell.org> #15703: Significant compilation time blowup when refactoring singletons-heavy code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- At ICFP, I griped to Ben about some code I'm writing (which makes use of `singletons` to the nth degree) that takes absolutely forever to compile with optimizations. I suspected that type families (i.e., coercions) were the culprit, but Ben requested that I put the code on Trac anyways, so here it is. I've attached two modules (`Lib.hs` and `Lib2.hs`). You'll need GHC 8.6.1 or later to compile it. To compile it, run: {{{ $ time /opt/ghc/8.6.1/bin/ghc -O1 -fforce-recomp Lib.hs [1 of 2] Compiling Lib2 ( Lib2.hs, Lib2.o ) [2 of 2] Compiling Lib ( Lib.hs, Lib.o ) real 3m28.367s user 3m28.512s sys 0m0.212s }}} Note that if you compile without optimizations, it'll finish almost immediately: {{{ $ time /opt/ghc/8.6.1/bin/ghc -O0 -fforce-recomp Lib.hs [1 of 2] Compiling Lib2 ( Lib2.hs, Lib2.o ) [2 of 2] Compiling Lib ( Lib.hs, Lib.o ) real 0m0.528s user 0m0.480s sys 0m0.036s }}} Also, if you look at the source code for `Lib.hs`, you'll notice some code which says: {{{#!hs instance SApplicative f => SApplicative (M1 i c f) where sPure x = singFun3 @(.@#@$) (%.) @@ singFun1 @M1Sym0 SM1 @@ (singFun1 @PureSym0 sPure) @@ x -- If I change the implementation of sPure above to be this: -- -- sPure x = SM1 (sPure x) -- -- Then Lib.hs compiles quickly again (< 1 second) with -O1. SM1 f %<*> SM1 x = SM1 (f %<*> x) }}} If you apply this suggested change, then you can see the difference when you compile it with optimizations again: {{{ $ time /opt/ghc/8.6.1/bin/ghc -O1 -fforce-recomp Lib.hs [1 of 2] Compiling Lib2 ( Lib2.hs, Lib2.o ) [2 of 2] Compiling Lib ( Lib.hs, Lib.o ) real 0m0.986s user 0m0.940s sys 0m0.040s }}} Given that this particular change of code causes such a dramatic increase in compilation, I have to wonder if there's more going on here than just the usual type-family slowness. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 02:10:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 02:10:42 -0000 Subject: [GHC] #15703: Significant compilation time blowup when refactoring singletons-heavy code In-Reply-To: <050.85b00ed8f7678528686f0902895081dc@haskell.org> References: <050.85b00ed8f7678528686f0902895081dc@haskell.org> Message-ID: <065.eb03f6cfc211573453553ceb32ee2007@haskell.org> #15703: Significant compilation time blowup when refactoring singletons-heavy code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "Lib.hs" added. Lib.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 02:10:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 02:10:55 -0000 Subject: [GHC] #15703: Significant compilation time blowup when refactoring singletons-heavy code In-Reply-To: <050.85b00ed8f7678528686f0902895081dc@haskell.org> References: <050.85b00ed8f7678528686f0902895081dc@haskell.org> Message-ID: <065.f7c12bb0c44d5c8f2991ef88f5a84a30@haskell.org> #15703: Significant compilation time blowup when refactoring singletons-heavy code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "Lib2.hs" added. Lib2.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 02:13:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 02:13:34 -0000 Subject: [GHC] #15703: Significant compilation time blowup when refactoring singletons-heavy code In-Reply-To: <050.85b00ed8f7678528686f0902895081dc@haskell.org> References: <050.85b00ed8f7678528686f0902895081dc@haskell.org> Message-ID: <065.8aef2fdb75de95daa03c1b8b3ef0b463@haskell.org> #15703: Significant compilation time blowup when refactoring singletons-heavy code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): If you're wondering why I split the code up into two separate modules (instead of combining it into a single module), I observed that combining things into a single module actually made the compilation slowdown less severe (it took about 1 minute to compile, as opposed to the ~3m30s compile time shown above). I suspect that dividing up the code into further modules might exacerbate the compile times even more, since in the original project that I took this code from, it actually takes //longer// than 3m30s to compile the whole thing with `-O1`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 02:15:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 02:15:00 -0000 Subject: [GHC] #15703: Significant compilation time blowup when refactoring singletons-heavy code In-Reply-To: <050.85b00ed8f7678528686f0902895081dc@haskell.org> References: <050.85b00ed8f7678528686f0902895081dc@haskell.org> Message-ID: <050.85b00ed8f7678528686f0902895081dc@haskell.org> #15703: Significant compilation time blowup when refactoring singletons-heavy code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "Lib.hs" removed. Lib.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 02:15:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 02:15:00 -0000 Subject: [GHC] #15703: Significant compilation time blowup when refactoring singletons-heavy code In-Reply-To: <050.85b00ed8f7678528686f0902895081dc@haskell.org> References: <050.85b00ed8f7678528686f0902895081dc@haskell.org> Message-ID: <065.fccc721945af2da1c8e5ed0c9e1682d6@haskell.org> #15703: Significant compilation time blowup when refactoring singletons-heavy code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "Lib.hs" added. Lib.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 02:31:05 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 02:31:05 -0000 Subject: [GHC] #15703: Significant compilation time blowup when refactoring singletons-heavy code In-Reply-To: <050.85b00ed8f7678528686f0902895081dc@haskell.org> References: <050.85b00ed8f7678528686f0902895081dc@haskell.org> Message-ID: <065.8d8b2cd97cee9774d61afc3e834b4036@haskell.org> #15703: Significant compilation time blowup when refactoring singletons-heavy code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I built this code using a profiled GHC 8.6.1. Here are the highlights: {{{ Wed Oct 3 22:18 2018 Time and Allocation Profiling Report (Final) ghc-stage2 +RTS -p -RTS -B/u/rgscott/Software/ghc4/inplace/lib -O1 -fforce-recomp Lib.hs total time = 276.05 secs (276053 ticks @ 1000 us, 1 processor) total alloc = 403,405,509,720 bytes (excludes profiling overheads) COST CENTRE MODULE SRC %time %alloc simplCast-simplCoercion Simplify compiler/simplCore/Simplify.hs:1248:57-77 75.8 76.8 substTyWith TyCoRep compiler/types/TyCoRep.hs:(2213,23)-(2214,50) 23.8 23.0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 04:32:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 04:32:48 -0000 Subject: [GHC] #15497: Coercion Quantification In-Reply-To: <047.3a4a4e067b87a899efdf8c3f044fd1ac@haskell.org> References: <047.3a4a4e067b87a899efdf8c3f044fd1ac@haskell.org> Message-ID: <062.32f5d30dfec2bd1c1d5270b20d402c7c@haskell.org> #15497: Coercion Quantification -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5054 Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase2| -------------------------------------+------------------------------------- Comment (by ningning): I have looked through TcSimplify and 14584, but I am unsure I have understood fully the details. The logic seems delicate there. I know the motivation is {{{ forall x[2]. [W] co1: alpaha[1] ~ ty |> co2 [W] co2: k1 ~ * }}} where we have the scope problem cause `co2` could mention `x` and `co1` depends on `co2`. What's the goal after we have coercion quantifications comparing to the current strategy?? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 05:03:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 05:03:52 -0000 Subject: [GHC] #15009: Float equalities past local equalities In-Reply-To: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> References: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> Message-ID: <062.d84a81ae34c3eeeef0eecebb046b03f2@haskell.org> #15009: Float equalities past local equalities -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: gadt/T15009 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nfrisby): For future interested parties (e.g. me :/), I suggest reading these Notes in this order. (These links are into the tip of the {{{ghc-8.6}}} branch as of this moment.) 1. {{{Note [TcLevel and untouchable type variables]}}}, {{{Note [WantedInv]}}}, {{{Note [Skolem escape prevention]}}}, and {{{Note [TcLevel assignment]}}} in the {{{Untoucable type variables}}} [sic] section starting at [https://github.com/ghc/ghc/blob/8bed140099f8ab78e3e728fd2e50dd73d7210e84/compiler/typecheck/TcType.hs#L679 TcType.hs line 679] 1. {{{Note [Float Equalities out of Implications]}}}, {{{Note [Float equalities from under a skolem binding]}}}, {{{Note [Which equalities to float]}}}, {{{Note [Skolem escape]}}}, and {{{Note [What prevents a constraint from floating]}}} within the {{{Floating equalities}}} section starting at [https://github.com/ghc/ghc/blob/8bed140099f8ab78e3e728fd2e50dd73d7210e84/compiler/typecheck/TcSimplify.hs#L2132 TcSimplify.hsline 2132] 1. {{{Note [When does an implication have given equalities?]}}} and {{{Note [Let-bound skolems]}}} starting at [https://github.com/ghc/ghc/blob/8bed140099f8ab78e3e728fd2e50dd73d7210e84/compiler/typecheck/TcSMonad.hs#L2142 TcSMonad.hs line 2142] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 05:38:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 05:38:13 -0000 Subject: [GHC] #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types Message-ID: <044.6bc4fafa2c23357f8677ca0feb803442@haskell.org> #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 (Type checker) | Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeFamilies, PolyKinds #-} module A where data family D :: k type family F (a :: k) :: * type instance F (D Int) = Int type instance F (f a b) = Char type instance F (D Int Bool) = Char }}} The last equation, even though a specialization of the middle one, trips up the equality consistency check: {{{#!hs a.hs:9:15: error: Conflicting family instance declarations: F (D Int) = Int -- Defined at a.hs:9:15 F (D Int Bool) = Char -- Defined at a.hs:10:15 | 9 | type instance F (D Int) = Int | ^ }}} So GHC is able to infer that `D Int ~/~ f a b` because `D ~/~ f a`, but for some reason the same reasoning doesn't work for `D ~/~ D a`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 06:57:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 06:57:24 -0000 Subject: [GHC] #15009: Float equalities past local equalities In-Reply-To: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> References: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> Message-ID: <062.a1f7e34f9104fe3585c9497f20c4e720@haskell.org> #15009: Float equalities past local equalities -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: gadt/T15009 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nfrisby): Replying to [comment:11 simonpj]: I've spent the evening reading all the examples I could find (see previous comment) and drafting this comment. I think the example you gave in #[comment:11] does address my precise question in #[comment:10] about {{{getNoGivenEqs}}} in a way that no other existing example does. So it would probably be useful in the Note. However, I can also now ask a more exact question! I pose two questions below. With GHC 8.6.0.20180810, the following does not typecheck, because {{{z}}} is untouchable under the pattern matches. {{{ data TFun z = MkTFun (forall y. T y -> z) data T a where T1 :: T Bool T2 :: T Char example () = MkTFun (\x -> case x of { T1 -> True; T2 -> False }) }}} The constraint solver gets stuck in this state in the {{{-ddump-tc- trace}}} (I grabbed this from the middle because the taus become sks after a certain point and I didn't intend for that to be relevant). {{{ solveNestedImplications starting { solveImplication { Implic { TcLevel = 2 Skolems = y_aWl[sk:2] No-eqs = True Status = Unsolved Given = Wanted = WC {wc_impl = Implic { TcLevel = 3 Skolems = No-eqs = False Status = Unsolved Given = co_aWq :: y_aWl[sk:2] GHC.Prim.~# Bool Wanted = WC {wc_simple = [WD] hole{co_aWB} {1}:: z_aWj[tau:1] GHC.Prim.~# Bool (CNonCanonical)} Binds = EvBindsVar a pattern with constructor: T1 :: T Bool, in a case alternative } Implic { TcLevel = 3 Skolems = No-eqs = False Status = Unsolved Given = co_aWt :: y_aWl[sk:2] GHC.Prim.~# Char Wanted = WC {wc_simple = [WD] hole{co_aWC} {1}:: z_aWj[tau:1] GHC.Prim.~# Bool (CNonCanonical)} Binds = EvBindsVar a pattern with constructor: T2 :: T Char, in a case alternative }} Binds = EvBindsVar a type expected by the context: forall y. T y -> z_aWj[tau:1] } Inerts {Unsolved goals = 0} Inert fsks = [] }}} {{{co_aWB}}} and {{{co_aWC}}} do not float; their parent implication has a given equality (where {{{skolem_bound_here}}} is {{{False}}}), so the {{{floatEqualities}}} function gives up immediately. Thus, my first question is: Why wouldn't we want GHC to float {{{z[tau:1] ~ Bool}}} past {{{y[sk:2] ~ Bool}}} here? The rest of this comment explains why I don't think the existing examples answer that question. This simple rule that causes {{{floatEqualities}}} to currently give up here is motivated by examples found in {{{Note [Float Equalities out of Implications]}}} and also in Section 5.1 and Example 5.1 of jfp- outsidein.pdf (print pages 35 and 37). However, in all of those examples the given and the wanted equalities involve metavars with the same level. In this comment's example, the levels and {{{TcTyVarDetails}}} flavors are different and that seems relevant to me. In particular, because of the levels, {{{z := y}}} is not a valid assignment -- but such an assignment (which is valid when {{{level(y) <= level(z)}}}) motivates the conservative rule in both {{{Note [Float Equalities out of Implications]}}} and also Section 5.1 of the paper. Relatedly, Example 5.1 from the paper points out that an assignment akin to {{{z := F y}}} might become a solution; that assignment is also invalid if {{{level(y) > level(z)}}}. Your example from #[comment:11] ... {{{ data S a where MkS :: S Int g :: forall a. S a -> a -> () g x y = let h = \z -> ( z :: Int , case x of MkS -> [y,z]) in h (3 :: Int) `seq` () }}} ... gets stuck here in the {{{-ddump-tc-trace}}} ... {{{ setImplicationStatus(not-all-solved) } Implic { TcLevel = 1 Skolems = a_a1ln[sk:1] No-eqs = True Status = Unsolved Given = Wanted = WC {wc_impl = Implic { TcLevel = 2 Skolems = No-eqs = False Status = Unsolved Given = co_a1lH :: a_a1ln[sk:1] GHC.Prim.~# Int Wanted = WC {wc_simple = [WD] hole{co_a1lY} {2}:: b_a1ly[tau:1] GHC.Prim.~# [Int] (CNonCanonical)} Binds = EvBindsVar a pattern with constructor: MkS :: S Int, in a case alternative }} Binds = EvBindsVar the type signature for: g :: forall a. S a -> a -> () } Constraint solver steps = 3 unflattenGivens [] End simplifyTop } reportUnsolved { }}} ... as it should! The given and the wanted both have type variables of the same level, so {{{b := a}}} is a valid assignment. The example from #[comment:5] that directly motivated this exact ticket is a little more involved. In that case, the given equality is between variables of level 2 and 3, while the wanted equality is for a variable of level 2. To some degree, the {{{level(y) > level(z)}}} condition does hold here. It's certainly more subtle than my example, but maybe the let-bound skolem rule could be subsumed by my hypothetical "float equalities past equalities if the involved levels are OK" rule. My second question is: Does such a "float equalities past equalities if the involved levels are OK" rule seem feasible/practical? Has that been investigated at all? I'm particularly worried I'm overlooking some pitfall due to the open world assumption, though skolems seem relatively localized. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 07:54:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 07:54:23 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.da60dd36326e34b4008c19e371a10275@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Changes (by osa1): * differential: Phab:D5196 => Phab:D5196, Phab:D5201 Comment: > As for the type-driven rewriting This is not possible unless we somehow distinguish "stuff that directly points to a value (without going through indirections)" from other at the type level. ---- I submitted another diff that fixes this bug in Cmm. It also does a bunch of simplifications in other parts of the compiler (removes notes, special cases, and hacks for `dataToTag#`). Here are some example code we generate: Program: {{{ data T = T1 | T2 main = do print (I# (dataToTag# f)) print (I# (dataToTag# a)) where {-# NOINLINE f #-} f = T2 {-# NOINLINE a #-} a = f }}} For the first `dataToTag#` we generate: {{{ _s1yo::I64 = 1; // CmmAssign }}} for the second {{{ // ======= DATA TO TAG ======== Hp = Hp - 16; // CmmAssign I64[Sp - 24] = c1yE; // CmmStore R1 = a_r1lF_closure; // CmmAssign Sp = Sp - 24; // CmmAssign if (R1 & 7 != 0) goto c1yE; else goto c1yF; // CmmCondBranch c1yF: // global call (I64[R1])(R1) returns to c1yE, args: 8, res: 8, upd: 24; // CmmCall, this is where we evalaute the arg c1yE: // global _c1yD::I64 = R1; // CmmAssign // ======= DATA TO TAG SMALL FAMILY ======== _s1yr::I64 = _c1yD::I64 & 7 - 1; // CmmAssign, read the tag bits }}} If I make this type a "big family", then we generate (for the second `dataToTag#`) {{{ // ======= DATA TO TAG ======== Hp = Hp - 16; // CmmAssign I64[Sp - 24] = c1A0; // CmmStore R1 = a_r1mL_closure; // CmmAssign Sp = Sp - 24; // CmmAssign if (R1 & 7 != 0) goto c1A0; else goto c1A1; // CmmCondBranch c1A1: // global call (I64[R1])(R1) returns to c1A0, args: 8, res: 8, upd: 24; // CmmCall, enter the argument c1A0: // global _c1zZ::I64 = R1; // CmmAssign // ======= DATA TO TAG GENERAL CASE ======== _s1zN::I64 = %MO_UU_Conv_W32_W64(I32[I64[_c1zZ::I64 & (-8)] - 4]); // CmmAssign, read info table }}} The patch is not ready (I'll need to update some notes, I also left some TODOs and questions in the code) but it fixes the bug and demonstrates that this is possible (and even easy) to do in Cmm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 10:12:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 10:12:26 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.3251191bd22e7c47075adb832cf2d485@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): So we mention this "optimisation" without describing what it is, and I realized that that may cause some confusion so let's define it. By "optimisation" I mean that in some cases when compiling `dataToTag#` we can avoid entering the argument, because we already know enough about it. - In compile time we sometimes know that the argument is definitely some constructor `C`. For example, in the example in comment:43, we know that `f` is `T2`, so we should be able to compile `dataToTag# f` to `1#`. Another example is `case foo of X -> ... dataToTag# foo ...`. Note that we currently (with GHC 8.6 and HEAD) don't do this for `f` in comment:43, even with -O2. However with Phab:D5201 `f` in comment:43 is optimised to `1#` in Cmm level. The case expression is optimised in all versions. (both diffs preserve Core transformations and rules, so anything optimised at Core level by GHC HEAD will still be optimised) (I don't know why `dataToTag# f` in comment:43 is not optimised in Core level, but perhaps that can be tracked in another ticket) - In compile time we sometimes know that a value is already evaluated, but we don't know specifics (i.e. which constructor it is). For example, in a pattern match, a variable binding a strict field should be evaluated. Another example is `let !foo = f x in ... dataToTag# foo ...`. In these cases we should be able to avoid entering the argument. There are a few problems with this: First, as #14677 demonstrates, we sometimes fail to tag values properly. So for example if a strict field's type is small, we still can't look at tag bits, we need to read the info table. Second, the analysis for this should be more strict than the current `exprIsHNF` or `isEvaldUnfolding` (see Note [Always introduce case around dataToTag# arg] in comment:30 for what goes wrong otherwise). However, we currently don't have an analysis for this, and I don't know how easy it'd be to implement in Core (remember that we don't know about CAFs in Core until CorePrep, and this information is necessary for this analysis). I don't know if going into the trouble of implementing a new analysis in Core just for this purpose is worth it. - For all other cases we need to enter the argument in runtime. If the argument is a small type then we can look at the tag bits, otherwise we read the info table. In other words, case (1) is when we know the constructor of the argument in compile time, case (2) is when we don't know the constructor, but we know that the argument is already evaluated, case (3) is when we don't know anything about the argument. Looking at the tag bits in (3) is currently only done by Phab:D5201, but it could be easily added to other implementations. (2) is currently only done by GHC 8.6 (and HEAD), but it's done incorrectly (thus this ticket). I think we should avoid this at least for now. (1) Is done best in Phab:D5201, because we check lambda form of the argument in Cmm, which optimises some code that escapes Core optimisations. However, I think we should be able to improve simplifier somehow to optimise `dataToTag# f` in comment:43. We can track this in another ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 10:29:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 10:29:52 -0000 Subject: [GHC] #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types In-Reply-To: <044.6bc4fafa2c23357f8677ca0feb803442@haskell.org> References: <044.6bc4fafa2c23357f8677ca0feb803442@haskell.org> Message-ID: <059.6a136177c294a15cdcb5a8a887274930@haskell.org> #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 10:48:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 10:48:49 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.c25b18ec7416cd3b529118dfd7cb749b@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): Here's my (hopefully final) proposal: (1) is best done in Core. I'll remove the relevant code from Phab:D5201. For cases that should be optimised but currently aren't, we can open a new ticket and track the progress there. (2) is best avoided. It opens a can of worms, and it's what caused this ticket. (3) Should be done in Cmm. Phab:D5201 already does this, but we need to do some refactoring to be able to reliably check whether the argument type is a large or small family (to decide whether to check tag bits of read the info table). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 12:19:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 12:19:16 -0000 Subject: [GHC] #15009: Float equalities past local equalities In-Reply-To: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> References: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> Message-ID: <062.ee52a2c8c50504e784089717697dae81@haskell.org> #15009: Float equalities past local equalities -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: gadt/T15009 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > How is it that a_a2do occurs both as a_a2do[sk:2] and also as a_a2do[tau:2] in this implication tree? I strongly suspect that `a_a2do` started life as a unification variable `[tau:2]`, but we ended up generalising over it, so we skolemised it to `a_a2do`. That is we unify `a_a2do := a_a2do[sk]`. I believe that the implication tree is being displayed here without zonking; that is, without taking account of unifications. I'd be shocked if we had both, but ''without'' having `a_a2do[tau]` being unified with `a_a2do[sk]`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 12:32:25 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 12:32:25 -0000 Subject: [GHC] #15009: Float equalities past local equalities In-Reply-To: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> References: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> Message-ID: <062.0113386f8f936e43def2e76755487d43@haskell.org> #15009: Float equalities past local equalities -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: gadt/T15009 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What, precisely, is the rule you propose? I don't know precisely what "float equalities past equalities if the involved levels are OK" means. I think you mean something like "you can float a wanted equality W past a given equality G iff that G not to be used in any solution of W. But it's hard to come up with an implementation of that rule, other than "don't float past equalities". Whatever we choose must be simple and predictable. I worry about things like this {{{ Implic { TcLevel = 3 , Skolems = [] , Given = (y ~ Bool, F y Int ~ Char) , Wanted = z[tau:2] ~ F Bool t[tau:1] } }}} Can I float that wanted? Well, no. Maybe, later, we'll discover that `t := Int`. Then our `F Bool Int` can be rewritten to `F y Int` (with the local equality), and thence to Char. But if we floated it out we'd get stuck. If you have a better rule, that'd be great. I just don't see it yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 12:33:09 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 12:33:09 -0000 Subject: [GHC] #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types In-Reply-To: <044.6bc4fafa2c23357f8677ca0feb803442@haskell.org> References: <044.6bc4fafa2c23357f8677ca0feb803442@haskell.org> Message-ID: <059.f1bcca9705fc5f1458c5605ae33c5103@haskell.org> #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Good point. Types with different numbers of arguments should be apart. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 13:16:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 13:16:48 -0000 Subject: [GHC] #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types In-Reply-To: <044.6bc4fafa2c23357f8677ca0feb803442@haskell.org> References: <044.6bc4fafa2c23357f8677ca0feb803442@haskell.org> Message-ID: <059.0f53d574340ff2da41bd2ea01a7e6362@haskell.org> #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9371 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #9371 Comment: Ah, I think I've figured out why this is happening. This all dates back to #9371, the fix for which is [http://git.haskell.org/ghc.git/blob/fc2ff6dd7496a33bf68165b28f37f40b7d647418:/compiler/types/Unify.hs#l348 explained] in `Note [Lists of different lengths are MaybeApart]`: {{{#!hs {- Note [Lists of different lengths are MaybeApart] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It is unusual to call tcUnifyTys or tcUnifyTysFG with lists of different lengths. The place where we know this can happen is from compatibleBranches in FamInstEnv, when checking data family instances. Data family instances may be eta-reduced; see Note [Eta reduction for data family axioms] in TcInstDcls. We wish to say that D :: * -> * -> * axDF1 :: D Int ~ DFInst1 axDF2 :: D Int Bool ~ DFInst2 overlap. If we conclude that lists of different lengths are SurelyApart, then it will look like these do *not* overlap, causing disaster. See Trac #9371. In usages of tcUnifyTys outside of family instances, we always use tcUnifyTys, which can't tell the difference between MaybeApart and SurelyApart, so those usages won't notice this design choice. -} }}} If it's not clear from context, this issue was that both of these data family instances were present: {{{#!hs data family D :: * -> * -> * data instance D Int a data instance D Int Bool }}} Normally, it would be quite simple to check that `D Int a` and `D Int Bool` overlapped. However, GHC eta-reduces `forall a. D Int a ~ DFInst1 a` to just `D Int ~ DFInst1`, which means that GHC was checking if `D Int` and `D Int Bool` were apart—and before #9371 was fixed, GHC mistakenly concluded that they //were// apart! This Note is referenced from [http://git.haskell.org/ghc.git/blob/fc2ff6dd7496a33bf68165b28f37f40b7d647418:/compiler/types/Unify.hs#l1038 unify_tys] (which determines whether things are apart in type family instance consistency checks): {{{#!hs unify_tys :: UMEnv -> [Type] -> [Type] -> UM () unify_tys env orig_xs orig_ys = go orig_xs orig_ys where go [] [] = return () go (x:xs) (y:ys) -- See Note [Kind coercions in Unify] = do { unify_ty env x y (mkNomReflCo $ typeKind x) ; go xs ys } go _ _ = maybeApart -- See Note [Lists of different lengths are MaybeApart] }}} And indeed, inserting some traces in `unify_tys` reveals that it's trying to unify `[* -> * -> k_a1B5, Int, Bool]` and `[* -> k_a1Bi, Int]` (the arguments to `D` in each instance of `F`), which are of different lengths, causing `unify_tys` to return `maybeApart` and later conclude that `F (D Int)` overlaps with `F (D Int Bool)`. I'm still not sure what exactly should be done here. If you revert the fix for #9371, then the program in this ticket will compile, but then the `T9371` test case will segfault again. At the same time, the fix for #9371 is too conservative, since it rules out the perfectly valid program in this ticket. There must be some sort of middle ground here, but I don't know what that would be. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 13:28:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 13:28:32 -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.860fec73a59a67f823ba39998e556a65@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): Phab:D5180 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"bd7898537768f936d05c0c83eef1cd9b00933347/ghc" bd789853/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bd7898537768f936d05c0c83eef1cd9b00933347" Parse the (!) type operator and allow type operators in existential context Summary: Improve the way `(!)`, `(~)`, and other type operators are handled in the parser, fixing two issues at once: 1. `(!)` can now be used as a type operator that respects fixity and precedence (#15457) 2. Existential context of a data constructor no longer needs parentheses (#15675) In addition to that, with this patch it is now trivial to adjust precedence of the `{-# UNPACK #-}` pragma, as suggested in https://ghc.haskell.org/trac/ghc/ticket/14761#comment:7 There was a small change to API Annotations. Before this patch, `(~)` was a strange special case that produced an annotation unlike any other type operator. After this patch, when `(~)` or `(!)` are used to specify strictness they produce AnnTilde and AnnBang annotations respectively, and when they are used as type operators, they produce no annotations. Test Plan: Validate Reviewers: simonpj, bgamari, alanz, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, mpickering, carter GHC Trac Issues: #15457, #15675 Differential Revision: https://phabricator.haskell.org/D5180 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 13:28:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 13:28:32 -0000 Subject: [GHC] #15675: Type operators in existential context cannot be parsed In-Reply-To: <048.82b49a5797d809055f4cfc780ae00441@haskell.org> References: <048.82b49a5797d809055f4cfc780ae00441@haskell.org> Message-ID: <063.ab8a820f0bb5bf482e3751249e3822dc@haskell.org> #15675: Type operators in existential context cannot be parsed -------------------------------------+------------------------------------- Reporter: int-index | 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: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5180 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"bd7898537768f936d05c0c83eef1cd9b00933347/ghc" bd789853/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bd7898537768f936d05c0c83eef1cd9b00933347" Parse the (!) type operator and allow type operators in existential context Summary: Improve the way `(!)`, `(~)`, and other type operators are handled in the parser, fixing two issues at once: 1. `(!)` can now be used as a type operator that respects fixity and precedence (#15457) 2. Existential context of a data constructor no longer needs parentheses (#15675) In addition to that, with this patch it is now trivial to adjust precedence of the `{-# UNPACK #-}` pragma, as suggested in https://ghc.haskell.org/trac/ghc/ticket/14761#comment:7 There was a small change to API Annotations. Before this patch, `(~)` was a strange special case that produced an annotation unlike any other type operator. After this patch, when `(~)` or `(!)` are used to specify strictness they produce AnnTilde and AnnBang annotations respectively, and when they are used as type operators, they produce no annotations. Test Plan: Validate Reviewers: simonpj, bgamari, alanz, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, mpickering, carter GHC Trac Issues: #15457, #15675 Differential Revision: https://phabricator.haskell.org/D5180 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 13:35:33 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 13:35:33 -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.eed43f5f907b29663d7689bc11293f44@haskell.org> #15457: (~) and (!) are parsed inconsistently in types (plus documentation warts) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: int-index Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_compile/T15457 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5180 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => parser/should_compile/T15457 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 13:36:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 13:36:15 -0000 Subject: [GHC] #15675: Type operators in existential context cannot be parsed In-Reply-To: <048.82b49a5797d809055f4cfc780ae00441@haskell.org> References: <048.82b49a5797d809055f4cfc780ae00441@haskell.org> Message-ID: <063.d78f5e1a6a24e9d7e1bb215e29d9a5c4@haskell.org> #15675: Type operators in existential context cannot be parsed -------------------------------------+------------------------------------- Reporter: int-index | Owner: int-index Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | parser/should_compile/T15675 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5180 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => parser/should_compile/T15675 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 13:36:58 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 13:36:58 -0000 Subject: [GHC] #15592: Type families without CUSKs cannot be given visible kind variable binders In-Reply-To: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> References: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> Message-ID: <065.e07e8217b4683790aea48748f6b4a6a4@haskell.org> #15592: Type families without CUSKs cannot be given visible kind variable binders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | TypeApplications, TypeFamilies, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14880 | Blocking: Related Tickets: #15591 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I discovered that this bug fix has a visible effect! Consider this in `GHC.Records`: {{{ -- | Constraint representing the fact that the field @x@ belongs to -- the record type @r@ and has field type @a at . This will be solved -- automatically, but manual instances may be provided as well. class HasField (x :: k) r a | x r -> a where -- | Selector function to extract the field from the record. getField :: r -> a }}} What is the kind of `HasField` and type of `getField`? As of today, GHC says {{{ HasField :: forall {k}. k -> * -> * -> Constraint getField :: forall {k] (x::k) r a. HasField x r a => r -> a }}} But actually, because of the `(x :: k)` in the class decl, the `k` is `Specified`. So the correct kind and type are: {{{ HasField :: forall k. k -> * -> * -> Constraint getField :: forall k (x::k) r a. HasField x r a => r -> a }}} So in a visible type application of `getField` you'd have to write `getField @Symbol @x`. But that is not what Adam intended. We don't want to be forced to write that kind, even in a visible type application. We want `k` to be `Inferred`. I can achieve this for now by changing the decl to {{{ class HasField x r a | x r -> a where getField :: r -> a }}} so removing the `:: k` from the decl. But that is rather subtle. I'm looking forward to explicit kind signatures... but NB: they need to be able to express the `Inferred`/`Specified` distinction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 13:42:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 13:42:21 -0000 Subject: [GHC] #15235: GHCi's claim of infixr 0 (->) is a lie In-Reply-To: <050.1dea13c2dffcf4fb3726d468418c6455@haskell.org> References: <050.1dea13c2dffcf4fb3726d468418c6455@haskell.org> Message-ID: <065.848bc350378a086c2d9dcaac2200ba3f@haskell.org> #15235: GHCi's claim of infixr 0 (->) is a lie -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15236 | Differential Rev(s): Phab:D5199 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: => Phab:D5199 Comment: The patch in comment:7 has been superseded by Phab:D5199. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 14:41:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 14:41:07 -0000 Subject: [GHC] #15675: Type operators in existential context cannot be parsed In-Reply-To: <048.82b49a5797d809055f4cfc780ae00441@haskell.org> References: <048.82b49a5797d809055f4cfc780ae00441@haskell.org> Message-ID: <063.e721b44411292dd3d14d007b11218d2f@haskell.org> #15675: Type operators in existential context cannot be parsed -------------------------------------+------------------------------------- Reporter: int-index | Owner: int-index Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | parser/should_compile/T15675 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5180 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks for doing this Vladislav. I think you plan to nail #1087 in the same way, which would be even better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 14:52:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 14:52:07 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.1af66e98af9abd4e4a2fcf448bf3ca76@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by simonpj): Comments about Phab:D5201. I'm not looking at the details yet (it's just a draft), but * I think this is the Right Place to deal with `dataToTag#`. Bravo. * The known-constructor case surely will be handled in the simplifier; if not now then soon. Handling it here is not wrong, but probably unnecesssary. * The thing that we CAN ONLY handle here is {{{ ...(case x of y { A -> blah DEFAULT -> ....(dataToTag# y)... }}} Here we know that `y` really points to the value, so `dastaToTag#` does not need to do a redundant eval. However I have just realised that this optimisation is available for '''any''' case expression, not just `dataToTag#`. Consider {{{ ...(case x of y { A -> blah DEFAULT -> ....(case y of B -> blah2 C -> blah3 )... }}} Here we know that `y` is fully evaluated and points to the final value; that's the promise of the outer case expression. So we can directly test y's tag bits without worrying that it might be unevaluated, need to build a return point and info table etc. Ha! I'm not sure how common this is. But perhaps it is worth a separate ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:03:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:03:39 -0000 Subject: [GHC] #15648: Core Lint error with source-level unboxed equality In-Reply-To: <050.b1c8c377aa63cdac74b3d157d20320e2@haskell.org> References: <050.b1c8c377aa63cdac74b3d157d20320e2@haskell.org> Message-ID: <065.ce2b9512928069129d2d8ec2b85723f5@haskell.org> #15648: Core Lint error with source-level unboxed equality -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15209 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"e7ff9344a18c58c7b321566545fd37c10c609fb1/ghc" e7ff934/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e7ff9344a18c58c7b321566545fd37c10c609fb1" Make Lint check that for CoVars more carefully Check than an Id of type (t1 ~# t2) is a CoVar; if not, it ends up in the wrong simplifier environment, with strange consequences. (Trac #15648) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:03:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:03:39 -0000 Subject: [GHC] #15695: Core Lint error, from -fobject-code + defer type errors + pattern synonyms + other stuff In-Reply-To: <051.924cbdebca03c5aa89a4c1b89bc4850d@haskell.org> References: <051.924cbdebca03c5aa89a4c1b89bc4850d@haskell.org> Message-ID: <066.7122c5303e9cdf78d2962b4c18de32bb@haskell.org> #15695: Core Lint error, from -fobject-code + defer type errors + pattern synonyms + other stuff -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"02b303eed0170983921877801e57f55d012db301/ghc" 02b303ee/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="02b303eed0170983921877801e57f55d012db301" Do not mark CoVars as dead in the occur-anal For years we have been marking CoVars as dead, becuase we don't gather occurrence info from types. This is obviously wrong and caused Trac #15695. See Note [Do not mark CoVars as dead] in OccurAnal. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:03:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:03:40 -0000 Subject: [GHC] #15692: GHC panic from pattern synonyms + deferred type errors In-Reply-To: <051.39157d43d1b8d263a8e2728339a9f8aa@haskell.org> References: <051.39157d43d1b8d263a8e2728339a9f8aa@haskell.org> Message-ID: <066.7aa6ca7b60146381602c87b3f5893912@haskell.org> #15692: GHC panic from pattern synonyms + deferred type errors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"9ebfa03d9e9cbf79f698b5d4bd39e799e4e9a02c/ghc" 9ebfa03/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9ebfa03d9e9cbf79f698b5d4bd39e799e4e9a02c" Fail fast on pattern synonyms We were recovering too eagerly from errors in pattern-synonym type inference, leading to a cascade of confusing follow up errors (Trac #15685, #15692). The underlying issue is that a pattern synonym should have a closed, fixed type, with no unification variables in it. But it wasn't! Fixing this made me change the interface to simplifyInfer slightly. Instead of /emitting/ a residual implication constraint, it now /returns/ it, so that the caller can decide what to do. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:03:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:03:40 -0000 Subject: [GHC] #15592: Type families without CUSKs cannot be given visible kind variable binders In-Reply-To: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> References: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> Message-ID: <065.e92ff43532e0b394ec00391ba10f3cd3@haskell.org> #15592: Type families without CUSKs cannot be given visible kind variable binders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | TypeApplications, TypeFamilies, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14880 | Blocking: Related Tickets: #15591 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2f09753f96207c12efd43090f5de55b05aef35d3/ghc" 2f09753f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2f09753f96207c12efd43090f5de55b05aef35d3" Distinguish Inferred from Specified tyvars In a declared type we need to distinguish between Inferred and Specified type variables. This was exposed by Trac #15592. See Note [Work out final tyConBinders] in TcTyClsDecls. I had to change the definition of HasField in GHC.Records to class HasField x r a | x r -> a where so as to have an /inferred/ kind argument rather than a specfied one. So HasField :: forall {k}. k -> * -> * -> Constraint }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:03:40 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:03:40 -0000 Subject: [GHC] #15685: Pattern signature not inferred In-Reply-To: <051.c5171c2fbdeaddb4c2ac22c9d434e0a0@haskell.org> References: <051.c5171c2fbdeaddb4c2ac22c9d434e0a0@haskell.org> Message-ID: <066.b837fec1ab84c2693734e30a42e3496e@haskell.org> #15685: Pattern signature not inferred -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"9ebfa03d9e9cbf79f698b5d4bd39e799e4e9a02c/ghc" 9ebfa03/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9ebfa03d9e9cbf79f698b5d4bd39e799e4e9a02c" Fail fast on pattern synonyms We were recovering too eagerly from errors in pattern-synonym type inference, leading to a cascade of confusing follow up errors (Trac #15685, #15692). The underlying issue is that a pattern synonym should have a closed, fixed type, with no unification variables in it. But it wasn't! Fixing this made me change the interface to simplifyInfer slightly. Instead of /emitting/ a residual implication constraint, it now /returns/ it, so that the caller can decide what to do. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:05:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:05:36 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.ec63ffffc3d86be224d61e1814a25f47@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by simonpj): > In compile time we sometimes know that a value is already evaluated, but we don't know specifics This ticket has convinced me that the property that "y is a correctly tagged pointer directly to an evaluated value" is ''extremely delicate''. The only time we are really sure of this is in the case-binder of a case expression: {{{ case e of y }}} In `` we know that `y` really is a tagged pointer and points to the value. I used to think that this was also true of the strict fields of a data constructor, but not so! See comment:36. Moreover, as comment:36 shows, the Simplifier (for good reasons) does not guaranteed to maintain the Delicate Property, even it if it holds at some point. Only the code generator knows for sure. Lets ''not'' attempt to do this in Core. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:07:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:07:46 -0000 Subject: [GHC] #15695: Core Lint error, from -fobject-code + defer type errors + pattern synonyms + other stuff In-Reply-To: <051.924cbdebca03c5aa89a4c1b89bc4850d@haskell.org> References: <051.924cbdebca03c5aa89a4c1b89bc4850d@haskell.org> Message-ID: <066.67d8e623413366a89ec1ede2db35f4a4@haskell.org> #15695: Core Lint error, from -fobject-code + defer type errors + pattern synonyms + other stuff -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | patsyn/should_fail/T15695 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => patsyn/should_fail/T15695 * status: new => merge Comment: Thanks for the great report -- a palpable bug in the occurrence analyser. Probably merge-able if we release another 8.6 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:09:38 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:09:38 -0000 Subject: [GHC] #15695: Core Lint error, from -fobject-code + defer type errors + pattern synonyms + other stuff In-Reply-To: <051.924cbdebca03c5aa89a4c1b89bc4850d@haskell.org> References: <051.924cbdebca03c5aa89a4c1b89bc4850d@haskell.org> Message-ID: <066.080ddc651834bbd4cd039e74fc5e9b1b@haskell.org> #15695: Core Lint error, from -fobject-code + defer type errors + pattern synonyms + other stuff -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | patsyn/should_fail/T15695 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: 8.6.1 => 8.6.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:11:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:11:21 -0000 Subject: [GHC] #15592: Type families without CUSKs cannot be given visible kind variable binders In-Reply-To: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> References: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> Message-ID: <065.5e20ddb748a583236ad5ff7eebfd1ba5@haskell.org> #15592: Type families without CUSKs cannot be given visible kind variable binders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | TypeApplications, TypeFamilies, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14880 | Blocking: Related Tickets: #15591 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK so I've done the first bit. We still need to address comment:9 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:12:38 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:12:38 -0000 Subject: [GHC] #15692: GHC panic from pattern synonyms + deferred type errors In-Reply-To: <051.39157d43d1b8d263a8e2728339a9f8aa@haskell.org> References: <051.39157d43d1b8d263a8e2728339a9f8aa@haskell.org> Message-ID: <066.b38ad67cdbbdbd7f6093a4bd517803a1@haskell.org> #15692: GHC panic from pattern synonyms + deferred type errors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | patsyn/should_fail/T15692 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => patsyn/should_fail/T15692 Comment: Thanks. This fix could probably be merged. It modifies a bit more code than I'd usually like in a patch-release, but I'm pretty confident. And it validates of course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:13:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:13:37 -0000 Subject: [GHC] #15685: Pattern signature not inferred In-Reply-To: <051.c5171c2fbdeaddb4c2ac22c9d434e0a0@haskell.org> References: <051.c5171c2fbdeaddb4c2ac22c9d434e0a0@haskell.org> Message-ID: <066.c7a0c1330cf40e8852a1f9070c72c263@haskell.org> #15685: Pattern signature not inferred -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | patsyn/should_fail/T15685 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => patsyn/should_fail/T15685 Comment: See post-commit comment on #15692 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:13:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:13:57 -0000 Subject: [GHC] #15692: GHC panic from pattern synonyms + deferred type errors In-Reply-To: <051.39157d43d1b8d263a8e2728339a9f8aa@haskell.org> References: <051.39157d43d1b8d263a8e2728339a9f8aa@haskell.org> Message-ID: <066.7e9440e9c85833b23976ec8d61d53311@haskell.org> #15692: GHC panic from pattern synonyms + deferred type errors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | patsyn/should_fail/T15692 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: 8.6.1 => 8.6.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:17:09 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:17:09 -0000 Subject: [GHC] #13365: Notify user when adding a CUSK might help fix a type error In-Reply-To: <047.53ccade2bc7f7794ee330b834d4cc090@haskell.org> References: <047.53ccade2bc7f7794ee330b834d4cc090@haskell.org> Message-ID: <062.506f45bceaff7593c7140e29a1e2a94a@haskell.org> #13365: Notify user when adding a CUSK might help fix a type error -------------------------------------+------------------------------------- Reporter: crockeea | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14139, #14207 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): #11498 is another example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:18:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:18:01 -0000 Subject: [GHC] #15685: Pattern signature not inferred In-Reply-To: <051.c5171c2fbdeaddb4c2ac22c9d434e0a0@haskell.org> References: <051.c5171c2fbdeaddb4c2ac22c9d434e0a0@haskell.org> Message-ID: <066.2cca60fbf1dcbcf058cbfc95df700e5f@haskell.org> #15685: Pattern signature not inferred -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | patsyn/should_fail/T15685 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: 8.6.1 => 8.6.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:18:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:18:18 -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.66f6af86bf494637a1c13851a8795aa2@haskell.org> #15383: T3171 doesn't terminate with Interrupted message on Darwin -------------------------------------+------------------------------------- Reporter: bgamari | 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: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15463 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * os: MacOS X => Unknown/Multiple Comment: I'm disabling this test for now until we can investigate. Raising priority so this happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:33:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:33:16 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.7f1c95abe9990ae9057713cc1e41663f@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: goldfire (added) Comment: I think the Right Thing is to make TH syntax look like Hs syntax. After all, rational literals in TH are (as you show) subject to precisely the problem of this ticket, and are amenable to precisely the same solution. When we complete the Trees That Grow epic that equivalence will become true by construction. Richard Eisenberg is the TH tzar; let's ask him. Generally we have changed the details of TH syntax in every GHC release, and I don't think it's a major source of complaints. To get rolling, though, you could do some approximate way of converting a `Rational` to literal in the form we have mapped out here. The passage through TH would not be fully faithful, but it'd be close. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:38:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:38:56 -0000 Subject: [GHC] #4861: Documentation for base does not include special items In-Reply-To: <051.5ee4c1527610ef4964c665e655014652@haskell.org> References: <051.5ee4c1527610ef4964c665e655014652@haskell.org> Message-ID: <066.dc87e5d7d077eee2e26e62028a8abd07@haskell.org> #4861: Documentation for base does not include special items -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: ⊥ Component: Core Libraries | Version: 7.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): Phab:D5167 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"60b547b583f27f436912acd70e674cd9f34d72b2/ghc" 60b547b5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="60b547b583f27f436912acd70e674cd9f34d72b2" Document the list data type Summary: Also qualified some identifier hyperlinks along the way. Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #4861 Differential Revision: https://phabricator.haskell.org/D5158 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:38:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:38:56 -0000 Subject: [GHC] #15233: You can always set fixity of (:), with no effect In-Reply-To: <051.8c3b112281bc7b731cc4cf74f7b2040c@haskell.org> References: <051.8c3b112281bc7b731cc4cf74f7b2040c@haskell.org> Message-ID: <066.40d3a5154d09dca4a3a6638660a4a55e@haskell.org> #15233: You can always set fixity of (:), with no effect -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch 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): Phab:D5167 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"feb8a671a4e92922ddac108686f0eace97dd331f/ghc" feb8a67/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="feb8a671a4e92922ddac108686f0eace97dd331f" Improve generated `GHC.Prim` docs Summary: * Extended `genprimcode` to generate Haddock-compatible deprecations, as well as displaying information about which functions are LLVM-only and which functions can fail with an unchecked exception. * Ported existing deprecations to the new format, and also added a deprecation on `par#` (see Trac #15227). * Emit an error on fixity/deprecation of builtins, unless we are processing the module in which that name is defined (see Trac #15233). That means the following is no longer accepted (outside of `GHC.Types`): ``` infixr 7 : {-# DEPRECATED (:) "cons is deprecated" #-} ``` * Generate `data (->) a b` with docs and fixity in `GHC.Prim`. This means: GHC can now parse `data (->) a b` and `infixr 0 ->` (only in `GHC.Prim`) and `genprimcode` can digest `primtype (->) a b` (See Trac #4861) as well as some misc fixes along the way. Reviewers: bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, mpickering, carter GHC Trac Issues: #15227, #15233, #4861 Differential Revision: https://phabricator.haskell.org/D5167 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:38:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:38:56 -0000 Subject: [GHC] #15227: Add PrelRules for par# In-Reply-To: <045.f292885fced757ba9c18aa7457f6b1f1@haskell.org> References: <045.f292885fced757ba9c18aa7457f6b1f1@haskell.org> Message-ID: <060.b5ce3492551390fe4b26ca7890792460@haskell.org> #15227: Add PrelRules for par# -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: bug | Status: new Priority: low | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"feb8a671a4e92922ddac108686f0eace97dd331f/ghc" feb8a67/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="feb8a671a4e92922ddac108686f0eace97dd331f" Improve generated `GHC.Prim` docs Summary: * Extended `genprimcode` to generate Haddock-compatible deprecations, as well as displaying information about which functions are LLVM-only and which functions can fail with an unchecked exception. * Ported existing deprecations to the new format, and also added a deprecation on `par#` (see Trac #15227). * Emit an error on fixity/deprecation of builtins, unless we are processing the module in which that name is defined (see Trac #15233). That means the following is no longer accepted (outside of `GHC.Types`): ``` infixr 7 : {-# DEPRECATED (:) "cons is deprecated" #-} ``` * Generate `data (->) a b` with docs and fixity in `GHC.Prim`. This means: GHC can now parse `data (->) a b` and `infixr 0 ->` (only in `GHC.Prim`) and `genprimcode` can digest `primtype (->) a b` (See Trac #4861) as well as some misc fixes along the way. Reviewers: bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, mpickering, carter GHC Trac Issues: #15227, #15233, #4861 Differential Revision: https://phabricator.haskell.org/D5167 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:38:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:38:56 -0000 Subject: [GHC] #4861: Documentation for base does not include special items In-Reply-To: <051.5ee4c1527610ef4964c665e655014652@haskell.org> References: <051.5ee4c1527610ef4964c665e655014652@haskell.org> Message-ID: <066.9187f00b13888146dc2454ccf0245a23@haskell.org> #4861: Documentation for base does not include special items -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: patch Priority: low | Milestone: ⊥ Component: Core Libraries | Version: 7.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): Phab:D5167 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"feb8a671a4e92922ddac108686f0eace97dd331f/ghc" feb8a67/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="feb8a671a4e92922ddac108686f0eace97dd331f" Improve generated `GHC.Prim` docs Summary: * Extended `genprimcode` to generate Haddock-compatible deprecations, as well as displaying information about which functions are LLVM-only and which functions can fail with an unchecked exception. * Ported existing deprecations to the new format, and also added a deprecation on `par#` (see Trac #15227). * Emit an error on fixity/deprecation of builtins, unless we are processing the module in which that name is defined (see Trac #15233). That means the following is no longer accepted (outside of `GHC.Types`): ``` infixr 7 : {-# DEPRECATED (:) "cons is deprecated" #-} ``` * Generate `data (->) a b` with docs and fixity in `GHC.Prim`. This means: GHC can now parse `data (->) a b` and `infixr 0 ->` (only in `GHC.Prim`) and `genprimcode` can digest `primtype (->) a b` (See Trac #4861) as well as some misc fixes along the way. Reviewers: bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, mpickering, carter GHC Trac Issues: #15227, #15233, #4861 Differential Revision: https://phabricator.haskell.org/D5167 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:38:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:38:56 -0000 Subject: [GHC] #7066: isInstance does not work for compound types In-Reply-To: <044.f26fdb7a0d5666f6e8ecfbb0861afaff@haskell.org> References: <044.f26fdb7a0d5666f6e8ecfbb0861afaff@haskell.org> Message-ID: <059.d066a88642cedef9380212dc7ec644b3@haskell.org> #7066: isInstance does not work for compound types -------------------------------------+--------------------------------- Reporter: edsko | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+--------------------------------- Comment (by Ryan Scott ): In [changeset:"85376570c5d34950b1bd8f6c575526e7ff789b84/ghc" 85376570/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="85376570c5d34950b1bd8f6c575526e7ff789b84" Documentation fixes in 'template-haskell' Summary: * Clarify the non-presence of derived classes in reified decls (#15167) * Clarify the shallowness of "reifyInstances" (#7066) * Mention that 'Typeable' instances are not found by reifyInstances (#11251) * Various Haddock markup issues fixed Reviewers: goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15167, #7066, #11251 Differential Revision: https://phabricator.haskell.org/D5197 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:38:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:38:56 -0000 Subject: [GHC] #11251: isInstance does not work on Typeable with base-4.8 anymore In-Reply-To: <045.6032ac627aa889ca8ac6f2a84e970c9c@haskell.org> References: <045.6032ac627aa889ca8ac6f2a84e970c9c@haskell.org> Message-ID: <060.c358ed358a1a048b2b6e95ae00b3a988@haskell.org> #11251: isInstance does not work on Typeable with base-4.8 anymore -------------------------------------+------------------------------------- Reporter: songzh | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Typeable, | isInstance Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"85376570c5d34950b1bd8f6c575526e7ff789b84/ghc" 85376570/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="85376570c5d34950b1bd8f6c575526e7ff789b84" Documentation fixes in 'template-haskell' Summary: * Clarify the non-presence of derived classes in reified decls (#15167) * Clarify the shallowness of "reifyInstances" (#7066) * Mention that 'Typeable' instances are not found by reifyInstances (#11251) * Various Haddock markup issues fixed Reviewers: goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15167, #7066, #11251 Differential Revision: https://phabricator.haskell.org/D5197 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:38:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:38:56 -0000 Subject: [GHC] #15167: DerivClause list is not populated for (TyConI (DataD ...)) In-Reply-To: <049.1da123fe6825387f79a8e9ada4e3ab34@haskell.org> References: <049.1da123fe6825387f79a8e9ada4e3ab34@haskell.org> Message-ID: <064.3e03d32a18585dda3ecc2c5cdf99b71a@haskell.org> #15167: DerivClause list is not populated for (TyConI (DataD ...)) -------------------------------------+------------------------------------- Reporter: 0xd34df00d | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | 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 Ryan Scott ): In [changeset:"85376570c5d34950b1bd8f6c575526e7ff789b84/ghc" 85376570/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="85376570c5d34950b1bd8f6c575526e7ff789b84" Documentation fixes in 'template-haskell' Summary: * Clarify the non-presence of derived classes in reified decls (#15167) * Clarify the shallowness of "reifyInstances" (#7066) * Mention that 'Typeable' instances are not found by reifyInstances (#11251) * Various Haddock markup issues fixed Reviewers: goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15167, #7066, #11251 Differential Revision: https://phabricator.haskell.org/D5197 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:40:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:40:39 -0000 Subject: [GHC] #15233: You can always set fixity of (:), with no effect In-Reply-To: <051.8c3b112281bc7b731cc4cf74f7b2040c@haskell.org> References: <051.8c3b112281bc7b731cc4cf74f7b2040c@haskell.org> Message-ID: <066.729e71b9b4b5e82e29f8b51a43e9881c@haskell.org> #15233: You can always set fixity of (:), with no effect -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_fail/T15233 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5167 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => parser/should_fail/T15233 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:42:38 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:42:38 -0000 Subject: [GHC] #4861: Documentation for base does not include special items In-Reply-To: <051.5ee4c1527610ef4964c665e655014652@haskell.org> References: <051.5ee4c1527610ef4964c665e655014652@haskell.org> Message-ID: <066.ba99ae9a543956d691b08c3dd2fadbc2@haskell.org> #4861: Documentation for base does not include special items -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.6.1 Component: Core Libraries | Version: 7.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:D5167 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed * milestone: ⊥ => 8.6.1 Comment: This eight-year old ticket has finally been fixed with the two commits above. Hooray! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 15:43:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 15:43:04 -0000 Subject: [GHC] #4861: Documentation for base does not include special items In-Reply-To: <051.5ee4c1527610ef4964c665e655014652@haskell.org> References: <051.5ee4c1527610ef4964c665e655014652@haskell.org> Message-ID: <066.a0f8e05642649a81875e04ea58d358aa@haskell.org> #4861: Documentation for base does not include special items -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.8.1 Component: Core Libraries | Version: 7.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:D5167 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 Thu Oct 4 16:21:03 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 16:21:03 -0000 Subject: [GHC] #15705: Confusing parser error in 8.6 Message-ID: <047.ea408fb5c8dae607c236808bbb29cc6e@haskell.org> #15705: Confusing parser error in 8.6 -------------------------------------+------------------------------------- Reporter: diatchki | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 (Parser) | 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: -------------------------------------+------------------------------------- Consider the following example: {{{ f x = case x of A -> 'a' B -> 'b' }}} The problem here is that `B` is misaligned, which is quite a common mistake, especially in a bigger case block. GHC reports the following error: {{{ Unexpected case expression in function application: case x of { A -> 'a' } You could write it with parentheses Or perhaps you meant to enable BlockArguments? }}} This is quite confusing, especially since the program won't parse, `BlockArguments` or not. My guess is that we are being a bit too eager with reporting the `BlockArguments` issue. One way to work around this would be to just remember if we used `BlockArguments` while parsing, but only do the check that the extension is enabled after a successful parse. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 16:25:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 16:25:56 -0000 Subject: [GHC] #15705: Confusing parser error in 8.6 In-Reply-To: <047.ea408fb5c8dae607c236808bbb29cc6e@haskell.org> References: <047.ea408fb5c8dae607c236808bbb29cc6e@haskell.org> Message-ID: <062.18941e9fce83bcf662a197663154447f@haskell.org> #15705: Confusing parser error in 8.6 -------------------------------------+------------------------------------- Reporter: diatchki | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 (Parser) | Keywords: Resolution: | BlockArguments Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => BlockArguments * cc: akio (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 16:55:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 16:55:17 -0000 Subject: [GHC] #4861: Documentation for base does not include special items In-Reply-To: <051.5ee4c1527610ef4964c665e655014652@haskell.org> References: <051.5ee4c1527610ef4964c665e655014652@haskell.org> Message-ID: <066.da174d89ba8ff5282fbc76538f548647@haskell.org> #4861: Documentation for base does not include special items -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.8.1 Component: Core Libraries | Version: 7.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:D5167 Wiki Page: | -------------------------------------+------------------------------------- Comment (by harpocrates): As far as GHC is concerned, this is fixed. Progress on the Haddock-side changes is tracked in https://github.com/haskell/haddock/issues/368. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 17:43:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 17:43:55 -0000 Subject: [GHC] #13256: Warn on out-of-range literals in pattern matches too In-Reply-To: <047.7ca58da29c25ea23cfcb20c42fd930ce@haskell.org> References: <047.7ca58da29c25ea23cfcb20c42fd930ce@haskell.org> Message-ID: <062.be15ffa3145e02377cfb1396bdc95e12@haskell.org> #13256: Warn on out-of-range literals in pattern matches too -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | 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:D5181 Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * status: new => patch * differential: => Phab:D5181 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 17:44:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 17:44:18 -0000 Subject: [GHC] #10930: missing empty-Enumeration and out-of-range warning for `Natural` In-Reply-To: <042.2b93c01d2c091805f9e006b42184d16c@haskell.org> References: <042.2b93c01d2c091805f9e006b42184d16c@haskell.org> Message-ID: <057.899fa7d135260cc7d73847434de10c35@haskell.org> #10930: missing empty-Enumeration and out-of-range warning for `Natural` -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #7881, #10929 | Differential Rev(s): Phab:D1306, Wiki Page: | Phab:D5181 -------------------------------------+------------------------------------- Changes (by harpocrates): * status: new => patch * differential: Phab:D1306 => Phab:D1306, Phab:D5181 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 18:06:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 18:06:17 -0000 Subject: [GHC] #9251: ghc does not expose branchless max/min operations as primops In-Reply-To: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> References: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> Message-ID: <060.5734189c89308652305d78766a3f7636@haskell.org> #9251: ghc does not expose branchless max/min operations as primops -------------------------------------+------------------------------------- Reporter: carter | Owner: osa1 Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9246 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ulysses4ever): Ben, I'm interested in this. For osa1's work: I don't see a patch. [https://lpaste.net/134455 His link above] has a tiny example program using something called `min##` which is not defined there. Is there a clear strategy on how to attack this ticket? Let's say, starting with the most conservative step: provide primop version of integer `min` / `max` which, for x86, is implemented in assembly (`CMOV` or SSE4's `PMINSD` / `PMAXSD`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 21:41:14 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 21:41:14 -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.85628ab390f122c7e2c0b107f9e5ee94@haskell.org> #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' ---------------------------------+---------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: infoneeded 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 George): I can confirm I don't see it with 8.6.1 final -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 21:43:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 21:43:55 -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.db2012f3e960daca4faead17bf8eabb9@haskell.org> #15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0 -------------------------------------+------------------------------------- Reporter: noah | Owner: tdammers 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 George): Shouldn't the milestone be moved to 8.8.1? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 22:47:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 22:47:00 -0000 Subject: [GHC] #9251: ghc does not expose branchless max/min operations as primops In-Reply-To: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> References: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> Message-ID: <060.a978747dcbf62fc474eda3fdd7cd5c28@haskell.org> #9251: ghc does not expose branchless max/min operations as primops -------------------------------------+------------------------------------- Reporter: carter | Owner: osa1 Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9246 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): ​> His link above has a tiny example program using something called min## which is not defined there. Whoops! Sorry about that; I had just assumed there was a patch sitting there. As you suggest, I would start by thinking about providing primops; in particular I would start by focusing on `Int#` and `Word#`. As pointed out above, floating point is a whole can of worms. However, before this I would first try to show that such a primop would improve real code. Afterall, introducing a primop means that we are forced to maintain that primop for eternity. This carries a cost which we want to ensure would be justified by the benefits it brings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 22:59:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 22:59:34 -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.7313c04ab4ba55f2fbb700f97890bb02@haskell.org> #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' ---------------------------------+---------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: infoneeded => closed * resolution: => fixed Comment: Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 23:16:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 23:16:24 -0000 Subject: [GHC] #9251: ghc does not expose branchless max/min operations as primops In-Reply-To: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> References: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> Message-ID: <060.600c5e188b084f6e4068e462e6985a21@haskell.org> #9251: ghc does not expose branchless max/min operations as primops -------------------------------------+------------------------------------- Reporter: carter | Owner: osa1 Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9246 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ulysses4ever): I agree with measure-first reasoning. How would one compare the performance of the current code with the one using primop which we haven't defined yet, though? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 23:38:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 23:38:29 -0000 Subject: [GHC] #11622: Annotating types in type familiy equations without parentheses In-Reply-To: <051.fa9ccc48e4902c5c4db8bb7f638000aa@haskell.org> References: <051.fa9ccc48e4902c5c4db8bb7f638000aa@haskell.org> Message-ID: <066.ecab9f433bd5e8ba960f3dcce5262276@haskell.org> #11622: Annotating types in type familiy equations without parentheses -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | 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:D5173 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"bace26aadaafa4064e78f9ed088c1e2217221acc/ghc" bace26a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bace26aadaafa4064e78f9ed088c1e2217221acc" Allow (unparenthesized) kind signatures Summary: This allows for things like `[t :: MyKind]`, `(a :: k, b)`, and so on. Test Plan: make TEST=T11622 && make TEST=T8708 Reviewers: RyanGlScott, bgamari, simonpj, goldfire, alanz Reviewed By: RyanGlScott, simonpj Subscribers: alanz, simonpj, rwbarton, mpickering, carter GHC Trac Issues: #11622, #8708 Differential Revision: https://phabricator.haskell.org/D5173 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 23:38:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 23:38:29 -0000 Subject: [GHC] #8708: Kind annotation in tuple not parsed In-Reply-To: <047.7299eca00fb25a2e788e2c82e2894717@haskell.org> References: <047.7299eca00fb25a2e788e2c82e2894717@haskell.org> Message-ID: <062.ad04f29364158aa05310b0f28cd5b79f@haskell.org> #8708: Kind annotation in tuple not parsed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.7 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11267, #11622 | Differential Rev(s): Phab:D5173 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"bace26aadaafa4064e78f9ed088c1e2217221acc/ghc" bace26a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bace26aadaafa4064e78f9ed088c1e2217221acc" Allow (unparenthesized) kind signatures Summary: This allows for things like `[t :: MyKind]`, `(a :: k, b)`, and so on. Test Plan: make TEST=T11622 && make TEST=T8708 Reviewers: RyanGlScott, bgamari, simonpj, goldfire, alanz Reviewed By: RyanGlScott, simonpj Subscribers: alanz, simonpj, rwbarton, mpickering, carter GHC Trac Issues: #11622, #8708 Differential Revision: https://phabricator.haskell.org/D5173 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 23:38:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 23:38:29 -0000 Subject: [GHC] #15235: GHCi's claim of infixr 0 (->) is a lie In-Reply-To: <050.1dea13c2dffcf4fb3726d468418c6455@haskell.org> References: <050.1dea13c2dffcf4fb3726d468418c6455@haskell.org> Message-ID: <065.95c9fa2c339129c60efc430531160f02@haskell.org> #15235: GHCi's claim of infixr 0 (->) is a lie -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15236 | Differential Rev(s): Phab:D5199 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"251e3424a96986fca5164a2397783a1c066558fc/ghc" 251e3424/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="251e3424a96986fca5164a2397783a1c066558fc" Set `infixr -1 ->` Summary: This simply makes explicit what is already the case. Due to special treatment in the parser, `->` has the lowest fixity. This patch propagates that information to: * GHCi, where `:info ->` now return the right fixity * TH, where `reifyFixity` returns the right fixity * the generated sources for `GHC.Prim` See #15235. Test Plan: make test Reviewers: bgamari, alanz, RyanGlScott Reviewed By: RyanGlScott Subscribers: int-index, RyanGlScott, rwbarton, mpickering, carter GHC Trac Issues: #15235 Differential Revision: https://phabricator.haskell.org/D5199 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 23:38:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 23:38:29 -0000 Subject: [GHC] #15360: Template Haskell splicing drops lots of type arguments In-Reply-To: <047.e6d2b23e630646579ceaa92c2d2bfbeb@haskell.org> References: <047.e6d2b23e630646579ceaa92c2d2bfbeb@haskell.org> Message-ID: <062.5f7979e30d343fdf2e3145655a4d98e1@haskell.org> #15360: Template Haskell splicing drops lots of type arguments -------------------------------------+------------------------------------- Reporter: goldfire | Owner: mnguyen 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:D5188 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"ba163c3b3502df039e589c5bb0bc9ea767267b2a/ghc" ba163c3b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ba163c3b3502df039e589c5bb0bc9ea767267b2a" Don't drop arguments in TH type arguments Summary: When converting from TH AST back to HsType, we were occasionally dropping type arguments. This resulted in incorrectly accepted programs as well as incorrectly rejected programs. Test Plan: make TEST=T15360a && make TEST=T15360b Reviewers: goldfire, bgamari, tdammers Reviewed By: bgamari, tdammers Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #15360 Differential Revision: https://phabricator.haskell.org/D5188 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 23:40:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 23:40:39 -0000 Subject: [GHC] #11622: Annotating types in type familiy equations without parentheses In-Reply-To: <051.fa9ccc48e4902c5c4db8bb7f638000aa@haskell.org> References: <051.fa9ccc48e4902c5c4db8bb7f638000aa@haskell.org> Message-ID: <066.ff6c9460a686dc70d850607173695592@haskell.org> #11622: Annotating types in type familiy equations without parentheses -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_compile/T11622 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5173 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => parser/should_compile/T11622 * status: patch => closed * resolution: => fixed * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 23:42:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 23:42:06 -0000 Subject: [GHC] #8708: Kind annotation in tuple not parsed In-Reply-To: <047.7299eca00fb25a2e788e2c82e2894717@haskell.org> References: <047.7299eca00fb25a2e788e2c82e2894717@haskell.org> Message-ID: <062.90c47fba41feedd0614a273f50bd91cc@haskell.org> #8708: Kind annotation in tuple not parsed -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.7 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_compile/T8708 Blocked By: | Blocking: Related Tickets: #11267, #11622 | Differential Rev(s): Phab:D5173 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => parser/should_compile/T8708 * resolution: => fixed * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 23:43:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 23:43:41 -0000 Subject: [GHC] #15235: GHCi's claim of infixr 0 (->) is a lie In-Reply-To: <050.1dea13c2dffcf4fb3726d468418c6455@haskell.org> References: <050.1dea13c2dffcf4fb3726d468418c6455@haskell.org> Message-ID: <065.498f647bed0446dc10c844f6727bd05e@haskell.org> #15235: GHCi's claim of infixr 0 (->) is a lie -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T8535 Blocked By: | Blocking: Related Tickets: #15236 | Differential Rev(s): Phab:D5199 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => ghci/scripts/T8535 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 4 23:47:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Oct 2018 23:47:21 -0000 Subject: [GHC] #15360: Template Haskell splicing drops lots of type arguments In-Reply-To: <047.e6d2b23e630646579ceaa92c2d2bfbeb@haskell.org> References: <047.e6d2b23e630646579ceaa92c2d2bfbeb@haskell.org> Message-ID: <062.f6d6b8d18b8526a4d7075147b3d4a63f@haskell.org> #15360: Template Haskell splicing drops lots of type arguments -------------------------------------+------------------------------------- Reporter: goldfire | Owner: mnguyen 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: th/T15360a, | th/T15360b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5188 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => th/T15360a, th/T15360b * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 01:43:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 01:43:20 -0000 Subject: [GHC] #9251: ghc does not expose branchless max/min operations as primops In-Reply-To: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> References: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> Message-ID: <060.1d9e4153375f3efb9741e867a6052094@haskell.org> #9251: ghc does not expose branchless max/min operations as primops -------------------------------------+------------------------------------- Reporter: carter | Owner: osa1 Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9246 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ulysses4ever): * cc: ulysses4ever (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 02:23:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 02:23:06 -0000 Subject: [GHC] #9251: ghc does not expose branchless max/min operations as primops In-Reply-To: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> References: <045.e29eb1e7c055c049cd093a2df9caa8db@haskell.org> Message-ID: <060.5422d5303422415ec43e414771b7e4aa@haskell.org> #9251: ghc does not expose branchless max/min operations as primops -------------------------------------+------------------------------------- Reporter: carter | Owner: osa1 Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9246 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Well, implementing then measuring (and accept the fact that the implementation may be thrown away as a consequence) is one option. However, another option would be to work incrementally: measuring a best- case speed-up in a C (or similar) program. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 03:35:12 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 03:35:12 -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.9852b175e69409f167a4e6577a46906b@haskell.org> #15383: T3171 doesn't terminate with Interrupted message on Darwin -------------------------------------+------------------------------------- Reporter: bgamari | 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: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15463 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"817ba0cf0d70663d934eee421288978ff939cbd2/ghc" 817ba0c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="817ba0cf0d70663d934eee421288978ff939cbd2" testsuite: Skip T3171 for now This test is remarkably flaky, failing regularly on i386/Linux, amd64/Fedora, and amd64/Darwin. I've opened #15383 to track this and am disabling the test for now until we have a chance to investigate. Test Plan: Validate Reviewers: alpmestan Subscribers: rwbarton, carter GHC Trac Issues: #15383 Differential Revision: https://phabricator.haskell.org/D5202 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 03:35:12 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 03:35:12 -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.9f424952580daeca7607fc6433063388@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): Phab:D5190 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"adcb5fb47c0942671d409b940d8884daa9359ca4/ghc" adcb5fb4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="adcb5fb47c0942671d409b940d8884daa9359ca4" Multiple fixes / improvements for LLVM backend - Fix for #13904 -- stop "trashing" callee-saved registers, since it is not actually doing anything useful. - Fix for #14251 -- fixes the calling convention for functions passing raw SSE-register values by adding padding as needed to get the values in the right registers. This problem cropped up when some args were unused an dropped from the live list. - Fixed a typo in 'readnone' attribute - Added 'lower-expect' pass to level 0 LLVM optimization passes to improve block layout in LLVM for stack checks, etc. Test Plan: `make test WAYS=optllvm` and `make test WAYS=llvm` Reviewers: bgamari, simonmar, angerman Reviewed By: angerman Subscribers: rwbarton, carter GHC Trac Issues: #13904, #14251 Differential Revision: https://phabricator.haskell.org/D5190 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 03:35:12 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 03:35:12 -0000 Subject: [GHC] #14251: LLVM Code Gen messes up registers In-Reply-To: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> References: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> Message-ID: <062.a8d6332b616944e290effb44769417a0@haskell.org> #14251: LLVM Code Gen messes up registers -------------------------------------+------------------------------------- Reporter: angerman | Owner: kavon Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler (LLVM) | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5190 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"adcb5fb47c0942671d409b940d8884daa9359ca4/ghc" adcb5fb4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="adcb5fb47c0942671d409b940d8884daa9359ca4" Multiple fixes / improvements for LLVM backend - Fix for #13904 -- stop "trashing" callee-saved registers, since it is not actually doing anything useful. - Fix for #14251 -- fixes the calling convention for functions passing raw SSE-register values by adding padding as needed to get the values in the right registers. This problem cropped up when some args were unused an dropped from the live list. - Fixed a typo in 'readnone' attribute - Added 'lower-expect' pass to level 0 LLVM optimization passes to improve block layout in LLVM for stack checks, etc. Test Plan: `make test WAYS=optllvm` and `make test WAYS=llvm` Reviewers: bgamari, simonmar, angerman Reviewed By: angerman Subscribers: rwbarton, carter GHC Trac Issues: #13904, #14251 Differential Revision: https://phabricator.haskell.org/D5190 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 03:35:12 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 03:35:12 -0000 Subject: [GHC] #14391: Make the simplifier independent of the typechecker In-Reply-To: <046.0a550c305c7e5731d1526aa1438cdf9f@haskell.org> References: <046.0a550c305c7e5731d1526aa1438cdf9f@haskell.org> Message-ID: <061.87098caf2d6131b5535214e492ca67e3@haskell.org> #14391: Make the simplifier independent of the typechecker -------------------------------------+------------------------------------- Reporter: nomeata | Owner: monoidal Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4503, Wiki Page: | Phab:D5135, Phab:D5139 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"e5013a567b230018b5d39b562ce21faf54740d04/ghc" e5013a5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e5013a567b230018b5d39b562ce21faf54740d04" Make TcRnMonad independent of TcSplice (#14391) Test Plan: validate Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #14391 Differential Revision: https://phabricator.haskell.org/D5135 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 06:49:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 06:49:06 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.f5bce00571065c2e517dd02d28240383@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): Great, I think we're on the same page. I'm finalizing Phab:D5201. Currently stuck on a let/app invariant invalidation (Core lint error) when I mark `dataToTag#` as can't fail (`can_fail = False`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 07:46:21 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 07:46:21 -0000 Subject: [GHC] #15706: Refactor NewHsTypeX to DerivedCoreTy Message-ID: <048.615ef91cfcf1df961a2a5b13d5c701f2@haskell.org> #15706: Refactor NewHsTypeX to DerivedCoreTy -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: new Priority: low | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `NewHsTypeX` is not a good name for this construct: {{{ data NewHsTypeX = NHsCoreTy Type -- An escape hatch for tunnelling a *closed* -- Core Type through HsSyn. }}} * the `New` prefix refers to the fact that it is a new approach, rather than to a property of the entity * it is not suggestive of the way `NewHsTypeX` is used in the code and why it exists A better name would be `DerivedCoreTy`. The reason for `NHsCoreTy` existence and its invariant of being closed is the `deriving` mechanism. Doing this renaming also exposes incorrect uses of `NHsCoreTy` in a couple of places that violate the invariant (in some calls to `unifyKind`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 09:04:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 09:04:10 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.e5edf28a632d56b6f86cb984ab55fe7b@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): Simon, what do you think about marking `dataToTag#` as can't fail? I thought it makes sense, but when I do that I get this lint error: (add type annotation on scrutinee) {{{ : warning: In the expression: tagToEnum# @ Bool (case (ds :: Instr) of lwild { __DEFAULT -> 0#; C_ALabel_1 ipv -> 1# }) This argument does not satisfy the let/app invariant: case ds of lwild { __DEFAULT -> 0#; C_ALabel_1 ipv -> 1# } }}} Note that the expression does not actually have `dataToTag#`. Apparently making `dataToTag#` can't fail enables some transformations, which leads to this. (Type of `ds` is a lifted sum type named `Instr`) If I don't make it "can't fail", I get this expression instead {{{ case GHC.Prim.dataToTag# @ Instr ds of b# { __DEFAULT -> GHC.Prim.tagToEnum# @ Bool (case b# of { __DEFAULT -> 0#; 0# -> 1# }) }; }}} The version with "can't fail" is better because we eliminate a redundant `dataToTag#` call, but apparently the resulting expression is not "OK for speculation". I think this expression is not OK for speculation because the scrutinee is lifted, but I'm not sure. I also don't know why lifted scrutinee is a problem for speculation.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 09:46:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 09:46:15 -0000 Subject: [GHC] #15706: Refactor NewHsTypeX to DerivedCoreTy In-Reply-To: <048.615ef91cfcf1df961a2a5b13d5c701f2@haskell.org> References: <048.615ef91cfcf1df961a2a5b13d5c701f2@haskell.org> Message-ID: <063.b277a59a7f3e3fee0c4af7d97623c8ec@haskell.org> #15706: Refactor NewHsTypeX to DerivedCoreTy -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: patch Priority: low | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5205 Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * status: new => patch * differential: => Phab:D5205 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 10:11:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 10:11:20 -0000 Subject: [GHC] #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types In-Reply-To: <044.6bc4fafa2c23357f8677ca0feb803442@haskell.org> References: <044.6bc4fafa2c23357f8677ca0feb803442@haskell.org> Message-ID: <059.b3424dae11ee8f9a511e7aca24564b84@haskell.org> #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9371 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mniip): Considering `unify_tys` is called recursively from when `unify_ty` needs to match a constructor application, I think this functionality of "Maybe"ing out on lists of different lengths needs to be moved somewhere closer to coaxiom compatibility checking and further away from `unify_tys`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 12:55:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 12:55:10 -0000 Subject: [GHC] #15707: More liberally kinded coercions for newtypes Message-ID: <044.c9a9836a78b92c4510540b41daeaddcf@haskell.org> #15707: More liberally kinded coercions for newtypes -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12369 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the infinite data family (possible thanks to #12369): {{{#!hs data family I :: k -> k newtype instance I a = I0 (a) newtype instance I a x = I1 (a x) newtype instance I a x y = I2 (a x y) newtype instance I a x y z = I3 (a x y z) ... }}} We end up with a family of eta-contracted coercions: {{{#!hs forall (a :: *). a ~R I a forall (a :: k -> *). a ~R I a forall (a :: k -> l -> *). a ~R I a forall (a :: k -> l -> m -> *). a ~R I a ... }}} What if we could somehow indicate that we desire a polykinded newtype (so to speak) with a coercion `forall (a :: k). a ~R I a` Maybe even do so by default: `newtype I a = I0 a` would create such a polykinded coercion. Though the `I` data constructor and pattern would still only use the *-kinded restriction of it. We could then recover other constructors with: {{{#!hs i1 :: a x -> I a x i1 = coerce ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 13:02:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 13:02:10 -0000 Subject: [GHC] #15707: More liberally kinded coercions for newtypes In-Reply-To: <044.c9a9836a78b92c4510540b41daeaddcf@haskell.org> References: <044.c9a9836a78b92c4510540b41daeaddcf@haskell.org> Message-ID: <059.33d83b2d33d41bac17da8c5f407d82bc@haskell.org> #15707: More liberally kinded coercions for newtypes -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by mniip: Old description: > Consider the infinite data family (possible thanks to #12369): > > {{{#!hs > data family I :: k -> k > newtype instance I a = I0 (a) > newtype instance I a x = I1 (a x) > newtype instance I a x y = I2 (a x y) > newtype instance I a x y z = I3 (a x y z) > ... > }}} > > We end up with a family of eta-contracted coercions: > {{{#!hs > forall (a :: *). a ~R I a > forall (a :: k -> *). a ~R I a > forall (a :: k -> l -> *). a ~R I a > forall (a :: k -> l -> m -> *). a ~R I a > ... > }}} > > What if we could somehow indicate that we desire a polykinded newtype (so > to speak) with a coercion `forall (a :: k). a ~R I a` > > Maybe even do so by default: `newtype I a = I0 a` would create such a > polykinded coercion. Though the `I` data constructor and pattern would > still only use the *-kinded restriction of it. > > We could then recover other constructors with: > {{{#!hs > i1 :: a x -> I a x > i1 = coerce > ... > }}} New description: Consider the infinite data family (possible thanks to #12369): {{{#!hs data family I :: k -> k newtype instance I a = I0 (a) newtype instance I a x = I1 (a x) newtype instance I a x y = I2 (a x y) newtype instance I a x y z = I3 (a x y z) ... }}} We end up with a family of eta-contracted coercions: {{{#!hs forall (a :: *). a ~R I a forall (a :: k -> *). a ~R I a forall (a :: k -> l -> *). a ~R I a forall (a :: k -> l -> m -> *). a ~R I a ... }}} What if we could somehow indicate that we desire a polykinded newtype (so to speak) with a coercion `forall (a :: k). a ~R I a` Maybe even do so by default: `newtype I a = I0 a` would create such a polykinded coercion. Though the `I0` data constructor and pattern would still only use the *-kinded restriction of it. We could then recover other constructors with: {{{#!hs i1 :: a x -> I a x i1 = coerce ... }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 13:21:38 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 13:21:38 -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.0657fa983c7aca97aee27e69539f0a8e@haskell.org> #13904: LLVM does not need to trash caller-saved registers. -------------------------------------+------------------------------------- Reporter: kavon | Owner: kavon Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #4992, #4308 | Differential Rev(s): Phab:D5190 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 13:21:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 13:21:45 -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.335dcef462c8e8dd6e6971ac532eb1e0@haskell.org> #13904: LLVM does not need to trash caller-saved registers. -------------------------------------+------------------------------------- Reporter: kavon | Owner: kavon Type: bug | Status: merge Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #4992, #4308 | Differential Rev(s): Phab:D5190 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.6.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 13:21:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 13:21:53 -0000 Subject: [GHC] #14251: LLVM Code Gen messes up registers In-Reply-To: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> References: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> Message-ID: <062.11b155a71018b69c3398b86883468afc@haskell.org> #14251: LLVM Code Gen messes up registers -------------------------------------+------------------------------------- Reporter: angerman | Owner: kavon Type: bug | Status: merge Priority: highest | Milestone: 8.6.2 Component: Compiler (LLVM) | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5190 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 13:22:41 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 13:22:41 -0000 Subject: [GHC] #14391: Make the simplifier independent of the typechecker In-Reply-To: <046.0a550c305c7e5731d1526aa1438cdf9f@haskell.org> References: <046.0a550c305c7e5731d1526aa1438cdf9f@haskell.org> Message-ID: <061.d91d7c866d08c4db211d202703237df1@haskell.org> #14391: Make the simplifier independent of the typechecker -------------------------------------+------------------------------------- Reporter: nomeata | Owner: monoidal Type: task | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4503, Wiki Page: | Phab:D5135, Phab:D5139 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 13:27:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 13:27:06 -0000 Subject: [GHC] #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types In-Reply-To: <044.6bc4fafa2c23357f8677ca0feb803442@haskell.org> References: <044.6bc4fafa2c23357f8677ca0feb803442@haskell.org> Message-ID: <059.0dfa12281d230bd668d5fbd90a56a836@haskell.org> #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9371 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mniip): * owner: (none) => mniip -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 13:35:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 13:35:10 -0000 Subject: [GHC] #15708: Cross-module SPECIALZE pragmas aren't typechecked in -O0 Message-ID: <045.547814c152bdca20f1390c41be0dec06@haskell.org> #15708: Cross-module SPECIALZE pragmas aren't typechecked in -O0 -------------------------------------+------------------------------------- Reporter: regnat | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If a module defines a `SPECIALIZE` pragma for a value defined in another module, then the signature of this pragma won't be typecheck by `ghc -O0` (but it will be if the `SPECIALIZE` pragma is in the same module as the value). For example, given {{{#!hs -- Foo.hs module Foo where foo :: a -> a foo = id ---------- -- Bar.hs module Bar where import Foo {-# SPECIALIZE foo :: Int -> Bool #-} }}} running `ghc --make Bar.hs` will run fine, while `ghc --make -O2 Bar.hs` will complain: {{{ Bar.hs:5:1: error: • Couldn't match type ‘Bool’ with ‘Int’ Expected type: Int -> Int Actual type: Int -> Bool • In the SPECIALISE pragma {-# SPECIALIZE foo :: Int -> Bool #-} | 5 | {-# SPECIALIZE foo :: Int -> Bool #-} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} Tested on ghc 8.6.1 and 8.4.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 13:51:18 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 13:51:18 -0000 Subject: [GHC] #15708: Cross-module SPECIALZE pragmas aren't typechecked in -O0 In-Reply-To: <045.547814c152bdca20f1390c41be0dec06@haskell.org> References: <045.547814c152bdca20f1390c41be0dec06@haskell.org> Message-ID: <060.acc7f4d72c70f075820e481793c65a24@haskell.org> #15708: Cross-module SPECIALZE pragmas aren't typechecked in -O0 -------------------------------------+------------------------------------- Reporter: regnat | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Currently that's by-design: without -O we just treat SPECIALISE pragmas as comments. Could easily be changed if that what our users wanted: we could type check the pragma and then discard it (because we are doing -O0). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 13:51:38 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 13:51:38 -0000 Subject: [GHC] #15113: Do not make CAFs from literal strings In-Reply-To: <046.d042ad82da8658ea11bcd44bf2d86387@haskell.org> References: <046.d042ad82da8658ea11bcd44bf2d86387@haskell.org> Message-ID: <061.46b90a0874772b5d7b447a1d7a12c9a6@haskell.org> #15113: Do not make CAFs from literal strings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4717 Wiki Page: | -------------------------------------+------------------------------------- Changes (by MikolajKonarski): * cc: MikolajKonarski (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 14:05:41 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 14:05:41 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.87a34c800fcd25c914db4bc59beff297@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by simonpj): > Simon, what do you think about marking dataToTag# as can't fail? It makes sense to me to do so -- but it's an unforced change. It's not so marked today, primops.txt.pp even says why {{{ {- Note [dataToTag#] ~~~~~~~~~~~~~~~~~~~~ The dataToTag# primop should always be applied to an evaluated argument. The way to ensure this is to invoke it via the 'getTag' wrapper in GHC.Base: getTag :: a -> Int# getTag !x = dataToTag# x But now consider \z. case x of y -> let v = dataToTag# y in ... To improve floating, the FloatOut pass (deliberately) does a binder-swap on the case, to give \z. case x of y -> let v = dataToTag# x in ... Now FloatOut might float that v-binding outside the \z. But that is bad because that might mean x gets evaluated much too early! (CorePrep adds an eval to a dataToTag# call, to ensure that the argument really is evaluated; see CorePrep Note [dataToTag magic].) Solution: make DataToTag into a can_fail primop. That will stop it floating (see Note [PrimOp can_fail and has_side_effects] in PrimOp). It's a bit of a hack but never mind. }}} Are we good to go if you don't make this change? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 14:32:24 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 14:32:24 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.33acd812939575cf3abd17a1bff0143d@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by simonpj): > In compile time we sometimes know that the argument is definitely some constructor C The simplifier does optimise this: {{{ data T = T1 | T2 | T3 | T4 Char boo = T4 'x' f x = case x of T1 -> getTag x T2 -> getTag boo _ -> getTag x }}} produces `-ddump-simpl` {{{ f :: T -> GHC.Prim.Int# f = \ (x_aXJ :: T) -> case x_aXJ of wild_Xf { __DEFAULT -> GHC.Prim.dataToTag# @ T wild_Xf; T1 -> 0#; T2 -> 3# } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 14:37:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 14:37:54 -0000 Subject: [GHC] #15707: More liberally kinded coercions for newtypes In-Reply-To: <044.c9a9836a78b92c4510540b41daeaddcf@haskell.org> References: <044.c9a9836a78b92c4510540b41daeaddcf@haskell.org> Message-ID: <059.14dd6d3d93d7e07ca4e443cf9a2accfc@haskell.org> #15707: More liberally kinded coercions for newtypes -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I see where you're getting, but it's still wishy-washy to me. Is there a concrete program you'd like to write with this feature? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 14:48:18 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 14:48:18 -0000 Subject: [GHC] #15707: More liberally kinded coercions for newtypes In-Reply-To: <044.c9a9836a78b92c4510540b41daeaddcf@haskell.org> References: <044.c9a9836a78b92c4510540b41daeaddcf@haskell.org> Message-ID: <059.a72c282c036de3306fe24e29082890d5@haskell.org> #15707: More liberally kinded coercions for newtypes -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => Roles -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 14:53:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 14:53:53 -0000 Subject: [GHC] #15709: GHC panic using TypeInType with minimal source code Message-ID: <044.692bd53c7710d970387a3a980ed4667a@haskell.org> #15709: GHC panic using TypeInType with minimal source code -------------------------------------+------------------------------------- Reporter: jnape | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Keywords: TypeInType | 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: -------------------------------------+------------------------------------- The following source code causes GHC 8.4.3 on 64bit Linux to panic: {{{#!haskell {-# LANGUAGE TypeInType #-} module Lib where import Data.Kind class Contravariant f where contramap :: (a -> b) -> f b -> f a dimap :: (Contravariant (p :: * -> b -> p * b), Functor (p a)) => (z -> a) -> (b -> c) -> p a b -> p z c dimap f g = contramap f . fmap g }}} I have no idea if it should compile or not, but it shouldn't do this: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-linux): piResultTy k_a34u[tau:1] * 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 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 15:16:24 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 15:16:24 -0000 Subject: [GHC] #15709: GHC panic using TypeInType with minimal source code In-Reply-To: <044.692bd53c7710d970387a3a980ed4667a@haskell.org> References: <044.692bd53c7710d970387a3a980ed4667a@haskell.org> Message-ID: <059.f8a1423e860b6cba8448e93cf2be3c50@haskell.org> #15709: GHC panic using TypeInType with minimal source code -------------------------------------+------------------------------------- Reporter: jnape | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: duplicate | Keywords: TypeInType 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 simonpj): * status: new => closed * resolution: => duplicate Comment: Happily, I think this is probably fixed. (Search for the many tickets with `piResultTy` in them. GHC 8.6 fails with {{{ T15709.hs:10:25: error: • Expecting one more argument to ‘(p :: * -> b -> p * b)’ Expected kind ‘* -> *’, but ‘(p :: * -> b -> p * b)’ has kind ‘* -> b -> p * b’ • In the first argument of ‘Contravariant’, namely ‘(p :: * -> b -> p * b)’ In the type signature: dimap :: (Contravariant (p :: * -> b -> p * b), Functor (p a)) => (z -> a) -> (b -> c) -> p a b -> p z c | 10 | dimap :: (Contravariant (p :: * -> b -> p * b), Functor (p a)) => (z -> a) -> (b -> c) -> p a b -> p z c | ^^^^^^^^^^^^^^^^^^^^^^ T15709.hs:10:26: error: • Expected kind ‘* -> b -> p * b’, but ‘p’ has kind ‘* -> * -> *’ • In the first argument of ‘Contravariant’, namely ‘(p :: * -> b -> p * b)’ In the type signature: dimap :: (Contravariant (p :: * -> b -> p * b), Functor (p a)) => (z -> a) -> (b -> c) -> p a b -> p z c | 10 | dimap :: (Contravariant (p :: * -> b -> p * b), Functor (p a)) => (z -> a) -> (b -> c) -> p a b -> p z c | ^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 16:04:01 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 16:04:01 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.954ead97962a05cf045dca2e9c422c34@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): I understand why it's currently marked as `can_fail`, but if my understanding is correct we should be able to mark it as `can_fail = False` now. I'm curious why that's causing problems. Also, as shown in comment:48, the code is actually better with `can_fail = False`. > Are we good to go if you don't make this change? I tried to validate now without `can_fail = False`. I'm getting a segfault in haddock (when building docs during validate), then in the test suite haddock perf tests are failing. Other tests are passing. I'll debug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 16:14:21 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 16:14:21 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.df401e2e1cae2515095e966bcabe205a@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by simonpj): > if my understanding is correct we should be able to mark it as can_fail = False now Why do you think the Note is now not relevant? It looks every bit as pertinent now as before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 16:22:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 16:22:32 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.b92b11775882bfe0e0b84f0e7e3005fb@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): Well because this transformation \z. case x of y -> let v = dataToTag# y in ... ==> \z. case x of y -> let v = dataToTag# x in ... is not a problem anymore. Although I now realize that floating `v` outsize of `\z` is still a problem, because that'd mean evaluating `x` more eagerly. So I think first part of the note isn't relevant anymore, but second part (floating out) is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 16:24:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 16:24:16 -0000 Subject: [GHC] #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types In-Reply-To: <044.6bc4fafa2c23357f8677ca0feb803442@haskell.org> References: <044.6bc4fafa2c23357f8677ca0feb803442@haskell.org> Message-ID: <059.2ef31a50d7041362c721b426b875362a@haskell.org> #15704: Different saturations of the same polymorphic-kinded type constructor aren't seen as apart types -------------------------------------+------------------------------------- Reporter: mniip | Owner: mniip Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9371 | Differential Rev(s): Phab:D5206 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mniip): * differential: => Phab:D5206 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 16:35:07 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 16:35:07 -0000 Subject: [GHC] #15707: More liberally kinded coercions for newtypes In-Reply-To: <044.c9a9836a78b92c4510540b41daeaddcf@haskell.org> References: <044.c9a9836a78b92c4510540b41daeaddcf@haskell.org> Message-ID: <059.d8465e1015a3890673e589c6439a139a@haskell.org> #15707: More liberally kinded coercions for newtypes -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mniip): Replying to [comment:2 goldfire]: > I see where you're getting, but it's still wishy-washy to me. Is there a concrete program you'd like to write with this feature? Me (and partly ekmett) are experimenting with the idea of building a polykinded generics framework using a type-level combinatory calculus. So there's a handful of such data families involved, acting as combinators. In practice of course the family can't be infinite and we have to stop at some arity. We could unsafely introduce a coercion of the desired shape, but then what if someone extends the family? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 16:56:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 16:56:57 -0000 Subject: [GHC] #15710: Should accept a type that needs coercion quantification Message-ID: <046.5bf95bcb5259eed36b1ec15b928de8c8@haskell.org> #15710: Should accept a type that needs coercion quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider {{{ f :: forall k (f :: k) (x :: k1). (k ~ (k1 -> *)) => f x f = error "uk" }}} Should we accept it? Now that we have coercion quantification (Trac #15497), I think the answer should be yes, with the elaborated signature being {{{ f :: forall k (f::k) (x::k1). forall (co :: k ~# (k1->*)). (f |> co) x }}} But there is a problem: the user wrote `k ~ (k1 -> *)`, and that's a boxed value that we can't take apart in types. I'm not sure what to do here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 16:57:39 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 16:57:39 -0000 Subject: [GHC] #15710: Should GHC accept a type signature that needs coercion quantification? (was: Should accept a type that needs coercion quantification) In-Reply-To: <046.5bf95bcb5259eed36b1ec15b928de8c8@haskell.org> References: <046.5bf95bcb5259eed36b1ec15b928de8c8@haskell.org> Message-ID: <061.00c27f2a3c5bcb662743c83f689a3154@haskell.org> #15710: Should GHC accept a type signature that needs coercion quantification? -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: 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 Fri Oct 5 17:21:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 17:21:50 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.6394b84965ceabc607a972a3816275af@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: 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 started working on this. A few notes: - We want to be able to change CAFFY-ness and arity information not only in Core, but also in STG. #15038 happened because CAFFY-ness was changed in STG. In Phab:D4717 (for #15113) we change CAFs in CoreToStg. - I think to update an iface file after STG we could update the old `ModIface` (used to generate the initial file) and pass it to `hscMaybeWriteIface` when we're done with transformations (right before starting to generate Cmm). So the only extra thing we keep in memory would be the `ModIface`. Alternatively I think we could implement a `ModIfaceUpdate` type that represents changes in `Name`s in an existing interface file. Then `updateIface` function would read the iface file, apply the updates to the in-memory representation, then write it again. This trades performance for residency (although peak memory may stay the same). - `ModIface` is currently not suitable for updates. The field that holds iface definitions has type `[(Fingerprint,IfaceDecl)]`, which is hard to update (need to search the entire list to find the `IfaceDecl` for a given `Name`. - Similarly, id details of a `IfaceDecls` is also hard to update. The relevant types are: {{{ data IfaceIdInfo = NoInfo -- When writing interface file without -O | HasInfo [IfaceInfoItem] -- Has info, and here it is data IfaceInfoItem = HsArity Arity | HsStrictness StrictSig | HsInline InlinePragma | HsUnfold Bool -- True <=> isStrongLoopBreaker is true IfaceUnfolding -- See Note [Expose recursive functions] | HsNoCafRefs | HsLevity -- Present <=> never levity polymorphic }}} So to update caf refs we need to filter the whole list. To update the arity we need to drop any existing `HsArity` info items and cons a new one. Depending on how large these lists are perhaps this isn't as big of a problem as the previous item though. - I'm assuming that `idName` of a top-level STG binder is the `Name` used in `IfaceDecl` for the declaration, so we don't need to generate a map from STG binders to `IfaceDecl` names. In my testing I found this to be true, but I only tried tiny programs so far. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 17:25:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 17:25:06 -0000 Subject: [GHC] #14626: No need to enter a scrutinised value In-Reply-To: <048.67c951c2aecb97b988badb4816dbe757@haskell.org> References: <048.67c951c2aecb97b988badb4816dbe757@haskell.org> Message-ID: <063.25d9b25e00e7100e35c9825c8e78dd04@haskell.org> #14626: No need to enter a scrutinised value -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: performance, | CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14677 | Blocking: Related Tickets: #13861 #14677 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 17:26:03 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 17:26:03 -0000 Subject: [GHC] #13861: Take more advantage of STG representation invariance (follows up #9291) In-Reply-To: <048.651e325a747e822318af666cede88e81@haskell.org> References: <048.651e325a747e822318af666cede88e81@haskell.org> Message-ID: <063.7116c2fbfbaea6ec0481d406d796212f@haskell.org> #13861: Take more advantage of STG representation invariance (follows up #9291) -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 17:27:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 17:27:36 -0000 Subject: [GHC] #14677: Code generator does not correctly tag a pointer In-Reply-To: <046.7a1d900f9976c54932290e6492402f05@haskell.org> References: <046.7a1d900f9976c54932290e6492402f05@haskell.org> Message-ID: <061.3ad7d843d89bd1d138e57e1c3bff8d48@haskell.org> #14677: Code generator does not correctly tag a pointer -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: 15155 | Blocking: 14626 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 Fri Oct 5 18:27:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 18:27:10 -0000 Subject: [GHC] #15709: GHC panic using TypeInType with minimal source code In-Reply-To: <044.692bd53c7710d970387a3a980ed4667a@haskell.org> References: <044.692bd53c7710d970387a3a980ed4667a@haskell.org> Message-ID: <059.836ee3c7eeec7fb0a221ae88cd2d824d@haskell.org> #15709: GHC panic using TypeInType with minimal source code -------------------------------------+------------------------------------- Reporter: jnape | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: duplicate | Keywords: TypeInType 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 jnape): Wonderful! Sorry for the duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 19:08:39 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 19:08:39 -0000 Subject: [GHC] #15710: Should GHC accept a type signature that needs coercion quantification? In-Reply-To: <046.5bf95bcb5259eed36b1ec15b928de8c8@haskell.org> References: <046.5bf95bcb5259eed36b1ec15b928de8c8@haskell.org> Message-ID: <061.5363b5361c27f4bcc1d07ee1beed8792@haskell.org> #15710: Should GHC accept a type signature that needs coercion quantification? -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: 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): Back when I was implementing `-XTypeInType`, your "problem" at the end was indeed a problem. There are some notes (meant mainly for myself) [https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Internal#Liftedvs.Unliftedequality here]. Briefly, the problem was: how should we interpret a user-written `~`? Should it be a lifted/boxed thing or an unlifted/unboxed thing? If it's lifted, then we can abstract over it (e.g., write `Dict (a ~ b)`, where `Dict :: Constraint -> Type`). If it's unlifted, we can write the program in the original ticket. However, we now have a robust levity polymorphism mechanism, meaning that we can now abstract over unlifted things quite handily. There has also been recent musing about strict constraints, which fits in nicely. So, here's a sketch for how to do this. 1. Introduce `CONSTRAINT :: RuntimeRep -> Type`. `Constraint` becomes a synonym for `CONSTRAINT LiftedRep`. 2. Existing constraints would continue to have kind `Constraint`. 3. Give `~` this new kind: `(~) :: forall k. k -> k -> CONSTRAINT (TupleRep '[])` -- essentially saying that `~` is strict and erases to 0 bits. Really, what I've done here is made the user-facing equality `~` the same as the internal equality `~#`. (This will make even more sense when `~#` is homogeneous, like `~` is.) One might wonder about deferred type errors. I claim that this is a red herring. Since GHC 8.0, GHC has been strict in equality errors anyway. This is described in #11197. The solution is conceptually simple (but no one has implemented it yet): aggressively float-in case-matches on deferred type errors. One might also wonder about `Dict (a ~ b)` in this brave new world. It's true that the traditional `Dict` won't work here, but any user could define a `Dict#` that would, by abstracting over erased, strict constraints. Perhaps this change would be breaking enough that we'd need to keep `~` lifted and introduce a new name for the unlifted equality that could be used in coercion quantification, but I think we can debate that problem separately from the general design. (Note that it's very easy for a user to introduce a lifted equality type that wraps the unlifted one.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 19:09:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 19:09:10 -0000 Subject: [GHC] #15710: Should GHC accept a type signature that needs coercion quantification? In-Reply-To: <046.5bf95bcb5259eed36b1ec15b928de8c8@haskell.org> References: <046.5bf95bcb5259eed36b1ec15b928de8c8@haskell.org> Message-ID: <061.a12a071f83587a00d4701269e57644c1@haskell.org> #15710: Should GHC accept a type signature that needs coercion quantification? -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 19:10:27 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 19:10:27 -0000 Subject: [GHC] #15707: More liberally kinded coercions for newtypes In-Reply-To: <044.c9a9836a78b92c4510540b41daeaddcf@haskell.org> References: <044.c9a9836a78b92c4510540b41daeaddcf@haskell.org> Message-ID: <059.7a08aa73235a4fb284363800baba8504@haskell.org> #15707: More liberally kinded coercions for newtypes -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12369 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): But do you have a concrete program (invent syntax if necessary) that uses this feature? It's much easier to understand the implications of it all with an example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 21:23:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 21:23:26 -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.cf9ec2bb3a23735f275bea386ff51362@haskell.org> #15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0 -------------------------------------+------------------------------------- Reporter: noah | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.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 bgamari): * milestone: 8.6.1 => 8.8.1 Comment: Yep! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 21:24:03 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 21:24:03 -0000 Subject: [GHC] #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` In-Reply-To: <046.74175c624c857c997e111eade5eabf30@haskell.org> References: <046.74175c624c857c997e111eade5eabf30@haskell.org> Message-ID: <061.505adc9b4f7f12816f393cd660ee359c@haskell.org> #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` -------------------------------------+------------------------------------- Reporter: rockbmb | Owner: rockbmb Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: base, | Data.Fixed Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ashley Yakeley): 1. The time library uses Fixed, so I'm not sure the Hackage search was good? 2. As written, the proposed change eliminates non-base-10 Fixed. Are we sure we want to do that? 3. If we're considering breaking changes to Data.Fixed, the more urgent need (imo) is to generalise the representation type, which is currently hard-coded as Integer. Touching both points 2 and 3, [https://en.wikipedia.org/wiki/Q_(number_format) Q formats] are fixed- point with a given number of fractional lower bits. It would be useful to be able to represent these. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 21:25:07 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 21:25:07 -0000 Subject: [GHC] #15711: Kind inference of class variables does not examine associated types Message-ID: <047.36e9feede9f94c1f90dd44b967991991@haskell.org> #15711: Kind inference of class variables does not examine associated types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I say this {{{ {-# LANGUAGE TypeFamilies, PolyKinds, DataKinds #-} module Bug where class C a where type F (x :: Maybe a) }}} then GHCi says this {{{ *Bug> :k C C :: k -> Constraint }}} That's silly. `C` should have kind `Type -> Constraint`, because the usage of `a` in the kind of the associated type constraints `a`'s kind. Will fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 21:26:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 21:26:10 -0000 Subject: [GHC] #15260: Xmobar crashes with segmentation fault In-Reply-To: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> References: <046.b86e6414659d8977828bbf471aa3fbf6@haskell.org> Message-ID: <061.2150b613a461a521522346f36f300143@haskell.org> #15260: Xmobar crashes with segmentation fault ----------------------------------+-------------------------------------- Reporter: Voronwe | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.4 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): * milestone: 8.6.1 => 8.4.4 Comment: Merged to `ghc-8.4` in 56590db07a776ce81eb89d4a4d86bd0f953fb44e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 21:28:12 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 21:28:12 -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.7a89b3251d606cef0af0b7e7a9b32e99@haskell.org> #15436: Compile-time panic, Prelude.!!: negative index -------------------------------------+------------------------------------- Reporter: pbrisbin | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.4.4 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: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.4.4 Comment: This was merged to `ghc-8.4` in 66c75922e04355ab3babc9c76eab6c97ddceec1e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 21:30:49 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 21:30:49 -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.8083d840c429c755933ca58b007002f2@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 bgamari): comment:9 has been backported to `ghc-8.4` in 026d908f56c05d1f02df688816278c479872212b. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 22:00:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 22:00:36 -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.a13b912b30ee556a7b3a9b314a6e4836@haskell.org> #15578: Honour INLINE pragmas on 0-arity bindings -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.2 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): Phab:D5137 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, this patch put up resistance in the form of validation issues when I tried to merge it before 8.6.1. I can try again for 8.6.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 22:01:33 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 22:01:33 -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.1687f260a1c745ff86230a419c19e497@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 bgamari): * milestone: 8.6.2 => 8.6.1 Comment: This didn't end up happening for 8.6.1 due to its size. I suspect this won't change in 8.6.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 22:10:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 22:10:52 -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.e5a235e799055873d0a673b972ee8cbf@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, 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: PatternMatchWarnings => PatternMatchWarnings, newcomer Comment: Unfortunately there wasn't really a conclusion (hence nothing happened for 8.6.1. Task (6) above would make for a great task for someone with a free weekend or three. It would require working out the theory but the coverage checker paper is fairly accessible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 22:19:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 22:19:05 -0000 Subject: [GHC] #15712: GHC panic with -XDerivingVia Message-ID: <051.18678e52e8ceb13158b151407af6bb08@haskell.org> #15712: GHC panic with -XDerivingVia -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: DerivingVia | 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 slipped up and typed `Codensity GEndo` and now `Codensity (GEndo m)`, resulting in a GHC panic {{{#!hs {-# Language RankNTypes #-} {-# Language DerivingVia #-} import Control.Monad.Codensity import Data.Kind newtype GEndo m a = GEndo (m a -> m a) newtype LogicT m a = LogicT { runLogicT :: forall xx. (a -> (m xx -> m xx)) -> (m xx -> m xx) } deriving (Functor, Applicative, Monad) via (Codensity GEndo) }}} {{{ $ ghci -ignore-dot-ghci 476.hs GHCi, version 8.7.20180828: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 476.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20180828 for x86_64-unknown-linux): ASSERT failed! Type-correct unfilled coercion hole {co_a2aG} Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:1716:99 in ghc:TcHsSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} Deriving via `Codensity (GEndo m)` works as expected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 22:21:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 22:21:19 -0000 Subject: [GHC] #15712: GHC panic with -XDerivingVia In-Reply-To: <051.18678e52e8ceb13158b151407af6bb08@haskell.org> References: <051.18678e52e8ceb13158b151407af6bb08@haskell.org> Message-ID: <066.738c4ad9032da534948d04c57e99ec3f@haskell.org> #15712: GHC panic with -XDerivingVia -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: DerivingVia Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > I slipped up and typed `Codensity GEndo` and now `Codensity (GEndo m)`, > resulting in a GHC panic > > {{{#!hs > {-# Language RankNTypes #-} > {-# Language DerivingVia #-} > > import Control.Monad.Codensity > import Data.Kind > > newtype GEndo m a = GEndo (m a -> m a) > > newtype LogicT m a = LogicT { runLogicT :: forall xx. (a -> (m xx -> m > xx)) -> (m xx -> m xx) } > deriving > (Functor, Applicative, Monad) > via > (Codensity GEndo) > }}} > > {{{ > $ ghci -ignore-dot-ghci 476.hs > GHCi, version 8.7.20180828: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( 476.hs, interpreted ) > ghc-stage2: panic! (the 'impossible' happened) > (GHC version 8.7.20180828 for x86_64-unknown-linux): > ASSERT failed! > Type-correct unfilled coercion hole {co_a2aG} > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in > ghc:Outputable > pprPanic, called at compiler/utils/Outputable.hs:1219:5 in > ghc:Outputable > assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:1716:99 > in ghc:TcHsSyn > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > > > }}} > > Deriving via `Codensity (GEndo m)` works as expected. New description: I slipped up and typed `Codensity GEndo` instead of `Codensity (GEndo m)`, resulting in a GHC panic {{{#!hs {-# Language RankNTypes #-} {-# Language DerivingVia #-} import Control.Monad.Codensity import Data.Kind newtype GEndo m a = GEndo (m a -> m a) newtype LogicT m a = LogicT { runLogicT :: forall xx. (a -> (m xx -> m xx)) -> (m xx -> m xx) } deriving (Functor, Applicative, Monad) via (Codensity GEndo) }}} {{{ $ ghci -ignore-dot-ghci 476.hs GHCi, version 8.7.20180828: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 476.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20180828 for x86_64-unknown-linux): ASSERT failed! Type-correct unfilled coercion hole {co_a2aG} Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:1716:99 in ghc:TcHsSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} Deriving via `Codensity (GEndo m)` works as expected. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 22:21:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 22:21:57 -0000 Subject: [GHC] #13477: Turn cIntegerLibraryType into a dynflag In-Reply-To: <046.1be05c5fa445155bed193903c2e35749@haskell.org> References: <046.1be05c5fa445155bed193903c2e35749@haskell.org> Message-ID: <061.1a18bd3f17a9b0db52facda9949cc3bd@haskell.org> #13477: Turn cIntegerLibraryType into a dynflag -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: closed Priority: low | Milestone: 8.8.1 Component: GHC API | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5079 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: 8.6.2 => 8.8.1 Comment: I don't see any urgent need to merge this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 22:24:28 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 22:24:28 -0000 Subject: [GHC] #15712: GHC panic with -XDerivingVia In-Reply-To: <051.18678e52e8ceb13158b151407af6bb08@haskell.org> References: <051.18678e52e8ceb13158b151407af6bb08@haskell.org> Message-ID: <066.1019faead6530ed2e6d88e19284e43ee@haskell.org> #15712: GHC panic with -XDerivingVia -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: DerivingVia Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): This is without the https://hackage.haskell.org/package/kan- extensions-5.2/docs/Control-Monad-Codensity.html dependency {{{#!hs {-# Language RankNTypes #-} {-# Language DerivingVia #-} {-# Language DeriveFunctor #-} -- import Control.Monad.Codensity import Data.Kind newtype Codensity f a = Codensity (forall xx. (a -> f xx) -> f xx) deriving Functor newtype GEndo m a = GEndo (m a -> m a) newtype LogicT m a = LogicT (forall xx. (a -> (m xx -> m xx)) -> (m xx -> m xx)) deriving (Functor) via (Codensity GEndo) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 22:25:49 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 22:25:49 -0000 Subject: [GHC] #15559: fromJust has no HasCallStack In-Reply-To: <046.0c0fc309394993486a792a626e8db1e1@haskell.org> References: <046.0c0fc309394993486a792a626e8db1e1@haskell.org> Message-ID: <061.b1708c5e9b04ce0cbe3be38e64844289@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 bgamari): We already have a [[http://downloads.haskell.org/~ghc/master/users-guide //using-optimisation.html?highlight=assert#ghc-flag--fignore-asserts|very similar]] mechanism for `Control.Exception.assert` occurrences at compile- time. It would be reasonably straightforward to add a similar flag for a magic synonym of `HasCallStack`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 22:50:37 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 22:50:37 -0000 Subject: [GHC] #15667: Readonly permissions bits are wrong In-Reply-To: <044.f1da98646cee33a60ff58118ea841bfc@haskell.org> References: <044.f1da98646cee33a60ff58118ea841bfc@haskell.org> Message-ID: <059.f85b51f75ab84adbb745c59d7380a5a2@haskell.org> #15667: Readonly permissions bits are wrong -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.6.2 Component: Compiler | Version: 8.4.3 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.6` in 73273be476a8cc6c13368660b042b3b0614fd928. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 22:51:11 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 22:51:11 -0000 Subject: [GHC] #14251: LLVM Code Gen messes up registers In-Reply-To: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> References: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> Message-ID: <062.48967da739a8bb73f10bb6eb20c9d36a@haskell.org> #14251: LLVM Code Gen messes up registers -------------------------------------+------------------------------------- Reporter: angerman | Owner: kavon Type: bug | Status: closed Priority: highest | Milestone: 8.6.2 Component: Compiler (LLVM) | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5190 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.6` with 73273be476a8cc6c13368660b042b3b0614fd928. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 22:51:34 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 22:51:34 -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.1778df1b45db307e9dec74685342257f@haskell.org> #13904: LLVM does not need to trash caller-saved registers. -------------------------------------+------------------------------------- Reporter: kavon | Owner: kavon Type: bug | Status: closed Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #4992, #4308 | Differential Rev(s): Phab:D5190 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.6` with 73273be476a8cc6c13368660b042b3b0614fd928. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 22:56:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 22:56:45 -0000 Subject: [GHC] #15672: Flags missing documentation. In-Reply-To: <045.958bbebd9adae560ab69fa02f124e3a9@haskell.org> References: <045.958bbebd9adae560ab69fa02f124e3a9@haskell.org> Message-ID: <060.a3084271a985d716e2d07731ff728308@haskell.org> #15672: Flags missing documentation. -------------------------------------+------------------------------------- Reporter: merijn | Owner: (none) 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 bgamari): Ahh, yes, it looks like 8f19c65c66e38709a8acba8f86015053d2c04126 dropped a few flags. That's quite unfortunate. Would you be interested in submitting a patch to fix this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 23:12:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 23:12:55 -0000 Subject: [GHC] #15707: More liberally kinded coercions for newtypes In-Reply-To: <044.c9a9836a78b92c4510540b41daeaddcf@haskell.org> References: <044.c9a9836a78b92c4510540b41daeaddcf@haskell.org> Message-ID: <059.0742b01ae2ba7fbb225848b118206dc8@haskell.org> #15707: More liberally kinded coercions for newtypes -------------------------------------+------------------------------------- Reporter: mniip | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Roles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12369 | 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 Fri Oct 5 23:15:39 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 23:15:39 -0000 Subject: [GHC] #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory In-Reply-To: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> References: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> Message-ID: <063.3a61592ecbfc31482647a50e96c6faa1@haskell.org> #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: None | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => highest * milestone: 8.6.1 => 8.6.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 23:25:40 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 23:25:40 -0000 Subject: [GHC] #15710: Should GHC accept a type signature that needs coercion quantification? In-Reply-To: <046.5bf95bcb5259eed36b1ec15b928de8c8@haskell.org> References: <046.5bf95bcb5259eed36b1ec15b928de8c8@haskell.org> Message-ID: <061.64f6d86b982d6a41f58bc16a3ba5a864@haskell.org> #15710: Should GHC accept a type signature that needs coercion quantification? -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): In #14648 you argued that `(t1 ~# t2)` should not be a constraint, should not return True to `isPredTy`, and should not be an invisible parameter, implicitly instantiated at call sites. Here you seem to be arguing the exact opposite! I'm uncomfortable with forcing the the user to deal with both `(~)` and `(~#)`; I wanted the latter to be an implementation detail. Even putting it in a constraint tuple like `f :: (Num a, a ~ b) => blah` is problematic if `a~b` is unlifted/unboxed. Our "all constraints are boxed" story was working perfectly well right up to this, when we add coercion quantification. But I don't see a way to reconcile it with coercion quantification. Alas. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 23:36:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 23:36:26 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.8d5b960149ec3dcb285439a9a3bc77e3@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: | (reverted), Phab:D5165, Phab:D5178 -------------------------------------+------------------------------------- Comment (by bgamari): Does comment:21 fix this issue, Omer? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 23:48:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 23:48:36 -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.66db2deb2647d9357a17fbccf7e2418b@haskell.org> #15072: Teach the testsuite driver about response files -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ckoparkar 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 bgamari): > Since we're updating the executable, is there some process we have to follow (eg. announce on a specific mailing list) ? I don't believe anything in particular is necessary for this change. I view this largely as just implementing a missing feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 23:49:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 23:49:23 -0000 Subject: [GHC] #14475: Upload documentation dumps In-Reply-To: <046.875271090aacfb7d8f31943e1b69bd4b@haskell.org> References: <046.875271090aacfb7d8f31943e1b69bd4b@haskell.org> Message-ID: <061.ebcf01dc82d553878989a449cb6020d0@haskell.org> #14475: Upload documentation dumps -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gander Type: task | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.2.1 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I updated the `~ghc/latest` symlink earlier this week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 5 23:51:49 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Oct 2018 23:51:49 -0000 Subject: [GHC] #15653: Both `Ptr a` in SerializedCompact are inaccurate because of the `a` In-Reply-To: <046.cd7d529803a4724dd6595ad0ba265e9b@haskell.org> References: <046.cd7d529803a4724dd6595ad0ba265e9b@haskell.org> Message-ID: <061.e316244b3c466ee6b8ce4f89847bd785@haskell.org> #15653: Both `Ptr a` in SerializedCompact are inaccurate because of the `a` -------------------------------------+------------------------------------- Reporter: chessai | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: | Version: 8.4.3 libraries/compact | Keywords: ghc-compact, Resolution: | compact regions Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect API | Unknown/Multiple annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I think it would be quite reasonable to fix this. In my view we should try quite hard to ensure unsafe interfaces like that of `Ptr` are made as safe as possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 6 00:07:26 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Oct 2018 00:07:26 -0000 Subject: [GHC] #15660: source file modify race leads to inconsistent error message In-Reply-To: <047.0bb5271dc9d70158327714b5707bda53@haskell.org> References: <047.0bb5271dc9d70158327714b5707bda53@haskell.org> Message-ID: <062.a886a9cf137d6f0ca4e282aa23f43729@haskell.org> #15660: source file modify race leads to inconsistent error message -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed this is a known limitation of GHC's implementation of caret diagnostics (which indeed re-reads the source file to extract the span indicated in the error message). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 6 01:13:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Oct 2018 01:13:57 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.961d8250f530901baee2f1d28cd60154@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.6.2 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: 15592 Related Tickets: #15076 | Differential Rev(s): Phab:D4769, Wiki Page: | Phab:D5141, Phab:D5147, Phab:D5150 -------------------------------------+------------------------------------- Comment (by goldfire): Interestingly, the current approach to this undoes the work to fix #14552, which has a very similar character. We now accept the program in #14552, but zapping some tyvars to `Any` (an approach we recognized would work back then, but decided issuing an error was better). The curious can track progress [https://gitlab.com/goldfirere/ghc/tree/wip/rae here]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 6 02:35:20 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Oct 2018 02:35:20 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.c861ede29778acedee6b2061995c09a3@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.6.2 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: 15592 Related Tickets: #15076 | Differential Rev(s): Phab:D4769, | Phab:D5141, Phab:D5147, Phab:D5150, Wiki Page: | Phab:D5208 -------------------------------------+------------------------------------- Changes (by goldfire): * differential: Phab:D4769, Phab:D5141, Phab:D5147, Phab:D5150 => Phab:D4769, Phab:D5141, Phab:D5147, Phab:D5150, Phab:D5208 Comment: My patch is at Phab:D5208. Before the most recent rebase, it validated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 6 06:25:00 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Oct 2018 06:25:00 -0000 Subject: [GHC] #15508: concprog001 fails with various errors In-Reply-To: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> References: <043.7b20754ba25128f911949e43ef11a3db@haskell.org> Message-ID: <058.518711113b661c9dc1c6febfa26a7d32@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: | (reverted), Phab:D5165, Phab:D5178 -------------------------------------+------------------------------------- Comment (by osa1): No, comment:20 is still valid. I used commit in comment:21 when writing comment:20. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 6 09:54:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Oct 2018 09:54:12 -0000 Subject: [GHC] #15660: source file modify race leads to inconsistent error message In-Reply-To: <047.0bb5271dc9d70158327714b5707bda53@haskell.org> References: <047.0bb5271dc9d70158327714b5707bda53@haskell.org> Message-ID: <062.8f37c676d221f6a2756ff5937b92ad69@haskell.org> #15660: source file modify race leads to inconsistent error message -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | 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 Sat Oct 6 10:01:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Oct 2018 10:01:54 -0000 Subject: [GHC] #15660: source file modify race leads to inconsistent error message In-Reply-To: <047.0bb5271dc9d70158327714b5707bda53@haskell.org> References: <047.0bb5271dc9d70158327714b5707bda53@haskell.org> Message-ID: <062.bd921883080deb51ec102b395e303dc5@haskell.org> #15660: source file modify race leads to inconsistent error message -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Does anyone know how do other compilers (gcc, clang, ...) do this? I see two options: - Copy the files to /tmp/ before reading, use the files in /tmp/ in consecutive reads. We need to make sure we clean /tmp/ after each run. - Keep the parsed source in memory, use it in caret diagnostics. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 6 12:43:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Oct 2018 12:43:39 -0000 Subject: [GHC] #15708: Cross-module SPECIALZE pragmas aren't typechecked in -O0 In-Reply-To: <045.547814c152bdca20f1390c41be0dec06@haskell.org> References: <045.547814c152bdca20f1390c41be0dec06@haskell.org> Message-ID: <060.efd77c071e232e747904f7c1b99362c2@haskell.org> #15708: Cross-module SPECIALZE pragmas aren't typechecked in -O0 -------------------------------------+------------------------------------- Reporter: regnat | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by regnat): > without -O we just treat SPECIALISE pragmas as comments. That seems not to be exactly the case in practice: if the SPECIALISE pragma is in the same module as the definition then I get an error. Regardless of that, I find this a bit surprising: I would have expected that as much as possible whether a program is valid or not doesn't depend on the optimization level (which obviously isn't possible to guaranty in the general case because of things like the RULE pragma, but as you mentioned this doesn't cost much to check). Or do I overlook another good reason for not typechecking these pragmas? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 6 13:27:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Oct 2018 13:27:55 -0000 Subject: [GHC] #15713: Bogus -Woverlapping-patterns warning with OverloadedStrings Message-ID: <057.7b8d57738ba0aca7168c860a8f80b0d4@haskell.org> #15713: Bogus -Woverlapping-patterns warning with OverloadedStrings -------------------------------------+------------------------------------- Reporter: | Owner: (none) quasicomputational | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ $ cat Test.hs {-# LANGUAGE OverloadedStrings, LambdaCase #-} import Data.String data Expr = App Expr Expr | Var String deriving (Eq) instance IsString Expr where fromString = Var . fromString go = \case App ( App ( App "refWithFile" identM ) filenameM) exceptionMayM -> Just 2 App ( App "and" a ) b -> Just 3 App ( App "or" a ) b -> Just 4 _ -> Nothing go' = \case App ( App ( App "refWithFile" identM ) filenameM) exceptionMayM -> Just 2 App ( App "and" a ) b -> Just 3 _ -> Nothing go'' = \case App ( App ( App (Var "refWithFile") identM ) filenameM) exceptionMayM -> Just 2 App ( App (Var "and") a ) b -> Just 3 App ( App (Var "or") a ) b -> Just 4 _ -> Nothing main = do let expr = App (App "or" "a") "b" print (go expr) print (go' expr) $ runghc-8.4.3 Test.hs Test.hs:13:3: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: App (App "or" a) b -> ... | 13 | App ( App "or" a ) b -> Just 4 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Just 4 Nothing $ runghc-8.6.1 Test.hs Test.hs:13:3: warning: [-Woverlapping-patterns] Pattern match is redundant In a case alternative: App (App "or" a) b -> ... | 13 | App ( App "or" a ) b -> Just 4 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Just 4 Nothing }}} The pattern match checker complains about the `"or"` case of `go` being redundant, but, when it is removed (as it is in `go'`) the output is different. `go''` demonstrates that `OverloadedStrings` is relevant, as that is *not* generating a warning. Removing either of the other two cases of `go` also suppresses the warning: all three are necessary. As seen in the transcript, this is happening on both 8.4.3 and 8.6.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 6 14:02:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Oct 2018 14:02:46 -0000 Subject: [GHC] #15713: Bogus -Woverlapping-patterns warning with OverloadedStrings In-Reply-To: <057.7b8d57738ba0aca7168c860a8f80b0d4@haskell.org> References: <057.7b8d57738ba0aca7168c860a8f80b0d4@haskell.org> Message-ID: <072.3081ab079964c130acf4022f7f28624d@haskell.org> #15713: Bogus -Woverlapping-patterns warning with OverloadedStrings -------------------------------------+------------------------------------- Reporter: | Owner: (none) quasicomputational | Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 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 RyanGlScott): * keywords: => PatternMatchWarnings -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 6 14:54:33 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Oct 2018 14:54:33 -0000 Subject: [GHC] #12469: Memory fence on writes to MutVar/Array missing on ARM In-Reply-To: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> References: <047.66ee5a4f3c8105fd7f2dd250bf4478e5@haskell.org> Message-ID: <062.6d7071f339a56f516b95a617bc0183cc@haskell.org> #12469: Memory fence on writes to MutVar/Array missing on ARM -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: memory model Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 12537 Related Tickets: | Differential Rev(s): Phab:D2495 Wiki Page: | Phab:D2525 -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"8be27c0371d53e051d59ba20dd65103bbb8d32d3/ghc" 8be27c03/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8be27c0371d53e051d59ba20dd65103bbb8d32d3" Add a missing write barrier to small array writes Write barriers for large array writes were added in D2525, as a part of #12469. However it seems we forgot about small arrays. This patch adds the same write barrier to small array writes. Reviewers: simonmar, bgamari Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #12469 Differential Revision: https://phabricator.haskell.org/D5209 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 6 15:29:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Oct 2018 15:29:54 -0000 Subject: [GHC] #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 In-Reply-To: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> References: <051.3edcb4a5909adf7ee53c809296177fd9@haskell.org> Message-ID: <066.c1ef469c36cb746b87c1ef5d8f28e355@haskell.org> #15304: Huge increase of compile time and memory use from 8.0.2 to 8.2.2 or 8.4.2 -------------------------------------+------------------------------------- Reporter: NathanWaivio | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NathanWaivio): I've continued to investigate and found an alternate work around. I changed every $! in the code to a $ I would get the improved compile performance even with worker-wrapper active. I'm not sure what that means. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 6 16:21:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Oct 2018 16:21:54 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.aa941b0bec81b344c1ad9b8152e2b59b@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): I did a little bit of debugging for the segfault problem. I'm wondering if I'm triggering some other bug, because the segfault is happening during GC: {{{ >>> bt #0 evacuate1 (p=p at entry=0x420fe54720) at rts/sm/Evac.c:642 #1 0x00007fdcea628c35 in scavenge_block1 (bd=0x420fe01500) at rts/sm/Scav.c:541 #2 0x00007fdcea648f5f in scavenge_find_work () at rts/sm/Scav.c:2067 #3 scavenge_loop1 () at rts/sm/Scav.c:2130 #4 0x00007fdcea6502e2 in scavenge_until_all_done () at rts/sm/GC.c:1090 #5 0x00007fdcea650c3f in GarbageCollect (collect_gen=collect_gen at entry=1, do_heap_census=do_heap_census at entry=false, gc_type=gc_type at entry=2, cap=cap at entry=0x7fdcea686ac0 , idle_cap=idle_cap at entry=0x1f14dd0) at rts/sm/GC.c:421 #6 0x00007fdcea635f17 in scheduleDoGC (pcap=pcap at entry=0x7ffdb2c2fea0, task=task at entry=0x1f109b0, force_major=force_major at entry=false) at rts/Schedule.c:1798 #7 0x00007fdcea6368ec in schedule (initialCapability=initialCapability at entry=0x7fdcea686ac0 , task=task at entry=0x1f109b0) at rts/Schedule.c:546 #8 0x00007fdcea637e41 in scheduleWaitThread (tso=0x4200006388, ret=ret at entry=0x0, pcap=pcap at entry=0x7ffdb2c2ff38) at rts/Schedule.c:2537 #9 0x00007fdcea642a98 in rts_evalLazyIO (cap=cap at entry=0x7ffdb2c2ff38, p=p at entry=0x756150, ret=ret at entry=0x0) at rts/RtsAPI.c:530 #10 0x00007fdcea6433ec in hs_main (argc=, argv=, main_closure=0x756150, rts_config=...) at rts/RtsMain.c:72 #11 0x0000000000749560 in main () }}} The info table pointer is wrong: {{{ >>> print info $1 = (const StgInfoTable *) 0x72 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 6 19:34:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Oct 2018 19:34:29 -0000 Subject: [GHC] #15714: Compacting StaticPtr of a function doesn't work Message-ID: <043.384efd9178ed9a6548163723ec902c15@haskell.org> #15714: Compacting StaticPtr of a function doesn't work -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I think we should be able to compact a StaticPtr of a function, but it currently doesn't work. Reproducer: {{{#!haskell {-# LANGUAGE StaticPointers #-} import GHC.StaticPtr import Data.Compact foo :: Int -> Int foo x = x^2 main = do c <- compact (static foo :: StaticPtr (Int -> Int)) return () }}} Output: {{{ ./compact_test compact_test: compaction failed: cannot compact functions }}} Tried with 8.4.3 (compact on hackage doesn't build with 8.6). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 6 20:39:30 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Oct 2018 20:39:30 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.a1dc826d1f0ac18c680f3551cb8ac72b@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): Interestingly, if I revert the Cmm bits and always introduce a case on dataToTag# args in CorePrep I can validate. Patch is [https://github.com/osa1/ghc/commit/1b9bd4769c2c70b23ef8739aba116f9d18628b00 here]. I'll compare the differences in generated code in this branch and Phab:D5201. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 6 20:40:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Oct 2018 20:40:39 -0000 Subject: [GHC] #15714: Compacting StaticPtr of a function doesn't work In-Reply-To: <043.384efd9178ed9a6548163723ec902c15@haskell.org> References: <043.384efd9178ed9a6548163723ec902c15@haskell.org> Message-ID: <058.a20c950872c14dfb450d4e28b09af886@haskell.org> #15714: Compacting StaticPtr of a function doesn't work -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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 simonmar): This is because a `FUN_STATIC` can refer (directly or indirectly) to CAFs, and compact regions cannot have any dependencies on other heap objects. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 6 20:47:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Oct 2018 20:47:56 -0000 Subject: [GHC] #15714: Compacting StaticPtr of a function doesn't work In-Reply-To: <043.384efd9178ed9a6548163723ec902c15@haskell.org> References: <043.384efd9178ed9a6548163723ec902c15@haskell.org> Message-ID: <058.affa35fcd053465a2020ee2e0e7a1589@haskell.org> #15714: Compacting StaticPtr of a function doesn't work -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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): Ah, that makes sense. But at least in theory we could check if the FUN has CAF references before failing, right? StaticPtr to a FUN with no CAF references should be OK I think -- although I guess in practice that may not be too useful as most functions probably have some CAF references. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 6 20:53:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Oct 2018 20:53:16 -0000 Subject: [GHC] #15714: Compacting StaticPtr of a function doesn't work In-Reply-To: <043.384efd9178ed9a6548163723ec902c15@haskell.org> References: <043.384efd9178ed9a6548163723ec902c15@haskell.org> Message-ID: <058.f73a98c39e0fa3e14a4767dc755a5fba@haskell.org> #15714: Compacting StaticPtr of a function doesn't work -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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 simonmar): I don't think that would be deterministic enough to be a reliable API. You could imagine the compiler making different optimisation choices which would change whether a function refers to CAFs or not - e.g. full laziness can do that, and then your program either works or not depending on whether optimisation is turned on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 6 20:54:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Oct 2018 20:54:35 -0000 Subject: [GHC] #15714: Compacting StaticPtr of a function doesn't work In-Reply-To: <043.384efd9178ed9a6548163723ec902c15@haskell.org> References: <043.384efd9178ed9a6548163723ec902c15@haskell.org> Message-ID: <058.e653404e2317ed866faf930e18fa0c53@haskell.org> #15714: Compacting StaticPtr of a function doesn't work -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 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 osa1): * status: new => closed * resolution: => invalid Comment: Agreed -- closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 6 23:40:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Oct 2018 23:40:56 -0000 Subject: [GHC] #15692: GHC panic from pattern synonyms + deferred type errors In-Reply-To: <051.39157d43d1b8d263a8e2728339a9f8aa@haskell.org> References: <051.39157d43d1b8d263a8e2728339a9f8aa@haskell.org> Message-ID: <066.586a50061973058f6bde752c97b80cca@haskell.org> #15692: GHC panic from pattern synonyms + deferred type errors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | patsyn/should_fail/T15692 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Is this the same issue? {{{#!hs {-# Language DataKinds, PatternSynonyms, KindSignatures, GADTs #-} {-# Options_GHC -fdefer-type-errors #-} import Data.Kind data N = O | S N data Fin :: N -> Type where FinO :: Fin (S n) data Exists :: (Type -> Type) -> Type where Exists :: f xx -> Exists f pattern O' = Exists FinO }}} {{{ $ ghci -ignore-dot-ghci hs/486.hs GHCi, version 8.7.20180828: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( hs/486.hs, interpreted ) hs/486.hs:15:21: warning: [-Wdeferred-type-errors] • Couldn't match kind ‘*’ with ‘N’ When matching types a :: * -> * Fin :: N -> * Expected type: a xx Actual type: Fin a0 • In the pattern: FinO In the pattern: Exists FinO In the declaration for pattern synonym ‘O'’ | 15 | pattern O' = Exists FinO | ^^^^ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20180828 for x86_64-unknown-linux): urk! lookup local fingerprint $mO' [iESflb :-> ($trModule, 1ca40dc83a9c879effdb760462cc9a2d), iESgex :-> ($tc'O, 111d9d0cf0cb57db9c77a4d216344e54), iESgKA :-> ($tc'S, 2d7f65aefd4d8c7deac332c17204e2c9), iESgKC :-> ($tcN, 04f8b57a4955bc680fd71fe4cee31a00), iESgKD :-> ($tc'FinO, a20e4215870bd6fb39afb23de637e84a), iESgKF :-> ($tcFin, 8a38d4451422cc87d0cc0459132dad73), iESgKG :-> ($tc'Exists, 365c3f6bd1b8c9580d1ae883b83c2c68), iESgKI :-> ($tcExists, 11a84f66f5d99fe1d3547c0ad0f538ae)] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/iface/MkIface.hs:524:37 in ghc:MkIface Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 7 00:34:51 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Oct 2018 00:34:51 -0000 Subject: [GHC] #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` In-Reply-To: <046.74175c624c857c997e111eade5eabf30@haskell.org> References: <046.74175c624c857c997e111eade5eabf30@haskell.org> Message-ID: <061.ab01838d0101e9bef6a44eecf2969e63@haskell.org> #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` -------------------------------------+------------------------------------- Reporter: rockbmb | Owner: rockbmb Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: base, | Data.Fixed Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ashley Yakeley): I would also like to see Data.Fixed (and possibly also Data.Ratio and Data.Complex) put in a new core library. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 7 08:34:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Oct 2018 08:34:17 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.efb9b274b755627b9499487be85dff07@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): Phab:D5201 currently validates and is ready for reviews. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 7 10:24:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Oct 2018 10:24:50 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.a62562a262f8c09afb6c9eb8454c92f5@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): Phab:D5170 #12753 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: infoneeded => patch * differential: => Phab:D5170 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 7 10:59:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Oct 2018 10:59:47 -0000 Subject: [GHC] #12932: -fexternal-interpreter` fails to find symbols In-Reply-To: <046.e268f025fb07ea6927f21c0906b2681d@haskell.org> References: <046.e268f025fb07ea6927f21c0906b2681d@haskell.org> Message-ID: <061.ff74ccec63e7eb6288bc1df5f7e22a97@haskell.org> #12932: -fexternal-interpreter` fails to find symbols -----------------------------+---------------------------------------- Reporter: dominic | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12946 | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Comment (by k-bx): > Do holler if you are affected by this Not affected myself ("works for me"), but for some people it might get in a way of building a profiling version of their app, see https://github.com/commercialhaskell/stack/issues/4275#issuecomment-427610436 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 7 11:35:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Oct 2018 11:35:21 -0000 Subject: [GHC] #15715: problematic openFile with named pipes Message-ID: <042.429251213bdecb6b7a1355c60029957a@haskell.org> #15715: problematic openFile with named pipes -------------------------------------+------------------------------------- Reporter: adp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 8.4.3 libraries/base | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- - while `openFile`'ng named pipes for `ReadMode` works fine, on `WriteMode` or `AppendMode` it throws `openFile: does not exist (No such device or address)`; and on `WriteReadMode`, it opens it, but seem not able to write to it (the process hearing on the other side didn't hear anything). - `writeFile` and `appendFile` works though. - using stack `resolver: lts-12.4`, on ubuntu 16.04 LTS -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 7 13:15:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Oct 2018 13:15:13 -0000 Subject: [GHC] #15692: GHC panic from pattern synonyms + deferred type errors In-Reply-To: <051.39157d43d1b8d263a8e2728339a9f8aa@haskell.org> References: <051.39157d43d1b8d263a8e2728339a9f8aa@haskell.org> Message-ID: <066.de8210fe37926d5bc5bd7eeade44bda2@haskell.org> #15692: GHC panic from pattern synonyms + deferred type errors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | patsyn/should_fail/T15692 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:6 Iceland_jack]: > Is this the same issue? Yes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 7 14:05:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Oct 2018 14:05:04 -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.8811422d42a8a5ceb8c1c95fc9947d90@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): bgamari: ping :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 7 14:11:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Oct 2018 14:11:50 -0000 Subject: [GHC] #15716: GHC hangs on default implementation of type family Message-ID: <047.d351f8fcf1aa5d446b36a2139459c9d3@haskell.org> #15716: GHC hangs on default implementation of type family -------------------------------------+------------------------------------- Reporter: Heimdell | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.4.1 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: -------------------------------------+------------------------------------- I have this code: {{{ {-# language TypeFamilies #-} {-# language MultiParamTypeClasses #-} {-# language FlexibleInstances #-} import Control.Monad.Except class Component comp where data Error comp :: * type ComponentT comp :: * -> * type ComponentT comp = ExceptT (Error comp) }}} I expect it to either compile or fail with error. Instead, GHC[i] hangs every time. It prints {{{ :10:28: error: }}} and then hangs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 7 14:45:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Oct 2018 14:45:28 -0000 Subject: [GHC] #15716: GHC hangs on default implementation of type family In-Reply-To: <047.d351f8fcf1aa5d446b36a2139459c9d3@haskell.org> References: <047.d351f8fcf1aa5d446b36a2139459c9d3@haskell.org> Message-ID: <062.e7eb295f6bce2d82e10ea092c378581b@haskell.org> #15716: GHC hangs on default implementation of type family -------------------------------------+------------------------------------- Reporter: Heimdell | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Heimdell): It seems to consume neither any memory during the hang, nor processor time. `strace` says: {{{ futex(0x24c8440, FUTEX_WAIT_PRIVATE, 0, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set) --- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=NULL}} --- rt_sigreturn({mask=[]}) = 202 futex(0x24c8440, FUTEX_WAIT_PRIVATE, 0, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set) --- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=NULL}} --- write(9, "\377\0\0\0\0\0\0\0", 8) = 8 rt_sigreturn({mask=[]}) = 202 futex(0x24c8440, FUTEX_WAIT_PRIVATE, 0, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set) --- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=NULL}} --- rt_sigreturn({mask=[]}) = 202 futex(0x24c8440, FUTEX_WAIT_PRIVATE, 0, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set) --- SIGVTALRM {si_signo=SIGVTALRM, si_code=SI_TIMER, si_timerid=0, si_overrun=0, si_value={int=0, ptr=NULL}} --- rt_sigreturn({mask=[]}) = 202 futex(0x24c8440, FUTEX_WAIT_PRIVATE, 0, NULL^C) = ? ERESTARTSYS (To be restarted if SA_RESTART is set) ^Cstrace: Process 13755 detached }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 7 15:15:00 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Oct 2018 15:15:00 -0000 Subject: [GHC] #2515: Flag to suppress orphan instance warnings In-Reply-To: <042.4664e49fbb66d0162bc19b3088fe61ba@haskell.org> References: <042.4664e49fbb66d0162bc19b3088fe61ba@haskell.org> Message-ID: <057.cf6c7458ba505d313901ab48e917d6e8@haskell.org> #2515: Flag to suppress orphan instance warnings -------------------------------------+------------------------------------- Reporter: tim | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 6.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10150 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Lemming): * related: => #10150 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 7 15:20:27 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Oct 2018 15:20:27 -0000 Subject: [GHC] #15716: GHC hangs on default implementation of type family In-Reply-To: <047.d351f8fcf1aa5d446b36a2139459c9d3@haskell.org> References: <047.d351f8fcf1aa5d446b36a2139459c9d3@haskell.org> Message-ID: <062.e29ac94b54aeb2b3986dad83fe243035@haskell.org> #15716: GHC hangs on default implementation of type family -------------------------------------+------------------------------------- Reporter: Heimdell | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): I cannot reproduce the hang on 8.4.3, I get an error instead: {{{ A.hs:10:28: error: • Expecting one more argument to ‘ExceptT (Error comp)’ Expected kind ‘* -> *’, but ‘ExceptT (Error comp)’ has kind ‘(* -> *) -> * -> *’ • In the type ‘ExceptT (Error comp)’ In the default type instance declaration for ‘ComponentT’ In the class declaration for ‘Component’ | 10 | type ComponentT comp = ExceptT (Error comp) | }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 7 15:23:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Oct 2018 15:23:46 -0000 Subject: [GHC] #14854: The size of FastString table is suboptimal for large codebases In-Reply-To: <046.96a71a8566a954e21839a1a60572305e@haskell.org> References: <046.96a71a8566a954e21839a1a60572305e@haskell.org> Message-ID: <061.acb9166bc51204acd2bd5ec6b6179616@haskell.org> #14854: The size of FastString table is suboptimal for large codebases -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5211 Wiki Page: | -------------------------------------+------------------------------------- Changes (by watashi): * differential: => Phab:D5211 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 7 15:24:49 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Oct 2018 15:24:49 -0000 Subject: [GHC] #13841: ADOPT pragma for silencing orphan instances warnings per instance In-Reply-To: <049.5c7de5285a14f8dfadfcf646791f0efd@haskell.org> References: <049.5c7de5285a14f8dfadfcf646791f0efd@haskell.org> Message-ID: <064.cfae18f893d5d88a11e82d095db2fbbf@haskell.org> #13841: ADOPT pragma for silencing orphan instances warnings per instance -------------------------------------+------------------------------------- Reporter: cocreature | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #602, #10150 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): Is there already a ticket for disabling of certain warnings within source regions? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 7 15:50:27 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Oct 2018 15:50:27 -0000 Subject: [GHC] #15717: Performance regression in for_ alternatives from GHC 8.2.2 to newer GHCs Message-ID: <042.01fd95f6e2a7057fc553813802d9c3b7@haskell.org> #15717: Performance regression in for_ alternatives from GHC 8.2.2 to newer GHCs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We are investigating various ways to make `for_` and `traverse_` not leak space by changing the type signature from `(a -> f b) -> t a -> f ()` to `(a -> f ()) -> t a -> f ()`. While doing so, we noticed a regression from GHC 8.2.2 to 8.4.3 and 8.6.1. The code: https://gist.github.com/nh2/b8f9f8e60443bdb30c1cd7e0acb8c8eb/bb1cc1a4987091fcd41c07b0a6f0512f96a992ae Run against 3 different GHC releases: {{{ # 8.2.2 stack --resolver lts-11.22 ghc -- --make -O2 -rtsopts ./TraverseMaybePerformance.hs && /usr/bin/time ./TraverseMaybePerformance 8 +RTS -sstderr 460,309,368 bytes allocated in the heap # 8.4.3 stack --resolver lts-12.11 ghc -- --make -O2 -rtsopts ./TraverseMaybePerformance.hs && /usr/bin/time ./TraverseMaybePerformance 8 +RTS -sstderr 860,301,736 bytes allocated in the heap # 8.6.1 stack --resolver nightly-2018-10-06 ghc -- --make -O2 -rtsopts ./TraverseMaybePerformance.hs && /usr/bin/time ./TraverseMaybePerformance 8 +RTS -sstderr 860,301,784 bytes allocated in the heap }}} Allocations doubled starting with 8.4. All was run on Ubuntu 16.04 64-bit. We haven't investigated in detail yet (also whether it's a GHC or libraries problem) since we're actually trying to do something else and this came out on the side, but it looks important enough to share already. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 7 16:01:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Oct 2018 16:01:17 -0000 Subject: [GHC] #15660: source file modify race leads to inconsistent error message In-Reply-To: <047.0bb5271dc9d70158327714b5707bda53@haskell.org> References: <047.0bb5271dc9d70158327714b5707bda53@haskell.org> Message-ID: <062.cb4934ea27d7aa64ad7cad6a5b0800bf@haskell.org> #15660: source file modify race leads to inconsistent error message -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I argued for your second option when we were discussion how to implement caret diagnostics. However, others made the very reasonable counterpoint that this won't work well with CPP. This is unfortunate, but CPP is too commonplace to ignore at this point. Copying sources to `/tmp` sounds plausible, although could be a bit painful to implement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 7 16:10:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Oct 2018 16:10:57 -0000 Subject: [GHC] #15660: source file modify race leads to inconsistent error message In-Reply-To: <047.0bb5271dc9d70158327714b5707bda53@haskell.org> References: <047.0bb5271dc9d70158327714b5707bda53@haskell.org> Message-ID: <062.be2366207e64f3015e8e68eb6084fae4@haskell.org> #15660: source file modify race leads to inconsistent error message -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by joeyhess): When I experienced this in the wild, the only problem was the surprise that it was mixing versions of the file; once past the surprise it was little bother to need to look up the code manually. So it would probably suffice for ghc to detect the race and not quote the wrong version of the file. I suppose it could use file stat information or a hash and so avoid keeping a copy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 7 19:01:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Oct 2018 19:01:50 -0000 Subject: [GHC] #15571: Eager AP_STACK blackholing causes incorrect size info for sanity checks In-Reply-To: <043.9213207e6a514a137db4ef0469470bf7@haskell.org> References: <043.9213207e6a514a137db4ef0469470bf7@haskell.org> Message-ID: <058.9fc9f1da0add0fbaf4af2fd4d34e5af0@haskell.org> #15571: Eager AP_STACK blackholing causes incorrect size info for sanity checks -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.2 Component: Runtime System | 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: #15508 | Differential Rev(s): Phab:D5165 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => merge * milestone: => 8.6.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 7 23:16:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Oct 2018 23:16:11 -0000 Subject: [GHC] #13841: ADOPT pragma for silencing orphan instances warnings per instance In-Reply-To: <049.5c7de5285a14f8dfadfcf646791f0efd@haskell.org> References: <049.5c7de5285a14f8dfadfcf646791f0efd@haskell.org> Message-ID: <064.97041115ca3ccc1da76100449d860c41@haskell.org> #13841: ADOPT pragma for silencing orphan instances warnings per instance -------------------------------------+------------------------------------- Reporter: cocreature | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #602, #10150 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I think you are looking for #602. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 7 23:21:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Oct 2018 23:21:06 -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.0514ea86f5db7a65b50d3814ae669202@haskell.org> #13896: Use response file to invoke hsc2hs ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.2 Component: hsc2hs | Version: 8.0.1 Resolution: fixed | 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: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: 8.8.1 => 8.6.2 Comment: Sounds like this is resolved in cabal-2.4, which shipped with GHC 8.6.1. Thanks for the pings, ckoparkar! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 7 23:21:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Oct 2018 23:21:14 -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.e536d91eaa3c7c0bb07ba268aa3f921c@haskell.org> #13896: Use response file to invoke hsc2hs ---------------------------------+---------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: hsc2hs | Version: 8.0.1 Resolution: fixed | 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: | ---------------------------------+---------------------------------------- Changes (by bgamari): * milestone: 8.6.2 => 8.6.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 7 23:25:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Oct 2018 23:25:29 -0000 Subject: [GHC] #15715: problematic openFile with named pipes In-Reply-To: <042.429251213bdecb6b7a1355c60029957a@haskell.org> References: <042.429251213bdecb6b7a1355c60029957a@haskell.org> Message-ID: <057.642653d194f6be198105221fd81c690a@haskell.org> #15715: problematic openFile with named pipes -------------------------------------+------------------------------------- Reporter: adp | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 8.4.3 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid Comment: This is due to the FIFO semantics. To quote `fifo(7)`: > A process can open a FIFO in nonblocking mode. In this case, opening for read-only succeeds even if no one has opened on the write side yet and opening for write-only fails with `ENXIO` (no such device or address) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 01:04:44 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 01:04:44 -0000 Subject: [GHC] #15718: Build panic on ghc-8.6.1 under FreeBSD when using -fllvm Message-ID: <046.0992e281b492040f72d63791112b8b7a@haskell.org> #15718: Build panic on ghc-8.6.1 under FreeBSD when using -fllvm -------------------------------------+------------------------------------- Reporter: gwright | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: FreeBSD Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This looks like a straightforward oversight. I am building my pure haskell LU solver under FreeBSD. I use the -fllvm compiler option because I need extra numerical performance. When I build, I get (this is the output from GitLab CI, which is in turn running 'stack build') {{{ Running with gitlab-runner 11.2.0 (35e8515d) on stacker.18clay.com a2111f63 Using Shell executor... Running on stacker.18clay.com... Fetching changes... Removing .stack-work/ HEAD is now at f8fe3b4 Use llvm60 on FreeBSD. From https://gitlab.18clay.com/software/luSolve f8fe3b4..c993a26 streamlined -> origin/streamlined Checking out c993a262 as streamlined... Skipping Git submodules setup $ stack build --pedantic luSolve-0.5: configure (lib) Configuring luSolve-0.5... luSolve-0.5: build (lib) Preprocessing library for luSolve-0.5.. Building library for luSolve-0.5.. [1 of 1] Compiling Numeric.LinearAlgebra.LUSolve ( src/Numeric/LinearAlgebra/LUSolve.hs, .stack- work/dist/x86_64-freebsd/Cabal-2.4.0.1/build/Numeric/LinearAlgebra/LUSolve.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.6.1 for x86_64-portbld-freebsd): Failed to lookup the datalayout for x86_64-unknown-freebsd; available targets: ["i386-unknown-windows","i686-unknown-windows","x86_64 -unknown-windows","arm-unknown-linux-gnueabihf","armv6-unknown-linux- gnueabihf","armv6l-unknown-linux-gnueabihf","armv7-unknown-linux-gnueabihf ","armv7a-unknown-linux-gnueabi","armv7l-unknown-linux-gnueabihf","aarch64 -unknown-linux-gnu","aarch64-unknown-linux","i386-unknown-linux-gnu","i386 -unknown-linux","x86_64-unknown-linux-gnu","x86_64-unknown-linux","armv7 -unknown-linux-androideabi","aarch64-unknown-linux-android","powerpc64le- unknown-linux","amd64-portbld-freebsd","arm-unknown-nto-qnx-eabi","i386 -apple-darwin","x86_64-apple-darwin","armv7-apple-ios","aarch64-apple- ios","i386-apple-ios","x86_64-apple-ios","aarch64-unknown-freebsd","armv6 -unknown-freebsd-gnueabihf","armv7-unknown-freebsd-gnueabihf"] CallStack (from HasCallStack): error, called at compiler/llvmGen/LlvmCodeGen.hs:96:24 in ghc:LlvmCodeGen Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- While building custom Setup.hs for package luSolve-0.5 using: /home/gitlab-runner/.stack/setup-exe-cache/x86_64-freebsd/Cabal- simple_mPHDZzAJ_2.4.0.1_ghc-8.6.1 --builddir=.stack- work/dist/x86_64-freebsd/Cabal-2.4.0.1 build lib:luSolve --ghc-options " -ddump-hi -ddump-to-file" Process exited with code: ExitFailure 1 ERROR: Job failed: exit status 1 }}} The bug seems simple. The compiler is looking for the datalayout for x86_64-unknown-freebsd; but what is available is amd64-portbld-freebsd. Is this just a simple naming error? The stack resolver was the cutting- edge nightly-2018-10-6; if it is a problem in their packaging rather than ghc itself I will file a report with them (though ghc did panic here, and as the breath ebbed from its ASTs and light faded from the code generator, it pleaded that a bug report be filed). I've attached the .cabal file in case it helps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 01:05:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 01:05:18 -0000 Subject: [GHC] #15718: Build panic on ghc-8.6.1 under FreeBSD when using -fllvm In-Reply-To: <046.0992e281b492040f72d63791112b8b7a@haskell.org> References: <046.0992e281b492040f72d63791112b8b7a@haskell.org> Message-ID: <061.9895e9a7777dd69e5862901a11f1e1fd@haskell.org> #15718: Build panic on ghc-8.6.1 under FreeBSD when using -fllvm -------------------------------------+------------------------------------- Reporter: gwright | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gwright): * Attachment "luSolve.cabal" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 01:13:14 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 01:13:14 -0000 Subject: [GHC] #15719: Primitive atomic logical operations Message-ID: <045.ff9998160297b6edc592f0d47158699d@haskell.org> #15719: Primitive atomic logical operations -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- We offer fetch-and-and, fetch-and-or, etc., which are available as GCC intrinsics. Unfortunately, as far as I can tell those operations are ''not'' actually offered by x86_64. So I ''believe'' GCC must be implementing them using CAS loops on that (rather important) architecture. On the other hand, that instruction set does offer a plain atomic-and, atomic-or, etc., that do not fetch. In some cases, that may be sufficient. For example, I'm currently designing a potential replacement for the stable pointer system that uses a bitmap to represent a free list. Each deletion operation needs to update the bitmap (or) and then check whether a certain threshold number of entries are free (popcnt). One straightforward way to accomplish this with available instructions would be 1. Atomic OR to mark an entry free 2. Load the bitmap 3. Perform the popcnt test Of course, it would be ''nice'' to have fetch-and-or here, but we don't actually need it--if a bunch of deletions happen concurrently, then at least one of them will see the popcnt over the threshold. Could we (and should we) offer non-fetching atomic operations implemented natively where they're available? One important question is of course whether we'd actually get better performance this way than using a CAS loop. I would conjecture that this is this case under contention, but I don't actually know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 01:18:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 01:18:25 -0000 Subject: [GHC] #15719: Primitive atomic logical operations In-Reply-To: <045.ff9998160297b6edc592f0d47158699d@haskell.org> References: <045.ff9998160297b6edc592f0d47158699d@haskell.org> Message-ID: <060.585e36a135ff64ffdc7c352406a8c518@haskell.org> #15719: Primitive atomic logical operations -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dfeuer: Old description: > We offer fetch-and-and, fetch-and-or, etc., which are available as GCC > intrinsics. Unfortunately, as far as I can tell those operations are > ''not'' actually offered by x86_64. So I ''believe'' GCC must be > implementing them using CAS loops on that (rather important) > architecture. On the other hand, that instruction set does offer a plain > atomic-and, atomic-or, etc., that do not fetch. In some cases, that may > be sufficient. For example, I'm currently designing a potential > replacement for the stable pointer system that uses a bitmap to represent > a free list. Each deletion operation needs to update the bitmap (or) and > then check whether a certain threshold number of entries are free > (popcnt). One straightforward way to accomplish this with available > instructions would be > > 1. Atomic OR to mark an entry free > 2. Load the bitmap > 3. Perform the popcnt test > > Of course, it would be ''nice'' to have fetch-and-or here, but we don't > actually need it--if a bunch of deletions happen concurrently, then at > least one of them will see the popcnt over the threshold. > > Could we (and should we) offer non-fetching atomic operations implemented > natively where they're available? One important question is of course > whether we'd actually get better performance this way than using a CAS > loop. I would conjecture that this is this case under contention, but I > don't actually know. New description: We offer fetch-and-and, fetch-and-or, etc., which are available as GCC intrinsics. Unfortunately, as far as I can tell those operations are ''not'' actually offered by x86_64. So I ''believe'' GCC must be implementing them using CAS loops on that (rather important) architecture. On the other hand, that instruction set does offer a plain atomic-and, atomic-or, etc., that do not fetch. In some cases, that may be sufficient. For example, I'm currently designing a potential replacement for the stable pointer system that uses a bitmap to represent a free list. Each deletion operation needs to update the bitmap (or) and then check whether a certain threshold number of entries are free (popcnt). One straightforward way to accomplish this with available instructions would be 1. Atomic OR to mark an entry free 2. Load the bitmap 3. Perform the popcnt test Of course, it would be ''nice'' to have fetch-and-or here, but we don't actually need it--if a bunch of deletions happen concurrently, then at least one of them will see the popcnt over the threshold (unless intervening allocations with the same bitmap bring the popcnt below the threshold, which is also perfectly acceptable). Could we (and should we) offer non-fetching atomic operations implemented natively where they're available? One important question is of course whether we'd actually get better performance this way than using a CAS loop. I would conjecture that this is this case under contention, but I don't actually know. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 01:30:02 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 01:30:02 -0000 Subject: [GHC] #15718: Build panic on ghc-8.6.1 under FreeBSD when using -fllvm In-Reply-To: <046.0992e281b492040f72d63791112b8b7a@haskell.org> References: <046.0992e281b492040f72d63791112b8b7a@haskell.org> Message-ID: <061.db23f41bec58a02d4a78fb33bcd81822@haskell.org> #15718: Build panic on ghc-8.6.1 under FreeBSD when using -fllvm -------------------------------------+------------------------------------- Reporter: gwright | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: FreeBSD | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gwright): The publicly accessible source code for the linear system solver is at [https://github.com/gwright83/luSolve], though that version doesn't specify building with LLVM in the .cabal file. The .cabal file attached to this ticket is the one that exhibits the failure. The build OS is FreeBSD 11.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 02:21:41 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 02:21:41 -0000 Subject: [GHC] #15710: Should GHC accept a type signature that needs coercion quantification? In-Reply-To: <046.5bf95bcb5259eed36b1ec15b928de8c8@haskell.org> References: <046.5bf95bcb5259eed36b1ec15b928de8c8@haskell.org> Message-ID: <061.fceeb003bb119efe2cfd4f1437b39447@haskell.org> #15710: Should GHC accept a type signature that needs coercion quantification? -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, I'm arguing both sides -- but with good reason. `t1 ~# t2` is not a constraint ''today'', and thus it shouldn't respond to `isPredTy`. But this ticket is all about ''tomorrow'', when I do think it could become a constraint. Would we be more efficient if constraints could be strict and unboxed? I imagine "yes". If so, then the current story isn't working as well as it could be. As for tupling: we could make `( ... )` be an unboxed tuple if it's written to the left of `=>`. In the end, I just think of the parens and commas as concrete syntax for some unspecified abstract syntax that handles sets of constraints here. (This is not how I think of the argument to `Dict`, say, where order suddenly matters.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 03:00:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 03:00:31 -0000 Subject: [GHC] #15720: Assign to literals is allowed in ghci Message-ID: <049.0b7514ea0558703d157a538647579f02@haskell.org> #15720: Assign to literals is allowed in ghci -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I have been asked that why `1 = 2` is allowed in ghci, which is quite confusing for beginners. {{{ > 1 = 2 > 1 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 03:05:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 03:05:15 -0000 Subject: [GHC] #15721: Command `:show bindings` throws exception for bindings without `let` Message-ID: <049.4a313483322b4bef10e6d1a3d81913cd@haskell.org> #15721: Command `:show bindings` throws exception for bindings without `let` -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The command `:show bindings` works for `let a = 1`: {{{#!hs Prelude> let a = 1 Prelude> :show bindings a :: Num p => p = _ }}} But not for `a = 1`: {{{#!hs Prelude> a = 1 Prelude> :show bindings ghc-stage2.exe: ^^ Could not load 'interactive_Ghci1_zdtrModule2_closure', dependency unresolved. See top entry above. ghc-stage2.exe: ^^ Could not load 'interactive_Ghci1_zdtrModule4_closure', dependency unresolved. See top entry above. $trModule :: GHC.Types.Module = _ $trModule1 :: GHC.Types.TrName = _ $trModule2 :: GHC.Prim.Addr# = *** Exception: ByteCodeLink.lookupCE During interactive linking, GHCi couldn't find the following symbol: interactive_Ghci1_zdtrModule2_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs at haskell.org $trModule3 :: GHC.Types.TrName = _ $trModule4 :: GHC.Prim.Addr# = *** Exception: ByteCodeLink.lookupCE During interactive linking, GHCi couldn't find the following symbol: interactive_Ghci1_zdtrModule4_closure This may be due to you not asking GHCi to load extra object files, archives or DLLs needed by your current session. Restart GHCi, specifying the missing library using the -L/path/to/object/dir and -lmissinglibname flags, or simply by naming the relevant files on the GHCi command line. Alternatively, this link failure might indicate a bug in GHCi. If you suspect the latter, please send a bug report to: glasgow-haskell-bugs at haskell.org a :: Num p => p = _ a1 :: Integer = _ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 03:10:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 03:10:32 -0000 Subject: [GHC] #15720: Assign to literals is allowed in ghci In-Reply-To: <049.0b7514ea0558703d157a538647579f02@haskell.org> References: <049.0b7514ea0558703d157a538647579f02@haskell.org> Message-ID: <064.dd8ef55e949b83e77e33bc7dd21edd93@haskell.org> #15720: Assign to literals is allowed in ghci -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This should perhaps be an on-by-default warning, but it's valid Haskell code. `1 = 2` is a lazy pattern match. Because it's lazy but binds no variables, we never see an error reported. This is maybe silly, but it doesn't quite seem worth putting another rule in Haskell to avoid this possibility. That said, a pattern-match that binds no variables is warned by `-Wunused- pattern-binds`; maybe this should really be its own warning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 04:02:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 04:02:33 -0000 Subject: [GHC] #15720: Assign to literals is allowed in ghci In-Reply-To: <049.0b7514ea0558703d157a538647579f02@haskell.org> References: <049.0b7514ea0558703d157a538647579f02@haskell.org> Message-ID: <064.322ff562b7c8d77dea865f489e2acfa4@haskell.org> #15720: Assign to literals is allowed in ghci -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): Should we enable `-Wunused-pattern-binds` by default ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 06:50:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 06:50:27 -0000 Subject: [GHC] #15715: problematic openFile with named pipes In-Reply-To: <042.429251213bdecb6b7a1355c60029957a@haskell.org> References: <042.429251213bdecb6b7a1355c60029957a@haskell.org> Message-ID: <057.df0f13e0dea246f1ec174ac8943ac2c4@haskell.org> #15715: problematic openFile with named pipes -------------------------------------+------------------------------------- Reporter: adp | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 8.4.3 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adp): Thanks for the answer, very helpful! Given in the future some people might have the same problem I had, shouldn't the docs be updated? Currently it says: > This operation may fail with: > > - `isAlreadyInUseError` if the file is already open and cannot be reopened; > - `isDoesNotExistError` if the file does not exist; or > - `isPermissionError` if the user does not have permission to open the file. Not mentioning that one could get `isDoesNotExistError` by other reason than the file not existing, like in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 06:52:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 06:52:01 -0000 Subject: [GHC] #15715: problematic openFile with named pipes In-Reply-To: <042.429251213bdecb6b7a1355c60029957a@haskell.org> References: <042.429251213bdecb6b7a1355c60029957a@haskell.org> Message-ID: <057.4c73c48197d8a8eaf5d5072e5b6589d0@haskell.org> #15715: problematic openFile with named pipes -------------------------------------+------------------------------------- Reporter: adp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect API | (amd64) annotation | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adp): * status: closed => new * failure: Incorrect result at runtime => Incorrect API annotation * resolution: invalid => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 07:59:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 07:59:50 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.ac36b69b0c79a67c6f4ea35deffb029c@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.6.2 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: 15592 Related Tickets: #15076 | Differential Rev(s): Phab:D4769, | Phab:D5141, Phab:D5147, Phab:D5150, Wiki Page: | Phab:D5208 -------------------------------------+------------------------------------- Comment (by tdammers): Looks like Phab:D5141 validates cleanly. Do we still need this part, or does Phab:D5208 supersede this effort? Also, Phab:D5208 fails to build on CI, so that needs looking into, I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 08:20:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 08:20:49 -0000 Subject: [GHC] #15710: Should GHC accept a type signature that needs coercion quantification? In-Reply-To: <046.5bf95bcb5259eed36b1ec15b928de8c8@haskell.org> References: <046.5bf95bcb5259eed36b1ec15b928de8c8@haskell.org> Message-ID: <061.ac552d39040e622a43d96a00e0ac8c73@haskell.org> #15710: Should GHC accept a type signature that needs coercion quantification? -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Tupling: yes `f :: (Num a, Ord a) => blah` is ''already'' syntactic sugar for `f :: Num a => Ord a => blah`. But I'm more concerned about {{{ type C a b = (Num a, a ~ b) }}} and here it'd be much trickier (and unprincipled) to switch to unboxed tuples. Moreover, we do lots of constraint abstraction {{{ data Dict c where Dict :: c => Dict c }}} and we can't instantiate that polymorphic `c` with an unboxed tuple. So yes, I think we could have `Constraint` and `Constraint#` just as we have `Int` and `Int#`. But it's very uncomfortable to have to use `a ~# b` in a type if (but only if) the constraint is used in a dependent way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 08:22:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 08:22:09 -0000 Subject: [GHC] #15710: Should GHC accept a type signature that needs coercion quantification? In-Reply-To: <046.5bf95bcb5259eed36b1ec15b928de8c8@haskell.org> References: <046.5bf95bcb5259eed36b1ec15b928de8c8@haskell.org> Message-ID: <061.5f096b70302c99abce647b608a20b0b7@haskell.org> #15710: Should GHC accept a type signature that needs coercion quantification? -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Consider > {{{ > f :: forall k (f :: k) (x :: k1). (k ~ (k1 -> *)) => f x > f = error "uk" > }}} > Should we accept it? Now that we have coercion quantification (Trac > #15497), I think the answer should be yes, with the elaborated signature > being > {{{ > f :: forall k (f::k) (x::k1). forall (co :: k ~# (k1->*)). (f |> co) x > }}} > But there is a problem: the user wrote `k ~ (k1 -> *)`, and that's a > boxed value that we can't take apart in types. I'm not sure what to do > here. New description: Consider {{{ f :: forall k (f :: k) (x :: k1). (k ~ (k1 -> *)) => f x f = error "uk" }}} Should we accept it? Now that we have coercion quantification (Trac #15497), I think the answer should be yes, with the elaborated signature being {{{ f :: forall k (f::k) (x::k1). forall (co :: k ~# (k1->*)). (f |> co) x }}} But there is a problem: the user wrote `k ~ (k1 -> *)`, and that's a boxed value that we can't take apart in types. I'm not sure what to do here. These thoughts arose when contemplating `Note [Emitting the residual implication in simplifyInfer]` in `TcSimplify`; see comment:5 in #15497 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 09:07:23 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 09:07:23 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.6189321e00cb6f4a59bb0320b06cab62@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.6.2 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: 15592 Related Tickets: #15076 | Differential Rev(s): Phab:D4769, | Phab:D5141, Phab:D5147, Phab:D5150, Wiki Page: | Phab:D5208 -------------------------------------+------------------------------------- Comment (by simonpj): > Looks like ​Phab:D5141 validates cleanly. Do we still need this part, or does ​Phab:D5208 supersede this effort? No, it doesn't supersede. Let's just get D5141 committed. It does Step 1. Then we can at last forget about Step 1. In fact, let's do Step 2 too. All we need to do there is to deal with the `closeOverKinds` change, using the clever trick in comment:123. '''But NB: you need the same trick for `ty_co_vars_of_co_var`. I think Step 2 should work cleanly, and probably improves performance. Tobias can you do that? That sets the stage for Phab:D5208, where some semantic trickiness is going on. But let's get the easy stuff done, nailed, committed, and forgotten! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 09:13:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 09:13:00 -0000 Subject: [GHC] #14854: The size of FastString table is suboptimal for large codebases In-Reply-To: <046.96a71a8566a954e21839a1a60572305e@haskell.org> References: <046.96a71a8566a954e21839a1a60572305e@haskell.org> Message-ID: <061.e1f2e9a771b0c1f347dfab00f9660ff0@haskell.org> #14854: The size of FastString table is suboptimal for large codebases -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5211 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): What's the actual status on this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 09:14:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 09:14:43 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.043774d9c4f447268929c6a6611cded2@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by simonpj): I'm confused. You report a set-fault in comment:55; but now you say it's ready for review. How did you fix it? What is the new design? It's hard to review the patch without understanding the thinking. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 09:20:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 09:20:13 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.28a874800bc715d6650823ba8c47895d@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): Sorry it's a bit hard to follow -- I asked Simon Marlow about the segfault, and he correctly guessed that the problem is that primops are assumed to be non-allocating and I have to update `StgCmmExpr.isSimpleOp`. This change is included in the diff and it fixes the segfault. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 10:12:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 10:12:33 -0000 Subject: [GHC] #15721: Command `:show bindings` throws exception for bindings without `let` In-Reply-To: <049.4a313483322b4bef10e6d1a3d81913cd@haskell.org> References: <049.4a313483322b4bef10e6d1a3d81913cd@haskell.org> Message-ID: <064.ef24f938237e40fa4e51da32085a84ad@haskell.org> #15721: Command `:show bindings` throws exception for bindings without `let` -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.6.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => newcomer Comment: I can't reproduce this on linux so it seems like a windows problem. Two other strange things about `x = a` {{{ let x = 'a' x = 'a' }}} doesn't warn about name shadowing. If you inspect the heap representation of the two versions of `x` they are also different. The latter is a thunk whilst the former is just the character. Making `x = a` behave exactly like `let x = a` will probably fix this ticket the above two problems as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 12:15:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 12:15:38 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.ab6897ffc289f5cb904ccf1a51903385@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): * Yes, I think we should take the arity and CAFness from the STG code, not ''just after we generate it'', but rather ''just before we code-gen it'' , which is the moment of truth. * Rather than use the `IfaceIdInfo` for these two fields, I think we could make them two fixed fields of each top-level Id binding in a `ModIface`. Every Id has CAF-ness and arity. * The final arity is really the ''representation'' arity, after unarisation of unboxed tuples etc. I think we should probably treat that as a separate matter to the "arity" recorded by the Simplifier. The latter really can be passed on by CoreTidy, exactly as now. The former determines calling convention etc; it's a code-gen thing. We currently fudge this issue: see `idRepArity`. * Fingerprints will indeed change; but they are in any case calculated separately; see `addFingerprints`. So we probably want to defer that step too. * For now, I'd be inclined to simply hold onto the partly-complete `ModIface` until codegen; then add info from the just-before-codegen STG code; and construct a final `ModIface`. If that gives rise to residency issues we can decide what to do then. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 12:26:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 12:26:09 -0000 Subject: [GHC] #15155: How untagged pointers sneak into banged fields In-Reply-To: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> References: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> Message-ID: <063.daa3cf7514cc95dd8b4a0530d673926e@haskell.org> #15155: How untagged pointers sneak into banged fields -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14677 Related Tickets: #13027 #7308 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Wow. I think we have discovered that it'll be really hard to ensure that a banged data constructor field always contains a correctly-tagged pointer to an evaluated object. See https://ghc.haskell.org/trac/ghc/ticket/15696#comment:36 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 12:27:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 12:27:36 -0000 Subject: [GHC] #15155: How untagged pointers sneak into banged fields In-Reply-To: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> References: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> Message-ID: <063.e1179e249faed5339542b817c42eddef@haskell.org> #15155: How untagged pointers sneak into banged fields -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14677 Related Tickets: #13027 #7308 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): heisenbug: are you still interested in this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 12:45:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 12:45:55 -0000 Subject: [GHC] #15155: How untagged pointers sneak into banged fields In-Reply-To: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> References: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> Message-ID: <063.9b5d5d65062ce9f686e76eafa59d32c6@haskell.org> #15155: How untagged pointers sneak into banged fields -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14677 Related Tickets: #13027 #7308 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:12 simonpj]: > heisenbug: are you still interested in this ticket? Yes, I am totally interested that it doesn't get killed :-) Feel free to close as fixed-by, though. I ''think'' I have a plan to enforce following invariant: - An IND_STATIC closure should never point to a tagged constructor. For this one needs to track which local (module) names point to some other module's exported name, peeking through casts (i.e. representational equalities). This needs to go into a knot tying state in the backend (or perhaps STG) codegens. Should be mostly mechanical. Then the local references should statically dereference the local name and emit the other module's imported binding. Reading the assembly will be slightly harder, as some names will reflect the representational equalities explicitly. I am not sure that the above invariant is enough, considering the presence of BLACKHOLEs etc. But my gut feeling is that such evaluation-predicated closure kinds should never arise pointing to statically evaluated data. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 12:48:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 12:48:17 -0000 Subject: [GHC] #15720: Assign to literals is allowed in ghci In-Reply-To: <049.0b7514ea0558703d157a538647579f02@haskell.org> References: <049.0b7514ea0558703d157a538647579f02@haskell.org> Message-ID: <064.3fb55ac98099c7632d8d2e5b9d7207f5@haskell.org> #15720: Assign to literals is allowed in ghci -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:2 sighingnow]: > Should we enable `-Wunused-pattern-binds` by default ? It's enabled by `-Wall`: {{{ $ ghci -Wall GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci λ> 1 = 2 :1:1: warning: [-Wtype-defaults] • Defaulting the following constraints to type ‘Integer’ (Eq a0) arising from the literal ‘1’ at :1:1 (Num a0) arising from the literal ‘1’ at :1:1 • In the pattern: 1 In a pattern binding: 1 = 2 :1:1: warning: [-Wunused-pattern-binds] This pattern-binding binds no variables: 1 = 2 }}} I'd be hesitant to enable `-Wunused-pattern-binds` by default without a clear community consensus for it (perhaps in the form of a GHC proposal). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 12:52:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 12:52:18 -0000 Subject: [GHC] #15722: Add -Wstar-is-type to the User's Guide Message-ID: <048.b0249a61ab8434cdd74d3b60e9731ff9@haskell.org> #15722: Add -Wstar-is-type to the User's Guide -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.6.2 Component: Documentation | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D5203 | Wiki Page: -------------------------------------+------------------------------------- Documentation for `-Wstar-is-type` is missing in the 8.6.1 release. Creating this ticket with a milestone as a reminder to cherry-pick the patch to 8.6.2 (right now it's merged to `master`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 12:54:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 12:54:03 -0000 Subject: [GHC] #15722: Add -Wstar-is-type to the User's Guide In-Reply-To: <048.b0249a61ab8434cdd74d3b60e9731ff9@haskell.org> References: <048.b0249a61ab8434cdd74d3b60e9731ff9@haskell.org> Message-ID: <063.ec6d0c79c5e6627a00bc9d1c15593283@haskell.org> #15722: Add -Wstar-is-type to the User's Guide -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: merge Priority: normal | Milestone: 8.6.2 Component: Documentation | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5203 Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 12:59:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 12:59:21 -0000 Subject: [GHC] #14152: Float exit paths out of recursive functions In-Reply-To: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> References: <046.dc062d85b02b871348583b82e3b8d72a@haskell.org> Message-ID: <061.b40b582b8cb08dde2c8a665cb01a060a@haskell.org> #14152: Float exit paths out of recursive functions -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14137 #10918 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: patch => closed * resolution: => fixed Comment: Joachim and I think we are all done here... closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 13:25:53 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 13:25:53 -0000 Subject: [GHC] #15716: GHC hangs on default implementation of type family In-Reply-To: <047.d351f8fcf1aa5d446b36a2139459c9d3@haskell.org> References: <047.d351f8fcf1aa5d446b36a2139459c9d3@haskell.org> Message-ID: <062.4774e7266a53718982326d11c8091fe1@haskell.org> #15716: GHC hangs on default implementation of type family -------------------------------------+------------------------------------- Reporter: Heimdell | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.4.1 Component: Compiler | Version: 8.4.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #13601 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #13601 * milestone: => 8.4.1 Comment: Indeed, this was fixed in commit c2417b87ff59c92fbfa8eceeff2a0d6152b11a47 (Fix #13819 by refactoring TypeEqOrigin.uo_thing), which debuted in GHC 8.4. The `T13601` test case from #13601 demonstrates a very similar program which used to loop at compile-time before this commit, so I'll close this bug as a duplicate of #13601. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 13:45:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 13:45:09 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.d11265a220be21170691e4f5f03d8661@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): Sebastian, how is this going? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 13:48:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 13:48:35 -0000 Subject: [GHC] #15723: -prof -fPIC -fexternal-dynamic-refs generates non-PIC relocations for external symbol Message-ID: <046.1c3e8598c6f9064f6c1ee4be47cb671b@haskell.org> #15723: -prof -fPIC -fexternal-dynamic-refs generates non-PIC relocations for external symbol -------------------------------------+------------------------------------- Reporter: watashi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 (CodeGen) | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: None/Unknown (amd64) | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When compiling code with `-prof -fPIC -fexternal-dynamic-refs`, the generated object file may contains R_X86_64_PC32 relocation to symbols defined in another object file. will add more details -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 13:54:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 13:54:22 -0000 Subject: [GHC] #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` In-Reply-To: <046.74175c624c857c997e111eade5eabf30@haskell.org> References: <046.74175c624c857c997e111eade5eabf30@haskell.org> Message-ID: <061.d70fc4f99dbdb682c00a0019e27b5f35@haskell.org> #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` -------------------------------------+------------------------------------- Reporter: rockbmb | Owner: rockbmb Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: base, | Data.Fixed Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rockbmb): Replying to [comment:14 Ashley Yakeley]: > 1. As written, the proposed change eliminates non-base-10 Fixed. Are we sure we want to do that? > > 2. If we're considering breaking changes to Data.Fixed, the more urgent need (imo) is to generalise the representation type, which is currently hard-coded as Integer. > > Touching both points, [https://en.wikipedia.org/wiki/Q_(number_format) Q formats] are fixed-point with a given number of fractional lower bits. It would be useful to be able to represent these. I do not understand the point you make in 1., could you please elaborate? Regarding 2., I understand and agree. Would replacing a hardcoded `Integer` with `Integral a => ...` be sufficient? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 14:39:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 14:39:47 -0000 Subject: [GHC] #15723: -prof -fPIC -fexternal-dynamic-refs generates non-PIC relocations for external symbol In-Reply-To: <046.1c3e8598c6f9064f6c1ee4be47cb671b@haskell.org> References: <046.1c3e8598c6f9064f6c1ee4be47cb671b@haskell.org> Message-ID: <061.65f46eb360c5beb52d65fcf0256674d8@haskell.org> #15723: -prof -fPIC -fexternal-dynamic-refs generates non-PIC relocations for external symbol -------------------------------------+------------------------------------- Reporter: watashi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 (CodeGen) | 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 watashi): * cc: simonmar (added) Old description: > When compiling code with `-prof -fPIC -fexternal-dynamic-refs`, the > generated object file may contains R_X86_64_PC32 relocation to symbols > defined in another object file. > > will add more details New description: When compiling code with `-prof -fPIC -fexternal-dynamic-refs`, the generated object file may contains R_X86_64_PC32 relocation to symbols defined in another object file. {{{ $ cat T15723A.hs T15723B.hs module T15723A where {-# INLINE foo #-} foo :: Int -> Int foo x = {-# SCC foo1 #-} bar x {-# NOINLINE bar #-} bar :: Int -> Int bar x = x module T15723B where import T15723A test :: Int -> Int test x = {-# SCC test1 #-} foo $ foo x $ $HC -prof -prof -fPIC -fexternal-dynamic-refs -O2 -c T15723A.hs $ $HC -prof -prof -fPIC -fexternal-dynamic-refs -O2 -c T15723B.hs $ objdump -rdS T15723B.o | less 0000000000000028 : 28: 48 8d 45 f0 lea -0x10(%rbp),%rax 2c: 4c 39 f8 cmp %r15,%rax 2f: 72 70 jb a1 31: 48 83 ec 08 sub $0x8,%rsp 35: 48 8d 35 00 00 00 00 lea 0x0(%rip),%rsi # 3c 38: R_X86_64_PC32 T15723B_test1_EXPR_cc-0x4 3c: 49 8b bd 60 03 00 00 mov 0x360(%r13),%rdi 43: 31 c0 xor %eax,%eax 45: e8 00 00 00 00 callq 4a 46: R_X86_64_PLT32 pushCostCentre-0x4 4a: 48 83 c4 08 add $0x8,%rsp 4e: 48 ff 40 30 incq 0x30(%rax) 52: 49 89 85 60 03 00 00 mov %rax,0x360(%r13) 59: 48 83 ec 08 sub $0x8,%rsp 5d: 48 8d 35 00 00 00 00 lea 0x0(%rip),%rsi # 64 60: R_X86_64_PC32 T15723A_foo1_EXPR_cc-0x4 }}} When attempt to link both `T15723A.o` and `T15723B.o` in ghci using `+RTS -xp`, the address of `T15723A_foo1_EXPR_cc` can be more than 2G away from `T15723B_test_info` and cause link error or segfault. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 14:49:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 14:49:06 -0000 Subject: [GHC] #15721: Command `:show bindings` throws exception for bindings without `let` In-Reply-To: <049.4a313483322b4bef10e6d1a3d81913cd@haskell.org> References: <049.4a313483322b4bef10e6d1a3d81913cd@haskell.org> Message-ID: <064.14b0f2a149873942c7d84d4aba26054e@haskell.org> #15721: Command `:show bindings` throws exception for bindings without `let` -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.6.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): Can't reproduce this on windows either. Tried 8.6.1 and master: {{{ PS C:\Users\Andi> stack ghci --compiler=ghc-8.6 ... Configuring GHCi with the following packages: GHCi, version 8.6.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from C:\Users\Andi\AppData\Local\Temp\haskell- stack-ghci\2a3bbd58\ghci-script Prelude> x = 'a' Prelude> :show bindings $trModule :: GHC.Types.Module = _ x :: Char = _ Prelude> }}} What OS have you been using? And what commit on master? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 14:55:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 14:55:22 -0000 Subject: [GHC] #15723: -prof -fPIC -fexternal-dynamic-refs generates non-PIC relocations for external symbol In-Reply-To: <046.1c3e8598c6f9064f6c1ee4be47cb671b@haskell.org> References: <046.1c3e8598c6f9064f6c1ee4be47cb671b@haskell.org> Message-ID: <061.fb42b268b019fb4714b434738a3c56eb@haskell.org> #15723: -prof -fPIC -fexternal-dynamic-refs generates non-PIC relocations for external symbol -------------------------------------+------------------------------------- Reporter: watashi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 (CodeGen) | 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:D5214 Wiki Page: | -------------------------------------+------------------------------------- Changes (by watashi): * differential: => Phab:D5214 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 15:05:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 15:05:50 -0000 Subject: [GHC] #15497: Coercion Quantification In-Reply-To: <047.3a4a4e067b87a899efdf8c3f044fd1ac@haskell.org> References: <047.3a4a4e067b87a899efdf8c3f044fd1ac@haskell.org> Message-ID: <062.5b739f238e6ccd571eb8149b7bafd2fe@haskell.org> #15497: Coercion Quantification -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5054 Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase2| -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: comment:5 really seems to be asking for #15710. Closing this ticket in favor of that one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 15:06:29 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 15:06:29 -0000 Subject: [GHC] #15710: Should GHC accept a type signature that needs coercion quantification? In-Reply-To: <046.5bf95bcb5259eed36b1ec15b928de8c8@haskell.org> References: <046.5bf95bcb5259eed36b1ec15b928de8c8@haskell.org> Message-ID: <061.02af165d7d313209d1bbb966479b0af7@haskell.org> #15710: Should GHC accept a type signature that needs coercion quantification? -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): When we get this, we can remove `Note [Emitting the residual implication in simplifyInfer]` in TcSimplify. See comment:5:ticket:15497. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 15:15:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 15:15:20 -0000 Subject: [GHC] #15724: GHC panic with malformed pragma Message-ID: <050.3cfe937f9b4b63c76d9bae67899495b5@haskell.org> #15724: GHC panic with malformed pragma -------------------------------------+------------------------------------- Reporter: etorreborre | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This comment crashes GHC (the comment is not properly closed) {{{#!hs {-# OPTIONS_GHC -f-nowarn-orphans #} }}} {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-apple-darwin): getOptions'.parseToks: Couldn't read " \"|\")) <> rand_bytes\n pure $ (==) hashed rehashed\n final = either (FailedToParse . show) (bool InValid Valid) result\n\n{-# ANN StateNamePrefix (Just (\"Test\" :: Text)) " as String }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 15:15:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 15:15:45 -0000 Subject: [GHC] #15724: GHC panic with malformed pragma In-Reply-To: <050.3cfe937f9b4b63c76d9bae67899495b5@haskell.org> References: <050.3cfe937f9b4b63c76d9bae67899495b5@haskell.org> Message-ID: <065.97deefcad34dd34a087785669916c102@haskell.org> #15724: GHC panic with malformed pragma -------------------------------------+------------------------------------- Reporter: etorreborre | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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 etorreborre: Old description: > This comment crashes GHC (the comment is not properly closed) > {{{#!hs > {-# OPTIONS_GHC -f-nowarn-orphans #} > }}} > {{{ > ghc: panic! (the 'impossible' happened) > (GHC version 8.4.3 for x86_64-apple-darwin): > getOptions'.parseToks: Couldn't read " \"|\")) <> rand_bytes\n > pure $ (==) hashed rehashed\n final = either (FailedToParse . show) > (bool InValid Valid) result\n\n{-# ANN StateNamePrefix (Just (\"Test\" :: > Text)) " as String > > }}} New description: This comment crashes GHC (the comment is not properly closed) {{{#!hs {-# OPTIONS_GHC -f-no-warn-orphans #} }}} {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-apple-darwin): getOptions'.parseToks: Couldn't read " \"|\")) <> rand_bytes\n pure $ (==) hashed rehashed\n final = either (FailedToParse . show) (bool InValid Valid) result\n\n{-# ANN StateNamePrefix (Just (\"Test\" :: Text)) " as String }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 15:30:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 15:30:45 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.0b9f0399685a7bfc7ece4dd4184ff0db@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): You can find the latest version of the paper at https://github.com/sgraf812/late-lam-lift/blob/master/paper.pdf. It's still pretty rough and littered with TODOs, but you can take a glance at the two chapters I got so far. What's missing is an evaluation + the usual prologue and epilogue. While writing the paper, I realised a few things here and there that I could change in the transformation. For example, currently we can't lift functions that occur in argument position, i.e. {{{ let f x = ... x ... a ... b ... in let g y z = ... in g f 1 }}} Lifting `f` would mean having to allocate a PAP at the call site of `g` for `f a b`. One of our heuristics forbids the lift here, because it's nonsense: We immediately re-introduce the allocation we spared at each call site of the lifted function. The only situation I can think of in which this could be beneficial is when this pushes allocation from a hot code path into multiple cold call sites. Making the transformation correct here is somewhat of a nuisance, but probably needed in order to back my claims in section 3 (C1, in particular) with benchmark figures. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 15:39:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 15:39:59 -0000 Subject: [GHC] #15720: Assign to literals is allowed in ghci In-Reply-To: <049.0b7514ea0558703d157a538647579f02@haskell.org> References: <049.0b7514ea0558703d157a538647579f02@haskell.org> Message-ID: <064.9ce1ca53f16c58ca8094b42348e5a54b@haskell.org> #15720: Assign to literals is allowed in ghci -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I had thought that `-Wunused-pattern-binds` did more than just this corner case... looking at it now ([https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/using- warnings.html#ghc-flag--Wunused-pattern-binds manual entry]), I do think we should enable this by default. I suppose a proposal is in order, but that's annoyingly heavy. Oh well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 15:51:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 15:51:12 -0000 Subject: [GHC] #15721: Command `:show bindings` throws exception for bindings without `let` In-Reply-To: <049.4a313483322b4bef10e6d1a3d81913cd@haskell.org> References: <049.4a313483322b4bef10e6d1a3d81913cd@haskell.org> Message-ID: <064.b48586ab21400b3fc398f01fad65141f@haskell.org> #15721: Command `:show bindings` throws exception for bindings without `let` -------------------------------------+------------------------------------- Reporter: sighingnow | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: Component: GHCi | Version: 8.6.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sighingnow): * status: new => infoneeded Comment: I can reproduce the problem with ghc-8.2.2/8.6.1/head on Windows 10 (10.0.17134.286), but this problem doesn't appear on another laptop also with Windows 10. I will try to post more detailed information tomorrow. Anyway, I have marked this ticket as infoneeded. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 15:51:30 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 15:51:30 -0000 Subject: [GHC] #15724: GHC panic with malformed pragma In-Reply-To: <050.3cfe937f9b4b63c76d9bae67899495b5@haskell.org> References: <050.3cfe937f9b4b63c76d9bae67899495b5@haskell.org> Message-ID: <065.72679c928c5728facdbb87988f783ca2@haskell.org> #15724: GHC panic with malformed pragma -------------------------------------+------------------------------------- Reporter: etorreborre | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 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: #15053 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #15053 Comment: This has been fixed upstream in #15053, and will hopefully debut in GHC 8.6.2. Thanks for the bug report! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 16:05:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 16:05:57 -0000 Subject: [GHC] #15497: Coercion Quantification In-Reply-To: <047.3a4a4e067b87a899efdf8c3f044fd1ac@haskell.org> References: <047.3a4a4e067b87a899efdf8c3f044fd1ac@haskell.org> Message-ID: <062.83d8242e81fb0ac9baec35c360b831ea@haskell.org> #15497: Coercion Quantification -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5054 Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase2| -------------------------------------+------------------------------------- Comment (by simonpj): On coercion quantification, I think it would be helpful to update [wiki:DependentHaskell/Phase2] * Under "Why homogeneous equality is good" explain how homogeneous equality can help the simplifier (in `exprIsConApp_maybe`). * On the same page, under "A small wrinkle: we need coercion quantification back", remove or rephrase the stuff about `(~~)`; perhaps use the ''data type'' `:~~:` rather than the ''class'' `(~~)`. * Promote "Another approach" for the class `(~~)` which appears lower down. It may be another approach but it is Our Plan for solving a Real Problem in introducing homogeneous equality at the moment, and as time goes on it is really helpful to know what The Plan is, with other approaches being discussed later. TL;DR: make the page reflect our current thinking as directly as possible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 16:11:57 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 16:11:57 -0000 Subject: [GHC] #15497: Coercion Quantification In-Reply-To: <047.3a4a4e067b87a899efdf8c3f044fd1ac@haskell.org> References: <047.3a4a4e067b87a899efdf8c3f044fd1ac@haskell.org> Message-ID: <062.37f905cc6903bd04ff0a5cd4d47a0447@haskell.org> #15497: Coercion Quantification -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5054 Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase2| -------------------------------------+------------------------------------- Comment (by simonpj): One other thing. As I said in our call today, it's striking how narrow are the use-cases for a coercion-quantified type: * We can't ''declare'' a function with type `f :: (t1 ~# t2) => blah`, because currently `(t1 ~# t2)` is not a constraint (see Trac #15648) and is never implicitly instantiated. * We can't ''infer'' a function with type `f :: (t1 ~# t2) => blah`. And if we did, it wouldn't be instantiated implicitly. And so ''a fortiori'' we can't have coercion-quantified variants of such types. '''So the ''only'' functions that can have these coercion-quantified types are the workers of data constructors'''. Am I right? If so, can we say so explicitly on the wiki page? That seems like a lot of work for a narrow use-case! And yet, and yet... it's a very important case. Note also that we cannot write an exactly-equivalent type signature with GADT-syntax, because we don't have source-syntax of `t1 ~# t2`, let alone for `forall (co:t1~#t2). blah`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 16:17:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 16:17:05 -0000 Subject: [GHC] #15703: Significant compilation time blowup when refactoring singletons-heavy code In-Reply-To: <050.85b00ed8f7678528686f0902895081dc@haskell.org> References: <050.85b00ed8f7678528686f0902895081dc@haskell.org> Message-ID: <065.c065bc4a2150411067c75efabe47fb4c@haskell.org> #15703: Significant compilation time blowup when refactoring singletons-heavy code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "dshow-passes.txt" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 16:21:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 16:21:18 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.9093c5d5b8ab15834f42d4305fb88094@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): Good stuff on the paper. I'll try to look. > For example, currently we can't lift functions that occur in argument position, i.e. That seems correct doesn't it? i.e. the implementation doesn't lift such functions, and it shouldn't. So why do you say "I realised a few things here and there that I could change in the transformation"? What about the implementation. Are you done? Ready to submit a Phab patch for review? With an up-to-date wiki page describing what it does? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 16:21:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 16:21:54 -0000 Subject: [GHC] #15703: Significant compilation time blowup when refactoring singletons-heavy code In-Reply-To: <050.85b00ed8f7678528686f0902895081dc@haskell.org> References: <050.85b00ed8f7678528686f0902895081dc@haskell.org> Message-ID: <065.8393c4d1cb2801b7edf63320f9a924db@haskell.org> #15703: Significant compilation time blowup when refactoring singletons-heavy code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I attached the results of compiling `Lib.hs` with `-dshow-passes` enabled. Of particular note is: {{{ Result size of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) = {terms: 950, types: 14,499, coercions: 83,275, joins: 0/12} !!! Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Lib]: finished in 28.01 milliseconds, allocated 19.390 megabytes *** Simplifier [Lib]: Result size of Simplifier iteration=1 = {terms: 924, types: 12,141, coercions: 235,672, joins: 0/46} Result size of Simplifier iteration=2 = {terms: 755, types: 5,948, coercions: 312,927, joins: 0/17} Result size of Simplifier iteration=3 = {terms: 715, types: 3,828, coercions: 403,226, joins: 0/2} Result size of Simplifier = {terms: 703, types: 3,759, coercions: 228,342, joins: 0/2} !!! Simplifier [Lib]: finished in 208488.74 milliseconds, allocated 373891.763 megabytes *** Simplifier [Lib]: Result size of Simplifier = {terms: 703, types: 3,759, coercions: 228,342, joins: 0/2} }}} The number of coercions appears to jump between float-out and the first simplifier pass. However, it's a later simplifier pass that takes up the bulk of the time (208488.74 milliseconds of it). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 16:31:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 16:31:11 -0000 Subject: [GHC] #15703: Significant compilation time blowup when refactoring singletons-heavy code In-Reply-To: <050.85b00ed8f7678528686f0902895081dc@haskell.org> References: <050.85b00ed8f7678528686f0902895081dc@haskell.org> Message-ID: <065.ad2b4f9c4c3024771f61a0ffae1491ef@haskell.org> #15703: Significant compilation time blowup when refactoring singletons-heavy code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): It might be worth checking whether `optCoercion` is helping or hurting: you can check the size of the input to the function and the size of the output. The output shouldn't be bigger than the input! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 17:09:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 17:09:25 -0000 Subject: [GHC] #15497: Coercion Quantification In-Reply-To: <047.3a4a4e067b87a899efdf8c3f044fd1ac@haskell.org> References: <047.3a4a4e067b87a899efdf8c3f044fd1ac@haskell.org> Message-ID: <062.d46a8c20cf0808acd949bb23c2ec1ce8@haskell.org> #15497: Coercion Quantification -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5054 Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase2| -------------------------------------+------------------------------------- Comment (by goldfire): I've done these wiki updates. Thanks for the concrete suggestions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 18:01:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 18:01:06 -0000 Subject: [GHC] #14677: Code generator does not correctly tag a pointer In-Reply-To: <046.7a1d900f9976c54932290e6492402f05@haskell.org> References: <046.7a1d900f9976c54932290e6492402f05@haskell.org> Message-ID: <061.b78d80948bb50a8ceff3fda29ea13ce3@haskell.org> #14677: Code generator does not correctly tag a pointer -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 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: 15155 | Blocking: 14626 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 18:02:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 18:02:36 -0000 Subject: [GHC] #15155: How untagged pointers sneak into banged fields In-Reply-To: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> References: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> Message-ID: <063.371d8aa96d5a7f178f520d9ade768af4@haskell.org> #15155: How untagged pointers sneak into banged fields -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14677 Related Tickets: #13027 #7308 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 18:05:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 18:05:22 -0000 Subject: [GHC] #14626: No need to enter a scrutinised value In-Reply-To: <048.67c951c2aecb97b988badb4816dbe757@haskell.org> References: <048.67c951c2aecb97b988badb4816dbe757@haskell.org> Message-ID: <063.31b75bdf2d2c9ef24fb9183eba7fb255@haskell.org> #14626: No need to enter a scrutinised value -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: performance, | CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14677 | Blocking: Related Tickets: #13861 #14677 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 18:07:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 18:07:32 -0000 Subject: [GHC] #15703: Significant compilation time blowup when refactoring singletons-heavy code In-Reply-To: <050.85b00ed8f7678528686f0902895081dc@haskell.org> References: <050.85b00ed8f7678528686f0902895081dc@haskell.org> Message-ID: <065.cbcde471e580253a3b48751ac833e363@haskell.org> #15703: Significant compilation time blowup when refactoring singletons-heavy code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I added `{-# OPTIONS_GHC -fprof-auto #-}` to the top of `OptCoercion`, which gives me some slightly more fine-grained information: {{{ Mon Oct 8 13:50 2018 Time and Allocation Profiling Report (Final) ghc-stage2 +RTS -p -RTS -B/u/rgscott/Software/ghc3/inplace/lib -O1 -fforce-recomp Lib.hs total time = 282.87 secs (282872 ticks @ 1000 us, 1 processor) total alloc = 403,927,138,248 bytes (excludes profiling overheads) COST CENTRE MODULE SRC %time %alloc matchAxiom OptCoercion compiler/types/OptCoercion.hs:(903,1)-(916,11) 47.3 43.4 substTyWith TyCoRep compiler/types/TyCoRep.hs:(2213,23)-(2214,50) 23.0 22.9 opt_trans_rule OptCoercion compiler/types/OptCoercion.hs:(512,1)-(681,30) 18.4 21.5 etaAppCo_maybe OptCoercion compiler/types/OptCoercion.hs:(985,1)-(996,11) 6.1 9.2 opt_co4 OptCoercion compiler/types/OptCoercion.hs:(174,1)-(386,71) 3.4 2.2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 19:45:08 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 19:45:08 -0000 Subject: [GHC] #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` In-Reply-To: <046.74175c624c857c997e111eade5eabf30@haskell.org> References: <046.74175c624c857c997e111eade5eabf30@haskell.org> Message-ID: <061.87ae3275a5b7edcfcb5bd7515e37943f@haskell.org> #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` -------------------------------------+------------------------------------- Reporter: rockbmb | Owner: rockbmb Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: base, | Data.Fixed Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ashley Yakeley): Never mind, it looks like my first point is not a concern, because you can still create other instances of HasResolution. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 20:06:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 20:06:19 -0000 Subject: [GHC] #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` In-Reply-To: <046.74175c624c857c997e111eade5eabf30@haskell.org> References: <046.74175c624c857c997e111eade5eabf30@haskell.org> Message-ID: <061.b85ae373ebd4817002a8785f45d96d34@haskell.org> #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` -------------------------------------+------------------------------------- Reporter: rockbmb | Owner: rockbmb Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: base, | Data.Fixed Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rockbmb): Replying to [comment:17 Ashley Yakeley]: > Never mind, it looks like my first point is not a concern, because you can still create other instances of HasResolution. > If that is the case, I do not mind addressing your second point in the PR I already made. Regarding Q formats, this sounds like a worthwhile addition, but it should probably be done in a separate PR, with a ticket here to match. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 20:09:05 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 20:09:05 -0000 Subject: [GHC] #12932: -fexternal-interpreter` fails to find symbols In-Reply-To: <046.e268f025fb07ea6927f21c0906b2681d@haskell.org> References: <046.e268f025fb07ea6927f21c0906b2681d@haskell.org> Message-ID: <061.f24240eb72713e5e1e3042987f990eea@haskell.org> #12932: -fexternal-interpreter` fails to find symbols -----------------------------+---------------------------------------- Reporter: dominic | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #12946 | Differential Rev(s): Wiki Page: | -----------------------------+---------------------------------------- Comment (by bgamari): Currently I lack any way to reproduce this. Perhaps someone can offer a reproduction instructions? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 20:24:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 20:24:27 -0000 Subject: [GHC] #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` In-Reply-To: <046.74175c624c857c997e111eade5eabf30@haskell.org> References: <046.74175c624c857c997e111eade5eabf30@haskell.org> Message-ID: <061.c86bbe02f35b7437247b4e6cf34b65e9@haskell.org> #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` -------------------------------------+------------------------------------- Reporter: rockbmb | Owner: rockbmb Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: base, | Data.Fixed Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Bodigrim): Actually, we can generalise the current approach to any base: {{{#!hs data E (n :: Nat) instance KnownNat n => HasResolution (E n) where resolution = natVal . Compose type Milli = E 1000 }}} ------ With regards to the representation type: it does not make much sense to have `Int8` with resolution 1000. And there are only two integer types with arbitrary precision available in `base`. IMHO it is reasonable to stick to `Integer`, not least because it allows to avoid having any visible breaking change at all. ------ > I would also like to see Data.Fixed (and possibly also Data.Ratio and Data.Complex) put in a new core library. I believe it could be desired, if there is a demand for a more rapid development of these modules than for the rest of `base`, but as far as I see this is not the case. Otherwise I do not see any direct benefits of such breaking change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 21:18:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 21:18:15 -0000 Subject: [GHC] #15671: Link errors due to forcibly exporting findPtr In-Reply-To: <044.6372bc7500582c14ea27cfe705ed9ef3@haskell.org> References: <044.6372bc7500582c14ea27cfe705ed9ef3@haskell.org> Message-ID: <059.5c560a5943b434280dcdfaa51e959fde@haskell.org> #15671: Link errors due to forcibly exporting findPtr -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: alpmestan 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: T10955dyn | T10955 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5138 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * owner: (none) => alpmestan Comment: I will implement the proposed solution this week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 21:23:55 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 21:23:55 -0000 Subject: [GHC] #15703: Significant compilation time blowup when refactoring singletons-heavy code In-Reply-To: <050.85b00ed8f7678528686f0902895081dc@haskell.org> References: <050.85b00ed8f7678528686f0902895081dc@haskell.org> Message-ID: <065.b565cd88cf7e4dab17a32cb5eecf2952@haskell.org> #15703: Significant compilation time blowup when refactoring singletons-heavy code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Those are staggeringly large coercions decorating relatively tiny types. I wonder: could any of them be very large representations of `Refl`? I note that `OptCoercion` doesn't use `isReflexiveCo` (which tests for equality of the two types) because doing so at every node would be expensive. But you could try testing for `isReflexiveCo`, and spit out the smallest coercion which says `True` to `isReflexiveCo` but is not actually `Refl`. You'd want to make this test for every sub-tree in the coercion. That's a guess. But it's very hard to imagine that you ''really'' need such large proofs. The trick is to find where the redundancy is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 21:31:14 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 21:31:14 -0000 Subject: [GHC] #15155: How untagged pointers sneak into banged fields In-Reply-To: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> References: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> Message-ID: <063.0d35b0a0864f5fb5586f5d39d5442823@haskell.org> #15155: How untagged pointers sneak into banged fields -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14677 Related Tickets: #13027 #7308 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): But see comment:11. I now think that it's a lost cause to insist that a strict constructor field is always a correctly-tagged pointer to an evaluated data value. In which case the whole IND_STATIC change becomes moot. I think we should work on the other tickets identified in commment:1. Are you interested in pursuing any of them? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 22:02:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 22:02:52 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.95afe8c73075a9b931d9fa62f4072e47@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by simonpj): The `dataToTag#` saga has revealed several things, which I'd like to summarise here. * We have been guilty of mixing up two things: * A ''semantic'' property, namely that an expression, or variable, is guaranteed to be non-bottom. For example, given {{{ data T = MkT !Int f (MkT y) = ...y... }}} in the body of `f`, we know that `y` is non-bottom. * A ''representational'' propery, that a variable is bound to a heap pointer that (a) points directly to an evaluated heap-allocated value (e.g. a cons cell), and (b) is properly tagged, for data constructors with small enough tags. The representational property implies the semantic property, ''but not vice versa''. For example, in the above code, are we guaranteed that `y` (being the strict field of `MkT` is bound to a properly-tagged pointer to an `Int`? I used to think yes, but [https://ghc.haskell.org/trac/ghc/ticket/15696#comment:36 this example] (look at the bullets in that comment) shows that the answer is NO. My conclusion: we should keep the two properties separate. The Simplifier can maintain the first; but the second is much more fragile, and is the business of the code generator alone. * We have never implemented #14626, but it's pretty easy to do so provided we focus our attention on the code generator. The example there is {{{ f x = case x of y Red -> Green DEFAULT -> y }}} The resturn contract of `case` specifies that `y` is bound to a properly-tagged pointer directly to the value; The code generator can remember this fact, in its environment; and simply ''return'' `y` in the DEFAULT branch rather than ''entering'' it. * `exprOkForSpeculation` finishes with this case (in `app_ok`) {{{ _other -> isUnliftedType (idType fun) -- c.f. the Var case of exprIsHNF || idArity fun > n_val_args -- Partial apps || (n_val_args == 0 && isEvaldUnfolding (idUnfolding fun)) -- Let-bound values }}} I think the final disjunct is wrong, becuase it is fragile. Consider {{{ case x of y { DEFAULT -> ...y.... } }}} In that branch, is `y` ok-for-speculation? It looks so, because it has an evald unfolding (`OtherCon`). But the binder-swap transformation performed by FloatOut transforms it to {{{ case x of y { DEFAULT -> ...x.... } }}} and `x` is NOT ok-for-spec. So the binder-swap transformation might invalidate invariants. This is pretty obscure in practice, but I think we can make the compiler simpler and more correct by deleting those two lines. I think it will have zero effect because `exprOkForSpecuation` is seldom if ever called on expressions of lifted type. * Only two primops (currently) evaluate a lifted-type argument: `SeqOp` and `DataToTagOp`. The former has a special case in `app_ok` (in `exprOkForSpeculation` and the latter should too. * Once all this is done, the hack of making `DataToTagOp` have `can_fail=True` can be dispensed with. * We have related loose ends in #14677 and #15155. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 22:06:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 22:06:46 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.c82a166d359a5e038f0da4bb437635ad@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by dfeuer): I believe that `spark#` and `par#` also evaluate lifted-type arguments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 8 22:14:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Oct 2018 22:14:38 -0000 Subject: [GHC] #15671: Link errors due to forcibly exporting findPtr In-Reply-To: <044.6372bc7500582c14ea27cfe705ed9ef3@haskell.org> References: <044.6372bc7500582c14ea27cfe705ed9ef3@haskell.org> Message-ID: <059.a7d844f69ee8846a52a92e2a1ffc9370@haskell.org> #15671: Link errors due to forcibly exporting findPtr -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: alpmestan 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: T10955dyn | T10955 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5138 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): Thanks @alpmestan! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 00:07:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 00:07:14 -0000 Subject: [GHC] #15725: Core Lint error: Trans coercion mis-match Message-ID: <050.b669cdd6d53ebfbfb35ff1834b5bd9f3@haskell.org> #15725: Core Lint error: Trans coercion mis-match -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: #15703 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I discovered this when debugging #15703. The following code fails to compile with `-dcore-lint`: {{{#!hs {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} module Bug where import Data.Functor.Identity (Identity(..)) import Data.Kind (Type) import GHC.Exts (Any) ----- -- The important bits ----- type instance Meth (x :: Identity a) = GenericMeth x instance SC Identity ------------------------------------------------------------------------------- data family Sing :: forall k. k -> Type data instance Sing :: forall a. Identity a -> Type where SIdentity :: Sing x -> Sing ('Identity x) newtype Par1 p = Par1 p data instance Sing :: forall p. Par1 p -> Type where SPar1 :: Sing x -> Sing ('Par1 x) type family Rep1 (f :: Type -> Type) :: Type -> Type class PGeneric1 (f :: Type -> Type) where type From1 (z :: f a) :: Rep1 f a type To1 (z :: Rep1 f a) :: f a class SGeneric1 (f :: Type -> Type) where sFrom1 :: forall (a :: Type) (z :: f a). Sing z -> Sing (From1 z) sTo1 :: forall (a :: Type) (r :: Rep1 f a). Sing r -> Sing (To1 r :: f a) type instance Rep1 Identity = Par1 instance PGeneric1 Identity where type From1 ('Identity x) = 'Par1 x type To1 ('Par1 x) = 'Identity x instance SGeneric1 Identity where sFrom1 (SIdentity x) = SPar1 x sTo1 (SPar1 x) = SIdentity x type family GenericMeth (x :: f a) :: f a where GenericMeth x = To1 (Meth (From1 x)) type family Meth (x :: f a) :: f a class SC f where sMeth :: forall a (x :: f a). Sing x -> Sing (Meth x) default sMeth :: forall a (x :: f a). ( SGeneric1 f, SC (Rep1 f) , Meth x ~ GenericMeth x ) => Sing x -> Sing (Meth x) sMeth sx = sTo1 (sMeth (sFrom1 sx)) dummy :: f a -> () dummy _ = () type instance Meth (x :: Par1 p) = x instance SC Par1 where sMeth x = x }}} {{{ $ /opt/ghc/8.6.1/bin/ghc -fforce-recomp Bug.hs -dcore-lint [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) *** Core Lint errors : in result of Simplifier *** : warning: [in body of letrec with binders x_s1Nw :: Sing (From1 x_a1Jc)] Trans coercion mis-match: D:R:Rep1Identity[0] _N ; Sym (Sym (D:R:Rep1Identity[0]) _N) Rep1 Identity a_a1Jb Par1 a_a1Jb Rep1 Identity a_a1Jb Par1 a_a1Jb *** Offending Program *** $csMeth_a1J9 [Occ=LoopBreaker] :: forall a (x :: Identity a). Sing x -> Sing (Meth x) [LclId, Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False, WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 100 60}] $csMeth_a1J9 = \ (@ a_a1Jb) (@ (x_a1Jc :: Identity a_a1Jb)) -> case heq_sel @ (Identity a_a1Jb) @ (Identity a_a1Jb) @ (Meth x_a1Jc) @ (GenericMeth x_a1Jc) (($d~_s1Nz @ a_a1Jb @ x_a1Jc) `cast` (((~) _N ((To1 _N _N (Coh (Sym (D:R:MethTYPEPar1px[0] _N (Coh (Sym (Coh _N (D:R:Rep1Identity[0] _N))) (D:R:Rep1Identity[0] _N)))) (Sym (D:R:Rep1Identity[0]) _N) ; (Meth <*>_N (Sym (D:R:Rep1Identity[0])) _N (Coh _N (D:R:Rep1Identity[0] _N)))_N))_N ; (Sym (D:R:GenericMeth[0] _N _N _N) ; Sym (D:R:MethTYPEIdentityax[0] _N _N))) ((To1 _N _N (Coh (Sym (Coh (Sym (Coh _N (D:R:Rep1Identity[0] _N))) (D:R:Rep1Identity[0] _N))) (Sym (D:R:Rep1Identity[0]) _N) ; (Sym (D:R:MethTYPEPar1px[0] _N (Coh (Sym (Coh _N (D:R:Rep1Identity[0] _N))) (D:R:Rep1Identity[0] _N))) ; (Meth <*>_N (Sym (D:R:Rep1Identity[0])) _N (Coh _N (D:R:Rep1Identity[0] _N)))_N)))_N ; Sym (D:R:GenericMeth[0] _N _N _N)))_R ; N:~[0] _N _N _N :: (To1 (From1 x_a1Jc) ~ To1 (From1 x_a1Jc)) ~R# (Meth x_a1Jc ~~ GenericMeth x_a1Jc))) of co_a1Kd { __DEFAULT -> (\ (sx_aEZ :: Sing x_a1Jc) -> let { x_s1Nw :: Sing (From1 x_a1Jc) [LclId] x_s1Nw = $csFrom1_a1Jz @ a_a1Jb @ x_a1Jc sx_aEZ } in case x_s1Nw `cast` ((Sing (D:R:Rep1Identity[0] _N) (Coh (Sym (Coh _N (D:R:Rep1Identity[0] _N ; Sym (Sym (D:R:Rep1Identity[0]) _N)))) (Sym (D:R:Rep1Identity[0]) _N)))_R ; (Nth:3 (Inst (forall (x :: Sym (D:R:Rep1Identity[0]) _N). (Sing (Sym (D:R:Rep1Identity[0]) _N) (Sym (Coh _N (Sym (D:R:Rep1Identity[0]) _N))))_R ->_R (Sing (Sym (D:R:Rep1Identity[0]) _N) (Sym (D:R:MethTYPEPar1px[0] _N _N) ; (Meth <*>_N (Sym (D:R:Rep1Identity[0])) _N (Sym (Coh _N (Sym (D:R:Rep1Identity[0]) _N))))_N))_R) (Coh _N (Sym (Sym (D:R:Rep1Identity[0]) _N)))) ; ((Sing (D:R:Rep1Identity[0] _N))_R ; D:R:SingPar10[0] _N) (Sym (Coh _N (D:R:Rep1Identity[0] _N)))) :: Sing (From1 x_a1Jc |> Sym (D:R:Rep1Identity[0]) _N) ~R# R:SingPar1 a_a1Jb (Meth (From1 x_a1Jc) |> D:R:Rep1Identity[0] _N)) of { SPar1 @ x_a1JZ co_a1K0 x_a195 -> ($WSIdentity @ a_a1Jb @ x_a1JZ x_a195) `cast` ((Sing _N (Sym (D:R:To1IdentityaPar1[0] _N _N) ; (To1 _N _N (Sym (Coh (Sym (Coh <'Par1 x_a1JZ>_N (Sym (D:R:Rep1Identity[0]) _N))) (Sym (D:R:Rep1Identity[0]) _N)) ; (Coh <'Par1 x_a1JZ>_N (Sym (D:R:Rep1Identity[0]) _N) ; (Sym co_a1K0 ; Coh _N (D:R:Rep1Identity[0] _N)))))_N))_R :: Sing ('Identity x_a1JZ) ~R# Sing (To1 (Meth (From1 x_a1Jc)))) }) `cast` (_R ->_R (Sing _N (Sym (D:R:GenericMeth[0] _N _N _N) ; Sym co_a1Kd))_R :: (Sing x_a1Jc -> Sing (To1 (Meth (From1 x_a1Jc)))) ~R# (Sing x_a1Jc -> Sing (Meth x_a1Jc))) } end Rec } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 00:08:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 00:08:12 -0000 Subject: [GHC] #15703: Significant compilation time blowup when refactoring singletons-heavy code In-Reply-To: <050.85b00ed8f7678528686f0902895081dc@haskell.org> References: <050.85b00ed8f7678528686f0902895081dc@haskell.org> Message-ID: <065.6f16b8ef653635a7987f0fa6a58362ad@haskell.org> #15703: Significant compilation time blowup when refactoring singletons-heavy code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #15725 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15725 Comment: I don't know if this is related to the performance issue witnessed here, but it turns out that `Lib.hs` compiles cleanly with `-dcore-lint -O0`, but crashes with `-dcore-lint -O1`. I've opened #15725 for this. (Interestingly, in the more minimal example I provide in #15725, the Core Lint error happens regardless of optimization level.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 00:19:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 00:19:02 -0000 Subject: [GHC] #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` In-Reply-To: <046.74175c624c857c997e111eade5eabf30@haskell.org> References: <046.74175c624c857c997e111eade5eabf30@haskell.org> Message-ID: <061.484b998e03d62011643b99c3b97c5e32@haskell.org> #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` -------------------------------------+------------------------------------- Reporter: rockbmb | Owner: rockbmb Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: base, | Data.Fixed Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rockbmb): Replying to [comment:19 Bodigrim]: > Actually, we can generalise the current approach to any base: > {{{#!hs > data E (n :: Nat) > > instance KnownNat n => HasResolution (E n) where > resolution = natVal . Compose > > type Milli = E 1000 > }}} How would the `Compose` help with numeric bases here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 02:06:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 02:06:23 -0000 Subject: [GHC] #15725: Core Lint error: Trans coercion mis-match In-Reply-To: <050.b669cdd6d53ebfbfb35ff1834b5bd9f3@haskell.org> References: <050.b669cdd6d53ebfbfb35ff1834b5bd9f3@haskell.org> Message-ID: <065.d7f85ef712ebe5f5c9be857faf2d6c9f@haskell.org> #15725: Core Lint error: Trans coercion mis-match -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15703 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It appears that `simplCoercion` is the thing that's producing this ill- formed coercion. Here is the input coercion: {{{ Sym (Nth:2 (Inst (forall (x1 :: Sym (Bug.D:R:Rep1Identity[0]) _N). (Bug.Sing (Sym (Bug.D:R:Rep1Identity[0]) _N) (GRefl nominal x1 (Sym (Bug.D:R:Rep1Identity[0]) _N)))_R ->_R (Bug.Sing (Sym (Bug.D:R:Rep1Identity[0]) _N) (Sym (Bug.D:R:MethTYPEPar1px[0] _N _N) ; (Bug.Meth <*>_N (Sym (Bug.D:R:Rep1Identity[0])) _N (GRefl nominal x1 (Sym (Bug.D:R:Rep1Identity[0]) _N)))_N))_R) (Sym (GRefl nominal (Bug.From1 x) (Sym (Sym (Bug.D:R:Rep1Identity[0]) _N)))))) }}} And here is the output coercion: {{{ Nth:2 ((Bug.Sing (Bug.D:R:Rep1Identity[0] _N) (Sym (GRefl nominal (Bug.From1 x) ((Bug.D:R:Rep1Identity[0] _N ; Sym (Sym (Bug.D:R:Rep1Identity[0]) _N)) ; Sym (Bug.D:R:Rep1Identity[0]) _N))))_R ->_R (Bug.Sing (Bug.D:R:Rep1Identity[0] _N) ((Bug.Meth <*>_N (Bug.D:R:Rep1Identity[0]) _N (Sym (GRefl nominal (Bug.From1 x) ((Bug.D:R:Rep1Identity[0] _N ; Sym (Sym (Bug.D:R:Rep1Identity[0]) _N)) ; Sym (Bug.D:R:Rep1Identity[0]) _N))))_N ; Bug.D:R:MethTYPEPar1px[0] _N (GRefl nominal (Bug.From1 x) (Bug.D:R:Rep1Identity[0] _N ; Sym (Sym (Bug.D:R:Rep1Identity[0]) _N)))))_R) }}} I haven't dug deeper than that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 04:26:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 04:26:18 -0000 Subject: [GHC] #15009: Float equalities past local equalities In-Reply-To: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> References: <047.0a49c3ac676b2b3bc6f93c4594762c08@haskell.org> Message-ID: <062.a9673a41797daf8d6a437f5d3a40a2cc@haskell.org> #15009: Float equalities past local equalities -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.4.3 Component: Compiler | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: gadt/T15009 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nfrisby): I think I'm slowly making progress! I'm doing it at wiki:FloatMoreEqs2018, to avoid polluting this ticket any more. I might open a separate feature request at some point. In particular, I work through an example there {{{ forall[3] y. () => ( (u : ) , forall[4]. (g : y ~ ) => (w1 : ) ) }}} showing why floating {{{w1}}} out from under {{{g}}} can be problematic. I think this answers my question from comment:10 more precisely than does comment:11. That example motivates a rule, which I'm now working to broaden and concretize: > We can float {{{w1}}} out from under {{{g}}} if {{{y}}} does not and can never again occur in {{{}}}. The destination I have in mind is something like "retiring" {{{g}}} (e.g. discarding it) if we can determine that it has eliminated all possible occurrences of {{{y}}} under it now and forever. I think some relatively simple heuristics are within reach -- will keep working on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 06:09:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 06:09:08 -0000 Subject: [GHC] #15726: Don't include Haskeline (and others) in the global package DB Message-ID: <044.07f22b221f9dd88b8989479d09a519f8@haskell.org> #15726: Don't include Haskeline (and others) in the global package DB -------------------------------------+------------------------------------- Reporter: judah | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Build System | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC installations include `haskeline` in their global DB, as well as its dependencies (currently: `stm` and `terminfo`). However, Haskeline isn't a dependency of the `ghc` library, so that shouldn't be necessary. Originally suggested by hvr here, in response to needing to pull `stm` into the global DB: https://github.com/judah/haskeline/pull/61#issuecomment-294878302 This change would let Haskeline add dependencies more easily. See in particular the pending PR to depend on the "exceptions" package: https://github.com/judah/haskeline/pull/97 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 08:16:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 08:16:58 -0000 Subject: [GHC] #15411: urk! lookup local fingerprint In-Reply-To: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> References: <045.e13102aed1544fc3b35011c9e428c96a@haskell.org> Message-ID: <060.8d1e7b8ece50289f8c097e3a684cb885@haskell.org> #15411: urk! lookup local fingerprint -------------------------------------+------------------------------------- Reporter: admock | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15399 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): I patched GHC 8.6.1 to not use unboxed arrays in `containers` and that fixes the build. Perhaps we need to look for endian issues in `array` or in the RTS array primitives. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 08:42:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 08:42:33 -0000 Subject: [GHC] #15155: How untagged pointers sneak into banged fields In-Reply-To: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> References: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> Message-ID: <063.0369c4091f63730c17f5b1c5db388a88@haskell.org> #15155: How untagged pointers sneak into banged fields -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14677 Related Tickets: #13027 #7308 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by heisenbug): Replying to [comment:15 simonpj]: > ... > > I think we should work on the other tickets identified in commment:1. Are you interested in pursuing any of them? I am at Haskell eXchange in 2 days, so we can discuss this at length there ;-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 10:09:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 10:09:50 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.cb107ddf34652749976be8379d8440fa@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Changes (by osa1): * related: => #14677, #15155 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 10:40:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 10:40:17 -0000 Subject: [GHC] #15727: bug: all generations are collected sequentially when compacting collection kicks in Message-ID: <045.b2fee5046f96adb1cdf5d9d374c4f606@haskell.org> #15727: bug: all generations are collected sequentially when compacting collection kicks in -------------------------------------+------------------------------------- Reporter: lolotp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.6.1 System | 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: -------------------------------------+------------------------------------- According to GHC documentation [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/runtime_control.html #rts-options-to-control-the-garbage-collector here], compacting collection should only be used for the oldest generation. I found out however while testing one of our programs that when compacting kicks in, Gen 0 were not being collected in parallel as well. Looking at the code, the bug looks to be [https://github.com/ghc/ghc/blob/5d5307f943d7581d7013ffe20af22233273fba06/rts/Schedule.c#L1543 here], fixing this should be a simple change to the condition in the if phrase. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 11:19:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 11:19:54 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.e055e9392bea71a4824a0152406a2faa@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): > That seems correct doesn't it? i.e. the implementation doesn't lift such functions, and it shouldn't. The implementation doesn't lift these functions because we ''think'' they won't lead to a beneficial lift anyway. But that's rather a heuristic and for illustrative purposes (e.g., look how things get worse when we allow this) we ''could'' implement the transformation in a way that it can cope with these cases. But after having played with it for a few hours yesterday, I came to realise that this has more serious consequences than I anticipated. In addition to the StgApp case, the Constructor application and PrimOp cases are particularly egregious, because they require to return floats along with the actual tranformed RHS. I'm no longer convinced that the illustrative purpose justifies complicating the implementation so much. > So why do you say "I realised a few things here and there that I could change in the transformation"? In the process of writing the paper, I repeatedly had to double-check what the transformation does and that it actually does the right thing. For example, thinking about how to formulate the function computing closure growth resulting from a lifting decision lead me to realise that we in fact could make better use of strictness in addition to usage (i.e. one- shot) information. Example: {{{ let f = [x y]. \z -> ... g = [x y f]. \u -> ... x ... y ... f u ... in g 1 }}} What's the closure growth resulting from lambda lifting `f`? Previously, although `g`s closure would shrink by one slot (so closure growth -1 from `g`s RHS), we can't be certain that this benefit would be visible on every program path, so we'd have to return 0 here. But that's too conservative, because in fact `g` is called strictly with one argument (strictness demand `C(S)`), which means closure growth for the expression is actually -1 (not yet counting in the saved two slots from not having to allocate a closure for `f`). > What about the implementation. Are you done? Ready to submit a Phab patch for review? With an up-to-date wiki page describing what it does? I consider the implementation done (probably should've submitted a patch much earlier). I'll bring the wiki page up to date and then submit a patch within the next week or so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 11:36:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 11:36:33 -0000 Subject: [GHC] #4900: Consider usage files in the GHCi recompilation check In-Reply-To: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> References: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> Message-ID: <061.96cbfcacd31de25a9d82902339c9dec2@haskell.org> #4900: Consider usage files in the GHCi recompilation check -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: TH_Depends Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by nh2): * cc: nh2 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 11:48:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 11:48:45 -0000 Subject: [GHC] #4900: Consider usage files in the GHCi recompilation check In-Reply-To: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> References: <046.52f138a2609bf72d7f5381a2c64d358e@haskell.org> Message-ID: <061.404a1b4f1539c1cda8700def5fdc97a3@haskell.org> #4900: Consider usage files in the GHCi recompilation check -------------------------------------+------------------------------------- Reporter: cdsmith | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: TH_Depends Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Patrick, is this something you still want to do? It would be awesome to get `addDependentFile` support in ghci, as Haskell projects are only getting larger and being able to iterate quickly with ghci makes it bearable. I personally would be very happy even with an intial mainlined version of this that explicitly doesn't support boot modules, as they are quite rare outside of GHC itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 12:47:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 12:47:14 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.77ad70ab2fc627a3cf0e7ee395030f34@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.6.2 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: 15592 Related Tickets: #15076 | Differential Rev(s): Phab:D4769, | Phab:D5141, Phab:D5147, Phab:D5150, Wiki Page: | Phab:D5208 -------------------------------------+------------------------------------- Comment (by tdammers): Great! Phab:D5141 is ready to merge as far as I am concerned. Step 2 is already lying around in patch form, but I need to rebase it onto step 1, and sort out the test wibbles. Doing that as we speak. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 13:25:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 13:25:35 -0000 Subject: [GHC] #15671: Link errors due to forcibly exporting findPtr In-Reply-To: <044.6372bc7500582c14ea27cfe705ed9ef3@haskell.org> References: <044.6372bc7500582c14ea27cfe705ed9ef3@haskell.org> Message-ID: <059.da44d9e5f0ea0b419243d95389f26359@haskell.org> #15671: Link errors due to forcibly exporting findPtr -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: alpmestan 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: T10955dyn | T10955 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5138 Wiki Page: | -------------------------------------+------------------------------------- Comment (by alpmestan): I have a GHC patch [https://github.com/alpmestan/ghc/commit/f78e0ae443f48bb2c58819f04d781a3d27c2d528 here]. I also opened [https://github.com/snowleopard/hadrian/pull/701 an hadrian PR] to verify that this works as expected. When I get it to pass, I'll submit a differential. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 13:39:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 13:39:26 -0000 Subject: [GHC] #15725: Core Lint error: Trans coercion mis-match In-Reply-To: <050.b669cdd6d53ebfbfb35ff1834b5bd9f3@haskell.org> References: <050.b669cdd6d53ebfbfb35ff1834b5bd9f3@haskell.org> Message-ID: <065.883e2a416ba4d93b4bb23a85c03950ba@haskell.org> #15725: Core Lint error: Trans coercion mis-match -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15703 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Some slightly more precise tracing reveals the following: {{{ opt_co4_wrap } Co: GRefl nominal x_X1Gk (Sym (D:R:Rep1Identity[0]) _N) coercionType(Co): (x_X1Gk :: Par1 a_a1FN) ~# ((x_X1Gk |> Sym (D:R:Rep1Identity[0]) _N) :: Rep1 Identity a_a1FN) --- Result: Sym (GRefl nominal (From1 Identity a_a1FN x_a1FO) ((D:R:Rep1Identity[0] _N ; Sym (Sym (D:R:Rep1Identity[0]) _N)) ; Sym (D:R:Rep1Identity[0]) _N)) coercionType(Result): (From1 Identity a_a1FN x_a1FO :: Rep1 Identity a_a1FN) ~# (From1 Identity a_a1FN x_a1FO :: Rep1 Identity a_a1FN) }}} Next step: figure out why `GRefl` is being optimized so crap-tacularly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 13:43:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 13:43:02 -0000 Subject: [GHC] #15723: -prof -fPIC -fexternal-dynamic-refs generates non-PIC relocations for external symbol In-Reply-To: <046.1c3e8598c6f9064f6c1ee4be47cb671b@haskell.org> References: <046.1c3e8598c6f9064f6c1ee4be47cb671b@haskell.org> Message-ID: <061.c48d15c416862ffb14d12237d2314a6e@haskell.org> #15723: -prof -fPIC -fexternal-dynamic-refs generates non-PIC relocations for external symbol -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 (CodeGen) | 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:D5214 Wiki Page: | -------------------------------------+------------------------------------- Changes (by watashi): * owner: (none) => watashi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 14:03:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 14:03:07 -0000 Subject: [GHC] #15728: Program with safe array operations triggers debug runtime assertion Message-ID: <043.4ccc75228773f971d3fe7d2e0fc9d104@haskell.org> #15728: Program with safe array operations triggers debug runtime assertion -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.6.1 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: -------------------------------------+------------------------------------- I'll try to minimize later. Main.hs: {{{ {-# LANGUAGE ForeignFunctionInterface #-} import Control.Monad import Control.Monad.ST import Data.Primitive.Array import Data.Primitive.ByteArray import Data.Primitive.SmallArray import System.Environment import System.Mem import Foreign.C data A arr = A !Int arr enumSmallArray :: Int -> A (SmallArray Int) enumSmallArray n = runST $ do arr <- newSmallArray n 0 forM_ [1..n] $ \i -> writeSmallArray arr i i iarr <- freezeSmallArray arr 0 n return (A n iarr) consumeSmallArray :: A (SmallArray a) -> a consumeSmallArray (A n arr) = indexSmallArray arr (n - 1) enumArray :: Int -> A (Array Int) enumArray n = runST $ do arr <- newArray n 0 forM_ [1..n] $ \i -> writeArray arr i i iarr <- freezeArray arr 0 n return (A n iarr) consumeArray :: A (Array a) -> a consumeArray (A n arr) = indexArray arr (n - 1) foreign import ccall "printInt" printInt :: CInt -> IO () main :: IO () main = do n <- (\[s] -> read s) <$> getArgs ints <- forM [1..n] $ \i -> do let x = consumeSmallArray (enumSmallArray 12) y = consumeArray (enumArray i) case x+y of r -> when (i `mod` 5000 == 0) performMajorGC >> return r printInt (fromIntegral (sum ints)) }}} print.c: {{{ #include void printInt(int i) { printf("Result: %d\n", i); } }}} Compile: {{{ $ ghc Main.hs print.c -debug Linking Main ... }}} Run: {{{ array_bug $ ./Main 1000 +RTS -DS Main: internal error: ASSERTION FAILED: file rts/sm/Storage.c, line 960 (GHC version 8.6.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug zsh: abort (core dumped) ./Main 1000 +RTS -DS }}} Tried with: 8.4.3, 8.6.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 14:07:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 14:07:46 -0000 Subject: [GHC] #15728: Program with safe array operations triggers debug runtime assertion In-Reply-To: <043.4ccc75228773f971d3fe7d2e0fc9d104@haskell.org> References: <043.4ccc75228773f971d3fe7d2e0fc9d104@haskell.org> Message-ID: <058.7406b4d2a8e4027c2a346b31d0c2d6df@haskell.org> #15728: Program with safe array operations triggers debug runtime assertion -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The backtrace is, {{{ >>> bt #0 __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007ffff6e18dc1 in __GI_abort () at abort.c:79 #2 0x0000000000898c87 in rtsFatalInternalErrorFn (s=0x8fdf18 "ASSERTION FAILED: file %s, line %u\n", ap=0x7fffffff83a8) at rts/RtsMessages.c:186 #3 0x0000000000898871 in barf (s=0x8fdf18 "ASSERTION FAILED: file %s, line %u\n") at rts/RtsMessages.c:48 #4 0x00000000008988d9 in _assertFail (filename=0x900a72 "rts/sm/Storage.c", linenum=978) at rts/RtsMessages.c:63 #5 0x00000000008a0d6e in allocateMightFail (cap=0xc92500 , n=14) at rts/sm/Storage.c:978 #6 0x00000000008a09eb in allocate (cap=0xc92500 , n=14) at rts/sm/Storage.c:853 #7 0x00000000008c51ad in stg_freezzeSmallArrayzh () at rts/PrimOps.cmm:462 Backtrace stopped: previous frame inner to this frame (corrupt stack?) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 14:09:55 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 14:09:55 -0000 Subject: [GHC] #15728: Program with safe array operations triggers debug runtime assertion In-Reply-To: <043.4ccc75228773f971d3fe7d2e0fc9d104@haskell.org> References: <043.4ccc75228773f971d3fe7d2e0fc9d104@haskell.org> Message-ID: <058.3afbf06085ee58a066d9a9418136aa26@haskell.org> #15728: Program with safe array operations triggers debug runtime assertion -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The assertion in question expects to see that the bits that we are about to return to the caller have been cleared with `0xaa` (since sanity checking is enabled). However, isn't quite the case, {{{ #5 0x00000000008a0d6e in allocateMightFail (cap=0xc92500 , n=14) at rts/sm/Storage.c:978 978 IF_DEBUG(sanity, ASSERT(*((StgWord8*)p) == 0xaa)); >>> x/8a p 0x4200105788: 0x420008da21 0xaaaaaaaaaaaaaaaa 0x4200105798: 0xaaaaaaaaaaaaaaaa 0xaaaaaaaaaaaaaaaa 0x42001057a8: 0xaaaaaaaaaaaaaaaa 0xaaaaaaaaaaaaaaaa 0x42001057b8: 0xaaaaaaaaaaaaaaaa 0xaaaaaaaaaaaaaaaa }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 14:20:04 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 14:20:04 -0000 Subject: [GHC] #15729: Static GHCi can segfault when accessing .bss section in C Message-ID: <046.01f3ec3cee991a7182d3dc45051c529d@haskell.org> #15729: Static GHCi can segfault when accessing .bss section in C --------------------------------------+------------------------------- Reporter: watashi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.1 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: --------------------------------------+------------------------------- When an object file is statically linked, GHCi can return junk or segfault when trying to access data defined in .bss section via foreign call. {{{ watashi % ~/gao/ghc/inplace/bin/ghc-stage2 --info | grep Dynamic ,("Dynamic by default","NO") ,("GHC Dynamic","NO") watashi % cat bss.c int read_bss(int i) { static int bss[1 << 20]; return bss[i]; } watashi % ~/gao/ghc/inplace/bin/ghc-stage2 --interactive test.o GHCi, version 8.7.20180920: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/watashi/.ghci Prelude> :m + Foreign Foreign.C Prelude Foreign Foreign.C> foreign import ccall unsafe "read_bss" read_bss :: Int -> IO Int Prelude Foreign Foreign.C> read_bss 0 4294059519 Prelude Foreign Foreign.C> read_bss 1 65535 Prelude Foreign Foreign.C> mapM (read_bss . bit) [0 .. 19] zsh: segmentation fault (core dumped) ~/gao/ghc/inplace/bin/ghc-stage2 --interactive test.o }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 14:20:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 14:20:20 -0000 Subject: [GHC] #15729: Static GHCi can segfault when accessing .bss section in C In-Reply-To: <046.01f3ec3cee991a7182d3dc45051c529d@haskell.org> References: <046.01f3ec3cee991a7182d3dc45051c529d@haskell.org> Message-ID: <061.4cabce541cf6e55f97689745f3082b57@haskell.org> #15729: Static GHCi can segfault when accessing .bss section in C -------------------------------+-------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.1 Resolution: | 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 watashi): * owner: (none) => watashi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 14:38:51 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 14:38:51 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.fb731d447e7e84b26bff32c9a47f40ad@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by bgamari): We will move ahead merging Phag:D5201 to move ahead with 8.6.2 but will continue to pursue the alternatives in Phab:60. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 14:39:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 14:39:12 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.68c51b9e5d5c9ba21a89d18027cd2617@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Changes (by bgamari): * owner: (none) => osa1 Comment: Omer will investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 14:50:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 14:50:58 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.6b56fccaf97244d912cac8382a16f654@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by simonpj): > I believe that spark# and par# also evaluate lifted-type arguments. They do have a lifted-type arg, but they don't evalauate it: they put it in a spark queue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 15:31:36 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 15:31:36 -0000 Subject: [GHC] #14375: Implement with# primop In-Reply-To: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> References: <046.d97bc36423b0cbcf2ececb77831c1a4a@haskell.org> Message-ID: <061.0716c15487c1cb760df8d9c8ec421066@haskell.org> #14375: Implement with# primop -------------------------------------+------------------------------------- Reporter: simonpj | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14346 | Differential Rev(s): ​Phab:D4110, Wiki Page: | Phab:D4189 -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 16:06:05 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 16:06:05 -0000 Subject: [GHC] #15730: SCC/HPC/CORE annotation can change the meaning of an expression Message-ID: <048.4d11c0d5be7d04e9080f8e39f06bd312@haskell.org> #15730: SCC/HPC/CORE annotation can change the meaning of an expression -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.6.1 (Parser) | 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: -------------------------------------+------------------------------------- Consider this GHCi session: {{{ Prelude> 1 / 2 / 2 0.25 Prelude> 1 / {-# SCC ann #-} 2 / 2 1.0 }}} Adding an SCC annotation changed the meaning of the expression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 16:13:05 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 16:13:05 -0000 Subject: [GHC] #15730: SCC/HPC/CORE annotation can change the meaning of an expression In-Reply-To: <048.4d11c0d5be7d04e9080f8e39f06bd312@haskell.org> References: <048.4d11c0d5be7d04e9080f8e39f06bd312@haskell.org> Message-ID: <063.e61ea70a58c0f1841911e609ab0ad4a0@haskell.org> #15730: SCC/HPC/CORE annotation can change the meaning of an expression -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.6.1 (Parser) | 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 int-index): This is a parsing issue. The first expression is parsed as `(1 / 2) / 2`, while the second as `1 / (2 / 2)`. I plan to fix by changing the precedence of the pragma. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 16:56:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 16:56:06 -0000 Subject: [GHC] #15728: Program with safe array operations triggers debug runtime assertion In-Reply-To: <043.4ccc75228773f971d3fe7d2e0fc9d104@haskell.org> References: <043.4ccc75228773f971d3fe7d2e0fc9d104@haskell.org> Message-ID: <058.b1cc1d93e8a45ceb061e60355b11cbeb@haskell.org> #15728: Program with safe array operations triggers debug runtime assertion -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): It appears that the write in question comes from code emitted for `writeSmallArray#`: {{{ Hardware watchpoint 1: *(void**) 0x4200105788 Old value = (void *) 0xaaaaaaaaaaaaaaaa New value = (void *) 0x4200012f01 0x000000000041fb51 in .Lslgf_info () at primitive/Data/Primitive/SmallArray.hs:191 191 primitive_ $ writeSmallArray# sma# i# x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 16:58:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 16:58:45 -0000 Subject: [GHC] #15728: Program with safe array operations triggers debug runtime assertion In-Reply-To: <043.4ccc75228773f971d3fe7d2e0fc9d104@haskell.org> References: <043.4ccc75228773f971d3fe7d2e0fc9d104@haskell.org> Message-ID: <058.786f3f01ad5a336c797d5a90e38b3149@haskell.org> #15728: Program with safe array operations triggers debug runtime assertion -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Runtime System | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => highest Comment: Bumping the priority of this since it looks to me like this could result in corruption. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 17:26:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 17:26:17 -0000 Subject: [GHC] #15703: Significant compilation time blowup when refactoring singletons-heavy code In-Reply-To: <050.85b00ed8f7678528686f0902895081dc@haskell.org> References: <050.85b00ed8f7678528686f0902895081dc@haskell.org> Message-ID: <065.5303eff86922387badbe93b6f8b4467e@haskell.org> #15703: Significant compilation time blowup when refactoring singletons-heavy code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #15725 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I tried compiling this program using the experimental Phab:D4766 (`Zap coercions when not building with -dcore-lint`) branch: {{{ $ time ~/Software/ghc3/inplace/bin/ghc-stage2 -O0 -fforce-recomp Lib.hs [1 of 2] Compiling Lib2 ( Lib2.hs, Lib2.o ) [2 of 2] Compiling Lib ( Lib.hs, Lib.o ) real 0m0.497s user 0m0.460s sys 0m0.028s $ time ~/Software/ghc3/inplace/bin/ghc-stage2 -O1 -fforce-recomp Lib.hs [1 of 2] Compiling Lib2 ( Lib2.hs, Lib2.o ) [2 of 2] Compiling Lib ( Lib.hs, Lib.o ) real 0m17.164s user 0m16.980s sys 0m0.200s }}} This looks promising! Perhaps this really is a duplicate of #8095 in disguise? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 17:34:37 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 17:34:37 -0000 Subject: [GHC] #15703: Significant compilation time blowup when refactoring singletons-heavy code In-Reply-To: <050.85b00ed8f7678528686f0902895081dc@haskell.org> References: <050.85b00ed8f7678528686f0902895081dc@haskell.org> Message-ID: <065.bf7e1cca4d9122ced9fa34042f46b53d@haskell.org> #15703: Significant compilation time blowup when refactoring singletons-heavy code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #15725 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 17:49:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 17:49:21 -0000 Subject: [GHC] #15725: Core Lint error: Trans coercion mis-match In-Reply-To: <050.b669cdd6d53ebfbfb35ff1834b5bd9f3@haskell.org> References: <050.b669cdd6d53ebfbfb35ff1834b5bd9f3@haskell.org> Message-ID: <065.86ab4e52e74a8d8a4698d253458cfbd1@haskell.org> #15725: Core Lint error: Trans coercion mis-match -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15703 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): After much digging this morning, I've finally found my way out of this rabbit hole. It turns out that the culprit is the [http://git.haskell.org/ghc.git/blob/d728c3c578cc9e9205def2c1e96934487b364b7b:/compiler/types/OptCoercion.hs#l375 InstCo] case of `opt_co4`: {{{#!hs -- See Note [Optimising InstCo] opt_co4 env sym rep r (InstCo co1 arg) -- forall over type... | Just (tv, kind_co, co_body) <- splitForAllCo_ty_maybe co1 = opt_co4_wrap (extendLiftingContext env tv (mkCoherenceRightCo Nominal t2 (mkSymCo kind_co) arg')) -- kind_co :: k1 ~ k2 -- arg' :: (t1 :: k1) ~ (t2 :: k2) -- tv |-> (t1 :: k1) ~ (((t2 :: k2) |> (sym kind_co)) :: k1) sym rep r co_body }}} In particular, the bug lies within an optimization where `co1` is of the form `forall (tv :: kind_co). co_body`, as explained in `Note [Optimising InstCo]`. As explained in the comment, we need to extend the `LiftingContext` such that `tv` maps to `(t1 :: k1) ~ (((t2 :: k2) |> (sym kind_co)) :: k1)`, which we accomplish by way of `mkCoherenceRightCo`. The [http://git.haskell.org/ghc.git/blob/4eeeb51d5f51083d0ae393009a7fd246223e9791:/compiler/types/Coercion.hs#l1087 Haddocks] state that given `mkCoherenceRightCo r ty co co2`, the following invariants must hold: {{{ ty :: k1 co :: k1 ~ k2 co2 :: ty' ~ ty }}} That is, it must be the case that `typeKind ty ~ fst (coercionKind co)` and `ty ~ snd (coercionKind co2)`. Through some `pprTrace` sleuthing, I discovered that these were the things being used to instantiate `ty`, `co`, and `co2`, respectively: {{{ ty = t2 = (From1 Identity a x |> D:R:Rep1Identity[0] _N) :: Par1 a co = mkSymCo kind_co = Sym (Sym (D:R:Rep1Identity[0]) _N) :: Rep1 Identity a ~ Par1 a co2 = arg' = GRefl nominal (From1 Identity a x) (D:R:Rep1Identity[0] _N) :: From1 Identity a x ~ (From1 Identity a x |> D:R:Rep1Identity[0] _N) }}} This does uphold the invariant that `ty ~ snd (coercionKind co2)`, but it does //not// uphold the invariant that `typeKind ty ~ fst (coercionKind co)`, since: * `typeKind ty ~ Par1 a` * `fst (coercionKind co) ~ Rep1 Identity a` My best guess as to why this happens is that `arg'` is computed [http://git.haskell.org/ghc.git/blob/d728c3c578cc9e9205def2c1e96934487b364b7b:/compiler/types/OptCoercion.hs#l414 like so]: {{{#!hs arg' = opt_co4_wrap env sym False Nominal arg }}} In particular, we pass `opt_co4_wrap` the `sym` flag which, in the program above, happens to be `True`, so an outer `Sym` is applied to the result of the whole optimized coercion. `mkSymCo kind_co`, on the other hand, was not the result of calling `opt_co4_wrap env sym` (since it comes from `co1`, not `co1'`), which means that it does //not// have the same outer `Sym` that `arg'` has. This causes a "polarity mismatch" between the two, leading to disaster. Here is one way to fix this issue: {{{#!diff diff --git a/compiler/types/OptCoercion.hs b/compiler/types/OptCoercion.hs index 8a44b86..c52e11e 100644 --- a/compiler/types/OptCoercion.hs +++ b/compiler/types/OptCoercion.hs @@ -377,7 +377,7 @@ opt_co4 env sym rep r (InstCo co1 arg) -- forall over type... | Just (tv, kind_co, co_body) <- splitForAllCo_ty_maybe co1 = opt_co4_wrap (extendLiftingContext env tv - (mkCoherenceRightCo Nominal t2 (mkSymCo kind_co) arg')) + (mkCoherenceRightCo Nominal t2 (mkSymCo kind_co) sym_arg')) -- kind_co :: k1 ~ k2 -- arg' :: (t1 :: k1) ~ (t2 :: k2) -- tv |-> (t1 :: k1) ~ (((t2 :: k2) |> (sym kind_co)) :: k1) @@ -396,14 +396,14 @@ opt_co4 env sym rep r (InstCo co1 arg) -- forall over type... | Just (tv', kind_co', co_body') <- splitForAllCo_ty_maybe co1' = opt_co4_wrap (extendLiftingContext (zapLiftingContext env) tv' - (mkCoherenceRightCo Nominal t2 (mkSymCo kind_co') arg')) + (mkCoherenceRightCo Nominal t2' (mkSymCo kind_co') arg')) False False r' co_body' -- forall over coercion... | Just (cv', kind_co', co_body') <- splitForAllCo_co_maybe co1' - , CoercionTy h1 <- t1 - , CoercionTy h2 <- t2 - = let new_co = mk_new_co cv' kind_co' h1 h2 + , CoercionTy h1' <- t1' + , CoercionTy h2' <- t2' + = let new_co = mk_new_co cv' kind_co' h1' h2' in opt_co4_wrap (extendLiftingContext (zapLiftingContext env) cv' new_co) False False r' co_body' @@ -412,7 +412,9 @@ opt_co4 env sym rep r (InstCo co1 arg) co1' = opt_co4_wrap env sym rep r co1 r' = chooseRole rep r arg' = opt_co4_wrap env sym False Nominal arg - Pair t1 t2 = coercionKind arg' + sym_arg' = wrapSym sym arg' + Pair t1 t2 = coercionKind sym_arg' + Pair t1' t2' = coercionKind arg' mk_new_co cv kind_co h1 h2 = let -- h1 :: (t1 ~ t2) }}} Essentially, we wrap `arg'` with another `Sym` to cancel out an extra `Sym` that `opt_co4_wrap env sym` might provide. Of course, this should only apply to the two cases where we inspect `co1` (which did not come from `opt_co4_wrap`); for the two cases where we instead inspect `co1'`, we continue to use plain old `arg'`. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 17:57:21 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 17:57:21 -0000 Subject: [GHC] #15725: Core Lint error: Trans coercion mis-match In-Reply-To: <050.b669cdd6d53ebfbfb35ff1834b5bd9f3@haskell.org> References: <050.b669cdd6d53ebfbfb35ff1834b5bd9f3@haskell.org> Message-ID: <065.69cb5846dcaf310bebca37b5d4a26612@haskell.org> #15725: Core Lint error: Trans coercion mis-match -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15703 | Differential Rev(s): Phab:D5217 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5217 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 17:58:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 17:58:11 -0000 Subject: [GHC] #15728: Program with safe array operations triggers debug runtime assertion In-Reply-To: <043.4ccc75228773f971d3fe7d2e0fc9d104@haskell.org> References: <043.4ccc75228773f971d3fe7d2e0fc9d104@haskell.org> Message-ID: <058.a4ad2c1e6a6da71d715877d259920ec9@haskell.org> #15728: Program with safe array operations triggers debug runtime assertion -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: Component: Runtime System | Version: 8.6.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid Comment: Sigh. The problem was staring at me the entire time: the testcase is wrong. Specifically: {{{#!hs arr <- newSmallArray n 0 forM_ [1..n] $ \i -> writeSmallArray arr i i }}} `[1..n]` will produce an out-of-bounds index for the allocated array. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 18:37:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 18:37:19 -0000 Subject: [GHC] #15730: SCC/HPC/CORE annotation can change the meaning of an expression In-Reply-To: <048.4d11c0d5be7d04e9080f8e39f06bd312@haskell.org> References: <048.4d11c0d5be7d04e9080f8e39f06bd312@haskell.org> Message-ID: <063.0d04a82c29d7af3acb2a7ad1b27b37f1@haskell.org> #15730: SCC/HPC/CORE annotation can change the meaning of an expression -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: Component: Compiler | Version: 8.6.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5218 Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * status: new => patch * differential: => Phab:D5218 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 19:17:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 19:17:45 -0000 Subject: [GHC] #15731: Add sortOn/coerce rule Message-ID: <045.88ea5e7418999c7e348b78eb7134ee32@haskell.org> #15731: Add sortOn/coerce rule -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.8.1 Component: Core | Version: 8.6.1 Libraries | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When the argument to `sortOn` is very cheap, we're better off ''not'' decorating the list. Detecting this is not easy in general, but it's trivial for coercions. We should probably offer something like {{{#!hs {-# RULES "sortOn/coerce" forall b xs. sortOn @_ @b coerce xs = sortWith (coerce @_ @b) xs #-} }}} As far as I can tell, we can't use type application directly like that, but we can go via `Proxy#`. `PrelRules` could do better, of course, catching selector functions, but I don't think we want to go that far. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 19:31:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 19:31:14 -0000 Subject: [GHC] #15732: getArgsWithResponseFiles does not filter out RTS options Message-ID: <048.b4d2648ba00dd69525e93686e30914e8@haskell.org> #15732: getArgsWithResponseFiles does not filter out RTS options -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: | Version: 8.6.1 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: #13896 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I discovered this while working on a fix for #15072. {{{GHC.ResponseFile.getArgsWithResponseFiles}}} is a recent addition to {{{base-4.12}}}. The idea was to have a function which could read command- line arguments supplied via response files, but otherwise would behave exactly like `System.Environment.getArgs` (see #13896). However, these functions return different results when RTS options are supplied. 1. {{{getArgs}}} does not include RTS options in the list it returns. 2. {{{getArgsWithResponseFiles}}} includes them. It's trivial to reproduce this. Consider these files: {{{ -- Bug1.hs module Main where import System.Environment ( getArgs ) main :: IO () main = do args <- getArgs putStrLn $ "Args: " ++ show args }}} and {{{ -- Bug2.hs module Main where import GHC.ResponseFile ( getArgsWithResponseFiles ) main :: IO () main = do args <- getArgsWithResponseFiles putStrLn $ "ArgsResp: " ++ show args }}} And run them with: {{{#!sh $ ghc-8.6.1 -rtsopts Bug1.hs && ghc-8.6.1 -rtsopts Bug2.hs $ ./Bug1 1 +RTS -H32m -RTS 10 20 Args: ["1","10","20"] -- 'opts_file' contains the same arguments passed to Bug1, and we -- use a '@' to pass it as a response file $ ./Bug2 @opts_file ArgsResp: ["1","+RTS","-H32m","-RTS","10","20"] }}} We should fix {{{getArgsWithResponseFiles}}} to properly handle {{{+RTS ... -RTS}}} and {{{--RTS}}} flags. Currently, {{{getArgs}}} relies on the [http://git.haskell.org/ghc.git/blob/HEAD:/rts/RtsFlags.c#l661 runtime system] for filtering out appropriate things. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 19:40:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 19:40:47 -0000 Subject: [GHC] #15732: getArgsWithResponseFiles does not filter out RTS options In-Reply-To: <048.b4d2648ba00dd69525e93686e30914e8@haskell.org> References: <048.b4d2648ba00dd69525e93686e30914e8@haskell.org> Message-ID: <063.740dc3fe103e3a09f661cfc088285d8b@haskell.org> #15732: getArgsWithResponseFiles does not filter out RTS options -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: libraries/base | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #13896 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by ckoparkar: Old description: > I discovered this while working on a fix for #15072. > > {{{GHC.ResponseFile.getArgsWithResponseFiles}}} is a recent addition to > {{{base-4.12}}}. The idea was to have a function which could read > command-line arguments supplied via response files, but otherwise > would behave exactly like `System.Environment.getArgs` (see #13896). > However, these functions return different results when RTS options are > supplied. > 1. {{{getArgs}}} does not include RTS options in the list it returns. > 2. {{{getArgsWithResponseFiles}}} includes them. > > It's trivial to reproduce this. Consider these files: > > {{{ > -- Bug1.hs > module Main where > > import System.Environment ( getArgs ) > > main :: IO () > main = do > args <- getArgs > putStrLn $ "Args: " ++ show args > }}} > > and > > {{{ > -- Bug2.hs > module Main where > > import GHC.ResponseFile ( getArgsWithResponseFiles ) > > main :: IO () > main = do > args <- getArgsWithResponseFiles > putStrLn $ "ArgsResp: " ++ show args > }}} > > And run them with: > > {{{#!sh > $ ghc-8.6.1 -rtsopts Bug1.hs && ghc-8.6.1 -rtsopts Bug2.hs > > $ ./Bug1 1 +RTS -H32m -RTS 10 20 > Args: ["1","10","20"] > > -- 'opts_file' contains the same arguments passed to Bug1, and we > -- use a '@' to pass it as a response file > > $ ./Bug2 @opts_file > ArgsResp: ["1","+RTS","-H32m","-RTS","10","20"] > }}} > > We should fix {{{getArgsWithResponseFiles}}} to properly handle {{{+RTS > ... -RTS}}} and {{{--RTS}}} flags. Currently, {{{getArgs}}} relies on the > [http://git.haskell.org/ghc.git/blob/HEAD:/rts/RtsFlags.c#l661 runtime > system] for filtering out appropriate things. New description: I discovered this while working on a fix for #15072. {{{GHC.ResponseFile.getArgsWithResponseFiles}}} is a recent addition to {{{base-4.12}}}. The idea was to have a function which could read command- line arguments supplied via response files, but otherwise would behave exactly like `System.Environment.getArgs` (see #13896). However, these functions return different results when RTS options are supplied. 1. {{{getArgs}}} does not include RTS options in the list it returns. 2. {{{getArgsWithResponseFiles}}} includes them. It's trivial to reproduce this. Consider these files: {{{ -- Bug1.hs module Main where import System.Environment ( getArgs ) main :: IO () main = do args <- getArgs putStrLn $ "Args: " ++ show args }}} and {{{ -- Bug2.hs module Main where import GHC.ResponseFile ( getArgsWithResponseFiles ) main :: IO () main = do args <- getArgsWithResponseFiles putStrLn $ "ArgsResp: " ++ show args }}} And run them with: {{{#!sh $ ghc-8.6.1 -rtsopts Bug1.hs && ghc-8.6.1 -rtsopts Bug2.hs $ ./Bug1 1 +RTS -H32m -RTS 10 20 Args: ["1","10","20"] -- 'opts_file' contains the same arguments passed to Bug1, and we -- use a '@' to pass it as a response file $ ./Bug2 @opts_file ArgsResp: ["1","+RTS","-H32m","-RTS","10","20"] }}} We should fix {{{getArgsWithResponseFiles}}} to properly handle {{{+RTS ... -RTS}}} and {{{--RTS}}} flags. {{{getArgs}}} relies on the [http://git.haskell.org/ghc.git/blob/HEAD:/rts/RtsFlags.c#l661 runtime system] for this. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 19:58:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 19:58:49 -0000 Subject: [GHC] #15729: Static GHCi can segfault when accessing .bss section in C In-Reply-To: <046.01f3ec3cee991a7182d3dc45051c529d@haskell.org> References: <046.01f3ec3cee991a7182d3dc45051c529d@haskell.org> Message-ID: <061.95d9ba0062c8311d863aa814cced2ed0@haskell.org> #15729: Static GHCi can segfault when accessing .bss section in C -------------------------------+-------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.1 Resolution: | 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: | -------------------------------+-------------------------------------- Comment (by simonmar): I think this is the same as #781, one of the oldest bugs we still have open. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 20:01:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 20:01:31 -0000 Subject: [GHC] #15729: Static GHCi can segfault when accessing .bss section in C In-Reply-To: <046.01f3ec3cee991a7182d3dc45051c529d@haskell.org> References: <046.01f3ec3cee991a7182d3dc45051c529d@haskell.org> Message-ID: <061.71e41cde466f67419d42684be4a32e00@haskell.org> #15729: Static GHCi can segfault when accessing .bss section in C -------------------------------+-------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.1 Resolution: | 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: | -------------------------------+-------------------------------------- Comment (by watashi): @simonmar It's similar, but not exactly the same. I don't know how we can fix #781 with static link, but this one should be fixable by allocating the .bss section in the range of 2G with the object. I will send a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 20:08:51 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 20:08:51 -0000 Subject: [GHC] #15155: How untagged pointers sneak into banged fields In-Reply-To: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> References: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> Message-ID: <063.34b9029f11ca3169286fa019c10e8cd3@haskell.org> #15155: How untagged pointers sneak into banged fields -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14677 Related Tickets: #13027 #7308 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Just to write down what @simonpj and I discussed earlier today: it *would* be possible to ensure that a strict field of a constructor always points to a tagged value, by employing the same method we now use for `dataToTag#` (see Phab:D5201), namely have the code generator inject an eval for each strict field when building the constructor. The eval could be omitted in cases where the codegen can see that the value for the field is already a tagged value, these cases could include: * it's a constructor we just built * it's a case binder * the value was read from another strict constructor However, the extra eval would likely remain in many cases. But evals are cheap - just a tag test in the common case. Whether this ends up being a win or not is hard to say, it would be a good experiment to do though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 20:09:54 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 20:09:54 -0000 Subject: [GHC] #15730: SCC/HPC/CORE annotation can change the meaning of an expression In-Reply-To: <048.4d11c0d5be7d04e9080f8e39f06bd312@haskell.org> References: <048.4d11c0d5be7d04e9080f8e39f06bd312@haskell.org> Message-ID: <063.0f2714d08eb94218e011e319e45e8047@haskell.org> #15730: SCC/HPC/CORE annotation can change the meaning of an expression -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: Component: Compiler | Version: 8.6.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5218 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Thanks for the patch. I added a comment there. In short, this is not a bug, you just need to know that annotations have lower precedence that everything else. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 20:14:44 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 20:14:44 -0000 Subject: [GHC] #15730: SCC/HPC/CORE annotation can change the meaning of an expression In-Reply-To: <048.4d11c0d5be7d04e9080f8e39f06bd312@haskell.org> References: <048.4d11c0d5be7d04e9080f8e39f06bd312@haskell.org> Message-ID: <063.5cf931a5bd58279663accae36bafe254@haskell.org> #15730: SCC/HPC/CORE annotation can change the meaning of an expression -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: Component: Compiler | Version: 8.6.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5218 Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): > In short, this is not a bug, you just need to know that annotations have lower precedence that everything else. Adding an annotation should not change the parse tree in any way other than adding an annotation to a node. I am firm in this expectation. "You just have to know there's a bug" is still a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 20:16:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 20:16:34 -0000 Subject: [GHC] #14854: The size of FastString table is suboptimal for large codebases In-Reply-To: <046.96a71a8566a954e21839a1a60572305e@haskell.org> References: <046.96a71a8566a954e21839a1a60572305e@haskell.org> Message-ID: <061.29a5de519508eecedfd34f14b3c7672d@haskell.org> #14854: The size of FastString table is suboptimal for large codebases -------------------------------------+------------------------------------- Reporter: niteria | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5211 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): @simonpj, there's a diff up for review: Phab:D5211 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 20:22:20 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 20:22:20 -0000 Subject: [GHC] #15730: SCC/HPC/CORE annotation can change the meaning of an expression In-Reply-To: <048.4d11c0d5be7d04e9080f8e39f06bd312@haskell.org> References: <048.4d11c0d5be7d04e9080f8e39f06bd312@haskell.org> Message-ID: <063.9ece6c3dd3b3a9dc0517e0ba49aec7d7@haskell.org> #15730: SCC/HPC/CORE annotation can change the meaning of an expression -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: Component: Compiler | Version: 8.6.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5218 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): > Adding an annotation should not change the parse tree in any way other than adding an annotation to a node You're assuming that in {{{ {-# SCC foo #-} f x y }}} the node you're annotating is `f` and not `f x y`. I don't know why this is better or more reasonable than the current behavior. Either way, as said in the diff, you need a proposal for this as this is a breaking change of a user-facing behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 20:29:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 20:29:42 -0000 Subject: [GHC] #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` In-Reply-To: <046.74175c624c857c997e111eade5eabf30@haskell.org> References: <046.74175c624c857c997e111eade5eabf30@haskell.org> Message-ID: <061.3096b3582e00a0d482af50a08f62516b@haskell.org> #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` -------------------------------------+------------------------------------- Reporter: rockbmb | Owner: rockbmb Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: base, | Data.Fixed Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Bodigrim): `Compose` itself makes no difference, of course. The instance from your PR is equivalent to `resolution = (10 ^) . natVal . Compose`. My suggestion is to put `resolution = natVal . Compose`, which makes us able to express desired accuracy both in decimal (`E 1000`) and binary (`E 1024`) digits, as well as in any other base. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 20:29:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 20:29:50 -0000 Subject: [GHC] #15730: SCC/HPC/CORE annotation can change the meaning of an expression In-Reply-To: <048.4d11c0d5be7d04e9080f8e39f06bd312@haskell.org> References: <048.4d11c0d5be7d04e9080f8e39f06bd312@haskell.org> Message-ID: <063.f567ba426041314ef0cbf04edfc5af74@haskell.org> #15730: SCC/HPC/CORE annotation can change the meaning of an expression -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: Component: Compiler | Version: 8.6.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5218 Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): Replying to [comment:5 osa1]: > > Adding an annotation should not change the parse tree in any way other than adding an annotation to a node > > You're assuming that in > > {{{ > {-# SCC foo #-} f x y > }}} > > the node you're annotating is `f` and not `f x y`. I don't know why this is better or more reasonable than the current behavior. > I'm not assuming this. In the patch that I offered, it is still parsed as `{-# SCC foo #-} f x y`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 20:32:05 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 20:32:05 -0000 Subject: [GHC] #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` In-Reply-To: <046.74175c624c857c997e111eade5eabf30@haskell.org> References: <046.74175c624c857c997e111eade5eabf30@haskell.org> Message-ID: <061.73f64ba51954e75577106097f1ae1857@haskell.org> #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` -------------------------------------+------------------------------------- Reporter: rockbmb | Owner: rockbmb Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: base, | Data.Fixed Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ashley Yakeley): Alternatively, use Nat directly? {{{ newtype Fixed (n :: Nat) = MkFixed Integer }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 20:39:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 20:39:35 -0000 Subject: [GHC] #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` In-Reply-To: <046.74175c624c857c997e111eade5eabf30@haskell.org> References: <046.74175c624c857c997e111eade5eabf30@haskell.org> Message-ID: <061.15b066477899c5a2f6900ee2baebeaee@haskell.org> #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` -------------------------------------+------------------------------------- Reporter: rockbmb | Owner: rockbmb Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: base, | Data.Fixed Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ashley Yakeley): Regarding representation type, the performance of the time library, as well as ease of serialisation, might be improvable if `DiffTime` and `NominalDiffTime` (which wrap `Pico`) were represented with 128-bit integer type rather than `Integer`. See . That said, I'm not feeling a lot of pressure for this at the moment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 20:41:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 20:41:31 -0000 Subject: [GHC] #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` In-Reply-To: <046.74175c624c857c997e111eade5eabf30@haskell.org> References: <046.74175c624c857c997e111eade5eabf30@haskell.org> Message-ID: <061.f701c2477278ff0a32ab7e1653c78410@haskell.org> #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` -------------------------------------+------------------------------------- Reporter: rockbmb | Owner: rockbmb Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: base, | Data.Fixed Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ashley Yakeley): If I were starting over, with no compatibility concerns, I would certainly do this: {{{ newtype Fixed a (n :: Nat) = MkFixed a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 20:42:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 20:42:18 -0000 Subject: [GHC] #15703: Significant compilation time blowup when refactoring singletons-heavy code In-Reply-To: <050.85b00ed8f7678528686f0902895081dc@haskell.org> References: <050.85b00ed8f7678528686f0902895081dc@haskell.org> Message-ID: <065.e4d9d837158b1f00bee32a0b89d6f73e@haskell.org> #15703: Significant compilation time blowup when refactoring singletons-heavy code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #15725 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I still think (comment:6) that it may well be that there is massive redundancy here, and if so it'd be a pity to miss out on fixing that, good though #8095 is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 20:44:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 20:44:28 -0000 Subject: [GHC] #15728: Program with safe array operations triggers debug runtime assertion In-Reply-To: <043.4ccc75228773f971d3fe7d2e0fc9d104@haskell.org> References: <043.4ccc75228773f971d3fe7d2e0fc9d104@haskell.org> Message-ID: <058.1312a7db7fd0042d1547d9977be8f33f@haskell.org> #15728: Program with safe array operations triggers debug runtime assertion -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: Component: Runtime System | Version: 8.6.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): So why don't we get an array-bounds check? Or is there no check? In which case it should be `unsafeWriteSmallArray`! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 20:49:06 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 20:49:06 -0000 Subject: [GHC] #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` In-Reply-To: <046.74175c624c857c997e111eade5eabf30@haskell.org> References: <046.74175c624c857c997e111eade5eabf30@haskell.org> Message-ID: <061.1fb88765ccacc0c8a653206ec59a0269@haskell.org> #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` -------------------------------------+------------------------------------- Reporter: rockbmb | Owner: rockbmb Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: base, | Data.Fixed Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ashley Yakeley): `Nat` is just a wrapper for `Integer`, isn't it? As opposed to `data Nat = Z | S Nat`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 20:50:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 20:50:45 -0000 Subject: [GHC] #15728: Program with safe array operations triggers debug runtime assertion In-Reply-To: <043.4ccc75228773f971d3fe7d2e0fc9d104@haskell.org> References: <043.4ccc75228773f971d3fe7d2e0fc9d104@haskell.org> Message-ID: <058.39eaf56bffc3a7a0dc79a79a6f6663e6@haskell.org> #15728: Program with safe array operations triggers debug runtime assertion -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: Component: Runtime System | Version: 8.6.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): That's because the `primitive` library is a very thin wrapper around GHC primops, and GHC primops (`readArray#` etc.) don't do bounds checking. FWIW I just opened a ticket: https://github.com/haskell/primitive/issues/212 at the very least we should mention this in primitive's haddocks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 21:11:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 21:11:17 -0000 Subject: [GHC] #15725: Core Lint error: Trans coercion mis-match In-Reply-To: <050.b669cdd6d53ebfbfb35ff1834b5bd9f3@haskell.org> References: <050.b669cdd6d53ebfbfb35ff1834b5bd9f3@haskell.org> Message-ID: <065.db6906507c55c25cfd336bcd42a82ed9@haskell.org> #15725: Core Lint error: Trans coercion mis-match -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15703 | Differential Rev(s): Phab:D5217 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Great sleuthing! Is the bug in [https://www.microsoft.com/en-us/research/publication /evidence-normalization-system-fc-2/ the paper], or just in the implementation? If the former we should fix the paper. I have not studied the details of your patch, but I'm sure Richard will. Thank you for doing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 21:13:48 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 21:13:48 -0000 Subject: [GHC] #15155: How untagged pointers sneak into banged fields In-Reply-To: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> References: <048.7d229d504bd9df060a5294d6d9eccfdc@haskell.org> Message-ID: <063.eff7220297ff9c4e440a245754205988@haskell.org> #15155: How untagged pointers sneak into banged fields -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: heisenbug Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14677 Related Tickets: #13027 #7308 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I agree with comment:17. But we also agreed that our short term plan is * Do ''not'' require the invariant that every strict constructor field must be a correctly tagged pointer to a data value. Fewer invariants means less to think about - and this is a delicate one! Moreover, it's not clear whether efficiency would be better or worse with it. But yes, it'd be good to try it out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 21:17:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 21:17:46 -0000 Subject: [GHC] #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` In-Reply-To: <046.74175c624c857c997e111eade5eabf30@haskell.org> References: <046.74175c624c857c997e111eade5eabf30@haskell.org> Message-ID: <061.cc923b03db6872e8f192f97b8218cb61@haskell.org> #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` -------------------------------------+------------------------------------- Reporter: rockbmb | Owner: rockbmb Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: base, | Data.Fixed Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Bodigrim): Replying to [comment:22 Ashley Yakeley]: > Alternatively, use Nat directly? > > {{{ > newtype Fixed (n :: Nat) = MkFixed Integer > }}} Yeah, looks nice. But one should scan Hackage again to make sure that no one derived `HasResolution` instances for his own types. Replying to [comment:25 Ashley Yakeley]: > `Nat` is just a wrapper for `Integer`, isn't it? As opposed to `data Nat = Z | S Nat`? Yes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 21:20:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 21:20:31 -0000 Subject: [GHC] #15731: Add sortOn/coerce rule In-Reply-To: <045.88ea5e7418999c7e348b78eb7134ee32@haskell.org> References: <045.88ea5e7418999c7e348b78eb7134ee32@haskell.org> Message-ID: <060.75b6f78bc8145000587fae9f9fc6c10e@haskell.org> #15731: Add sortOn/coerce rule -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm completely lost. What is the problem you are trying to solve? What does it mean to "decorate the list"? What is the bug you are reporting? Or is it a feature request? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 21:21:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 21:21:07 -0000 Subject: [GHC] #15725: Core Lint error: Trans coercion mis-match In-Reply-To: <050.b669cdd6d53ebfbfb35ff1834b5bd9f3@haskell.org> References: <050.b669cdd6d53ebfbfb35ff1834b5bd9f3@haskell.org> Message-ID: <065.28367536a3b3b3c1288e77e07690a6c0@haskell.org> #15725: Core Lint error: Trans coercion mis-match -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15703 | Differential Rev(s): Phab:D5217 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:5 simonpj]: > Is the bug in [https://www.microsoft.com/en-us/research/publication /evidence-normalization-system-fc-2/ the paper], or just in the implementation? I'm not sure. Having skimmed the paper, it looks like the code I changed roughly corresponds to the RedInstTy reduction rule from Figure 7 (when you have `InstCo (ForAllCo (a:eta). gamma) phi`). But the RedInstTy rule that is shown in the paper is much simpler than the thing that's actually implemented in GHC, since the paper doesn't distinguish between the cases where `a` is a type variable or coercion variable, nor does it include any details of the "lifting context" business from //System FC with Explicit Kind Equality//. So I can't really make any kind of judgment on whether //Evidence Normalisation in System FC// is correct or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 21:22:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 21:22:41 -0000 Subject: [GHC] #15731: Add sortOn/coerce rule In-Reply-To: <045.88ea5e7418999c7e348b78eb7134ee32@haskell.org> References: <045.88ea5e7418999c7e348b78eb7134ee32@haskell.org> Message-ID: <060.b237360a4e7aa36e77bfb875a66ee85e@haskell.org> #15731: Add sortOn/coerce rule -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): `sortOn` uses decorate-sort-undecorate, which is only efficient if the passed function is sufficiently expensive. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 21:44:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 21:44:26 -0000 Subject: [GHC] #15703: Significant compilation time blowup when refactoring singletons-heavy code In-Reply-To: <050.85b00ed8f7678528686f0902895081dc@haskell.org> References: <050.85b00ed8f7678528686f0902895081dc@haskell.org> Message-ID: <065.dc3920aafc7411c353d8a975e0f82a4c@haskell.org> #15703: Significant compilation time blowup when refactoring singletons-heavy code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #15725 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Hold on a second... now that I've compiled GHC HEAD, it turns out that HEAD compiles this program //much// faster than 8.6.1 does: {{{ $ time ~/Software/ghc2/inplace/bin/ghc-stage2 -O0 -fforce-recomp Lib.hs [1 of 2] Compiling Lib2 ( Lib2.hs, Lib2.o ) [2 of 2] Compiling Lib ( Lib.hs, Lib.o ) real 0m0.462s user 0m0.404s sys 0m0.048s $ time ~/Software/ghc2/inplace/bin/ghc-stage2 -O1 -fforce-recomp Lib.hs [1 of 2] Compiling Lib2 ( Lib2.hs, Lib2.o ) [2 of 2] Compiling Lib ( Lib.hs, Lib.o ) real 0m22.205s user 0m22.180s sys 0m0.048s }}} In fact, much of the speed gain that I saw in comment:8 would more accurately be attributed to using HEAD, not necessarily Phab:D4766 (although Phab:D4766 does seem to shave off about five seconds, which is nothing to shake a stick at). It's not clear to me what makes HEAD so much faster, but that's quite encouraging! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 22:08:00 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 22:08:00 -0000 Subject: [GHC] #15703: Significant compilation time blowup when refactoring singletons-heavy code In-Reply-To: <050.85b00ed8f7678528686f0902895081dc@haskell.org> References: <050.85b00ed8f7678528686f0902895081dc@haskell.org> Message-ID: <065.fb7232bdc816350fc54bb48f5c4fa060@haskell.org> #15703: Significant compilation time blowup when refactoring singletons-heavy code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #15725 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Interesting. It's great that HEAD is faster; and it'd be even better to understand why. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 22:15:51 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 22:15:51 -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.bb3dd326a71bc4fd64b6ac2d264987be@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: CodeGen 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): * keywords: => CodeGen -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 23:17:05 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 23:17:05 -0000 Subject: [GHC] #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` In-Reply-To: <046.74175c624c857c997e111eade5eabf30@haskell.org> References: <046.74175c624c857c997e111eade5eabf30@haskell.org> Message-ID: <061.d90e6f480306f3c185a3702c0107fa95@haskell.org> #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` -------------------------------------+------------------------------------- Reporter: rockbmb | Owner: rockbmb Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: base, | Data.Fixed Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rockbmb): Replying to [comment:21 Bodigrim]: > `Compose` itself makes no difference, of course. The instance from your PR is equivalent to `resolution = (10 ^) . natVal . Compose`. My suggestion is to put `resolution = natVal . Compose`, which makes us able to express desired accuracy both in decimal (`E 1000`) and binary (`E 1024`) digits, as well as in any other base. I understand now, I failed to notice that where I wrote `type Milli = E 3`, you wrote `type Milli = E 1000`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 9 23:26:22 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Oct 2018 23:26:22 -0000 Subject: [GHC] #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` In-Reply-To: <046.74175c624c857c997e111eade5eabf30@haskell.org> References: <046.74175c624c857c997e111eade5eabf30@haskell.org> Message-ID: <061.773bc9a45efb251b6876ef735f95db02@haskell.org> #15622: Generalize `E{0,1,2,3,6,9,12}` from `Data.Fixed` -------------------------------------+------------------------------------- Reporter: rockbmb | Owner: rockbmb Type: feature request | Status: new Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: base, | Data.Fixed Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rockbmb): Replying to [comment:24 Ashley Yakeley]: > If I were starting over, with no compatibility concerns, I would certainly do this: > > {{{ > newtype Fixed a (n :: Nat) = MkFixed a > }}} In this case, isn't one of the two false: * One of the type parameters is unnecessary (I'd say `a`) * `HasResolution` is unnecessary ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 00:23:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 00:23:14 -0000 Subject: [GHC] #15729: Static GHCi can segfault when accessing .bss section in C In-Reply-To: <046.01f3ec3cee991a7182d3dc45051c529d@haskell.org> References: <046.01f3ec3cee991a7182d3dc45051c529d@haskell.org> Message-ID: <061.956e6ebdb3d9689e6bb003a82b7ae7ac@haskell.org> #15729: Static GHCi can segfault when accessing .bss section in C -------------------------------+-------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #781 | Differential Rev(s): Phab:D5219 Wiki Page: | -------------------------------+-------------------------------------- Changes (by watashi): * differential: => Phab:D5219 * related: => #781 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 03:06:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 03:06:43 -0000 Subject: [GHC] #15632: Undependable Dependencies In-Reply-To: <043.01997ce1746c591111a0a2273155036b@haskell.org> References: <043.01997ce1746c591111a0a2273155036b@haskell.org> Message-ID: <058.ccaa7cf27b51592e7bf842bf2a174463@haskell.org> #15632: Undependable Dependencies -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: | FunctionalDependencies, | OverlappingInstances Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 10675, 9210, | Differential Rev(s): 8634 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): There is a structure of instances for which the suggested rules at comment:2 are over-restrictive: you can code round it under the rules, but awkwardly. I'd appreciate feedback on how common this is: a diamond overlap pattern. Consider {{{#!hs class Whuther a b | a -> b where ... instance Whuther (Int, a2, Bool) Hither where ... instance (b ~ Thither) => Whuther (Int, a2, a3) b where ... instance (b ~ Thither) => Whuther (a1, a2, Bool) b where ... instance (b ~ Yon) Whuther (a1, a2, a3) b where ... }}} The `Hither`instance is strictly more specific than any of the other three; the `Yon` instance is strictly more general. The two `Thither` instances overlap, but are in no substitution order, so don't meet conditions B ii), B iii) above. (For the example, it's not necessary the two instances produce the same result type for `b`, it just makes the example more poignant. Also it's not necessary for there to be a more general instance; in practice there usually is a 'catch-all'.) Currently GHC accepts this example, and does the 'right thing'. (Saying GHC accepts it is not much of a claim: GHC will accept nearly any rubbishy set of instances; whether it does the 'right thing' in all cases needs a lot of testing.) The example can be coded within the rules, via an auxiliary class: {{{#!hs class Whuther a b | a -> b where ... instance Whuther (Int, a2, Bool) Hither where ... instance (b ~ Thither) => Whuther (Int, a2, a3) b where ... instance (Whuther2 (a1, a2, a3) b) => Whuther (a1, a2, a3) b where ... class Whuther2 a b | a -> b where ... instance (b ~ Thither) => Whuther2 (a1, a2, Bool) b where ... instance (b ~ Yon) Whuther2 (a1, a2, a3) b where ... }}} This has taken a symmetric set of instances to asymmetric, arbitrarily moving one of the instances into the auxiliary class. A very similar set of instances that GHC also accepts, but for which it's not clear what would be the 'right thing': {{{#!hs class Whuther a b | a -> b where ... instance Whuther (Int, Char, Bool) Hither where ... instance (b ~ Thither) => Whuther (Int, a2, a3) b where ... instance (b ~ Thither) => Whuther (a1, a2, Bool) b where ... instance (b ~ Yon) Whuther (a1, a2, a3) b where ... }}} These are accepted because of GHC's delayed/relaxed overlap check. then consider a wanted `Whuther (Int, a2, Bool) b` in which `a2` is known to be apart from `Char`. This gives irresolvable overlap, because there's no reason to prefer either of the `Thither` instances. I could amend the rules, still keeping within the idea of pairwise validation of instance heads. If A), B) fail: C) Relax to follow GHC's bogus consistency check providing all of i) The FunDep is full; ii) The instances overlap but neither is strictly more specific; there is a third instance strictly more specific than either; and iii) that third instance's argument positions taken together are exactly at the unification of the two partially-overlapping instances' argument positions. (i.e. the third instance's result positions are not less specific than the unification.) C ii), iii) together need search amongst instances. Note there could be at most one instance that would meet the criteria: * `Whuther (Int, a2, Bool) Hither` meets C ii), its `(Int, a2, Bool)` exactly meets C iii). * `Whuther (Int, Char, Bool) Hither` meets C ii), but its `(Int Char, Bool)` is too specific for C iii). * Note that both of those instances could legitimately be in scope under the rules: they're in a strict substitution order; and their FunDep result position is the same (meets condition A)'s strict consistency condition). To make the search a bit more deterministic, we could revise C ii) to require C) ii') Neither of the instances is strictly more specific; and there is a third instance at exactly the unification of the two instances. Then C iii) is not needed. Under C ii'), the example at the top of this comment would be rejected, but the `Hither` instance could be amended to: {{{#!hs instance (b ~ Hither) => Whuther (Int, a2, Bool) b where ... }}} And that would still allow another `instance Whuther (Int, Char, Bool) Hither`, which is strictly more specific yet. I've tried coding either version of rule C). It needs **either** entirely restructuring the consistency check to delay until all the instances are visible (rather than validating instances one-by-one in order of textual appearance); **or** requiring the programmer write the overlapping instances in textual order most-specific first. Usual practice is to write most-specific first. Never the less this makes the validation rules brittle: programmers won't appreciate error messages suggesting re- ordering their instances ''might'' help (no guarantee). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 07:32:55 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 07:32:55 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.aacce2be49ed2c614cc0dc3f65085943@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"ac977688523e5d77eb6f041f043552410b0c21da/ghc" ac977688/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ac977688523e5d77eb6f041f043552410b0c21da" Fix dataToTag# argument evaluation See #15696 for more details. We now always enter dataToTag# argument (done in generated Cmm, in StgCmmExpr). Any high-level optimisations on dataToTag# applications are done by the simplifier. Looking at tag bits (instead of reading the info table) for small types is left to another diff. Incorrect test T14626 is removed. We no longer do this optimisation (see comment:44, comment:45, comment:60). Comments and notes about special cases around dataToTag# are removed. We no longer have any special cases around it in Core. Other changes related to evaluating primops (seq# and dataToTag#) will be pursued in follow-up diffs. Test Plan: Validates with three regression tests Reviewers: simonpj, simonmar, hvr, bgamari, dfeuer Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15696 Differential Revision: https://phabricator.haskell.org/D5201 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 07:35:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 07:35:37 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.c29c9575db54bef4989e3db9debb2aa6@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): The bug fix is now merged. I'll be investigating the loose ends mentioned in comment:60. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 08:58:09 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 08:58:09 -0000 Subject: [GHC] #15733: Several links in GHC.Exts.Heap documentation are broken Message-ID: <049.e71035ad0f7b2d4e40b57a77fc8c9c35@haskell.org> #15733: Several links in GHC.Exts.Heap documentation are broken -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There are some broken links in the GHC.Exts.Heap documentation. https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc- heap-8.6.1/GHC-Exts-Heap.html For example, in `GenClosure`, the first link is wrong and redirects. http://hackage.haskell.org/trac/ghc/browser/includes/rts/storage/Closures.h Similarly in the definition of `StgInfoTable`. Those are the two I found. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 08:59:49 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 08:59:49 -0000 Subject: [GHC] #15734: ghc-heap package is not on hackage Message-ID: <049.300f57126ce3ad632ecc7d07ef48ea17@haskell.org> #15734: ghc-heap package is not on hackage -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The documentation for ghc-heap is quite hidden away here: https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc- heap-8.6.1/GHC-Exts-Heap.html It would be useful if it was on hackage so that it had better discoverability and was easier to browse the documentation like the normal `ghc` package. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 09:12:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 09:12:56 -0000 Subject: [GHC] #15735: ghc-heap doesn't support profiling Message-ID: <049.3191219306253cf22cd5b8421d297cba@haskell.org> #15735: ghc-heap doesn't support profiling -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc-heap should show an accurate representation of what's on the heap. When profiling is enabled the profiling header is just completely ignored and not represented in the `StgInfoTable`. https://downloads.haskell.org/~ghc/latest/docs/html/libraries/ghc- heap-8.6.1/GHC-Exts-Heap.html#t:StgInfoTable A new field should be added to `StgInfoTable` with type `Maybe ProfilingHeader` just like we already have for tables next to code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 09:22:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 09:22:33 -0000 Subject: [GHC] #15725: Core Lint error: Trans coercion mis-match In-Reply-To: <050.b669cdd6d53ebfbfb35ff1834b5bd9f3@haskell.org> References: <050.b669cdd6d53ebfbfb35ff1834b5bd9f3@haskell.org> Message-ID: <065.aa9dce7a5c395d784a55b8ab55344a23@haskell.org> #15725: Core Lint error: Trans coercion mis-match -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15703 | Differential Rev(s): Phab:D5217 Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): If this helps, I reduced to {{{ #!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind (Type) newtype Identity a = Identity a newtype Par1 a = Par1 a data family Sing :: forall k. k -> Type data instance Sing :: forall k. k -> Type type family Rep1 (f :: Type -> Type) :: Type -> Type type instance Rep1 Identity = Par1 type family From1 (z :: f a) :: Rep1 f a type instance From1 ('Identity x) = 'Par1 x und :: a und = und f :: forall (a :: Type) (x :: Identity a). Sing x f = g where g :: forall (a :: Type) (f :: Type -> Type) (x :: f a). Sing x g = seq (und :: Sing (From1 x)) und }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 09:39:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 09:39:33 -0000 Subject: [GHC] #10783: Partial type signatures should work in pattern synonym signatures In-Reply-To: <049.9210bbc1c425a4fe689a15bfe5ab9550@haskell.org> References: <049.9210bbc1c425a4fe689a15bfe5ab9550@haskell.org> Message-ID: <064.4286ec47cb7fb9f2a13be81d1e64a535@haskell.org> #10783: Partial type signatures should work in pattern synonym signatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternSynonyms partial-type- | signatures Operating System: 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): * owner: mpickering => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 09:39:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 09:39:44 -0000 Subject: [GHC] #11368: Pattern synonym name is mangled when patterns are non-exhaustive In-Reply-To: <051.8288963528e24dfd4127278f265607de@haskell.org> References: <051.8288963528e24dfd4127278f265607de@haskell.org> Message-ID: <066.d2f89cad835db9fe1496b119374afe51@haskell.org> #11368: Pattern synonym name is mangled when patterns are non-exhaustive ---------------------------------+--------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: PatternSynonyms Operating System: Linux | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #11367 | Differential Rev(s): Wiki Page: | ---------------------------------+--------------------------------------- Changes (by mpickering): * owner: mpickering => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 09:39:53 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 09:39:53 -0000 Subject: [GHC] #13128: Refactor AvailInfo to be more sensible In-Reply-To: <049.bc2f7a9276b82f96ff767e83d3db4bb5@haskell.org> References: <049.bc2f7a9276b82f96ff767e83d3db4bb5@haskell.org> Message-ID: <064.f61d104d4059bd9625a460994927671a@haskell.org> #13128: Refactor AvailInfo to be more sensible -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 12662 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: mpickering => (none) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 12:39:41 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 12:39:41 -0000 Subject: [GHC] #15734: ghc-heap package is not on hackage In-Reply-To: <049.300f57126ce3ad632ecc7d07ef48ea17@haskell.org> References: <049.300f57126ce3ad632ecc7d07ef48ea17@haskell.org> Message-ID: <064.b46416665c3d9f191f8454069feecbd4@haskell.org> #15734: ghc-heap package is not on hackage -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: upstream Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: hvr (added) * status: new => upstream Comment: hvr notes [https://github.com/haskell-infra/hackage-trustees/issues/179 here] that `ghc-heap` can't be uploaded to Hackage at the moment due to a `Cabal` bug. (hvr can provide more details then I can.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 14:31:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 14:31:20 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.b808909d3da175e7726a59ab5943b8cb@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): > In the process of writing the paper, I repeatedly had to double-check what the transformation does and that it actually does the right thing. For example, thinking about how to formulate the function computing closure growth resulting from a lifting decision lead me to realise that we in fact could make better use of strictness in addition to usage (i.e. one-shot) information Great. So did you update the impl to take advantage of these new insights? I'll look forwards to the patch. An up to date nofib comparison would be good. And please yell when you are ready for me to take a proper sweep through the paper. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 14:49:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 14:49:37 -0000 Subject: [GHC] #15725: Core Lint error: Trans coercion mis-match In-Reply-To: <050.b669cdd6d53ebfbfb35ff1834b5bd9f3@haskell.org> References: <050.b669cdd6d53ebfbfb35ff1834b5bd9f3@haskell.org> Message-ID: <065.6af13f4bafb5968fba0a305c2fe956c2@haskell.org> #15725: Core Lint error: Trans coercion mis-match -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15703 | Differential Rev(s): Phab:D5217 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Thanks for your tireless efforts to minimize these bugs, monoidal. They're very much appreciated. In this particular example, I think you might have minimized it too well! That's because that program trips up Core Lint even with the patch in Phab:D5217. In fact, I think this program has an entirely different bug from the one described in this ticket. Here is the Core Lint error for your program: {{{ *** Core Lint errors : in result of Simplifier *** Bug.hs:25:1: warning: [in body of lambda with binder x_a19R :: Identity a_a19Q] Kind application error in coercion ‘(Sing (D:R:Rep1Identity[0] _N) _N)_R’ Function kind = forall k. k -> * Arg kinds = [(Par1 a_a19Q, *), (From1 x_a19R, Rep1 Identity a_a19Q)] Fun: Par1 a_a19Q (From1 x_a19R, Rep1 Identity a_a19Q) Bug.hs:25:1: warning: [in body of lambda with binder x_a19R :: Identity a_a19Q] Kind application error in coercion ‘D:R:Singk0[0] _N _N’ Function kind = Par1 a_a19Q -> * Arg kinds = [(From1 x_a19R, Rep1 Identity a_a19Q)] Fun: Par1 a_a19Q (From1 x_a19R, Rep1 Identity a_a19Q) Bug.hs:25:1: warning: [in body of lambda with binder x_a19R :: Identity a_a19Q] Kind application error in coercion ‘D:R:Singk0[0] _N _N’ Function kind = Par1 a_a19Q -> * Arg kinds = [(From1 x_a19R, Rep1 Identity a_a19Q)] Fun: Par1 a_a19Q (From1 x_a19R, Rep1 Identity a_a19Q) : warning: In the type ‘R:Singk (Par1 a_a19Q) (From1 x_a19R)’ Kind application error in type ‘R:Singk (Par1 a_a19Q) (From1 x_a19R)’ Function kind = forall k -> k -> * Arg kinds = [(Par1 a_a19Q, *), (From1 x_a19R, Rep1 Identity a_a19Q)] Fun: Par1 a_a19Q (From1 x_a19R, Rep1 Identity a_a19Q) : warning: In the type ‘R:Singk (Par1 a_a19Q) (From1 x_a19R)’ Kind application error in type ‘R:Singk (Par1 a_a19Q) (From1 x_a19R)’ Function kind = forall k -> k -> * Arg kinds = [(Par1 a_a19Q, *), (From1 x_a19R, Rep1 Identity a_a19Q)] Fun: Par1 a_a19Q (From1 x_a19R, Rep1 Identity a_a19Q) }}} My suspicion is that this program suffers from the same problems that afflict the program in #15549, since (1) the errors look very similar, and (2) `seq` is being used here, and I identified the `improveSeq` function as being responsible for an incorrect optimization in #15549. I'll put this program over in that ticket as another test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 14:50:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 14:50: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.2c7934de4d045d4197720974ba9181c9@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: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Another program, identified in https://ghc.haskell.org/trac/ghc/ticket/15725#comment:7, which may suffer from the same problems as described in this ticket: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind (Type) newtype Identity a = Identity a newtype Par1 a = Par1 a data family Sing :: forall k. k -> Type data instance Sing :: forall k. k -> Type type family Rep1 (f :: Type -> Type) :: Type -> Type type instance Rep1 Identity = Par1 type family From1 (z :: f a) :: Rep1 f a type instance From1 ('Identity x) = 'Par1 x und :: a und = und f :: forall (a :: Type) (x :: Identity a). Sing x f = g where g :: forall (a :: Type) (f :: Type -> Type) (x :: f a). Sing x g = seq (und :: Sing (From1 x)) und }}} {{{ *** Core Lint errors : in result of Simplifier *** Bug.hs:25:1: warning: [in body of lambda with binder x_a19R :: Identity a_a19Q] Kind application error in coercion ‘(Sing (D:R:Rep1Identity[0] _N) _N)_R’ Function kind = forall k. k -> * Arg kinds = [(Par1 a_a19Q, *), (From1 x_a19R, Rep1 Identity a_a19Q)] Fun: Par1 a_a19Q (From1 x_a19R, Rep1 Identity a_a19Q) Bug.hs:25:1: warning: [in body of lambda with binder x_a19R :: Identity a_a19Q] Kind application error in coercion ‘D:R:Singk0[0] _N _N’ Function kind = Par1 a_a19Q -> * Arg kinds = [(From1 x_a19R, Rep1 Identity a_a19Q)] Fun: Par1 a_a19Q (From1 x_a19R, Rep1 Identity a_a19Q) Bug.hs:25:1: warning: [in body of lambda with binder x_a19R :: Identity a_a19Q] Kind application error in coercion ‘D:R:Singk0[0] _N _N’ Function kind = Par1 a_a19Q -> * Arg kinds = [(From1 x_a19R, Rep1 Identity a_a19Q)] Fun: Par1 a_a19Q (From1 x_a19R, Rep1 Identity a_a19Q) : warning: In the type ‘R:Singk (Par1 a_a19Q) (From1 x_a19R)’ Kind application error in type ‘R:Singk (Par1 a_a19Q) (From1 x_a19R)’ Function kind = forall k -> k -> * Arg kinds = [(Par1 a_a19Q, *), (From1 x_a19R, Rep1 Identity a_a19Q)] Fun: Par1 a_a19Q (From1 x_a19R, Rep1 Identity a_a19Q) : warning: In the type ‘R:Singk (Par1 a_a19Q) (From1 x_a19R)’ Kind application error in type ‘R:Singk (Par1 a_a19Q) (From1 x_a19R)’ Function kind = forall k -> k -> * Arg kinds = [(Par1 a_a19Q, *), (From1 x_a19R, Rep1 Identity a_a19Q)] Fun: Par1 a_a19Q (From1 x_a19R, Rep1 Identity a_a19Q) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 15:35:19 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 15:35:19 -0000 Subject: [GHC] #15732: getArgsWithResponseFiles does not filter out RTS options In-Reply-To: <048.b4d2648ba00dd69525e93686e30914e8@haskell.org> References: <048.b4d2648ba00dd69525e93686e30914e8@haskell.org> Message-ID: <063.dc7085d7d7874faf0d8a4243ee771161@haskell.org> #15732: getArgsWithResponseFiles does not filter out RTS options -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: libraries/base | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #13896 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ckoparkar): There's a bigger problem here wrt setting RTS flags via a file. In the current implementation, {{{getArgsWithResponseFiles}}} is responsible for for reading any command-line arguments passed via a file. It iterates over the list returned by {{{getArgs}}}, and issues {{{readFile}}}'s for appropriate elements (the ones that start with '@'). This means that the RTS never sees any of the flags contained in these files. This is fine for regular command-line arguments -- those which are used by a program, not GHC. But if a file contains any RTS flags ({{{+RTS ... -RTS}}}) they're completely ignored since {{{getArgsWithResponseFiles}}} doesn't know what to do with them. But these flags are indeed special, and we want the RTS to know about them. I can think of two ways to fix this: (1) Properly support response files Like all the other arguments, the RTS would also process response files (read, check errors etc.). It can then do the right thing for the flags contained in these files. We'd also like the main GHC executable to support response files (see #15072). (2) Ignore the {{{+RTS ... -RTS}}} flags contained in a response file Such flags won't have any effect on the RTS. {{{getArgsWithResponseFiles}}} would just filter these out from it's return value. Option (2) is very easy to implement but I don't feel like it's the right thing to do. I can imagine this causing confusion and further problems. On the other hand, (1) is a big change which might affect things included in the Haskell Report. If we decide to go with option (1), I'd be happy to give it a shot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 15:39:23 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 15:39:23 -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.92793d0dbdd0dab0c94e76ce726e3c7e@haskell.org> #15072: Teach the testsuite driver about response files -------------------------------------+------------------------------------- Reporter: bgamari | Owner: ckoparkar 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: 15732 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ckoparkar): * blockedby: => 15732 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 16:13:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 16:13:24 -0000 Subject: [GHC] #15703: Significant compilation time blowup when refactoring singletons-heavy code In-Reply-To: <050.85b00ed8f7678528686f0902895081dc@haskell.org> References: <050.85b00ed8f7678528686f0902895081dc@haskell.org> Message-ID: <065.c4cd573a368e65d90eda3e1a72c81e8e@haskell.org> #15703: Significant compilation time blowup when refactoring singletons-heavy code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #15725 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): After some digging, I've found the commit that made compiling this program become so much faster. It's commit 55a3f8552c9dc9b84e204ec6623c698912795347 (`Refactor coercion rule`). In the commit prior, it took this long to build: {{{ $ time ~/Software/ghc2/inplace/bin/ghc-stage2 -O1 -fforce-recomp Lib.hs [1 of 2] Compiling Lib2 ( Lib2.hs, Lib2.o ) [2 of 2] Compiling Lib ( Lib.hs, Lib.o ) real 3m17.647s user 3m17.776s sys 0m0.168s }}} But if I apply that commit, it then takes this long to build: {{{ $ time ~/Software/ghc2/inplace/bin/ghc-stage2 -O1 -fforce-recomp Lib.hs [1 of 2] Compiling Lib2 ( Lib2.hs, Lib2.o ) [2 of 2] Compiling Lib ( Lib.hs, Lib.o ) real 0m26.102s user 0m26.032s sys 0m0.108s }}} This is quite a humorous coincidence, since up to this point I had been under the impression that that commit had made compilation performance slightly //worse// overall. But this shows I was completely wrong! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 17:19:58 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 17:19:58 -0000 Subject: [GHC] #11719: Cannot use higher-rank kinds with type families In-Reply-To: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> References: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> Message-ID: <062.03a44cce23f50fdd74db79f6ac889fd8@haskell.org> #11719: Cannot use higher-rank kinds with type families -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | dependent/should_compile/T11719 Blocked By: | Blocking: Related Tickets: #13913 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Is this another consequence of this limitation? Consider the following program: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Kind type family Sing :: k -> Type data SBool :: Bool -> Type where SFalse :: SBool False STrue :: SBool True type instance Sing = SBool sFalse :: Sing False sFalse = SFalse }}} This typechecks without issue. However, if you change the following line of code: {{{#!hs type family Sing :: k -> Type }}} To become this: {{{#!hs type family Sing :: forall k. k -> Type }}} Then it stops typechecking: {{{ $ /opt/ghc/8.6.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:18:10: error: • Couldn't match type ‘SBool’ with ‘Sing’ Expected type: Sing 'False Actual type: SBool 'False • In the expression: SFalse In an equation for ‘sFalse’: sFalse = SFalse | 18 | sFalse = SFalse | ^^^^^^ }}} I find this extremely surprising: I would have thought that GHC could treat `type family Sing :: k -> Type` and `type family Sing :: forall k. k -> Type` identically without the need for any fancy higher-rank business (like what the original program in this ticket requires). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 19:10:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 19:10:22 -0000 Subject: [GHC] #11719: Cannot use higher-rank kinds with type families In-Reply-To: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> References: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> Message-ID: <062.b38baf624f54e9ced453a7f2d2000224@haskell.org> #11719: Cannot use higher-rank kinds with type families -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | dependent/should_compile/T11719 Blocked By: | Blocking: Related Tickets: #13913 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): These two declarations have quite different meanings: {{{#!hs type family F1 :: k -> Type type family F2 :: forall k. k -> Type }}} `F1` takes one argument, `k`. `F2`, on the other hand, takes no arguments. `F1` can match on `k`, returning constructors of different kinds in different instances. On the other hand, `F2` must return a polykinded constructor, and can have only one instance. So, I think this is unrelated to the ticket... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 19:16:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 19:16:44 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.3918ec3b1cdc4d9fe0c5749b61bff597@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): Simon, you said that we can remove `can_fail=True` for `dataToTag#` after removing various hacks (in comment:60), and I also used to think that this should be the case, but thinking about this more I think `dataToTag#` should stay as `can_fail=True`. The reason is because `dataToTag#` evaluates the argument and returns an unboxed value, so I think these two expressions calls should have the same value: {{{ exprOkForSpeculation `dataToTag# foo` exprOkForSpeculation `case foo of x -> 1#` -- note: foo is lifted }}} Looking at the code I see that the latter returns `False` (because the scrutinee is lifted), so for the former to return false we need to mark `dataToTag#` as `can_fail = True`. Does this make sense? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 19:19:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 19:19:10 -0000 Subject: [GHC] #11719: Cannot use higher-rank kinds with type families In-Reply-To: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> References: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> Message-ID: <062.f1dfe2dc9868ab7a7718f7833ec0ee11@haskell.org> #11719: Cannot use higher-rank kinds with type families -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | dependent/should_compile/T11719 Blocked By: | Blocking: Related Tickets: #13913 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:14 goldfire]: > On the other hand, `F2` must return a polykinded constructor, and can have only one instance. That doesn't appear to be true, since this program (with multiple `F2` instances) typechecks: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Kind type family F2 :: forall k. k -> Type type instance F2 = SBool type instance F2 = STuple0 data SBool :: Bool -> Type where SFalse :: SBool False STrue :: SBool True data STuple0 :: () -> Type where STuple0 :: STuple0 '() }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 19:46:21 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 19:46:21 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow Message-ID: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof | recomp007 space_leak_001 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In case it helps, I ran a `./validate --slow` on HEAD on Ubuntu Bionic with 8.6.1. I don't attach much weight to the performance / stat failures as the tests seem to run in parallel. I'll pull out more specific diagnostics, if necessary. `` ==== STAGE 1 TESTS ==== SUMMARY for test run started at Wed Oct 10 20:29:33 2018 BST 0:00:04 spent to go through 2 total tests, which gave rise to 10 test cases, of which 0 were skipped 0 had missing libraries 10 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 0 unexpected failures 0 unexpected stat failures ==== STAGE 2 TESTS ==== Unexpected results from: TEST="EtaExpandLevPoly T14936 T15349 T2783 T4334 T7919 haddock.Cabal haddock.base haddock.compiler hpc_fork plugin-recomp-change plugin-recomp- change-prof recomp007 space_leak_001" SUMMARY for test run started at Wed Oct 10 19:31:20 2018 BST 0:58:10 spent to go through 6596 total tests, which gave rise to 29689 test cases, of which 5881 were skipped 256 had missing libraries 23273 expected passes 257 expected failures 0 caused framework failures 0 caused framework warnings 3 unexpected passes 6 unexpected failures 13 unexpected stat failures Unexpected passes: /tmp/ghctest-kyex1v3_/test spaces/rts/T2783.run T2783 [unexpected] (threaded1) /tmp/ghctest-kyex1v3_/test spaces/typecheck/should_run/EtaExpandLevPoly.run EtaExpandLevPoly [unexpected] (profasm) /tmp/ghctest-kyex1v3_/test spaces/typecheck/should_run/EtaExpandLevPoly.run EtaExpandLevPoly [unexpected] (profthreaded) Unexpected failures: /tmp/ghctest-kyex1v3_/test spaces/driver/recomp007/recomp007.run recomp007 [bad stderr] (normal) /tmp/ghctest-kyex1v3_/test spaces/plugins/plugin-recomp-change.run plugin-recomp-change [bad stderr] (normal) /tmp/ghctest-kyex1v3_/test spaces/plugins/plugin-recomp-change- prof.run plugin-recomp-change-prof [bad stderr] (normal) /tmp/ghctest-kyex1v3_/test spaces/rts/T7919.run T7919 [bad exit code] (ghci) /tmp/ghctest-kyex1v3_/test spaces/libraries/hpc/tests/fork/hpc_fork.run hpc_fork [bad heap profile] (profasm) /tmp/ghctest-kyex1v3_/test spaces/libraries/base/tests/T15349.run T15349 [bad exit code] (ghci) Unexpected stat failures: /tmp/ghctest-kyex1v3_/test spaces/perf/haddock/haddock.base.run haddock.base [stat not good enough] (normal) /tmp/ghctest-kyex1v3_/test spaces/perf/haddock/haddock.Cabal.run haddock.Cabal [stat not good enough] (normal) /tmp/ghctest-kyex1v3_/test spaces/perf/haddock/haddock.compiler.run haddock.compiler [stat not good enough] (normal) /tmp/ghctest-kyex1v3_/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (hpc) /tmp/ghctest-kyex1v3_/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (profasm) /tmp/ghctest-kyex1v3_/test spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (hpc) /tmp/ghctest-kyex1v3_/test spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (optasm) /tmp/ghctest-kyex1v3_/test spaces/perf/space_leaks/T4334.run T4334 [stat not good enough] (threaded2) /tmp/ghctest-kyex1v3_/test spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (dyn) /tmp/ghctest-kyex1v3_/test spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (optllvm) /tmp/ghctest-kyex1v3_/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (threaded1) /tmp/ghctest-kyex1v3_/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (threaded2) /tmp/ghctest-kyex1v3_/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (profthreaded) == Start post-testsuite package check GHC package manager version 8.7.20181010 Timestamp 2018-10-10 18:31:15.21573855 UTC for /home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181010/package.conf.d/package.cache using cache: /home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181010/package.conf.d/package.cache db stack: ["/home/jrp/.ghc/x86_64-linux-8.7.20181010/package.conf.d","/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181010/package.conf.d"] flag db stack: ["/home/jrp/.ghc/x86_64-linux-8.7.20181010/package.conf.d","/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181010/package.conf.d"] == End post-testsuite package check ------------------------------------------------------------------- Oops! Looks like you have some unexpected test results or framework failures. Please fix them before pushing/sending patches. ------------------------------------------------------------------- `` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 19:47:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 19:47:51 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.a29317598fe6aa3e29a726fb3d19fa85@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by simonpj): It's tricky, I agree; and I agree that's the result that `exprOkForSpeculation` should return False in these cases. But as I say in item (6) of comment:60, `app_ok` already has a special case for `SeqOp` for this very reason, and I think we should just extend that to `DataToTagOp`. In fact I got as far as writing the Note to accompany the change to `app_ok`: {{{ Note [PrimOps that evaluate their arguments] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Most primops to not evaluate their arguments, even lifted arguments. But two do: DataToTagOp and SeqOp (rembember the latter is monadic; it is not the primop corresponding to 'seq'). Now, is (dataToTag# x) ok-for-speculation? You might say "yes, if x is ok-for-speculation", because then it'll obey the rules for ok-for-speculation. But it's very fragile. Consider: \z. case x of y { DEFAULT -> let v = dataToTag# y in ... } This looks OK: we ask if 'y' is ok-for-spec, and say yes because it is evaluated. But if we do the binder-swap operation (which happens in FloatOut) we have \z. case x of y { DEFAULT -> let v = dataToTag# x in ... } and now it is /not/ ok-for-spec. This becomes even clearer if we float it to give let v = dataToTag# x in \z. case x of y { DEFAULT -> ... } Conclusion: always return False for ok-to-spec on SeqOp and DataToTagOp. }}} Does that makes sense? The can-fail thing is a hack, and we don't do it for `SeqOp`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 20:00:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 20:00:07 -0000 Subject: [GHC] #11719: Cannot use higher-rank kinds with type families In-Reply-To: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> References: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> Message-ID: <062.287e8403783572dbf7497ae3330e9641@haskell.org> #11719: Cannot use higher-rank kinds with type families -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | dependent/should_compile/T11719 Blocked By: | Blocking: Related Tickets: #13913 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): It on HEAD but fails on 8.2.1 (after adding `{-# LANGUAGE TypeInType #-}`) {{{ $ ghci -ignore-dot-ghci 504.hs GHCi, version 8.2.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Bug ( 504.hs, interpreted ) 504.hs:12:20: error: • Expected kind ‘forall k. k -> *’, but ‘SBool’ has kind ‘Bool -> *’ • In the type ‘SBool’ In the type instance declaration for ‘F2’ | 12 | type instance F2 = SBool | ^^^^^ 504.hs:13:20: error: • Expected kind ‘forall k. k -> *’, but ‘STuple0’ has kind ‘() -> *’ • In the type ‘STuple0’ In the type instance declaration for ‘F2’ | 13 | type instance F2 = STuple0 | ^^^^^^^ Failed, 0 modules loaded. Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 10 20:00:11 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Oct 2018 20:00:11 -0000 Subject: [GHC] #15737: Implement sconcat Semigroup Instances for Tuples Message-ID: <049.439142afc8fc476a69684a04f0fcdb7d@haskell.org> #15737: Implement sconcat Semigroup Instances for Tuples -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For some semigroups, the user-defined `sconcat` performs asymptotically better than the default. The semigroup instances for tuples should create a list of each component individually, use `sconcat` for the underlying type, and then zip the tuples back together. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 07:41:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 07:41:21 -0000 Subject: [GHC] #11719: Cannot use higher-rank kinds with type families In-Reply-To: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> References: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> Message-ID: <062.e1309dba6a63ae18622d5e2ca8da34bd@haskell.org> #11719: Cannot use higher-rank kinds with type families -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | dependent/should_compile/T11719 Blocked By: | Blocking: Related Tickets: #13913 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): Replying to [comment:14 goldfire]: > These two declarations have quite different meanings: > > {{{#!hs > type family F1 :: k -> Type > type family F2 :: forall k. k -> Type > }}} > This statement doesn't sit well with me. I expect to be able to introduce any type variable explicitly, and `F1` with an explicit `forall` for `k` turns out to be `F2`. These declarations ''must'' have the same meaning. Let's compare to term-level functions: {{{#!hs f :: k -> Type f :: forall k. k -> Type }}} These types are the same (modulo specificity of `k`)! > `F1` takes one argument, `k`. `F2`, on the other hand, takes no arguments. `F1` can match on `k`, returning constructors of different kinds in different instances. On the other hand, `F2` must return a polykinded constructor, and can have only one instance. So you mean that we treat `F1` as having kind `pi k. k -> Type`, while `F2` has kind `forall k. k -> Type`: `F1` can match on its parameter `k` and `F2` cannot. Why? I thought we always treat `forall` as `pi` in kinds, at least for now. Therefore, I agree with Ryan's expectations in comment:13. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 07:41:38 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 07:41:38 -0000 Subject: [GHC] #11719: Cannot use higher-rank kinds with type families In-Reply-To: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> References: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> Message-ID: <062.45444e405f15d0602e382b3282a4880a@haskell.org> #11719: Cannot use higher-rank kinds with type families -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | dependent/should_compile/T11719 Blocked By: | Blocking: Related Tickets: #13913 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: int-index (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 09:15:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 09:15:16 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow In-Reply-To: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> References: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> Message-ID: <057.cbe941c801e944ca5464c19dc799670d@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof recomp007 | space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) Old description: > In case it helps, I ran a `./validate --slow` on HEAD on Ubuntu Bionic > with 8.6.1. I don't attach much weight to the performance / stat > failures as the tests seem to run in parallel. I'll pull out more > specific diagnostics, if necessary. > `` > ==== STAGE 1 TESTS ==== > > SUMMARY for test run started at Wed Oct 10 20:29:33 2018 BST > 0:00:04 spent to go through > 2 total tests, which gave rise to > 10 test cases, of which > 0 were skipped > > 0 had missing libraries > 10 expected passes > 0 expected failures > > 0 caused framework failures > 0 caused framework warnings > 0 unexpected passes > 0 unexpected failures > 0 unexpected stat failures > > ==== STAGE 2 TESTS ==== > > Unexpected results from: > TEST="EtaExpandLevPoly T14936 T15349 T2783 T4334 T7919 haddock.Cabal > haddock.base haddock.compiler hpc_fork plugin-recomp-change plugin- > recomp-change-prof recomp007 space_leak_001" > > SUMMARY for test run started at Wed Oct 10 19:31:20 2018 BST > 0:58:10 spent to go through > 6596 total tests, which gave rise to > 29689 test cases, of which > 5881 were skipped > > 256 had missing libraries > 23273 expected passes > 257 expected failures > > 0 caused framework failures > 0 caused framework warnings > 3 unexpected passes > 6 unexpected failures > 13 unexpected stat failures > > Unexpected passes: > /tmp/ghctest-kyex1v3_/test spaces/rts/T2783.run > T2783 [unexpected] (threaded1) > /tmp/ghctest-kyex1v3_/test > spaces/typecheck/should_run/EtaExpandLevPoly.run EtaExpandLevPoly > [unexpected] (profasm) > /tmp/ghctest-kyex1v3_/test > spaces/typecheck/should_run/EtaExpandLevPoly.run EtaExpandLevPoly > [unexpected] (profthreaded) > > Unexpected failures: > /tmp/ghctest-kyex1v3_/test spaces/driver/recomp007/recomp007.run > recomp007 [bad stderr] (normal) > /tmp/ghctest-kyex1v3_/test spaces/plugins/plugin-recomp-change.run > plugin-recomp-change [bad stderr] (normal) > /tmp/ghctest-kyex1v3_/test spaces/plugins/plugin-recomp-change- > prof.run plugin-recomp-change-prof [bad stderr] (normal) > /tmp/ghctest-kyex1v3_/test spaces/rts/T7919.run > T7919 [bad exit code] (ghci) > /tmp/ghctest-kyex1v3_/test > spaces/libraries/hpc/tests/fork/hpc_fork.run hpc_fork [bad heap profile] > (profasm) > /tmp/ghctest-kyex1v3_/test spaces/libraries/base/tests/T15349.run > T15349 [bad exit code] (ghci) > > Unexpected stat failures: > /tmp/ghctest-kyex1v3_/test spaces/perf/haddock/haddock.base.run > haddock.base [stat not good enough] (normal) > /tmp/ghctest-kyex1v3_/test spaces/perf/haddock/haddock.Cabal.run > haddock.Cabal [stat not good enough] (normal) > /tmp/ghctest-kyex1v3_/test spaces/perf/haddock/haddock.compiler.run > haddock.compiler [stat not good enough] (normal) > /tmp/ghctest-kyex1v3_/test spaces/perf/should_run/T14936.run > T14936 [stat not good enough] (hpc) > /tmp/ghctest-kyex1v3_/test spaces/perf/should_run/T14936.run > T14936 [stat not good enough] (profasm) > /tmp/ghctest-kyex1v3_/test > spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too > good] (hpc) > /tmp/ghctest-kyex1v3_/test > spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too > good] (optasm) > /tmp/ghctest-kyex1v3_/test spaces/perf/space_leaks/T4334.run > T4334 [stat not good enough] (threaded2) > /tmp/ghctest-kyex1v3_/test > spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too > good] (dyn) > /tmp/ghctest-kyex1v3_/test > spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too > good] (optllvm) > /tmp/ghctest-kyex1v3_/test spaces/perf/should_run/T14936.run > T14936 [stat not good enough] (threaded1) > /tmp/ghctest-kyex1v3_/test spaces/perf/should_run/T14936.run > T14936 [stat not good enough] (threaded2) > /tmp/ghctest-kyex1v3_/test spaces/perf/should_run/T14936.run > T14936 [stat not good enough] (profthreaded) > > == Start post-testsuite package check > GHC package manager version 8.7.20181010 > Timestamp 2018-10-10 18:31:15.21573855 UTC for > /home/jrp/Projects/ghc/bindisttest/install > dir/lib/ghc-8.7.20181010/package.conf.d/package.cache > using cache: /home/jrp/Projects/ghc/bindisttest/install > dir/lib/ghc-8.7.20181010/package.conf.d/package.cache > db stack: > ["/home/jrp/.ghc/x86_64-linux-8.7.20181010/package.conf.d","/home/jrp/Projects/ghc/bindisttest/install > dir/lib/ghc-8.7.20181010/package.conf.d"] > flag db stack: > ["/home/jrp/.ghc/x86_64-linux-8.7.20181010/package.conf.d","/home/jrp/Projects/ghc/bindisttest/install > dir/lib/ghc-8.7.20181010/package.conf.d"] > == End post-testsuite package check > ------------------------------------------------------------------- > Oops! Looks like you have some unexpected test results or framework > failures. > Please fix them before pushing/sending patches. > ------------------------------------------------------------------- > `` New description: In case it helps, I ran a `./validate --slow` on HEAD on Ubuntu Bionic with 8.6.1. I don't attach much weight to the performance / stat failures as the tests seem to run in parallel. I'll pull out more specific diagnostics, if necessary. {{{ ==== STAGE 1 TESTS ==== SUMMARY for test run started at Wed Oct 10 20:29:33 2018 BST 0:00:04 spent to go through 2 total tests, which gave rise to 10 test cases, of which 0 were skipped 0 had missing libraries 10 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 0 unexpected failures 0 unexpected stat failures ==== STAGE 2 TESTS ==== Unexpected results from: TEST="EtaExpandLevPoly T14936 T15349 T2783 T4334 T7919 haddock.Cabal haddock.base haddock.compiler hpc_fork plugin-recomp-change plugin-recomp- change-prof recomp007 space_leak_001" SUMMARY for test run started at Wed Oct 10 19:31:20 2018 BST 0:58:10 spent to go through 6596 total tests, which gave rise to 29689 test cases, of which 5881 were skipped 256 had missing libraries 23273 expected passes 257 expected failures 0 caused framework failures 0 caused framework warnings 3 unexpected passes 6 unexpected failures 13 unexpected stat failures Unexpected passes: /tmp/ghctest-kyex1v3_/test spaces/rts/T2783.run T2783 [unexpected] (threaded1) /tmp/ghctest-kyex1v3_/test spaces/typecheck/should_run/EtaExpandLevPoly.run EtaExpandLevPoly [unexpected] (profasm) /tmp/ghctest-kyex1v3_/test spaces/typecheck/should_run/EtaExpandLevPoly.run EtaExpandLevPoly [unexpected] (profthreaded) Unexpected failures: /tmp/ghctest-kyex1v3_/test spaces/driver/recomp007/recomp007.run recomp007 [bad stderr] (normal) /tmp/ghctest-kyex1v3_/test spaces/plugins/plugin-recomp-change.run plugin-recomp-change [bad stderr] (normal) /tmp/ghctest-kyex1v3_/test spaces/plugins/plugin-recomp-change- prof.run plugin-recomp-change-prof [bad stderr] (normal) /tmp/ghctest-kyex1v3_/test spaces/rts/T7919.run T7919 [bad exit code] (ghci) /tmp/ghctest-kyex1v3_/test spaces/libraries/hpc/tests/fork/hpc_fork.run hpc_fork [bad heap profile] (profasm) /tmp/ghctest-kyex1v3_/test spaces/libraries/base/tests/T15349.run T15349 [bad exit code] (ghci) Unexpected stat failures: /tmp/ghctest-kyex1v3_/test spaces/perf/haddock/haddock.base.run haddock.base [stat not good enough] (normal) /tmp/ghctest-kyex1v3_/test spaces/perf/haddock/haddock.Cabal.run haddock.Cabal [stat not good enough] (normal) /tmp/ghctest-kyex1v3_/test spaces/perf/haddock/haddock.compiler.run haddock.compiler [stat not good enough] (normal) /tmp/ghctest-kyex1v3_/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (hpc) /tmp/ghctest-kyex1v3_/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (profasm) /tmp/ghctest-kyex1v3_/test spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (hpc) /tmp/ghctest-kyex1v3_/test spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (optasm) /tmp/ghctest-kyex1v3_/test spaces/perf/space_leaks/T4334.run T4334 [stat not good enough] (threaded2) /tmp/ghctest-kyex1v3_/test spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (dyn) /tmp/ghctest-kyex1v3_/test spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (optllvm) /tmp/ghctest-kyex1v3_/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (threaded1) /tmp/ghctest-kyex1v3_/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (threaded2) /tmp/ghctest-kyex1v3_/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (profthreaded) == Start post-testsuite package check GHC package manager version 8.7.20181010 Timestamp 2018-10-10 18:31:15.21573855 UTC for /home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181010/package.conf.d/package.cache using cache: /home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181010/package.conf.d/package.cache db stack: ["/home/jrp/.ghc/x86_64-linux-8.7.20181010/package.conf.d","/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181010/package.conf.d"] flag db stack: ["/home/jrp/.ghc/x86_64-linux-8.7.20181010/package.conf.d","/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181010/package.conf.d"] == End post-testsuite package check ------------------------------------------------------------------- Oops! Looks like you have some unexpected test results or framework failures. Please fix them before pushing/sending patches. ------------------------------------------------------------------- }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 10:15:06 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 10:15:06 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.1583fc836c2138a4d9e6835d83c073c5@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): OK, that makes sense, thanks. Moving on, I'm now trying to understand an assertion in `FloatIn` which is triggered when I make the `can_fail` change and update `ok_app` so that `dataToTag#` is never OK for speculation. The assertion that fails is this: (in FloatIn.hs) {{{ fiExpr _ to_drop (_, AnnLit lit) = ASSERT( null to_drop ) Lit lit }}} The definition that triggers it: {{{ $wclosureTypeHeaderSize_s75y [InlPrag=NOUSERINLINE[2]] :: ClosureType -> Int# [LclId, Arity=1, Str=] $wclosureTypeHeaderSize_s75y = \ (w_s75u :: ClosureType) -> case dataToTag# @ ClosureType w_s75u of a#_a4k2 [Dmd=] { __DEFAULT -> join { $j_s6vr [Dmd=] :: Int# [LclId[JoinId(0)], Str=m] $j_s6vr = case w_s75u of lwild_s6yB { __DEFAULT -> case a#_a4k2 of a#_a4jU [Dmd=] { __DEFAULT -> case w_s75u of lwild_s6yA { __DEFAULT -> case a#_a4k2 of a#_X4Ml [Dmd=] { __DEFAULT -> case w_s75u of lwild_s6vm { __DEFAULT -> case a#_a4k2 of a#_X4Mq [Dmd=] { __DEFAULT -> 1# }; AP_STACK -> 2# } }; AP -> 2# } }; THUNK_SELECTOR -> 2# } } in case <# a#_a4k2 15# of lwild_s6vx { __DEFAULT -> case a#_a4k2 of b#_a4k3 [Dmd=] { __DEFAULT -> case <# 20# a#_a4k2 of lwild_s6vu { __DEFAULT -> 2#; 1# -> jump $j_s6vr } }; 1# -> jump $j_s6vr } } }}} At one point `fiExpr` comes across this expression: {{{ case a#_a4k2 :: Int# of a#_X4Mq [Dmd=] { __DEFAULT -> 1# } }}} with an empty "to drop" list. At this point we try to float the case inside the alternative (happens in first `AnnCase` alternative of `fiExpr`), but body of the alternative is a literal so the assertion is triggered. Questions: - What's wrong with seeing a literal when floating stuff inwards? Why not just introduce case/let around it? - There should be some code somewhere that's supposed to ensure that this assertion is not triggered, but I can't find it. - Why did simplifier not remove this case expression? It does no work (the scrutinee is unlifted and binder is not used) but it's somehow not eliminated by the simplifier pass right before FloatIn. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 10:26:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 10:26:17 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.24612521b3b84be0dfb8974b792cff87@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by simonpj): > What's wrong with seeing a literal when floating stuff inwards? Why not just introduce case/let around it? Because the float-in pass floats bindings inwards ''towards their use sites''. If there is no use of the variable bound by a floating binding, then we should not be floating that binding into that part of the code. Literals are an extreme case. > There should be some code somewhere that's supposed to ensure that this assertion is not triggered, but I can't find it. It's `FloatIn.sepBindsByDropPoint`. > Why did simplifier not remove this case expression? That is indeed a mystery. Is the code you are showing the output of the simplifier? Can you give instructions to reproduce (maybe make a `wip/` branch)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 10:33:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 10:33:28 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.da3ab2788fbb202937e502ee954c24ba@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Another thing we need to figure out is how to update use sites of binders when we update CAFness info. For example, in the example in #15113: {{{ lvl2_r3y3 :: [Char] [GblId] lvl2_r3y3 = unpackCString# lvl1_r3y2 -- RHS size: {terms: 7, types: 6, coercions: 2, joins: 0/0} patError :: forall a. Addr# -> a [GblId, Arity=1, Str=x, Unf=OtherCon []] patError = \ (@ a_a2kh) (s_a1Pi :: Addr#) -> raise# @ SomeException @ 'LiftedRep @ a_a2kh (Control.Exception.Base.$fExceptionPatternMatchFail_$ctoException ((untangle s_a1Pi lvl2_r3y3) `cast` (Sym (Control.Exception.Base.N:PatternMatchFail[0]) :: (String :: *) ~R# (PatternMatchFail :: *)))) }}} We want to be able to make `lvl2_r3y3` re-entrant. When we do this `patError` won't have any CAF refs, but to actually realize this we need to update references to `lvl2_r3y3` to update the id info. Alternatively I think we could pass an environment of updated ids to `topStgBindHasCafRefs` and friends. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 11:23:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 11:23:57 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.80fcd773c66cd6e9d720c2346538bf03@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): > That is indeed a mystery. Is the code you are showing the output of the simplifier? The code I showed is the input of `FloatIn` when a file is compiled with `-O`. The full command to reproduce (after building stage 1): {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -this-unit-id ghc-heap-8.7 -hide-all-packages -i -ilibraries /ghc-heap/. -ilibraries/ghc-heap/dist-install/build -Ilibraries/ghc-heap /dist-install/build -ilibraries/ghc-heap/dist-install/build/./autogen -Ilibraries/ghc-heap/dist-install/build/./autogen -Ilibraries/ghc-heap/. -optP-include -optPlibraries/ghc-heap/dist- install/build/./autogen/cabal_macros.h -package-id base-4.12.0.0 -package- id ghc-prim-0.5.3 -package-id rts -Wall -XHaskell2010 -XNoImplicitPrelude -O -no-user-package-db -rtsopts -Wno-deprecated-flags -Wnoncanonical-monad-instances -odir libraries/ghc-heap/dist- install/build -hidir libraries/ghc-heap/dist-install/build -stubdir libraries/ghc-heap/dist-install/build -dynamic-too -c libraries/ghc- heap/./GHC/Exts/Heap/ClosureTypes.hs -o libraries/ghc-heap/dist- install/build/GHC/Exts/Heap/ClosureTypes.o -dyno libraries/ghc-heap/dist- install/build/GHC/Exts/Heap/ClosureTypes.dyn_o }}} > Can you give instructions to reproduce (maybe make a wip/ branch)? Committed code to `wip/T15696`. Note that -ddump-simpl-iterations is not printing Core right before `FloatIn` so you need some extra prints to be able to trace this. I'm currently using [https://gist.githubusercontent.com/osa1/9755f7d7238a3757cfee0b37a183a6d8/raw/7d28a30632cf9d39f85fa4630c040fed80c52036/gistfile1.txt this] patch for that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 13:47:25 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 13:47:25 -0000 Subject: [GHC] #15738: -ddump-splices omits required parentheses around quantified constraints Message-ID: <050.9a7d0a45c19a0231a6c34d5b7b0c0ffb@haskell.org> #15738: -ddump-splices omits required parentheses around quantified constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template | Version: 8.6.1 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 this program with `-ddump-splices`: {{{#!hs {-# LANGUAGE QuantifiedConstraints #-} {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Bug where import Language.Haskell.TH data Foo x = MkFoo x $([d| f :: (forall a. Eq (Foo a)) => Foo x -> Foo x -> Bool f = (==) |]) }}} You'll notice something fishy: {{{ $ /opt/ghc/8.6.1/bin/ghci Bug.hs GHCi, version 8.6.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:(10,3)-(12,6): Splicing declarations [d| f_a1Ia :: (forall a_a1Ic. Eq (Foo a_a1Ic)) => Foo x_a1Ib -> Foo x_a1Ib -> Bool f_a1Ia = (==) |] ======> f_a5tj :: forall a_a5tk. Eq (Foo a_a5tk) => Foo x_a5ti -> Foo x_a5ti -> Bool f_a5tj = (==) Ok, one module loaded. }}} The signature for `f` gets pretty-printed as: {{{#!hs f_a5tj :: forall a_a5tk. Eq (Foo a_a5tk) => Foo x_a5ti -> Foo x_a5ti -> Bool }}} Which is just plain wrong—there is a missing set of parentheses around the quantified constraint `forall a_a5tk. Eq (Foo a_a5tk)`. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 13:57:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 13:57:18 -0000 Subject: [GHC] #15738: -ddump-splices omits required parentheses around quantified constraints In-Reply-To: <050.9a7d0a45c19a0231a6c34d5b7b0c0ffb@haskell.org> References: <050.9a7d0a45c19a0231a6c34d5b7b0c0ffb@haskell.org> Message-ID: <065.e1699a80dcde6605671715bc74de482b@haskell.org> #15738: -ddump-splices omits required parentheses around quantified constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5222 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5222 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 14:43:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 14:43:18 -0000 Subject: [GHC] #15332: lintIdUnfolding could be simpler In-Reply-To: <049.a909e6dc2cdb6ebb060656336ed39a00@haskell.org> References: <049.a909e6dc2cdb6ebb060656336ed39a00@haskell.org> Message-ID: <064.ec49c21c55ff46addb56a02435b3566e@haskell.org> #15332: lintIdUnfolding could be simpler -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4919 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 14:46:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 14:46:01 -0000 Subject: [GHC] #13923: Add a suppression flag to stop Typeable bindings being emitted with -ddump-simpl In-Reply-To: <049.278c5e90a08d18618906c14fe1c23641@haskell.org> References: <049.278c5e90a08d18618906c14fe1c23641@haskell.org> Message-ID: <064.a0d2002c657796ffbd6cc7a6c4aa79ee@haskell.org> #13923: Add a suppression flag to stop Typeable bindings being emitted with -ddump- simpl -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 14:46:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 14:46:27 -0000 Subject: [GHC] #15603: ref6 example from StaticPointers documentation doesn't type check In-Reply-To: <049.2f1c9babf7c08f8cf0bfccd75c2c4869@haskell.org> References: <049.2f1c9babf7c08f8cf0bfccd75c2c4869@haskell.org> Message-ID: <064.75814589e21ee03ff31e587d178250f5@haskell.org> #15603: ref6 example from StaticPointers documentation doesn't type check -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | StaticPointers, newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: StaticPointers => StaticPointers, newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 15:30:38 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 15:30:38 -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.687b112b6741f88b38edcf74d4caed38@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 kavon): Dropping a recent paper on this topic that uses dynamic profiling, though there might be some adaptable ideas / further reading in here: https://arxiv.org/abs/1810.00905 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 15:49:14 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 15:49:14 -0000 Subject: [GHC] #15739: ghc-heap: code field never seems to be populated in StgInfoTable Message-ID: <049.bc36daf9ad15db6eeae1e65f651d6b5c@haskell.org> #15739: ghc-heap: code field never seems to be populated in StgInfoTable -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems that `peekItbl` doesn't populate the `code` field of `StgInfoTable`. https://github.com/ghc/ghc/blob/6bb9bc7d3c935dcb77e0700cce28de2c9df646df/libraries /ghc-heap/GHC/Exts/Heap/InfoTable.hsc#L52 If you look at `InfoTables.h`, when `TABLES_NEXT_TO_CODE`, it should be populated. https://github.com/ghc/ghc/blob/1c2c2d3dfd4c36884b22163872feb87122b4528d/includes/rts/storage/InfoTables.h#L200 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 17:00:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 17:00:18 -0000 Subject: [GHC] #15739: ghc-heap: code field never seems to be populated in StgInfoTable In-Reply-To: <049.bc36daf9ad15db6eeae1e65f651d6b5c@haskell.org> References: <049.bc36daf9ad15db6eeae1e65f651d6b5c@haskell.org> Message-ID: <064.54097095109518087c96289bf66f868b@haskell.org> #15739: ghc-heap: code field never seems to be populated in StgInfoTable -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Yes, I suppose this is true. I suspect the reason for this is that GHCi never needed this functionality. What do you intend on doing with it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 17:01:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 17:01:36 -0000 Subject: [GHC] #15737: Implement sconcat Semigroup Instances for Tuples In-Reply-To: <049.439142afc8fc476a69684a04f0fcdb7d@haskell.org> References: <049.439142afc8fc476a69684a04f0fcdb7d@haskell.org> Message-ID: <064.8d4cc65d6d43b95c39992ef27ae792e6@haskell.org> #15737: Implement sconcat Semigroup Instances for Tuples -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Do send a patch! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 17:09:57 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 17:09:57 -0000 Subject: [GHC] #15739: ghc-heap: code field never seems to be populated in StgInfoTable In-Reply-To: <049.bc36daf9ad15db6eeae1e65f651d6b5c@haskell.org> References: <049.bc36daf9ad15db6eeae1e65f651d6b5c@haskell.org> Message-ID: <064.e01a974830b9717a321a8f6344596719@haskell.org> #15739: ghc-heap: code field never seems to be populated in StgInfoTable -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): I just noticed whilst working on #15735. I don't have any plans for it but it could be confusing if someone just looks at the API. pokeItbl also seems to implement it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 18:02:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 18:02:49 -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.2bb3a1421f8cfefbd4f276593f2d2c96@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): Replying to [comment:10 kavon]: > Dropping a recent paper on this topic that uses dynamic profiling, though there might be some adaptable ideas / further reading in here: https://arxiv.org/abs/1810.00905 Cool idea! I don't know how much Haskell could would benefit comperatively here as I would assume info tables would get in the way of fall throughs between functions. But might still be worth doing eventually. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 18:39:38 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 18:39:38 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.80afade50aa34da3c0820e958a1d9b34@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by simonpj): I took a look 1. We should give `dataToTag#` a strictness signatures in `primops.txt.pp`. After all, it's strict. If we do that then, {{{ case x of y { DEFAULT -> daataToTag# y } }}} will correctly optimise to `dataToTag# x`. 2. We should remove the bang from `GHC.Base.getTag`. Currenlty it says {{{ getTag !x = dataToTag# x }}} But now the bang is unnecessary, and has to be optimised away by (1). 3. That's also the source of the extra stuff like {{{ case a#_a4k2 :: Int# of a#_X4Mq [Dmd=] { __DEFAULT -> ... } }}} which you report in comment:70. This is ''not'' the output of the simplifier; since that simplifier run we have done (a) exitification, (b) float-out and (c) CSE. The last of these left those redudant cases; they would, I believe, disappear in the next simplifier run (if only we reached it). But after (1) and (2) they won't even be there in the first place. 4. I see why the ASSERT trips. In the ''input'' to float-in we have {{{ case a#_a4k2 :: Int# of a#_X4Mq { __DEFAULT -> 1# } }}} So float-in picks up that case-expression and pushes it inwards. But it immediately hits the literal. The ASSERT wasn't expecting to have bindings that were ''dead'' in the input; but here is exactly such a binding, and there's nothign actually wrong with it. The same ASSERT failure would happen with {{{ let x = e in 1# }}} Of course the simplifer would usually eliminate such a thing, but there is no reason for float-in to require that. Just change {{{ fiExpr _ to_drop (_, AnnLit lit) = ASSERT( null to_drop ) Lit lit }}} to {{{ fiExpr _ to_drop (_, AnnLit lit) = wrapFloats to_drop (Lit lit) -- See Note [Dead bindings] {- Note dead bindings ~~~~~~~~~~~~~~~~~~~~~ At a literal we won't usually have any floated bindings; the only way that can happen is if the binding wrapped the literal /in the original input program/. e.g. case x of { DEFAULT -> 1# } But, while this may be unusual it is not actually wrong, and it did once happen (Trac #15696). }} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 20:45:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 20:45:55 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.a15d7bdebede1e18e5f9022e335f65f5@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): Thanks Simon, Re 1, the primop is already marked as strict: {{{ strictness = { \ _arity -> mkClosedStrictSig [evalDmd] topRes } }}} Re 2, I already removed the bang pattern in Phab:D5201. I think you need a git pull. Re 3, both (1) and (2) are already done so this should've worked? I'll implement 4 and update. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 21:10:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 21:10:29 -0000 Subject: [GHC] #15740: Type family with higher-rank result is too accepting Message-ID: <047.98bb6600d0afd0d0f5c82db2394db54f@haskell.org> #15740: Type family with higher-rank result is too accepting -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: TypeFamilies, | Operating System: Unknown/Multiple TypeInType | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC accepts this garbage: {{{ type family F2 :: forall k. k -> Type data SBool :: Bool -> Type data Nat data SNat :: Nat -> Type type instance F2 = SBool type instance F2 = SNat }}} The family `F2` should have an arity of 0, meaning that only one instance is possible -- and the RHS of that instance must have kind `forall k. k -> Type`. In other words, even accepting only one of the instances above is hogwash. This is from comment:15:ticket:11719, but you don't have to read that to understand this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 21:11:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 21:11:15 -0000 Subject: [GHC] #11719: Cannot use higher-rank kinds with type families In-Reply-To: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> References: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> Message-ID: <062.708e26674d3477d5a0cad8fc126dd47e@haskell.org> #11719: Cannot use higher-rank kinds with type families -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | dependent/should_compile/T11719 Blocked By: | Blocking: Related Tickets: #13913 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The difference with terms is that the arity of type families matters. `F1` has arity 1, while `F2` has arity 0. The real question is: where is the `k` bound. In `F1`, `k` is bound "before the colon", while in `F2`, it's bound after the colon. In terms of [https://github.com/goldfirere/ghc- proposals/blob/pi/proposals/0000-pi.rst#the-quantifier-table this syntax]: {{{ F1 :: foreach k . k -> Type F2 :: foreach k '. k -> Type }}} Both are really `foreach`-kinds, like @int-index observed. The difference is that `F1`'s argument is not matchable. (Perversely, type families can pattern-match only on unmatchable arguments. Perhaps a name change is in order.) On the other hand, `F2`'s argument is matchable, as it's declared to be so. (Recall that every abstraction in a kind is currently interpreted as matchable, even though the future syntax for matchable kinds will change.) Accepting the program in comment:15 seems like an egregious bug, to me. I've reported it as #15740. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 21:56:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 21:56:24 -0000 Subject: [GHC] #15703: Significant compilation time blowup when refactoring singletons-heavy code In-Reply-To: <050.85b00ed8f7678528686f0902895081dc@haskell.org> References: <050.85b00ed8f7678528686f0902895081dc@haskell.org> Message-ID: <065.7670767c5f1c6024da542e316f95f34c@haskell.org> #15703: Significant compilation time blowup when refactoring singletons-heavy code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #15725 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * cc: xnning (added) Comment: Ha! One of the motivations for that refactoring was increased performance, and we were befuddled why that goal didn't materialize. And now it has. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 22:15:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 22:15:27 -0000 Subject: [GHC] #15740: Type family with higher-rank result is too accepting In-Reply-To: <047.98bb6600d0afd0d0f5c82db2394db54f@haskell.org> References: <047.98bb6600d0afd0d0f5c82db2394db54f@haskell.org> Message-ID: <062.f863e7ca9859d78604ca5712a62ac929@haskell.org> #15740: Type family with higher-rank result is too accepting -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeFamilies, | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 22:24:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 22:24:20 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.4e5dc6560c1de1a9a6fd94e229a7b831@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by simonpj): Sorry, yes, I was looking in the wrong tree re (1) and (2). Re (3) I now understand. The output of the simplifier is this {{{ $j_s6vr = case w_s75u of lwild_s6yB { __DEFAULT -> case GHC.Prim.dataToTag# @ ClosureType lwild_s6yB of { __DEFAULT -> case lwild_s6yB of lwild_s6yA { __DEFAULT -> case GHC.Prim.dataToTag# @ ClosureType lwild_s6yA of { __DEFAULT -> case lwild_s6yA of lwild_s6vm { __DEFAULT -> case GHC.Prim.dataToTag# @ ClosureType lwild_s6vm of { __DEFAULT -> 1# }; AP_STACK -> 2# } }; AP -> 2# } }; THUNK_SELECTOR -> 2# } } in }}} Are those `case lwild_s6yB of lwild_s6yq { ...}` evals actually redundant? No: they are checking for `AP_STACK` and `THUNK_SELECTOR` resp. But the one you originally asked about was {{{ case a#_a4k2 :: Int# of a#_X4Mq { __DEFAULT -> 1# } }}} This one was ''introduced'' by CSE, so it has not yet had a simplifer run to eliminate it. Before CSE it looked like {{{ case dataToTag# lwild of a#_X4Mq { __DEFAULT -> 1# } }}} In short, all is well. Just do (4). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 23:00:25 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 23:00:25 -0000 Subject: [GHC] #15741: Accept GHCRTS=-N1 when not compiled with -threaded Message-ID: <048.934ff60b2153fe1890cedafca9e2e374@haskell.org> #15741: Accept GHCRTS=-N1 when not compiled with -threaded -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Runtime | Version: 8.6.1 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: -------------------------------------+------------------------------------- current behaviour: {{{ > ghc Main.hs -o test > ./test +RTS -N1 test: the flag -N1 requires the program to be built with -threaded [blah blah] }}} requested: {{{ > ghc Main.hs -o test > ./test +RTS -N1 hello world }}} Motivation: In certain environments, threaded is bad idea due to resource constraints even when multiple capabilities are available, because resident memory can increase with parallel execution. Slapping GHCRTS=-N1 onto those environments would be nice, but breaks for things not compiled with -threaded. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 23:06:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 23:06:20 -0000 Subject: [GHC] #15741: Accept GHCRTS=-N1 when not compiled with -threaded In-Reply-To: <048.934ff60b2153fe1890cedafca9e2e374@haskell.org> References: <048.934ff60b2153fe1890cedafca9e2e374@haskell.org> Message-ID: <063.848d98dacaac420100d06968983d1b61@haskell.org> #15741: Accept GHCRTS=-N1 when not compiled with -threaded -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by lspitzner): There also is the more general feature request "support passing rts opts in a ignore-if-unsupported" mode. E.g. with a system-wide "GHCRTS=-M1G" even running cabal install flat-out fails because cabal does not compile `Setup.hs`s with -rtsopts. Might be considered a bug in cabal in that case, but some escape hatch might make sense regardless. Maybe a second env var, like "GHCRTSSOFT" or something? Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 11 23:22:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Oct 2018 23:22:56 -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.eb0b9c125113cfe21871a32c6f098666@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.8.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 Ben Gamari ): In [changeset:"ce7a1c4ae4c93f2d0d3d7a0b573ddd876fc855c2/ghc" ce7a1c4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ce7a1c4ae4c93f2d0d3d7a0b573ddd876fc855c2" Support builtin classes like KnownNat in backpack This commit allows backpack signatures to enforce constraints like KnownNat on data types. Thus it fixes #15379. There were two important differences in the way GHC used to handle classes like KnowNat 1. Hand crafted instances of `KnownNat` were forbidden, and 2. The dictionary for an instance `KnownNat T` was generated on the fly. For supporting backpack both these points have to be revisited. Disallowing instances of KnownNat -------------------------------------------- Users were disallowed to declare instances of certain builtin classes like KnownNat for obvious safety reasons --- when we use the constraint like `KnownNat T`, we want T to be associated to a natural number. However, due to the reuse of this code while processing backpack signatures, `instance KnownNat T` were being disallowed even in module signature files. There is an important difference when it comes to instance declarations in a signature file. Consider the signature `Abstract` given below ``` signature Abstract where data T :: Nat instance KnownNat T ``` Inside a signature like `Abstract`, the `instance Known T` is not really creating an instance but rather demanding any module that implements this signature to enforce the constraint `KnownNat` on its type T. While hand crafted KnownNat instances continued to be prohibited in modules, this commit ensures that it is not forbidden while handling signatures. Resolving Dictionaries ---------------------------- Normally GHC expects any instance `T` of class `KnownNat` to eventually resolve to an integer and hence used to generate the evidence/dictionary for such instances on the fly as in when it is required. However, when backpack module and signatures are involved It is not always possible to resolve the type to a concrete integer utill the mixin stage. To illustrate consider again the signature `Abstract` > signature Abstract where > data T :: Nat > instance KnownNat T and a module `Util` that depends on it: > module Util where > import Abstract > printT :: IO () > printT = do print $ natVal (Proxy :: Proxy T) Clearly, we need to "use" the dictionary associated with `KnownNat T` in the module `Util`, but it is too early for the compiler to produce a real dictionary as we still have not fixed what `T` is. Only when we mixin a concrete module > module Concrete where > type T = 42 do we really get hold of the underlying integer. In this commit, we make the following changes in the resolution of instance dictionary for constraints like `KnownNat T` 1. If T is indeed available as a type alias for an integer constant, generate the dictionary on the fly as before, failing which 2. Do not give up as before but look up the type class environment for the evidence. This was enough to make the resolution of `KnownNat` dictionaries work in the setting of Backpack as when actual code is generated, the signature Abstract (due to the `import Abstract` ) in `Util` gets replaced by an actual module like Concrete, and resolution happens as before. Everything that we said for `KnownNat` is applicable for `KnownSymbol` as well. Reviewers: bgamari, ezyang, goldfire, simonpj Reviewed By: simonpj Subscribers: simonpj, ezyang, rwbarton, thomie, carter GHC Trac Issues: #15379 Differential Revision: https://phabricator.haskell.org/D4988 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 00:50:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 00:50:59 -0000 Subject: [GHC] #15742: GHC configure step can fail when CC=clang Message-ID: <044.8fa9c1a96d14701a2886c54f5226a16e@haskell.org> #15742: GHC configure step can fail when CC=clang ----------------------------------------+--------------------------------- Reporter: judah | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | 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: ----------------------------------------+--------------------------------- In our internal build of GHC from source, we are building it on Linux with Clang. Unfortunately, this results in an error on ghc-8.4.3: {{{ $ ./configure CC=clang CC_STAGE0=clang --prefix=... --with-ghc=... ... checking version of gcc... configure: error: Need at least gcc version 4.4 (4.7+ recommended) }}} Looking in the code, it seems that the logic is wrong: it calls `$CC -v` and parses the output unconditionally, whether or not the compiler is actually GCC: https://github.com/ghc/ghc/blob/ce7a1c4ae4c93f2d0d3d7a0b573ddd876fc855c2/aclocal.m4#L1245 In our case, the test fails since the compiler is a build of Clang that doesn't produce a useful version number. I also realized that on macOS (where gcc *is* clang), this test succeeds accidentally, since the output of {{{gcc -v}}} is: {{{ Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with- gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 10.0.0 (clang-1000.10.44.2) Target: x86_64-apple-darwin17.7.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin judahjacobson-macbookpro:~ judahjacobson$ gcc -v Configured with: --prefix=/Library/Developer/CommandLineTools/usr --with- gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 10.0.0 (clang-1000.10.44.2) Target: x86_64-apple-darwin17.7.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 04:01:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 04:01:26 -0000 Subject: [GHC] #15740: Type family with higher-rank result is too accepting In-Reply-To: <047.98bb6600d0afd0d0f5c82db2394db54f@haskell.org> References: <047.98bb6600d0afd0d0f5c82db2394db54f@haskell.org> Message-ID: <062.fde581353ad9f863cb95875096f98ca4@haskell.org> #15740: Type family with higher-rank result is too accepting -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeFamilies, | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): As noted in comment:16:ticket:11719, this behavior is a regression from GHC 8.2, which rejects those instances. The first commit to demonstrate this behavior is 4239238306e911803bf61fdda3ad356fd0b42e05 (Fix #12369 by being more flexible with data insts). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 07:33:08 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 07:33:08 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.e0df63af0b7a06518a61772cedc97d29@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ningning): I did some experiments recently. What I did: - add back {{{CoherenceCo}}} and related functions, such as {{{mkCoherenceLeftCo}}} (renaming it to {{{mkCoherenceLeftCo'}}}). - replace uses of functions defined in terms of {{{GRefl}}} to corresponding functions defined in terms of {{{CoherenceCo}}}; for example, replace `mkCoherenceLeftCo` with `mkCoherenceLeftCo'` - test allocation after each change A general observation is, {{{mkCoherenceLeftCo'}}} saves more allocation than {{{mkCoherenceLeftCo}}} when {{{kind_co}}} is not reflexive (similarly for {{{mkCoherenceRightCo}}}) {{{#!hs -- | Given @ty :: k1@, @co :: k1 ~ k2@, @co2:: ty ~ ty'@, -- produces @co' :: (ty |> co) ~r ty' mkCoherenceLeftCo r ty co co2 | isGReflCo co = co2 | otherwise = (mkSymCo co $ GRefl r ty (MCo co)) `mktransCo` co2 -- stores an extra r and ty mkCoherenceLeftCo' co (Refl _) = co mkCoherenceLeftCo' (CoherenceCo co1 co2) co3 = CoherenceCo co1 (co2 `mkTransCo` co3) mkCoherenceLeftCo' co1 co2 = CoherenceCo co1 co2 }}} In the test case {{{T9872d}}}, {{{TcFlatten.homogenise_result}}} is called 340k+ times, which means {{{mkCoherenceLeftCo}}} is called 340k+ times. (not exactly as {{{mkCoherenceLeftCo}}} is inlined by hand in {{{TcFlatten.homogenise_result}}} now. Bur morally it is still true.) If I leave everything unchanged, except for using {{{mkCoherenceLeftCo'}}} instead of {{{mkCoherenceLeftCo}}} in {{{TcFlatten.homogenise_result}}}, I save allocation in {{{T9872d}}} by ~2.5% and it passes the test before the regression. (I also tried to replace the suspicious use of {{{zipWith3}}} in {{{TcFlatten}}} with the original implementation by {{{zipWith}}}, but it save little allocation.) I propose to update {{{Note [flatten_exact_fam_app_fully performance]}}} in {{{TcFlatten}}} to include the analysis. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 08:02:11 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 08:02:11 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.2db77e513955c944bf972b8552041e49@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ningning, let me check my understanding * In HEAD we have `GRefl` but not `CoherenceCo` * In EXPERIMENT you added `CoherenceCo` and used it. * You found that EXPERIMENT allocated up to 2.5% less. Right so far? What are the costs of EXPERIMENT? * The extra constructor in Coercion, and extra cases in free-vars, substitution, pretty-printing etc. * Extra stuff in `OptCoercion`, I assume. This is already a very tricky module, so may be the biggest cost. Is that all? Other thoughts * I recall that `CoerherenceCo` was biased to the laft. One could add a right-biased version too -- would that help even more? * Are you implicitly advocating adding `CoherenceCo` not for expressiveness but for efficiency? And if so, are there any other combinations of coercions that we could play a similar game with? * I've noticed (in `tc_trace` printing) that we build a LOT of Refl coercions. Yet the `isGReflCo` case obviously doesn't fire, perhaps because the coercion hasn't been zonked. Yet in fact `zonkTcType` ''does'' zonk coercions, so I'm a bit puzzled about why we get quite so many of them. There might be some low-hanging fruit in finding out why. * In writing that comment I ''also'' realised that when zonking a type (with `zonkTcType`) we fully zonk all the coercions it mentions. I wonder if that is really necessary? That is, in `zonkTcType` could we simply not-zonk any coercions, just doing the latter when we do `zonkTcTypeToType`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 08:34:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 08:34:45 -0000 Subject: [GHC] #11719: Cannot use higher-rank kinds with type families In-Reply-To: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> References: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> Message-ID: <062.a09f99907b7bbb80b61f0b6984b18fa7@haskell.org> #11719: Cannot use higher-rank kinds with type families -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | dependent/should_compile/T11719 Blocked By: | Blocking: Related Tickets: #13913 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: csongor.kiss14@…, s.eisenbach@…, t.field@… (added) Comment: > The difference with terms is that the arity of type families matters. F1 has arity 1, while F2 has arity 0. The real question is: where is the k bound. In F1, k is bound "before the colon", while in F2, it's bound after the colon. Tricky stuff! Could we document this in the user manual? If we end up adopting Csongor's ideas about unsaturated type families (when the matchability shows up in the kind), we'll need to adopt some notation for the forall-case too. I can't say I like `forall k '. k -> Type`! But we clearly need ''something''. > Perversely, type families can pattern-match only on unmatchable arguments. Perhaps a name change is in order. That is indeed perverse. Worth considering as part of the same effort. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 08:35:34 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 08:35:34 -0000 Subject: [GHC] #15740: Type family with higher-rank result is too accepting In-Reply-To: <047.98bb6600d0afd0d0f5c82db2394db54f@haskell.org> References: <047.98bb6600d0afd0d0f5c82db2394db54f@haskell.org> Message-ID: <062.02b8b8c14dae3bb9b47229a3f48b7ade@haskell.org> #15740: Type family with higher-rank result is too accepting -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeFamilies, | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => high * milestone: => 8.8.1 Comment: Let's make sure this is fixed in 8.8. Can't be too hard... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 08:36:00 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 08:36:00 -0000 Subject: [GHC] #15740: Type family with higher-rank result is too accepting In-Reply-To: <047.98bb6600d0afd0d0f5c82db2394db54f@haskell.org> References: <047.98bb6600d0afd0d0f5c82db2394db54f@haskell.org> Message-ID: <062.09962a10a3c7b8529779b6dd35f108d2@haskell.org> #15740: Type family with higher-rank result is too accepting -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeFamilies, | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: high => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 08:50:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 08:50:14 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.a674fad05d9618a5fa5560d6f925f5a8@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ningning): Replying to [comment:25 simonpj]: > Ningning, let me check my understanding > > * In HEAD we have `GRefl` but not `CoherenceCo` > > * In EXPERIMENT you added `CoherenceCo` and used it. > > * You found that EXPERIMENT allocated up to 2.5% less. > > Right so far? The change of {{{homogenise_result}}} saves ~2.5%. With more similar changes the allocation could become fewer. For example, a similar change in {{{TcFlatten.flatten_args_slow}}} (use {{{mkTcCoherenceLeftCo'}}} instead of {{{mkTcCoherenceLeftCo}}} saves ~1% in T9872d. Namely, if we combine those two changes, it saves ~3.5%. Changes in other places does not have a significant result in T9872d though. > What are the costs of EXPERIMENT? > > * The extra constructor in Coercion, and extra cases in free-vars, substitution, pretty-printing etc. > > * Extra stuff in `OptCoercion`, I assume. This is already a very tricky module, so may be the biggest cost. > > Is that all? Extra stuff in the compilation pipeline, including {{{Coercion}}}, {{{OptCoercion}}}, {{{CoreLint}}}, {{{Ifacexxx}}} etc. Basically I recovered everything I have removed of {{{CoherenceCo}}} in previous commit. Except that, I added nothing new. > Other thoughts > > * I recall that `CoerherenceCo` was biased to the laft. One could add a right-biased version too -- would that help even more? I don't know the answer for sure. But I guess not. As {{{mkCoherenceRightCo}}} differs from {{{CoherenceCo}}} only by 2 {{{SymCo}}}, which won' save much I presume. In contrast, the {{{GRefl}}}-version of {{{mkCoherenceLeftCo}}} differs from {{{CoherenceCo}}}-version of {{{mkCoherenceLeftCo'}}} by a whole type, and the type can be large. > * Are you implicitly advocating adding `CoherenceCo` not for expressiveness but for efficiency? And if so, are there any other combinations of coercions that we could play a similar game with? No I am not advocating addting `CoherenceCo` back. I don't know if it is worth it to add all those stuff for one particular test case. If we look through `Coercion.hs` in head, we can find that functions `mkCoherenceLeftCo` and `mkCoherenceRightCo` are utility functions that construct coercions and are used frequently but don't have their own constructor of coercion (namely, `CoherenceCo`). Other ones don't seem to need a new constructor. (`castCoercionKind` could be one, but I don't think it will benefit from a new constructor of coercion). > * I've noticed (in `tc_trace` printing) that we build a LOT of Refl coercions. Yet the `isGReflCo` case obviously doesn't fire, perhaps because the coercion hasn't been zonked. Yet in fact `zonkTcType` ''does'' zonk coercions, so I'm a bit puzzled about why we get quite so many of them. There might be some low-hanging fruit in finding out why. > > * In writing that comment I ''also'' realised that when zonking a type (with `zonkTcType`) we fully zonk all the coercions it mentions. I wonder if that is really necessary? That is, in `zonkTcType` could we simply not-zonk any coercions, just doing the latter when we do `zonkTcTypeToType`? I am not familiar with the zonking process (yet). If there are some other ways to improve the performance that would be great. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 08:52:04 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 08:52:04 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.9606288c124943e59922d547eb1bcc34@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: 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): > Alternatively I think we could pass an environment of updated ids to topStgBindHasCafRefs and friends. Yes, let's do something more like that. But I have forgotten how SRTs are constructed. We clearly need two passes: 1. Find out which top-level bindings are CAFFy: that is, refers (transitively) to a CAF. That simply involves a free-variable analysis and a fixpoint calculation. 2. Build an SRT for each closure that lists the CAFFy things it mentions. It's not obvious where that is done today -- can you point to it? For step (2) it occurs to me that we could decorate the `StgRhsClosure` with the list of things to put in its SRT, just as we decorate it with the list of locally-bound free variables to put in its closure. That seems so obvious, I'm not sure why we don't do that. One other thought. Suppose we have {{{ x = factorial 200 p = (x,True) q = (False,x) wubble = \x. (p,q) }}} Then `x`, `y` and `p` are all CAFFy, so currently `wurble`'s SRT will contain both `p` and `q`. But actually we need only one of them, because the goal is solely to keep `x` alive. So actually `wurble`'s SRT could list `p` alone, or `q` alone, or indeed just `x`. I'm not sure if this is worth exploiting; and doing so cross-module would mean we had to put more stuff in .hi files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 08:53:39 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 08:53:39 -0000 Subject: [GHC] #15054: ghc internal error appeared in GHCI In-Reply-To: <045.4b99770d3a502039c89178fc2b0221b5@haskell.org> References: <045.4b99770d3a502039c89178fc2b0221b5@haskell.org> Message-ID: <060.dda16c7b2ff16e89a5a67239e9a0b88c@haskell.org> #15054: ghc internal error appeared in GHCI -------------------------------------+------------------------------------- Reporter: radrow | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.2.2 Resolution: | Keywords: debugger Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nh2): Is it possible that this happened during idle GC ("while no query was being evaluated")? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 10:29:42 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 10:29:42 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.e797ee4135e325dde2f37d20a77b4f99@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: patch 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): D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Changes (by sgraf): * status: new => patch * differential: => D5224 Comment: I submitted a patch of the implementation at Phab:D5224 and brought the wiki page up to date. This is ready for review, although still lacking a unit test suite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 12:01:38 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 12:01:38 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.69a9e692238698722a597a07df265743@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): I did (4) and tried to validate. There are 4 regressions. 2 of them are perf, the other 2 are tests with checks on -ddump-simpl output. They're all basically the same problem: worker/wrapper results change slightly after the patch, and worker functions take more boxed params. Here's an example (T10482). Original program is this: {{{ {-# LANGUAGE BangPatterns #-} {-# LANGUAGE TypeFamilies #-} module T10482 where data family Foo a data instance Foo (a, b) = FooPair !(Foo a) !(Foo b) newtype instance Foo Int = Foo Int foo :: Foo ((Int, Int), Int) -> Int -> Int foo !f k = if k == 0 then 0 else if even k then foo f (k-1) else case f of FooPair (FooPair (Foo n) _) _ -> n }}} `$wfoo` originally: {{{ Rec { -- RHS size: {terms: 19, types: 4, coercions: 0, joins: 0/0} T10482.$wfoo [InlPrag=NOUSERINLINE[2], Occ=LoopBreaker] :: GHC.Prim.Int# -> GHC.Prim.Int# -> GHC.Prim.Int# [GblId, Arity=2, Caf=NoCafRefs, Str=, Unf=OtherCon []] T10482.$wfoo = \ (ww_s2Qy :: GHC.Prim.Int#) (ww1_s2QG :: GHC.Prim.Int#) -> case ww1_s2QG of wild_X1v { __DEFAULT -> case GHC.Prim.remInt# wild_X1v 2# of { __DEFAULT -> ww_s2Qy; 0# -> T10482.$wfoo ww_s2Qy (GHC.Prim.-# wild_X1v 1#) }; 0# -> 0# } end Rec } }}} after the patch (`wip/T15696`): {{{ Rec { -- RHS size: {terms: 22, types: 7, coercions: 3, joins: 0/0} T10482.$wfoo [InlPrag=NOUSERINLINE[2], Occ=LoopBreaker] :: Foo Int -> GHC.Prim.Int# -> GHC.Prim.Int# [GblId, Arity=2, Caf=NoCafRefs, Str=, Unf=OtherCon []] T10482.$wfoo = \ (ww_s2Qs :: Foo Int Unf=OtherCon []) (ww1_s2Qz :: GHC.Prim.Int#) -> case ww1_s2Qz of wild_X1l { __DEFAULT -> case GHC.Prim.remInt# wild_X1l 2# of { __DEFAULT -> case ww_s2Qs `cast` (T10482.D:R:FooInt0[0] ; T10482.N:R:FooInt[0] :: Foo Int ~R# Int) of { GHC.Types.I# ww3_s2QD -> ww3_s2QD }; 0# -> T10482.$wfoo ww_s2Qs (GHC.Prim.-# wild_X1l 1#) }; 0# -> 0# } end Rec } }}} The difference is that the first argument is now boxed `Int` instead of `Int#` as before. I think the reason for this change is this: originally evaluation of `ww_s2Qs` happens after `remInt# wild_X1l 2#`, but if we pass `ww_s2Qs` unboxed that'd mean evaluating it before `remInt#`. This is possible if at least one of those expressions are OK-for-speculation. `remInt#` is not OK-for-speculation because it can fail. `ww_s2Qs` was previously (without `wip/T15696`) OK-for- speculation, but we just made `app_ok` more strict by removing a disjunct which was actually holding for this expression: - `n_val_args == 0` holds because it has no args - `isEvaldUnfolding (idUnfolding fun)` apparently also somehow holds. I don't know how exactly, but I'm guessing that because of the strictness annotation on the data con field we give this id `evaldUnfolding`. Other 3 regressions are also of similar nature (worker function with less unboxing). What to do? I think it's correct to consider the data con field as strict here and pass an unboxed value to the worker. While we may not actually have a tagged value there (or even an evaluated one! e.g. #14677, #15155), the programmer indicated that it's fine to evaluate the field eagerly. As long as we don't expect (in the generated code) evaluated or tagged value it's fine. So perhaps we should not do the change in `ok_app`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 13:08:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 13:08:15 -0000 Subject: [GHC] #13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff. In-Reply-To: <044.8846313dfa837f257582237983583132@haskell.org> References: <044.8846313dfa837f257582237983583132@haskell.org> Message-ID: <059.2d65cc0f8b6377ddbb366b8bc127e8c6@haskell.org> #13112: Windows 64-bit GHC HEAD segfaults on the code with a lot of TH stuff. ---------------------------------+-------------------------------------- Reporter: awson | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by Kurren123): I am also getting this issue when I run `stack build`. Using GHC 8.0.1 fixes the issue. I'm fairly new to haskell but I'm willing to help provide any diagnostic info if anyone needs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 13:38:37 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 13:38:37 -0000 Subject: [GHC] #15743: Nail down the Required/Inferred/Specified story Message-ID: <046.20125fa3baabaa154b0336067d36471f@haskell.org> #15743: Nail down the Required/Inferred/Specified story -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In a class/data/type declaration we need to say precisely which type variables are Inferred/Specified/Required and, for the specified ones, which order they occur in. See `Note [VarBndrs, TyCoVarBinders, TyConBinders, and visibility]` in `TyCoRep`. Reminder: * Required: explicitly-specified arguments to the type constructor, always appear in any user-written type. * Specified: variables mentioned lexically in the declaration, but not positionally. Available for visible kind application. * Inferred: completely invisible in the declaration; always implicit and not available for visible kind application. The rules for top-level (non-associated) declarations. Running example: {{{ data T (b :: (k2 :: k)) c (a :: k) }}} * Categorisation * Required: the positional arguments in the header (`a`, `b`, `c`) * Specified: all the variables mentioned in the declaration header, that are not Required (`k`, `k2`) * Inferred: all the others (the kind of `c`) * Order. We need to specify the order in which the Specfied variables are quantified. Here is the spec: * Specified variables are always quantified before Required ones. (We could revisit this.) * List the specified variables in the textual order in which they appear [`k2`, `k`] * Sort them into dependency order using ''ScopedSort'' (see below), giving [`k`, `k2`] * Finally quantify Inferred, then Specified, then Required. In the example we get {{{ T :: forall {k1}. forall k k2. k2 -> k1 -> k -> Type }}} The ''ScopedSort'' algorithm works as follows * Do dependency analysis, so for each variable we know what other variables it depends on, transitively. By "depends on" we mean after full kind inference, not just what is written in the source program. * Work left-to-right through the list, with a cursor. * If variable `v` at the cursor is depended on by any earlier variable `w`, move `v` immediately before the leftmost such `w`. The invariant is that the variables to the left of the cursor form a valid telescope. For associated types, use this running example: {{{ class C (a :: k) where type T a (b :: k2) }}} The rules are elaborated a bit for an associated type like `T` * Required: the explicit positional arguments (here `a`, `b`) * Specified: any non-Required variable that is * mentioned (lexically) in the class header and transitively depended on by the Required variables (here `k`), listed left-to-right; followed by * any other variables mentioned in the type header (here `k2`), again listed left-right. * Inferred: all the others, as before. The Specified variables are sorted exactly as before. Relevant tickets * #14887 esp comment:10 (order of Inferred type variables) * #15592 * #15591 comment:4ff (All following discussion with RAE Friday 12 Oct.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 14:21:17 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 14:21:17 -0000 Subject: [GHC] #15744: Existence of complete pattern synonym hides unrelated incomplete pattern warning Message-ID: <044.0d98254e48b626b7b3d36f84e92f3445@haskell.org> #15744: Existence of complete pattern synonym hides unrelated incomplete pattern warning -------------------------------------+------------------------------------- Reporter: Taneb | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 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: -------------------------------------+------------------------------------- This example {{{#!hs {-# LANGUAGE PatternSynonyms #-} pattern Foo :: a -> b -> (a, b) pattern Foo a b = (a, b) {-# complete Foo #-} main :: IO () main = case ((), Nothing :: Maybe Integer) of ((), Just x) -> print x }}} doesn't give a warning for the incomplete pattern match in {{{main}}}, which doesn't involve textually the pattern synonym {{{Foo}}}. Removing the complete pragma or changing the expression being matched on to even {{{(,) () (Nothing :: Maybe Integer)}}} allows the warning -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 15:01:02 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 15:01:02 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.37e0740f8fc17bac84267da4e1460023@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by simonpj): The rabbit hole gets deeper. In `T10482` We have a data constructor `FooPair` that is strict in both arguments, and an expression like {{{ foo f k = case f of FooPair x y -> case burble of True -> case x of FooPair p q -> ... False -> ... }}} Previously we floated that inner `case x` out to get {{{ foo f k = case f of FooPair x y -> case x of FooPair p q -> case burble of True -> ... False -> ... }}} which is nice and strict. '''So firstly''': the reasoning in item (3) of comment:60 is right for case-binders, but not for the binders of a constructor pattern (the binder-swap stuff doesn't apply to them). So rather than make the change in item (3), we could instead just refrain from giving an "evald-unfolding" to the case binder. This happens here, in `Simplify.simplAlts` {{{ ; (env1, case_bndr1) <- simplBinder env0 case_bndr ; let case_bndr2 = case_bndr1 `setIdUnfolding` evaldUnfolding env2 = modifyInScope env1 case_bndr2 -- See Note [Case binder evaluated-ness] }}} We could try (a) undoing the change in item (3), and (b) removing the above meddling with `case_bndr`. NB: `Note [Case binder evaluated-ness]` is, I believe, out of date; we now skip the lifted args of primpos in `app_ok`. '''Secondly''' I think we can improve w/w, even for the case where that case-expression is not floated out. It's all to do with `Note [Add demands for strict constructors]` in `DmdAnal`, and the function `addDataConStrictness`. This special treatment is ineffective here because (in the first code for foo above), `x` is really used lazily in the alternative. And yet it'd be sound to unpack it. So here's an idea: * Delete all the stuff about `addDataConStrictness` from `DmdAnal`. * Instead, add it into `WwLib` thus: {{{ | isStrictDmd dmd , Just cs <- splitProdDmd_maybe dmd -- See Note [Unpacking arguments with product and polymorphic demands] , not (has_inlineable_prag && isClassPred arg_ty) -- See Note [Do not unpack class dictionaries] , Just (data_con, inst_tys, inst_con_arg_tys, co) <- deepSplitProductType_maybe fam_envs arg_ty , cs `equalLength` inst_con_arg_tys -- See Note [mkWWstr and unsafeCoerce] = do { (uniq1:uniqs) <- getUniquesM ; let cs' = addDataConStrictness data_con cs <---------------- NEW unpk_args = zipWith3 mk_ww_arg uniqs inst_con_arg_tys cs' unbox_fn = mkUnpackCase (Var arg) co uniq1 data_con unpk_args arg_no_unf = zapStableUnfolding arg }}} That is, add one new line, and transfer the defn of `addDataConStrictness` from `DmdAnal`. This actually works, even without implementing "Firstly" -- I tried it. '''And thirdly''', I noticed that `addDataConStrictness` makes the demand stricter like this {{{ add dmd str | isMarkedStrict str , not (isAbsDmd dmd) = dmd `bothDmd` seqDmd | otherwise = dmd }}} But `bothDmd seqDmd` messes up the cardinality information! I doubt this is important but better to define (in `Demand`) {{{ strictifyDmd :: Demand -> Demand strictifyDmd dmd@(JD { sd = str }) = dmd { sd = str `bothArgStr` Str VanStr HeadStr } }}} and call it from `addDataConStrictness`. I think either Firstly or Secondly should fix the regressions, but all three should be good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 15:09:34 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 15:09:34 -0000 Subject: [GHC] #13624: loadObj() does not respect alignment In-Reply-To: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> References: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> Message-ID: <063.157d901e20bc522cad0c81e9141c0c0f@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 George): Trying to find out if MacOS on 8.6.1 is one of the platforms where this needs to be fixed but I can't reproduce: {{{ ./build.sh + llc -filetype=obj -mcpu=native map.ll + ghc --make -no-hs-main test.c bash-3.2$ ./a.out array size is 31 calling function... ok 1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0 10.0 11.0 12.0 13.0 14.0 15.0 16.0 17.0 18.0 19.0 20.0 21.0 22.0 23.0 24.0 25.0 26.0 27.0 28.0 29.0 30.0 31.0 bash-3.2$ lldb a.out (lldb) target create "a.out" Traceback (most recent call last): File "", line 1, in File "/usr/local/Cellar/python at 2/2.7.15_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/copy.py", line 52, in import weakref File "/usr/local/Cellar/python at 2/2.7.15_1/Frameworks/Python.framework/Versions/2.7/lib/python2.7/weakref.py", line 14, in from _weakref import ( ImportError: cannot import name _remove_dead_weakref Current executable set to 'a.out' (x86_64). (lldb) quit quit }}} I don't understand why lldb is needed to reproduce this in any case, in particular how it changes the arr could you explain. Above it says "The #define N on line 7 will change the size of the array...For 32 elements or larger (i.e. entering the core loop) the program will (almost certainly) segfault. " I trying changing N to 32 but then running build.sh a.out just worked, no segfault. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 15:57:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 15:57:58 -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.c78231d91d5c219e2edb212c2515d7fa@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: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5b2388b2cb657771c3c578eaf552b300b79f8260/ghc" 5b2388b2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5b2388b2cb657771c3c578eaf552b300b79f8260" Include -fwarn-star-is-type in -Wcompat According to the deprecation schedule in the accepted proposal, the first step is to include `-fwarn-star-is-type` in `-Wcompat`. Test Plan: Validate Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15476 Differential Revision: https://phabricator.haskell.org/D5044 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 16:14:07 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 16:14:07 -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.c48c1b9fe02ab2db49308fd26c6d759c@haskell.org> #15476: Add -fwarn-star-is-type to -Wcompat -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5044 Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 16:14:42 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 16:14:42 -0000 Subject: [GHC] #15744: Existence of complete pattern synonym hides unrelated incomplete pattern warning In-Reply-To: <044.0d98254e48b626b7b3d36f84e92f3445@haskell.org> References: <044.0d98254e48b626b7b3d36f84e92f3445@haskell.org> Message-ID: <059.deacd6d6ca07600650a5a05105ddc578@haskell.org> #15744: Existence of complete pattern synonym hides unrelated incomplete pattern warning -------------------------------------+------------------------------------- Reporter: Taneb | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | PatternMatchWarnings, | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => PatternMatchWarnings, PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 17:29:01 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 17:29:01 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.152134dd404a45da598aefe140b099f2@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): I'm probably missing the big picture, but I think it makes sense to give evaluated things `evaldUnfolding` and if that breaks something else then we should fix that something else. In (3) of comment:60, perhaps the thing to fix is the binder-swapping transform rather than the id unfolding, so that it avoids swapping binders with different evaluated-ness (or maybe only avoid it if doing so will break the let/app invariant -- not sure how hard would it be to check this though). I don't know enough about demand analysis to comment on Secondly. I'll try it. Re Thirdly, the demand type does not make too much sense to me (how can an id have strict demand but unused cardinality? Sounds like a hack to make some transformations possible) but I can see how the current code changes cardinality incorrectly. I'll update. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 19:40:16 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 19:40:16 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.eb0c29741b727d2b928aab6e5ae17328@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201 -------------------------------------+------------------------------------- Comment (by osa1): Submitted Phab:D5225 for `addDataConStrictness` fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 21:08:49 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 21:08:49 -0000 Subject: [GHC] #15633: Type-checker plugins aren't loaded in GHCi 8.6.1 In-Reply-To: <045.8bcaa0505fc8b553b9837a1fc9146bf4@haskell.org> References: <045.8bcaa0505fc8b553b9837a1fc9146bf4@haskell.org> Message-ID: <060.63e69f39145b7e7117f712cae1ab1bb0@haskell.org> #15633: Type-checker plugins aren't loaded in GHCi 8.6.1 -------------------------------------+------------------------------------- Reporter: phadej | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: | TypeCheckerPlugins Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) * keywords: => TypeCheckerPlugins -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 21:15:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 21:15:54 -0000 Subject: [GHC] #15322: `KnownNat` does not imply `Typeable` any more when used with plugin In-Reply-To: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> References: <047.ea5542689589ff9f84b15b4205aa6aef@haskell.org> Message-ID: <062.f6429189ca520dccd568cf2ad940678c@haskell.org> #15322: `KnownNat` does not imply `Typeable` any more when used with plugin -------------------------------------+------------------------------------- Reporter: chshersh | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | typeable,knownnat,TypeCheckerPlugins Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #10348 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * keywords: typeable,knownnat => typeable,knownnat,TypeCheckerPlugins * cc: adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 22:45:14 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 22:45:14 -0000 Subject: [GHC] #11004: hsc2hs does not handle single quotes properly In-Reply-To: <044.0bda8c5df856d596df18293a23a5f521@haskell.org> References: <044.0bda8c5df856d596df18293a23a5f521@haskell.org> Message-ID: <059.b4988c2a132a6bc1cb978d9d9ab18906@haskell.org> #11004: hsc2hs does not handle single quotes properly -------------------------------------+------------------------------------- Reporter: sergv | Owner: sergv Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tmobile): I just hit this. Anyone have a patch? If not I'll try to have someone work on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 22:51:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 22:51:09 -0000 Subject: [GHC] #11004: hsc2hs does not handle single quotes properly In-Reply-To: <044.0bda8c5df856d596df18293a23a5f521@haskell.org> References: <044.0bda8c5df856d596df18293a23a5f521@haskell.org> Message-ID: <059.89282edbd496a54b55ae380abb46e3fd@haskell.org> #11004: hsc2hs does not handle single quotes properly -------------------------------------+------------------------------------- Reporter: sergv | Owner: sergv Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sergv): I've never got around to actually doing this issue, so there's no patch. Please feel free to reassign as you see fit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 22:57:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 22:57:06 -0000 Subject: [GHC] #11004: hsc2hs does not handle single quotes properly In-Reply-To: <044.0bda8c5df856d596df18293a23a5f521@haskell.org> References: <044.0bda8c5df856d596df18293a23a5f521@haskell.org> Message-ID: <059.7a703f30d63588ea90a28806d8ed5ac6@haskell.org> #11004: hsc2hs does not handle single quotes properly -------------------------------------+------------------------------------- Reporter: sergv | Owner: tmobile Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.10.2 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tmobile): * owner: sergv => tmobile -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 22:57:38 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 22:57:38 -0000 Subject: [GHC] #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 In-Reply-To: <046.a39037510433715ab5f0873fb73e977c@haskell.org> References: <046.a39037510433715ab5f0873fb73e977c@haskell.org> Message-ID: <061.8b0fa41953179f9e3e1aeaad0a51b4ae@haskell.org> #15449: Nondeterministic Failure on aarch64 with -jn, n > 1 -------------------------------------+------------------------------------- Reporter: tmobile | Owner: tmobile Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tmobile): * owner: (none) => tmobile -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 12 22:58:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Oct 2018 22:58:19 -0000 Subject: [GHC] #13624: loadObj() does not respect alignment In-Reply-To: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> References: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> Message-ID: <063.667a8d74220d521e2ebac4d023fd5306@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 tmcdonell): Replying to [comment:13 George]: > Trying to find out if MacOS on 8.6.1 is one of the platforms where this needs to be fixed but I can't reproduce: The problem still exists. I verified this just now; macOS 10.13.6 {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.6.1 $ ghc --print-project-git-commit-id 0d2cdec78471728a0f2c487581d36acda68bb941 }}} > I don't understand why lldb is needed to reproduce this in any case. Obviously, `lldb` is not required. Just run the executable and watch it segfault. The point of using a debugger (any would suffice) is to demonstrate which instruction is causing the problem, which for this issue is important to understand. > In particular how it changes the array size to 32, could you explain? In the description it says "The #define N on line 7 will change the size of the array...For 32 elements or larger (i.e. entering the core loop) the program will (almost certainly) segfault. " I trying changing N to 32 but then running build.sh a.out just worked, no segfault. If you read the description, you will see that the core loop is a 8-way vectorised and 4-way unrolled; i.e. 32-elements per trip. For any remainder it backs out to a single element per loop. Thus, to activate the code path which exhibits the problem, you require at least 32 elements. The description also says "For a CPU with AVX instructions (sandy bridge or later) you should get the following". Since you are running an original corei7 (nephalem) and don't have AVX instructions, this exact example obviously won't trigger for you. If you checked the objdump output as suggested, you would also have seen this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 13 03:27:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Oct 2018 03:27:12 -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.35861d60f7d04abf9d804d0c702f468e@haskell.org> #15499: Panic in occurence analysis phase (?), getRuntimeRep -------------------------------------+------------------------------------- Reporter: _deepfire | Owner: RyanGlScott Type: bug | Status: closed Priority: high | Milestone: 8.6.2 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 Comment: Merged to `ghc-8.6` with 0af55c128d06e8c23a6fd68bafe47a5315bea812. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 13 03:31:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Oct 2018 03:31:55 -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.022151126163ee3328ac8939e56c365c@haskell.org> #15196: Invert floating point comparisons such that no extra parity check is required. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler (NCG) | Version: 8.4.3 Resolution: fixed | 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 bgamari): * status: merge => closed * resolution: => fixed * milestone: 8.6.2 => 8.8.1 Comment: I'm going to punt this to 8.8 to ensure it gets proper testing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 13 03:34:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Oct 2018 03:34:11 -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.a273836c45cfb68f3610ac159be6b25d@haskell.org> #8763: forM_ [1..N] does not get fused (allocates 50% more) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | 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): Phab:D5131 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: 8.6.2 => 8.8.1 Comment: I'm going to leave this for 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 13 08:42:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Oct 2018 08:42:13 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.99caefa32e885d9a618039ecaf7fe07c@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: patch 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): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Changes (by potato44): * differential: D5224 => Phab:D5224 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 13 11:44:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Oct 2018 11:44:18 -0000 Subject: [GHC] #13624: loadObj() does not respect alignment In-Reply-To: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> References: <048.7da849a741966df9bea522bb2e35fdcc@haskell.org> Message-ID: <063.0e89ae4356bd80b8cda29adcf4187f2e@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 George): Sorry, when I first read the bug I realized that I wouldn't be able to reproduce it on my machine but was interested in seeing it fixed as I plan on getting a new machine in the near future. When I saw comment 11 I forgot all that and tried to reproduce. Sorry for wasting your time but thanks for taking the time to answer. Replying to [comment:14 tmcdonell]: > Replying to [comment:13 George]: > > Trying to find out if MacOS on 8.6.1 is one of the platforms where this needs to be fixed but I can't reproduce: > > The problem still exists. I verified this just now; macOS 10.13.6 > > {{{ > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version 8.6.1 > $ ghc --print-project-git-commit-id > 0d2cdec78471728a0f2c487581d36acda68bb941 > }}} > > > I don't understand why lldb is needed to reproduce this in any case. > > Obviously, `lldb` is not required. Just run the executable and watch it segfault. The point of using a debugger (any would suffice) is to demonstrate which instruction is causing the problem, which for this issue is important to understand. > > > In particular how it changes the array size to 32, could you explain? In the description it says "The #define N on line 7 will change the size of the array...For 32 elements or larger (i.e. entering the core loop) the program will (almost certainly) segfault. " I trying changing N to 32 but then running build.sh a.out just worked, no segfault. > > If you read the description, you will see that the core loop is a 8-way vectorised and 4-way unrolled; i.e. 32-elements per trip. For any remainder it backs out to a single element per loop. Thus, to activate the code path which exhibits the problem, you require at least 32 elements. > > The description also says "For a CPU with AVX instructions (sandy bridge or later) you should get the following". Since you are running an original corei7 (nephalem) and don't have AVX instructions, this exact example obviously won't trigger for you. If you checked the objdump output as suggested, you would also have seen this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 13 13:09:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Oct 2018 13:09:28 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.7cf51487b3a1c8f63167b6709c73c405@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * Attachment "compile.out" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 13 13:12:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Oct 2018 13:12:45 -0000 Subject: [GHC] #13535: vector test suite uses excessive memory on GHC 8.2 In-Reply-To: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> References: <050.16d8aabc8a5c61d8950e3575a8e4ccd4@haskell.org> Message-ID: <065.b59f93d99b33ae6418f563359095e3dd@haskell.org> #13535: vector test suite uses excessive memory on GHC 8.2 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10800 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): The original test still reproduces with ghc 8.6.1. In particular, bash -c 'ulimit -v 4000000; cabal test' fails with "ghc: out of memory." The output of David's compile above with Smaller-Vector.hs is in the attached file, compile.out, just above -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 13 17:23:03 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Oct 2018 17:23:03 -0000 Subject: [GHC] #14907: Error message: (%, %) shows up when with accidental paren In-Reply-To: <051.2e9709c3004b74af6c52b8b012de4b6f@haskell.org> References: <051.2e9709c3004b74af6c52b8b012de4b6f@haskell.org> Message-ID: <066.945cfd5152430c2ddb7c80e55b1ecfa8@haskell.org> #14907: Error message: (%,%) shows up when with accidental paren -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5172 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.6` with 87266ea717de2df11d7b491bf3c525b7c1a1a47a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 13 17:23:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Oct 2018 17:23:28 -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.b9ccd2c6f95236fa24009c6b34383cb2@haskell.org> #15053: Compiler panic on invalid syntax (unterminated pragma) -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: RolandSenn Type: bug | Status: closed Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.2.2 (Parser) | Resolution: fixed | 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 bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.6` with 523047768913836177f49768d1070996ebabf242. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 13 17:23:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Oct 2018 17:23:55 -0000 Subject: [GHC] #15571: Eager AP_STACK blackholing causes incorrect size info for sanity checks In-Reply-To: <043.9213207e6a514a137db4ef0469470bf7@haskell.org> References: <043.9213207e6a514a137db4ef0469470bf7@haskell.org> Message-ID: <058.84ab6aa9f6b89ebf1e02e4d90fe4a01b@haskell.org> #15571: Eager AP_STACK blackholing causes incorrect size info for sanity checks -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.2 Component: Runtime System | 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: #15508 | Differential Rev(s): Phab:D5165 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Merged to `ghc-8.6` with 10e3125d4f6ea0684cbe1315b35a2a213d2765cd. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 13 17:24:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Oct 2018 17:24:17 -0000 Subject: [GHC] #15722: Add -Wstar-is-type to the User's Guide In-Reply-To: <048.b0249a61ab8434cdd74d3b60e9731ff9@haskell.org> References: <048.b0249a61ab8434cdd74d3b60e9731ff9@haskell.org> Message-ID: <063.c3afea38e484b69ee68e5a9ce9f8fa21@haskell.org> #15722: Add -Wstar-is-type to the User's Guide -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.6.2 Component: Documentation | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5203 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.6` with 4ab2f347b76d65a405959fb01a058a45e791c41b. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 13 17:24:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Oct 2018 17:24:39 -0000 Subject: [GHC] #12005: Constraint instances not shown in `:info` In-Reply-To: <051.e0728f3c0e56a4361f8b5139b7d323c2@haskell.org> References: <051.e0728f3c0e56a4361f8b5139b7d323c2@haskell.org> Message-ID: <066.8105a0f1192bcc00254a57be3b73c41f@haskell.org> #12005: Constraint instances not shown in `:info` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5182 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.6` with 51c447936ef3f2f3f67c54d2dd62de537f443e89. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 13 18:19:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Oct 2018 18:19:06 -0000 Subject: [GHC] #15745: Panicking typechecker plugins Message-ID: <051.0643b56f13bc8491c2a5c13a701f5bf7@haskell.org> #15745: Panicking typechecker plugins -------------------------------------+------------------------------------- Reporter: philderbeast | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I use a typechecker plugin that fails then ghc panics and I'm asked to report a bug with GHC; {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.2.2 for x86_64-apple-darwin): Prelude.undefined CallStack (from HasCallStack): error, called at libraries/base/GHC/Err.hs:79:14 in base:GHC.Err undefined, called at plugin/Undefined/Solve/Plugin.hs:14:39 in undefined-solve- plugin-1.0.0.0-56evBabJYBHHTUlrE3HO5m:Undefined.Solve.Plugin Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Could we please say that it is the typechecker plugin that is panicking and ask for a bug report for the faulty typechecker, giving the issues URL for the plugin if we know it? The following [https://github.com/BlockScope/undefined-plugin undefined plugins] fail for init, solve and stop functions. {{{ #!haskell module Undefined.Init.Plugin (plugin) where import Plugins (Plugin(..), tcPlugin, defaultPlugin) import TcRnTypes (TcPluginM, TcPluginResult(..), Ct, TcPlugin(..)) import GHC.TcPluginM.Extra (tracePlugin) plugin :: Plugin plugin = defaultPlugin { tcPlugin = const $ Just undefinedPlugin } undefinedPlugin :: TcPlugin undefinedPlugin = tracePlugin "undefined-init-plugin" $ TcPlugin { tcPluginInit = undefined , tcPluginSolve = \_ _ _ _ -> return $ TcPluginOk [] [] , tcPluginStop = const $ return () } }}} {{{ #!haskell module Undefined.Solve.Plugin (plugin) where import Plugins (Plugin(..), tcPlugin, defaultPlugin) import TcRnTypes (TcPluginM, TcPluginResult, Ct, TcPlugin(..)) import GHC.TcPluginM.Extra (tracePlugin) plugin :: Plugin plugin = defaultPlugin { tcPlugin = const $ Just undefinedPlugin } undefinedPlugin :: TcPlugin undefinedPlugin = tracePlugin "undefined-solve-plugin" $ TcPlugin { tcPluginInit = return () , tcPluginSolve = \_ _ _ _ -> undefined , tcPluginStop = const $ return () } }}} {{{ #!haskell module Undefined.Stop.Plugin (plugin) where import Plugins (Plugin(..), tcPlugin, defaultPlugin) import TcRnTypes (TcPluginM, TcPluginResult(..), Ct, TcPlugin(..)) import GHC.TcPluginM.Extra (tracePlugin) plugin :: Plugin plugin = defaultPlugin { tcPlugin = const $ Just undefinedPlugin } undefinedPlugin :: TcPlugin undefinedPlugin = tracePlugin "undefined-stop-plugin" $ TcPlugin { tcPluginInit = return () , tcPluginSolve = \_ _ _ _ -> return $ TcPluginOk [] [] , tcPluginStop = const $ undefined } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 13 21:28:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Oct 2018 21:28:13 -0000 Subject: [GHC] #15745: Panicking typechecker plugins In-Reply-To: <051.0643b56f13bc8491c2a5c13a701f5bf7@haskell.org> References: <051.0643b56f13bc8491c2a5c13a701f5bf7@haskell.org> Message-ID: <066.f9c82508d441dc4170dfdcf49b3ed7bc@haskell.org> #15745: Panicking typechecker plugins -------------------------------------+------------------------------------- Reporter: philderbeast | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: Resolution: | TypeCheckerPlugins 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 adamgundry): * keywords: => TypeCheckerPlugins * cc: adamgundry (added) Comment: Makes sense. We can't necessarily identify such plugin-caused errors in all cases, but it should at least be possible to catch exceptions thrown in TcPluginM. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 13 21:59:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Oct 2018 21:59:04 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.91c25554f1dd92572f622c21d74c5077@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201, Phab:D5226 -------------------------------------+------------------------------------- Changes (by bgamari): * differential: Phab:D5196, Phab:D5201 => Phab:D5196, Phab:D5201, Phab:D5226 Comment: I gave Secondly from comment:77 a try while waiting for GHC 8.4.4 builds. The result is Phab:D5226. However, the approach presented does seem a bit odd since the demand resulting from demand analysis is still conservative; we merely make up for this conservatism in worker-wrapper. However, this doesn't help other (hypothetical) consumers of demand analysis. Perhaps it would be good to open a ticket to ensure we don't forget about this limitation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 13 23:55:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Oct 2018 23:55:34 -0000 Subject: [GHC] #14037: Fix fusion for GHC's utility functions In-Reply-To: <047.af3aa20f0a3e0012611cde731288958b@haskell.org> References: <047.af3aa20f0a3e0012611cde731288958b@haskell.org> Message-ID: <062.3d205fbc568511b97b1f6e35bf930667@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: | -------------------------------------+------------------------------------- Comment (by rockbmb): I'd like to take this issue on, but before I do I'll take a look at the modules in question. Is there a benchmarking suite in GHC that includes the functions mentioned? If not then that would also be part of the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 14 06:13:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Oct 2018 06:13:12 -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.0345daaba783888435f23ea693a3e942@haskell.org> #15481: TH fails to recover from reifyFixity with -fexternal-interpreter -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 8.6.2 Component: Template Haskell | Version: 8.4.3 Resolution: fixed | Keywords: RemoteGHCi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5185 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.6` in a04ecd7ba8c7f012369eeb5864b813a130e043e3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 14 06:13:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Oct 2018 06:13:46 -0000 Subject: [GHC] #15695: Core Lint error, from -fobject-code + defer type errors + pattern synonyms + other stuff In-Reply-To: <051.924cbdebca03c5aa89a4c1b89bc4850d@haskell.org> References: <051.924cbdebca03c5aa89a4c1b89bc4850d@haskell.org> Message-ID: <066.a6a237c2f17797308f486283a39fb12f@haskell.org> #15695: Core Lint error, from -fobject-code + defer type errors + pattern synonyms + other stuff -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | patsyn/should_fail/T15695 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.6` with a22ee7050b610b862ebe1eb725e7aa141b766e05. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 14 11:32:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Oct 2018 11:32:09 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.9dee371b654a94ede2398edb0c506277@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Update: Been working on this today; I've done the changes required in `BasicTypes.hs` and I'm on `Lexer.hs` changes now. It's going well, currently in the process of refactoring `readHexRational` to use a new function for reading the significand and exponent out of hex floating literals. (from `Util.hs`). Just finished doing that for `readRational`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 14 14:46:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Oct 2018 14:46:45 -0000 Subject: [GHC] #15746: Memory leak in print when RTS option -N is >= 2 Message-ID: <046.4d2c5320a55de5bc853b26efeb4f21cf@haskell.org> #15746: Memory leak in print when RTS option -N is >= 2 -------------------------------------+------------------------------------- Reporter: nmattia | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In GHC 802 the code below runs with constant memory. In GHC 822, 843 and 861 the code below runs with constant memory only if at most one core is used. If the RTS option -N is set to anything greater than 1, the memory usage grows with the size of "big_file". {{{#!hs import Data.ByteString.Builder.Extra (defaultChunkSize) import Data.Function import System.IO import qualified Data.ByteString as BS main :: IO () main = do h <- openFile "big_file" ReadMode fix $ \loop -> do bs <- BS.hGetSome h defaultChunkSize if BS.null bs then pure () else do print bs loop }}} You can reproduce this by cloning https://github.com/nmattia/ghc-print- leak and running "nix-shell". Alternatively save the code above to "Main.hs" and run "ghc ./Main.hs -threaded -rtsopts" and then "./Main +RTS -M2M -N[1|2] > /dev/null". Side note: the memory does not grow as quickly if the _size_ of the bytestring is printed, i.e. it seems to be a problem specific to hPutStrLn/print as opposed to the actual file content/bytestring being retained. I first encountered this issue when using conduit for the loop. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 14 18:59:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Oct 2018 18:59:13 -0000 Subject: [GHC] #15747: GHC panics when builds for arm as: ghc-stage1: panic! (the 'impossible' happened): padLiveArgs -- i > regNum ?? Message-ID: <045.cba5326f4d617f1d05fcc7dfa664973a@haskell.org> #15747: GHC panics when builds for arm as: ghc-stage1: panic! (the 'impossible' happened): padLiveArgs -- i > regNum ?? -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc-HEAD fails build as: {{{ $ LANG=C make ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for 'phase_1_builds'. ===--- building final phase make --no-print-directory -f ghc.mk phase=final all "inplace/bin/ghc-stage1" -static -H32m -O -O0 -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical- monad-instances -c rts/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.o You are using an unsupported version of LLVM! Currently only 6.0 is supported. We will try though... ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.7.20181014 for arm-unknown-linux): padLiveArgs -- i > regNum ??(2,1) CallStack (from HasCallStack): error, called at compiler/llvmGen/LlvmCodeGen/Base.hs:194:27 in ghc:LlvmCodeGen.Base Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [rts/ghc.mk:318: rts/dist/build/HeapStackCheck.o] Error 1 make: *** [Makefile:127: all] Error 2 }}} The suspect is: https://phabricator.haskell.org/D5190 GHC is built for '''armv7a-unknown-linux-gnueabihf''' target. {{{ inplace/bin/ghc-stage1 --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv -fno-builtin") ,("C compiler command","armv7a-unknown-linux-gnueabihf-gcc") ,("C compiler flags"," -marm -fno-stack-protector") ,("C compiler link flags"," -Wl,-z,noexecstack") ,("C compiler supports -no-pie","YES") ,("Haskell CPP command","armv7a-unknown-linux-gnueabihf-gcc") ,("Haskell CPP flags","-E -undef -traditional") ,("ld command","armv7a-unknown-linux-gnueabihf-ld.gold") ,("ld flags"," -z noexecstack") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","armv7a-unknown-linux-gnueabihf-ar") ,("ar flags","q") ,("ar supports at file","YES") ,("ranlib command","armv7a-unknown-linux-gnueabihf-ranlib") ,("touch command","touch") ,("dllwrap command","armv7a-unknown-linux-gnueabihf-dllwrap") ,("windres command","armv7a-unknown-linux-gnueabihf-windres") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("cross compiling","YES") ,("target os","OSLinux") ,("target arch","ArchARM {armISA = ARMv7, armISAExt = [VFPv3,NEON], armABI = HARD}") ,("target word size","4") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("target has RTS linker","YES") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("LLVM clang command","clang") ,("Project version","8.7.20181014") ,("Project Git commit id","4a79ae580698ec635a6edd2b56958af2682511dd") ,("Booter version","8.4.2") ,("Stage","1") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","arm-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","NO") ,("Have native code generator","NO") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn ") ,("RTS expects libdw","NO") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Support Backpack","YES") ,("Requires unified installed package IDs","YES") ,("Uses package keys","YES") ,("Uses unit IDs","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","NO") ,("GHC Profiled","NO") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/tmp/portage/cross-armv7a-unknown-linux- gnueabihf/ghc-9999/work/ghc-9999/inplace/lib") ,("Global Package DB","/tmp/portage/cross-armv7a-unknown-linux- gnueabihf/ghc-9999/work/ghc-9999/inplace/lib/package.conf.d") ] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 14 19:16:30 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Oct 2018 19:16:30 -0000 Subject: [GHC] #15748: panic Message-ID: <042.ddee66d80c6f02a82c2257ffc3132db1@haskell.org> #15748: panic -------------------------------------+------------------------------------- Reporter: awf | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help Prelude> :print getChar >>= return ghc.exe: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-unknown-mingw32): isUnliftedType t1_a1tM[rt] :: TYPE t_a1tL[rt] 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 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 14 19:28:30 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Oct 2018 19:28:30 -0000 Subject: [GHC] #15748: panic In-Reply-To: <042.ddee66d80c6f02a82c2257ffc3132db1@haskell.org> References: <042.ddee66d80c6f02a82c2257ffc3132db1@haskell.org> Message-ID: <057.25fa3084a38a6f5891affd95dbddaffc@haskell.org> #15748: panic -------------------------------------+------------------------------------- Reporter: awf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: Thank you for the report. This is a duplicate of #14828. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 14 20:05:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Oct 2018 20:05:14 -0000 Subject: [GHC] #15371: Eventlog framework outputs environment variables which may cause a security issue In-Reply-To: <043.e0598f3eff95a3e71b8c6103a2d86a17@haskell.org> References: <043.e0598f3eff95a3e71b8c6103a2d86a17@haskell.org> Message-ID: <058.86aa36998cf2dad5494ad959f7ae5c17@haskell.org> #15371: Eventlog framework outputs environment variables which may cause a security issue -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | 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): Phab:D5187 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"68a747c702d2432cc90d2a79a6aba0e67ac3e2c0/ghc" 68a747c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="68a747c702d2432cc90d2a79a6aba0e67ac3e2c0" rts: Stop tracing environment variables (fixes #15371) Summary: This tracing may cause a security issue as some external tools out there expects user to set credentials in environment variables. Reviewers: bgamari, erikd, simonmar, monoidal Reviewed By: monoidal Subscribers: tdammers, rwbarton, carter GHC Trac Issues: #15371 Differential Revision: https://phabricator.haskell.org/D5187 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 14 20:05:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Oct 2018 20:05:14 -0000 Subject: [GHC] #15627: Absent unlifted bindings In-Reply-To: <044.bc86ad63a852b5821c5e83dda4b97374@haskell.org> References: <044.bc86ad63a852b5821c5e83dda4b97374@haskell.org> Message-ID: <059.9187ec18383fdc2fdfd1ab3b1de1b7b4@haskell.org> #15627: Absent unlifted bindings -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: ⊥ 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: #9279 #4328 | Differential Rev(s): Phab:D5153 #11126 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"448b77b93b369745e9bfbc8b46a5b87bb73dd379/ghc" 448b77b9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="448b77b93b369745e9bfbc8b46a5b87bb73dd379" Add RubbishLit for absent bindings of UnliftedRep Summary: Trac #9279 reminded us that the worker wrapper transformation copes really badly with absent unlifted boxed bindings. As `Note [Absent errors]` in WwLib.hs points out, we can't just use `absentError` for unlifted bindings because there is no bottom to hide the error in. So instead, we synthesise a new `RubbishLit` of type `forall (a :: TYPE 'UnliftedRep). a`, which code-gen may subsitute for any boxed value. We choose `()`, so that there is a good chance that the program crashes instead instead of leading to corrupt data, should absence analysis have been too optimistic (#11126). Reviewers: simonpj, hvr, goldfire, bgamari, simonmar Reviewed By: simonpj Subscribers: osa1, rwbarton, carter GHC Trac Issues: #15627, #9279, #4306, #11126 Differential Revision: https://phabricator.haskell.org/D5153 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 14 20:05:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Oct 2018 20:05:14 -0000 Subject: [GHC] #11126: Entered absent arg in a Repa program In-Reply-To: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> References: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> Message-ID: <064.0f5b8e72a676729eb4771d324475b888@haskell.org> #11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3221 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"448b77b93b369745e9bfbc8b46a5b87bb73dd379/ghc" 448b77b9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="448b77b93b369745e9bfbc8b46a5b87bb73dd379" Add RubbishLit for absent bindings of UnliftedRep Summary: Trac #9279 reminded us that the worker wrapper transformation copes really badly with absent unlifted boxed bindings. As `Note [Absent errors]` in WwLib.hs points out, we can't just use `absentError` for unlifted bindings because there is no bottom to hide the error in. So instead, we synthesise a new `RubbishLit` of type `forall (a :: TYPE 'UnliftedRep). a`, which code-gen may subsitute for any boxed value. We choose `()`, so that there is a good chance that the program crashes instead instead of leading to corrupt data, should absence analysis have been too optimistic (#11126). Reviewers: simonpj, hvr, goldfire, bgamari, simonmar Reviewed By: simonpj Subscribers: osa1, rwbarton, carter GHC Trac Issues: #15627, #9279, #4306, #11126 Differential Revision: https://phabricator.haskell.org/D5153 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 14 20:05:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Oct 2018 20:05:14 -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.02e5b9f0c9ae1a4c37ff8846c8b782d5@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: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"448b77b93b369745e9bfbc8b46a5b87bb73dd379/ghc" 448b77b9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="448b77b93b369745e9bfbc8b46a5b87bb73dd379" Add RubbishLit for absent bindings of UnliftedRep Summary: Trac #9279 reminded us that the worker wrapper transformation copes really badly with absent unlifted boxed bindings. As `Note [Absent errors]` in WwLib.hs points out, we can't just use `absentError` for unlifted bindings because there is no bottom to hide the error in. So instead, we synthesise a new `RubbishLit` of type `forall (a :: TYPE 'UnliftedRep). a`, which code-gen may subsitute for any boxed value. We choose `()`, so that there is a good chance that the program crashes instead instead of leading to corrupt data, should absence analysis have been too optimistic (#11126). Reviewers: simonpj, hvr, goldfire, bgamari, simonmar Reviewed By: simonpj Subscribers: osa1, rwbarton, carter GHC Trac Issues: #15627, #9279, #4306, #11126 Differential Revision: https://phabricator.haskell.org/D5153 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 14 20:05:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Oct 2018 20:05:14 -0000 Subject: [GHC] #4306: UNPACK can lead to unnecessary copying and wasted stack space In-Reply-To: <045.5bbd862c0c7e991fd2a851c9160f9ab1@haskell.org> References: <045.5bbd862c0c7e991fd2a851c9160f9ab1@haskell.org> Message-ID: <060.701047c84ac3add7628d9d7eae94e81c@haskell.org> #4306: UNPACK can lead to unnecessary copying and wasted stack space -------------------------------------+------------------------------------- Reporter: Olathe | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: Runtime | Test Case: performance bug | simplCore/should_compile/T4306 Blocked By: | Blocking: -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"448b77b93b369745e9bfbc8b46a5b87bb73dd379/ghc" 448b77b9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="448b77b93b369745e9bfbc8b46a5b87bb73dd379" Add RubbishLit for absent bindings of UnliftedRep Summary: Trac #9279 reminded us that the worker wrapper transformation copes really badly with absent unlifted boxed bindings. As `Note [Absent errors]` in WwLib.hs points out, we can't just use `absentError` for unlifted bindings because there is no bottom to hide the error in. So instead, we synthesise a new `RubbishLit` of type `forall (a :: TYPE 'UnliftedRep). a`, which code-gen may subsitute for any boxed value. We choose `()`, so that there is a good chance that the program crashes instead instead of leading to corrupt data, should absence analysis have been too optimistic (#11126). Reviewers: simonpj, hvr, goldfire, bgamari, simonmar Reviewed By: simonpj Subscribers: osa1, rwbarton, carter GHC Trac Issues: #15627, #9279, #4306, #11126 Differential Revision: https://phabricator.haskell.org/D5153 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 14 20:07:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Oct 2018 20:07:43 -0000 Subject: [GHC] #15371: Eventlog framework outputs environment variables which may cause a security issue In-Reply-To: <043.e0598f3eff95a3e71b8c6103a2d86a17@haskell.org> References: <043.e0598f3eff95a3e71b8c6103a2d86a17@haskell.org> Message-ID: <058.c73c05f155a2ddf29b40ad592575ceb4@haskell.org> #15371: Eventlog framework outputs environment variables which may cause a security issue -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: feature request | Status: merge Priority: normal | Milestone: Component: Runtime System | 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): Phab:D5187 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 14 20:30:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Oct 2018 20:30:13 -0000 Subject: [GHC] #15627: Absent unlifted bindings In-Reply-To: <044.bc86ad63a852b5821c5e83dda4b97374@haskell.org> References: <044.bc86ad63a852b5821c5e83dda4b97374@haskell.org> Message-ID: <059.4f066d77183fd4038bbd426e9e35cd6f@haskell.org> #15627: Absent unlifted bindings -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: ⊥ 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: #9279 #4328 | Differential Rev(s): Phab:D5153 #11126 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 14 21:16:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Oct 2018 21:16:08 -0000 Subject: [GHC] #15749: Long Harbormaster builds Message-ID: <047.7675be525c388a72a4307972f4794c78@haskell.org> #15749: Long Harbormaster builds -------------------------------------+------------------------------------- Reporter: monoidal | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.6.1 Integration | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Harbormaster builds sometimes take too long and are not terminated. For example, the following builds have been running for over 2 days: https://phabricator.haskell.org/harbormaster/build/54452/ https://phabricator.haskell.org/harbormaster/build/54477/ https://phabricator.haskell.org/harbormaster/build/54485/ We should have some timeout (or lower the threshold if it's already present). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 14 22:04:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Oct 2018 22:04:37 -0000 Subject: [GHC] #15749: Long Harbormaster builds In-Reply-To: <047.7675be525c388a72a4307972f4794c78@haskell.org> References: <047.7675be525c388a72a4307972f4794c78@haskell.org> Message-ID: <062.5cc9e25514d28c3f43a0e9e6a1e35d1b@haskell.org> #15749: Long Harbormaster builds -------------------------------------+------------------------------------- Reporter: monoidal | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Continuous | Version: 8.6.1 Integration | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Note that these aren't actually building; rather, they are simply waiting for a machine to build on. It may be that the the Linux/amd64 build queue is jammed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 14 22:14:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Oct 2018 22:14:17 -0000 Subject: [GHC] #15748: panic In-Reply-To: <042.ddee66d80c6f02a82c2257ffc3132db1@haskell.org> References: <042.ddee66d80c6f02a82c2257ffc3132db1@haskell.org> Message-ID: <057.cd856856bb43e4fb9a488487b770dfd1@haskell.org> #15748: panic -------------------------------------+------------------------------------- Reporter: awf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Well it's hard to tell if it's a duplicate without a way to reproduce it. Andrew, do you have a repro case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 14 22:36:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Oct 2018 22:36:04 -0000 Subject: [GHC] #15748: panic In-Reply-To: <042.ddee66d80c6f02a82c2257ffc3132db1@haskell.org> References: <042.ddee66d80c6f02a82c2257ffc3132db1@haskell.org> Message-ID: <057.1b51f42132383bbd630705c5f5fea319@haskell.org> #15748: panic -------------------------------------+------------------------------------- Reporter: awf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): The reproduction is above the panic message: `:print getChar >>= return` causes ghci to panic. Simplifying, `:print return` also panicks, which is one of examples in #14828. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 14 22:59:58 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Oct 2018 22:59:58 -0000 Subject: [GHC] #15750: Investigate haddock.base perf test Message-ID: <047.c45d20d3b9f7fe7999748725890fca87@haskell.org> #15750: Investigate haddock.base perf test -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I've seen failures in the `haddock.base` perf test when making changes that really should have no effect on performance. My guess is that this perf test is sitting right on the line of the acceptable range. We should confirm this hunch and then update the values to recenter the range. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 01:45:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 01:45:15 -0000 Subject: [GHC] #15745: Panicking typechecker plugins In-Reply-To: <051.0643b56f13bc8491c2a5c13a701f5bf7@haskell.org> References: <051.0643b56f13bc8491c2a5c13a701f5bf7@haskell.org> Message-ID: <066.06535eb90108042bf3fb6104bc5bebec@haskell.org> #15745: Panicking typechecker plugins -------------------------------------+------------------------------------- Reporter: philderbeast | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: Resolution: | TypeCheckerPlugins 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): Just to expand on Adam's comment (which I agree with): a plugin passes data back to GHC. If that data contains an `undefined`, then it will cause a panic, and there's no (reasonably easy) way to properly blame the plugin instead of GHC. I don't see any way to avoid this, unless we deepseq all data that the plugin returns (which isn't, on its surface, a terrible idea). However, the bald `undefined`s above should be easy enough to catch. What might be an unreasonable way to do this? To carefully track plugin- provided information using some sort of tainting process. This is, of course, doable, but of quite small benefit compared to the cost. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 03:23:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 03:23:50 -0000 Subject: [GHC] #15743: Nail down the Required/Inferred/Specified story In-Reply-To: <046.20125fa3baabaa154b0336067d36471f@haskell.org> References: <046.20125fa3baabaa154b0336067d36471f@haskell.org> Message-ID: <061.c2c35098ecc3a2367c881d5f6d8dfd40@haskell.org> #15743: Nail down the Required/Inferred/Specified story -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Here is the defining property of `Specified`: * All specified arguments have a predictable order. In other words, this order is stable regardless of what GHC's solver does. As long as we can uphold that property, then we're free to label variables as Specified. Furthermore, the place where we put Inferred variables is never important and needn't be specified. Accordingly, we can relax a few restrictions in Simon's description. I propose this algorithm instead: 1. Perform kind inference, getting a fully-settled kind for each variable. This process may introduce new kind variables we would like to quantify over. The precise process is beyond the scope of this ticket. 2. Put the variables in this order: first the newly-quantified variables never written by the user (the Inferred ones), in any order; then the Specified ones in order of first lexical occurrence, reading left-to- right; then the Required ones, in their left-to-right order. 3. Sort all these variables according to ''ScopedSort''. If ''ScopedSort'' tries to move one Required variable past another, fail. This new way of treating the variables relaxes two restrictions imposed above: that a Specified can never appear after a Required, and that an Inferred can never appear after a Specified. Here is an example: {{{ data SimilarKind :: forall (c :: k) (d :: k). Proxy c -> Proxy d -> Type data T k (c :: k) (a :: Proxy c) b (x :: SimilarKind a b) }}} We will want to quantify over `b`'s kind (call it `Proxy d`), but that kind depends on the Required `k`. Simon's approach would reject (where? it doesn't say) because we put Inferred before Specified before Required. But my approach will infer {{{ T :: forall (k :: Type) -> forall {d :: k}. forall (c :: k) (a :: Proxy c) (b :: Proxy d) -> SimilarKind a b -> Type }}} Note that `d` comes after `k`. This declaration is rejected today, whether or not we write down `b`'s kind explicitly. I had been loathe to allow such mixed quantification in the past, but now that the algorithm is written down (and can be included in the manual), I feel comfortable doing it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 07:29:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 07:29:35 -0000 Subject: [GHC] #15743: Nail down the Required/Inferred/Specified story In-Reply-To: <046.20125fa3baabaa154b0336067d36471f@haskell.org> References: <046.20125fa3baabaa154b0336067d36471f@haskell.org> Message-ID: <061.0d58eec999c02c298523d7d435da4331@haskell.org> #15743: Nail down the Required/Inferred/Specified story -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm not against comment:1, but if there turns out to be a significant implementation-cost difference, I'd go with the cheaper one and wait for cries of pain. Richard are you volunteering to implement? There are some open tickets here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 07:43:07 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 07:43:07 -0000 Subject: [GHC] #15748: panic In-Reply-To: <042.ddee66d80c6f02a82c2257ffc3132db1@haskell.org> References: <042.ddee66d80c6f02a82c2257ffc3132db1@haskell.org> Message-ID: <057.027ae9cde4652f3f82d6d8334f485b67@haskell.org> #15748: panic -------------------------------------+------------------------------------- Reporter: awf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by awf): Thanks @monoidal, agree it is a dup. I assume it's by design that the "Report a bug" link at https://ghc.haskell.org/trac/ghc/wiki/ReportABug doesn't encourage submitters to check for duplicates? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 08:16:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 08:16:58 -0000 Subject: [GHC] #15751: GHC takes huge amounts of memory and compile time when compiling ZipWith from accelerate Message-ID: <047.03b6a24c8ceca13dc1f3f31878c68000@haskell.org> #15751: GHC takes huge amounts of memory and compile time when compiling ZipWith from accelerate -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: Compile | Blocked By: `Data.Array.Accelerate.Test.NoFib.Prelude.ZipWith`| from `accelerate-1.2.0` | Blocking: | Related Tickets: #15488 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In #15488, we found that GHC takes huge amounts of memory by building up excessively large amounts of Core. Looking a the `Data.Array.Accelerate.Analysis.Hash` module there, the problem seems to be due to excessive (and unproductive) inlining. However, the `Data.Array.Accelerate.Test.NoFib.Prelude.ZipWith` module *also* takes a very large amount of time and memory to compile, and while it also builds up huge amounts of Core in unproductive ways, the blowup happens in a different step. https://github.com/AccelerateHS/accelerate/issues/428#issuecomment-425019263 has a build log that points at the first round of `Specialise` as the culprit. Just like #15488, this problem seems to trace back to GHC 8.0.2 at least, possibly further. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 08:17:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 08:17:49 -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.9ab3a4ca5c063452776bdfb4ffb3ce59@haskell.org> #15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0 -------------------------------------+------------------------------------- Reporter: noah | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.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: #15751 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tdammers): * related: => #15751 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 08:18:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 08:18: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.10c7369310dcc65f66a04c448164aef0@haskell.org> #15488: GHC takes up huge amount of memory when compiling accelerate 1.2.0 -------------------------------------+------------------------------------- Reporter: noah | Owner: tdammers Type: bug | Status: new Priority: high | Milestone: 8.8.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: #15751 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): The `ZipWith` module peformance problems seem to have a different cause; we'll look into that one separately in #15751. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 09:43:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 09:43:04 -0000 Subject: [GHC] #15725: Core Lint error: Trans coercion mis-match In-Reply-To: <050.b669cdd6d53ebfbfb35ff1834b5bd9f3@haskell.org> References: <050.b669cdd6d53ebfbfb35ff1834b5bd9f3@haskell.org> Message-ID: <065.4bf053ff73c9a5232fac0d4c493e4b9b@haskell.org> #15725: Core Lint error: Trans coercion mis-match -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15703 | Differential Rev(s): Phab:D5217 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"48efbc04bd45d806c52376641e1a7ed7278d1ec7/ghc" 48efbc0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="48efbc04bd45d806c52376641e1a7ed7278d1ec7" Fix #15725 with an extra Sym Summary: We were adding a `Sym` to one argument in the `InstCo` case of `optCoercion` but not another, leading to the two arguments to misaligned when combined via `Trans`. This fixes the issue with a well targeted use of `wrapSym`. Test Plan: make test TEST=T15725 Reviewers: goldfire, ningning, bgamari Reviewed By: goldfire, ningning Subscribers: rwbarton, carter GHC Trac Issues: #15725 Differential Revision: https://phabricator.haskell.org/D5217 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 09:43:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 09:43:04 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.702febf8dee00983b851ad922196e7f5@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.6.2 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: 15592 Related Tickets: #15076 | Differential Rev(s): Phab:D4769, | Phab:D5141, Phab:D5147, Phab:D5150, Wiki Page: | Phab:D5208 -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"08b3db7e670d7a142244466f1722cb48ab82f1f5/ghc" 08b3db7e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="08b3db7e670d7a142244466f1722cb48ab82f1f5" Use an accumulator version of tyCoVarsOfType Summary: This is part 1 from #14880: factor out a worker for the tyCoVarsOf... family of function, implementing them in terms of VarSet, but with accumulator-style (like in `FV`) built in, and with the same kind of pre-insert lookup; this has shown to perform better than either FV or plain VarSet in this particular scenario. Original notes from simonpj: 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)? Becuase 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 speical purpose code. On the way I also simplified the (less used) coVarsOfType/Co family to use FV, by making serious use of the InterestingVarFun! Test Plan: validate, nofib Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #14880 Differential Revision: https://phabricator.haskell.org/D5141 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 09:43:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 09:43:04 -0000 Subject: [GHC] #14088: Allow users to omit `forall` In-Reply-To: <051.feb84b44d4478cc8d9e34787d0f77657@haskell.org> References: <051.feb84b44d4478cc8d9e34787d0f77657@haskell.org> Message-ID: <066.5e9219b504fbcd474399e38fbc55c50e@haskell.org> #14088: Allow users to omit `forall` -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 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: | -------------------------------------+------------------------------------- Comment (by Krzysztof Gogolewski ): In [changeset:"08b3db7e670d7a142244466f1722cb48ab82f1f5/ghc" 08b3db7e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="08b3db7e670d7a142244466f1722cb48ab82f1f5" Use an accumulator version of tyCoVarsOfType Summary: This is part 1 from #14880: factor out a worker for the tyCoVarsOf... family of function, implementing them in terms of VarSet, but with accumulator-style (like in `FV`) built in, and with the same kind of pre-insert lookup; this has shown to perform better than either FV or plain VarSet in this particular scenario. Original notes from simonpj: 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)? Becuase 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 speical purpose code. On the way I also simplified the (less used) coVarsOfType/Co family to use FV, by making serious use of the InterestingVarFun! Test Plan: validate, nofib Reviewers: simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #14880 Differential Revision: https://phabricator.haskell.org/D5141 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 09:47:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 09:47:12 -0000 Subject: [GHC] #15725: Core Lint error: Trans coercion mis-match In-Reply-To: <050.b669cdd6d53ebfbfb35ff1834b5bd9f3@haskell.org> References: <050.b669cdd6d53ebfbfb35ff1834b5bd9f3@haskell.org> Message-ID: <065.457b148d4b6cd13d90292883293aa598@haskell.org> #15725: Core Lint error: Trans coercion mis-match -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15703 | Differential Rev(s): Phab:D5217 Wiki Page: | -------------------------------------+------------------------------------- Changes (by monoidal): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 09:47:16 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 09:47:16 -0000 Subject: [GHC] #15750: Investigate haddock.base perf test In-Reply-To: <047.c45d20d3b9f7fe7999748725890fca87@haskell.org> References: <047.c45d20d3b9f7fe7999748725890fca87@haskell.org> Message-ID: <062.f3615579c2f658e66d0167dc02b76d23@haskell.org> #15750: Investigate haddock.base perf test -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: My apologies for accidentally regressing this test. I pushed feb8a671a4e92922ddac108686f0eace97dd331f too hastily and forgot to update the allocations. In any case, the test was re-centered in commit 4eeeb51d5f51083d0ae393009a7fd246223e9791, so this has already been fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 09:56:41 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 09:56:41 -0000 Subject: [GHC] #15748: panic In-Reply-To: <042.ddee66d80c6f02a82c2257ffc3132db1@haskell.org> References: <042.ddee66d80c6f02a82c2257ffc3132db1@haskell.org> Message-ID: <057.784235c0cc2aceb75b17b856b66d3c0c@haskell.org> #15748: panic -------------------------------------+------------------------------------- Reporter: awf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): There is some encouragement to check for duplicates at that page, but maybe it's not visible enough; feel free to edit the wiki page. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 10:39:00 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 10:39:00 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.1a6d6eeef4754e28771c4a56cc360024@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: 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): > Build an SRT for each closure that lists the CAFFy things it mentions. It's not obvious where that is done today -- can you point to it? We don't build SRTs until Cmm (`doSRTs` in `CmmBuildInfoTables.hs`). In `TidyPgm` we decide on CAFFYness and record it in `IdInfo`s of binders. As far as I can see there are no CAF or SRT related computation done in STG. Btw, I found this commented-out code in `StgSyn`: {{{ pprStgExpr (StgLet srt (StgNonRec bndr (StgRhsClosure cc bi free_vars upd_flag args rhs)) expr@(StgLet _ _)) = ... }}} It seems like at some point someone tried to decorate `StgLet`s with SRTs. I don't understand how the CAFFYness info in Ids used in the code gen, but I wonder if even after this work there will still be room for bugs because `idCafInfo` of an id (not in binder position) may disagree with the final CAFFYness information of the id. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 12:27:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 12:27:19 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.0d387cd7bcf292bcbb17a869c12e7183@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Okay so I'm a bit stuck on implementing a version of `readHexRational :: String -> Rational` that looks like `readHexSignificandExponentPair :: String -> (Integer, Integer)` instead (where the pair returned is the significand and exponent in base 10). The hex float format has its exponent in base 2, not base 10. Should I also store the base within the `FractionalLit` type? Otherwise I'd have to do a (not very) precise conversion, and it strikes me that that'd bring us back to where we were before but on the hex side instead of the decimal side. I might give that a crack, actually. Let me know if not a good idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 15:09:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 15:09:12 -0000 Subject: [GHC] #15627: Absent unlifted bindings In-Reply-To: <044.bc86ad63a852b5821c5e83dda4b97374@haskell.org> References: <044.bc86ad63a852b5821c5e83dda4b97374@haskell.org> Message-ID: <059.0620f0231729d9a2908e524f497e2ac7@haskell.org> #15627: Absent unlifted bindings -------------------------------------+------------------------------------- Reporter: sgraf | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: ⊥ Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | stranal/should_compile/T15627 Blocked By: | Blocking: Related Tickets: #9279 #4328 | Differential Rev(s): Phab:D5153 #11126 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => stranal/should_compile/T15627 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 15:10:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 15:10:47 -0000 Subject: [GHC] #11126: Entered absent arg in a Repa program In-Reply-To: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> References: <049.08d17e678ab01e39cf7b040134e05fa3@haskell.org> Message-ID: <064.b16e2ebd9846742e93b63960ae4f59cf@haskell.org> #11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D3221 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The patch in comment:20 does ''not'' fix the bug in this ticket, which is accurately diagnosed in comment:5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 15:12:42 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 15:12:42 -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.9b3201f35b4fa81db10f0d523f993ae8@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: | -------------------------------------+------------------------------------- Comment (by simonpj): The patch in comment:23 nails issue (2) of comment:20, leaving issue (1) open. So we should not close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 15:26:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 15:26:01 -0000 Subject: [GHC] #15748: panic In-Reply-To: <042.ddee66d80c6f02a82c2257ffc3132db1@haskell.org> References: <042.ddee66d80c6f02a82c2257ffc3132db1@haskell.org> Message-ID: <057.31e15b6c655c8d30e0f0d08443828ad1@haskell.org> #15748: panic -------------------------------------+------------------------------------- Reporter: awf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > There is some encouragement to check for duplicates at that page, but maybe it's not visible enough I have amplified a bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 15:29:11 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 15:29:11 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.2b0fa7d576eccba7ae6f4cd1667bd7c6@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: 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 understand how the CAFFYness info in Ids used in the code gen, but I wonder if even after this work there will still be room for bugs because idCafInfo of an id (not in binder position) may disagree with the final CAFFYness information of the id. I think we should * Tag each binder with its CAFFYness, immediately before code generation, after any STG-to-STG passes (step 1 of comment:14). * Propagate that info into the .hi file for the module. * In SRT generation (setp 2 of comment:14, presumably in `CmmBuildInfoTables`) use a finite map of Id to CAFFYness, so that we specifically do not rely on the CAFFYness of ''occurrences'' of ''local'' Ids. (For imported Ids we should be fine.) Sound OK? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 15:41:56 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 15:41:56 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.98e5bbd28a7125eaa2ee4ffbe4e004dd@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Would you like to lay out the design, and its moving parts, in a draft Note that will eventually be part of the source code? eg I think (but am not sure) that your question is this: in representation of a literal fractional number: {{{ data FractionalLit = FL { fl_text :: SourceText -- How the value was written in the source , fl_neg :: Bool -- See Note [Negative zero] , fl_mantissa, fl_exp :: Integer -- Denotes E } }}} in what number base is the `fl_exp` expressed? For example * `1.7e30` has `fl_mantissa = 17`, and `fl_exp = 29`, assuming base 10 * But what about `0x5e.ff2p12`? Here the mantissa can reasonably still be `0x5eff`, but the exponent must (presumably, given [http://downloads.haskell.org/~ghc/master/users-guide/glasgow_exts.html #hexadecimal-floating-point-literals the spec]) be in base 2. To me it sounds as if we need another field for the exponent base to accurately represent the literal. So the value of the literal is `mantissa * (base ^ exponent)`. My instinct is just to make the a sum-type rather than another `Int` or `Integer`: {{{ data ExponentBase = Base10 | Base 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 15:48:02 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 15:48:02 -0000 Subject: [GHC] #12430: TypeFamilyDependencies accepts invalid injectivity annotation In-Reply-To: <048.bd286895ba8b7f6cc12aad47c9d255c3@haskell.org> References: <048.bd286895ba8b7f6cc12aad47c9d255c3@haskell.org> Message-ID: <063.9dbe1387eb37c5a34313e17687de8945@haskell.org> #12430: TypeFamilyDependencies accepts invalid injectivity annotation -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by monoidal): Here's a simpler version: {{{ #!hs {-# LANGUAGE TypeFamilies, PolyKinds, KindSignatures, TypeFamilyDependencies, GADTs, ScopedTypeVariables #-} module Bug where import Data.Kind (Type) data Proxy a type C a = Int type family Family (x :: Type) = (y :: Type) | y -> x where Family x = Proxy (C x) }}} `Family` shouldn't be allowed to be injective, it's a constant function: `Family Int ~ Family Bool`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 15:59:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 15:59:52 -0000 Subject: [GHC] #15192: Refactor of Coercion In-Reply-To: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> References: <047.060aeef3805df87e61a1408a60ab4dd6@haskell.org> Message-ID: <062.ca9aa86cd4182deab7b250248c1cccd9@haskell.org> #15192: Refactor of Coercion -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4747 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): About not zonking in coercions in types: I'm worried about violating `Note [The tcType invariant]` in TcHsType. I do think we'll need to zonk these. An unappealing alternative would be to have `data Coercion = ... | ZonkedCo Coercion Type Type FV`; zonking would zonk the types that the coercion relates instead of the coercion body. These types would be put into a `ZonkedCo`, along with the fvs and the unzonked underlying coercion. `zonkTcTypeToType` would then drop the `ZonkedCo` and zonk the underlying coercion instead. I don't think this is a good idea, though. Back to the main points above: Having an extra constructor for performance has a precedent: that's why we have both `TyConApp` and `FunTy`. (Both can be encoded by `AppTy`.) The problem is that it will be hard to know when to stop playing that game: we will probably always be able to identify patterns in individual test cases that would be improved by an extra constructor. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 17:03:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 17:03:47 -0000 Subject: [GHC] #15743: Nail down the Required/Inferred/Specified story In-Reply-To: <046.20125fa3baabaa154b0336067d36471f@haskell.org> References: <046.20125fa3baabaa154b0336067d36471f@haskell.org> Message-ID: <061.89d1ebeafca19a70894f17e5d51b0616@haskell.org> #15743: Nail down the Required/Inferred/Specified story -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): See also GhcKinds/KindInference/Examples for some thoughts on how we should behave. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 17:19:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 17:19:12 -0000 Subject: [GHC] #12430: TypeFamilyDependencies accepts invalid injectivity annotation In-Reply-To: <048.bd286895ba8b7f6cc12aad47c9d255c3@haskell.org> References: <048.bd286895ba8b7f6cc12aad47c9d255c3@haskell.org> Message-ID: <063.378d054baa88f0766dd49d87259adfc3@haskell.org> #12430: TypeFamilyDependencies accepts invalid injectivity annotation -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => InjectiveFamilies Comment: Even simpler: {{{#!hs {-# LANGUAGE TypeFamilyDependencies #-} module Bug where type C a = Int type family F x = y | y -> x where F x = C x }}} I'm on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 17:34:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 17:34:25 -0000 Subject: [GHC] #12430: TypeFamilyDependencies accepts invalid injectivity annotation In-Reply-To: <048.bd286895ba8b7f6cc12aad47c9d255c3@haskell.org> References: <048.bd286895ba8b7f6cc12aad47c9d255c3@haskell.org> Message-ID: <063.470e26fda694dbbcf89b607b47fdeef9@haskell.org> #12430: TypeFamilyDependencies accepts invalid injectivity annotation -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5228 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5228 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 19:37:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 19:37:39 -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.19b0e74da10e4dc9de828fd0f52a00ac@haskell.org> #14037: Fix fusion for GHC's utility functions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: rockbmb 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 rockbmb): * owner: (none) => rockbmb -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 20:42:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 20:42:13 -0000 Subject: [GHC] #15743: Nail down the Required/Inferred/Specified story In-Reply-To: <046.20125fa3baabaa154b0336067d36471f@haskell.org> References: <046.20125fa3baabaa154b0336067d36471f@haskell.org> Message-ID: <061.108afc447874f808a60c2212b632acfe@haskell.org> #15743: Nail down the Required/Inferred/Specified story -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm having second thoughts about my more permissive approach. Consider {{{#!hs data SameKind :: k -> k -> * data Bad a (c :: Proxy b) (d :: Proxy a) (x :: SameKind b d) }}} We could infer this ordering for the tyvars of `Bad`: `@{k :: Type} (a :: k) @(b :: Proxy a) (c :: Proxy b) (d :: Proxy a) (x :: SameKind b d)`. My notation indicates that `k` is Inferred, `b` is Specified, and the rest are Required. Note that a Specified is going ''after'' a Required here. Is this too clever by half? Or is it snazzy that we can accept this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 20:51:48 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 20:51:48 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.260204604912927d816af22e7b2127d9@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Simon, your supposition is just what I had in mind when I asked "Should I also store the base within the `FractionalLit` type?". A sum type for the exponent is a great idea, I hadn't even thought of it, but it makes more much sense for efficiency, intention conveyance and clarity. Thank you! Yeah, I'll lay out the design and draft note. It would have been helpful to me in the past to have known the way hex rationals work, so this would fulfil that role, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 21:43:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 21:43:20 -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.ceb1c5a228b07838d314789c278af49f@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: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: T13600a, error message | T13600b Blocked By: | Blocking: Related Tickets: #15166, #15458 | Differential Rev(s): Phab:D5040 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0b0cb484eb0b51bf5485dfadff7cd8a079ceb16e/ghc" 0b0cb484/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0b0cb484eb0b51bf5485dfadff7cd8a079ceb16e" Surprising error message with bang pattern Reviewers: bgamari, alanz Reviewed By: bgamari Subscribers: sgraf, mpickering, rwbarton, thomie, carter GHC Trac Issues: #13600 Differential Revision: https://phabricator.haskell.org/D5040 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 21:43:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 21:43:20 -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.6fca08b0e36e24635aa68347c84b981a@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 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"846fe90464a1916df4ea72659255963a596eec84/ghc" 846fe904/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="846fe90464a1916df4ea72659255963a596eec84" Typeable: Only render saturated tuple types with tuple syntax This isn't as efficient as it could be since it needs to compute the kind of the type. However, this is `show` so there shouldn't be any particular expectation of speed. Fixes #14341. Test Plan: Validate Reviewers: hvr Subscribers: monoidal, rwbarton, carter GHC Trac Issues: #14341 Differential Revision: https://phabricator.haskell.org/D5080 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 22:28:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 22:28:43 -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.15af893ce550a3ad1e0b77ececcac9c1@haskell.org> #13600: surprising error message with bang pattern -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: v0d1ch Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: BangPatterns, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: T13600a, error message | T13600b Blocked By: | Blocking: Related Tickets: #15166, #15458 | Differential Rev(s): Phab:D5040 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.8.1 Comment: Thanks for tackling this, v0d1ch! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 22:29:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 22:29:43 -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.c5391c95e64ccc75bba17eda837aee13@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 -------------------------------------+------------------------------------- Comment (by bgamari): There is still more than could be done here but at least the correctness issues are solved. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 22:32:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 22:32:45 -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.e5a04e9e51222c7f8994251af80acd84@haskell.org> #14037: Fix fusion for GHC's utility functions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: rockbmb 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: | -------------------------------------+------------------------------------- Comment (by bgamari): There is nothing that tests these functions in isolation although it's possible improvements would be reflected in the compiler allocations measured by the Nofib suite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 22:34:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 22:34:37 -0000 Subject: [GHC] #12430: TypeFamilyDependencies accepts invalid injectivity annotation In-Reply-To: <048.bd286895ba8b7f6cc12aad47c9d255c3@haskell.org> References: <048.bd286895ba8b7f6cc12aad47c9d255c3@haskell.org> Message-ID: <063.e07e0f371ad62b9d8e209dcf7cfdeb40@haskell.org> #12430: TypeFamilyDependencies accepts invalid injectivity annotation -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: patch Priority: high | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5228 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"26e81e90281685af37c8f2cf149c242b4039117a/ghc" 26e81e90/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="26e81e90281685af37c8f2cf149c242b4039117a" Fix #12430 by expanding type synonyms in injTyVarsOfType We weren't expanding type synonyms when determining the injective type variables of a type, leading to certain non-injective families being mistakenly labeled as injective (#12430). Easily fixed with a tactical use of `coreView`. Test Plan: make test TEST=T12430 Reviewers: bgamari, goldfire Reviewed By: goldfire Subscribers: goldfire, rwbarton, carter GHC Trac Issues: #12430 Differential Revision: https://phabricator.haskell.org/D5228 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 22:34:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 22:34:37 -0000 Subject: [GHC] #15738: -ddump-splices omits required parentheses around quantified constraints In-Reply-To: <050.9a7d0a45c19a0231a6c34d5b7b0c0ffb@haskell.org> References: <050.9a7d0a45c19a0231a6c34d5b7b0c0ffb@haskell.org> Message-ID: <065.a9a32de8a1a1c9f6a98a7ba152530e87@haskell.org> #15738: -ddump-splices omits required parentheses around quantified constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5222 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"02b2116e458357e87718e7378a80579a7021e2a7/ghc" 02b2116/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="02b2116e458357e87718e7378a80579a7021e2a7" Fix #15738 by defining (and using) parenthesizeHsContext With `QuantifiedConstraints`, `forall`s can appear in more nested positions than they could before, but `Convert` and the TH pretty-printer were failing to take this into account. On the `Convert` side, this is fixed by using a `parenthesizeHsContext` to parenthesize singleton quantified constraints that appear to the left of a `=>`. (A similar fix is applied to the TH pretty-printer.) Test Plan: make test TEST=T15738 Reviewers: goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15738 Differential Revision: https://phabricator.haskell.org/D5222 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 22:34:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 22:34:37 -0000 Subject: [GHC] #15723: -prof -fPIC -fexternal-dynamic-refs generates non-PIC relocations for external symbol In-Reply-To: <046.1c3e8598c6f9064f6c1ee4be47cb671b@haskell.org> References: <046.1c3e8598c6f9064f6c1ee4be47cb671b@haskell.org> Message-ID: <061.0401af3054bb77c77cc4aba4dabbb473@haskell.org> #15723: -prof -fPIC -fexternal-dynamic-refs generates non-PIC relocations for external symbol -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 (CodeGen) | 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:D5214 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"95ec7c88c7223508db3ba91d6ab9e303d0b062ad/ghc" 95ec7c88/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="95ec7c88c7223508db3ba91d6ab9e303d0b062ad" Generate correct relocation for external cost centre We used to always generate direct access for cost centre labels. We fixed this by generating indirect data load for cost centre defined in external module. Test Plan: The added test used to fail with error message ``` /bin/ld.gold: error: T15723B.o: requires dynamic R_X86_64_PC32 reloc against 'T15723A_foo1_EXPR_cc' which may overflow at runtime; recompile with -fPIC ``` and now passes. Also check that `R_X86_64_PC32` is generated for CostCentre from the same module and `R_X86_64_GOTPCREL` is generated for CostCentre from external module: ``` $ objdump -rdS T15723B.o 0000000000000028 : 28: 48 8d 45 f0 lea -0x10(%rbp),%rax 2c: 4c 39 f8 cmp %r15,%rax 2f: 72 70 jb a1 31: 48 83 ec 08 sub $0x8,%rsp 35: 48 8d 35 00 00 00 00 lea 0x0(%rip),%rsi # 3c 38: R_X86_64_PC32 T15723B_test1_EXPR_cc-0x4 3c: 49 8b bd 60 03 00 00 mov 0x360(%r13),%rdi 43: 31 c0 xor %eax,%eax 45: e8 00 00 00 00 callq 4a 46: R_X86_64_PLT32 pushCostCentre-0x4 4a: 48 83 c4 08 add $0x8,%rsp 4e: 48 ff 40 30 incq 0x30(%rax) 52: 49 89 85 60 03 00 00 mov %rax,0x360(%r13) 59: 48 83 ec 08 sub $0x8,%rsp 5d: 49 8b bd 60 03 00 00 mov 0x360(%r13),%rdi 64: 48 8b 35 00 00 00 00 mov 0x0(%rip),%rsi # 6b 67: R_X86_64_GOTPCREL T15723A_foo1_EXPR_cc-0x4 6b: 31 c0 xor %eax,%eax 6d: e8 00 00 00 00 callq 72 6e: R_X86_64_PLT32 pushCostCentre-0x4 72: 48 83 c4 08 add $0x8,%rsp 76: 48 ff 40 30 incq 0x30(%rax) ``` Reviewers: simonmar, bgamari Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15723 Differential Revision: https://phabricator.haskell.org/D5214 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 22:36:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 22:36:21 -0000 Subject: [GHC] #12430: TypeFamilyDependencies accepts invalid injectivity annotation In-Reply-To: <048.bd286895ba8b7f6cc12aad47c9d255c3@haskell.org> References: <048.bd286895ba8b7f6cc12aad47c9d255c3@haskell.org> Message-ID: <063.a675dc2d0d2a2b1da7103e9eae4dc3b1@haskell.org> #12430: TypeFamilyDependencies accepts invalid injectivity annotation -------------------------------------+------------------------------------- Reporter: vagarenko | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: fixed | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5228 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 Oct 15 22:36:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 22:36:31 -0000 Subject: [GHC] #15738: -ddump-splices omits required parentheses around quantified constraints In-Reply-To: <050.9a7d0a45c19a0231a6c34d5b7b0c0ffb@haskell.org> References: <050.9a7d0a45c19a0231a6c34d5b7b0c0ffb@haskell.org> Message-ID: <065.49a50a1aa140716464dbf563428866d9@haskell.org> #15738: -ddump-splices omits required parentheses around quantified constraints -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5222 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 22:40:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 22:40:27 -0000 Subject: [GHC] #15723: -prof -fPIC -fexternal-dynamic-refs generates non-PIC relocations for external symbol In-Reply-To: <046.1c3e8598c6f9064f6c1ee4be47cb671b@haskell.org> References: <046.1c3e8598c6f9064f6c1ee4be47cb671b@haskell.org> Message-ID: <061.8e4097e55d22a38a255272c5cc461041@haskell.org> #15723: -prof -fPIC -fexternal-dynamic-refs generates non-PIC relocations for external symbol -------------------------------------+------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5214 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 22:46:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 22:46:26 -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.2bf4cb21df29262ba38d2c3e6e474b90@haskell.org> #13600: surprising error message with bang pattern -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: v0d1ch Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.2 Resolution: fixed | Keywords: BangPatterns, | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Poor/confusing | Test Case: T13600a, error message | T13600b Blocked By: | Blocking: Related Tickets: #15166, #15458 | Differential Rev(s): Phab:D5040 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): My apologies -- I should have looked at the Phab earlier. Would it be possible to add a Note to explain what is happening in the code, perhaps near `Passer.warnSpaceAfterBang`. I believe that the specification is this: -------- GHC warns if it sees * A infix definition of `(!)` * that lacks a space before the `!` operator That is, something like {{{ x !p = e }}} where `p` is a pattern. If `BangPatterns` are on, this example would be treated as a definition of the function `x` applied the to the bang-pattern `!p`. If there is a space after the bang, thus {{{ x ! p = e }}} then the definition is treated as a definition of `(!)` (without `BangPatterns`) or as `x (!p) = e` (with `BangPatterns`), with no warning in either case. ------------ Is that the correct specification? If so, it'd be good to explain this in the user manual, and in the Note in the code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 15 23:02:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Oct 2018 23:02:49 -0000 Subject: [GHC] #15717: Performance regression in for_ alternatives from GHC 8.2.2 to newer GHCs In-Reply-To: <042.01fd95f6e2a7057fc553813802d9c3b7@haskell.org> References: <042.01fd95f6e2a7057fc553813802d9c3b7@haskell.org> Message-ID: <057.0f4aa088ece080dd167df05364150949@haskell.org> #15717: Performance regression in for_ alternatives from GHC 8.2.2 to newer GHCs -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: simonpj (added) Comment: This regression was introduced in commit 71037b61597d8e80ba5acebc8ad2295e5266dc07 (`Join-point refactoring`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 00:00:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 00:00:11 -0000 Subject: [GHC] #15278: Add -Werror=compat, enable it in the testsuite In-Reply-To: <048.fbf132fc1c72e8f658fc554d15eaed54@haskell.org> References: <048.fbf132fc1c72e8f658fc554d15eaed54@haskell.org> Message-ID: <063.a2ebe21aba98b1f57804a858f5cbf3e4@haskell.org> #15278: Add -Werror=compat, enable it in the testsuite -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"165d3d5ddaecc7dbe7f5ac051834a7619463efb0/ghc" 165d3d5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="165d3d5ddaecc7dbe7f5ac051834a7619463efb0" Enable -Wcompat=error in the testsuite Enabling -Werror=compat in the testsuite allows us to easily see the impact that a new warning has on code. It also means that in the period between adding the warning and making the actual breaking change, all new test cases that are being added to the testsuite will be forwards-compatible. This is good because it will make the actual breaking change contain less irrelevant testsuite updates. Things that -Wcompat warns about are things that are going to break in the future, so we can be proactive and keep our testsuite forwards-compatible. This patch consists of two main changes: * Add `TEST_HC_OPTS += -Werror=compat` to the testsuite configuration. * Fix all broken test cases. Test Plan: Validate Reviewers: hvr, goldfire, bgamari, simonpj, RyanGlScott Reviewed By: goldfire, RyanGlScott Subscribers: rwbarton, carter GHC Trac Issues: #15278 Differential Revision: https://phabricator.haskell.org/D5200 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 00:00:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 00:00:11 -0000 Subject: [GHC] #15729: Static GHCi can segfault when accessing .bss section in C In-Reply-To: <046.01f3ec3cee991a7182d3dc45051c529d@haskell.org> References: <046.01f3ec3cee991a7182d3dc45051c529d@haskell.org> Message-ID: <061.08f7f367ee5b46e78bd9b62be5d56d99@haskell.org> #15729: Static GHCi can segfault when accessing .bss section in C -------------------------------+-------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #781 | Differential Rev(s): Phab:D5219 Wiki Page: | -------------------------------+-------------------------------------- Comment (by Ben Gamari ): In [changeset:"8306141397d6e47a169dbe4b7ff1b3319a502aa7/ghc" 83061413/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8306141397d6e47a169dbe4b7ff1b3319a502aa7" Allocate bss section within proper range of other sections Allocate bss section within proper range of other sections: * when `+RTS -xp` is passed, allocate it contiguously as we did for jump islands * when we mmap the code to lower 2Gb, we should allocate bss section there too This depends on {D5195} Test Plan: 1. `./validate` 2. with ``` DYNAMIC_GHC_PROGRAMS = NO DYNAMIC_BY_DEFAULT = NO ``` `TEST="T15729" make test` passed in both linux and macos. 3. Also test in a use case where we used to encouter error like: ``` ghc-iserv-prof: R_X86_64_PC32 relocation out of range: (noname) = b90282ba ``` and now, everything works fine. Reviewers: simonmar, bgamari, angerman, erikd Reviewed By: simonmar Subscribers: rwbarton, carter GHC Trac Issues: #15729 Differential Revision: https://phabricator.haskell.org/D5219 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 00:00:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 00:00:11 -0000 Subject: [GHC] #1: Implicit parameters cause strange behavi In-Reply-To: <045.dd635ef62f3ce1d5e8bfe2b4cd36b0de@haskell.org> References: <045.dd635ef62f3ce1d5e8bfe2b4cd36b0de@haskell.org> Message-ID: <060.fcef7add465056c36161f42f8454a755@haskell.org> #1: Implicit parameters cause strange behavi --------------------------------+-------------------- Reporter: nobody | Owner: nobody Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 5.0 Resolution: Fixed | Keywords: Type of failure: None/Unknown | --------------------------------+-------------------- Comment (by Ben Gamari ): In [changeset:"104599f3f157613589e78627c915e4dc20ee54b4/ghc" 104599f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="104599f3f157613589e78627c915e4dc20ee54b4" Add a RTS option -xp to load PIC object anywhere in address space Add a RTS option -xp to load PIC object anywhere in address space. We do this by relaxing the requirement of <0x80000000 result of `mmapForLinker` and implying USE_CONTIGUOUS_MMAP. We also need to change calls to `ocInit` and `ocGetNames` to avoid dangling pointers when the address of `oc->image` is changed by `ocAllocateSymbolExtra`. Test Plan: ``` $ uname -a Linux localhost 4.18.8-arch1-1-ARCH #1 SMP PREEMPT Sat Sep 15 20:34:48 UTC 2018 x86_64 GNU/Linux $ cat mk/build.mk DYNAMIC_GHC_PROGRAMS = NO DYNAMIC_BY_DEFAULT = NO GhcRTSWays += thr_debug EXTRA_HC_OPTS += -debug WAY_p_HC_OPTS += -fPIC -fexternal-dynamic-refs $ inplace/bin/ghc-stage2 --interactive -prof +RTS -xp GHCi, version 8.7.20180928: http://www.haskell.org/ghc/ :? for help ghc-stage2: R_X86_64_32 relocation out of range: ghczmprim_GHCziTypes_ZMZN_closure = 7f690bffab59 Recompile /data/users/watashi/ghc/libraries/ghc-prim/dist-install/build/HSghc-prim -0.5.3.o with -fPIC -fexternal-dynamic-refs. ghc-stage2: unable to load package `ghc-prim-0.5.3' $ strace -f -e open,mmap inplace/bin/ghc-stage2 --interactive -prof -fexternal-interpreter -opti+RTS -opti-xp ... [pid 1355283] open("/data/users/watashi/ghc/libraries/base/dist-install/build/libHSbas e-4.12.0.0_p.a", O_RDONLY) = 14 [pid 1355283] mmap(NULL, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6a84842000 [pid 1355283] open("/data/users/watashi/ghc/libraries/base/dist-install/build/libHSbas e-4.12.0.0_p.a", O_RDONLY) = 14 [pid 1355283] mmap(NULL, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6a84676000 ... Prelude> System.Posix.Process.getProcessID ... [pid 1355283] open("/data/users/watashi/ghc/libraries/unix/dist-install/build/libHSuni x-2.7.2.2_p.a", O_RDONLY) = 14 [pid 1355283] mmap(NULL, 45056, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6a67d60000 [pid 1355283] open("/data/users/watashi/ghc/libraries/unix/dist-install/build/libHSuni x-2.7.2.2_p.a", O_RDONLY) = 14 [pid 1355283] mmap(NULL, 57344, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f6a67d52000 ... ``` ``` $ uname -a Darwin watashis-iMac.local 18.0.0 Darwin Kernel Version 18.0.0: Wed Aug 22 20:13:40 PDT 2018; root:xnu-4903.201.2~1/RELEASE_X86_64 x86_64 $ mv /Users/watashi/gao/ghc/libraries/integer-gmp/dist-install/build/HSintege r-gmp-1.0.2.0.o{,._DISABLE_GHC_ISSUE_15105} $ inplace/bin/ghc-stage2 --interactive +RTS -xp GHCi, version 8.7.20181003: http://www.haskell.org/ghc/ :? for help Prelude> System.Posix.Process.getProcessID 42791 Prelude> Data.Set.fromList [1 .. 10] fromList [1,2,3,4,5,6,7,8,9,10] Prelude> Leaving GHCi. $ inplace/bin/ghc-stage2 --interactive -prof -fexternal-interpreter GHCi, version 8.7.20181003: http://www.haskell.org/ghc/ :? for help Prelude> System.Posix.Process.getProcessID 42806 Prelude> Data.Set.fromList [1 .. 10] fromList [1,2,3,4,5,6,7,8,9,10] Prelude> Leaving GHCi. ``` Also test with something that used to hit the 2Gb limit and it loads and runs without problem. Reviewers: simonmar, bgamari, angerman, Phyx, hvr, erikd Reviewed By: simonmar Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5195 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 00:00:11 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 00:00:11 -0000 Subject: [GHC] #8316: GHCi debugger panics when trying force a certain variable In-Reply-To: <044.9ebacfadd8f49d7b017849858920cbb4@haskell.org> References: <044.9ebacfadd8f49d7b017849858920cbb4@haskell.org> Message-ID: <059.d765b1a750b0b355ad8a16b882309a37@haskell.org> #8316: GHCi debugger panics when trying force a certain variable -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: debugger Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4535, Wiki Page: | Phab:D5179 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"45ed4619fd5cfe785bbf1142b9d16e4f3c5148ce/ghc" 45ed461/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="45ed4619fd5cfe785bbf1142b9d16e4f3c5148ce" Fix BLACKHOLE inspection in RtClosureInspect When inspecing a BLACKHOLE if the BLACKHOLE points to a TSO or a BLOCKING_QUEUE we should return a suspension to the BLACKHOLE itself (instead of returning a suspension to the indirectee). The reason is because in the debugger when we want to evaluate this term we need to enter the BLACKHOLE and not to the TSO or BLOCKING_QUEUE. See the runtime panic caused by this in #8316. Note that while with this patch we do the right thing to evaluate thunks in GHCi, evaluating thunks that are owned by the evaluator thread in a breakpoint will cause a deadlock as we don't release the breakMVar, which is what blocks the evaluator thread from continuing with evaluation. So the GHCi thread will enter the BLACKHOLE, but owner of the BLACKHOLE is also blocked. Reviewers: simonmar, hvr, bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #8316 Differential Revision: https://phabricator.haskell.org/D5179 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 00:50:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 00:50:59 -0000 Subject: [GHC] #15350: gcdExtInteger violates assertion In-Reply-To: <047.463f72a51535cf21b879b51cdb0841bf@haskell.org> References: <047.463f72a51535cf21b879b51cdb0841bf@haskell.org> Message-ID: <062.6cbca1d416d62363096613d6a2fa5f4a@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: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"45d5eff820aefd42454a7b9f25c4a61dbfca1ad5/ghc" 45d5eff/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="45d5eff820aefd42454a7b9f25c4a61dbfca1ad5" Update integer_gmp_gcdext documentation. Reviewers: hvr, bgamari, monoidal Reviewed By: monoidal Subscribers: rwbarton, carter GHC Trac Issues: #15350 Differential Revision: https://phabricator.haskell.org/D5091 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 01:37:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 01:37:12 -0000 Subject: [GHC] #15278: Add -Werror=compat, enable it in the testsuite In-Reply-To: <048.fbf132fc1c72e8f658fc554d15eaed54@haskell.org> References: <048.fbf132fc1c72e8f658fc554d15eaed54@haskell.org> Message-ID: <063.b0457416caff97ace85b4505d8b213a3@haskell.org> #15278: Add -Werror=compat, enable it in the testsuite -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: I believe that should finish this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 01:39:14 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 01:39:14 -0000 Subject: [GHC] #8316: GHCi debugger panics when trying force a certain variable In-Reply-To: <044.9ebacfadd8f49d7b017849858920cbb4@haskell.org> References: <044.9ebacfadd8f49d7b017849858920cbb4@haskell.org> Message-ID: <059.dbb91e78531b2f8ecf04753e41e2ad1d@haskell.org> #8316: GHCi debugger panics when trying force a certain variable -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: GHCi | Version: 7.6.3 Resolution: fixed | Keywords: debugger Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4535, Wiki Page: | Phab:D5179 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 01:39:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 01:39:39 -0000 Subject: [GHC] #15729: Static GHCi can segfault when accessing .bss section in C In-Reply-To: <046.01f3ec3cee991a7182d3dc45051c529d@haskell.org> References: <046.01f3ec3cee991a7182d3dc45051c529d@haskell.org> Message-ID: <061.ded4b17003a728748f4fbf15ae88f547@haskell.org> #15729: Static GHCi can segfault when accessing .bss section in C -------------------------------+-------------------------------------- Reporter: watashi | Owner: watashi Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: GHCi | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #781 | Differential Rev(s): Phab:D5219 Wiki Page: | -------------------------------+-------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 02:04:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 02:04:50 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.698ced5ed093e6e193ad658f3cfc33e4@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Here's my suggested draft, so far: {{{ data FractionalLit = FL { fl_text :: SourceText -- How the value was written in the source , fl_neg :: Bool -- See Note [Negative zero] , fl_signi :: Integer -- The significand component of the literal , fl_exp :: Integer -- The exponent component of the literal , fl_exp_base :: FractionalExponentBase -- See Note [Fractional exponent bases] } data FractionalExponentBase = Base2 | Base10 -- Note [fractional exponent bases] For hexadecimal rationals of -- the form 0x0.3p10 the exponent is given on base 2 rather than -- base 10. These are the only options, hence the sum type. See also #15646. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 02:50:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 02:50:07 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.47e0a60d61f38a506ad9d04dd97089bf@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Hm... now, following the refactoring of changing the types, I'm up against this, in `Convert.hs`: {{{ cvtOverLit (RationalL r) = do { force r; return $ mkHsFractional (mkFractionalLit r) } }}} ... which clearly doesn't type-check anymore because it's expecting a `RationalL r` where `r :: Rational`. Given the `Lit` types for `TH` don't include anything remotely compatible with this, I'm not too sure what to do. Can we change `TH` syntax? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 06:05:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 06:05:41 -0000 Subject: [GHC] #8316: GHCi debugger panics when trying force a certain variable In-Reply-To: <044.9ebacfadd8f49d7b017849858920cbb4@haskell.org> References: <044.9ebacfadd8f49d7b017849858920cbb4@haskell.org> Message-ID: <059.bb217b5c1f03d96a2a1fd1f770c454aa@haskell.org> #8316: GHCi debugger panics when trying force a certain variable -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: GHCi | Version: 7.6.3 Resolution: fixed | Keywords: debugger Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4535, Wiki Page: | Phab:D5179 -------------------------------------+------------------------------------- Comment (by osa1): Should this really be closed? I thought we want to do implement rest of the ideas in comment:19 too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 06:59:32 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 06:59:32 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.f08ffc4de671f1992adc688ac19f659c@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Right, so there's a brief discussion about this in comment:29, however we can't convert a `Rational` to the new `FractionalLit` type so the idea doesn't quite work. Changing TH syntax is not easy becuase it's a user-facing type (would need a proposal). One idea comes to mind is to make `FractionalLit` a sum type, with an alternative for the old `FractionalLit` values: {{{ data FractonalLit = FL { ... } -- | TemplateHaskell fractional lit: we lose information during conversion -- from Haskell syntax to TH syntax (happens when desugaring quasiquotes, in -- DsMeta) where we convert a `FL` to a `Rational` because that's what TH -- syntax wants. | THFL { fl_text :: SourceText , fl_next :: Bool , fl_value :: Rational } }}} Then we can propose a change to the TH syntax, depending on the result we can remove the `THFL` constructor. Alternatively, Simon suggests finding an approximate conversion of a `Rational` to the new `FractionalLit` in comment:30. That'd fine to get the code to compile but it won't be mergeable until the conversion is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 08:58:34 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 08:58:34 -0000 Subject: [GHC] #14784: RTS header files can't be used with a C++ compiler In-Reply-To: <046.915be18a946df960093f8bf95e37faf5@haskell.org> References: <046.915be18a946df960093f8bf95e37faf5@haskell.org> Message-ID: <061.31d307b0276eff186460d8966f627256@haskell.org> #14784: RTS header files can't be used with a C++ compiler -------------------------------------+------------------------------------- Reporter: niteria | Owner: hvr Type: bug | Status: new Priority: highest | Milestone: 8.4.1 Component: Runtime System | 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 gilmi): Hello, any news on this bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 09:45:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 09:45:17 -0000 Subject: [GHC] #15752: Renaming `Pat` in `HsSyn` to `HsPat` for Consistency Message-ID: <050.def3f5fe4c2cdb305a2a1dff5267be5d@haskell.org> #15752: Renaming `Pat` in `HsSyn` to `HsPat` for Consistency -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 09:47:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 09:47:07 -0000 Subject: [GHC] #15752: Renaming `Pat` in `HsSyn` to `HsPat` for Consistency In-Reply-To: <050.def3f5fe4c2cdb305a2a1dff5267be5d@haskell.org> References: <050.def3f5fe4c2cdb305a2a1dff5267be5d@haskell.org> Message-ID: <065.271c8b00031ae5d854630a4dba31cc1c@haskell.org> #15752: Renaming `Pat` in `HsSyn` to `HsPat` for Consistency -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Shayan-Najd: Old description: New description: Other datatypes in `HsSyn` are prefixed as `Hs...`, except `Pat`. The datatype `Pat` should be renamed to `HsPat` for consistency. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 12:28:42 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 12:28:42 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.b1f37e495d38839480e6ccaa12f2ea02@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Thanks osa1. I'm working on doing the sum type for `FractionalLit` as well. It's coming along nicely, I think. I'm looking forward to finishing it and getting what I'm sure will be a lot of feedback. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 13:08:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 13:08:28 -0000 Subject: [GHC] #15753: Inconsistent pattern-match warnings when using guards versus case expressions Message-ID: <050.11cbf5f3c28baba4d6b09c776c82eb41@haskell.org> #15753: Inconsistent pattern-match warnings when using guards versus case expressions -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 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: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following code (apologies for the rather non-minimal example): {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE EmptyCase #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} {-# OPTIONS_GHC -Wall -Wno-unticked-promoted-constructors #-} module Bug where import Data.Kind import Data.Type.Bool import Data.Type.Equality ((:~:)(..)) import Data.Void data family Sing :: forall k. k -> Type data instance Sing :: Bool -> Type where SFalse :: Sing False STrue :: Sing True data instance Sing :: forall a. [a] -> Type where SNil :: Sing '[] SCons :: Sing x -> Sing xs -> Sing (x:xs) data instance Sing :: forall a b. (a, b) -> Type where STuple2 :: Sing x -> Sing y -> Sing '(x, y) newtype instance Sing (f :: k1 ~> k2) = SLambda { (@@) :: forall t. Sing t -> Sing (f @@ t) } data TyFun :: Type -> Type -> Type type a ~> b = TyFun a b -> Type infixr 0 ~> type family (f :: k1 ~> k2) @@ (x :: k1) :: k2 infixl 9 @@ newtype Map k v = MkMap [(k, v)] data instance Sing :: forall k v. Map k v -> Type where SMkMap :: Sing x -> Sing (MkMap x) type family MapEmpty :: Map k v where MapEmpty = MkMap '[] type family MapInsertWith (f :: v ~> v ~> v) (new_k :: k) (new_v :: v) (m :: Map k v) :: Map k v where MapInsertWith _ new_k new_v (MkMap '[]) = MkMap '[ '(new_k, new_v)] MapInsertWith f new_k new_v (MkMap ('(old_k,old_v):old_kvs)) = If (old_k == new_k) (MkMap ('(new_k,f @@ new_v @@ old_v):old_kvs)) (Case (MapInsertWith f new_k new_v (MkMap old_kvs)) old_k old_v) type family Case (m :: Map k v) (old_k :: k) (old_v :: v) :: Map k v where Case (MkMap kvs) old_k old_v = MkMap ('(old_k,old_v) : kvs) sMapInsertWith :: forall k v (f :: v ~> v ~> v) (new_k :: k) (new_v :: v) (m :: Map k v). SEq k => Sing f -> Sing new_k -> Sing new_v -> Sing m -> Sing (MapInsertWith f new_k new_v m) sMapInsertWith _ snew_k snew_v (SMkMap SNil) = SMkMap (STuple2 snew_k snew_v `SCons` SNil) sMapInsertWith sf snew_k snew_v (SMkMap (STuple2 sold_k sold_v `SCons` sold_kvs)) = case sold_k %== snew_k of STrue -> SMkMap (STuple2 snew_k (sf @@ snew_v @@ sold_v) `SCons` sold_kvs) SFalse -> case sMapInsertWith sf snew_k snew_v (SMkMap sold_kvs) of SMkMap skvs -> SMkMap (STuple2 sold_k sold_v `SCons` skvs) class PEq a where type (x :: a) == (y :: a) :: Bool class SEq a where (%==) :: forall (x :: a) (y :: a). Sing x -> Sing y -> Sing (x == y) mapInsertWithNonEmpty1 :: forall k v (f :: v ~> v ~> v) (old_k :: k) (old_v :: v) (old_kvs :: [(k,v)]) (new_k :: k) (new_v :: v) (m :: Map k v). SEq k => Sing f -> Sing new_k -> Sing new_v -> Sing m -> m :~: MkMap ('(old_k,old_v) : old_kvs) -> MapInsertWith f new_k new_v m :~: MapEmpty -> Void mapInsertWithNonEmpty1 sf snew_k snew_v (SMkMap sm) Refl Refl | STuple2 sold_k _ `SCons` sold_kvs <- sm , SFalse <- sold_k %== snew_k = case sMapInsertWith sf snew_k snew_v (SMkMap sold_kvs) of {} mapInsertWithNonEmpty2 :: forall k v (f :: v ~> v ~> v) (old_k :: k) (old_v :: v) (old_kvs :: [(k,v)]) (new_k :: k) (new_v :: v) (m :: Map k v). SEq k => Sing f -> Sing new_k -> Sing new_v -> Sing m -> m :~: MkMap ('(old_k,old_v) : old_kvs) -> MapInsertWith f new_k new_v m :~: MapEmpty -> Void mapInsertWithNonEmpty2 sf snew_k snew_v (SMkMap sm) Refl Refl | STuple2 sold_k _ `SCons` sold_kvs <- sm = case sold_k %== snew_k of SFalse -> case sMapInsertWith sf snew_k snew_v (SMkMap sold_kvs) of {} }}} If you compile this with GHC 8.6.1 or later, you'll notice something interesting happening with the pattern-match coverage checker warnings: {{{ $ /opt/ghc/8.6.1/bin/ghci Bug.hs GHCi, version 8.6.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:78:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘mapInsertWithNonEmpty1’: Patterns not matched: _ _ _ (SMkMap _) Refl Refl | 78 | mapInsertWithNonEmpty1 sf snew_k snew_v (SMkMap sm) Refl Refl | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... Ok, one module loaded. }}} `mapInsertWithNonEmpty1` is deemed non-exhaustive, but `mapInsertWithNonEmpty2` is deemed exhaustive. However, the code for the two functions are functionally identical—the only difference is that `mapInsertWithNonEmpty1` uses one more pattern guard than `mapInsertWithNonEmpty2` does. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 13:19:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 13:19:50 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.2c8bd16c0aa6094e58fbd812e2c14a95@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: bgamari, osa1 Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #15630 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): I've instrumented GHC to dump more intermediate information during SpecConstr. Specifically, I've added the following logic: In `scExpr`, capture the expression to be specialized before and after specialization; then compare number of terms to detect a blowup (a factor of 2 is enough to weed out the non-blowups), and if this particular incantation does in fact blow up, dump the expression before the blowup. The resulting dump is a bit too large to attach, but it shows a typical pattern: the expressions that blow up all look very much alike; as we progress through the compilation, the "before" size stays at ~6000 terms, while the "after" size progressively increases, and it looks like expressions from earlier incantations get inlined into expressions later in the process. Which fits the hypothesis from the GHC HQ meeting, namely, that the inlining heuristic only looks at the size of the inlinee, but not at the inlining context, so when something gets inlined "top-down", then functions to be inlined (which don't have their own dependencies inlined yet) are all still small, and so the inliner happily copies them many times, and then in the next round, it inlines exponentially more invocations of the inlined functions' dependencies, and so on. For example, given: {{{#!haskell f = g1 + g2 + g3 + g4 + g5 g1 = a1 + a2 + a3 + a4 g2 = b1 + b2 + b3 + b4 ... }}} ...the inlining heuristic will first look at `f`, conclude that each of `g1` through `g5` is small, and can thus be inlined; then after inlining, it will look at f again, and conclude that each of `a1` etc. is small, and inline those; and if those have further dependencies following the same matter, it will happily keep inlining all those small things, not realizing that it is creating a monstrosity. And because all the inlinees involved are different, there will not be any opportunities for optimizations that might shrink things back down, so the resulting program just keeps growing exponentially. One fun thing I'll try now is this: Considering that I already have code in place to detect blowups, I can trivially use this logic to just say "if this blows up, then throw away the specialized Core, and use the original expression instead". So I'll try that, and see what that does to various performance metrics. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 13:26:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 13:26:59 -0000 Subject: [GHC] #15743: Nail down the Required/Inferred/Specified story In-Reply-To: <046.20125fa3baabaa154b0336067d36471f@haskell.org> References: <046.20125fa3baabaa154b0336067d36471f@haskell.org> Message-ID: <061.177acec182f4327ba3c832899ec6dac7@haskell.org> #15743: Nail down the Required/Inferred/Specified story -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * cc: xnning (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 14:12:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 14:12:52 -0000 Subject: [GHC] #15753: Inconsistent pattern-match warnings when using guards versus case expressions In-Reply-To: <050.11cbf5f3c28baba4d6b09c776c82eb41@haskell.org> References: <050.11cbf5f3c28baba4d6b09c776c82eb41@haskell.org> Message-ID: <065.804abe53f878f98fc671347a5cf0377d@haskell.org> #15753: Inconsistent pattern-match warnings when using guards versus case expressions -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Here is a slightly smaller example: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE EmptyCase #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UndecidableInstances #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Bug where import Data.Kind (Type) import Data.Type.Equality ((:~:)(..)) import Data.Void (Void) data SBool :: Bool -> Type where SFalse :: SBool False STrue :: SBool True data SUnit :: () -> Type where SUnit :: SUnit '() type family IsUnit (u :: ()) :: Bool where IsUnit '() = True sIsUnit :: SUnit u -> SBool (IsUnit u) sIsUnit SUnit = STrue type family If (c :: Bool) (t :: Type) (f :: Type) :: Type where If True t _ = t If False _ f = f type family F (u1 :: ()) (u2 :: ()) :: Type where F u1 u2 = If (IsUnit u1) (Case u2) Int type family Case (u :: ()) :: Type where Case '() = Int g1 :: F u1 u2 :~: Char -> SUnit u1 -> SUnit u2 -> Void g1 Refl su1 su2 | STrue <- sIsUnit su1 = case su2 of {} g2 :: F u1 u2 :~: Char -> SUnit u1 -> SUnit u2 -> Void g2 Refl su1 su2 = case sIsUnit su1 of STrue -> case su2 of {} }}} {{{ $ /opt/ghc/8.6.1/bin/ghci Bug.hs GHCi, version 8.6.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:40:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘g1’: Patterns not matched: Refl _ _ | 40 | g1 Refl su1 su2 | ^^^^^^^^^^^^^^^... Ok, one module loaded. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 14:42:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 14:42:18 -0000 Subject: [GHC] #15743: Nail down the Required/Inferred/Specified story In-Reply-To: <046.20125fa3baabaa154b0336067d36471f@haskell.org> References: <046.20125fa3baabaa154b0336067d36471f@haskell.org> Message-ID: <061.f7b2e0de89cbfdd8bc76ca4b392e2271@haskell.org> #15743: Nail down the Required/Inferred/Specified story -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Ningning (@xnning) and I just had a great conversation about all this. Amazingly, `Bad` is accepted by Idris (`data T5 : (a : _) -> (c : Proxy b) -> (d : Proxy a) -> (x : SameKind b d) -> Type`), as is my `T` in comment:1. This means Idris must surely be doing ScopedSort or something very similar. We can't let ourselves be out-inferred by them, so let's do it, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 14:58:16 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 14:58:16 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.c0141fc7a90927448257dadbc7e9ed28@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201, Phab:D5226 -------------------------------------+------------------------------------- Comment (by simonpj): We decided ''not'' to attempt to put Phab:D5226 on GHC 8.6. It's not necessary to fix 8.6. Instead Omer will include it on his `wip/T15696` branch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 15:01:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 15:01:59 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.a70283f3cc7ef69973b7441cc179b472@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.6.2 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: 15592 Related Tickets: #15076 | Differential Rev(s): Phab:D4769, | Phab:D5141, Phab:D5147, Phab:D5150, Wiki Page: | Phab:D5208 -------------------------------------+------------------------------------- Comment (by simonpj): Step 2 is Phab:D5147 and `wip/T14880​-2-step2-c​123`. Two validation failures. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 15:11:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 15:11:49 -0000 Subject: [GHC] #15753: Inconsistent pattern-match warnings when using guards versus case expressions In-Reply-To: <050.11cbf5f3c28baba4d6b09c776c82eb41@haskell.org> References: <050.11cbf5f3c28baba4d6b09c776c82eb41@haskell.org> Message-ID: <065.3c9cd755fd86a39a5a62c3fdd55f9f42@haskell.org> #15753: Inconsistent pattern-match warnings when using guards versus case expressions -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Even simpler: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TypeOperators #-} {-# OPTIONS_GHC -Wincomplete-patterns #-} module Bug where import Data.Type.Equality data G a where GInt :: G Int GBool :: G Bool ex1, ex2, ex3 :: a :~: Int -> G a -> () ex1 Refl g | GInt <- id g = () ex2 Refl g | GInt <- g = () ex3 Refl g = case id g of GInt -> () }}} {{{ $ /opt/ghc/8.6.1/bin/ghci Bug.hs GHCi, version 8.6.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/ryanglscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:17:1: warning: [-Wincomplete-patterns] Pattern match(es) are non-exhaustive In an equation for ‘ex1’: Patterns not matched: Refl _ | 17 | ex1 Refl g | ^^^^^^^^^^... }}} This time, I've included three examples. In particular, note that `ex1` and `ex2` are //extremely// similar—the only difference is the use of `id`! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 15:11:51 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 15:11:51 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.ffe35224c591a7c3f9a70658ff06abea@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: bgamari, osa1 Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #15630 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Suggestion from Simon PJ: track nesting depth through `SpecConstr`, and just stop specializing after exceeding some threshold. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 15:12:41 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 15:12:41 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.8172ab20a7e1a986a4448d7d92ef2d4a@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 15:17:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 15:17:58 -0000 Subject: [GHC] #15753: Inconsistent pattern-match warnings when using guards versus case expressions In-Reply-To: <050.11cbf5f3c28baba4d6b09c776c82eb41@haskell.org> References: <050.11cbf5f3c28baba4d6b09c776c82eb41@haskell.org> Message-ID: <065.4a44a3ff9a9a0ad548f45b60cf381cbf@haskell.org> #15753: Inconsistent pattern-match warnings when using guards versus case expressions -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): A workaround is to bind the result of `id g` to some auxiliary variable. For instance, both of the following variants of `ex1` are deemed to be exhaustive: {{{#!hs ex1a, ex1b :: a :~: Int -> G a -> () ex1a Refl g | let g' = id g , GInt <- g' = () ex1b Refl g | g' <- id g , GInt <- g' = () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 15:20:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 15:20:03 -0000 Subject: [GHC] #15754: Move free variable computation to after STG passes Message-ID: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> #15754: Move free variable computation to after STG passes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 15:22:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 15:22:46 -0000 Subject: [GHC] #15754: Move free variable computation to after STG passes In-Reply-To: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> References: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> Message-ID: <061.fb61a9a16751174c5c23c64ad5e91950@haskell.org> #15754: Move free variable computation to after STG passes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: Old description: New description: Currently (we believe) `CoreToStg` is responsible for computing free variables. However, later STG transformations may invalidate this information. It would make more sense to defer FV computation until the end of the STG pipeline. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 15:23:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 15:23:59 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.a28eb46cc78e89210c7b771bef42ef43@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: bgamari, osa1 Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #15630 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Hypothesis: * `SpecConstr` is specialising a function `f1` * In `f`'s RHS there is a local function `f2` * In each specialised copy of `f1` we create two specialised copies of `f2` * Alas `f2` has a nested function `f3` -- and it too specialises... and so on. Result: the specialised code is exponential in the nesting depth. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 15:28:18 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 15:28:18 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.0fb041422c0ef9f16075fd2750763ac0@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: bgamari, osa1 Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #15630 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Solution 1 (brutal): keep track of nesting depth, and simply stop specialising at some depth. Solution 2 (nicer): I think the actual code in this example looks like {{{ join j1 x = join j2 y = join j3 z = blah3 in blah2 in blah1 in blah0 }}} (only nested more deeply). I've been working (slowly) on a join-point-floating patch that would do a kind of local lambda lifting to give {{{ join j3 x y z = blah3 in join j2 x y = blah2 in join j1 x = blah1 in blah0 }}} This would specialise a lot better, I think. Tobias will try (1); I will get back to (2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 15:44:38 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 15:44:38 -0000 Subject: [GHC] #15754: Move free variable computation to after STG passes In-Reply-To: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> References: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> Message-ID: <061.9ba2e7596fbc304d009e9db9dd3fb8df@haskell.org> #15754: Move free variable computation to after STG passes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 16:49:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 16:49:02 -0000 Subject: [GHC] #15743: Nail down the Required/Inferred/Specified story In-Reply-To: <046.20125fa3baabaa154b0336067d36471f@haskell.org> References: <046.20125fa3baabaa154b0336067d36471f@haskell.org> Message-ID: <061.bc7717b5432e5c852e2f60a3e6db9434@haskell.org> #15743: Nail down the Required/Inferred/Specified story -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This is still not really working out to my satisfaction. Let's reconsider my example from comment:1. {{{#!hs data SimilarKind :: forall (c :: k) (d :: k). Proxy c -> Proxy d -> Type data T k (c :: k) (a :: Proxy c) b (x :: SimilarKind a b) }}} To get this to be accepted, we must infer this order for the tyvars of `T`, using `@` to denote Specified and `@{..}` to denote Inferred: `k @{d} c a b x`. Note that an Inferred comes after a Required. I'm confident that we can come up with an algorithm to do this. I'm even somewhat confident that the algorithm will be well-specified (including ScopedSort in its specification). However, what if we rewrite this to become {{{#!hs data T' :: forall k (c :: k) (a :: Proxy c) (b :: _) (x :: SimilarKind a b) -> Type }}} Really, `T'` and `T` should be treated the same. Yet to accept `T'`, we would have to insert a variable in that telescope that isn't there. Here's another example worth pondering here, from #14880: {{{#!hs data Foo (x :: Type) :: forall (a :: x). Proxy a -> Type quux :: forall arg. Proxy (Foo arg) -> () }}} We get `Foo :: forall (x :: Type) -> forall (a :: x). Proxy a -> Type`. In the type of `quux`, when we say `Proxy (Foo arg)`, GHC needs to add the implicit application to some variable `alpha` -- otherwise, the implicit kind argument to `Proxy` would have to have a `forall` in it, and that would be impredicative. So we have `quux :: forall arg. Proxy (Foo arg @alpha) -> ()`. The type of `alpha` must be `arg`, but `alpha` is otherwise unconstrained. The polite thing to do would be to quantify over `alpha`, but the only way to do so is to quantify it ''after'' `arg`, thusly: `quux :: forall (arg :: Type) {a :: arg}. Proxy (Foo arg @a) -> ()`. Sadly, we don't allow implicit quantification in the ''middle'' of a type, saying that all implicit quantification must occur directly after the `::`. So, instead of quantifying `alpha`, we zap it to `Any`, yielding `quux :: forall (arg :: Type). Proxy (Foo arg @Any) -> ()`, which is probably not what the user wants, anyway. This is relevant here because the action in `quux` is just like the action in `T'`: both require inserting an implicit quantification in the ''middle'' of a telescope. Also of interest: both `T'` and `quux` are accepted in Idris, with implicit quantification arising the middle of telescopes. (`T` is syntactically not allowed.) I see a few options here (when I say "allow `quux`, I mean to quantify over `alpha` instead of zap it): 1. Disallow all of these declarations. This makes us less powerful than Idris, but it's internally consistent. 2. Allow `T` but not the others. This means that we can insert variables into a list of tyvarbinders in a type/class declaration, but not in a `forall`. 3. Allow `T` and `T'` but not `quux`. This means that we special-case `forall`s in the return kind of type/class declarations to allow variable insertion in the middle of telescopes. 4. Allow them all. The rule for things like `quux` is that we allow insertion of implicit variables into ''top-level'' quantification only, but not necessarily immediately after the `::`. Note that top-level quantification is already special, in that it brings `ScopedTypeVariables` into scope, while inner quantifications do not. As a further experiment, I tried `quux2 : Int -> ({arg : _} -> Proxy (Foo arg)) -> Int` in Idris, to see if it was clever enough to figure this out in a higher-rank situation. Idris said `No such variable arg`. I think this is because it tried to quantify `alpha` at top-level, which is ill- scoped. So I think sticking to top-level implicit quantification is fine. Options 1-3 have a similar implementation cost. (You might think that all the variable swizzling is hard to implement. It's not particularly bad, and we have to do it anyway to attack #15591 and #15592 satisfactorily.) Note that higher-numbered options require less work to generate sensible error messages, which is non-trivial here. Option 4 is a bit worse because of the way the AST stores implicit quantification of variable declarations. I don't think it would be too bad, though. I'm really torn between these options. Probably (1) is the safest territory, but it irks me not to accept these other programs (short of `quux`), when they have truly unambiguous, well specified meanings, and it's not hard to write an algorithm to accept them. I don't like (2) because it shouldn't have to matter where I put the `::`. And (3) shows up a jarring inconsistency between the meaning of `forall` in type/class declarations and variable declarations. Looking forward to hearing your thoughts (for any instantiation of "you"). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 21:39:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 21:39:28 -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.c59320aa8bc829efcca88f153ad6a5c2@haskell.org> #14037: Fix fusion for GHC's utility functions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: rockbmb 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: | -------------------------------------+------------------------------------- Comment (by rockbmb): Replying to [comment:5 bgamari]: > There is nothing that tests these functions in isolation although it's possible improvements would be reflected in the compiler allocations measured by the Nofib suite. I've been reading [https://ghc.haskell.org/trac/ghc/wiki/Building/RunningNoFib this] resource on NoFib, very useful. I'll keep what you said in mind. Since the OP also mentions `testsuite/tests/perf/compiler/T5631`, I'm also reading https://ghc.haskell.org/trac/ghc/wiki/Building/RunningTests so I can test the specific case described. I've already added some pragma code to `zipWith3, zipWith3M, zipwith4, zipwith4M`. In the coming days I'll run benchmarks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 16 22:30:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Oct 2018 22:30:59 -0000 Subject: [GHC] #15743: Nail down the Required/Inferred/Specified story In-Reply-To: <046.20125fa3baabaa154b0336067d36471f@haskell.org> References: <046.20125fa3baabaa154b0336067d36471f@haskell.org> Message-ID: <061.e995d176ec60b977b0e34d209fc6b8a0@haskell.org> #15743: Nail down the Required/Inferred/Specified story -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Really, T' and T should be treated the same. Yet to accept T', we would have to insert a variable in that telescope that isn't there. and > Sadly, we don't allow implicit quantification in the middle of a type, saying that all implicit quantification must occur directly after the ::. Both these comments about the same thing: if I write an explicit kind signature (for a type constructor) or type signature (for a function), can the Inferred variables be interleaved with the Specified forall'd ones? That indeed seems tricky: after all, the user is explicitly specifying the telescope, and we'd have to "insert a variable in that telescope that isn't there". But I feel similarly about `T` in comment:1 where you propose to insert an Inferred `d::k` in the middle of the user-specfied telescope. One thing we have not discussed, but perhaps which goes without saying, is this: an explicit, user-specified kind signature may specify a different order for the Specified variables than the one we'd infer -- and then we'd better follow the order in the signature. And that leads back to the question: ''is it even possible to specify the position of an inferred variable other than at the front?'' Presumably not -- if we specified that variable it's be Specified not Inferred! So at the moment, pending further debate, I feel pretty strongly that Inferred should be at the front, always. Overall, my current vote is (1). It is simple to specify: Inferred, then Specified, then Required. If it becomes irksome we can loosen up. When things get complicated I worry that we might find that our sophisticated inference system is incompatible with something we want to do in the future. Let's keep it simple. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 03:58:46 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 03:58:46 -0000 Subject: [GHC] #15755: randomRIO panic on (GHC version 8.4.3 for x86_64-apple-darwin) Message-ID: <043.d99d803d2e9b59ef17275c0dcbc2174a@haskell.org> #15755: randomRIO panic on (GHC version 8.4.3 for x86_64-apple-darwin) -------------------------------------+------------------------------------- Reporter: cmal | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Keywords: randomRIO | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+-------------------------------------  randomRIO (1,100) ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-apple-darwin): nameModule system $dShow_a78p Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 04:37:49 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 04:37:49 -0000 Subject: [GHC] #15755: randomRIO panic on (GHC version 8.4.3 for x86_64-apple-darwin) In-Reply-To: <043.d99d803d2e9b59ef17275c0dcbc2174a@haskell.org> References: <043.d99d803d2e9b59ef17275c0dcbc2174a@haskell.org> Message-ID: <058.bf149f160c5f9953cf7e9163f61997dc@haskell.org> #15755: randomRIO panic on (GHC version 8.4.3 for x86_64-apple-darwin) -------------------------------------+------------------------------------- Reporter: cmal | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: randomRIO Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Old description: >  randomRIO (1,100) > ghc: panic! (the 'impossible' happened) > (GHC version 8.4.3 for x86_64-apple-darwin): > nameModule > system $dShow_a78p > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in > ghc:Outputable > pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug New description: randomRIO (1,100) ghc: panic! (the 'impossible' happened) (GHC version 8.4.3 for x86_64-apple-darwin): nameModule system $dShow_a78p Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1150:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Name.hs:241:3 in ghc:Name Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug -- Comment: Can you provide more specific reproduction instructions? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 05:00:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 05:00:35 -0000 Subject: [GHC] #15756: The "-fcontext-stack=N" GHC flag is not documented Message-ID: <049.1c4b5ad8cfd995290ce8d06a04adc317@haskell.org> #15756: The "-fcontext-stack=N" GHC flag is not documented -------------------------------------+------------------------------------- Reporter: terrorjack | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently, there isn't an entry for the `-fcontext-stack=N` flag in the [Flag reference](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/flags.html) section of GHC documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 05:05:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 05:05:07 -0000 Subject: [GHC] #15756: The "-freduction-depth=N" GHC flag is not documented (was: The "-fcontext-stack=N" GHC flag is not documented) In-Reply-To: <049.1c4b5ad8cfd995290ce8d06a04adc317@haskell.org> References: <049.1c4b5ad8cfd995290ce8d06a04adc317@haskell.org> Message-ID: <064.393690e45015931f5280f870123f8e6b@haskell.org> #15756: The "-freduction-depth=N" GHC flag is not documented -------------------------------------+------------------------------------- Reporter: terrorjack | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by terrorjack: Old description: > Currently, there isn't an entry for the `-fcontext-stack=N` flag in the > [Flag > reference](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/flags.html) > section of GHC documentation. New description: Currently, there isn't an entry for the `-freduction-depth=N` flag in the [Flag reference](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/flags.html) section of GHC documentation. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 07:55:52 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 07:55:52 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.67fc547893ba645b7f5b5db83a8b5051@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201, Phab:D5226 -------------------------------------+------------------------------------- Comment (by osa1): Just an update before I forget where I had left: the performance regression in `wip/T15696` is fixed by any of these: - Revert change in `app_ok` general case, don't give case binders `evaldUnfolding` in `simplAlts` (first suggestion in comment:77) - Revert change in `app_ok` general case, disable binder swapping of case bidners and scrutinee. Both validate, but I don't have nofib results yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 10:55:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 10:55:29 -0000 Subject: [GHC] #15757: Coercion Variable Almost Devoid Checking in ForAllCo Message-ID: <047.e3bc1ec429883d9b3738da4edd6cb2a8@haskell.org> #15757: Coercion Variable Almost Devoid Checking in ForAllCo -------------------------------------+------------------------------------- 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: #15497 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In [https://repository.brynmawr.edu/cgi/viewcontent.cgi?article=1074&context=compsci_pubs/ Richard's thesis] Section 5.8.5.2, there is a restriction on where a coercion variable can appear in `ForAllCo` for the sake of consistency: the coercion variable can appear nowhere except in coherence coercions. Currently this restriction is missing in coercion quantification (see #15497). The goal of this ticket is to add the missing restriction. After discussion with Richard, we restate the restriction a little bit: the coercion variable can appear nowhere except in `GRefl` and `Refl`. Allowing it to appear in `Refl` should not break consistency. Notice that this also means `liftCoSubst` might fail when it lifts a `ForAllTy` over a coercion variable to a `ForAllCo`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 11:15:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 11:15:03 -0000 Subject: [GHC] #15757: Coercion Variable Almost Devoid Checking in ForAllCo In-Reply-To: <047.e3bc1ec429883d9b3738da4edd6cb2a8@haskell.org> References: <047.e3bc1ec429883d9b3738da4edd6cb2a8@haskell.org> Message-ID: <062.c50a7baa3899448baffaa6e7e4ba43b0@haskell.org> #15757: Coercion Variable Almost Devoid Checking in ForAllCo -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning 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: #15497 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ningning): * owner: (none) => ningning -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 12:14:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 12:14:10 -0000 Subject: [GHC] #15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable Message-ID: <043.18564262c59dae41f0454bb2c0047a1d@haskell.org> #15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently packages with .hsc files can't be built with GHC HEAD on some systems becuase of a problem in hsc2hs wrapper script. I don't understand the problem good enough, but we did some debugging with hvr today and he asked me to file a ticket. Here's how to reproduce: {{{ regex-posix-0.95.2 $ cabal new-build --with- ghc=/home/omer/haskell/ghc/inplace/bin/ghc-stage2 Warning: Unknown/unsupported 'ghc' version detected (Cabal 2.4.0.1 supports 'ghc' version < 8.7): /home/omer/haskell/ghc/inplace/bin/ghc-stage2 is version 8.7.20181017 Warning: The package list for 'hackage.haskell.org' is 22 days old. Run 'cabal update' to get the latest list of available packages. Resolving dependencies... Build profile: -w ghc-8.7.20181017 -O1 In order, the following will be built (use -v for more details): - regex-posix-0.95.2 (lib:regex-posix) (first run) Warning: regex-posix.cabal:6:1: The field "build-type" is specified more than once at positions 6:1, 19:1 Configuring regex-posix-0.95.2... Preprocessing library for regex-posix-0.95.2.. hsc2hs: @/home/omer/haskell/regex-posix-0.95.2/dist- newstyle/build/x86_64-linux/ghc-8.7.20181017/regex- posix-0.95.2/build/Text/Regex/Posix/hsc2hs-response17101-2.txt: openBinaryFile: does not exist (No such file or directory) }}} As far as I understand, the problem is that the script runs `hsc2hs -- @foo` instead of `hsc2hs @foo`. Hopefully hvr will correct if I misunderstood. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 13:09:06 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 13:09:06 -0000 Subject: [GHC] #15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable In-Reply-To: <043.18564262c59dae41f0454bb2c0047a1d@haskell.org> References: <043.18564262c59dae41f0454bb2c0047a1d@haskell.org> Message-ID: <058.e179a21241c48928f9334a67b4bf3b4e@haskell.org> #15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: ckoparkar (added) Comment: This looks like it might be related to `hsc2hs`'s recently added support for reading response files. ckoparkar, might you have an idea what's happening here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 13:13:09 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 13:13:09 -0000 Subject: [GHC] #15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable In-Reply-To: <043.18564262c59dae41f0454bb2c0047a1d@haskell.org> References: <043.18564262c59dae41f0454bb2c0047a1d@haskell.org> Message-ID: <058.ae8142a7eb8a03cba3205db9c73fd2c5@haskell.org> #15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: hvr (added) Comment: (forgot to cc hvr) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 14:03:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 14:03:59 -0000 Subject: [GHC] #15759: GHC doesn't use fixity in type instances Message-ID: <047.f3746336dffeb9f2cf2f7ed375dedd07@haskell.org> #15759: GHC doesn't use fixity in type instances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I say {{{#!hs data a * b infixl 7 * type family a + b infixl 6 + type instance Int * Bool + Double = Float }}} (with `-XNoStarIsType` -- `*` is not the issue here) I get {{{ • Illegal family instance for ‘*’ (* is not an indexed type family) • In the type instance declaration for ‘*’ }}} But that's wrong. The `*` should bind tighter than the `+`, meaning this is an instance for `+`, not `*`. This also fails for closed type families: {{{#!hs data a * b infixl 7 * type family a + b where Int * Bool + Double = Float infixl 6 + }}} Interestingly, a ''class'' instance works here. This did not bite me "in the wild", but came up while reading the GHC source code. Still, it is a real bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 14:16:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 14:16:51 -0000 Subject: [GHC] #15760: Preserve parens in TH Message-ID: <047.bd515b636bed31bfe65d883c11cd9bb1@haskell.org> #15760: Preserve parens in TH -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.6.1 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: -------------------------------------+------------------------------------- Template Haskell supports parentheses in its AST. So does GHC. Yet GHC casually discards parentheses when desugaring TH quotes. We should preserve them. I was originally thinking that this could get rid of `Note [Adding parens for splices]` in Convert, but that processing would still be necessary if we are converting TH AST that did not come from a quote. Actually, it gets worse with this change, because we don't want to add ''redundant'' parens. Still, I think preserving parens is the right thing to do here. It also makes it possible for a client to give special meaning to, say, nested parens: Perhaps `process [| f x |]` and `process [| f ((x)) |]` will behave differently. (Idiom brackets, anyone?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 14:33:55 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 14:33:55 -0000 Subject: [GHC] #15761: pprFamInstLHS drops parentheses Message-ID: <047.803fc501a51c837a80f63502f8cd5460@haskell.org> #15761: pprFamInstLHS drops parentheses -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I say {{{#!hs data family (a + b) c d data instance (Int + Bool) Double = Float }}} GHC says {{{ • Expecting one more argument to ‘Int + Bool Double’ Expected a type, but ‘Int + Bool Double’ has kind ‘* -> *’ • In the data instance declaration for ‘+’ }}} Note the missing parens in the first line of the error. Will fix shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 14:44:52 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 14:44:52 -0000 Subject: [GHC] #15759: GHC doesn't use fixity in type instances In-Reply-To: <047.f3746336dffeb9f2cf2f7ed375dedd07@haskell.org> References: <047.f3746336dffeb9f2cf2f7ed375dedd07@haskell.org> Message-ID: <062.c2c563f4b2fd011da96ec1d9f5d8f1b8@haskell.org> #15759: GHC doesn't use fixity in type instances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11307 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #11307 Comment: See also #11307. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 14:45:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 14:45:14 -0000 Subject: [GHC] #11307: Regresssion: parsing type operators In-Reply-To: <044.2722f1013c64633fbf159145867daa0f@haskell.org> References: <044.2722f1013c64633fbf159145867daa0f@haskell.org> Message-ID: <059.16b25c313d05c05655a24858d9704f38@haskell.org> #11307: Regresssion: parsing type operators -------------------------------------+------------------------------------- Reporter: alanz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 11400 Related Tickets: #15759 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15759 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 15:01:04 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 15:01:04 -0000 Subject: [GHC] #15760: Preserve parens in TH In-Reply-To: <047.bd515b636bed31bfe65d883c11cd9bb1@haskell.org> References: <047.bd515b636bed31bfe65d883c11cd9bb1@haskell.org> Message-ID: <062.5546b6e6438d474c6593f27f1f9da7d8@haskell.org> #15760: Preserve parens in TH -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): That sounds like a reasonable enough desire. Where are you applying this fix? In `DsMeta`? If so, please make sure that the functions in `Convert` don't accidentally add extraneous parentheses (I've tried quite hard to ensure that `Convert` only adds required parentheses if they're missing, but it's quite possible that I've missed a case). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 15:02:39 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 15:02:39 -0000 Subject: [GHC] #15762: ghci command: report function's inferred visible type applications Message-ID: <051.4423f1d866fd4ea3150fb77ffc8a796f@haskell.org> #15762: ghci command: report function's inferred visible type applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15610 #15613 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Example inspired by #40. ghci already has a [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html #ghci-cmd-:type-at :type-at] command for reporting a type in a range {{{ >> :type-at X.hs 6 6 6 7 f Int -> Int }}} A similar thing (for integrating into IDEs) is doing the same for visible type applications. An innocent expression like `x y` has a lot going on under the surface {{{#!hs {-# Language RankNTypes #-} {-# Language PolyKinds #-} {-# Language KindSignatures #-} import Data.Kind f :: forall res . (forall k (f :: k -> Type) (a :: k). f a -> res) -> (forall (f :: Type -> Type) . f res) -> res f x y = x y }}} How hard would it be to expand that to `(x @Type @f @res) (y @f)` or (x @Type @Any @res) (y @Any) {{{#!hs f :: forall res (f :: Type -> Type) . (forall k (f :: k -> Type) (a :: k). f a -> res) -> (forall (f :: Type -> Type) . f res) -> res f x y = (x @Type @f @res) (y @f) }}} ---- Other ghci ideas: #15610, #15613 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 15:03:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 15:03:22 -0000 Subject: [GHC] #15762: ghci command: report function's inferred visible type applications In-Reply-To: <051.4423f1d866fd4ea3150fb77ffc8a796f@haskell.org> References: <051.4423f1d866fd4ea3150fb77ffc8a796f@haskell.org> Message-ID: <066.1222b0920e6b49d7f7d52f20750e4924@haskell.org> #15762: ghci command: report function's inferred visible type applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15610 #15613 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > Example inspired by #40. > > ghci already has a > [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html > #ghci-cmd-:type-at :type-at] command for reporting a type in a range > > {{{ > >> :type-at X.hs 6 6 6 7 f > Int -> Int > }}} > > A similar thing (for integrating into IDEs) is doing the same for visible > type applications. An innocent expression like `x y` has a lot going on > under the surface > > {{{#!hs > {-# Language RankNTypes #-} > {-# Language PolyKinds #-} > {-# Language KindSignatures #-} > > import Data.Kind > > f :: forall res > . (forall k (f :: k -> Type) (a :: k). f a -> res) > -> (forall (f :: Type -> Type) . f res) > -> res > f x y = x y > }}} > > How hard would it be to expand that to `(x @Type @f @res) (y @f)` or (x > @Type @Any @res) (y @Any) > > {{{#!hs > f :: forall res (f :: Type -> Type) > . (forall k (f :: k -> Type) (a :: k). f a -> res) > -> (forall (f :: Type -> Type) . f res) > -> res > f x y = (x @Type @f @res) (y @f) > }}} > > ---- > > Other ghci ideas: #15610, #15613 New description: Example inspired by #40. ghci already has a [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html #ghci-cmd-:type-at :type-at] command for reporting a type in a range {{{ >> :type-at X.hs 6 6 6 7 f Int -> Int }}} A similar thing (for integrating into IDEs) is doing the same for visible type applications. An innocent expression like `x y` has a lot going on under the surface {{{#!hs {-# Language RankNTypes #-} {-# Language PolyKinds #-} {-# Language KindSignatures #-} import Data.Kind f :: forall res . (forall k (f :: k -> Type) (a :: k). f a -> res) -> (forall (f :: Type -> Type) . f res) -> res f x y = x y }}} How hard would it be to expand that to `(x @Type @f @res) (y @f)` (or `(x @Type @Any @res) (y @Any)`) {{{#!hs f :: forall res (f :: Type -> Type) . (forall k (f :: k -> Type) (a :: k). f a -> res) -> (forall (f :: Type -> Type) . f res) -> res f x y = (x @Type @f @res) (y @f) }}} ---- Other ghci ideas: #15610, #15613 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 15:19:36 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 15:19:36 -0000 Subject: [GHC] #15763: GHC forbids kind signatures in data family instances Message-ID: <047.49f1f43c53222eaf676061f6d8b6e96a@haskell.org> #15763: GHC forbids kind signatures in data family instances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If I say {{{#!hs class C (a :: k) instance (C :: Type -> Constraint) a }}} GHC is happy. Note that this is actually useful to do. But if I say {{{#!hs data family D (a :: k) data instance (D :: Type -> Type) a }}} GHC is unhappy: {{{ Malformed head of type or class declaration: (D :: Type -> Type) a }}} Fixing this will require a change to the `FamEqn` type, which doesn't have enough flexibility to deal with a kind signature there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 15:19:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 15:19:38 -0000 Subject: [GHC] #15263: Fuse zipWith3 In-Reply-To: <047.9d2de90ae6f11d155cd01f5a30989bf4@haskell.org> References: <047.9d2de90ae6f11d155cd01f5a30989bf4@haskell.org> Message-ID: <062.12d8d05f9566c0f7ada3aad0e90aa849@haskell.org> #15263: Fuse zipWith3 -------------------------------------+------------------------------------- Reporter: goldfire | Owner: TDecki 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 TDecki): * owner: (none) => TDecki -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 15:32:04 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 15:32:04 -0000 Subject: [GHC] #15761: pprFamInstLHS drops parentheses In-Reply-To: <047.803fc501a51c837a80f63502f8cd5460@haskell.org> References: <047.803fc501a51c837a80f63502f8cd5460@haskell.org> Message-ID: <062.b5bd56e787a1d7690c7ede33b0b70825@haskell.org> #15761: pprFamInstLHS drops parentheses -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"38c28c1a8bb129141e533866700e7318314f32c1/ghc" 38c28c1a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="38c28c1a8bb129141e533866700e7318314f32c1" Fix #15761 by adding parens This was just a pretty-printer infelicity. Fixed now. Test case: printer/T15761 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 15:33:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 15:33:02 -0000 Subject: [GHC] #15761: pprFamInstLHS drops parentheses In-Reply-To: <047.803fc501a51c837a80f63502f8cd5460@haskell.org> References: <047.803fc501a51c837a80f63502f8cd5460@haskell.org> Message-ID: <062.64edf65ebc77e2731e62fccdaf031781@haskell.org> #15761: pprFamInstLHS drops parentheses -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge Comment: There's no reason not to merge, but there's not much reason to either if there is any challenge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 15:43:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 15:43:20 -0000 Subject: [GHC] #15761: pprFamInstLHS drops parentheses In-Reply-To: <047.803fc501a51c837a80f63502f8cd5460@haskell.org> References: <047.803fc501a51c837a80f63502f8cd5460@haskell.org> Message-ID: <062.918b6a08c7f7a8056cfa812ca2d4d1d2@haskell.org> #15761: pprFamInstLHS drops parentheses -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | printer/T15761 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => printer/T15761 * milestone: => 8.6.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 15:44:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 15:44:56 -0000 Subject: [GHC] #15763: GHC forbids kind signatures in data family instances In-Reply-To: <047.49f1f43c53222eaf676061f6d8b6e96a@haskell.org> References: <047.49f1f43c53222eaf676061f6d8b6e96a@haskell.org> Message-ID: <062.d47f48d544862bf5271fa2107c926a86@haskell.org> #15763: GHC forbids kind signatures in data family instances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Should we also permit `data (D :: Type -> Type) a`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 16:16:12 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 16:16:12 -0000 Subject: [GHC] #15764: GHC panic from PolyKinds + DataKinds Message-ID: <051.fa1a75fe8be67f6456bdec06d1e8c54f@haskell.org> #15764: GHC panic from PolyKinds + DataKinds -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Playing around with GhcKinds/KindInference/Examples gives me a GHC panic {{{#!hs -- https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/KindInference/Examples?version=4 {-# Language PolyKinds #-} {-# Language KindSignatures #-} {-# Language DataKinds #-} import Data.Kind import Data.Proxy import GHC.TypeLits class C6 (k :: Type) (a :: k) (b :: Proxy (a :: k)) where type T6 (proxy :: Proxy '(k, b)) }}} on an out of date version of HEAD I get {{{ $ ghci -ignore-dot-ghci 519.hs GHCi, version 8.7.20180828: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 519.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20180828 for x86_64-unknown-linux): ASSERT failed! 1 0 k_a1FD[tau:0] Proxy a_a1EN[sk:1] 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:768:54 in ghc:TcMType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 16:43:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 16:43:00 -0000 Subject: [GHC] #15765: Make the "extract" functions in RnTypes pure Message-ID: <047.96044c33162b65d98275c8947da2911e@haskell.org> #15765: Make the "extract" functions in RnTypes pure -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Once upon a time, the `extract` functions at the bottom of RnTypes were pure. Then, along came `-XTypeInType`, which needed to do a check in these functions for users mixing type variables with kind variables. Now, however, with `-XTypeInType` gone again, we no longer do this check. Thus, there is no reason to keep these functions monadic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 17:52:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 17:52:34 -0000 Subject: [GHC] #15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable In-Reply-To: <043.18564262c59dae41f0454bb2c0047a1d@haskell.org> References: <043.18564262c59dae41f0454bb2c0047a1d@haskell.org> Message-ID: <058.041bac0261abfc53e96246d8b098a982@haskell.org> #15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ckoparkar): Here's another way to reproduce the build failure. If we create a 'Foo.hsc' file, and use {{{hsc2hs}}} built by HEAD to process it via a response file, it fails with the same error. {{{#!haskell -- Foo.hsc main :: IO () main = print $ #size int }}} {{{#!sh $ cat cmd_opts Foo.hsc }}} {{{#!sh $ ~/ghc/inplace/bin/hsc2hs @cmd_opts hsc2hs: @cmd_opts: openBinaryFile: does not exist (No such file or directory) }}} And this would always fail if HEAD is built with GHC < 8.6. I think that it's because in the GHC build system, {{{hsc2hs}}} is built during Phase 0, by the bootstrapping compiler. So if HEAD is bootstrapped with GHC < 8.6, it uses a version of {{{base}}} which does not support response files, and triggers a CPP codepath which does not know how to parse {{{@file}}} command-line arguments. So {{{hsc2hs}}} tries to read a '@file', which does not exist. I am unsure what right solution for this is. We certainly can't move {{{hsc2hs}}} out of 'Phase 0' as some artifacts in 'Phase 1' depend on it. Maybe the final {{{hsc2hs}}} executable that's generated under 'ghc/inplace' could be regenerated in a later phase. What do other people think about this ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 18:24:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 18:24:24 -0000 Subject: [GHC] #15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable In-Reply-To: <043.18564262c59dae41f0454bb2c0047a1d@haskell.org> References: <043.18564262c59dae41f0454bb2c0047a1d@haskell.org> Message-ID: <058.aa0fdde03e6f9578bd1426002ef4f482@haskell.org> #15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ckoparkar): I forgot to mention the Cabal bits in comment:3. In Cabal, the decision of whether or not to use response files for invoking {{{hsc2hs}}} is made based only on the version of {{{hsc2hs}}}. {{{#!haskell if hsc2hs_version >= 0.68.4 then use response files else regular command-line arguments }}} But we can have a {{{hsc2hs-0.68.4}}} that is compiled with GHC < 8.6, which won't support response file arguments. I think this is what's happening in the {{{regex-posix}}} example that osa1 posted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 18:45:54 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 18:45:54 -0000 Subject: [GHC] #15761: pprFamInstLHS drops parentheses In-Reply-To: <047.803fc501a51c837a80f63502f8cd5460@haskell.org> References: <047.803fc501a51c837a80f63502f8cd5460@haskell.org> Message-ID: <062.21140344115d6276675ad8a77cf102cb@haskell.org> #15761: pprFamInstLHS drops parentheses -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | printer/T15761 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.6` with bf667f9d6b9c4e39584217f7828952600cfc00a6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 18:48:33 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 18:48:33 -0000 Subject: [GHC] #15692: GHC panic from pattern synonyms + deferred type errors In-Reply-To: <051.39157d43d1b8d263a8e2728339a9f8aa@haskell.org> References: <051.39157d43d1b8d263a8e2728339a9f8aa@haskell.org> Message-ID: <066.2fa6cd66b03d26460f40f24cc2cca2d7@haskell.org> #15692: GHC panic from pattern synonyms + deferred type errors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | patsyn/should_fail/T15692 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged with 3e050064511ce67ee9150d51cb9db487187be39e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 19:14:10 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 19:14:10 -0000 Subject: [GHC] #15763: GHC forbids kind signatures in data family instances In-Reply-To: <047.49f1f43c53222eaf676061f6d8b6e96a@haskell.org> References: <047.49f1f43c53222eaf676061f6d8b6e96a@haskell.org> Message-ID: <062.0a1471ec294e43f87337121c151b5638@haskell.org> #15763: GHC forbids kind signatures in data family instances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): No. `data` is a declaration (binding site) and has its own, restrictive syntax. On the other hand, the head of a `data instance` is a type, containing only occurrences, not binding sites. (Even the type variables are occurrences. They are magically and invisibly bound by an implicit `forall`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 19:20:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 19:20:07 -0000 Subject: [GHC] #10453: \case should trigger auto-multiline mode in ghci In-Reply-To: <044.2d59789cf30828fd243fec4509fe4124@haskell.org> References: <044.2d59789cf30828fd243fec4509fe4124@haskell.org> Message-ID: <059.3611f8fde41718844963617e0d56b97d@haskell.org> #10453: \case should trigger auto-multiline mode in ghci -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5236 Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * differential: => Phab:D5236 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 19:32:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 19:32:24 -0000 Subject: [GHC] #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory In-Reply-To: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> References: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> Message-ID: <063.281f791d8a1c957957116d4cf7077f86@haskell.org> #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: None | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I see what happened here: we used to build for Darwin using the in-tree GMP but this logic was never ported to CircleCI. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 19:39:47 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 19:39:47 -0000 Subject: [GHC] #15743: Nail down the Required/Inferred/Specified story In-Reply-To: <046.20125fa3baabaa154b0336067d36471f@haskell.org> References: <046.20125fa3baabaa154b0336067d36471f@haskell.org> Message-ID: <061.1665b846f5dd7e88313660fb7832eef6@haskell.org> #15743: Nail down the Required/Inferred/Specified story -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): > is it even possible to specify the position of an inferred variable other than at the front? It isn't possible to specify the position of an inferred variable. Full stop. (At least, not until we have explicit specificity.) But this isn't just about Inferred variables. It's also about Specified ones. Here's a slight tweak to `T`: {{{#!hs data T k (c :: k) (a :: Proxy c) (b :: Proxy d) (x :: SimilarKind a b) }}} I've given `b` a kind that mentions `d`. This makes `d` Specified. But poor `d` still must come ''after'' `k`. We can still go ahead with option (1) (which is what I've been reluctantly leaning toward as well), but I'm clarifying here that the problem isn't just with Inferred. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 19:46:12 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 19:46:12 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow In-Reply-To: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> References: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> Message-ID: <057.21ca46b7b2bb5e381623732b30949f08@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof recomp007 | space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrp): .. and the `plugin` recomp tests now pass, but `T3001-2` fails. Not sure why `EtaExpandLevPoly` is deemed to be a unexpected pass while living in s `should_run` directory. {{{ ==== STAGE 1 TESTS ==== SUMMARY for test run started at Wed Oct 17 20:38:13 2018 BST 0:00:05 spent to go through 2 total tests, which gave rise to 10 test cases, of which 0 were skipped 0 had missing libraries 10 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 0 unexpected failures 0 unexpected stat failures ==== STAGE 2 TESTS ==== Unexpected results from: TEST="EtaExpandLevPoly T14936 T15349 T2783 T3001-2 T4334 T7919 haddock.Cabal haddock.base haddock.compiler hpc_fork recomp007 space_leak_001" SUMMARY for test run started at Wed Oct 17 19:38:22 2018 BST 0:59:50 spent to go through 6606 total tests, which gave rise to 29725 test cases, of which 5914 were skipped 256 had missing libraries 23278 expected passes 256 expected failures 0 caused framework failures 0 caused framework warnings 3 unexpected passes 5 unexpected failures 13 unexpected stat failures Unexpected passes: /tmp/ghctest-3xm7yvst/test spaces/rts/T2783.run T2783 [unexpected] (threaded1) /tmp/ghctest-3xm7yvst/test spaces/typecheck/should_run/EtaExpandLevPoly.run EtaExpandLevPoly [unexpected] (profasm) /tmp/ghctest-3xm7yvst/test spaces/typecheck/should_run/EtaExpandLevPoly.run EtaExpandLevPoly [unexpected] (profthreaded) Unexpected failures: /tmp/ghctest-3xm7yvst/test spaces/driver/recomp007/recomp007.run recomp007 [bad stderr] (normal) /tmp/ghctest-3xm7yvst/test spaces/profiling/should_run/T3001-2.run T3001-2 [exit code non-0] (prof_hb) /tmp/ghctest-3xm7yvst/test spaces/rts/T7919.run T7919 [bad exit code] (ghci) /tmp/ghctest-3xm7yvst/test spaces/libraries/hpc/tests/fork/hpc_fork.run hpc_fork [bad heap profile] (profasm) /tmp/ghctest-3xm7yvst/test spaces/libraries/base/tests/T15349.run T15349 [bad exit code] (ghci) Unexpected stat failures: /tmp/ghctest-3xm7yvst/test spaces/perf/haddock/haddock.base.run haddock.base [stat not good enough] (normal) /tmp/ghctest-3xm7yvst/test spaces/perf/haddock/haddock.Cabal.run haddock.Cabal [stat not good enough] (normal) /tmp/ghctest-3xm7yvst/test spaces/perf/haddock/haddock.compiler.run haddock.compiler [stat not good enough] (normal) /tmp/ghctest-3xm7yvst/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (hpc) /tmp/ghctest-3xm7yvst/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (profasm) /tmp/ghctest-3xm7yvst/test spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (hpc) /tmp/ghctest-3xm7yvst/test spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (optasm) /tmp/ghctest-3xm7yvst/test spaces/perf/space_leaks/T4334.run T4334 [stat not good enough] (threaded2) /tmp/ghctest-3xm7yvst/test spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (dyn) /tmp/ghctest-3xm7yvst/test spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (optllvm) /tmp/ghctest-3xm7yvst/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (threaded1) /tmp/ghctest-3xm7yvst/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (threaded2) /tmp/ghctest-3xm7yvst/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (profthreaded) == Start post-testsuite package check GHC package manager version 8.7.20181017 Timestamp 2018-10-17 18:38:18.160937921 UTC for /home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181017/package.conf.d/package.cache using cache: /home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181017/package.conf.d/package.cache db stack: ["/home/jrp/.ghc/x86_64-linux-8.7.20181017/package.conf.d","/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181017/package.conf.d"] flag db stack: ["/home/jrp/.ghc/x86_64-linux-8.7.20181017/package.conf.d","/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181017/package.conf.d"] == End post-testsuite package check ------------------------------------------------------------------- Oops! Looks like you have some unexpected test results or framework failures. Please fix them before pushing/sending patches. ------------------------------------------------------------------- }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 19:55:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 19:55:51 -0000 Subject: [GHC] #13087: AlternativeLayoutRule breaks LambdaCase In-Reply-To: <049.ad6e034aa7e8b11be8486b436f8c84ca@haskell.org> References: <049.ad6e034aa7e8b11be8486b436f8c84ca@haskell.org> Message-ID: <064.ddb8ea7268878be0c4511c69b084186b@haskell.org> #13087: AlternativeLayoutRule breaks LambdaCase -------------------------------------+------------------------------------- Reporter: ohhellojoe | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (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): Phab:D5236 Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * status: new => patch * differential: => Phab:D5236 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 20:05:19 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 20:05:19 -0000 Subject: [GHC] #12045: Visible kind application In-Reply-To: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> References: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> Message-ID: <066.819d644d01f0a881650ea78157134a8d@haskell.org> #12045: Visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: mnguyen Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications TypeInType | GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: ​Phab:D2216 => Phab:D5229 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 20:36:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 20:36:45 -0000 Subject: [GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code In-Reply-To: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> References: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> Message-ID: <065.99f4c559ba69350ccb65a8f1013a84eb@haskell.org> #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T14579 Blocked By: 12045 | Blocking: Related Tickets: | Differential Rev(s): Phab:D4264 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: closed => new * resolution: fixed => * blockedby: => 12045 * milestone: 8.4.1 => 8.8.1 Comment: I wonder if the hack we implemented to fix this issue originally could be made substantially simpler with visible kind applications (which should [https://phabricator.haskell.org/D5229 be available soon-ish]). With VKAs, we could instead generate the following code: {{{#!hs {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind import Data.Proxy newtype Wat (x :: Proxy (a :: Type)) = MkWat (Maybe a) deriving Eq newtype Glurp a = MkGlurp (Wat ('Proxy :: Proxy a)) instance Eq a => Eq (Glurp a) where (==) = coerce @(Wat ('Proxy @a) -> Wat ('Proxy @a) -> Bool) @(Glurp a -> Glurp a -> Bool) (==) }}} I'll reopen this ticket to keep track of this idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 21:13:51 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 21:13:51 -0000 Subject: [GHC] #15766: GeneralizedNewtypeDeriving should support classes with ambiguous types Message-ID: <046.ddffe3369745431e208957be5c12666f@haskell.org> #15766: GeneralizedNewtypeDeriving should support classes with ambiguous types -------------------------------------+------------------------------------- Reporter: reinerp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following module has a class with an ambiguous type: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} module Ambig where class C a where c :: Int data A = A instance C A where c = 5 newtype B = B A deriving C }}} Thanks to TypeApplications, this typeclass is still usable. However, GeneralizedNewtypeDeriving fails on it: {{{ Ambig.hs:12:26: error: • Ambiguous type variable ‘a0’ arising from a use of ‘c’ prevents the constraint ‘(C a0)’ from being solved. Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instances exist: instance C A -- Defined at Ambig.hs:10:10 instance C B -- Defined at Ambig.hs:12:26 • In the third argument of ‘GHC.Prim.coerce’, namely ‘c’ In the expression: GHC.Prim.coerce @(Int) @(Int) c In an equation for ‘c’: c = GHC.Prim.coerce @(Int) @(Int) c When typechecking the code for ‘c’ in a derived instance for ‘C B’: To see the code I am typechecking, use -ddump-deriv | 12 | newtype B = B A deriving C | }}} It shouldn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 21:48:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 21:48:26 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.74cc82dcb068e668881da467de251b53@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201, Phab:D5226 -------------------------------------+------------------------------------- Comment (by simonpj): > Revert change in app_ok general case, don't give case binders evaldUnfolding in simplAlts (first suggestion in comment:77) This is my preferred option; I don't like disabling binder swapping - it's there for a good reason! It would be illuminating to know (perhaps via `-ticky`) what code is improved by reverting the `app_ok` general case. If we knew, we could add an example to the code so that we had a concrete reason for that `isEvaldUnfolding` case. But it's only curiosity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 21:54:18 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 21:54:18 -0000 Subject: [GHC] #15757: Coercion Variable Almost Devoid Checking in ForAllCo In-Reply-To: <047.e3bc1ec429883d9b3738da4edd6cb2a8@haskell.org> References: <047.e3bc1ec429883d9b3738da4edd6cb2a8@haskell.org> Message-ID: <062.1943aee97dc3aa189965aafab6f14cb8@haskell.org> #15757: Coercion Variable Almost Devoid Checking in ForAllCo -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning 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: #15497 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Interesting. Before we are done with coercion quantification, it'd be good to update the core-spec.tex document to cover it; with some accompanying text to explain subtle points like this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 21:55:04 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 21:55:04 -0000 Subject: [GHC] #15757: Coercion Variable Almost Devoid Checking in ForAllCo In-Reply-To: <047.e3bc1ec429883d9b3738da4edd6cb2a8@haskell.org> References: <047.e3bc1ec429883d9b3738da4edd6cb2a8@haskell.org> Message-ID: <062.05a646d4cc79f46074cc145ee2df829c@haskell.org> #15757: Coercion Variable Almost Devoid Checking in ForAllCo -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning 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: #15497 | Differential Rev(s): Phab:D5231 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * differential: => Phab:D5231 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 22:18:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 22:18:43 -0000 Subject: [GHC] #15765: Make the "extract" functions in RnTypes pure In-Reply-To: <047.96044c33162b65d98275c8947da2911e@haskell.org> References: <047.96044c33162b65d98275c8947da2911e@haskell.org> Message-ID: <062.43b22113357a3bb3e2f69034c6baf07f@haskell.org> #15765: Make the "extract" functions in RnTypes pure -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Good plan -- let's fix! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 22:26:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 22:26:45 -0000 Subject: [GHC] #15743: Nail down the Required/Inferred/Specified story In-Reply-To: <046.20125fa3baabaa154b0336067d36471f@haskell.org> References: <046.20125fa3baabaa154b0336067d36471f@haskell.org> Message-ID: <061.c66c47aa3062880182545bf5aab5a473@haskell.org> #15743: Nail down the Required/Inferred/Specified story -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): But, to be clear, you could still give an explicit kind signature to `k` (at least, when we have explicit kind signatures) thus {{{ T :: forall k (c::k) -> forall (d::k). forall (a::Proxy c) (b :: Proxy d) -> SimilarKind a b -> Type }}} Given that signature, we should accept the declaration. So, even if we reject under (1) we have a route accepting it -- and I think it's arguable that if you need funny interleaving then it's a good thing to write the signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 22:29:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 22:29:30 -0000 Subject: [GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code In-Reply-To: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> References: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> Message-ID: <065.d99b24cb495ff0275fc599f3dfafa117@haskell.org> #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T14579 Blocked By: 12045 | Blocking: Related Tickets: | Differential Rev(s): Phab:D4264 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes indeed. comment:3 identifies VKA as the desired facility, with kind signatures as second best. Good idea to re-open -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 22:51:57 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 22:51:57 -0000 Subject: [GHC] #15766: GeneralizedNewtypeDeriving should support classes with ambiguous types In-Reply-To: <046.ddffe3369745431e208957be5c12666f@haskell.org> References: <046.ddffe3369745431e208957be5c12666f@haskell.org> Message-ID: <061.eae7ff8bc80d0780e516a8578943d62d@haskell.org> #15766: GeneralizedNewtypeDeriving should support classes with ambiguous types -------------------------------------+------------------------------------- Reporter: reinerp | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15637 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #15637 Comment: Thanks for the bug report. This is a duplicate of #15637, which has been fixed upstream. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 23:02:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 23:02:22 -0000 Subject: [GHC] #15767: "StgCmmEnv: variable not found" with FunctionalDependencies and FlexibleContexts Message-ID: <045.2239633dfbb009c41762262dc87d11d7@haskell.org> #15767: "StgCmmEnv: variable not found" with FunctionalDependencies and FlexibleContexts -------------------------------------+------------------------------------- Reporter: roland | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE FunctionalDependencies, FlexibleContexts #-} module Bug where class C a b | b -> a where f :: a -> b y = x where x :: (C () b, C Bool b) => b x = f () }}} {{{ $ ghc -c Bug.hs ghc: panic! (the 'impossible' happened) (GHC version 8.6.1 for x86_64-unknown-openbsd): StgCmmEnv: variable not found $dC_a1lC local binds for: f $tc'C:C $tcC $trModule $tc'C:C1_r1mz $tc'C:C2_r1n0 $krep_r1n1 $krep1_r1n2 $krep2_r1n3 $krep3_r1n4 $krep4_r1n5 $tcC1_r1n6 $tcC2_r1n7 $krep5_r1n8 $krep6_r1n9 $krep7_r1na $trModule1_r1nb $trModule2_r1nc $trModule3_r1nd $trModule4_r1ne $krep8_r1nf $krep9_r1ng Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/codeGen/StgCmmEnv.hs:149:9 in ghc:StgCmmEnv Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 17 23:49:52 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Oct 2018 23:49:52 -0000 Subject: [GHC] #15767: "StgCmmEnv: variable not found" with FunctionalDependencies and FlexibleContexts In-Reply-To: <045.2239633dfbb009c41762262dc87d11d7@haskell.org> References: <045.2239633dfbb009c41762262dc87d11d7@haskell.org> Message-ID: <060.a2ed61ba4c76d72fbe20aeab45833889@haskell.org> #15767: "StgCmmEnv: variable not found" with FunctionalDependencies and FlexibleContexts -------------------------------------+------------------------------------- Reporter: roland | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This is quite an interesting program you have here. When this is compiled with GHC 8.2 or earlier, you get a proper type error: {{{ $ /opt/ghc/8.2.2/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:7:5: error: • Couldn't match type ‘()’ with ‘Bool’ arising from a functional dependency between constraints: ‘C Bool b’ arising from a use of ‘x’ at Bug.hs:7:5 ‘C () b’ arising from a use of ‘x’ at Bug.hs:7:5 • In the expression: x In an equation for ‘y’: y = x where x :: (C () b, C Bool b) => b x = f () | 7 | y = x where | ^ }}} It appears to compile successfully with GHC 8.4. But that is a charade, since if you try to evaluate `y` in GHCi, you get... well, this: {{{ $ /opt/ghc/8.4.4/bin/ghci Bug.hs GHCi, version 8.4.4: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, one module loaded. λ> y *** Exception: Bug.hs:7:5: error: • No instance for (C () b) arising from a use of ‘x’ • In the expression: x In an equation for ‘y’: y = x where x :: (C () b, C Bool b) => b x = f () (deferred type error) }}} Interestingly, despite the fact that compiling this directly with GHC 8.6.1 panics, it //does// load successfully into GHCi with GHC 8.6.1. However, if you evaluate `y` in GHCi 8.6.1, you get a //different// panic: {{{ $ /opt/ghc/8.6.1/bin/ghci Bug.hs GHCi, version 8.6.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, one module loaded. λ> y ghc: panic! (the 'impossible' happened) (GHC version 8.6.1 for x86_64-unknown-linux): nameModule system $dC_a1PK Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/basicTypes/Name.hs:240:3 in ghc:Name }}} Weird behavior all around. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 01:38:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 01:38:15 -0000 Subject: [GHC] #15768: Using oneshot kqueue() on macOS Message-ID: <052.23d28fc3421f1bb560c819068174239d@haskell.org> #15768: Using oneshot kqueue() on macOS -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 8.6.1 Libraries | Keywords: KQueue, | Operating System: MacOS X oneshot, parallel build | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Oneshot kqueue() is disabled on macOS due to https://ghc.haskell.org/trac/ghc/ticket/7651 Recall that the paper "Mio: A High-Performance Multicore IO Manager for GHC" says: "Mio also uses kqueue on OS X, since Darwin, the foundation for Apple’s OS X, is a variant of BSD. However, we encountered problems running parallel builds of the GHC compiler using Mio as described above. We have been unable to uncover the underlying source of the problem to our satisfaction. However, several Internet discussions suggest that the implementation of kqueue and pipe on OS X are unstable. We were able to resolve the observed prob- lems on OS X by avoiding the use of one-shot mode on OS X, instead unregistering events after they are delivered, and by send- ing wakeup writes to a pipe monitored by the dispatcher threads’ kqueue instances on every event registration. With these changes, the behavior on OS X, including parallel builds of GHC, has been stable." Now the serious bug on KQueue has been fixed: - https://ghc.haskell.org/trac/ghc/ticket/13903 - https://phabricator.haskell.org/D3692 So, I guess it's time to use oneshot on macOS. A patch is attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 01:38:42 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 01:38:42 -0000 Subject: [GHC] #15768: Using oneshot kqueue() on macOS In-Reply-To: <052.23d28fc3421f1bb560c819068174239d@haskell.org> References: <052.23d28fc3421f1bb560c819068174239d@haskell.org> Message-ID: <067.fdb75eb96f927bfb11d7c1a9f1d67d34@haskell.org> #15768: Using oneshot kqueue() on macOS -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.6.1 Resolution: | Keywords: KQueue, | oneshot, parallel build Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by kazu-yamamoto): * Attachment "macos-oneshot-kqueue.diff" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 04:41:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 04:41:48 -0000 Subject: [GHC] #15680: Flag for printing absolute paths in diagnostics In-Reply-To: <057.3257c78352f5d8777cf39f28c5a70ccf@haskell.org> References: <057.3257c78352f5d8777cf39f28c5a70ccf@haskell.org> Message-ID: <072.ce1ed110e3bb74ad12f07c68ed00466e@haskell.org> #15680: Flag for printing absolute paths in diagnostics -------------------------------------+------------------------------------- Reporter: | Owner: (none) quasicomputational | Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Wizek): * cc: Wizek (added) Comment: I am also interested in this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 07:11:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 07:11:21 -0000 Subject: [GHC] #15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable In-Reply-To: <043.18564262c59dae41f0454bb2c0047a1d@haskell.org> References: <043.18564262c59dae41f0454bb2c0047a1d@haskell.org> Message-ID: <058.d2b2c4728a457cf5bb3369f10fc2d53c@haskell.org> #15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): OK so if I understand this correctly here's how this happens: - hsc2hs built using bootstrap compiler, which in my case is 8.4.4, which doesn't have `getArgsWithResponseFiles` function. - So in [https://github.com/haskell/hsc2hs/commit/0535fe65467d1a07b838c17c62438086c12e98a9 this commit] the code with `getArgs` is used. - However, Cabal doesn't consider this possibility that a new enough GHC is built using a GHC without `getArgsWithResponseFiles`, and just based on hsc2hs version thinks that it should support `getArgsWithResponseFiles`, and passes arguments usign response file conventions. The question is: is this a GHC bug or a Cabal bug? - If we want newer GHCs (HEAD, 8.8) to always support response files this is a GHC bug. - Otherwise this is a Cabal bug. > We certainly can't move hsc2hs out of 'Phase 0' as some artifacts in 'Phase 1' depend on it What do you mean by "Phase"? I think we can build hsc2hs using stage 1 compiler and libs and that'd fix the problem, no? Any .hsc files for stage 1 can be compiled using bootstrap hsc2hs. Here's the hack I used to fix this on Cabal side: {{{ diff --git a/Cabal/Distribution/Simple/PreProcess.hs b/Cabal/Distribution/Simple/PreProcess.hs index daf419ef2..da231f9a0 100644 --- a/Cabal/Distribution/Simple/PreProcess.hs +++ b/Cabal/Distribution/Simple/PreProcess.hs @@ -396,7 +396,7 @@ ppHsc2hs bi lbi clbi = (hsc2hsProg, hsc2hsVersion, _) <- requireProgramVersion verbosity hsc2hsProgram anyVersion (withPrograms lbi) -- See Trac #13896 and https://github.com/haskell/cabal/issues/3122. - let hsc2hsSupportsResponseFiles = hsc2hsVersion >= mkVersion [0,68,4] + let hsc2hsSupportsResponseFiles = False pureArgs = genPureArgs gccProg inFile outFile if hsc2hsSupportsResponseFiles then withResponseFile }}} I'd suggest bumping priority, but I guess we should first decide whether to fix this on GHC side or Cabal side. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 07:18:26 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 07:18:26 -0000 Subject: [GHC] #15769: GHC 8.6 for macOS depends on homebrew Message-ID: <052.67c63639682c97d8d4af8a3fcaeffa11@haskell.org> #15769: GHC 8.6 for macOS depends on homebrew -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: Installing GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I guess the ghc-8.6.1-x86_64-apple-darwin.tar.xz is build with homebrew. So, it depends on homebrew's "libgmp". Since I'm using MacPorts, the following error occurs on installation: {{{ % sudo make install "utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries /ghc-prim dist-install "strip" '' '/usr/local/ghc-8.6.1' '/usr/local/ghc-8.6.1/lib/ghc-8.6.1' '/usr/local/ghc-8.6.1/share/doc/ghc-8.6.1/html/libraries' 'v p dyn' dyld: Library not loaded: /usr/local/opt/gmp/lib/libgmp.10.dylib Referenced from: /Users/kazu/Downloads/ghc-8.6.1/libraries/base/dist- install/build/libHSbase-4.12.0.0-ghc8.6.1.dylib Reason: image not found make[1]: *** [install_packages] Abort trap: 6 make: *** [install] Error 2 }}} After make a link from "/usr/local/opt/gmp/lib/libgmp.10.dylib" to "/opt/local/lib/libgmp.10.dylib" installed by MacPorts, the installation succeeds. But when using GHC 8.6.1, the following error occurs: {{{ [15 of 15] Compiling Network.DNS ( Network/DNS.hs, dist/build/Network/DNS.o ) ld: library not found for -lgmp clang: error: linker command failed with exit code 1 (use -v to see invocation) `gcc' failed in phase `Linker'. (Exit code: 1) cab: callCommand: cabal build (exit 1): failed }}} To fix this, the following is necessary: {{{ % export LIBRARY_PATH=/usr/lib:/opt/local/lib }}} - "/usr/lib" is for "libiconv" and should come first to hide "/opt/local/lib/libiconv" - "/opt/local/lib" is for "libgmp" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 08:24:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 08:24:17 -0000 Subject: [GHC] #15770: Missing optimisation opportunity in code gen for always-saturated applications? Message-ID: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> #15770: Missing optimisation opportunity in code gen for always-saturated applications? -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- As a part of the work on moving some fragile analyses from Core to final phase before code gen (#9718) I found an unused analysis in CoreToStg which basically assigns each binder this: {{{ data StgBinderInfo = NoStgBinderInfo | SatCallsOnly -- All occurrences are *saturated* *function* calls -- This means we don't need to build an info table and -- slow entry code for the thing -- Thunks never get this value }}} The idea is , as mentioned in the comment, for `SatCallsOnly` binder we can avoid generating code for slow entry. However this is currently not used (see Phab:D5232), and this ticket is to decide whether to use or remove this. I found these comments in `StgCmmClosure` that explains how this became unused and how it was used before: {{{ ----------------------------------------------------------------------------- -- staticClosureRequired ----------------------------------------------------------------------------- {- staticClosureRequired is never called (hence commented out) SimonMar writes (Sept 07) It's an optimisation we used to apply at one time, I believe, but it got lost probably in the rewrite of the RTS/code generator. I left that code there to remind me to look into whether it was worth doing sometime {- Avoiding generating entries and info tables ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ At present, for every function we generate all of the following, just in case. But they aren't always all needed, as noted below: [NB1: all of this applies only to *functions*. Thunks always have closure, info table, and entry code.] [NB2: All are needed if the function is *exported*, just to play safe.] * Fast-entry code ALWAYS NEEDED * Slow-entry code Needed iff (a) we have any un-saturated calls to the function OR (b) the function is passed as an arg OR (c) we're in the parallel world and the function has free vars [Reason: in parallel world, we always enter functions with free vars via the closure.] * The function closure Needed iff (a) we have any un-saturated calls to the function OR (b) the function is passed as an arg OR (c) if the function has free vars (ie not top level) Why case (a) here? Because if the arg-satis check fails, UpdatePAP stuffs a pointer to the function closure in the PAP. [Could be changed; UpdatePAP could stuff in a code ptr instead, but doesn't seem worth it.] [NB: these conditions imply that we might need the closure without the slow-entry code. Here's how. f x y = let g w = ...x..y..w... in ...(g t)... Here we need a closure for g which contains x and y, but since the calls are all saturated we just jump to the fast entry point for g, with R1 pointing to the closure for g.] * Standard info table Needed iff (a) we have any un-saturated calls to the function OR (b) the function is passed as an arg OR (c) the function has free vars (ie not top level) NB. In the sequential world, (c) is only required so that the function closure has an info table to point to, to keep the storage manager happy. If (c) alone is true we could fake up an info table by choosing one of a standard family of info tables, whose entry code just bombs out. [NB In the parallel world (c) is needed regardless because we enter functions with free vars via the closure.] If (c) is retained, then we'll sometimes generate an info table (for storage mgr purposes) without slow-entry code. Then we need to use an error label in the info table to substitute for the absent slow entry code. -} staticClosureRequired :: Name -> StgBinderInfo -> LambdaFormInfo -> Bool staticClosureRequired binder bndr_info (LFReEntrant top_level _ _ _ _) -- It's a function = ASSERT( isTopLevel top_level ) -- Assumption: it's a top-level, no-free-var binding not (satCallsOnly bndr_info) staticClosureRequired binder other_binder_info other_lf_info = True -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 08:36:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 08:36:43 -0000 Subject: [GHC] #15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable In-Reply-To: <043.18564262c59dae41f0454bb2c0047a1d@haskell.org> References: <043.18564262c59dae41f0454bb2c0047a1d@haskell.org> Message-ID: <058.e855e2d68f14c6765283add0a281139d@haskell.org> #15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): It's remarkable how many bugs this issue entails... :-) I've quickly addressed part of the issue via https://github.com/haskell/hsc2hs/commit/8807b4cd9b9efc719828b52cd9aecb9892d3d80b (one problem to consider is that we have at least two lib:Cabal releases out there eligible to custom Setup.hs scripts as well as included in the cabal-install-2.4.0.0 release which have the `>= 0.68.4` logic hardwired; so the metadata revision is the most economical way to mitigate that issue) So the next thing that needs fixing is the hsc2hs wrapper script used for inplace; moreoever I noticed yet another bug that wasn't mentioned here: GHC also installs a wrapper script into its installed `bin/` folder, e.g. `/opt/ghc/8.6.1/bin/hsc2hs`: {{{#!bash #!/bin/sh exedir="/opt/ghc/8.6.1/lib/ghc-8.6.1/bin" exeprog="hsc2hs" executablename="$exedir/$exeprog" datadir="/opt/ghc/8.6.1/share" bindir="/opt/ghc/8.6.1/bin" topdir="/opt/ghc/8.6.1/lib/ghc-8.6.1" HSC2HS_EXTRA="--cflag=-fno-stack-protector --lflag=-fuse-ld=gold" #!/bin/sh tflag="--template=$topdir/template-hsc.h" Iflag="-I$topdir/include/" for arg do case "$arg" in # On OS X, we need to specify -m32 or -m64 in order to get gcc to # build binaries for the right target. We do that by putting it in # HSC2HS_EXTRA. When cabal runs hsc2hs, it passes a flag saying which # gcc to use, so if we set HSC2HS_EXTRA= then we don't get binaries # for the right platform. So for now we just don't set HSC2HS_EXTRA= # but we probably want to revisit how this works in the future. # -c*) HSC2HS_EXTRA=;; # --cc=*) HSC2HS_EXTRA=;; -t*) tflag=;; --template=*) tflag=;; --) break;; esac done exec "$executablename" ${tflag:+"$tflag"} $HSC2HS_EXTRA ${1+"$@"} "$Iflag" }}} while this script doesn't inject any `--`s before response-file args, it exhibits a different problem: it's logic is completely bypassed when you use response files, as the script then cannot rewrite the flags because it doesn't look into the response files! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 08:45:39 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 08:45:39 -0000 Subject: [GHC] #15771: Could there be further refactoring to the `seq` typing rule Message-ID: <047.67c91dbc084b96f7038e1947295a8b6c@haskell.org> #15771: Could there be further refactoring to the `seq` typing rule -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Seq has a special cased typing rule. It's been greatly simplified in aab3c6d18416b3bc8e1378dfc4d485a9307ca5c7 . But there is still duplication, with a different rule applying when `seq` is used in infix position (unchanged in that commit), and when used in prefix position. Could there be a way to reduce code duplication here? I find it really hard to convince myself that both cases do the same thing. Though, really, given levity polymorphism, does `seq` need a special typing rule at all anymore? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 09:52:29 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 09:52:29 -0000 Subject: [GHC] #15772: Strange constraint error that disappears when adding another top-level declaration Message-ID: <047.9ab8f8e3bc7217de267282254f3eaa12@haskell.org> #15772: Strange constraint error that disappears when adding another top-level declaration -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this program: {{{#!hs {-# LANGUAGE DataKinds, TypeFamilies, TypeOperators, UndecidableInstances #-} module CURepro where import Data.Kind data NP (f :: Type -> Type) (xs :: [Type]) type family Curry (f :: Type -> Type) (xs :: [Type]) (r :: Type) (a :: Type) :: Constraint where Curry f xs r (f x -> a) = (xs ~ (x : Tail xs), Curry f (Tail xs) r a) Curry f xs r a = (xs ~ '[], r ~ a) type family Tail (a :: [Type]) :: [Type] where Tail (_ : xs) = xs uncurry_NP :: (Curry f xs r a) => (NP f xs -> r) -> a uncurry_NP = undefined fun_NP :: NP Id xs -> () fun_NP = undefined newtype Id a = MkId a -- test1 :: () -- test1 = uncurry_NP fun_NP (MkId 5) test2 :: () test2 = uncurry_NP fun_NP (MkId True) (MkId 5) (MkId True) }}} With GHC 8.6.1 (and also 8.4.3), this produces the following error message: {{{ CURepro.hs:27:9: error: • Couldn't match type ‘Tail t0’ with ‘Bool : Tail (Tail t0)’ arising from a use of ‘uncurry_NP’ The type variable ‘t0’ is ambiguous • In the expression: uncurry_NP fun_NP (MkId True) (MkId 5) (MkId True) In an equation for ‘test2’: test2 = uncurry_NP fun_NP (MkId True) (MkId 5) (MkId True) | 27 | test2 = uncurry_NP fun_NP (MkId True) (MkId 5) (MkId True) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} However, uncommenting the definition of `test1` makes the whole program check without error! I think both versions of the program should be accepted. I've tried to extract this from a much larger failing example, but did not manage to make it any smaller than this. In particular, the fact that `NP` is parameterised over a type constructor `f` seems to be somehow essential to trigger this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 10:56:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 10:56:24 -0000 Subject: [GHC] #15772: Strange constraint error that disappears when adding another top-level declaration In-Reply-To: <047.9ab8f8e3bc7217de267282254f3eaa12@haskell.org> References: <047.9ab8f8e3bc7217de267282254f3eaa12@haskell.org> Message-ID: <062.ab1bf26593b4b95462f721a464301445@haskell.org> #15772: Strange constraint error that disappears when adding another top-level declaration -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 11:38:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 11:38:43 -0000 Subject: [GHC] #15772: Strange constraint error that disappears when adding another top-level declaration In-Reply-To: <047.9ab8f8e3bc7217de267282254f3eaa12@haskell.org> References: <047.9ab8f8e3bc7217de267282254f3eaa12@haskell.org> Message-ID: <062.f5d77d2a1dc733d149733443ca93c0b9@haskell.org> #15772: Strange constraint error that disappears when adding another top-level declaration -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 12:38:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 12:38:47 -0000 Subject: [GHC] #15773: User Guide contains erroneous information about `-rtsopts` modes. Message-ID: <049.f59ba05675988fa8d9d5e3bd6258f696@haskell.org> #15773: User Guide contains erroneous information about `-rtsopts` modes. -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: Keywords: User Guide | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently the user guide section on [https://downloads.haskell.org/%7Eghc/latest/docs/html/users_guide/phases.html #ghc-flag--rtsopts[=%E2%9F%A8none|some|all|ignore|ignoreAll%E2%9F%A9 `-rtsopts`] specifies that `-rtsopts=some` is the default setting in the text under it, while the specified default is `all`. Happy to submit a patch if someone can confirm that `all` is actually the default, and that I'm not misunderstanding the meaning here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 12:39:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 12:39:47 -0000 Subject: [GHC] #15773: User Guide contains erroneous information about `-rtsopts` modes. In-Reply-To: <049.f59ba05675988fa8d9d5e3bd6258f696@haskell.org> References: <049.f59ba05675988fa8d9d5e3bd6258f696@haskell.org> Message-ID: <064.0feb52d8802063cf976e61c9f24408b1@haskell.org> #15773: User Guide contains erroneous information about `-rtsopts` modes. -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: Resolution: | Keywords: User Guide Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by _recursion: Old description: > Currently the user guide section on > [https://downloads.haskell.org/%7Eghc/latest/docs/html/users_guide/phases.html > #ghc-flag--rtsopts[=%E2%9F%A8none|some|all|ignore|ignoreAll%E2%9F%A9 > `-rtsopts`] specifies that `-rtsopts=some` is the default setting in the > text under it, while the specified default is `all`. > > Happy to submit a patch if someone can confirm that `all` is actually the > default, and that I'm not misunderstanding the meaning here. New description: Currently the user guide section on [https://downloads.haskell.org/%7Eghc/latest/docs/html/users_guide/phases.html #ghc-flag--rtsopts[=%E2%9F%A8none|some|all|ignore|ignoreAll%E2%9F%A9 `-rtsopts`] specifies that `-rtsopts=some` is the default setting in the text under it, while the specified default is `all`. > "[this is the default setting] Enable only the “safe” RTS options: (Currently only `-?` and `--info`.) Any other RTS options on the command line or in the `GHCRTS` environment variable causes the program with to abort with an error message." Happy to submit a patch if someone can confirm that `all` is actually the default, and that I'm not misunderstanding the meaning here. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 12:43:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 12:43:51 -0000 Subject: [GHC] #15773: User Guide contains erroneous information about `-rtsopts` modes. In-Reply-To: <049.f59ba05675988fa8d9d5e3bd6258f696@haskell.org> References: <049.f59ba05675988fa8d9d5e3bd6258f696@haskell.org> Message-ID: <064.1498811f038be26217909b79ec4f1373@haskell.org> #15773: User Guide contains erroneous information about `-rtsopts` modes. -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: Resolution: | Keywords: User Guide 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 _recursion): Turns out the section on [https://downloads.haskell.org/%7Eghc/latest/docs/html/users_guide/phases.html #ghc-flag--fno-gen-manifest `-fno-gen-manifest`] also has an error, though this one is just grammatical: > On Windows, GHC normally generates a manifestmanifest file... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 13:02:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 13:02:15 -0000 Subject: [GHC] #15773: User Guide contains erroneous information about `-rtsopts` modes. In-Reply-To: <049.f59ba05675988fa8d9d5e3bd6258f696@haskell.org> References: <049.f59ba05675988fa8d9d5e3bd6258f696@haskell.org> Message-ID: <064.295f4500d858dc51c162c2100bffe0ca@haskell.org> #15773: User Guide contains erroneous information about `-rtsopts` modes. -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: Resolution: | Keywords: User Guide 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 osa1): I agree that it looks a bit confusing, but it's actually correct. - The default (without any `-rtsopts`) is `-rtsopts=some` - If you just do `-rtsopts` it means `-rtsopts=all` So there are two defaults: when you don't pass `-rtsopts` at all, and you pass it without specifying the detail (all, some etc.). Not sure what's the best way to clarify this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 13:15:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 13:15:27 -0000 Subject: [GHC] #15773: User Guide contains erroneous information about `-rtsopts` modes. In-Reply-To: <049.f59ba05675988fa8d9d5e3bd6258f696@haskell.org> References: <049.f59ba05675988fa8d9d5e3bd6258f696@haskell.org> Message-ID: <064.8a75a0b359d1e7292068ebe822662c32@haskell.org> #15773: User Guide contains erroneous information about `-rtsopts` modes. -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: Resolution: | Keywords: User Guide 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 _recursion): Probably something as simple as 'This is the default setting when `-rtsopts` is not specified at all.' -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 13:16:04 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 13:16:04 -0000 Subject: [GHC] #15773: User Guide contains confusing information about `-rtsopts` modes. (was: User Guide contains erroneous information about `-rtsopts` modes.) In-Reply-To: <049.f59ba05675988fa8d9d5e3bd6258f696@haskell.org> References: <049.f59ba05675988fa8d9d5e3bd6258f696@haskell.org> Message-ID: <064.e8f8e6c3d58266e2ec198bad166bc31b@haskell.org> #15773: User Guide contains confusing information about `-rtsopts` modes. -------------------------------------+------------------------------------- Reporter: _recursion | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: Resolution: | Keywords: User Guide Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | 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 Oct 18 14:18:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 14:18:13 -0000 Subject: [GHC] #15774: SIGKILL only reports backtrace for one capability Message-ID: <046.e21c102c9324a56f284ce4eaee590729@haskell.org> #15774: SIGKILL only reports backtrace for one capability -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Runtime | Version: 8.6.1 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: -------------------------------------+------------------------------------- SIGKILL is intended to mirror the same signal's functionality provided by the JVM. That is, provide a snapshot of a processes' state in the form of backtraces on stderr. However, GHC's implementation currently only prints a backtrace for a single, arbitrary thread. This should be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 14:28:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 14:28:28 -0000 Subject: [GHC] #15774: SIGKILL only reports backtrace for one capability In-Reply-To: <046.e21c102c9324a56f284ce4eaee590729@haskell.org> References: <046.e21c102c9324a56f284ce4eaee590729@haskell.org> Message-ID: <061.93c1eb22a1622db7b16e2565fc4f3d71@haskell.org> #15774: SIGKILL only reports backtrace for one capability -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): There is the question of what the precise semantics of SIGKILL should be. Should we dump the state of all threads, all schedulable threads, or only currently scheduled threads? My feeling is the latter. This isn't entirely trivial to implement, especially given that we need to ensure that the output is readable (e.g. prevent interleaving of output from different capabilities). One option would be to add a new Message variety which can be used to request a backtrace from a capability. The thread handling the SIGKILL could then send this message to each capability and wait for their replies and print the result. This sounds complex for a debugging feature, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 14:46:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 14:46:15 -0000 Subject: [GHC] #15775: Interpreter is treating a comment character as an identifier character. Message-ID: <051.6777fe00ba4f223fa9a6c4406a4df30a@haskell.org> #15775: Interpreter is treating a comment character as an identifier character. -------------------------------------+------------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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 bringing dhall-lang up in a REPL I stumbled across a warning about a character in a haddock comment. Should the interpreter be treating a comment character as an identifier character? https://github.com/dhall-lang/dhall- haskell/issues/646#issuecomment-430776320 {{{#!hs {-# LANGUAGE CPP #-} data Expr s a -- | > Combine x y ~ x ∧ y = Combine (Expr s a) (Expr s a) }}} {{{ > stack runghc -- --interactive Intersect.hs Intersect.hs:13:29: error: warning: treating Unicode character as identifier character rather than as '^' symbol [-Wunicode-homoglyph] -- | > Combine x y ~ x ∧ y ^ | 13 | -- | > Combine x y ~ x ∧ y | ^ 1 warning generated. > stack runghc -- --version runghc 8.4.3 }}} There's a [https://github.com/BlockScope/unicode-homoglyph unicode- homoglyph] repo with the reproduction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 14:54:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 14:54:31 -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.d5067e0fa8f6305ebdb6e4010c052414@haskell.org> #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' ---------------------------------+---------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): This was fixed by cbd73bbbb7df080d5204098aa02e5f5d0d48823c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 14:56:20 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 14:56:20 -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.83a8ec2a5bbbfd509fe94fc542b456fa@haskell.org> #15112: ghc 8.4.2 on OS X: clang: warning: argument unused during compilation: '-nopie' ---------------------------------+---------------------------------------- Reporter: elaforge | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by bgamari): Unfortunately this fix didn't make it into 8.4.4. If you are experiencing this look at comment:7 for a workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 15:07:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 15:07:53 -0000 Subject: [GHC] #15772: Strange constraint error that disappears when adding another top-level declaration In-Reply-To: <047.9ab8f8e3bc7217de267282254f3eaa12@haskell.org> References: <047.9ab8f8e3bc7217de267282254f3eaa12@haskell.org> Message-ID: <062.0811c0d9a200e9c8a1ea9a93177147d5@haskell.org> #15772: Strange constraint error that disappears when adding another top-level declaration -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This appears to be a regression, since this program typechecks in GHC 8.0, but not in 8.2 and later. (It also typechecks in 7.8 and 7.10, provided you make some tweaks to support older GHCs). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 15:19:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 15:19:16 -0000 Subject: [GHC] #15767: "StgCmmEnv: variable not found" with FunctionalDependencies and FlexibleContexts In-Reply-To: <045.2239633dfbb009c41762262dc87d11d7@haskell.org> References: <045.2239633dfbb009c41762262dc87d11d7@haskell.org> Message-ID: <060.b3c08e9c9bdc316e1dc3c5ad86b535c1@haskell.org> #15767: "StgCmmEnv: variable not found" with FunctionalDependencies and FlexibleContexts -------------------------------------+------------------------------------- Reporter: roland | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 15:22:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 15:22:51 -0000 Subject: [GHC] #15772: Strange constraint error that disappears when adding another top-level declaration In-Reply-To: <047.9ab8f8e3bc7217de267282254f3eaa12@haskell.org> References: <047.9ab8f8e3bc7217de267282254f3eaa12@haskell.org> Message-ID: <062.870e61b32b6d55021b68f19383515c24@haskell.org> #15772: Strange constraint error that disappears when adding another top-level declaration -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This looks subtle. I think that `Note [FunEq occurs-check principle]` may be implicated, and I'm worried that there's something subtle about solve order. FWIW, `-fdefer-type-errors` forces implications to be built more aggressively, and that too makes it work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 15:26:53 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 15:26:53 -0000 Subject: [GHC] #7542: GHC doesn't optimize (strict) composition with id In-Reply-To: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> References: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> Message-ID: <061.b7985b77d11fb1662267b63239618b73@haskell.org> #7542: GHC doesn't optimize (strict) composition with id -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chessai): I'm using ghc 8.4.3, and compiling your example exactly with -O2 produces no difference whether i compile with '-fpedantic-bottoms' or '-fno- pedantic-bottoms' produce the same core. {{{ module Foo (foo) where (#) :: (b -> c) -> (a -> b) -> a -> c (#) f g = f `seq` g `seq` \x -> f (g x) foo :: (a -> b) -> [a] -> [b] foo f = map (id # f) }}} the core shows `foo = map`. This is in contrast to @nomeata's comment from 5 years ago, where compilation with -fpedantic-bottoms is necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 15:31:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 15:31:24 -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.78b1ba0f7f376f512b2f2371803d3b70@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: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by juhpetersen): I think ghc-8.4 now builds on s390x, right? I have builds for both 8.4.3 and 8.4.4 on Fedora. And there is 8.4.3+dfsg1-2+b1 for Debian. (Though it requires Debian's fix-build-using-unregisterized-v8.2.patch.) However 8.6.1 fails to build on s390x for me with ghc-8.2.2 even with the patch: {{{ : "/usr/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -package-db libraries/bootstrapping.conf -this-unit-id ghc-8.6.1 -hide-all-packages -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -icompiler/nativeGen -icompiler/parser -icompiler/prelude -icompiler/profiling -icompiler/rename -icompiler/simplCore -icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils -icompiler/stage1/build -Icompiler/stage1/build -icompiler/stage1/build/./autogen -Icompiler/stage1/build/./autogen -Icompiler/. -Icompiler/parser -Icompiler/utils -Icompiler/stage1 -Icompiler/stage1/build/. -Icompiler/stage1/build/parser -Icompiler/stage1/build/utils -Icompiler/stage1/build/stage1 -optP- include -optPcompiler/stage1/build/./autogen/cabal_macros.h -package-id array-0.5.2.0 -package-id base-4.10.1.0 -package-id binary-0.8.6.0 -package-id bytestring-0.10.8.2 -package-id containers-0.5.10.2 -package- id deepseq-1.4.3.0 -package-id directory-1.3.0.2 -package-id filepath-1.4.1.2 -package-id ghc-boot-8.6.1 -package-id ghc-boot-th-8.6.1 -package-id ghc-heap-8.6.1 -package-id ghci-8.6.1 -package-id hpc-0.6.0.3 -package-id process-1.6.1.0 -package-id template-haskell-2.14.0.0 -package-id terminfo-0.4.1.2 -package-id time-1.8.0.2 -package-id transformers-0.5.5.0 -package-id unix-2.7.2.2 -Wall -Wno-name-shadowing -Wnoncanonical-monad-instances -Wnoncanonical-monadfail-instances -Wnoncanonical-monoid-instances -this-unit-id ghc -XHaskell2010 -XNoImplicitPrelude -DNO_REGS -DNOSMP -optc-DNOSMP -DSTAGE=1 -Rghc-timing -Wcpp-undef -no-user-package-db -rtsopts -odir compiler/stage1/build -hidir compiler/stage1/build -stubdir compiler/stage1/build -c compiler/utils/Binary.hs -o compiler/stage1/build/Binary.o /tmp/ghc8bd3_0/ghc_3.hc: In function ‘cNqW_entry’: /tmp/ghc8bd3_0/ghc_3.hc:50988:61: error: error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? ((struct {W_ x;} __attribute__((packed))*) _sHcZ)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ stg_MUT_ARR_PTRS_FROZEN_DIRTY_info | 50988 | ((struct {W_ x;} __attribute__((packed))*) _sHcZ)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; | ^ /tmp/ghc8bd3_0/ghc_3.hc:50988:61: error: note: each undeclared identifier is reported only once for each function it appears in | 50988 | ((struct {W_ x;} __attribute__((packed))*) _sHcZ)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; | ^ /tmp/ghc8bd3_0/ghc_3.hc: In function ‘cNra_entry’: /tmp/ghc8bd3_0/ghc_3.hc:51045:61: error: error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? ((struct {W_ x;} __attribute__((packed))*) _sHcZ)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ stg_MUT_ARR_PTRS_FROZEN_DIRTY_info | 51045 | ((struct {W_ x;} __attribute__((packed))*) _sHcZ)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; | ^ /tmp/ghc8bd3_0/ghc_3.hc: In function ‘sHDG_entry’: /tmp/ghc8bd3_0/ghc_3.hc:56499:61: error: error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? ((struct {W_ x;} __attribute__((packed))*) _sHDE)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ stg_MUT_ARR_PTRS_FROZEN_DIRTY_info | 56499 | ((struct {W_ x;} __attribute__((packed))*) _sHDE)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; | ^ /tmp/ghc8bd3_0/ghc_3.hc: In function ‘cO9A_entry’: /tmp/ghc8bd3_0/ghc_3.hc:56819:61: error: error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? ((struct {W_ x;} __attribute__((packed))*) _sHDE)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ stg_MUT_ARR_PTRS_FROZEN_DIRTY_info | 56819 | ((struct {W_ x;} __attribute__((packed))*) _sHDE)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; | ^ /tmp/ghc8bd3_0/ghc_3.hc: In function ‘cOa5_entry’: /tmp/ghc8bd3_0/ghc_3.hc:56907:61: error: error: ‘stg_MUT_ARR_PTRS_FROZEN0_info’ undeclared (first use in this function); did you mean ‘stg_MUT_ARR_PTRS_FROZEN_DIRTY_info’? ((struct {W_ x;} __attribute__((packed))*) _sHDE)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ stg_MUT_ARR_PTRS_FROZEN_DIRTY_info | 56907 | ((struct {W_ x;} __attribute__((packed))*) _sHDE)->x = (W_)&stg_MUT_ARR_PTRS_FROZEN0_info; | ^ `gcc' failed in phase `C Compiler'. (Exit code: 1) <> make[1]: *** [compiler/ghc.mk:446: compiler/stage1/build/Binary.o] Error 1 }}} I suppose I should try building 8.6.1 with ghc-8.4.x. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 15:32:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 15:32:21 -0000 Subject: [GHC] #7542: GHC doesn't optimize (strict) composition with id In-Reply-To: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> References: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> Message-ID: <061.7014005d3e6345b9bae5db1f24e41b5f@haskell.org> #7542: GHC doesn't optimize (strict) composition with id -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chessai): It also produces the same core with -O1. With -O0, i see the problem, but i would expect that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 15:37:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 15:37:21 -0000 Subject: [GHC] #7542: GHC doesn't optimize (strict) composition with id In-Reply-To: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> References: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> Message-ID: <061.883d6ec5adb03fed2e7343071f46f805@haskell.org> #7542: GHC doesn't optimize (strict) composition with id -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Examples using `map` are important, but they also need to be taken with a grain of salt. List fusion will tear those things apart and put them together again and that can eliminate some problems we want to look at. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 15:53:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 15:53:56 -0000 Subject: [GHC] #7542: GHC doesn't optimize (strict) composition with id In-Reply-To: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> References: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> Message-ID: <061.364571da04554d7ca5218757f0737969@haskell.org> #7542: GHC doesn't optimize (strict) composition with id -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chessai): Ah, you're right. look at this: {{{ module Foo (foo) where data List a = Nil | Cons a (List a) mapList :: (a -> b) -> List a -> List b mapList f Nil = Nil mapList f (Cons a l) = Cons (f a) (mapList f l) (#) :: (b -> c) -> (a -> b) -> a -> c (#) f g = f `seq` g `seq` \x -> f (g x) foo :: (a -> b) -> List a -> List b foo f = mapList (id # f) xs }}} The core i get looks like: {{{ mapList mapList = \ @ a_avr @ b_avs f_atJ ds_d10t -> case ds_d10t of { Nil -> Nil; Cons a1_atL l_atM -> Cons (f_atJ a1_atL) (mapList f_atJ l_atM) foo = \ @ a_avy @ b_avz f_atQ xs_atR -> mapList f_atQ xs_atR }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 16:15:18 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 16:15:18 -0000 Subject: [GHC] #7542: GHC doesn't optimize (strict) composition with id In-Reply-To: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> References: <046.3bbc04071c1dd827d32f98edcf90fd64@haskell.org> Message-ID: <061.b250a6223a6fa7e7a23102b2ceb310bf@haskell.org> #7542: GHC doesn't optimize (strict) composition with id -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): That does look good. I don't know how we can determine whether the problem is sufficiently fixed. We have an interaction between a weird language feature (detectably lifted functions) and a somewhat illegitimate compiler transformation that tries to avoid paying too much for those. Everything feels a bit brittle and ill-specified. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 16:39:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 16:39:27 -0000 Subject: [GHC] #15772: Strange constraint error that disappears when adding another top-level declaration In-Reply-To: <047.9ab8f8e3bc7217de267282254f3eaa12@haskell.org> References: <047.9ab8f8e3bc7217de267282254f3eaa12@haskell.org> Message-ID: <062.f941d4d59b330f9bdc5d8ed914fe6776@haskell.org> #15772: Strange constraint error that disappears when adding another top-level declaration -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I think your hunch about `Note [FunEq occurs-check principle]` is right on the mark, since commit 1eec1f21268af907f59b5d5c071a9a25de7369c7 (`Another major constraint-solver refactoring`), which introduced that Note, is the first commit to demonstrate this bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 17:12:54 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 17:12:54 -0000 Subject: [GHC] #15772: Strange constraint error that disappears when adding another top-level declaration In-Reply-To: <047.9ab8f8e3bc7217de267282254f3eaa12@haskell.org> References: <047.9ab8f8e3bc7217de267282254f3eaa12@haskell.org> Message-ID: <062.ed6c70783bfc850a0c64408ad5b47793@haskell.org> #15772: Strange constraint error that disappears when adding another top-level declaration -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.6.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kosmikus): Thanks Ryan. I can confirm that my original test case works as expected with GHC 8.0. In addition, it also seems to typecheck ''much'' faster. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 18:12:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 18:12:10 -0000 Subject: [GHC] #15770: Missing optimisation opportunity in code gen for always-saturated applications? In-Reply-To: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> References: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> Message-ID: <058.881daacc23ff84170a6bb37a81b32fac@haskell.org> #15770: Missing optimisation opportunity in code gen for always-saturated applications? -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Even if there were saturated calls only, we'd still need the info table and slow entry code to support the heap/stack checks. And we'd need the info table for the closure, which might be referred to by SRTs. And the function has to be not externally visible. So it seems like only in very narrow circumstances could we save anything here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 18:13:28 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 18:13:28 -0000 Subject: [GHC] #15770: Missing optimisation opportunity in code gen for always-saturated applications? In-Reply-To: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> References: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> Message-ID: <058.6b8020b679f48000ee25c581ecc37855@haskell.org> #15770: Missing optimisation opportunity in code gen for always-saturated applications? -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Oh, and most of the time there isn't any slow entry code because we have built-in argument patterns that cover a good proportion of functions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 18:17:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 18:17:10 -0000 Subject: [GHC] #15775: Interpreter is treating a comment character as an identifier character. In-Reply-To: <051.6777fe00ba4f223fa9a6c4406a4df30a@haskell.org> References: <051.6777fe00ba4f223fa9a6c4406a4df30a@haskell.org> Message-ID: <066.8d4846cc802cad1708e9f630b8f74c7d@haskell.org> #15775: Interpreter is treating a comment character as an identifier character. -------------------------------------+------------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: GHCi | Version: 8.4.3 Resolution: | Keywords: CPP Operating System: 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 * keywords: => CPP Comment: It's worth noting that `-Wunicode-homoglyph` is not a GHC warning, but rather a CPP preprocessor warning (`clang`, perhaps?). Moreover, I cannot reproduce this on my machine, which leads to suspect that this is somewhat toolchain-specific. What OS and CPP command are you using? The latter can be found out by looking at the contents of the `${GHC_INSTALLATION_DIR}/lib/ghc-${GHC_VERSION}/settings` file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 19:01:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 19:01:47 -0000 Subject: [GHC] #14784: RTS header files can't be used with a C++ compiler In-Reply-To: <046.915be18a946df960093f8bf95e37faf5@haskell.org> References: <046.915be18a946df960093f8bf95e37faf5@haskell.org> Message-ID: <061.e763c0a707905d86db65b260bffd4c9f@haskell.org> #14784: RTS header files can't be used with a C++ compiler -------------------------------------+------------------------------------- Reporter: niteria | Owner: hvr Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Runtime System | 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 simonmar): * milestone: 8.4.1 => 8.6.2 Comment: I'd forgotten about this, we should get it fixed. It will certainly block us when we import GHC 8.4.x at work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 19:41:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 19:41:10 -0000 Subject: [GHC] #15776: Untested modules excluded from hpc coverage report Message-ID: <047.aba015236410b0c9a8eb3bd99c26c33e@haskell.org> #15776: Untested modules excluded from hpc coverage report -------------------------------------+------------------------------------- Reporter: ramirez7 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Code Coverage | 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: -------------------------------------+------------------------------------- If I add a new module to my project without adding testing and then generate a code coverage report, there is no mention of the new module in the report. I believe the correct behavior is for the module to be included with it being 0% covered (w/corresponding highlighted source) I posted some details here: https://www.reddit.com/r/haskell/comments/9mjwr6/how_to_get_hpc_to_include_fullyuncovered_modules/ As a workaround, I could probably use the hpc library to add 0% coverage for all modules to tix files. But that feels hacky. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 20:50:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 20:50:01 -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.63975f448a293ae137e5b2a56e1d4811@haskell.org> #14037: Fix fusion for GHC's utility functions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: rockbmb 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): D5240 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rockbmb): * differential: => D5240 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 20:50:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 20:50:55 -0000 Subject: [GHC] #15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable In-Reply-To: <043.18564262c59dae41f0454bb2c0047a1d@haskell.org> References: <043.18564262c59dae41f0454bb2c0047a1d@haskell.org> Message-ID: <058.62a0111a6b498c4af1c805aced0475d0@haskell.org> #15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5238 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ckoparkar): * differential: => Phab:D5238 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 21:26:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 21:26:24 -0000 Subject: [GHC] #15775: Interpreter is treating a comment character as an identifier character. In-Reply-To: <051.6777fe00ba4f223fa9a6c4406a4df30a@haskell.org> References: <051.6777fe00ba4f223fa9a6c4406a4df30a@haskell.org> Message-ID: <066.f8c0be9a5b7a184edc86f42d61687e4a@haskell.org> #15775: Interpreter is treating a comment character as an identifier character. -------------------------------------+------------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: GHCi | Version: 8.4.3 Resolution: | Keywords: CPP Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by philderbeast): {{{ > sw_vers ProductName: Mac OS X ProductVersion: 10.13.6 BuildVersion: 17G65 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 21:26:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 21:26:41 -0000 Subject: [GHC] #15775: Interpreter is treating a comment character as an identifier character. In-Reply-To: <051.6777fe00ba4f223fa9a6c4406a4df30a@haskell.org> References: <051.6777fe00ba4f223fa9a6c4406a4df30a@haskell.org> Message-ID: <066.8b08a4bfd2f33f996c9ac4bec6420297@haskell.org> #15775: Interpreter is treating a comment character as an identifier character. ---------------------------------+---------------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: GHCi | Version: 8.4.3 Resolution: | Keywords: CPP Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by philderbeast): * os: Unknown/Multiple => MacOS X -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 21:38:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 21:38:21 -0000 Subject: [GHC] #15777: Ordering of code in file affects compilation Message-ID: <046.415e5f15d1aaa2f7a3ae387df5079aa8@haskell.org> #15777: Ordering of code in file affects compilation -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 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: -------------------------------------+------------------------------------- consider the following module: {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} -- | Conversion between unlifted and lifted datatypes module Packed.Levity ( -- * Types Rep , Levity(..) ) where import Data.Kind (Type) import GHC.Types (TYPE, RuntimeRep(..), Int(..), Word(..)) import GHC.Exts (Int#, Word#, ByteArray#) type family Rep (a :: Type) :: RuntimeRep type instance Rep Int = IntRep type instance Rep Word = WordRep type Stuff# = (# Int#, Int# #) data Stuff = Stuff Int# Int# type instance Rep Stuff = TupleRep '[ 'IntRep, 'IntRep ] stuff# :: (# Int#, Int# #) -> Stuff stuff# (# x, y #) = Stuff x y unStuff# :: Stuff -> (# Int#, Int# #) unStuff# (Stuff x y) = (# x, y #) class Levity (a :: Type) where type Unlifted a :: TYPE (Rep a) box :: Unlifted a -> a unbox :: a -> Unlifted a instance Levity Int where type Unlifted Int = Int# box = I# unbox (I# i) = i instance Levity Word where type Unlifted Word = Word# box = W# unbox (W# w) = w instance Levity Stuff where type Unlifted Stuff = Stuff# box = stuff# unbox = unStuff# }}} This succeeds to compile. Now, if we move everything from `type family Rep` to `unStuff# (` to the bottom of the module, it fails to compile. {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} -- | Conversion between unlifted and lifted datatypes module Packed.Levity ( -- * Types Rep , Levity(..) ) where import Data.Kind (Type) import GHC.Types (TYPE, RuntimeRep(..), Int(..), Word(..)) import GHC.Exts (Int#, Word#, ByteArray#) class Levity (a :: Type) where type Unlifted a :: TYPE (Rep a) box :: Unlifted a -> a unbox :: a -> Unlifted a instance Levity Int where type Unlifted Int = Int# box = I# unbox (I# i) = i instance Levity Word where type Unlifted Word = Word# box = W# unbox (W# w) = w instance Levity Stuff where type Unlifted Stuff = Stuff# box = stuff# unbox = unStuff# type family Rep (a :: Type) :: RuntimeRep type instance Rep Int = IntRep type instance Rep Word = WordRep type Stuff# = (# Int#, Int# #) data Stuff = Stuff Int# Int# type instance Rep Stuff = TupleRep '[ 'IntRep, 'IntRep ] stuff# :: (# Int#, Int# #) -> Stuff stuff# (# x, y #) = Stuff x y unStuff# :: Stuff -> (# Int#, Int# #) unStuff# (Stuff x y) = (# x, y #) }}} {{{ ts.hs:33:25-30: error: • Expected kind ‘TYPE (Rep Stuff)’, but ‘Stuff#’ has kind ‘TYPE ('TupleRep '['IntRep, 'IntRep])’ • In the type ‘Stuff#’ In the type instance declaration for ‘Unlifted’ In the instance declaration for ‘Levity Stuff’ | 33 | type Unlifted Stuff = Stuff# | ^^^^^^ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 21:59:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 21:59:31 -0000 Subject: [GHC] #15775: Interpreter is treating a comment character as an identifier character. In-Reply-To: <051.6777fe00ba4f223fa9a6c4406a4df30a@haskell.org> References: <051.6777fe00ba4f223fa9a6c4406a4df30a@haskell.org> Message-ID: <066.a751caa4d66e5834e7db4687d0c973ba@haskell.org> #15775: Interpreter is treating a comment character as an identifier character. ---------------------------------+---------------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.4.3 Resolution: | Keywords: CPP Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by RyanGlScott): * status: infoneeded => new Comment: Indeed, I can reproduce this with `clang-cpp-6.0` on Linux: {{{ $ clang-cpp-6.0 Bug.hs Bug.hs:4:28: warning: treating Unicode character as identifier character rather than as '^' symbol [-Wunicode-homoglyph] -- | > Combine x y ~ x ∧ y ^ # 1 "Bug.hs" # 1 "" 1 # 1 "" 3 # 349 "" 3 # 1 "" 1 # 1 "" 2 # 1 "Bug.hs" 2 {-# LANGUAGE CPP #-} data Expr s a -- | > Combine x y ~ x ∧ y = Combine (Expr s a) (Expr s a) 1 warning generated. $ clang-cpp-6.0 --version clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 22:05:49 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 22:05:49 -0000 Subject: [GHC] #15777: Ordering of code in file affects compilation In-Reply-To: <046.415e5f15d1aaa2f7a3ae387df5079aa8@haskell.org> References: <046.415e5f15d1aaa2f7a3ae387df5079aa8@haskell.org> Message-ID: <061.395d16f16f986343b85c8288c61d6108@haskell.org> #15777: Ordering of code in file affects compilation -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12088 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => duplicate * related: => #12088 Comment: Thanks for the bug report. This is a duplicate of #12088 (as well as many other tickets listed in its related tickets pane), so I'll close this ticket in favor of #12088. As a crude workaround, you can use Template Haskell to force GHC to see the light. That is, this slight variant of the second program typechecks: {{{#!hs {-# LANGUAGE MagicHash #-} {-# LANGUAGE UnboxedTuples #-} {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} -- | Conversion between unlifted and lifted datatypes module Packed.Levity ( -- * Types Rep , Levity(..) ) where import Data.Kind (Type) import GHC.Types (TYPE, RuntimeRep(..), Int(..), Word(..)) import GHC.Exts (Int#, Word#, ByteArray#) class Levity (a :: Type) where type Unlifted a :: TYPE (Rep a) box :: Unlifted a -> a unbox :: a -> Unlifted a instance Levity Int where type Unlifted Int = Int# box = I# unbox (I# i) = i instance Levity Word where type Unlifted Word = Word# box = W# unbox (W# w) = w type family Rep (a :: Type) :: RuntimeRep type instance Rep Int = IntRep type instance Rep Word = WordRep type Stuff# = (# Int#, Int# #) data Stuff = Stuff Int# Int# type instance Rep Stuff = TupleRep '[ 'IntRep, 'IntRep ] $(pure []) instance Levity Stuff where type Unlifted Stuff = Stuff# box = stuff# unbox = unStuff# stuff# :: (# Int#, Int# #) -> Stuff stuff# (# x, y #) = Stuff x y unStuff# :: Stuff -> (# Int#, Int# #) unStuff# (Stuff x y) = (# x, y #) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 22:06:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 22:06:10 -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.2332a3fe30f709efee905af26b68852b@haskell.org> #12088: Type/data family instances in kind checking -------------------------------------+------------------------------------- Reporter: alexvieth | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.4.1 Component: Compiler (Type | Version: 8.1 checker) | Keywords: TypeInType, Resolution: | CUSKs Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11348, #12239, | Differential Rev(s): Phab:D2272 #12643, #13790, #15561, #15777 | Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/InterleavingTypeInstanceChecking| -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #11348, #12239, #12643, #13790, #15561 => #11348, #12239, #12643, #13790, #15561, #15777 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 22:27:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 22:27:00 -0000 Subject: [GHC] #15762: ghci command: report function's inferred visible type applications In-Reply-To: <051.4423f1d866fd4ea3150fb77ffc8a796f@haskell.org> References: <051.4423f1d866fd4ea3150fb77ffc8a796f@haskell.org> Message-ID: <066.32c01e987c95368b2554d237b5d41204@haskell.org> #15762: ghci command: report function's inferred visible type applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15610 #15613 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Would be invaluable for Ryan's [https://github.com/ekmett/eq/blob/9a8b1f61ad44a65c8f2ea5b900dc975658445c65/src/Data/Eq/Type/Hetero.hs eq] :P {{{#!hs symm :: forall (a::k) (b::j). (:==) @k @j a b -> (:==) @j @k b a symm ab = unpush @j @k @(:==) @b @a $ unsymm @k @j @(Push (:==)) @a @b $ hsubst @k @j @a @b @(Symm (Push (:==)) a) ab $ Symm @k @k @(Push (:==)) @a @a $ Push @k @k @(:==) @a @a $ refl @k @a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 22:31:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 22:31:13 -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.2c5b339602946dfff53b09a55ac71d9a@haskell.org> #14037: Fix fusion for GHC's utility functions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: rockbmb 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): Phab:D5240 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rockbmb): * differential: D5240 => Phab:D5240 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 22:54:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 22:54:36 -0000 Subject: [GHC] #15778: GHC HEAD-only panic (zonkTcTyVarToTyVar) Message-ID: <050.3cd9086426b45d98a8ca89f3f02fc672@haskell.org> #15778: GHC HEAD-only panic (zonkTcTyVarToTyVar) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.5 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash or panic Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following program typechecks on GHC 8.0.1 through 8.6.1: {{{#!hs {-# LANGUAGE AllowAmbiguousTypes #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE TypeInType #-} {-# LANGUAGE TypeOperators #-} module Bug where import Data.Kind type a ~> b = a -> b -> Type type family Apply (f :: k1 ~> k2) (x :: k1) :: k2 data family Sing (a :: k) data Flarble (a :: Type) where MkFlarble :: Flarble Bool data instance Sing (z :: Flarble a) where SMkFlarble :: Sing MkFlarble elimFlarble :: forall a (p :: forall x. Flarble x ~> Type) (f :: Flarble a). Sing f -> Apply p MkFlarble -> Apply p f elimFlarble s at SMkFlarble pMkFlarble = case s of (_ :: Sing (MkFlarble :: Flarble probablyABadIdea)) -> pMkFlarble }}} However, it panics on GHC HEAD: {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181015 for x86_64-unknown-linux): zonkTcTyVarToTyVar probablyABadIdea_aWn[tau:2] Bool Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcMType.hs:1627:34 in ghc:TcMType }}} If I replace `probablyABadIdea` with `Bool`, then it typechecks again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 22:55:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 22:55:52 -0000 Subject: [GHC] #15778: GHC HEAD-only panic (zonkTcTyVarToTyVar) In-Reply-To: <050.3cd9086426b45d98a8ca89f3f02fc672@haskell.org> References: <050.3cd9086426b45d98a8ca89f3f02fc672@haskell.org> Message-ID: <065.8a49d6cf5d14cb336c4ef54f972b6577@haskell.org> #15778: GHC HEAD-only panic (zonkTcTyVarToTyVar) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * version: 8.5 => 8.7 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 23:25:27 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 23:25:27 -0000 Subject: [GHC] #15263: Fuse zipWith3 In-Reply-To: <047.9d2de90ae6f11d155cd01f5a30989bf4@haskell.org> References: <047.9d2de90ae6f11d155cd01f5a30989bf4@haskell.org> Message-ID: <062.00aec41ec573d4b21e1f33d12703f0ba@haskell.org> #15263: Fuse zipWith3 -------------------------------------+------------------------------------- Reporter: goldfire | Owner: TDecki 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): Phab:D5241 Wiki Page: | -------------------------------------+------------------------------------- Changes (by TDecki): * differential: => Phab:D5241 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 18 23:28:14 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Oct 2018 23:28:14 -0000 Subject: [GHC] #15778: GHC HEAD-only panic (zonkTcTyVarToTyVar) In-Reply-To: <050.3cd9086426b45d98a8ca89f3f02fc672@haskell.org> References: <050.3cd9086426b45d98a8ca89f3f02fc672@haskell.org> Message-ID: <065.22744f52d45a25abefe9b13829f8d49c@haskell.org> #15778: GHC HEAD-only panic (zonkTcTyVarToTyVar) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This regression was introduced in commit 4d91cabcd5e3c603997d9876f6d30204a9b029c6 (`Allow scoped type variables refer to types`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 00:10:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 00:10:10 -0000 Subject: [GHC] #15726: Don't include Haskeline (and others) in the global package DB In-Reply-To: <044.07f22b221f9dd88b8989479d09a519f8@haskell.org> References: <044.07f22b221f9dd88b8989479d09a519f8@haskell.org> Message-ID: <059.b91bfe897678d8dfcafa4b5d9dcc3c6e@haskell.org> #15726: Don't include Haskeline (and others) in the global package DB -------------------------------------+------------------------------------- Reporter: judah | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed this sounds reasonable to me. The only possible issue is that it would also be no longer possible to link against the `ghci` library that ships with GHC (since it depends upon `haskeline`). However, I suspect this won't be a problem since GHC is more-or-less a normal Haskell package which `Cabal` should be able to install on its own. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 00:21:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 00:21:10 -0000 Subject: [GHC] #15328: cpphs: internal error: evacuate(static): strange closure type 8440 In-Reply-To: <044.e7d3083ced1a98874e271c4b45548264@haskell.org> References: <044.e7d3083ced1a98874e271c4b45548264@haskell.org> Message-ID: <059.2bdfb994c0ca051d2015c42a7170efe8@haskell.org> #15328: cpphs: internal error: evacuate(static): strange closure type 8440 -------------------------------------+------------------------------------- Reporter: cnmne | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Package system | Version: 8.4.3 Resolution: | Keywords: cabal, cpphs, | strange closure Operating System: MacOS X | Architecture: x86 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 00:23:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 00:23:06 -0000 Subject: [GHC] #15775: Interpreter is treating a comment character as an identifier character. In-Reply-To: <051.6777fe00ba4f223fa9a6c4406a4df30a@haskell.org> References: <051.6777fe00ba4f223fa9a6c4406a4df30a@haskell.org> Message-ID: <066.65c131d97ef73443e4601601ca73ea3b@haskell.org> #15775: Interpreter is treating a comment character as an identifier character. ---------------------------------+---------------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.4.3 Resolution: | Keywords: CPP 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): Oh dear, yet another reason why relying on the system's C preprocessor is a bad idea. More incentive to follow through on #14533. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 00:26:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 00:26:32 -0000 Subject: [GHC] #14784: RTS header files can't be used with a C++ compiler In-Reply-To: <046.915be18a946df960093f8bf95e37faf5@haskell.org> References: <046.915be18a946df960093f8bf95e37faf5@haskell.org> Message-ID: <061.aa4580da9d1c0bb830c4c7b319a4d0fc@haskell.org> #14784: RTS header files can't be used with a C++ compiler -------------------------------------+------------------------------------- Reporter: niteria | Owner: hvr Type: bug | Status: new Priority: highest | Milestone: 8.6.3 Component: Runtime System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.2 => 8.6.3 Comment: Unless we plan on fixing this in the next 48 hours I'm not sure this will make it into 8.6.2. That being said, I agree that we should fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 00:37:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 00:37:58 -0000 Subject: [GHC] #15066: EtaExpandLevPoly triggers a core lint error in profasm/profthreaded ways In-Reply-To: <048.d54d45a802f9d9d37b6c6fc6639d5d39@haskell.org> References: <048.d54d45a802f9d9d37b6c6fc6639d5d39@haskell.org> Message-ID: <063.6eac3b061de83ec79ea098ff4b532d43@haskell.org> #15066: EtaExpandLevPoly triggers a core lint error in profasm/profthreaded ways ---------------------------------+---------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: EtaExpandLevPoly Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: => 8.8.1 Comment: Strangely this no longer fails in the profiled ways as of 46f2906d1c6e1fb732a90882487479a2ebf19ca1. Ideally we would determine why but life is short. I'm going to close; reopen if this rears its ugly head again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 00:41:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 00:41:56 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow In-Reply-To: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> References: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> Message-ID: <057.d09e14b5ba65a2a9f8650bc468bb54c1@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof recomp007 | space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): `EtaExpandLevPoly` used to fail with a Core Lint failure (see #15066). It seems that the issue has worked itself out. I'll mark as fixed but if someone wants a project it would be great to reverse-bisect this to see what fixed it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 00:46:24 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 00:46:24 -0000 Subject: [GHC] #15349: fixST is a bit wrong In-Reply-To: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> References: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> Message-ID: <060.15f6faaa5c30cec7512b9b162339a573@haskell.org> #15349: fixST is a bit wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4948 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmm, as reported in ticket:15738#comment:2 and on CircleCI T15349 seems to fail in the `ghci` way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 01:08:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 01:08:22 -0000 Subject: [GHC] #14784: RTS header files can't be used with a C++ compiler In-Reply-To: <046.915be18a946df960093f8bf95e37faf5@haskell.org> References: <046.915be18a946df960093f8bf95e37faf5@haskell.org> Message-ID: <061.30c0df64a3a22246eef36ae76a7dffde@haskell.org> #14784: RTS header files can't be used with a C++ compiler -------------------------------------+------------------------------------- Reporter: niteria | Owner: hvr Type: bug | Status: patch Priority: highest | Milestone: 8.6.3 Component: Runtime System | 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:D5244 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D5244 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 01:19:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 01:19:09 -0000 Subject: [GHC] #15768: Using oneshot kqueue() on macOS In-Reply-To: <052.23d28fc3421f1bb560c819068174239d@haskell.org> References: <052.23d28fc3421f1bb560c819068174239d@haskell.org> Message-ID: <067.8b2fad71cb25be01de1fecf683342d0a@haskell.org> #15768: Using oneshot kqueue() on macOS -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Core Libraries | Version: 8.6.1 Resolution: | Keywords: KQueue, | oneshot, parallel build Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * priority: normal => highest * milestone: => 8.8.1 Comment: Thanks Kazu! Let's try to get this in for 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 01:30:39 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 01:30:39 -0000 Subject: [GHC] #8316: GHCi debugger panics when trying force a certain variable In-Reply-To: <044.9ebacfadd8f49d7b017849858920cbb4@haskell.org> References: <044.9ebacfadd8f49d7b017849858920cbb4@haskell.org> Message-ID: <059.170421510e9417834cd8f39b02787cb5@haskell.org> #8316: GHCi debugger panics when trying force a certain variable -------------------------------------+------------------------------------- Reporter: guest | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: GHCi | Version: 7.6.3 Resolution: | Keywords: debugger Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4535, Wiki Page: | Phab:D5179 -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => new * resolution: fixed => Comment: I left a comment drawing attention to this on the Phab:D5179 before merging but yes, you are right, we should wait to close this until all of these tasks are done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 01:34:13 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 01:34:13 -0000 Subject: [GHC] #15779: Follow-ups to D5169 Message-ID: <046.2d2f72ea3821ecb52abedacaf1c0155d@haskell.org> #15779: Follow-ups to D5169 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Simonmar points out that there are a few follow-up tasks after Phab:D5169: > > 1. We should build these at installation time, so they don't have to go into the binary distribution (the same goes for the vanilla way` libHSfoo.o` files) > 2. This also needs to be done in Hadrian > -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 01:39:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 01:39:22 -0000 Subject: [GHC] #15660: source file modify race leads to inconsistent error message In-Reply-To: <047.0bb5271dc9d70158327714b5707bda53@haskell.org> References: <047.0bb5271dc9d70158327714b5707bda53@haskell.org> Message-ID: <062.dfedd7b726cb262c1248d39c1a0434be@haskell.org> #15660: source file modify race leads to inconsistent error message -------------------------------------+------------------------------------- Reporter: joeyhess | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => newcomer Comment: > So it would probably suffice for ghc to detect the race and not quote the wrong version of the file. I suppose it could use file stat information or a hash and so avoid keeping a copy. Yes, this sounds like a good 80% solution. Sounds like a good task for someone new to GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 01:49:40 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 01:49:40 -0000 Subject: [GHC] #15349: fixST is a bit wrong In-Reply-To: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> References: <045.c66c57b0f1e688e823bf4cb8db932ffe@haskell.org> Message-ID: <060.376a48488ee65267f7546d07da7a6e5a@haskell.org> #15349: fixST is a bit wrong -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: dfeuer Type: bug | Status: closed Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4948 Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:16 bgamari]: > Hmm, as reported in ticket:15738#comment:2 and on CircleCI T15349 seems to fail in the `ghci` way. I believe you mean ticket:15736#comment:2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 02:47:40 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 02:47:40 -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.aaf262d55e6b609a76b775b459c0e412@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: Linux | Architecture: Other Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Changes (by juhpetersen): * cc: juhpetersen (added) * failure: None/Unknown => Building GHC failed * architecture: Unknown/Multiple => Other -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 04:14:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 04:14:32 -0000 Subject: [GHC] #15780: ghc-8.4.4 failed to build on armv7 and aarch64 Message-ID: <050.81668a88e354aac40559f0e53fb7e269@haskell.org> #15780: ghc-8.4.4 failed to build on armv7 and aarch64 -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Keywords: | Operating System: Linux Architecture: arm | Type of failure: Building GHC | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- ghc-8.4.4 is failing to build for me on Fedora ARM archs (both 32bit and 64bit). https://koji.fedoraproject.org/koji/taskinfo?taskID=30284522 They both fail in the same way: {{{ "inplace/bin/ghc-stage1" -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.o "inplace/bin/ghc-stage1" -static -H32m -O -Wall -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-unit-id rts -dcmm-lint -i -irts -irts/dist/build -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen -O2 -Wcpp-undef -Wnoncanonical-monad-instances -c rts/StgMiscClosures.cmm -o rts/dist/build/StgMiscClosures.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.4.4 for aarch64-unknown-linux): padLiveArgs -- i > regNum ?? CallStack (from HasCallStack): error, called at compiler/llvmGen/LlvmCodeGen/Base.hs:194:27 in ghc:LlvmCodeGen.Base Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug make[1]: *** [rts/ghc.mk:295: rts/dist/build/HeapStackCheck.o] Error 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 04:47:30 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 04:47:30 -0000 Subject: [GHC] #15700: Plugins cause GHC to panic: cannot find dynamic libraries In-Reply-To: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> References: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> Message-ID: <059.1e5538b91dabf8c1f99df42e225d955d@haskell.org> #15700: Plugins cause GHC to panic: cannot find dynamic libraries -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15492 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sheaf): * Attachment "DsUsage.hs" added. thrown-together fix for plugin change check crash on windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 04:47:45 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 04:47:45 -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.a614b54d53c27b08e2feaf436e5eeb3f@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: | -------------------------------------+------------------------------------- Comment (by sheaf): I'm sure this isn't news to anyone, but after testing I can confirm that plugins work on GHC 8.6.1 on Windows if one bypasses the test for whether a plugin has changed (`mkPluginUsage` in `DsUsage.hs`). So it seems the solution should be to make the functions that look up plugin locations, within `mkPluginUsage`, work correctly on Windows. The only relevant files that I can see on my machine are static `.a` files. For instance, instead of the non-existent `libHSghc- typelits-_-0.6.2-faf29727b3dbdfa09cfb6f0c881a2a227b5d2bb0-ghc8.6.1.dll`, I have `libHSghc- typelits-_-0.6.2-faf29727b3dbdfa09cfb6f0c881a2a227b5d2bb0.a`, which I have to assume is what is being used by GHC for plugin usage. \\ Does this mean mkPluginUsage should be hashing these files instead? On Windows only? The attached `DsUsage.hs` file is working on my end, inelegant as it may be. It tries looking for .a files if looking for dynamic files (.dll, .so, .dylib) fails. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 04:48:06 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 04:48:06 -0000 Subject: [GHC] #15700: Plugins cause GHC to panic: cannot find dynamic libraries In-Reply-To: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> References: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> Message-ID: <059.0f13bc3a6fec5f4bc7da9c8089ad734d@haskell.org> #15700: Plugins cause GHC to panic: cannot find dynamic libraries -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15492 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sheaf): I'm sure this isn't news to anyone, but after testing I can confirm that plugins work on GHC 8.6.1 on Windows if one bypasses the test for whether a plugin has changed (`mkPluginUsage` in `DsUsage.hs`). So it seems the solution should be to make the functions that look up plugin locations, within `mkPluginUsage`, work correctly on Windows. The only relevant files that I can see on my machine are static `.a` files. For instance, instead of the non-existent `libHSghc- typelits-_-0.6.2-faf29727b3dbdfa09cfb6f0c881a2a227b5d2bb0-ghc8.6.1.dll`, I have `libHSghc- typelits-_-0.6.2-faf29727b3dbdfa09cfb6f0c881a2a227b5d2bb0.a`, which I have to assume is what is being used by GHC for plugin usage. \\ Does this mean mkPluginUsage should be hashing these files instead? On Windows only? The attached `DsUsage.hs` file is working on my end, inelegant as it may be. It tries looking for .a files if looking for dynamic files (.dll, .so, .dylib) fails. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 06:10:23 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 06:10:23 -0000 Subject: [GHC] #15775: Interpreter is treating a comment character as an identifier character. In-Reply-To: <051.6777fe00ba4f223fa9a6c4406a4df30a@haskell.org> References: <051.6777fe00ba4f223fa9a6c4406a4df30a@haskell.org> Message-ID: <066.3aee1bf1df087f22211569e014494915@haskell.org> #15775: Interpreter is treating a comment character as an identifier character. ---------------------------------+---------------------------------------- Reporter: philderbeast | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.4.3 Resolution: | Keywords: CPP 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 potato44): This is/was causing problems for the Agda people too. https://github.com/agda/agda/commit/5ff3fc5155af087c3881915ed82e45c9d06523df -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 06:51:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 06:51:43 -0000 Subject: [GHC] #15780: ghc-8.4.4 failed to build on armv7 and aarch64 In-Reply-To: <050.81668a88e354aac40559f0e53fb7e269@haskell.org> References: <050.81668a88e354aac40559f0e53fb7e269@haskell.org> Message-ID: <065.843f8f5b46946e56008f7a0fa85c1f21@haskell.org> #15780: ghc-8.4.4 failed to build on armv7 and aarch64 ----------------------------------------+------------------------------ Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by juhpetersen): I suspect this is caused by commit 6e361d89 ("Multiple fixes / improvements for LLVM backend") -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 07:10:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 07:10:53 -0000 Subject: [GHC] #14251: LLVM Code Gen messes up registers In-Reply-To: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> References: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> Message-ID: <062.31f4b98e551d778f3458ba356a75053f@haskell.org> #14251: LLVM Code Gen messes up registers -------------------------------------+------------------------------------- Reporter: angerman | Owner: kavon Type: bug | Status: closed Priority: highest | Milestone: 8.6.2 Component: Compiler (LLVM) | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5190 Wiki Page: | -------------------------------------+------------------------------------- Changes (by juhpetersen): * cc: juhpetersen (added) Comment: Was this tested on ARM? (see #15780) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 07:20:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 07:20:57 -0000 Subject: [GHC] #15779: Follow-ups to D5169 In-Reply-To: <046.2d2f72ea3821ecb52abedacaf1c0155d@haskell.org> References: <046.2d2f72ea3821ecb52abedacaf1c0155d@haskell.org> Message-ID: <061.bce70622538d840a380dd7912f611671@haskell.org> #15779: Follow-ups to D5169 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * priority: normal => highest * milestone: => 8.8.1 Comment: At least point (2) is a blocker for 8.8.1, and we ought to do (1) too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 08:02:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 08:02:22 -0000 Subject: [GHC] #15770: Missing optimisation opportunity in code gen for always-saturated applications? In-Reply-To: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> References: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> Message-ID: <058.217ac7b635418a76fd8fb50046f52948@haskell.org> #15770: Missing optimisation opportunity in code gen for always-saturated applications? -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5232 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * differential: => Phab:D5232 Comment: Great, because this means less work for #9718. Shall we merge Phab:D5232? > info table and slow entry code to support the heap/stack checks Out of curiosity, why do we need entry code for heap/stack checks? Do we use slow entry code as continuation when we do GC? Or something else? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 08:32:52 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 08:32:52 -0000 Subject: [GHC] #15779: Follow-ups to D5169 In-Reply-To: <046.2d2f72ea3821ecb52abedacaf1c0155d@haskell.org> References: <046.2d2f72ea3821ecb52abedacaf1c0155d@haskell.org> Message-ID: <061.a251ff4f6c85d24112d527ad9f9a8a75@haskell.org> #15779: Follow-ups to D5169 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 08:53:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 08:53:20 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow In-Reply-To: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> References: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> Message-ID: <057.cc208e059019232ab12ae8faf7760379@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof recomp007 | space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 09:43:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 09:43:43 -0000 Subject: [GHC] #15757: Coercion Variable Almost Devoid Checking in ForAllCo In-Reply-To: <047.e3bc1ec429883d9b3738da4edd6cb2a8@haskell.org> References: <047.e3bc1ec429883d9b3738da4edd6cb2a8@haskell.org> Message-ID: <062.496aeae9c1370ac12c507800198aabc1@haskell.org> #15757: Coercion Variable Almost Devoid Checking in ForAllCo -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning 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: #15497 | Differential Rev(s): Phab:D5231 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ningning Xie ): In [changeset:"879db5595208fb665ff1a0a2b12b9921d3efae0e/ghc" 879db559/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="879db5595208fb665ff1a0a2b12b9921d3efae0e" Adding almost devoid check for covar in ForAllCo Summary: For the sake of consistency of the dependent core, there is a restriction on where a coercion variable can appear in ForAllCo: the coercion variable can appear nowhere except in coherence coercions. Currently this restriction is missing in Core. The goal of this patch is to add the missing restriction. After discussion, we decide: coercion variables can appear nowhere except in `GRefl` and `Refl`. Relaxing the restriction to include `Refl` should not break consistency, we premuse. Test Plan: ./validate Reviewers: goldfire, simonpj, bgamari Reviewed By: goldfire Subscribers: rwbarton, carter GHC Trac Issues: #15757 Differential Revision: https://phabricator.haskell.org/D5231 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 09:51:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 09:51:55 -0000 Subject: [GHC] #15757: Coercion Variable Almost Devoid Checking in ForAllCo In-Reply-To: <047.e3bc1ec429883d9b3738da4edd6cb2a8@haskell.org> References: <047.e3bc1ec429883d9b3738da4edd6cb2a8@haskell.org> Message-ID: <062.f58c6cab6372e2b814d54156ef68637b@haskell.org> #15757: Coercion Variable Almost Devoid Checking in ForAllCo -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15497 | Differential Rev(s): Phab:D5231 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ningning): * status: new => closed * resolution: => fixed Comment: Updating core-spec is a good idea. Will do in the near future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 10:24:47 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 10:24:47 -0000 Subject: [GHC] #12677: Type equality in constraint not used? In-Reply-To: <051.fe74d91fb30a3bb9a0169149567d721f@haskell.org> References: <051.fe74d91fb30a3bb9a0169149567d721f@haskell.org> Message-ID: <066.d7d2a3333854b1f4d8d122a65d08cb97@haskell.org> #12677: Type equality in constraint not used? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13337, #15710 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #13337 => #13337, #15710 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 10:25:01 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 10:25:01 -0000 Subject: [GHC] #15710: Should GHC accept a type signature that needs coercion quantification? In-Reply-To: <046.5bf95bcb5259eed36b1ec15b928de8c8@haskell.org> References: <046.5bf95bcb5259eed36b1ec15b928de8c8@haskell.org> Message-ID: <061.54729bde21d57c34fde622dcdd9531ee@haskell.org> #15710: Should GHC accept a type signature that needs coercion quantification? -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12677 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #12677 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 10:29:12 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 10:29:12 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.0b3b1728c0447731a23124f7ac91207d@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: patch 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): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): I realised that while the heuristics currently employed work quite well, we are too pessimistic wrt. unsaturated applications. Currently, we don't lift binders that have undersaturated calls [https://github.com/sgraf812/ghc/blob/c4b8c04f26b5045da8015dd7289cd176a4addff2/compiler/simplStg/StgLiftLams/Analysis.hs#L250 at all]. But there's nothing wrong with lifting those, as long as allocations don't get worse. So I set out to get rid of that heuristic and replaced it with a check that disallows occurrences in argument position instead (previously, this would be subsumed by the undersaturated call check). The results are inconclusive, with some significant slow-downs which I could pin-point to a bug in the heuristic that detects known calls. Currently, we say that a call to some variable would be lowered as a known call when `idArity bndr > 0`. But there actually are thunks (e.g. arity 0) of function type, which count as known calls. Abstracting over these thunks makes for an increase in allocation and runtime. I'm investigating more robust ways of detecting known calls. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 11:07:08 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 11:07:08 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.54d058f0415ce9e2e0737ac7e6ea22b4@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201, Phab:D5226 -------------------------------------+------------------------------------- Comment (by osa1): > I don't like disabling binder swapping - it's there for a good reason! I don't feel strongly about this, but just out of curiosity I compared nofib outputs of GHC HEAD with and without this patch: (disables swapping case binder swapping) {{{ diff --git a/compiler/simplCore/SetLevels.hs b/compiler/simplCore/SetLevels.hs index b8212c72f3..8fabf98179 100644 --- a/compiler/simplCore/SetLevels.hs +++ b/compiler/simplCore/SetLevels.hs @@ -469,15 +469,15 @@ lvlCase env scrut_fvs scrut' case_bndr ty alts -- Always float the case if possible -- Unlike lets we don't insist that it escapes a value lambda do { (env1, (case_bndr' : bs')) <- cloneCaseBndrs env dest_lvl (case_bndr : bs) - ; let rhs_env = extendCaseBndrEnv env1 case_bndr scrut' - ; body' <- lvlMFE rhs_env True body + -- ; let rhs_env = extendCaseBndrEnv env1 case_bndr scrut' + ; body' <- lvlMFE env1 True body ; let alt' = (con, map (stayPut dest_lvl) bs', body') ; return (Case scrut' (TB case_bndr' (FloatMe dest_lvl)) ty' [alt']) } | otherwise -- Stays put = do { let (alts_env1, [case_bndr']) = substAndLvlBndrs NonRecursive env incd_lvl [case_bndr] - alts_env = extendCaseBndrEnv alts_env1 case_bndr scrut' - ; alts' <- mapM (lvl_alt alts_env) alts + -- alts_env = extendCaseBndrEnv alts_env1 case_bndr scrut' + ; alts' <- mapM (lvl_alt alts_env1) alts ; return (Case scrut' case_bndr' ty' alts') } where ty' = substTy (le_subst env) ty @@ -1496,6 +1496,7 @@ floatTopLvlOnly le = floatToTopLevelOnly (le_switches le) incMinorLvlFrom :: LevelEnv -> Level incMinorLvlFrom env = incMinorLvl (le_ctxt_lvl env) +{- -- extendCaseBndrEnv adds the mapping case-bndr->scrut-var if it can -- See Note [Binder-swap during float-out] extendCaseBndrEnv :: LevelEnv @@ -1507,6 +1508,7 @@ extendCaseBndrEnv le@(LE { le_subst = subst, le_env = id_env }) = le { le_subst = extendSubstWithVar subst case_bndr scrut_var , le_env = add_id id_env (case_bndr, scrut_var) } extendCaseBndrEnv env _ _ = env +-} -- See Note [Join ceiling] placeJoinCeiling :: LevelEnv -> LevelEnv }}} There's one -0.3% allocation in one program ("pic") with this patch, the rest is the same. No change in binary sizes. So perhaps this is not as important as we thought. > It would be illuminating to know (perhaps via -ticky) what code is improved by reverting the app_ok general case Have you seen comment:76? I show one example there, showing Core with and without the change in `app_ok`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 12:02:34 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 12:02:34 -0000 Subject: [GHC] #15770: Missing optimisation opportunity in code gen for always-saturated applications? In-Reply-To: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> References: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> Message-ID: <058.b889729a2429badcb0014bb1836e3979@haskell.org> #15770: Missing optimisation opportunity in code gen for always-saturated applications? -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5232 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Yes, the slow entry code is used as the continuation for the heap check for a function entry point, which saves a lot of code. See `stg_gc_fun` in `rts/HeapStackCheck.cmm`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 12:36:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 12:36:25 -0000 Subject: [GHC] #15781: Extraneous parentheses required to parse kind signature on the RHS of a type synonym Message-ID: <050.be8b8c1a94d013f8504422795938ca88@haskell.org> #15781: Extraneous parentheses required to parse kind signature on the RHS of a type synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 (Parser) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- After Phab:D5173, the restrictions about where kind signatures can appear in the source were significantly relaxed so that things like: {{{#!hs type family F where F = Int :: Type }}} Are now allowed. However, there appears to be one case that was missed in that patch: the right-hand sides of type synonyms. For instance, I would expect the following to parse: {{{#!hs {-# LANGUAGE KindSignatures #-} module Bug where import Data.Kind type F = Int :: Type }}} However, even GHC HEAD still refuses to parse this: {{{ $ /opt/ghc/head/bin/ghci Bug.hs GHCi, version 8.7.20181015: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:6:14: error: parse error on input ‘::’ | 6 | type F = Int :: Type | ^^ }}} Luckily, I don't think this will be too difficult to fix, since all that needs to be done is to update the parser production for type synonyms to use something like `ktype` instead of `ctype`. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 12:38:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 12:38:20 -0000 Subject: [GHC] #15782: Visible type/kind applications in declaration of data/type constructors Message-ID: <051.20d3160ec20ed7bdea0f42672fc7888b@haskell.org> #15782: Visible type/kind applications in declaration of data/type constructors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #12045 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Two "logical" placements of visible type / kind application, in the declaration of data and type constructors (from [https://phabricator.haskell.org/D5229#144558 Phab comment]). {{{#!hs data Proxy :: forall k. k -> Type where MkProxy :: Proxy @k (a :: k) -- can be written data Proxy @k :: k -> Type where MkProxy @k :: Proxy @k (a :: k) }}} & {{{#!hs data Fin :: N -> Type where FinO :: Fin (S n) FinS :: Fin n -> Fin (S n) -- can be written data Fin :: N -> Type where FinO @n :: Fin (S n) FinS @n :: Fin n -> Fin (S n) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 12:40:00 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 12:40:00 -0000 Subject: [GHC] #15782: Visible type/kind applications in declaration of data/type constructors In-Reply-To: <051.20d3160ec20ed7bdea0f42672fc7888b@haskell.org> References: <051.20d3160ec20ed7bdea0f42672fc7888b@haskell.org> Message-ID: <066.f1492fda674fedeacb2f3b777fb1f258@haskell.org> #15782: Visible type/kind applications in declaration of data/type constructors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12045 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > Two "logical" placements of visible type / kind application, in the > declaration of data and type constructors (from > [https://phabricator.haskell.org/D5229#144558 Phab comment]). > > > {{{#!hs > data > Proxy :: forall k. k -> Type where > MkProxy :: Proxy @k (a :: k) > > -- can be written > > data > Proxy @k :: k -> Type where > MkProxy @k :: Proxy @k (a :: k) > }}} > > & > > {{{#!hs > data > Fin :: N -> Type where > FinO :: Fin (S n) > FinS :: Fin n -> Fin (S n) > > -- can be written > > data > Fin :: N -> Type where > FinO @n :: Fin (S n) > FinS @n :: Fin n -> Fin (S n) > }}} New description: I'm making this ticket to keep track of this, I don't know if it's a good idea. Allow visible type/kind applications when declaring data/type constructors on the LHS of `::` (from [https://phabricator.haskell.org/D5229#144558 Phab comment]). {{{#!hs data Proxy :: forall k. k -> Type where MkProxy :: Proxy @k (a :: k) -- can be written data Proxy @k :: k -> Type where MkProxy @k :: Proxy @k (a :: k) }}} & {{{#!hs data Fin :: N -> Type where FinO :: Fin (S n) FinS :: Fin n -> Fin (S n) -- can be written data Fin :: N -> Type where FinO @n :: Fin (S n) FinS @n :: Fin n -> Fin (S n) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 12:43:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 12:43:32 -0000 Subject: [GHC] #15782: Visible type/kind applications in declaration of data/type constructors In-Reply-To: <051.20d3160ec20ed7bdea0f42672fc7888b@haskell.org> References: <051.20d3160ec20ed7bdea0f42672fc7888b@haskell.org> Message-ID: <066.570801dd3979b874158d3c1eec394287@haskell.org> #15782: Visible type/kind applications in declaration of data/type constructors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12045 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > I'm making this ticket to keep track of this, I don't know if it's a good > idea. > > Allow visible type/kind applications when declaring data/type > constructors on the LHS of `::` (from > [https://phabricator.haskell.org/D5229#144558 Phab comment]). > > {{{#!hs > data > Proxy :: forall k. k -> Type where > MkProxy :: Proxy @k (a :: k) > > -- can be written > > data > Proxy @k :: k -> Type where > MkProxy @k :: Proxy @k (a :: k) > }}} > > & > > {{{#!hs > data > Fin :: N -> Type where > FinO :: Fin (S n) > FinS :: Fin n -> Fin (S n) > > -- can be written > > data > Fin :: N -> Type where > FinO @n :: Fin (S n) > FinS @n :: Fin n -> Fin (S n) > }}} New description: I'm making this ticket to keep track of this, I don't know if it's a good idea. Allow visible type/kind applications when declaring data/type constructors on the LHS of `::` (from [https://phabricator.haskell.org/D5229#144558 Phab comment]). {{{#!hs data Proxy @k :: k -> Type where MkProxy @k :: Proxy @k (a :: k) }}} & {{{#!hs data Fin :: N -> Type where FinO @n :: Fin (S n) FinS @n :: Fin n -> Fin (S n) }}} & {{{#!hs data Elem @k @n :: Vec n k -> Type where ElemO @a @as :: Elem @k @(S n) (a:>as) ElemS @a @as :: Elem @k @n as -> Elem @k @(S n) (a:>as) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 12:53:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 12:53:15 -0000 Subject: [GHC] #15781: Extraneous parentheses required to parse kind signature on the RHS of a type synonym In-Reply-To: <050.be8b8c1a94d013f8504422795938ca88@haskell.org> References: <050.be8b8c1a94d013f8504422795938ca88@haskell.org> Message-ID: <065.ca98cfc89aec48f3a9678be53b753954@haskell.org> #15781: Extraneous parentheses required to parse kind signature on the RHS of a type synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5245 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5245 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 14:01:49 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 14:01:49 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.b6b8fe9f5b7219de944d8738ef39de33@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201, Phab:D5226 -------------------------------------+------------------------------------- Comment (by osa1): Making progress. We want to handle dataToTag# and seq# uniformly, as they're two exceptional primops that evaluate their arguments. So I added this to `app_ok`: {{{ app_ok primop_ok fun args = case idDetails fun of ... | SeqOp <- op ------------------- OLD CODE -> all (expr_ok primop_ok) args | DataToTagOp <- op ------------- NEW CODE -> all (expr_ok primop_ok) args }}} However this causes let/app invariant errors. Here's an example: {{{ $cpred_a3m9 = \ (a_a2Ix :: VecElem) -> case dataToTag# @ VecElem a_a2Ix of a#_a2Iy { __DEFAULT -> case eqInt (GHC.Types.I# 0#) (GHC.Types.I# a#_a2Iy) of { False -> tagToEnum# @ VecElem (+# a#_a2Iy -1#); True -> error @ 'LiftedRep @ VecElem ($dIP_s4eG `cast` (Sym (GHC.Classes.N:IP[0] <"callStack">_N _N) :: GHC.Stack.Types.CallStack ~R# (?callStack::GHC.Stack.Types.CallStack))) (build @ Char (\ (@ b_a44N) -> unpackFoldrCString# @ b_a44N "pred{VecElem}: tried to take `pred' of first tag in enumeration"#)) } } }}} This is OK-for-spec, but FloatOut first transforms this into: {{{ $cpred_a3m9 :: VecElem -> VecElem [LclId, Arity=1] $cpred_a3m9 = \ (a_a2Ix :: VecElem) -> case dataToTag# @ VecElem a_a2Ix of a#_a2Iy { __DEFAULT -> case eqInt lvl_s4yV (I# a#_a2Iy) of { False -> tagToEnum# @ VecElem (+# a#_a2Iy -1#); True -> lvl_s4yY } }, }}} then simplifier: {{{ $cpred_a3m9 = \ (a_a2Ix :: VecElem) -> case a_a2Ix of lwild_s50A [Dmd=] { __DEFAULT -> tagToEnum# @ VecElem (+# (dataToTag# @ VecElem a_a2Ix) -1#); Int8ElemRep -> lvl_s4yY } }}} which is not OK-for-spec beucase `a_a2Ix` doesn't have evaldUnfolding. The error message: {{{ *** Core Lint errors : in result of Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) *** : warning: In the expression: +# (dataToTag# @ VecElem a_a2Ix) -1# This argument does not satisfy the let/app invariant: dataToTag# @ VecElem a_a2Ix }}} I don't understand why we substitute `dataToTag# @ VecElem a_a2Ix` for the case binder. Simon, any ideas? (Committed the code to wip/T15696, the error happens during validate) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 14:03:38 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 14:03:38 -0000 Subject: [GHC] #15777: Ordering of code in file affects compilation In-Reply-To: <046.415e5f15d1aaa2f7a3ae387df5079aa8@haskell.org> References: <046.415e5f15d1aaa2f7a3ae387df5079aa8@haskell.org> Message-ID: <061.11f622f0ea343f2219cc7a4f0fa31ac8@haskell.org> #15777: Ordering of code in file affects compilation -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12088 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chessai): Thanks for the quick response. Curious - why does that hack work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 14:16:04 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 14:16:04 -0000 Subject: [GHC] #15777: Ordering of code in file affects compilation In-Reply-To: <046.415e5f15d1aaa2f7a3ae387df5079aa8@haskell.org> References: <046.415e5f15d1aaa2f7a3ae387df5079aa8@haskell.org> Message-ID: <061.fb6d0a378a8f07c6438a093b0f86f147@haskell.org> #15777: Ordering of code in file affects compilation -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12088 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): When kind-checking, GHC performs strongly-connected component (SCC) analysis to determine which declarations depend on the presence of other declarations. In your example, the `type Unlifted Stuff = Stuff#` instance declaration depends on the `type instance Rep Stuff = TupleRep '[ 'IntRep, 'IntRep ]` instance declaration in order to kind-check, so a proper SCC analysis should put the former declaration //after// the latter one. Because of #12088, however, this does not happen correctly, and these declarations get processed out of dependency order. The use of a Template Haskell splice (such as `$(pure [])`) is a gruesome hack which forces the declarations following the splice to be processed //after// the declarations preceding the splice. This is often an annoying weakness of Template Haskell, but in this particular case, it happens to work to our advantage :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 14:18:05 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 14:18:05 -0000 Subject: [GHC] #15777: Ordering of code in file affects compilation In-Reply-To: <046.415e5f15d1aaa2f7a3ae387df5079aa8@haskell.org> References: <046.415e5f15d1aaa2f7a3ae387df5079aa8@haskell.org> Message-ID: <061.afc00b1918fc5f21349e5d1f337542cb@haskell.org> #15777: Ordering of code in file affects compilation -------------------------------------+------------------------------------- Reporter: chessai | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #12088 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chessai): Ah, ok. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 14:32:24 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 14:32:24 -0000 Subject: [GHC] #14251: LLVM Code Gen messes up registers In-Reply-To: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> References: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> Message-ID: <062.fc47e5315730c40ad5324ba955ef54b8@haskell.org> #14251: LLVM Code Gen messes up registers -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler (LLVM) | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5190 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: kavon => (none) * status: closed => new * resolution: fixed => Comment: Sadly no; we currently don't have CI for ARM (although I am currently speaking with people to fix this). Regardless, Kavon is aware of the issue and will hopefully pop up soon with a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 14:47:26 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 14:47:26 -0000 Subject: [GHC] #15783: Quoting an internal variable causes an error when splicing Message-ID: <049.e3b5744f03cf250cd18d056d6a8f061a@haskell.org> #15783: Quoting an internal variable causes an error when splicing -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE TemplateHaskell #-} module A where import B main = $$f }}} {{{ {-# LANGUAGE TemplateHaskell #-} module B(f) where d = 0 f = [|| d ||] }}} Note that `d` is not exported from `B`. {{{ [1 of 2] Compiling B ( B.hs, B.o ) [2 of 2] Compiling A ( A.hs, A.o ) A.hs:6:8: error: • Can't find interface-file declaration for variable B.d Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error • In the expression: B.d In the result of the splice: $f To see what the splice expanded to, use -ddump-splices In the Template Haskell splice $$f | 6 | main = $$f | ^^^ }}} This doesn't seem to happen for untyped quotes/splices. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 15:00:39 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 15:00:39 -0000 Subject: [GHC] #15783: Quoting an internal variable causes an error when splicing In-Reply-To: <049.e3b5744f03cf250cd18d056d6a8f061a@haskell.org> References: <049.e3b5744f03cf250cd18d056d6a8f061a@haskell.org> Message-ID: <064.823167d5f2daed1a1252c8f96beb0b0e@haskell.org> #15783: Quoting an internal variable causes an error when splicing -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: RyanGlScott (added) * component: Compiler => Template Haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 16:44:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 16:44:58 -0000 Subject: [GHC] #15783: Quoting an internal variable causes an error when splicing In-Reply-To: <049.e3b5744f03cf250cd18d056d6a8f061a@haskell.org> References: <049.e3b5744f03cf250cd18d056d6a8f061a@haskell.org> Message-ID: <064.e7dbee7f97435ddb08d52c04a870306b@haskell.org> #15783: Quoting an internal variable causes an error when splicing -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Curiously, this doesn't happen when loaded into GHCi, only when compiled with `--make`. Also, if you compile these files one at a time with `-c`, you get something... interesting: {{{ $ /opt/ghc/8.6.1/bin/ghc -c B.hs $ /opt/ghc/8.6.1/bin/ghc -c A.hs ghc: panic! (the 'impossible' happened) (GHC version 8.6.1 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc6527_0/libghc_1.so: undefined symbol: templatezmhaskell_LanguageziHaskellziTHziLib_varE_closure }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 16:49:08 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 16:49:08 -0000 Subject: [GHC] #15783: Quoting an internal variable causes an error when splicing In-Reply-To: <049.e3b5744f03cf250cd18d056d6a8f061a@haskell.org> References: <049.e3b5744f03cf250cd18d056d6a8f061a@haskell.org> Message-ID: <064.59940763f5054b0332289d4ecb93bd4a@haskell.org> #15783: Quoting an internal variable causes an error when splicing -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Another curious thing. If you compile `B.hs` with `-ddump-simpl`, you'll get this: {{{ $ /opt/ghc/8.6.1/bin/ghc B.hs -fforce-recomp -ddump-simpl [1 of 1] Compiling B ( B.hs, B.o ) ==================== Tidy Core ==================== Result size of Tidy Core = {terms: 24, types: 9, coercions: 0, joins: 0/0} -- RHS size: {terms: 9, types: 1, coercions: 0, joins: 0/0} f :: Language.Haskell.TH.Syntax.Q (Language.Haskell.TH.Syntax.TExp Integer) [GblId] f = Language.Haskell.TH.Syntax.unsafeTExpCoerce @ Integer (Language.Haskell.TH.Lib.Internal.varE (Language.Haskell.TH.Syntax.mkNameG_v (GHC.CString.unpackCString# "main"#) (GHC.CString.unpackCString# "B"#) (GHC.CString.unpackCString# "d"#))) }}} Now change the typed quote to an untyped one (i.e., change `f = [|| d ||]` to `f = [| d |]`) and recompile it: {{{ $ /opt/ghc/8.6.1/bin/ghc B.hs -fforce-recomp -ddump-simpl [1 of 1] Compiling B ( B.hs, B.o ) ==================== Tidy Core ==================== Result size of Tidy Core = {terms: 25, types: 7, coercions: 0, joins: 0/0} -- RHS size: {terms: 8, types: 0, coercions: 0, joins: 0/0} f :: Language.Haskell.TH.Lib.Internal.ExpQ [GblId] f = Language.Haskell.TH.Lib.Internal.varE (Language.Haskell.TH.Syntax.mkNameG_v (GHC.CString.unpackCString# "main"#) (GHC.CString.unpackCString# "B"#) (GHC.CString.unpackCString# "d"#)) -- RHS size: {terms: 1, types: 0, coercions: 0, joins: 0/0} d :: Integer [GblId, Caf=NoCafRefs, Unf=OtherCon []] d = 0 }}} Notice that `d` actually makes an appearance this time! This makes me wonder if `d` is being mistakenly removed under the pretense of it being dead code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 16:56:24 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 16:56:24 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.f2f05953776d53997d861821094392cb@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: patch 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): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): Nevermind, the regression was due to lifting binders occuring in a nullary applications. Example from `CS`: {{{ main_$s$wgo = \r [sc sc1] case sc1 of wild { __DEFAULT -> let { lvl = \u [] case -# [wild 1#] of sat { __DEFAULT -> main_$s$wgo sc sat; }; } in let { sat = \r [s1] case plusInteger s1 ds of s' { __DEFAULT -> lvl s'; }; } in sat; 0# -> sc (); }; ==> main_$s$wgo = \r [sc sc1] case sc1 of wild { __DEFAULT -> let { lvl = \u [] case -# [wild 1#] of sat { __DEFAULT -> main_$s$wgo sc sat; }; } in $lsat lvl; 0# -> sc (); }; $lsat = \r [lvl s1] case plusInteger s1 ds of s' { __DEFAULT -> lvl s'; }; }}} (`main_$s$wgo` is a ternary function) This is a beneficial lift from the perspective of closure growth, but actually allocates more because the nullary application `sat` turns into a partial application `$lsat lvl` which allocates. Fixing this by regarding nullary applications as argument occurrences of the binder (e.g. a no-go) has the same effect to nofib benchmarks as just disallowing ''any'' undersaturated calls to the binder to lift. The latter is much simpler to check for (just look at the `StgBinderInfo` of the RHS) and is the status quo in Phab:D5224. So, no news, basically. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 19 18:49:25 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Oct 2018 18:49:25 -0000 Subject: [GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code In-Reply-To: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> References: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> Message-ID: <065.bd4eefa81422ea013ba3ecc468ec6348@haskell.org> #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T14579 Blocked By: 12045 | Blocking: Related Tickets: | Differential Rev(s): Phab:D4264 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * cc: mynguyen (added) Comment: Cc'ing the implementor of visible kind application. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 20 04:18:44 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Oct 2018 04:18:44 -0000 Subject: [GHC] #14830: Use test instead of cmp for comparison against zero. In-Reply-To: <047.ca37bf7e6f971d0d97b5218e90d6b786@haskell.org> References: <047.ca37bf7e6f971d0d97b5218e90d6b786@haskell.org> Message-ID: <062.6d5c876b2888619129cad552f13197bb@haskell.org> #14830: Use test instead of cmp for comparison against zero. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler (NCG) | Version: Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by vanessamchale): `stmtToInstrs` calls `genCondJump` which as far as I can tell only uses `cmp` on registers, not immediate values. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 20 04:49:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Oct 2018 04:49:22 -0000 Subject: [GHC] #14830: Use test instead of cmp for comparison against zero. In-Reply-To: <047.ca37bf7e6f971d0d97b5218e90d6b786@haskell.org> References: <047.ca37bf7e6f971d0d97b5218e90d6b786@haskell.org> Message-ID: <062.17df9c95bf2e64ec51266590692ad7e6@haskell.org> #14830: Use test instead of cmp for comparison against zero. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: low | Milestone: Component: Compiler (NCG) | Version: Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanessamchale): * cc: vanessa.mchale@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 20 04:49:41 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Oct 2018 04:49:41 -0000 Subject: [GHC] #15258: Implement CMOV support. In-Reply-To: <047.e9fd16ce925ccd3a92fb9b02db12d4ac@haskell.org> References: <047.e9fd16ce925ccd3a92fb9b02db12d4ac@haskell.org> Message-ID: <062.defc5306e8ef0977383dbd2a63f374d7@haskell.org> #15258: Implement CMOV support. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: AndreasK Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanessamchale): * cc: vanessa.mchale@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 20 05:35:18 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Oct 2018 05:35:18 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.e1b22c343069fa7dbf7701d16dfb906b@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): I got it compiling and typechecking, then set about writing a test. Discussed with you (osa1) and a couple others in IRC about writing tests. Looked more into how the testing framework works, read up on writing tests. Pretty sure I can figure that out now (it's really not going to be hard, once I read all the test guides). So that's fine, but I had an issue compiling after doing a `git pull` (for some reason I had to recompile stage 1 of the compiler again), so I recompiled and thought I'd try out my changes. So I typechecked a large scientific notational literal, and it got `*** Exception: No match in record selector thfl_value` I realised immediately that was because I'd just made the types match in the desugarer and renamer by using the new TH part of the FractionalLit type because the desugarer talks bout pattern group matching on HsFractional and seemed to expect a Rational. So, the `PatGroup` data type, has a constructor `PgN :: Rational -> PatGroup` which I'm now going to refactor to be `PgN :: Integer -> Integer -> PatGroup`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 20 06:31:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Oct 2018 06:31:11 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.e1a648de32689cee414073e5df727702@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): :dance: Changed the types over properly, and now I got it compiling again and it now typechecks large exponent fractionals very quickly. :excited: I'll finish it up and get it on Phabricator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 20 08:59:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Oct 2018 08:59:17 -0000 Subject: [GHC] #15780: ghc-8.4.4 failed to build on armv7 and aarch64 In-Reply-To: <050.81668a88e354aac40559f0e53fb7e269@haskell.org> References: <050.81668a88e354aac40559f0e53fb7e269@haskell.org> Message-ID: <065.65622fc1498bc60d58edf523f230edec@haskell.org> #15780: ghc-8.4.4 failed to build on armv7 and aarch64 ----------------------------------------+------------------------------ Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.2 Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Changes (by juhpetersen): * priority: normal => high * milestone: => 8.6.2 Comment: Just for the record - only seems to affect ARM: https://koji.fedoraproject.org/koji/taskinfo?taskID=30340200 (ignore the arm failures there, because of missing llvm-5.0). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 20 09:36:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Oct 2018 09:36:56 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.3cd57609360a3afd8222218759fef71b@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Changes (by sgraf): * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 20 09:40:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Oct 2018 09:40:07 -0000 Subject: [GHC] #12119: Can't create injective type family equation with TypeError as the RHS In-Reply-To: <050.21d4af732cea81fafcb58c894bb8137c@haskell.org> References: <050.21d4af732cea81fafcb58c894bb8137c@haskell.org> Message-ID: <065.8ca11feca9d17b9f9a6877741bc1b0bf@haskell.org> #12119: Can't create injective type family equation with TypeError as the RHS -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: wontfix | CustomTypeErrors, TypeFamilies, | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sheaf): What about the following: {{{#!hs data Dim = D2 | D3 | D4 type family ToDim (n :: Nat) = d | d -> n where ToDim 2 = D2 ToDim 3 = D3 ToDim 4 = D4 ToDim n = TypeError ( Text "Error: dimension must be 2, 3 or 4 (given: " :<>: ShowType n :<>: Text ")" ) }}} This seems useful to me, as it allows one to switch easily between two different representations of dimension (which have different uses: with Nats I can do arithmetic, but the explicit enum is more convenient with singletons for instance). I feel like the injectivity annotation should be allowed in this case (but I am not aware of any of the theory which backs injective type families). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 20 10:45:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Oct 2018 10:45:35 -0000 Subject: [GHC] #12119: Can't create injective type family equation with TypeError as the RHS In-Reply-To: <050.21d4af732cea81fafcb58c894bb8137c@haskell.org> References: <050.21d4af732cea81fafcb58c894bb8137c@haskell.org> Message-ID: <065.4c1fc486f9339b6372ecfa08d39677ab@haskell.org> #12119: Can't create injective type family equation with TypeError as the RHS -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: wontfix | CustomTypeErrors, TypeFamilies, | InjectiveFamilies Operating System: 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 Oct 20 10:46:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Oct 2018 10:46:37 -0000 Subject: [GHC] #15784: :doc shouldn't report for a data constructor when it can show docs for the type constructor of the same name and type Message-ID: <046.71b4b165f0b3bcd2befe35d7035d18de@haskell.org> #15784: :doc shouldn't report for a data constructor when it can show docs for the type constructor of the same name and type -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.6.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ λ import Data.Monoid λ :doc Sum Monoid under addition. >>> getSum (Sum 1 <> Sum 2 <> mempty) 3 }}} I think it would be nicer if we could elide the `` message for the `Sum` data constructor here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 20 11:11:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Oct 2018 11:11:22 -0000 Subject: [GHC] #15785: Improve/complete the GHCi :doc command Message-ID: <046.a0ed2b72c637e61830d31abbd108bb52@haskell.org> #15785: Improve/complete the GHCi :doc command -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: GHCi | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `:doc` command, so far implemented as a ''tech preview'', could be a lot nicer: * For a type constructor, it should also show the data constructors and their documentation * It should include documentation on function arguments. * For records it should include any docs on the fields. Overall I think it should work roughly like the `:info` command, but of course enhanced by the docstrings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 20 11:28:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Oct 2018 11:28:55 -0000 Subject: [GHC] #15786: Hi Haddock: Enable haddock to generate docs from .hi-files Message-ID: <046.3eb0cf9aabf2ed86b7408b08e6e3c569@haskell.org> #15786: Hi Haddock: Enable haddock to generate docs from .hi-files -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D5067 | Wiki Page: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 20 14:58:33 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Oct 2018 14:58:33 -0000 Subject: [GHC] #15783: Quoting an internal variable causes an error when splicing In-Reply-To: <049.e3b5744f03cf250cd18d056d6a8f061a@haskell.org> References: <049.e3b5744f03cf250cd18d056d6a8f061a@haskell.org> Message-ID: <064.406adbba1399e3ff78cfb93067a75881@haskell.org> #15783: Quoting an internal variable causes an error when splicing -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5248 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5248 Comment: I figured out what's causing this. See Phab:D5248 for a fix. It turns out that occurrence analysis was dropping the binding for `d` during desugaring (this explains why this bug didn't surface in GHCi, as occurrence analysis does not run there). So why was occurrence analysis dropping bindings for top-level things referenced from typed TH quotes, but not from untyped TH quotes? It turns out that two functions called `checkCrossStageLifting` are to blame. ...No seriously, there are two completely separate functions named `checkCrossStageLifting` in GHC. One exists in `RnSplice`, and only handles untyped quotes, and the other exists in `TcExpr`, and only handles typed quotes. And wouldn't you know it, `RnSplice.checkCrossStageLifting` was doing something that `TcExpr.checkCrossStageLifting` wasn't doing. In particular, [http://git.haskell.org/ghc.git/blob/879db5595208fb665ff1a0a2b12b9921d3efae0e:/compiler/rename/RnSplice.hs#l800 these lines] of `RnSplice.checkCrossStageLifting` are crucial: {{{#!hs | isTopLevel top_lvl -- Top-level identifiers in this module, -- (which have External Names) -- are just like the imported case: -- no need for the 'lifting' treatment -- E.g. this is fine: -- f x = x -- g y = [| f 3 |] = when (isExternalName name) (keepAlive name) -- See Note [Keeping things alive for Template Haskell] }}} That call to `keepAlive` ensures that the binding for `f` (from the example in the comments) doesn't get discarded during occurrence analysis. `TcExpr.checkCrossStageLifting` wasn't doing anything like this, which explains why this bug exists. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 20 17:31:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Oct 2018 17:31:46 -0000 Subject: [GHC] #15782: Visible type/kind applications in declaration of data/type constructors In-Reply-To: <051.20d3160ec20ed7bdea0f42672fc7888b@haskell.org> References: <051.20d3160ec20ed7bdea0f42672fc7888b@haskell.org> Message-ID: <066.d826d95d89a6ce3191a20aef8c618c87@haskell.org> #15782: Visible type/kind applications in declaration of data/type constructors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12045 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Consider also, declarations of type classes and synonyms {{{#!hs class (f a, g a) => (&) @k f g a instance (f a, g a) => (&) @k f g a -- on the VKA branch, only this works }}} {{{#!hs type Cat ob = ob -> ob -> Type class Category (ob :: Type) where type Hom @ob :: Cat ob id :: Hom @ob a a (.) :: Hom @ob b c -> Hom @ob a b -> Hom @ob a c }}} Now for an extreme example, but what about this {{{#!hs class Category @ob where type Hom @ob :: Cat ob id :: Hom @ob a a }}} where the type of `id` is `id :: forall (a :: ob). Category @ob => Hom a a`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 20 17:50:03 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Oct 2018 17:50:03 -0000 Subject: [GHC] #12045: Visible kind application In-Reply-To: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> References: <051.f572b464c11770181720f8a1a7ec05a5@haskell.org> Message-ID: <066.a4ae705f67155e0c72d251ac997d87ec@haskell.org> #12045: Visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: mnguyen Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications TypeInType | GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 14579 Related Tickets: #15782 | Differential Rev(s): Phab:D5229 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * related: => #15782 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 20 18:09:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Oct 2018 18:09:28 -0000 Subject: [GHC] #15787: GHC panic using kind application Message-ID: <051.88158355ed422210999943d4c175f35d@haskell.org> #15787: GHC panic using kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Using GHC head at diff [https://phabricator.haskell.org/D5229 Visible kind application D5229] (#12045), bug goes away if you remove `@ob`. {{{#!hs {-# Language RankNTypes #-} {-# Language TypeApplications #-} {-# Language DataKinds #-} {-# Language PolyKinds #-} {-# Language GADTs #-} {-# Language TypeFamilies #-} import Data.Kind class Ríki (ob :: Type) where type Hom :: ob -> ob -> Type data Kl_kind :: forall ob . (ob -> ob) -> ob -> Type where Kl :: k -> Kl_kind @ob (m) k type family UnKl (kl :: Kl_kind m k) = (res :: k) where UnKl (Kl a) = a }}} {{{ $ ghci -ignore-dot-ghci 543_bug.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 543_bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181017 for x86_64-unknown-linux): ASSERT failed! Type-correct unfilled coercion hole {co_a1yH} Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:1805:99 in ghc:TcHsSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 20 18:27:24 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Oct 2018 18:27:24 -0000 Subject: [GHC] #15788: Core Lint error, from visible kind applications Message-ID: <051.9512af2451069a0fc0b33528cf855ee3@haskell.org> #15788: Core Lint error, from visible kind applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: #12045 | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language RankNTypes #-} {-# Language GADTs #-} {-# Language TypeApplications #-} {-# Language PolyKinds #-} {-# Options_GHC -dcore-lint #-} import Data.Kind data A :: forall k. Type where MkA :: A @k }}} this cute bug crashes under the [https://phabricator.haskell.org/D5229 visible kind application] diff, produces: {{{ $ ghci -ignore-dot-ghci 545_bug.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 545_bug.hs, interpreted ) *** Core Lint errors : in result of Tidy Core *** : warning: In the type ‘forall (k :: k_a1xN[sk:1]) k. A’ @ k_a1xN[sk:1] is out of scope *** Offending Program *** $WMkA [InlPrag=INLINE[2]] :: forall (k :: k_a1xN[sk:1]) k. A [GblId[DataConWrapper], Caf=NoCafRefs, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True) Tmpl= \ (@ (k_a1y5 :: k_a1xN[sk:1])) (@ k_X1xP) -> MkA @ k_X1xP @ k_a1y5}] $WMkA = \ (@ (k_a1y5 :: k_a1xN[sk:1])) (@ k_X1xP) -> MkA @ k_X1xP @ k_a1y5 $trModule1_r1zb :: Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule1_r1zb = "main"# $trModule2_r1zu :: TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule2_r1zu = TrNameS $trModule1_r1zb $trModule3_r1zv :: Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule3_r1zv = "Main"# $trModule4_r1zw :: TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule4_r1zw = TrNameS $trModule3_r1zv $trModule :: Module [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule = Module $trModule2_r1zu $trModule4_r1zw $krep_r1zx :: KindRep [GblId, Caf=NoCafRefs, Unf=OtherCon []] $krep_r1zx = KindRepVar 1# $krep1_r1zy :: KindRep [GblId, Caf=NoCafRefs, Unf=OtherCon []] $krep1_r1zy = KindRepVar 0# $tcA1_r1zz :: Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] $tcA1_r1zz = "A"# $tcA2_r1zA :: TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] $tcA2_r1zA = TrNameS $tcA1_r1zz $tcA :: TyCon [GblId, Unf=OtherCon []] $tcA = TyCon 16201120719427956884## 13080046616073797921## $trModule $tcA2_r1zA 2# krep$* $krep2_r1zB :: [KindRep] [GblId, Caf=NoCafRefs, Unf=OtherCon []] $krep2_r1zB = : @ KindRep $krep1_r1zy ([] @ KindRep) $krep3_r1zC :: [KindRep] [GblId, Caf=NoCafRefs, Unf=OtherCon []] $krep3_r1zC = : @ KindRep $krep_r1zx $krep2_r1zB $krep4_r1zD :: KindRep [GblId, Unf=OtherCon []] $krep4_r1zD = KindRepTyConApp $tcA $krep3_r1zC $tc'MkA1_r1zE :: Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] $tc'MkA1_r1zE = "'MkA"# $tc'MkA2_r1zF :: TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] $tc'MkA2_r1zF = TrNameS $tc'MkA1_r1zE $tc'MkA :: TyCon [GblId, Unf=OtherCon []] $tc'MkA = TyCon 1695572187443655535## 16213897990811765752## $trModule $tc'MkA2_r1zF 2# $krep4_r1zD *** End of Offense *** : error: Compilation had errors *** Exception: ExitFailure 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 20 18:38:42 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Oct 2018 18:38:42 -0000 Subject: [GHC] #15788: Core Lint error, from visible kind applications In-Reply-To: <051.9512af2451069a0fc0b33528cf855ee3@haskell.org> References: <051.9512af2451069a0fc0b33528cf855ee3@haskell.org> Message-ID: <066.80c2bb3971ca9f5bd863c88d93bc7d22@haskell.org> #15788: Core Lint error, from visible kind applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: #12045 Operating System: 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): Giving `k` a signature fixes is `data A :: forall (k :: Type). Type`. This also works fine: {{{#!hs data B :: forall k (a :: k). Type where MkB :: a -> B @Type @a data C :: forall }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 20 18:44:27 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Oct 2018 18:44:27 -0000 Subject: [GHC] #15788: Core Lint error, from visible kind applications In-Reply-To: <051.9512af2451069a0fc0b33528cf855ee3@haskell.org> References: <051.9512af2451069a0fc0b33528cf855ee3@haskell.org> Message-ID: <066.ab1a0aca37818fc91b26667a30ceb333@haskell.org> #15788: Core Lint error, from visible kind applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: #12045 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > {{{#!hs > {-# Language RankNTypes #-} > {-# Language GADTs #-} > {-# Language TypeApplications #-} > {-# Language PolyKinds #-} > > {-# Options_GHC -dcore-lint #-} > > import Data.Kind > > data A :: forall k. Type where > MkA :: A @k > }}} > > this cute bug crashes under the [https://phabricator.haskell.org/D5229 > visible kind application] diff, produces: > > {{{ > $ ghci -ignore-dot-ghci 545_bug.hs > GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( 545_bug.hs, interpreted ) > *** Core Lint errors : in result of Tidy Core *** > : warning: > In the type ‘forall (k :: k_a1xN[sk:1]) k. A’ > @ k_a1xN[sk:1] is out of scope > *** Offending Program *** > $WMkA [InlPrag=INLINE[2]] :: forall (k :: k_a1xN[sk:1]) k. A > [GblId[DataConWrapper], > Caf=NoCafRefs, > Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, > WorkFree=True, Expandable=True, > Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True) > Tmpl= \ (@ (k_a1y5 :: k_a1xN[sk:1])) (@ k_X1xP) -> > MkA @ k_X1xP @ k_a1y5}] > $WMkA > = \ (@ (k_a1y5 :: k_a1xN[sk:1])) (@ k_X1xP) -> > MkA @ k_X1xP @ k_a1y5 > > $trModule1_r1zb :: Addr# > [GblId, Caf=NoCafRefs, Unf=OtherCon []] > $trModule1_r1zb = "main"# > > $trModule2_r1zu :: TrName > [GblId, Caf=NoCafRefs, Unf=OtherCon []] > $trModule2_r1zu = TrNameS $trModule1_r1zb > > $trModule3_r1zv :: Addr# > [GblId, Caf=NoCafRefs, Unf=OtherCon []] > $trModule3_r1zv = "Main"# > > $trModule4_r1zw :: TrName > [GblId, Caf=NoCafRefs, Unf=OtherCon []] > $trModule4_r1zw = TrNameS $trModule3_r1zv > > $trModule :: Module > [GblId, Caf=NoCafRefs, Unf=OtherCon []] > $trModule = Module $trModule2_r1zu $trModule4_r1zw > > $krep_r1zx :: KindRep > [GblId, Caf=NoCafRefs, Unf=OtherCon []] > $krep_r1zx = KindRepVar 1# > > $krep1_r1zy :: KindRep > [GblId, Caf=NoCafRefs, Unf=OtherCon []] > $krep1_r1zy = KindRepVar 0# > > $tcA1_r1zz :: Addr# > [GblId, Caf=NoCafRefs, Unf=OtherCon []] > $tcA1_r1zz = "A"# > > $tcA2_r1zA :: TrName > [GblId, Caf=NoCafRefs, Unf=OtherCon []] > $tcA2_r1zA = TrNameS $tcA1_r1zz > > $tcA :: TyCon > [GblId, Unf=OtherCon []] > $tcA > = TyCon > 16201120719427956884## > 13080046616073797921## > $trModule > $tcA2_r1zA > 2# > krep$* > > $krep2_r1zB :: [KindRep] > [GblId, Caf=NoCafRefs, Unf=OtherCon []] > $krep2_r1zB = : @ KindRep $krep1_r1zy ([] @ KindRep) > > $krep3_r1zC :: [KindRep] > [GblId, Caf=NoCafRefs, Unf=OtherCon []] > $krep3_r1zC = : @ KindRep $krep_r1zx $krep2_r1zB > > $krep4_r1zD :: KindRep > [GblId, Unf=OtherCon []] > $krep4_r1zD = KindRepTyConApp $tcA $krep3_r1zC > > $tc'MkA1_r1zE :: Addr# > [GblId, Caf=NoCafRefs, Unf=OtherCon []] > $tc'MkA1_r1zE = "'MkA"# > > $tc'MkA2_r1zF :: TrName > [GblId, Caf=NoCafRefs, Unf=OtherCon []] > $tc'MkA2_r1zF = TrNameS $tc'MkA1_r1zE > > $tc'MkA :: TyCon > [GblId, Unf=OtherCon []] > $tc'MkA > = TyCon > 1695572187443655535## > 16213897990811765752## > $trModule > $tc'MkA2_r1zF > 2# > $krep4_r1zD > > *** End of Offense *** > > : error: > Compilation had errors > > *** Exception: ExitFailure 1 > }}} New description: {{{#!hs {-# Language RankNTypes #-} {-# Language GADTs #-} {-# Language TypeApplications #-} {-# Language PolyKinds #-} {-# Options_GHC -dcore-lint #-} import Data.Kind data A :: forall k. Type where MkA :: A @k }}} this cute bug crashes under the [https://phabricator.haskell.org/D5229 visible kind application] diff, produces: {{{ $ ghci -ignore-dot-ghci 545_bug.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 545_bug.hs, interpreted ) *** Core Lint errors : in result of Tidy Core *** : warning: In the type ‘forall (k :: k_a1xN[sk:1]) k. A’ @ k_a1xN[sk:1] is out of scope *** Offending Program *** $WMkA [InlPrag=INLINE[2]] :: forall (k :: k_a1xN[sk:1]) k. A [GblId[DataConWrapper], Caf=NoCafRefs, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True) Tmpl= \ (@ (k_a1y5 :: k_a1xN[sk:1])) (@ k_X1xP) -> MkA @ k_X1xP @ k_a1y5}] $WMkA = \ (@ (k_a1y5 :: k_a1xN[sk:1])) (@ k_X1xP) -> MkA @ k_X1xP @ k_a1y5 $trModule1_r1zb :: Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule1_r1zb = "main"# $trModule2_r1zu :: TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule2_r1zu = TrNameS $trModule1_r1zb $trModule3_r1zv :: Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule3_r1zv = "Main"# $trModule4_r1zw :: TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule4_r1zw = TrNameS $trModule3_r1zv $trModule :: Module [GblId, Caf=NoCafRefs, Unf=OtherCon []] $trModule = Module $trModule2_r1zu $trModule4_r1zw $krep_r1zx :: KindRep [GblId, Caf=NoCafRefs, Unf=OtherCon []] $krep_r1zx = KindRepVar 1# $krep1_r1zy :: KindRep [GblId, Caf=NoCafRefs, Unf=OtherCon []] $krep1_r1zy = KindRepVar 0# $tcA1_r1zz :: Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] $tcA1_r1zz = "A"# $tcA2_r1zA :: TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] $tcA2_r1zA = TrNameS $tcA1_r1zz $tcA :: TyCon [GblId, Unf=OtherCon []] $tcA = TyCon 16201120719427956884## 13080046616073797921## $trModule $tcA2_r1zA 2# krep$* $krep2_r1zB :: [KindRep] [GblId, Caf=NoCafRefs, Unf=OtherCon []] $krep2_r1zB = : @ KindRep $krep1_r1zy ([] @ KindRep) $krep3_r1zC :: [KindRep] [GblId, Caf=NoCafRefs, Unf=OtherCon []] $krep3_r1zC = : @ KindRep $krep_r1zx $krep2_r1zB $krep4_r1zD :: KindRep [GblId, Unf=OtherCon []] $krep4_r1zD = KindRepTyConApp $tcA $krep3_r1zC $tc'MkA1_r1zE :: Addr# [GblId, Caf=NoCafRefs, Unf=OtherCon []] $tc'MkA1_r1zE = "'MkA"# $tc'MkA2_r1zF :: TrName [GblId, Caf=NoCafRefs, Unf=OtherCon []] $tc'MkA2_r1zF = TrNameS $tc'MkA1_r1zE $tc'MkA :: TyCon [GblId, Unf=OtherCon []] $tc'MkA = TyCon 1695572187443655535## 16213897990811765752## $trModule $tc'MkA2_r1zF 2# $krep4_r1zD *** End of Offense *** : error: Compilation had errors *** Exception: ExitFailure 1 }}} Another example that fails {{{#!hs data Kl_kind :: forall (m :: k -> Type). Type where Kl :: k -> Kl_kind @(m :: k -> Type) }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 20 19:48:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Oct 2018 19:48:34 -0000 Subject: [GHC] #15789: GHC panic using visible kind applications and a higher-rank kind Message-ID: <051.0cec3213d5885cf112eba4e0f29633b7@haskell.org> #15789: GHC panic using visible kind applications and a higher-rank kind -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Using visible kind applications (#12045): {{{#!hs {-# Language LiberalTypeSynonyms #-} {-# Language PolyKinds #-} {-# Language RankNTypes #-} {-# Language DataKinds #-} import Data.Kind type Cat ob = ob -> ob -> Type data Zero :: forall (cat :: forall xx. xx -> Type) a. forall b. Cat (forall b. cat b u) }}} {{{ $ ghci -ignore-dot-ghci 546_bug.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 546_bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181017 for x86_64-unknown-linux): ASSERT failed! Type-correct unfilled coercion hole {co_a1yl} Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:1805:99 in ghc:TcHsSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 20 19:53:20 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Oct 2018 19:53:20 -0000 Subject: [GHC] #15789: GHC panic using visible kind applications and a higher-rank kind In-Reply-To: <051.0cec3213d5885cf112eba4e0f29633b7@haskell.org> References: <051.0cec3213d5885cf112eba4e0f29633b7@haskell.org> Message-ID: <066.f4c18f673c0316124376b721cb8df437@haskell.org> #15789: GHC panic using visible kind applications and a higher-rank kind -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): this also fails: {{{#!hs {-# Language LiberalTypeSynonyms #-} {-# Language PolyKinds #-} {-# Language RankNTypes #-} {-# Language DataKinds #-} import Data.Kind data Zero :: forall (f :: forall xx. (forall yy. yy -> Type) -> Type). f a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 20 20:33:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Oct 2018 20:33:07 -0000 Subject: [GHC] #15789: GHC panic using visible kind applications and a higher-rank kind In-Reply-To: <051.0cec3213d5885cf112eba4e0f29633b7@haskell.org> References: <051.0cec3213d5885cf112eba4e0f29633b7@haskell.org> Message-ID: <066.96e9ef30c39050e3010d931c22456965@haskell.org> #15789: GHC panic using visible kind applications and a higher-rank kind -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > Using visible kind applications (#12045): > > {{{#!hs > {-# Language LiberalTypeSynonyms #-} > {-# Language PolyKinds #-} > {-# Language RankNTypes #-} > {-# Language DataKinds #-} > > import Data.Kind > > type Cat ob = ob -> ob -> Type > > data Zero :: forall (cat :: forall xx. xx -> Type) a. forall b. Cat > (forall b. cat b u) > }}} > > {{{ > $ ghci -ignore-dot-ghci 546_bug.hs > GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( 546_bug.hs, interpreted ) > ghc-stage2: panic! (the 'impossible' happened) > (GHC version 8.7.20181017 for x86_64-unknown-linux): > ASSERT failed! > Type-correct unfilled coercion hole {co_a1yl} > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in > ghc:Outputable > pprPanic, called at compiler/utils/Outputable.hs:1219:5 in > ghc:Outputable > assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:1805:99 > in ghc:TcHsSyn > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > > > }}} New description: Using visible kind applications (#12045): {{{#!hs {-# Language LiberalTypeSynonyms #-} {-# Language PolyKinds #-} {-# Language RankNTypes #-} {-# Language DataKinds #-} import Data.Kind type Cat ob = ob -> ob -> Type data Zero :: forall (cat :: forall xx. xx -> Type) a. forall b. Cat (forall b. cat b u) }}} {{{ $ ghci -ignore-dot-ghci 546_bug.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 546_bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181017 for x86_64-unknown-linux): ASSERT failed! Type-correct unfilled coercion hole {co_a1yl} Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:1805:99 in ghc:TcHsSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 20 22:58:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Oct 2018 22:58:46 -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.8d2973aff118b8524d220f73d9d02f1d@haskell.org> #14037: Fix fusion for GHC's utility functions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: rockbmb 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 rockbmb): * differential: Phab:D5240 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 20 23:07:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Oct 2018 23:07:17 -0000 Subject: [GHC] #15778: GHC HEAD-only panic (zonkTcTyVarToTyVar) In-Reply-To: <050.3cd9086426b45d98a8ca89f3f02fc672@haskell.org> References: <050.3cd9086426b45d98a8ca89f3f02fc672@haskell.org> Message-ID: <065.094ec5c2e806e7ae00e280025cb6d856@haskell.org> #15778: GHC HEAD-only panic (zonkTcTyVarToTyVar) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => TypeInType Comment: Marginally simpler example: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeInType #-} module Bug where import Data.Kind data Flarble (a :: Type) where MkFlarble :: Flarble Bool data SFlarble (z :: Flarble a) where SMkFlarble :: SFlarble MkFlarble foo :: SFlarble z -> () foo s at SMkFlarble = case s of (_ :: SFlarble (MkFlarble :: Flarble probablyABadIdea)) -> () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 20 23:33:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Oct 2018 23:33:01 -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.84ec2c8bf75817deccfd069bcabe8f73@haskell.org> #14037: Fix fusion for GHC's utility functions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: rockbmb 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): Phab:5249 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rockbmb): * differential: => Phab:5249 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 21 00:41:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Oct 2018 00:41:54 -0000 Subject: [GHC] #15350: gcdExtInteger violates assertion In-Reply-To: <047.463f72a51535cf21b879b51cdb0841bf@haskell.org> References: <047.463f72a51535cf21b879b51cdb0841bf@haskell.org> Message-ID: <062.d13f42a56e1e697a88e3f2d974cd2a49@haskell.org> #15350: gcdExtInteger violates assertion -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.1 Component: Core Libraries | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5042 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Bodigrim): * owner: Bodigrim => (none) * status: closed => new * version: 8.4.3 => 8.6.1 * resolution: fixed => Old description: > {{{#!haskell > {-# LANGUAGE UnboxedTuples #-} > import GHC.Integer.GMP.Internals > > main = let (# _, s #) = gcdExtInteger 2 (2^65 + 1) in print s > }}} > > fails with > > {{{#!haskell > Assertion failed: (sn <= mp_size_abs(xn)), function integer_gmp_gcdext, > file libraries/integer-gmp/cbits/wrappers.c, line 316. > Abort trap: 6 > }}} > > It happens because `s = -2^64` and does not fit one-limbed `BigNat`. The > implementation of `gcdExtInteger x y` > (https://github.com/ghc/ghc/blob/master/libraries/integer- > gmp/src/GHC/Integer/Type.hs#L1392) allocates for `s` a buffer, equal to > size of `x` (one limb in our case), but according to GMP manual > (https://gmplib.org/manual/Number-Theoretic-Functions.html#index- > mpz_005fgcdext) it should be equal to size of `y` (two limbs in our > case). > > Hopefully, the diff is simple enough for a PR on GitHub > (https://github.com/ghc/ghc/pull/163). Otherwise I'll be happy to prepare > a patch for Phabricator. > > {{{#!diff > - s@(MBN# s#) <- newBigNat# (absI# xn#) > + s@(MBN# s#) <- newBigNat# (absI# yn#) > }}} New description: {{{#!haskell {-# LANGUAGE UnboxedTuples #-} import GHC.Integer.GMP.Internals main = let (# _, s #) = gcdExtInteger 2 (2^65 + 1) in print s }}} fails with {{{#!haskell Assertion failed: (sn <= mp_size_abs(xn)), function integer_gmp_gcdext, file libraries/integer-gmp/cbits/wrappers.c, line 316. Abort trap: 6 }}} It happens because `s = -2^64` and does not fit one-limbed `BigNat`. The implementation of `gcdExtInteger x y` (https://github.com/ghc/ghc/blob/master/libraries/integer- gmp/src/GHC/Integer/Type.hs#L1392) allocates for `s` a buffer, equal to size of `x` (one limb in our case), but according to GMP manual (https://gmplib.org/manual/Number-Theoretic-Functions.html#index- mpz_005fgcdext) it should be equal to size of `y` (two limbs in our case). Hopefully, the diff is simple enough for a PR on GitHub (https://github.com/ghc/ghc/pull/163). Otherwise I'll be happy to prepare a patch for Phabricator. {{{#!diff - s@(MBN# s#) <- newBigNat# (absI# xn#) + s@(MBN# s#) <- newBigNat# (absI# yn#) }}} --- Reopening, because {{{#!haskell {-# LANGUAGE UnboxedTuples #-} import GHC.Integer.GMP.Internals main = let (# _, s #) = gcdExtInteger (- (2^63 - 1) * 2^63) 0 in print s }}} fails in GHC 8.6.1 with {{{#!haskell Assertion failed: (0 <= gn && gn <= gn0), function integer_gmp_gcdext, file libraries/integer-gmp/cbits/wrappers.c, line 309. Abort trap: 6 }}} I have not yet understood what is going on. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 21 01:17:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Oct 2018 01:17:25 -0000 Subject: [GHC] #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code In-Reply-To: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> References: <050.a14779f75731c6fe141e22d22092cebf@haskell.org> Message-ID: <065.1d402c0de537a9f4d6656a71bd3b708e@haskell.org> #14579: GeneralizedNewtypeDeriving produces ambiguously-kinded code -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | deriving/should_compile/T14579 Blocked By: 12045 | Blocking: Related Tickets: | Differential Rev(s): Phab:D4264 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * cc: mynguyen (removed) * cc: mnguyen (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 21 01:18:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Oct 2018 01:18:36 -0000 Subject: [GHC] #15787: GHC panic using kind application In-Reply-To: <051.88158355ed422210999943d4c175f35d@haskell.org> References: <051.88158355ed422210999943d4c175f35d@haskell.org> Message-ID: <066.67c1ced2b0a95450e05145df5e6d2872@haskell.org> #15787: GHC panic using kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * cc: mnguyen (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 21 01:51:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Oct 2018 01:51:39 -0000 Subject: [GHC] #15790: String literals are not escaped in -ddump-splices Message-ID: <048.c922ce5adc54ae740dbf47d013e37ac3@haskell.org> #15790: String literals are not escaped in -ddump-splices -------------------------------------+------------------------------------- Reporter: michalrus | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- For example, with this code: `Main.hs`: {{{#!hs {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices -ddump-to-file #-} module Main where main :: IO () main = do putStrLn $( [| "\n\n\n" |] ) putStrLn $( [| "\"" |] ) }}} This is output: `Main.dump-splices`: {{{ Main.hs:8:15-28: Splicing expression [| "\n\n\n" |] ======> " " Main.hs:9:15-24: Splicing expression [| "\"" |] ======> """ }}} … which is not valid Haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 21 02:58:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Oct 2018 02:58:34 -0000 Subject: [GHC] #15769: GHC 8.6 for macOS depends on homebrew In-Reply-To: <052.67c63639682c97d8d4af8a3fcaeffa11@haskell.org> References: <052.67c63639682c97d8d4af8a3fcaeffa11@haskell.org> Message-ID: <067.5e8c2569d61bfb7db8c8fd37505459af@haskell.org> #15769: GHC 8.6 for macOS depends on homebrew -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by elaforge): I had this same problem. I do use homebrew, but hadn't installed with it `gmp`. So `brew install gmp` fixed it for me. If homebrew's gmp is an intentional dependency now it should probably be documented! Otherwise it would be nice to continue linking it statically, or whatever it was that older compiles did. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 21 03:44:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Oct 2018 03:44:10 -0000 Subject: [GHC] #14971: Use appropriatly sized comparison instruction for small values. In-Reply-To: <047.ebf633502b771144a04c11718d3a50dd@haskell.org> References: <047.ebf633502b771144a04c11718d3a50dd@haskell.org> Message-ID: <062.d1ed2aaa4919dc0f394c1a8727c336ad@haskell.org> #14971: Use appropriatly sized comparison instruction for small values. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: (CodeGen) | Resolution: | Keywords: CodeGen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by vanessamchale): * cc: vanessa.mchale@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 21 09:02:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Oct 2018 09:02:02 -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.6f341604d1e33b07ffde25f674f26654@haskell.org> #14037: Fix fusion for GHC's utility functions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: rockbmb 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): Phab:D5249 Wiki Page: | -------------------------------------+------------------------------------- Changes (by potato44): * differential: Phab:5249 => Phab:D5249 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 21 09:06:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Oct 2018 09:06:28 -0000 Subject: [GHC] #15754: Move free variable computation to after STG passes In-Reply-To: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> References: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> Message-ID: <061.8929e9727270969227206ab5bde29e27@haskell.org> #15754: Move free variable computation to after STG passes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): I was under the impression that because free vars are inherently part of the STG syntax (vs. some binder annotation like in Core), correct free variable information would be an invariant on STG terms. So the lambda lifting optimisation I implemented on STG (#9476) relies on correct free variable information being available (and makes sure to update it after the transformation). Instead of deferring computation of free variables, how about having other transformations maintain this particular invariant of STG syntax? Or introduce a `StgFV` pass that can be used by other passes if we really want to abandon that invariant, but then we could (should?) get rid of mention in syntax. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 21 09:10:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Oct 2018 09:10:40 -0000 Subject: [GHC] #15754: Move free variable computation to after STG passes In-Reply-To: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> References: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> Message-ID: <061.15d6bc66c4bf07d7847c4deedd792101@haskell.org> #15754: Move free variable computation to after STG passes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 21 09:18:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Oct 2018 09:18:32 -0000 Subject: [GHC] #9718: Avoid TidyPgm predicting what CorePrep will do In-Reply-To: <046.5eef205a104808a079ad54238c650906@haskell.org> References: <046.5eef205a104808a079ad54238c650906@haskell.org> Message-ID: <061.b458d60994565be056429a6d8f727ca3@haskell.org> #9718: Avoid TidyPgm predicting what CorePrep will do -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: CodeGen, CAFs Operating System: 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 Sun Oct 21 09:29:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Oct 2018 09:29:14 -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.e7d119a07767bc0a889a66e8d8ac753f@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: CodeGen 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 sgraf): * cc: sgraf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 21 10:40:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Oct 2018 10:40:09 -0000 Subject: [GHC] #13104: runRW# ruins join points In-Reply-To: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> References: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> Message-ID: <064.de2d29b4b98623080b52eae2e8fa279e@haskell.org> #13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: chessai Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.1 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: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) Comment: I very much agree with what nomeata (comment:10) and simonpj (comment:14) said. We should aim for `loop 0` to be eta-expanded by realising that `runRW#` only calls its argument once. I would begin by looking at how `runRW#` gets its demand signature. It's not listed in primops.txt.pp, so it doesn't seem to be hard-coded into the compiler. It gets 'inlined' in CorePrep and in `cpe_app` there's a test for `runRWKey`. The problem, I guess, is that `runRW#` isn't a recognized primop. On the other hand, it doesn't seem to be a regular identifier, either: If the demand analyser were to look into its definition, it would be given a demand signature of ``, e.g. a signature saying that it calls its argument exactly once with one argument. We want the one-shot (i.e. usage demand) part, but apparently (see Note [runRW magic] in CorePrep) not the strictness part. So, I'd say `runRW#` should be handled as a regular primop like i.e. `catch#` and give it a `lazyApply1Dmd`. If this doesn't help, we could always fall back to more special cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 21 11:28:44 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Oct 2018 11:28:44 -0000 Subject: [GHC] #15790: String literals are not escaped in -ddump-splices In-Reply-To: <048.c922ce5adc54ae740dbf47d013e37ac3@haskell.org> References: <048.c922ce5adc54ae740dbf47d013e37ac3@haskell.org> Message-ID: <063.280cff9ff9057d33c363c464fb7f576f@haskell.org> #15790: String literals are not escaped in -ddump-splices -------------------------------------+------------------------------------- Reporter: michalrus | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by michalrus): So, intuitively, this seems like a low hanging fruit. It’s Sunday, so I’d maybe want to try to submit a patch. I’ll report a possible failure. !^.!^ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 21 13:27:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Oct 2018 13:27:28 -0000 Subject: [GHC] #15790: String literals are not escaped in -ddump-splices In-Reply-To: <048.c922ce5adc54ae740dbf47d013e37ac3@haskell.org> References: <048.c922ce5adc54ae740dbf47d013e37ac3@haskell.org> Message-ID: <063.e6aadbaaf0bc0282ad346bd2673c1f0d@haskell.org> #15790: String literals are not escaped in -ddump-splices -------------------------------------+------------------------------------- Reporter: michalrus | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4436 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #4436 Comment: Hah. It actually used to be the case that `\n` characters //were// escaped in `-ddump-splices`. However, someone specifically requested to change that to the current behavior (printing `\n` as newlines) in #4436. I'm not sure which behavior is better, given that separate groups of people want different things here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 21 13:48:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Oct 2018 13:48:29 -0000 Subject: [GHC] #11719: Cannot use higher-rank kinds with type families In-Reply-To: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> References: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> Message-ID: <062.f13762be3b5c7648f0d9195b467e121b@haskell.org> #11719: Cannot use higher-rank kinds with type families -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | dependent/should_compile/T11719 Blocked By: | Blocking: Related Tickets: #13913 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Something to consider (I don't know if I got the typing right, but allowing higher rank kinds in splitting type application) {{{#!hs type RudeWord a = forall xx. xx -> a type family Split (a :: res) :: forall arg. Maybe (RudeWord res, arg) where Split ((f :: RudeWord res) (a :: k)) = 'Just '(f, a) Split _ = 'Nothing }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 21 13:58:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Oct 2018 13:58:13 -0000 Subject: [GHC] #15790: String literals are not escaped in -ddump-splices In-Reply-To: <048.c922ce5adc54ae740dbf47d013e37ac3@haskell.org> References: <048.c922ce5adc54ae740dbf47d013e37ac3@haskell.org> Message-ID: <063.836fcd0e32a5f310e8a496abe11c8faa@haskell.org> #15790: String literals are not escaped in -ddump-splices -------------------------------------+------------------------------------- Reporter: michalrus | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #4436 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by michalrus): I see. =) But isn’t output of `-ddump-splices` supposed to be valid Haskell? If it was, then that would settle it. The manual says: > `-ddump-splices` > > Dump Template Haskell expressions that we splice in, and **what Haskell code** the expression evaluates to. > > — https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/debugging.html #ghc-flag--ddump-splices At the same time, I can see the reasoning behind breaking such strings in #4436. After all, it’s a debugging flag, with output meant for human consumption. I’d like to propose, then, in line with #13190’s ideas, a patch, which causes `-ddump-splices` output to be JSON if the `-ddump-json` flag is present, and in which JSON the string literals would be escaped properly, as they would be in valid Haskell code? This way we get a clear distinction between human– and machine-targeted output. Would that be accepted? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 21 19:57:41 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Oct 2018 19:57:41 -0000 Subject: [GHC] #14909: Change default armhf target to a newer architecture In-Reply-To: <044.27d87d6827047d9a351acb29d7974fea@haskell.org> References: <044.27d87d6827047d9a351acb29d7974fea@haskell.org> Message-ID: <059.a1e7013d30b7c450cba9b822e73e552a@haskell.org> #14909: Change default armhf target to a newer architecture ---------------------------------------+------------------------------ Reporter: Phyx- | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (CodeGen) | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------------+------------------------------ Changes (by vanessamchale): * cc: vanessa.mchale@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 21 19:57:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Oct 2018 19:57:54 -0000 Subject: [GHC] #15780: ghc-8.4.4 failed to build on armv7 and aarch64 In-Reply-To: <050.81668a88e354aac40559f0e53fb7e269@haskell.org> References: <050.81668a88e354aac40559f0e53fb7e269@haskell.org> Message-ID: <065.815ae64c9463e04ae009e6d57c94e8d4@haskell.org> #15780: ghc-8.4.4 failed to build on armv7 and aarch64 ----------------------------------------+------------------------------ Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.2 Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Changes (by vanessamchale): * cc: vanessa.mchale@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 21 19:59:26 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Oct 2018 19:59:26 -0000 Subject: [GHC] #14909: Change default armhf target to a newer architecture In-Reply-To: <044.27d87d6827047d9a351acb29d7974fea@haskell.org> References: <044.27d87d6827047d9a351acb29d7974fea@haskell.org> Message-ID: <059.20d31cc863d7fc62882858337611f595@haskell.org> #14909: Change default armhf target to a newer architecture ---------------------------------------+------------------------------ Reporter: Phyx- | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (CodeGen) | Version: 8.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------------+------------------------------ Comment (by vanessamchale): I think some old Raspberry Pis use ARMv7, no? I could see some value in targeting ARMv7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 21 21:07:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Oct 2018 21:07:43 -0000 Subject: [GHC] #10453: \case should trigger auto-multiline mode in ghci In-Reply-To: <044.2d59789cf30828fd243fec4509fe4124@haskell.org> References: <044.2d59789cf30828fd243fec4509fe4124@haskell.org> Message-ID: <059.b2472712be59498fbff38ce10227ea41@haskell.org> #10453: \case should trigger auto-multiline mode in ghci -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5236 Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 21 21:29:51 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Oct 2018 21:29:51 -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.fcebbe436b72f971abb17c9cd0670450@haskell.org> #14037: Fix fusion for GHC's utility functions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: rockbmb 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): Phab:D5249 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rockbmb): Replying to [comment:11 potato44]: Thanks, I didn't notice that mistake. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 21 22:12:35 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Oct 2018 22:12:35 -0000 Subject: [GHC] #15782: Visible type/kind applications in declaration of data/type constructors In-Reply-To: <051.20d3160ec20ed7bdea0f42672fc7888b@haskell.org> References: <051.20d3160ec20ed7bdea0f42672fc7888b@haskell.org> Message-ID: <066.324e1707db17ea3d91381e4a4e27e633@haskell.org> #15782: Visible type/kind applications in declaration of data/type constructors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12045 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I generally support this. But this has to go via a proposal, not just a ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 21 23:29:38 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Oct 2018 23:29:38 -0000 Subject: [GHC] #12119: Can't create injective type family equation with TypeError as the RHS In-Reply-To: <050.21d4af732cea81fafcb58c894bb8137c@haskell.org> References: <050.21d4af732cea81fafcb58c894bb8137c@haskell.org> Message-ID: <065.45af193d38cf1e28ed7c9c8d35015ea0@haskell.org> #12119: Can't create injective type family equation with TypeError as the RHS -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: wontfix | CustomTypeErrors, TypeFamilies, | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:6 sheaf]: > What about the following: ... > > This seems useful to me, ... Sure, it's the same structure as the O.P. > > I feel like the injectivity annotation should be allowed in this case ... It is. Ryan's comment:5 says what's not allowed is the `TypeError` catch- all equation -- that is, if you want `ToDim` to be injective. So if you call `ToDim 5`, inference will get stuck, and you'll get an error message somewhere/somehow else. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 22 06:12:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Oct 2018 06:12:52 -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.24102d943cf93c755f8d22c6fee1a334@haskell.org> #14037: Fix fusion for GHC's utility functions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: rockbmb Type: bug | Status: patch 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): Phab:D5249 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 22 06:38:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Oct 2018 06:38:31 -0000 Subject: [GHC] #15754: Move free variable computation to after STG passes In-Reply-To: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> References: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> Message-ID: <061.b86bdd6b7065ab39d9751d6557ffa6c4@haskell.org> #15754: Move free variable computation to after STG passes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * related: => #9718 Comment: So, for #9718 I'm working on a large Stg refactoring that fixes this ticket too. I'll add the detailed refactoring plan in #9718. Basically the proposal is we do analyses as late as possible, and for free variables we do the analysis right before code generation. But if late lambda lifting uses this information then that's not going to work, we need to do it earlier, and then make sure (perhaps only in debug builds or with a flag) that late lambda lift correctly updates free variables of closures. Because lll (late lambda lift) will be the first pass that'll need the free variables I think we should compute it right before the pass. That means (depending on when we're running lll) some passes may not have the information. In that case perhaps it's better to remove the fvs list from the syntax, and pass it around in an environment. Alternatively we could keep it in the syntax, do the computation in CoreToStg, and run a sanity check after each pass to make sure the information remains correct. However this means that a pass that doesn't need the information, but incidentally updates it (we currently don't have such a pass) will have to deal with the fvs field. Not sure if this is a huge concern right now.. Any thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 22 09:32:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Oct 2018 09:32:25 -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.786db7fe8eb07fc4b008a20fb36e454f@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: Linux | Architecture: Other Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by juhpetersen): (Maybe I should have opened a new ticket since it seems a different issue.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 22 10:21:47 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Oct 2018 10:21:47 -0000 Subject: [GHC] #15754: Move free variable computation to after STG passes In-Reply-To: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> References: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> Message-ID: <061.429ece4d3c12ea0f430e921cc2b99754@haskell.org> #15754: Move free variable computation to after STG passes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Free-var info is inherently fragile, and is easily regenerated. It's a bit like `OccInfo` on a binder in `Core`. Best, I think, to generate it where needed, and explicitly nuke it in any pass that can't easily guarantee to preserve it. I suppose we could have a type index to specify whether or not the FV info was in there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 22 10:31:34 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Oct 2018 10:31:34 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.9bfaa65079d548bd977c7c1b4b11995e@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Okay... I think I've put all the pieces into place now. I'm a little confused as to why, but `dsLit` seems to still be taking a while to desugar with the `fromRational (readRational txt)` pattern in place. I'm not 100% sure I've done what was intended... {{{ HsRat _ fl ty -> do let txt = case fl of THFL { thfl_text = SourceText t } -> t FL { fl_text = SourceText t } -> t val = fromRational (readRational txt) num <- mkIntegerExpr (numerator val) denom <- mkIntegerExpr (denominator val) return (mkCoreConApps ratio_data_con [Type integer_ty, num, denom]) }}} However if I do `./inplace/bin/ghc-stage2 --interactive` then `:t 1e10000000` and it takes over 3 seconds still. (One less digit takes under 1 second) so the bug is still there — it's now taking *less* time to typecheck, but the desugarer seems to still be catching me out. I'll attach a patch file so you can see what I've done to now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 22 10:33:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Oct 2018 10:33:15 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.87894b0be137f10d4f88d32b5932ae59@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by JulianLeviston): * Attachment "ghc_changes.patch" added. PatchFile for 22 Oct 2018 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 22 10:49:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Oct 2018 10:49:45 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.90fc8c4b025ea5f1ce35dcb7b15c2580@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: bgamari, osa1 Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #15630 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): I did try (1), but failed. A naive attempt at "simply" stopping the recursion leads to core lint errors, causing uniques to escape their scope. AFAICT this has to do with how the specialiser mixes the "gather usages", "generate uniques" and "specialise" concerns. Unfortunately, the particular code that does this (`scExpr`) doesn't come with sufficient documentation, and I can't seem to figure out how to do it properly - it's not even clear to me what "do nothing" should look like in the context of `scExpr` - `return (nullUsage, e)`, as I originally expected, is certainly not it. Also, it looks like there is a recursion counter of sorts, `sc_count`, in place already (or rather, a counter that calculates the number of specialisations), but it doesn't seem to be effective in this particular case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 22 11:06:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Oct 2018 11:06:17 -0000 Subject: [GHC] #15700: Plugins cause GHC to panic: cannot find dynamic libraries In-Reply-To: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> References: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> Message-ID: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> #15700: Plugins cause GHC to panic: cannot find dynamic libraries -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15492 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sheaf): * Attachment "DsUsage.hs" removed. thrown-together fix for plugin change check crash on windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 22 11:06:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Oct 2018 11:06:17 -0000 Subject: [GHC] #15700: Plugins cause GHC to panic: cannot find dynamic libraries In-Reply-To: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> References: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> Message-ID: <059.7892666b194b5b6c0f0654013d458f20@haskell.org> #15700: Plugins cause GHC to panic: cannot find dynamic libraries -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15492 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sheaf): * Attachment "DsUsage.hs" added. Fix for plugin change check crash on Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 22 11:12:31 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Oct 2018 11:12:31 -0000 Subject: [GHC] #15700: Plugins cause GHC to panic: cannot find dynamic libraries In-Reply-To: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> References: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> Message-ID: <059.cb201740333233558eeabcfe52b83d38@haskell.org> #15700: Plugins cause GHC to panic: cannot find dynamic libraries -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15492 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sheaf): I've updated `DSUsage.hs` and checked that it works as intended on my Windows machine (both normal and profiling builds). As the fix simply adds another option (searching for static `.a` files), all programs that already compiled should still compile (including on other platforms, which I haven't tested). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 22 11:15:14 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Oct 2018 11:15:14 -0000 Subject: [GHC] #15700: Plugins cause GHC to panic: cannot find dynamic libraries In-Reply-To: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> References: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> Message-ID: <059.670d415cf33881620d06eb532a717573@haskell.org> #15700: Plugins cause GHC to panic: cannot find dynamic libraries -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15492 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sheaf): * status: infoneeded => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 22 13:25:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Oct 2018 13:25: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.7cf0fdbd384a76d738ad64e17ce2b53f@haskell.org> #15560: Full laziness destroys opportunities for join points -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: chessai Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14287 #13286 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): @chessai Are you still interested in this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 22 13:31:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Oct 2018 13:31:26 -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.ed3708b650343ab926383dfb1c2f6056@haskell.org> #15560: Full laziness destroys opportunities for join points -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: chessai Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 (CodeGen) | Resolution: | Keywords: JoinPoints Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14287 #13286 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by chessai): Replying to [comment:19 AndreasK]: > @chessai Are you still interested in this? Yes - I am working on https://ghc.haskell.org/trac/ghc/ticket/13104 as a sort of preparation, it's a simpler issue related to join points, in that it's less time consuming and has a straightforward solution, as far as i can tell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 22 15:47:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Oct 2018 15:47:04 -0000 Subject: [GHC] #15754: Move free variable computation to after STG passes In-Reply-To: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> References: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> Message-ID: <061.a1699abcc39f02af36a7d0449a8c2822@haskell.org> #15754: Move free variable computation to after STG passes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): LLL will run as late as possible, ideally immediately before going to Cmm. It's pretty easy for LLL to maintain FV information accurately, I'd say, so generating it once (or as needed) would still be feasible. I'm still not sure if it's a good idea to store free variable information ''directly in STG syntax'' if we only guarantee the implied invariants immediately after StgFV is run. Sort of the same problem which is solved by Trees to grow in the frontend. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 22 15:58:14 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Oct 2018 15:58:14 -0000 Subject: [GHC] #15770: Missing optimisation opportunity in code gen for always-saturated applications? In-Reply-To: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> References: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> Message-ID: <058.2b702a85b9b76da0d898cbf7335deeac@haskell.org> #15770: Missing optimisation opportunity in code gen for always-saturated applications? -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5232 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): I'm conveniently using `satCallsOnly` when performing [https://github.com/sgraf812/ghc/blob/7839fe7fdb1a0b89d1edbff56f7ab6cee6293b0b/compiler/simplStg/StgLiftLams/Analysis.hs#L296 late lambda lifting]. It would not be terribly upsetting to see this go, but I found it convenient not having to compute the same analysis info myself. The same arguments as for free variables apply, though: It's occurrence information which is probably fragile enough to just be generated on demand. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 22 16:01:52 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Oct 2018 16:01:52 -0000 Subject: [GHC] #15770: Missing optimisation opportunity in code gen for always-saturated applications? In-Reply-To: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> References: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> Message-ID: <058.599be6950be784eccab29e9432104512@haskell.org> #15770: Missing optimisation opportunity in code gen for always-saturated applications? -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5232 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sgraf): * cc: sgraf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 22 17:19:19 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Oct 2018 17:19:19 -0000 Subject: [GHC] #15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable In-Reply-To: <043.18564262c59dae41f0454bb2c0047a1d@haskell.org> References: <043.18564262c59dae41f0454bb2c0047a1d@haskell.org> Message-ID: <058.8a9bfb17eb95c9c3cea4e81dd6296899@haskell.org> #15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5238 Wiki Page: | -------------------------------------+------------------------------------- Comment (by klebinger.andreas@…>): In [changeset:"fce07c99fa6528e95892604edb73fb975d6a01fc/ghc" fce07c99/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fce07c99fa6528e95892604edb73fb975d6a01fc" Update hsc2hs submodule to work around bug in response file handling. Summary: This works around #15758 by bumping hsc2hs. The new version includes support for response files independent of the boot compiler. Test Plan: ci, building formerly broken packages Reviewers: bgamari, RyanGlScott, ckoparkar Reviewed By: ckoparkar Subscribers: rwbarton, carter GHC Trac Issues: #15758 Differential Revision: https://phabricator.haskell.org/D5250 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 22 19:04:17 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Oct 2018 19:04:17 -0000 Subject: [GHC] #15791: typeKind confuses Type and Constraint Message-ID: <047.14fa0e2dfd42db4b54f79032d932ab60@haskell.org> #15791: typeKind confuses Type and Constraint -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `typeKind` function takes a type and reports its kind. It gets this wrong, sometimes: if you ask for `typeKind` of the quantified constraint `Eq a => C a` (where `C` is a class), you get `Type`. This is wrong, though I don't have a concrete case where GHC misfires. We ''could'' fix `typeKind` to get this right, but doing so would require making the `FunTy` case recursive (right now, it always returns `Type`). This is wasteful, because most clients of `typeKind` do not care about the distinction between `Type` and `Constraint`. Instead, I propose making a new `tcTypeKind` which behaves correctly in this case. We could also muse about making `tcTypeKind` monadic so that it can look through unification variables. This might also simplify the story around `Note [The tcType invariant]`. Regardless of the "make monadic" idea, I claim that, when this is done, we should have `isPredTy` be functionally equivalent to `(== Constraint) . tcTypeKind`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 22 19:47:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Oct 2018 19:47:54 -0000 Subject: [GHC] #15792: TH reification prints invisible arguments to rank-2-kinded type as visible Message-ID: <050.e2a4d6e1194c7cbbd578f8d344e1ef48@haskell.org> #15792: TH reification prints invisible arguments to rank-2-kinded type as visible -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template | Version: 8.6.1 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 run the following program: {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TemplateHaskell #-} module Bug where import Data.Kind import Language.Haskell.TH hiding (Type) newtype T (f :: forall a. a -> Type) = MkT (f Bool) $(pure []) main :: IO () main = do putStrLn $(reify ''T >>= stringE . pprint) putStrLn $(reify ''T >>= stringE . show) }}} You'll get: {{{ $ /opt/ghc/8.6.1/bin/runghc Bug.hs newtype Bug.T (f_0 :: forall (a_1 :: *) . a_1 -> *) = Bug.MkT (f_0 * GHC.Types.Bool) TyConI (NewtypeD [] Bug.T [KindedTV f_6989586621679016168 (ForallT [KindedTV a_6989586621679016167 StarT] [] (AppT (AppT ArrowT (VarT a_6989586621679016167)) StarT))] Nothing (NormalC Bug.MkT [(Bang NoSourceUnpackedness NoSourceStrictness,AppT (AppT (VarT f_6989586621679016168) StarT) (ConT GHC.Types.Bool))]) []) }}} These are the parts that are suspect: * `f_0 * GHC.Types.Bool` * `AppT (AppT (VarT f_6989586621679016168) StarT) (ConT GHC.Types.Bool)` Notice how `f`/`VarT f` accepts `*`/`StarT` as a visible argument, despite the fact that its kind `forall a. a -> Type` indicates that this should be invisible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 22 22:09:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Oct 2018 22:09:38 -0000 Subject: [GHC] #15792: TH reification prints invisible arguments to rank-2-kinded type as visible In-Reply-To: <050.e2a4d6e1194c7cbbd578f8d344e1ef48@haskell.org> References: <050.e2a4d6e1194c7cbbd578f8d344e1ef48@haskell.org> Message-ID: <065.195a08178729b0be5c69c5d3b83f9e2a@haskell.org> #15792: TH reification prints invisible arguments to rank-2-kinded type as visible -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5252 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5252 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 22 22:18:40 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Oct 2018 22:18:40 -0000 Subject: [GHC] #15770: Missing optimisation opportunity in code gen for always-saturated applications? In-Reply-To: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> References: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> Message-ID: <058.eff7866e063ae1e2b8e107d498ce6b43@haskell.org> #15770: Missing optimisation opportunity in code gen for always-saturated applications? -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5232 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > The same arguments as for free variables apply, though: It's occurrence information which is probably fragile enough to just be generated on demand. I think so too. That is, let's not generate it at the beginning. If LLF wants it, it's probably best just to calculate it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 22 22:24:20 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Oct 2018 22:24:20 -0000 Subject: [GHC] #15754: Move free variable computation to after STG passes In-Reply-To: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> References: <046.252c429fa44c8bd4c34c75cb2bce70c6@haskell.org> Message-ID: <061.4b64489bd56f44aa860282532b878cfd@haskell.org> #15754: Move free variable computation to after STG passes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9718 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > That's probably what Simon alludes to in comment:6 by suggesting a type index to solve this. Yes. Even without the full glory of TTG we could have something like this: {{{ data GenStgRhs pass = StgRhsClosure CostCentreStack -- CCS to be attached (default is CurrentCCS) StgBinderInfo -- Info about how this binder is used (see below) (XRhsClosure pass) -- non-global free vars; a list, rather than -- a set, because order is important !UpdateFlag -- ReEntrant | Updatable | SingleEntry [StgBndr pass] -- arguments; if empty, then not a function; -- as above, order is important. (GenStgExpr pass) -- body type instance XRhsClosure pass where XRhsCLosure JustBeforeCodeGen = [Id] XRhsClosure _ = () }}} Now `GenStgRhs JustBeforeCodeGen` has free-var info, but `GenStgRhs OtherPass` does not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 23 01:26:49 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Oct 2018 01:26:49 -0000 Subject: [GHC] #3372: Allow for multiple linker instances In-Reply-To: <049.b54da97038a1da97405ea7b63a99f067@haskell.org> References: <049.b54da97038a1da97405ea7b63a99f067@haskell.org> Message-ID: <064.504c8b18a9a951e7fbe2985f6fa670a7@haskell.org> #3372: Allow for multiple linker instances -------------------------------------+------------------------------------- Reporter: jcpetruzza | Owner: (none) Type: feature request | Status: new Priority: low | Milestone: Component: Runtime System | Version: (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 3658 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Update issue link: https://github.com/haskell-hint/hint/issues/68 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 23 03:13:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Oct 2018 03:13:33 -0000 Subject: [GHC] #15793: Type family doesn't reduce with visible kind application Message-ID: <051.61f364214000f10c10115e9460ffba57@haskell.org> #15793: Type family doesn't reduce with visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If we un-comment `f2` {{{#!hs {-# Language RankNTypes #-} {-# Language TypeFamilies #-} {-# Language TypeApplications #-} {-# Language PolyKinds #-} import Data.Kind type family F1 (a :: Type) :: Type where F1 a = Maybe a f1 :: F1 a f1 = Nothing type family F2 :: forall (a :: Type). Type where F2 @a = Maybe a -- f2 :: F2 @a -- f2 = Nothing }}} this program fails with {{{ • Couldn't match kind ‘forall a1. *’ with ‘* -> *’ When matching types F2 :: forall a. * Maybe :: * -> * Expected type: F2 Actual type: Maybe a • In the expression: Nothing In an equation for ‘f2’: f2 = Nothing | 20 | f2 = Nothing | ^^^^^^^ Failed, no modules loaded. }}} It also succeeds replacing `Nothing` with `undefined` {{{#!hs f2 :: F2 @a f2 = undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 23 08:07:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Oct 2018 08:07:07 -0000 Subject: [GHC] #15700: Plugins cause GHC to panic: cannot find dynamic libraries In-Reply-To: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> References: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> Message-ID: <059.978affed4e18a8e715adaa4769403291@haskell.org> #15700: Plugins cause GHC to panic: cannot find dynamic libraries -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15492 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): @sheaf, can you a diff instead of an updated file? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 23 08:59:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Oct 2018 08:59:58 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.b01f5d7da37d3e0e59d0021b1f76cc7c@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): Could you submit your patch to Phabricator? It's really hard to review it this way. I haven't looked at the patch in details yet, but the desugaring in comment:41 is not right. We want to avoid building a rational in compile time (the `Integer` components of `Rational` is what's taking all the time), but that's what you're doing in the code in comment:41 (in `readRational`). See comment:24 for how we want to desugar this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 23 12:08:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Oct 2018 12:08:19 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.72ad7cb3437d7ceb9c9665937eaaffd8@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Yeah, ok, sorry I was reading https://ghc.haskell.org/trac/ghc/ticket/15646#comment:16 by mistake... I also thought desugaring wasn't part of type-checking. In the diagram it happens after type checking. For some reason I'd assumed once it'd type checked the expression it would stop. Ok I can easily refactor that. Yeah I didn't submit to Phabricator yet because I knew it was obviously wrong. Thanks for correcting me. I'll give it another shot. Again, thanks for all the help, I really really appreciate it, and hope to repay by hopefully being able to fix bugs more easily with the next ones. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 23 13:18:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Oct 2018 13:18:09 -0000 Subject: [GHC] #15700: Plugins cause GHC to panic: cannot find dynamic libraries In-Reply-To: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> References: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> Message-ID: <059.95e507d25e1c5c30a9abf5d0afca219a@haskell.org> #15700: Plugins cause GHC to panic: cannot find dynamic libraries -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15492 | Differential Rev(s): Phab:D5253 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sheaf): * differential: => Phab:D5253 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 23 13:20:28 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Oct 2018 13:20:28 -0000 Subject: [GHC] #15751: GHC takes huge amounts of memory and compile time when compiling ZipWith from accelerate In-Reply-To: <047.03b6a24c8ceca13dc1f3f31878c68000@haskell.org> References: <047.03b6a24c8ceca13dc1f3f31878c68000@haskell.org> Message-ID: <062.d35b0470fdbc9099f1b29aa93a76f7bb@haskell.org> #15751: GHC takes huge amounts of memory and compile time when compiling ZipWith from accelerate -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: Compile performance bug | `Data.Array.Accelerate.Test.NoFib.Prelude.ZipWith` | from `accelerate-1.2.0` Blocked By: | Blocking: Related Tickets: #15488 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by tmcdonell): * cc: tmcdonell (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 23 13:48:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Oct 2018 13:48:19 -0000 Subject: [GHC] #11719: Cannot use higher-rank kinds with type families In-Reply-To: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> References: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> Message-ID: <062.e5cef071b6754feb456a5c61f822e1d6@haskell.org> #11719: Cannot use higher-rank kinds with type families -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | dependent/should_compile/T11719 Blocked By: | Blocking: Related Tickets: #13913, #14268 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #13913 => #13913, #14268 Comment: I've found a workaround for the original issue in this ticket after much persistence. The trick is to associate `BaseType` with a type class: {{{#!hs class CBaseType (k :: forall a. a ~> Type) (x :: b) where type BaseType k x :: Type }}} Then, define a flexible instance like so, using an explicit `forall` to give `k` the appropriate higher-rank kind: {{{#!hs instance forall b (k :: forall a. a ~> Type) (x :: b). CBaseType k x where type BaseType k x = (@@) k x }}} That's it! Now you can use `BaseType` like you'd expect: {{{ λ> data ProxySym0 :: forall a. a ~> Type λ> type instance ProxySym0 @@ x = Proxy x λ> :kind! BaseType ProxySym0 Bool BaseType ProxySym0 Bool :: * = Proxy Bool λ> :kind! BaseType ProxySym0 Maybe BaseType ProxySym0 Maybe :: * = Proxy Maybe λ> :kind! BaseType ProxySym0 'Just BaseType ProxySym0 'Just :: * = Proxy 'Just }}} It's a bit gnarly, but this is the best that you can do until #14268 is implemented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 23 13:48:30 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Oct 2018 13:48:30 -0000 Subject: [GHC] #13913: Can't apply higher-ranked kind in type family In-Reply-To: <050.5f4c4ea8193a5e7095f6124ed594e16e@haskell.org> References: <050.5f4c4ea8193a5e7095f6124ed594e16e@haskell.org> Message-ID: <065.35f896f6f0f3c20a7db8a90a323943fa@haskell.org> #13913: Can't apply higher-ranked kind in type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11719 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): I've found a workaround for this issue after much persistence. The trick is to associate `F2` with a type class: {{{#!hs class C (g :: forall a. a -> a) where type F2 g :: Bool }}} Then, define a flexible instance like so, using an explicit `forall` to give `g` the appropriate higher-rank kind: {{{#!hs instance forall (g :: forall a. a -> a). C g where type F2 g = g True }}} That's it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 23 13:49:07 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Oct 2018 13:49:07 -0000 Subject: [GHC] #14268: Implement Explicit Foralls Proposal In-Reply-To: <046.b2c6e5199adb1a263d1f797400e3472d@haskell.org> References: <046.b2c6e5199adb1a263d1f797400e3472d@haskell.org> Message-ID: <061.1f66dfcde60723d61609c76803258086@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: #11719, #13809 | Differential Rev(s): Phab:D4894 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: #13809 => #11719, #13809 Comment: This feature will make #11719 less annoying to work around. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 23 14:02:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Oct 2018 14:02:23 -0000 Subject: [GHC] #14980: Runtime performance regression with binary operations on vectors In-Reply-To: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> References: <045.ab336d0088ca69d4e469f8fa0aa0a8ee@haskell.org> Message-ID: <060.d8f12fff0de6ad7fe368f6f2983d8f30@haskell.org> #14980: Runtime performance regression with binary operations on vectors -------------------------------------+------------------------------------- Reporter: ttylec | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.2.2 Resolution: | Keywords: vector | bitwise operations 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 ttylec): Sorry for long inactivity. I had some time to do more tests recently, based on your suggestions. To focus attention, I tried to investigate difference between: - `performance-bug-pair-1`: 256 columns - `performance-bug-pair-2`: 64 and 256, the same code as in `performance- bug-pair-1` but with 64 column check uncommented On ghc-8.2.2 and ghc-8.0.2. - on ghc-8.2.2, `performance-bug-pair-2` behaves as expected -- we have speedup for both 64 and 256 columns, `performance-bug-pair-1` does not have speed-up. - on ghc-8.0.2, I see speedup in both cases. Based on @tdammers example, I tried to print fired rules difference between both `performance-bug-pair-1` and `performance-bug-pair-2`, using analogous diff expression: {{{ ➜ ghc-bug diff <(grep '^Rule' rules-firing1-1 | sort -u) <(grep '^Rule' rules-firing-2 | sort -u) -u | grep '^[+-]' --- /proc/self/fd/13 2018-10-23 15:49:27.063541325 +0200 +++ /proc/self/fd/14 2018-10-23 15:49:27.067541342 +0200 -Rule fired: eftIntList (GHC.Enum) -Rule fired: stream/unstream [Vector] (Data.Vector.Generic) +Rule fired: SPEC matchPacked @ BPack4 (Main) +Rule fired: SPEC matchPacked @ BPack (Main) }}} `-` are rules that fired for `performance-bug-pair-1` (the bad) and `+` are rules that fired for `performance-bug-pair-2`. It's not about specialization, because I even tried to compile with `performance-bug-pair-1` with explicit monomorphic type. The only common rule on both rules, that fired in bad case and did not fire in good is `Rule fired: stream/unstream [Vector] (Data.Vector.Generic)`. Not that I understand it... but it seems that firing that rule interferes with some GHC optimizations? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 23 14:27:45 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Oct 2018 14:27:45 -0000 Subject: [GHC] #15700: Plugins cause GHC to panic: cannot find dynamic libraries In-Reply-To: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> References: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> Message-ID: <059.95607a2a664a315f5568d3bdcef4ff81@haskell.org> #15700: Plugins cause GHC to panic: cannot find dynamic libraries -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15492 | Differential Rev(s): Phab:D5253 Wiki Page: | -------------------------------------+------------------------------------- Changes (by alpmestan): * cc: alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 23 18:42:58 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Oct 2018 18:42:58 -0000 Subject: [GHC] Batch modify: #2257, #3932, #4031, #4326, #5201, #5356, #5484, ... In-Reply-To: <3423.48e707f7d32c0339d9401ebef6a9f245@haskell.org> References: <3423.48e707f7d32c0339d9401ebef6a9f245@haskell.org> Message-ID: <3438.e93a01ffbdc55670622db618be5c6b17@haskell.org> Batch modification to #2257, #3932, #4031, #4326, #5201, #5356, #5484, #8122, #8182, #8194, #8266, #8320, #10901, #11061, #11419, #11586, #11744, #11820, #12058, #13111, #115, #238, #511, #866, #898, #912, #1093, #1304, #1339, #1346, #1359, #1367, #1394, #1440, #1515, #1528, #1540, #1559, #1625, #1661, #1690, #1703, #1848, #1850, #1879, #1924, #2107, #2318, #2335, #2385, #2694, #3233, #3374, #3438, #3448, #3451, #3475, #3481, #3493, #3494, #3495, #3512, #3529, #3531, #3542, #3556, #3598, #3599, #3610, #3637, #3642, #3644, #3678, #3756, #3852, #3855, #3860, #3863, #3889, #3904, #3934, #4053, #4112, #4155, #4163, #4183, #4829, #4882, #4975, #4982, #4989, #5109, #5354, #5397, #5706, #5874, #5958, #6086, #7017, #7559, #7712, #7819, #7833, #8102, #8374, #8446, #8700, #8725, #9955, #10726, #12755, #13315, #14017, #14021, #14312, #14459, #15442, #32, #46, #55, #60, #99, #121, #144, #166, #212, #234, #235, #245, #260, #268, #284, #300, #350, #355, #363, #390, #442, #465, #482, #486, #521, #5 47, #556, #561, #571, #600, #654, #660, #689, #729, #730, #749, #762, #774, #798, #841, #856, #891, #916, #951, #957, #977, #978, #1009, #1020, #1021, #1028, #1150, #1170, #1242, #1284, #1291, #1299, #1309, #1325, #1352, #1374, #1389, #1395, #1431, #1436, #1459, #1507, #1511, #1578, #1668, #1697, #1698, #1700, #1711, #1717, #1745, #1778, #1796, #1805, #1810, #1837, #1846, #1851, #1854, #1855, #1858, #1860, #1863, #1906, #1926, #1949, #1950, #1961, #1962, #1971, #2009, #2067, #2085, #2198, #2242, #2243, #2263, #2265, #2312, #2342, #2348, #2390, #2423, #2434, #2441, #2443, #2495, #2564, #2567, #2575, #2582, #2613, #2616, #2619, #2654, #2662, #2689, #2718, #2744, #2751, #2752, #2770, #2781, #2789, #2794, #2802, #2809, #2857, #2957, #2958, #2966, #2970, #3004, #3040, #3075, #3077, #3115, #3139, #3148, #3151, #3173, #3201, #3226, #3228, #3230, #3237, #3250, #3254, #3255, #3267, #3289, #3343, #3344, #3350, #3354, #3359, #3375, #3390, #3413, #3426, #3471, #3479, #3510, #3525, #3595, #3597, #3608, #3612, #3623, #3639, #3652, #3661, #3662, #3673, #3683, #3686, #3708, #3716, #3718, #3724, #3730, #3740, #3761, #3763, #3764, #3794, #3804, #3827, #3841, #3842, #3849, #3853, #3882, #3896, #3912, #4032, #4054, #4075, #4117, #4130, #4151, #4171, #4250, #4252, #4253, #4320, #4352, #4357, #4374, #4386, #4402, #4406, #4447, #4461, #4469, #4490, #4496, #4521, #4818, #4819, #4821, #4878, #4883, #4916, #4923, #5033, #5093, #5110, #5119, #5154, #5195, #5196, #5200, #5264, #5276, #5350, #5457, #5459, #5488, #5491, #5579, #5693, #5730, #5743, #5871, #5880, #5933, #5994, #6154, #6169, #7028, #7136, #7152, #7195, #7202, #7234, #7249, #7333, #7340, #7362, #7371, #7381, #7452, #7465, #7470, #7472, #7486, #7544, #7572, #7577, #7592, #7632, #7639, #7648, #7651, #7677, #7686, #7708, #7733, #7760, #7768, #7779, #7780, #7798, #7806, #7810, #7841, #7871, #7879, #7941, #7945, #7979, #7992, #8040, #8056, #8096, #8126, #8259, #8260, #8282, #8349, #8373, #8378, #8379, #8389, #8437, #8438, #8439, #8 465, #8558, #8675, #8709, #8746, #8760, #8764, #8765, #8781, #8784, #8801, #8842, #8866, #8880, #8919, #8940, #8951, #9014, #9053, #9087, #9101, #9184, #9218, #9257, #9302, #9341, #9362, #9363, #9396, #9397, #9442, #9465, #9503, #9513, #9524, #9549, #9578, #9589, #9597, #9603, #9604, #9620, #9626, #9663, #9679, #9697, #9709, #9720, #9727, #9769, #9772, #9828, #9873, #9899, #9924, #9927, #9932, #9945, #9983, #10032, #10070, #10090, #10093, #10096, #10172, #10234, #10240, #10275, #10310, #10349, #10374, #10406, #10410, #10464, #10536, #10543, #10551, #10594, #10601, #10705, #10791, #10795, #10861, #10879, #10973, #11082, #11097, #11109, #11119, #11147, #11168, #11185, #11231, #11354, #11433, #11434, #11445, #11446, #11447, #11530, #11537, #11559, #11587, #11604, #11618, #11657, #11659, #11729, #11737, #11757, #11761, #11946, #11960, #12075, #12078, #12111, #12171, #12193, #12233, #12467, #12487, #12495, #12502, #12598, #12627, #12645, #12722, #12740, #12772, #12840, #12841, #12891, #1 2939, #12940, #12981, #13057, #13091, #13217, #13355, #13356, #13471, #13638, #13686, #13792, #13794, #13812, #13858, #13934, #13935, #14027, #14039, #14126, #14144, #14274, #14392, #14411, #14412, #14469, #14501, #14512, #14526, #14533, #14793, #14867, #14919, #14945, #14986, #15004, #15040, #15075, #15096, #15121, #15130, #15132, #15140, #15190, #15239, #15257, #15425, #15448, #15451, #15506, #15538, #15688, #15726, #15742, #604, #764, #1095, #1096, #2025, #2791, #3472, #3499, #3739, #4366, #5190, #5291, #8156, #8283, #8593, #8723, #9057, #9095, #9678, #9680, #9685, #9807, #9884, #9982, #10157, #10261, #10456, #10476, #11191, #14712, #15218, #1693, #2548, #3003, #3470, #3509, #3533, #8358, #8375, #8794, #9500, #11005, #13459 by bgamari: component to Build System (make) Comment: The new Hadrian build system has been merged. Relabeling the tickets concerning the legacy `make` build system to prevent confusion. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 23 19:15:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Oct 2018 19:15:53 -0000 Subject: [GHC] #15794: shell.nix depends on build artifacts Message-ID: <048.63dee06778c1bd567b4f9a7ef09514bf@haskell.org> #15794: shell.nix depends on build artifacts -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | Keywords: | Operating System: Linux Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Filed Mar 19, 2018, as https://github.com/snowleopard/hadrian/issues/532 **Steps to reproduce:** 1. `git clone --recursive git://git.haskell.org/ghc.git` 2. `cd ghc/hadrian` 3. `nix-shell --pure` **Expected result:** Successful build. **Actual result:** {{{ hadrian(master)$ nix-shell --pure these derivations will be built: /nix/store/lmpgkvswlkcgpcjdilbyh202vm8a5i5r-directory-1.3.1.5.drv /nix/store/rcg0mmq0bincjfjnzbabc8fq7307bylq-process-1.6.3.0.drv /nix/store/15alkpni823gkfp63c79962v032wxvjs-extra-1.6.4.drv /nix/store/1b54g6nv8rw0kq3i5xjpcbhy88jvdnbr-xml-1.3.14.drv /nix/store/89salv051l8yr2y2k52pzkqraw9lfib9-test-framework-0.8.1.1.drv /nix/store/iqq0xsvgf3hf551b3jj0x3lg661c5y4f-test-framework- hunit-0.3.0.2.drv /nix/store/cy7ynm7r9jb41kxb1gxbwdprhvl03ivk-parsec-3.1.13.0.drv /nix/store/rgnsvxfvmbhrkniy0c86v65jgvx8nsan-test-framework- quickcheck2-0.3.0.4.drv /nix/store/fyrj002axd2skdz370hi13fq6prjh5cz-network-uri-2.6.1.0.drv /nix/store/7qcfy5gy9sjcz7cijqghgj3cilm2pzps-HTTP-4000.3.8.drv /nix/store/gk0w3grh2hz008sp6ksy669zvl6pyznb-js-flot-0.8.3.drv /nix/store/h39chz7m8zvawlrzfjsz496vl2rbp921-hashable-1.2.6.1.drv /nix/store/zpv0xi25jq6p5kkpvbc11sq73dxi2g0a-unordered- containers-0.2.8.0.drv /nix/store/i7p5c3mv9p20z7kb2mrdlpx0fwmyz3f5-shake-0.16.2.drv /nix/store/pzfcvib6sbsaascsc7djzcfqzlw847gc-Cabal-2.3.0.0.drv /nix/store/j5w4i42pgfy03s7fjsj4dfkis26c3nnp-happy-1.19.8.drv /nix/store/pl2dxjvbqs36rh80q5i09zdhbh6hjl2r-alex-3.2.3.drv /nix/store/dck8p81zlij9qksglaw8hkp11msrm426-hadrian-0.1.0.0.drv building '/nix/store/lmpgkvswlkcgpcjdilbyh202vm8a5i5r- directory-1.3.1.5.drv'... building '/nix/store/1b54g6nv8rw0kq3i5xjpcbhy88jvdnbr-xml-1.3.14.drv'... setupCompilerEnvironmentPhase Build with /nix/store/d57p5gzyld7b3y4irzv70bfa3d8xxwgx-ghc-8.2.2. setupCompilerEnvironmentPhase Build with /nix/store/d57p5gzyld7b3y4irzv70bfa3d8xxwgx-ghc-8.2.2. unpacking sources unpacking source archive /nix/store/khjm3agcb1y91925r78h3chaq56w9fi7 -6wsbrbb60dzbfqf62c6sskwcijc3arjj-directory unpacking sources unpacking source archive /nix/store/dnx7hpl7wz81r3av4l09pqqhdqi4qpg6-xml-1.3.14.tar.gz source root is xml-1.3.14 source root is 6wsbrbb60dzbfqf62c6sskwcijc3arjj-directory setting SOURCE_DATE_EPOCH to timestamp 1424727750 of file xml-1.3.14/xml.cabal patching sources patching sources compileBuildDriverPhase compileBuildDriverPhase setupCompileFlags: -package-db=/tmp/nix-build- xml-1.3.14.drv-0/package.conf.d -j1 -threaded setupCompileFlags: -package-db=/tmp/nix-build- directory-1.3.1.5.drv-0/package.conf.d -j1 -threaded [1 of 1] Compiling Main ( Setup.hs, /tmp/nix-build- directory-1.3.1.5.drv-0/Main.o ) [1 of 1] Compiling Main ( Setup.hs, /tmp/nix-build- xml-1.3.14.drv-0/Main.o ) Linking Setup ... Linking Setup ... configuring configureFlags: --verbose --prefix=/nix/store /v3yazy78gy6kkpvrcn3schm8lc8y5dgl-xml-1.3.14 --libdir=$prefix/lib/$compiler --libsubdir=$pkgid --docdir=/nix/store /zdzgar7mwysym9dbai87fann20pbw75n-xml-1.3.14-doc/share/doc --with-gcc=gcc --package-db=/tmp/nix-build-xml-1.3.14.drv-0/package.conf.d --ghc- option=-optl=-Wl,-rpath=/nix/store/v3yazy78gy6kkpvrcn3schm8lc8y5dgl- xml-1.3.14/lib/ghc-8.2.2/xml-1.3.14 --ghc-option=-j1 --disable-split-objs --disable-library-profiling --disable-profiling --enable-shared --disable- coverage --enable-library-vanilla --enable-executable-dynamic --enable- tests --ghc-option=-split-sections configuring configureFlags: --verbose --prefix=/nix/store /59r1c7sfgph9j2xxsc1k3j6dwkm32ybk-directory-1.3.1.5 --libdir=$prefix/lib/$compiler --libsubdir=$pkgid --docdir=/nix/store /w0gkzrf5q6ng40vzyvdl5m8pvw9v9dxy-directory-1.3.1.5-doc/share/doc --with- gcc=gcc --package-db=/tmp/nix-build-directory-1.3.1.5.drv-0/package.conf.d --ghc-option=-optl=-Wl,-rpath=/nix/store/59r1c7sfgph9j2xxsc1k3j6dwkm32ybk- directory-1.3.1.5/lib/ghc-8.2.2/directory-1.3.1.5 --ghc-option=-j1 --disable-split-objs --disable-library-profiling --disable-profiling --enable-shared --disable-coverage --enable-library-vanilla --enable- executable-dynamic --enable-tests --ghc-option=-split-sections Configuring directory-1.3.1.5... Warning: The 'build-type' is 'Configure' but there is no 'configure' script. You probably need to run 'autoreconf -i' to generate it. Configuring xml-1.3.14... Dependency base >=3 && <5: using base-4.10.1.0 Dependency bytestring -any: using bytestring-0.10.8.2 Dependency text -any: using text-1.2.3.0 Dependency base >=4.5 && <4.12: using base-4.10.1.0 Dependency directory -any: using directory-1.3.1.5 Dependency filepath >=1.3 && <1.5: using filepath-1.4.2 Dependency time >=1.4 && <1.9: using time-1.8.0.2 Dependency unix >=2.5.1 && <2.8: using unix-2.7.2.2 Source component graph: component lib component test:test dependency lib Configured component graph: component directory-1.3.1.5-EFdDcGoPsV2JQnFPz1QOGK include base-4.10.1.0 include time-1.8.0.2 include filepath-1.4.2-DyDAQ5oOwBVDvLxMoNLDxx include unix-2.7.2.2 component directory-1.3.1.5-8aJ3UecsjNUIxs4bq1vU8T-test include base-4.10.1.0 include directory-1.3.1.5-EFdDcGoPsV2JQnFPz1QOGK include filepath-1.4.2-DyDAQ5oOwBVDvLxMoNLDxx include time-1.8.0.2 include unix-2.7.2.2 Linked component graph: unit directory-1.3.1.5-EFdDcGoPsV2JQnFPz1QOGK include base-4.10.1.0 include time-1.8.0.2 include filepath-1.4.2-DyDAQ5oOwBVDvLxMoNLDxx include unix-2.7.2.2 System.Directory=directory-1.3.1.5-EFdDcGoPsV2JQnFPz1QOGK:System.Directory,System.Directory.Internal=directory-1.3.1.5-EFdDcGoPsV2JQnFPz1QOGK:System.Directory.Internal,System.Directory.Internal.Prelude=directory-1.3.1.5-EFdDcGoPsV2JQnFPz1QOGK:System.Directory.Internal.Prelude unit directory-1.3.1.5-8aJ3UecsjNUIxs4bq1vU8T-test include base-4.10.1.0 include directory-1.3.1.5-EFdDcGoPsV2JQnFPz1QOGK include filepath-1.4.2-DyDAQ5oOwBVDvLxMoNLDxx include time-1.8.0.2 include unix-2.7.2.2 Ready component graph: definite directory-1.3.1.5-EFdDcGoPsV2JQnFPz1QOGK depends base-4.10.1.0 depends time-1.8.0.2 depends filepath-1.4.2-DyDAQ5oOwBVDvLxMoNLDxx depends unix-2.7.2.2 definite directory-1.3.1.5-8aJ3UecsjNUIxs4bq1vU8T-test depends base-4.10.1.0 depends directory-1.3.1.5-EFdDcGoPsV2JQnFPz1QOGK depends filepath-1.4.2-DyDAQ5oOwBVDvLxMoNLDxx depends time-1.8.0.2 depends unix-2.7.2.2 Using Cabal-2.0.1.0 compiled by ghc-8.2 Using compiler: ghc-8.2.2 Using install prefix: /nix/store/59r1c7sfgph9j2xxsc1k3j6dwkm32ybk-directory-1.3.1.5 Executables installed in: /nix/store/59r1c7sfgph9j2xxsc1k3j6dwkm32ybk-directory-1.3.1.5/bin Libraries installed in: /nix/store/59r1c7sfgph9j2xxsc1k3j6dwkm32ybk- directory-1.3.1.5/lib/ghc-8.2.2/directory-1.3.1.5 Dynamic Libraries installed in: /nix/store/59r1c7sfgph9j2xxsc1k3j6dwkm32ybk- directory-1.3.1.5/lib/ghc-8.2.2/x86_64-linux-ghc-8.2.2 Private executables installed in: /nix/store/59r1c7sfgph9j2xxsc1k3j6dwkm32ybk- directory-1.3.1.5/libexec/x86_64-linux-ghc-8.2.2/directory-1.3.1.5 Data files installed in: /nix/store/59r1c7sfgph9j2xxsc1k3j6dwkm32ybk-directory-1.3.1.5/share/x86_64 -linux-ghc-8.2.2/directory-1.3.1.5 Documentation installed in: /nix/store/w0gkzrf5q6ng40vzyvdl5m8pvw9v9dxy- directory-1.3.1.5-doc/share/doc Configuration files installed in: /nix/store/59r1c7sfgph9j2xxsc1k3j6dwkm32ybk-directory-1.3.1.5/etc No alex found Using ar found on system at: /nix/store/aplvnhqdm6s9wj9r0jh46r46wvh65j86-binutils-2.28.1/bin/ar No c2hs found No cpphs found No doctest found Using gcc version 6.4.0 given by user at: /nix/store/wriy1xis74fybcg3m1jnq5bd5myxvhm6-gcc-wrapper-6.4.0/bin/gcc Using ghc version 8.2.2 found on system at: /nix/store/d57p5gzyld7b3y4irzv70bfa3d8xxwgx-ghc-8.2.2/bin/ghc Using ghc-pkg version 8.2.2 found on system at: /nix/store/d57p5gzyld7b3y4irzv70bfa3d8xxwgx-ghc-8.2.2/bin/ghc-pkg No ghcjs found No ghcjs-pkg found No greencard found Using haddock version 2.18.1 found on system at: /nix/store/d57p5gzyld7b3y4irzv70bfa3d8xxwgx-ghc-8.2.2/bin/haddock No happy found Using haskell-suite found on system at: haskell-suite-dummy-location Using haskell-suite-pkg found on system at: haskell-suite-pkg-dummy- location No hmake found Using hpc version 0.67 found on system at: /nix/store/d57p5gzyld7b3y4irzv70bfa3d8xxwgx-ghc-8.2.2/bin/hpc Using hsc2hs version 0.68.2 found on system at: /nix/store/d57p5gzyld7b3y4irzv70bfa3d8xxwgx-ghc-8.2.2/bin/hsc2hs Using hscolour version 1.24 found on system at: /nix/store/yf0bs1q9ph388jms8xlgcd5vh99amjm4-hscolour-1.24.2/bin/HsColour No jhc found Using ld found on system at: /nix/store/wriy1xis74fybcg3m1jnq5bd5myxvhm6-gcc-wrapper-6.4.0/bin/ld No lhc found No lhc-pkg found No pkg-config found Using runghc version 8.2.2 found on system at: /nix/store/d57p5gzyld7b3y4irzv70bfa3d8xxwgx-ghc-8.2.2/bin/runghc Using strip version 2.28 found on system at: /nix/store/aplvnhqdm6s9wj9r0jh46r46wvh65j86-binutils-2.28.1/bin/strip Using tar found on system at: /nix/store/vvq16kzwgx9yhkf0fwwms5xzgg0rwdpl-gnutar-1.29/bin/tar No uhc found Setup: configure script not found. builder for '/nix/store/lmpgkvswlkcgpcjdilbyh202vm8a5i5r- directory-1.3.1.5.drv' failed with exit code 1 cannot build derivation '/nix/store/dck8p81zlij9qksglaw8hkp11msrm426-hadrian-0.1.0.0.drv': 1 dependencies couldn't be built error: build of '/nix/store/dck8p81zlij9qksglaw8hkp11msrm426-hadrian-0.1.0.0.drv' failed }}} Notice that the build fails for a library shipped with GHC. In `shell.nix` it's included as `localPackage`. **Workaround** First, we need to run `configurePhase` of the default Nix derivation for GHC HEAD: 1. `cd ghc` 2. `nix-shell '' -A haskell.compiler.ghcHEAD` 3. `configurePhase` 4. `exit` Now we can `cd` into `ghc/hadrian` and proceed normally, the build won't fail. The issue is that this step shouldn't be required, we must have a self- contained `shell.nix`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 23 20:16:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Oct 2018 20:16:03 -0000 Subject: [GHC] #15794: shell.nix depends on build artifacts In-Reply-To: <048.63dee06778c1bd567b4f9a7ef09514bf@haskell.org> References: <048.63dee06778c1bd567b4f9a7ef09514bf@haskell.org> Message-ID: <063.8fab7e3663330372b12659ac3274b016@haskell.org> #15794: shell.nix depends on build artifacts -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For what it's worth, I use generally use Alp's [[https://github.com/alpmestan/ghc.nix|ghc.nix]] to build GHC under NixOS. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 23 20:27:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Oct 2018 20:27:53 -0000 Subject: [GHC] #15794: shell.nix depends on build artifacts In-Reply-To: <048.63dee06778c1bd567b4f9a7ef09514bf@haskell.org> References: <048.63dee06778c1bd567b4f9a7ef09514bf@haskell.org> Message-ID: <063.6b6eabdbe67bc45bc8234e026c4de281@haskell.org> #15794: shell.nix depends on build artifacts -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): [comment:1 bgamari], so do I – however, I expect the `shell.nix` shipped with GHC to work properly if it exists at all. Besides, `ghc.nix` requires the same preparations, manually running `./boot && ./configure`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 23 21:21:19 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Oct 2018 21:21:19 -0000 Subject: [GHC] #15793: Type family doesn't reduce with visible kind application In-Reply-To: <051.61f364214000f10c10115e9460ffba57@haskell.org> References: <051.61f364214000f10c10115e9460ffba57@haskell.org> Message-ID: <066.1cf167fc2d2b6eafbf7421eea4530305@haskell.org> #15793: Type family doesn't reduce with visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: invalid | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => invalid Comment: This is expected behavior. Your `F2` has an arity of 0 and so takes no argument, visible or otherwise. See related discussion in #11719. We don't yet have the syntax to declare a type family whose argument is both invisible and non-dependent. This would work fine internally, but there's just no way to say it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 23 21:45:43 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Oct 2018 21:45:43 -0000 Subject: [GHC] #14062: Pure syntax transformation affects performance. In-Reply-To: <046.089af9e8af77712388f25b4c1e1105b6@haskell.org> References: <046.089af9e8af77712388f25b4c1e1105b6@haskell.org> Message-ID: <061.346671b3680b82eceda04bebb9a4a505@haskell.org> #14062: Pure syntax transformation affects performance. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): I can't reproduce with 8.6.1 either: {{{ benchmarking monad transformers overhead/test1 time 94.84 ms (91.89 ms .. 97.81 ms) 0.998 R² (0.993 R² .. 1.000 R²) mean 97.52 ms (95.91 ms .. 100.6 ms) std dev 3.344 ms (1.380 ms .. 4.705 ms) benchmarking monad transformers overhead/test2 time 95.69 ms (94.49 ms .. 98.26 ms) 0.999 R² (0.996 R² .. 1.000 R²) mean 95.81 ms (95.24 ms .. 97.28 ms) std dev 1.375 ms (323.2 μs .. 2.151 ms) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 23 21:47:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Oct 2018 21:47:33 -0000 Subject: [GHC] #14062: Pure syntax transformation affects performance. In-Reply-To: <046.089af9e8af77712388f25b4c1e1105b6@haskell.org> References: <046.089af9e8af77712388f25b4c1e1105b6@haskell.org> Message-ID: <061.00c0c9726ec0a44733bc394669351507@haskell.org> #14062: Pure syntax transformation affects performance. -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: infoneeded Priority: high | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by George): * status: new => infoneeded * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 23 22:18:46 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Oct 2018 22:18:46 -0000 Subject: [GHC] #14251: LLVM Code Gen messes up registers In-Reply-To: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> References: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> Message-ID: <062.c9298213fc80519c041224c754973951@haskell.org> #14251: LLVM Code Gen messes up registers -------------------------------------+------------------------------------- Reporter: angerman | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler (LLVM) | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5190 Wiki Page: | -------------------------------------+------------------------------------- Comment (by kavon): New fix is up: https://phabricator.haskell.org/D5254 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 23 22:19:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Oct 2018 22:19:09 -0000 Subject: [GHC] #14251: LLVM Code Gen messes up registers In-Reply-To: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> References: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> Message-ID: <062.7703e3d01478237d74c209e2f4449a50@haskell.org> #14251: LLVM Code Gen messes up registers -------------------------------------+------------------------------------- Reporter: angerman | Owner: kavon Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler (LLVM) | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5190 Wiki Page: | -------------------------------------+------------------------------------- Changes (by kavon): * owner: (none) => kavon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 23 22:57:30 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Oct 2018 22:57:30 -0000 Subject: [GHC] #14854: The size of FastString table is suboptimal for large codebases In-Reply-To: <046.96a71a8566a954e21839a1a60572305e@haskell.org> References: <046.96a71a8566a954e21839a1a60572305e@haskell.org> Message-ID: <061.2d13336283dab6470062b1d71252aef7@haskell.org> #14854: The size of FastString table is suboptimal for large codebases -------------------------------------+------------------------------------- Reporter: niteria | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5211 Wiki Page: | -------------------------------------+------------------------------------- Changes (by watashi): * owner: (none) => watashi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 23 22:59:50 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Oct 2018 22:59:50 -0000 Subject: [GHC] #12119: Can't create injective type family equation with TypeError as the RHS In-Reply-To: <050.21d4af732cea81fafcb58c894bb8137c@haskell.org> References: <050.21d4af732cea81fafcb58c894bb8137c@haskell.org> Message-ID: <065.833c5ccb55be3eab3a897aab34a602e1@haskell.org> #12119: Can't create injective type family equation with TypeError as the RHS -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: wontfix | CustomTypeErrors, TypeFamilies, | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by sheaf): * cc: sheaf (added) Comment: I understand that the type family is injective if I remove the type error. However I would prefer a custom error message, as opposed to the user getting some confusing error about stuck type families. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 00:07:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 00:07:29 -0000 Subject: [GHC] #15795: Core lint error with visible kind patterns Message-ID: <051.bf94d4950afb355e3a341dea83f8a180@haskell.org> #15795: Core lint error with visible kind patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Finally managed to trigger a core lint error with #12045 {{{#!hs {-# Language RankNTypes #-} {-# Language TypeApplications #-} {-# Language DataKinds #-} {-# Language PolyKinds #-} {-# Language TypeOperators #-} {-# Language GADTs #-} {-# Options_GHC -dcore-lint #-} import Data.Kind type Cat ob = ob -> ob -> Type data (×) :: forall (cat1 :: Cat ob1) (cat2 :: Cat ob2). Cat (ob1, ob2) where Prod :: forall ob1 ob2 cat1 cat2 a1 b1 a2 b2 u. cat1 a1 b1 -> cat2 a2 b2 -> (×) @u '(a1, a2) '(b1, b2) }}} log attached from running `ghci -ignore-dot-ghci .hs` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 00:07:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 00:07:38 -0000 Subject: [GHC] #15795: Core lint error with visible kind patterns In-Reply-To: <051.bf94d4950afb355e3a341dea83f8a180@haskell.org> References: <051.bf94d4950afb355e3a341dea83f8a180@haskell.org> Message-ID: <066.cd39148aed81c3334fd9fc39a18d1229@haskell.org> #15795: Core lint error with visible kind patterns -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * Attachment "log" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 01:50:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 01:50:14 -0000 Subject: [GHC] #15796: Core Lint error Message-ID: <051.693414c0b173ccf97801ac65c4aeaf38@haskell.org> #15796: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This gives a Core Lint error {{{#!hs {-# Language QuantifiedConstraints #-} {-# Language TypeApplications #-} {-# Language TypeOperators #-} {-# Language PolyKinds #-} {-# Language FlexibleInstances #-} {-# Language DataKinds #-} {-# Language TypeFamilies #-} {-# Language MultiParamTypeClasses #-} {-# Language ConstraintKinds #-} {-# Language UndecidableInstances #-} {-# Language GADTs #-} {-# Options_GHC -dcore-lint #-} import Data.Kind type Cat ob = ob -> ob -> Type class Ríki (obj :: Type) where type (-->) :: Cat obj class Varpi (f :: dom -> cod) newtype (··>) :: Cat (a -> b) where Natu :: Varpi f => (forall xx. f xx --> f' xx) -> (f ··> f') instance Ríki cod => ------------- Ríki (dom -> cod) where type (-->) = (··>) @dom @cod }}} {{{ $ ghci -ignore-dot-ghci 568_bug.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 568_bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181017 for x86_64-unknown-linux): Core Lint error : warning: In the type ‘(··>)’ Found TcTyCon: ··>[tc] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/typecheck/FamInst.hs:171:31 in ghc:FamInst Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > :q Leaving GHCi. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 02:40:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 02:40:44 -0000 Subject: [GHC] #15797: GHC panic using visible kind application Message-ID: <051.d9fe92394302d401a2d56c3c16cf3fc2@haskell.org> #15797: GHC panic using visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language RankNTypes #-} {-# Language TypeFamilies #-} {-# Language ScopedTypeVariables #-} {-# Language TypeApplications #-} {-# Language DataKinds #-} {-# Language PolyKinds #-} {-# Language TypeOperators #-} {-# Language GADTs #-} {-# Options_GHC -dcore-lint #-} import Data.Kind class Ríki (obj :: Type) where type Obj :: obj -> Constraint type Obj = Bæ @obj class Bæ (a :: k) instance Bæ @k (a :: k) data EQ :: forall ob. ob -> ob -> Type where EQ :: EQ a a instance Ríki (EQ @ob) }}} {{{ $ ghci -dcore-lint 568_bug.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 568_bug.hs, interpreted ) WARNING: file compiler/types/TyCoRep.hs, line 2567 in_scope InScope {ob_a1zs co_a1zt} tenv [] cenv [a1zt :-> co_a1zt] tys [Bæ] cos [] needInScope [a1zn :-> co_a1zn, a1zs :-> ob_a1zs] ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181017 for x86_64-unknown-linux): Core Lint error : warning: In the type ‘Bæ’ Unfilled coercion hole: {co_a1zn} : warning: In the type ‘Bæ’ co_a1zn :: (ob_a1zs -> ob_a1zs -> *) ~# * [LclId[CoVarId]] is out of scope Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/typecheck/FamInst.hs:171:31 in ghc:FamInst Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 02:50:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 02:50:01 -0000 Subject: [GHC] #12119: Can't create injective type family equation with TypeError as the RHS In-Reply-To: <050.21d4af732cea81fafcb58c894bb8137c@haskell.org> References: <050.21d4af732cea81fafcb58c894bb8137c@haskell.org> Message-ID: <065.b82d17e1c6613a6500ccccd71e3c42e3@haskell.org> #12119: Can't create injective type family equation with TypeError as the RHS -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: Resolution: wontfix | CustomTypeErrors, TypeFamilies, | InjectiveFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): The injectivity annotation is a promise that all your equations are injective. Then consider the return ''type'' of `ToDim 5` compared to `ToDim 6` (if you put a `TypeError` equation): they're the same type. Then that equation is not injective. Specifically, `ShowType n` is not injective: [https://downloads.haskell.org/~ghc/latest/docs/html/libraries/base-4.12.0.0/src /GHC-TypeLits.html#AppendSymbol it's an existentially-quantified data constructor, promoted to a datakind]. If you omit the `TypeError` equation, there's an implicit `ToDim n = ToDim n` added at the end. That is injective. Possibly you could put some other error-handling logic, that preserves plain `n` on the rhs, then that would be injective. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 03:43:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 03:43:34 -0000 Subject: [GHC] #13104: runRW# ruins join points In-Reply-To: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> References: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> Message-ID: <064.cc10699ca4b26d7bdcfddb095abb3817@haskell.org> #13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: chessai Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.1 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 chessai): Replying to [comment:16 sgraf]: > I very much agree with what nomeata (comment:10) and simonpj (comment:14) said. We should aim for `loop 0` to be eta-expanded by realising that `runRW#` only calls its argument once. > > I would begin by looking at how `runRW#` gets its demand signature. It's not listed in primops.txt.pp, so it doesn't seem to be hard-coded into the compiler. It gets 'inlined' in CorePrep and in `cpe_app` there's a test for `runRWKey`. > > The problem, I guess, is that `runRW#` isn't a recognized primop. On the other hand, it doesn't seem to be a regular identifier, either: If the demand analyser were to look into its definition, it would be given a demand signature of ``, e.g. a signature saying that it calls its argument exactly once with one argument. We want the one-shot (i.e. usage demand) part, but apparently (see Note [runRW magic] in CorePrep) not the strictness part. > > So, I'd say `runRW#` should be handled as a regular primop like i.e. `catch#` and give it a `lazyApply1Dmd`. If this doesn't help, we could always fall back to more special cases. This is pretty useful information, thanks! When you say 'handle _like_ a regular primop', do you mean to say 'make it a primop'? To be clear, while currently the demand signature of `runRW#` is ``, and you'd rather it be `< L, C1(U)>`? Why? How is this laziness related to the problem related to the Note [runRW magic]? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 07:25:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 07:25:08 -0000 Subject: [GHC] #15135: Overlapping typeclass instance selection depends on the optimisation level In-Reply-To: <046.e35da1b896548effba77cf7dc5003beb@haskell.org> References: <046.e35da1b896548effba77cf7dc5003beb@haskell.org> Message-ID: <061.86d3bbf871af074cb5f4470e89de2f5c@haskell.org> #15135: Overlapping typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by baramoglo): Here is an example that exhibits the same bug (I think) in a single file: {{{ {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE MultiParamTypeClasses #-} data A = A deriving (Show) data B a = B a deriving (Show) class Project a b where project :: b -> Maybe a instance {-# OVERLAPPING #-} Project a b where project _ = Nothing instance {-# OVERLAPPING #-} Project a a where project = Just instance {-# OVERLAPPING #-} Project a b => Project a (B b) where project (B a) = project a main = print (project (B A) :: Maybe A) }}} Prints `Just A` when compiled with `-O0` and `Nothing` when compiled with `-O1`. Note that the first instance should really say `{-# OVERLAPPABLE #-}` (AFAIU). If I change to that, the bug goes away. Let me know if you think this should be filed as a different bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 08:27:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 08:27:24 -0000 Subject: [GHC] #10445: Wrong stack space size when using -Ksize In-Reply-To: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> References: <042.794c5bde83bb1d57f2fc1adc9766262f@haskell.org> Message-ID: <057.cb2bc21f58869ee205abaee89852975c@haskell.org> #10445: Wrong stack space size when using -Ksize -------------------------------------+------------------------------------- Reporter: asr | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D938, Wiki Page: | Phab:D961 -------------------------------------+------------------------------------- Changes (by Lemming): * milestone: 8.0.1 => 8.6.2 Comment: I just encountered the problem in GHC-8.6.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 08:30:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 08:30:40 -0000 Subject: [GHC] #13104: runRW# ruins join points In-Reply-To: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> References: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> Message-ID: <064.53a77f74cb894334559ab021b49b1841@haskell.org> #13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: chessai Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.1 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 sgraf): Yes, I meant 'make runRW# a proper primop'. It's treated like one by Core anyway. This mostly entails adding it to primops.txt.pp, but I'd suggest grepping for mentions of another primop like `seq#` (lowered in STG, IIRC) and handle it the same way. > To be clear, while currently the demand signature of runRW# is , and you'd rather it be < L, C1(U)>? Why? How is this laziness related to the problem related to the Note [runRW magic]? I got the note wrong. I was referring to `Note [runRW arg]`, but that note says that we ''should'' make `runRW#` strict and says that we do so in `MkId`. I couldn't find any mention of runRW in there, so that may have been a lie, not sure. So, it seems that `` is actually the correct demand signature. Upon following Phab:D2444, I'm not so sure anymore we should actually handle it as a primop, but rather like `lazy` or `unsafeCoerce#` entirely in `MkId`. Reading wiki:Commentary/PrimOps and wiki:Commentary/Compiler/WiredIn, it seems that currently `runRW#` is a "known-key" thing, but we need it to become a "wired-in" thing to attach useful `IdInfo` such as demand signatures. It should not become a prim-op, because we know how to lower it in CoreToStg as opposed to StgToCmm (effectively 'linking' to an appropriate implementation). It would be great if someone more knowledgable could chime in and confirm my last paragraph. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 10:26:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 10:26:59 -0000 Subject: [GHC] #13104: runRW# ruins join points In-Reply-To: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> References: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> Message-ID: <064.af8c1b80f1402d9c8626b84632291a80@haskell.org> #13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: chessai Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.1 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): Primops are intended to reflect machine operations that simply cannot be expressed more simply in Haskell (at least not efficiently): e.g. add two `Int#` values. Things like `unsafeCoerce#`, `lazy`, and `runRW#` really are expressible in a functional style; and "lowering" them in `CoreToSTG` feels like the right place to deal with them. So yes, either known-key or wired-in `Id`. We need wired-in if we need IdInfo that won't be inferred; but actually I think the right strictness ''will'' be inferred from its definition, so maybe known-key is enough. The important thing is that we don't inline it until very very late; and (sadly) we may want the simplifier to treat it specially. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 10:45:37 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 10:45:37 -0000 Subject: [GHC] #15135: Overlapping typeclass instance selection depends on the optimisation level In-Reply-To: <046.e35da1b896548effba77cf7dc5003beb@haskell.org> References: <046.e35da1b896548effba77cf7dc5003beb@haskell.org> Message-ID: <061.8ae6d57e0bb2c6e9b17aab7fd11eaefa@haskell.org> #15135: Overlapping typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:3 baramoglo]: > Here is an example that exhibits the same bug (I think) in a single file: > > ... > Prints `Just A` when compiled with `-O0` and `Nothing` when compiled with `-O1`. > I agree the optimisation level shouldn't change the behaviour when everything's in a single module. > Note that the first instance should really say `{-# OVERLAPPABLE #-}` (AFAIU). If I change to that, the bug goes away. > Ugh! Strictly speaking, the second and third instances are `INCOHERENT` because in no substitution ordering. But your `project (B A) :: Maybe A`, by giving a type annotation means it's apart from the second instance. (It should resolve to the third, which is marked `OVERLAPPING` so that's OK against the other eligible instance, i.e. the first one.) > Let me know if you think this should be filed as a different bug. The O.P. is a classic 'Orphan Instances' problem, so expected behaviour. And as Simon's comment:2 says, use `OVERLAPPABLE` to avoid premature instance resolution in the imported module. I'm surprised that also seems to be required when in a single module. That seems too subtle for my liking. BTW what happens if you change all the pragmas to `OVERLAPS`? (That's supposed to give the effect of both `OVERLAPPING` and `OVERLAPPABLE`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 10:48:41 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 10:48:41 -0000 Subject: [GHC] #13104: runRW# ruins join points In-Reply-To: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> References: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> Message-ID: <064.38aa0a53768f08921a60ac3b1276f6f9@haskell.org> #13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: chessai Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.1 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 sgraf): Replying to [comment:19 simonpj]: > So yes, either known-key or wired-in `Id`. We need wired-in if we need IdInfo that won't be inferred; but actually I think the right strictness ''will'' be inferred from its definition, so maybe known-key is enough. Ah, right. I thought I checked this and expected `runRW#`'s strictness signature to be present in the interface file for `GHC.Exts`, but it wasn't, so I assumed it got special treatment, like wired-in things. It turns out that `f` in the this program {{{ {-# LANGUAGE MagicHash #-} module Foo where import GHC.Magic f = runRW# }}} has the right strictness signature ``. Then it's a little unclear to me why `loop 0` (or the definition of `loop`, at least) isn't eta-expanded. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 11:32:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 11:32:35 -0000 Subject: [GHC] #13104: runRW# ruins join points In-Reply-To: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> References: <049.de62ded7b05ef8af28dbfe5dd7c43ff2@haskell.org> Message-ID: <064.eba2c8ef78ca2dba44a739459f6ffb4b@haskell.org> #13104: runRW# ruins join points -------------------------------------+------------------------------------- Reporter: lukemaurer | Owner: chessai Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.1 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: | -------------------------------------+------------------------------------- Changes (by sgraf): * status: new => infoneeded Comment: Actually, I don't think this reproduces any longer. What's actually the regression test here? The argument to `runST` in #12781 is properly eta- expanded in GHC 8.4.3. Any attempt to manually reproduce the issue with similar code as in the OP, e.g. {{{ f = runST (loop (0 :: Int)) where loop 1000 = return 42 loop n = loop (n+1) }}} leads to this Core for `f`: {{{ Rec { -- RHS size: {terms: 14, types: 11, coercions: 0, joins: 0/0} $wloop $wloop = \ ww_s2DT w_s2DQ -> case ww_s2DT of wild_Xk { __DEFAULT -> $wloop (+# wild_Xk 1#) w_s2DQ; 1000# -> (# w_s2DQ, lvl_r2Eo #) } end Rec } -- RHS size: {terms: 4, types: 2, coercions: 0, joins: 0/0} f1 f1 = \ w_s2DQ -> $wloop 0# w_s2DQ -- RHS size: {terms: 5, types: 30, coercions: 0, joins: 0/0} f f = case runRW# f1 of { (# ipv_a2Bw, ipv1_a2Bx #) -> ipv1_a2Bx } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 11:47:53 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 11:47:53 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.d798ec123ed9cf350075036e34e7ff39@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201, Phab:D5226 -------------------------------------+------------------------------------- Changes (by asr): * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 11:59:16 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 11:59:16 -0000 Subject: [GHC] #15135: Overlapping typeclass instance selection depends on the optimisation level In-Reply-To: <046.e35da1b896548effba77cf7dc5003beb@haskell.org> References: <046.e35da1b896548effba77cf7dc5003beb@haskell.org> Message-ID: <061.6d68ef8053fe52200fec01b73974ee73@haskell.org> #15135: Overlapping typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by baramoglo): Replying to [comment:4 AntC]: > BTW what happens if you change all the pragmas to `OVERLAPS`? Then it works correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 12:15:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 12:15:08 -0000 Subject: [GHC] #15793: Type family doesn't reduce with visible kind application In-Reply-To: <051.61f364214000f10c10115e9460ffba57@haskell.org> References: <051.61f364214000f10c10115e9460ffba57@haskell.org> Message-ID: <066.f75b3d12b114343d1f61d630ca445215@haskell.org> #15793: Type family doesn't reduce with visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: invalid => Comment: But surely we should reject {{{ F2 @a = Maybe a }}} on the grounds that, well, `F2` has arity 0, so you can't supply an `@ty` arg on the left? > We don't yet have the syntax to declare a type family whose argument is both invisible and non-dependent. Is another way to say this that the final argument of a type family must be `Required`; it cannot be `Specified`? What about `Inferred`? I think that is possible, isn't it? We should document this somehow in the user manual. Re-opening for these reasons. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 12:19:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 12:19:40 -0000 Subject: [GHC] #10453: \case should trigger auto-multiline mode in ghci In-Reply-To: <044.2d59789cf30828fd243fec4509fe4124@haskell.org> References: <044.2d59789cf30828fd243fec4509fe4124@haskell.org> Message-ID: <059.ef3bb7db8e36c79c098a93dafd2fbc5c@haskell.org> #10453: \case should trigger auto-multiline mode in ghci -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5236 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"eaf159340cfa948c16fa212ff1bf5aec6134a694/ghc" eaf1593/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eaf159340cfa948c16fa212ff1bf5aec6134a694" Trigger multiline mode in GHCi on '\case' (#13087) Summary: In ALR, 'ITlcase' should expect an opening curly. This is probably a forgotten edge case in ALR, since `maybe_layout` (which handles the non-ALR layout) already deals with the 'ITlcase' token properly. Test Plan: make TEST=T10453 && make TEST=T13087 Reviewers: bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #10453, #13087 Differential Revision: https://phabricator.haskell.org/D5236 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 12:19:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 12:19:40 -0000 Subject: [GHC] #13087: AlternativeLayoutRule breaks LambdaCase In-Reply-To: <049.ad6e034aa7e8b11be8486b436f8c84ca@haskell.org> References: <049.ad6e034aa7e8b11be8486b436f8c84ca@haskell.org> Message-ID: <064.1a8e00c2a76de9d182e78e9f2b5e9709@haskell.org> #13087: AlternativeLayoutRule breaks LambdaCase -------------------------------------+------------------------------------- Reporter: ohhellojoe | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 (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): Phab:D5236 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"eaf159340cfa948c16fa212ff1bf5aec6134a694/ghc" eaf1593/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="eaf159340cfa948c16fa212ff1bf5aec6134a694" Trigger multiline mode in GHCi on '\case' (#13087) Summary: In ALR, 'ITlcase' should expect an opening curly. This is probably a forgotten edge case in ALR, since `maybe_layout` (which handles the non-ALR layout) already deals with the 'ITlcase' token properly. Test Plan: make TEST=T10453 && make TEST=T13087 Reviewers: bgamari, RyanGlScott Reviewed By: RyanGlScott Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #10453, #13087 Differential Revision: https://phabricator.haskell.org/D5236 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 12:19:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 12:19:40 -0000 Subject: [GHC] #15783: Quoting an internal variable causes an error when splicing In-Reply-To: <049.e3b5744f03cf250cd18d056d6a8f061a@haskell.org> References: <049.e3b5744f03cf250cd18d056d6a8f061a@haskell.org> Message-ID: <064.e838664bb35149848ee375a2105987cf@haskell.org> #15783: Quoting an internal variable causes an error when splicing -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5248 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"bb835c96c3d962c2e08d23f6fb900665c89953b4/ghc" bb835c96/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bb835c96c3d962c2e08d23f6fb900665c89953b4" Keep top-level names in typed TH quotes alive Summary: When renaming untyped TH quotes, some care is taken to ensure that uses of top-level names in quotes do not have their bindings discarded during desugaring. The same care was not applied to typed TH quotes, so this patch brings the two into sync. Test Plan: make test TEST=T15783 Reviewers: bgamari, mpickering Reviewed By: mpickering Subscribers: mpickering, rwbarton, carter GHC Trac Issues: #15783 Differential Revision: https://phabricator.haskell.org/D5248 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 12:19:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 12:19:40 -0000 Subject: [GHC] #15781: Extraneous parentheses required to parse kind signature on the RHS of a type synonym In-Reply-To: <050.be8b8c1a94d013f8504422795938ca88@haskell.org> References: <050.be8b8c1a94d013f8504422795938ca88@haskell.org> Message-ID: <065.d3c3bfe3f8c3fe4886058adc251ed35d@haskell.org> #15781: Extraneous parentheses required to parse kind signature on the RHS of a type synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5245 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"79c641de60f1d6aa6f724d4fc49137ccbe3ab008/ghc" 79c641d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="79c641de60f1d6aa6f724d4fc49137ccbe3ab008" Fix #15781 by using ktypedocs on type synonym RHSes Summary: This is a follow-up to D5173, which permitted unparenthesized kind signatures in certain places. One place that appeared to be overlooked was the right-hand sides of type synonyms, which this patch addresses by introducing a `ktypedoc` parser production (which is to `ctypdoc` as `ktype` is to `ctype`) and using it in the right place. Test Plan: make test TEST="KindSigs T15781" Reviewers: harpocrates, bgamari Reviewed By: harpocrates Subscribers: rwbarton, mpickering, carter GHC Trac Issues: #15781 Differential Revision: https://phabricator.haskell.org/D5245 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 12:19:40 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 12:19:40 -0000 Subject: [GHC] #15792: TH reification prints invisible arguments to rank-2-kinded type as visible In-Reply-To: <050.e2a4d6e1194c7cbbd578f8d344e1ef48@haskell.org> References: <050.e2a4d6e1194c7cbbd578f8d344e1ef48@haskell.org> Message-ID: <065.23d25e3222bed2c24b5ae29f909e3a77@haskell.org> #15792: TH reification prints invisible arguments to rank-2-kinded type as visible -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5252 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"bfd93f90b6c63edf2790356e95feddf9898ec888/ghc" bfd93f9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bfd93f90b6c63edf2790356e95feddf9898ec888" Fix #15792 by not reifying invisible arguments in AppTys Summary: The `reifyType` function in `TcSplice` is carefully designed to avoid reifying visible arguments to `TyConApp`s. However, the same care was not given towards the `AppTy` case, which lead to #15792. This patch changes to the `AppTy` case of `reifyType` so that it consults the kind of the function type to determine which of the argument types are invisible (and therefore should be dropped) during reification. This required crafting a variant of `tyConArgFlags`, which I dubbed `appTyArgFlags`, that accept an arbitrary function `Type` instead of a `TyCon`. Test Plan: make test TEST=T15792 Reviewers: goldfire, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, rwbarton, carter GHC Trac Issues: #15792 Differential Revision: https://phabricator.haskell.org/D5252 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 12:24:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 12:24:26 -0000 Subject: [GHC] #10453: \case should trigger auto-multiline mode in ghci In-Reply-To: <044.2d59789cf30828fd243fec4509fe4124@haskell.org> References: <044.2d59789cf30828fd243fec4509fe4124@haskell.org> Message-ID: <059.a90bcab35ffa942d668dadba9ef1fc1f@haskell.org> #10453: \case should trigger auto-multiline mode in ghci -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T10453 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5236 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => ghci/scripts/T10453 * status: patch => closed * resolution: => fixed * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 12:25:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 12:25:59 -0000 Subject: [GHC] #13087: AlternativeLayoutRule breaks LambdaCase In-Reply-To: <049.ad6e034aa7e8b11be8486b436f8c84ca@haskell.org> References: <049.ad6e034aa7e8b11be8486b436f8c84ca@haskell.org> Message-ID: <064.17d720edfce036fdc69dafb6290b0653@haskell.org> #13087: AlternativeLayoutRule breaks LambdaCase -------------------------------------+------------------------------------- Reporter: ohhellojoe | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_compile/T13087 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5236 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => parser/should_compile/T13087 * resolution: => fixed * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 12:27:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 12:27:34 -0000 Subject: [GHC] #15781: Extraneous parentheses required to parse kind signature on the RHS of a type synonym In-Reply-To: <050.be8b8c1a94d013f8504422795938ca88@haskell.org> References: <050.be8b8c1a94d013f8504422795938ca88@haskell.org> Message-ID: <065.97d2a4aee60cccf455a8ea6389c420d6@haskell.org> #15781: Extraneous parentheses required to parse kind signature on the RHS of a type synonym -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | parser/should_compile/T15781 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5245 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => parser/should_compile/T15781 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 12:28:49 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 12:28:49 -0000 Subject: [GHC] #15783: Quoting an internal variable causes an error when splicing In-Reply-To: <049.e3b5744f03cf250cd18d056d6a8f061a@haskell.org> References: <049.e3b5744f03cf250cd18d056d6a8f061a@haskell.org> Message-ID: <064.0080679967226490e0d03caeb62a6d2e@haskell.org> #15783: Quoting an internal variable causes an error when splicing -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T15783 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5248 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * testcase: => th/T15783 * resolution: => fixed * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 12:29:54 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 12:29:54 -0000 Subject: [GHC] #15792: TH reification prints invisible arguments to rank-2-kinded type as visible In-Reply-To: <050.e2a4d6e1194c7cbbd578f8d344e1ef48@haskell.org> References: <050.e2a4d6e1194c7cbbd578f8d344e1ef48@haskell.org> Message-ID: <065.ffca56b7092c607dab866066a263f8f2@haskell.org> #15792: TH reification prints invisible arguments to rank-2-kinded type as visible -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T15792 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5252 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => th/T15792 * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 12:46:07 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 12:46:07 -0000 Subject: [GHC] #15793: Type family doesn't reduce with visible kind application In-Reply-To: <051.61f364214000f10c10115e9460ffba57@haskell.org> References: <051.61f364214000f10c10115e9460ffba57@haskell.org> Message-ID: <066.e3f3c2ba30770b467c0f3480dc82dce3@haskell.org> #15793: Type family doesn't reduce with visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15740 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15740 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 12:46:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 12:46:20 -0000 Subject: [GHC] #15740: Type family with higher-rank result is too accepting In-Reply-To: <047.98bb6600d0afd0d0f5c82db2394db54f@haskell.org> References: <047.98bb6600d0afd0d0f5c82db2394db54f@haskell.org> Message-ID: <062.9de0bad2225a4189f85f9c14c3bd8601@haskell.org> #15740: Type family with higher-rank result is too accepting -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeFamilies, | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15793 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15793 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 12:47:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 12:47:20 -0000 Subject: [GHC] #10453: \case should trigger auto-multiline mode in ghci In-Reply-To: <044.2d59789cf30828fd243fec4509fe4124@haskell.org> References: <044.2d59789cf30828fd243fec4509fe4124@haskell.org> Message-ID: <059.2b20c455cfd88cb2b0d1fd4de1a4754e@haskell.org> #10453: \case should trigger auto-multiline mode in ghci -------------------------------------+------------------------------------- Reporter: dmwit | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/scripts/T10453 Blocked By: | Blocking: Related Tickets: #13087 | Differential Rev(s): Phab:D5236 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #13087 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 12:47:35 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 12:47:35 -0000 Subject: [GHC] #13087: AlternativeLayoutRule breaks LambdaCase In-Reply-To: <049.ad6e034aa7e8b11be8486b436f8c84ca@haskell.org> References: <049.ad6e034aa7e8b11be8486b436f8c84ca@haskell.org> Message-ID: <064.515abc784cb0bfd2f6a6406dd19139eb@haskell.org> #13087: AlternativeLayoutRule breaks LambdaCase -------------------------------------+------------------------------------- Reporter: ohhellojoe | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_compile/T13087 Blocked By: | Blocking: Related Tickets: #10453 | Differential Rev(s): Phab:D5236 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #10453 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 13:19:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 13:19:27 -0000 Subject: [GHC] #12677: Type equality in constraint not used? In-Reply-To: <051.fe74d91fb30a3bb9a0169149567d721f@haskell.org> References: <051.fe74d91fb30a3bb9a0169149567d721f@haskell.org> Message-ID: <066.3e34427f4258364268f84c5c8886c9bf@haskell.org> #12677: Type equality in constraint not used? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13337, #15710 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > The problem is that this would require using the equality proof for Type ~ k as the body of η Doesn't coercion quantification help with this? (Though as so often, I'm worried about the difference between `(Type ~ k)` and `(Type ~# k)`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 13:20:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 13:20:45 -0000 Subject: [GHC] #15793: Type family doesn't reduce with visible kind application In-Reply-To: <051.61f364214000f10c10115e9460ffba57@haskell.org> References: <051.61f364214000f10c10115e9460ffba57@haskell.org> Message-ID: <066.994bc9e0d22759b8a84a502b0830450c@haskell.org> #15793: Type family doesn't reduce with visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15740 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think this is likely #15740, but you're right that I was too hasty in closing this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 13:21:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 13:21:45 -0000 Subject: [GHC] #12677: Type equality in constraint not used? In-Reply-To: <051.fe74d91fb30a3bb9a0169149567d721f@haskell.org> References: <051.fe74d91fb30a3bb9a0169149567d721f@haskell.org> Message-ID: <066.2d9a4d1cfa3ecff7f6ba8dc6dc16b2d5@haskell.org> #12677: Type equality in constraint not used? -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13337, #15710 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think this is #15710. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 14:09:44 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 14:09:44 -0000 Subject: [GHC] #15778: GHC HEAD-only panic (zonkTcTyVarToTyVar) In-Reply-To: <050.3cd9086426b45d98a8ca89f3f02fc672@haskell.org> References: <050.3cd9086426b45d98a8ca89f3f02fc672@haskell.org> Message-ID: <065.866049d8c7f017794025e86b4015d279@haskell.org> #15778: GHC HEAD-only panic (zonkTcTyVarToTyVar) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): The following code does //not// compile on earlier versions of GHC, but it is the simplest way to trigger the panic that I've discovered: {{{#!hs {-# LANGUAGE PolyKinds, ScopedTypeVariables #-} foo (_ :: (a :: probablyABadIdea)) = () }}} {{{ $ /opt/ghc/head/bin/ghc Bug.hs [1 of 1] Compiling Main ( Bug.hs, Bug.o ) ghc: panic! (the 'impossible' happened) (GHC version 8.7.20181015 for x86_64-unknown-linux): zonkTcTyVarToTyVar probablyABadIdea_arQ[tau:1] TYPE t_arX[tau:1] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcMType.hs:1627:34 in ghc:TcMType }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 15:23:31 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 15:23:31 -0000 Subject: [GHC] #15778: GHC HEAD-only panic (zonkTcTyVarToTyVar) In-Reply-To: <050.3cd9086426b45d98a8ca89f3f02fc672@haskell.org> References: <050.3cd9086426b45d98a8ca89f3f02fc672@haskell.org> Message-ID: <065.745a5d909589ce2e275e9c6af842bdab@haskell.org> #15778: GHC HEAD-only panic (zonkTcTyVarToTyVar) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I know what is happening here. In `tcHsPatSigType` we have {{{ mk_tv_pair tv = do { tv' <- zonkTcTyVarToTyVar tv ; return (tyVarName tv, tv') } }}} But now the tyvar might have unified with a ''type'' not a type ''variable''. And in these cases it does. I think that the right thing is simply to remove the zonk. I'll act on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 15:39:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 15:39:26 -0000 Subject: [GHC] #15767: "StgCmmEnv: variable not found" with FunctionalDependencies and FlexibleContexts In-Reply-To: <045.2239633dfbb009c41762262dc87d11d7@haskell.org> References: <045.2239633dfbb009c41762262dc87d11d7@haskell.org> Message-ID: <060.94f836cc95c80f5142f90e49c8a239e5@haskell.org> #15767: "StgCmmEnv: variable not found" with FunctionalDependencies and FlexibleContexts -------------------------------------+------------------------------------- Reporter: roland | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.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: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"6b1102e2cfcffb265fd33cf8a99ab5e6b3f14906/ghc" 6b1102e2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6b1102e2cfcffb265fd33cf8a99ab5e6b3f14906" Report a Wanted error even if there are Given ones We suppress some Given errors; see Note [Given errors] in TcErrors. But we must be careful not to suppress Wanted errors because of the presence of these Given errors -- else we might allow compilation to bogusly proceed The rubber hits the road in TcRnTypes.insolubleCt, where we don't want to treat Givens as insoluble, nor (and this is the new bit) Deriveds that arise from Givens. See Note [Given insolubles] in TcRnTypes. This fixes #15767. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 15:39:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 15:39:26 -0000 Subject: [GHC] #15694: GHC panic from pattern synonym, "Type-correct unfilled coercion hole" In-Reply-To: <051.eef99d48758aa3732858d34fad575ab5@haskell.org> References: <051.eef99d48758aa3732858d34fad575ab5@haskell.org> Message-ID: <066.69482b05d37515e0286e9643bdd260ee@haskell.org> #15694: GHC panic from pattern synonym, "Type-correct unfilled coercion hole" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"7ea714cd8d64dd0a7646d71d45e18c9f6a3527cb/ghc" 7ea714c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7ea714cd8d64dd0a7646d71d45e18c9f6a3527cb" Solve equalities in a pattern signature Trac #15694 showed that we were forgetting to solve the equalities of a pattern signature until too late. Result: WARNINGs and a panic: "Type-correct unfilled coercion hole" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 15:39:26 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 15:39:26 -0000 Subject: [GHC] #15648: Core Lint error with source-level unboxed equality In-Reply-To: <050.b1c8c377aa63cdac74b3d157d20320e2@haskell.org> References: <050.b1c8c377aa63cdac74b3d157d20320e2@haskell.org> Message-ID: <065.c4d8ee6799cc321f2ff883d31cd600c7@haskell.org> #15648: Core Lint error with source-level unboxed equality -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15209 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"0faf7fd3e6c652575af9993787f07cad86f452f6/ghc" 0faf7fd3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0faf7fd3e6c652575af9993787f07cad86f452f6" Refactor the treatment of predicate types Trac #15648 showed that GHC was a bit confused about the difference between the types for * Predicates * Coercions * Evidence (in the typechecker constraint solver) This patch cleans it up. See especially Type.hs Note [Types for coercions, predicates, and evidence] Particular changes * Coercion types (a ~# b) and (a ~#R b) are not predicate types (so isPredTy reports False for them) and are not implicitly instantiated by the type checker. This is a real change, but it consistently reflects that fact that (~#) and (~R#) really are different from predicates. * isCoercionType is renamed to isCoVarType * During type inference, simplifyInfer, we do /not/ want to infer a constraint (a ~# b), because that is no longer a predicate type. So we 'lift' it to (a ~ b). See TcType Note [Lift equality constaints when quantifying] * During type inference for pattern synonyms, we need to 'lift' provided constraints of type (a ~# b) to (a ~ b). See Note [Equality evidence in pattern synonyms] in PatSyn * But what about (forall a. Eq a => a ~# b)? Is that a predicate type? No -- it does not have kind Constraint. Is it an evidence type? Perhaps, but awkwardly so. In the end I decided NOT to make it an evidence type, and to ensure the the type inference engine never meets it. This made me /simplify/ the code in TcCanonical.makeSuperClasses; see TcCanonical Note [Equality superclasses in quantified constraints] Instead I moved the special treatment for primitive equality to TcInteract.doTopReactOther. See TcInteract Note [Looking up primitive equalities in quantified constraints] Also see Note [Evidence for quantified constraints] in Type. All this means I can have isEvVarType ty = isCoVarType ty || isPredTy ty which is nice. All in all, rather a lot of work for a small refactoring, but I think it's a real improvement. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 15:42:08 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 15:42:08 -0000 Subject: [GHC] #15694: GHC panic from pattern synonym, "Type-correct unfilled coercion hole" In-Reply-To: <051.eef99d48758aa3732858d34fad575ab5@haskell.org> References: <051.eef99d48758aa3732858d34fad575ab5@haskell.org> Message-ID: <066.8885cbf1021ec48ac9f7d64cf9240945@haskell.org> #15694: GHC panic from pattern synonym, "Type-correct unfilled coercion hole" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | patsyn/should_fail/T15694 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => patsyn/should_fail/T15694 * status: new => merge Comment: Thanks -- fixed! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 15:42:50 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 15:42:50 -0000 Subject: [GHC] #15767: "StgCmmEnv: variable not found" with FunctionalDependencies and FlexibleContexts In-Reply-To: <045.2239633dfbb009c41762262dc87d11d7@haskell.org> References: <045.2239633dfbb009c41762262dc87d11d7@haskell.org> Message-ID: <060.89730981febebc69f0e0ccb6a6b27e8d@haskell.org> #15767: "StgCmmEnv: variable not found" with FunctionalDependencies and FlexibleContexts -------------------------------------+------------------------------------- Reporter: roland | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_fail/T15767 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => typecheck/should_fail/T15767 Comment: Thanks -- fixed! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 15:56:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 15:56:45 -0000 Subject: [GHC] #15796: Core Lint error In-Reply-To: <051.693414c0b173ccf97801ac65c4aeaf38@haskell.org> References: <051.693414c0b173ccf97801ac65c4aeaf38@haskell.org> Message-ID: <066.40193d9bf962135dbcc57efad97d8210@haskell.org> #15796: Core Lint error -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeApplications Comment: This is related to Visible Kind Application, correct? Which is not yet committed to HEAD? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 15:58:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 15:58:13 -0000 Subject: [GHC] #15796: Core Lint error with visible kind application (was: Core Lint error) In-Reply-To: <051.693414c0b173ccf97801ac65c4aeaf38@haskell.org> References: <051.693414c0b173ccf97801ac65c4aeaf38@haskell.org> Message-ID: <066.d33cf9e62366e07d67a6428f992b21db@haskell.org> #15796: Core Lint error with visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12045 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * cc: mnguyen (added) * related: => #12045 Comment: Yes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 16:28:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 16:28:42 -0000 Subject: [GHC] #15648: Core Lint error with source-level unboxed equality In-Reply-To: <050.b1c8c377aa63cdac74b3d157d20320e2@haskell.org> References: <050.b1c8c377aa63cdac74b3d157d20320e2@haskell.org> Message-ID: <065.576a69ac23fa5c28085733d031e8291b@haskell.org> #15648: Core Lint error with source-level unboxed equality -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15209 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Good news—the original program is now rejected: {{{ $ ~/Software/ghc/inplace/bin/ghc-stage2 Bug.hs[1 of 2] Compiling Foo ( Foo.hs, Foo.o ) [2 of 2] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:23:21: error: • Couldn't match type ‘(a0 ~ b0) -> JankyEquality a0 b0’ with ‘JankyEquality a a’ Expected type: JankyEquality a b Actual type: (a0 ~ b0) -> JankyEquality a0 b0 • Probable cause: ‘Jank’ is applied to too few arguments In the expression: Jank In an equation for ‘legitToJank’: legitToJank Legit = Jank • Relevant bindings include legitToJank :: LegitEquality a b -> JankyEquality a b (bound at Bug.hs:23:1) | 23 | legitToJank Legit = Jank | ^^^^ Bug.hs:30:10: error: • Couldn't match expected type ‘(a ~ b) -> b ~ a’ with actual type ‘b ~ a’ • In the expression: unJank $ legitToJank $ mkLegit @b @a In an equation for ‘ueqSym’: ueqSym = unJank $ legitToJank $ mkLegit @b @a • Relevant bindings include ueqSym :: (a ~ b) -> b ~ a (bound at Bug.hs:30:1) | 30 | ueqSym = unJank $ legitToJank $ mkLegit @b @a | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ }}} You can still use `$ueqT a b` as a visible argument to a function, but it appears to be functionally inert now, since you can't bring equalities into scope with it anymore (at least, not as far as I can tell). Should we claim victory on this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 16:30:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 16:30:59 -0000 Subject: [GHC] #15648: Core Lint error with source-level unboxed equality In-Reply-To: <050.b1c8c377aa63cdac74b3d157d20320e2@haskell.org> References: <050.b1c8c377aa63cdac74b3d157d20320e2@haskell.org> Message-ID: <065.eb8e38d895fc3265a59cace2babb3b46@haskell.org> #15648: Core Lint error with source-level unboxed equality -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15209 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think so. I'm just about to add a test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 16:58:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 16:58:34 -0000 Subject: [GHC] #14859: Allow explicit impredicativity In-Reply-To: <046.bce52cd0cbee25c5f867b88fe7e6b527@haskell.org> References: <046.bce52cd0cbee25c5f867b88fe7e6b527@haskell.org> Message-ID: <061.5b08dc1404659d8609f2300061de947a@haskell.org> #14859: Allow explicit impredicativity -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Should we allow visible application of polytypes //carte blanche//? What happens when visible kind application rolls in and we can write this? {{{#!hs hm :: forall (f :: forall a. a -> a). Proxy @(forall a. a -> a) f hm = Proxy }}} The type `Proxy @(forall a. a -> a) f` seems to have a strongly impredicative flavor, but this is only a hunch. What do others think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 17:16:13 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 17:16:13 -0000 Subject: [GHC] #15559: fromJust has no HasCallStack In-Reply-To: <046.0c0fc309394993486a792a626e8db1e1@haskell.org> References: <046.0c0fc309394993486a792a626e8db1e1@haskell.org> Message-ID: <061.b51082fd6bc76b3f9dc78006e133a86c@haskell.org> #15559: fromJust has no HasCallStack -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D5256 Wiki Page: | -------------------------------------+------------------------------------- Changes (by fangyizhou): * status: new => patch * differential: => D5256 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 18:15:02 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 18:15:02 -0000 Subject: [GHC] #15733: Several links in GHC.Exts.Heap documentation are broken In-Reply-To: <049.e71035ad0f7b2d4e40b57a77fc8c9c35@haskell.org> References: <049.e71035ad0f7b2d4e40b57a77fc8c9c35@haskell.org> Message-ID: <064.e9381f134266532de0c8adbca6b133d3@haskell.org> #15733: Several links in GHC.Exts.Heap documentation are broken -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D5257 Wiki Page: | -------------------------------------+------------------------------------- Changes (by fangyizhou): * status: new => patch * differential: => D5257 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 18:30:30 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 18:30:30 -0000 Subject: [GHC] #15798: Flag to warn when deriving strategy is not explicitly specified Message-ID: <049.5f2057353415a55d9c8168e9d08cdca6@haskell.org> #15798: Flag to warn when deriving strategy is not explicitly specified -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In my code, I aim to always specify deriving strategies. I would like to add a flag `-fwarn-unspecified-deriving` that would cause a warning to be emitted when someone wrote this: {{{ newtype Foo = Foo Int deriving (Show) }}} The user would be required to instead write: {{{ newtype Foo = Foo Int deriving newtype (Show) }}} Or they could use `stock` if that was the behavior they wanted. This flag would be off by default. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 18:38:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 18:38:00 -0000 Subject: [GHC] #15798: Flag to warn when deriving strategy is not explicitly specified In-Reply-To: <049.5f2057353415a55d9c8168e9d08cdca6@haskell.org> References: <049.5f2057353415a55d9c8168e9d08cdca6@haskell.org> Message-ID: <064.3b63227f10b12c2dee5e44a963b3d81e@haskell.org> #15798: Flag to warn when deriving strategy is not explicitly specified -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by andrewthad): * cc: RyanGlScott (added) Comment: Ryan, if you to see if you had any thoughts on the name of the flag, I am welcome to suggestions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 18:41:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 18:41:14 -0000 Subject: [GHC] #15798: Flag to warn when deriving strategy is not explicitly specified In-Reply-To: <049.5f2057353415a55d9c8168e9d08cdca6@haskell.org> References: <049.5f2057353415a55d9c8168e9d08cdca6@haskell.org> Message-ID: <064.1ca09e4289a8c6d166dd0904501d4fc0@haskell.org> #15798: Flag to warn when deriving strategy is not explicitly specified -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): One other suggestion I've heard is `-Wimplicit-deriving-strategies` (mirroring the name of the `ImplicitPrelude` extension). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 18:51:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 18:51:20 -0000 Subject: [GHC] #15798: Flag to warn when deriving strategy is not explicitly specified In-Reply-To: <049.5f2057353415a55d9c8168e9d08cdca6@haskell.org> References: <049.5f2057353415a55d9c8168e9d08cdca6@haskell.org> Message-ID: <064.e63bc016afafc173de14e877abed1d03@haskell.org> #15798: Flag to warn when deriving strategy is not explicitly specified -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by andrewthad): That does sound better. I'll go with that. And I'm glad to know that someone else has thought about such a flag before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 19:14:05 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 19:14:05 -0000 Subject: [GHC] #15796: Core Lint error with visible kind application In-Reply-To: <051.693414c0b173ccf97801ac65c4aeaf38@haskell.org> References: <051.693414c0b173ccf97801ac65c4aeaf38@haskell.org> Message-ID: <066.8fad6e080d5fe1603db6510688b26a38@haskell.org> #15796: Core Lint error with visible kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12045 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Yes it is Simon this uses [https://phabricator.haskell.org/D5229 D5229 (Visible kind application)]. Here is another program that triggers a similar error {{{#!hs {-# Language DataKinds #-} {-# Language TypeOperators #-} {-# Language PolyKinds #-} {-# Language GADTs #-} {-# Language TypeFamilies #-} {-# Options_GHC -dcore-lint #-} import qualified GHC.TypeLits as TypeLits import Data.Kind data OP a = Op a type family UnOp (op_a :: OP a) :: a where UnOp (Op a) = a class Ríki (obj :: Type) where type (-->) :: OP obj -> obj -> Type data (<=) :: OP TypeLits.Nat -> TypeLits.Nat -> Type where LessThan :: TypeLits.KnownNat (UnOp op_a) => op_a <= b instance Ríki TypeLits.Nat where type (-->) = (<=) }}} {{{ $ ghci -ignore-dot-ghci 572_bug.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 572_bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181017 for x86_64-unknown-linux): Core Lint error : warning: In the type ‘(<=)’ Found TcTyCon: <=[tc] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/typecheck/FamInst.hs:171:31 in ghc:FamInst Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 20:08:09 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 20:08:09 -0000 Subject: [GHC] #15799: GHC panic (and warnings) Message-ID: <051.9f403c90f37670c8d3e47780b16a76ec@haskell.org> #15799: GHC panic (and warnings) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- On the [https://phabricator.haskell.org/D5229 visible kind application] differential, {{{#!hs {-# Language CPP #-} {-# Language DataKinds #-} {-# Language RankNTypes #-} {-# Language PatternSynonyms #-} {-# Language TypeOperators #-} {-# Language PolyKinds #-} {-# Language GADTs #-} {-# Language TypeFamilies #-} {-# Language TypeApplications #-} {-# Language FlexibleContexts #-} {-# Language FlexibleInstances #-} {-# Language InstanceSigs #-} import qualified GHC.TypeLits as TypeLits import GHC.TypeLits (Nat, KnownNat) import Data.Kind data Op obj = Op obj type family UnOp (op_a :: Op obj) :: obj where UnOp ('Op obj) = obj class Ríki (obj :: Type) where type (-->) :: Op obj -> obj -> Type type (<--) :: obj -> Op obj -> Type unop :: forall (a :: obj) (b :: obj). (a <-- 'Op b) -> ('Op b --> a) data (<=) :: Op Nat -> Nat -> Type where LessThan :: (KnownNat (UnOp op_a), KnownNat b, UnOp op_a TypeLits.<= b) => (op_a <= b) newtype (>=) :: Nat -> Op Nat -> Type where Y :: (a <= b) -> (b >= a) instance Ríki Nat where type (-->) = (<=) type (<--) = (>=) unop :: (a >= b) -> (b <= a) unop GreaterThan = LessThan pattern GreaterThan :: () => (KnownNat (UnOp b), KnownNat a, UnOp b <= a) => a >= b pattern GreaterThan = Y LessThan }}} {{{ $ ghci -ignore-dot-ghci 573_bug.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 573_bug.hs, interpreted ) WARNING: file compiler/types/TyCoRep.hs, line 2567 in_scope InScope {b_a1Em a_a1En} tenv [a1Em :-> b_a1Em[sk:0], a1En :-> a_a1En[sk:0]] cenv [] tys [KnownNat (UnOp b_a1Em[sk:1]), KnownNat a_a1En[sk:1], (UnOp b_a1Em[sk:1] |> {co_a1HN}) <= a_a1En[sk:1]] cos [] needInScope [a1HN :-> co_a1HN] WARNING: file compiler/types/TyCoRep.hs, line 2567 in_scope InScope {b_a1Jo a_a1Jp} tenv [a1Em :-> b_a1Jo[tau:3], a1En :-> a_a1Jp[tau:3]] cenv [] tys [KnownNat (UnOp b_a1Em), KnownNat a_a1En, (UnOp b_a1Em |> {co_a1HN}) <= a_a1En] cos [] needInScope [a1HN :-> co_a1HN] ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181017 for x86_64-unknown-linux): tcEvVarPred irred_a1Js (UnOp b_a1Jo[tau:3] |> {co_a1HN}) <= a_a1Jp[tau:3] Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/typecheck/TcType.hs:1998:20 in ghc:TcType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 20:11:34 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 20:11:34 -0000 Subject: [GHC] #15799: GHC panic (and warnings) In-Reply-To: <051.9f403c90f37670c8d3e47780b16a76ec@haskell.org> References: <051.9f403c90f37670c8d3e47780b16a76ec@haskell.org> Message-ID: <066.889034666724c22ffa04ecd3081881d4@haskell.org> #15799: GHC panic (and warnings) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): This works again if you qualify `UnOp b TypeLits.<= a` in the pattern signature for `GreaterThan`, or remove it entirely -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 20:33:01 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 20:33:01 -0000 Subject: [GHC] #15645: TypeChecking of Monad patterns incorrect with RebindableSyntax and OverloadedStrings In-Reply-To: <051.1afac0be4b689267d905f3e66b5a2d7d@haskell.org> References: <051.1afac0be4b689267d905f3e66b5a2d7d@haskell.org> Message-ID: <066.c8c8371af6f96b69568662a503660623@haskell.org> #15645: TypeChecking of Monad patterns incorrect with RebindableSyntax and OverloadedStrings -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: shayne- | fletcher-da Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D5251 Wiki Page: | -------------------------------------+------------------------------------- Changes (by NeilMitchell): * differential: => D5251 Comment: Proposal was accepted. Patch submitted at https://phabricator.haskell.org/D5251 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 21:37:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 21:37:43 -0000 Subject: [GHC] #15800: Overlapping instances error with single instance Message-ID: <045.2e1fce9b901f82fa18c2e6cad6f62eea@haskell.org> #15800: Overlapping instances error with single instance -------------------------------------+------------------------------------- Reporter: roland | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 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: -------------------------------------+------------------------------------- {{{ {-# LANGUAGE MultiParamTypeClasses, FlexibleContexts, FlexibleInstances #-} module Bug where class C a b instance C a Int x :: () x = undefined :: C a Int => () }}} {{{ ghc -c Bug.hs Bug.hs:10:18: error: • Overlapping instances for C a0 Int Matching givens (or their superclasses): C a Int bound by an expression type signature: forall a. C a Int => () at Bug.hs:10:18-30 Matching instances: instance C a Int -- Defined at Bug.hs:7:10 (The choice depends on the instantiation of ‘a0’) • In the ambiguity check for an expression type signature To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In an expression type signature: C a Int => () In the expression: undefined :: C a Int => () | 10 | x = undefined :: C a Int => () | ^^^^^^^^^^^^^ }}} The "matching instances" bit of the error messages only lists a single instance. Doesn't it take at least two instances for something to overlap? Also, following the algorithm laid out in the user guide (section "Overlapping Instances"), it appears this program should be accepted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 22:19:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 22:19:00 -0000 Subject: [GHC] #15733: Several links in GHC.Exts.Heap documentation are broken In-Reply-To: <049.e71035ad0f7b2d4e40b57a77fc8c9c35@haskell.org> References: <049.e71035ad0f7b2d4e40b57a77fc8c9c35@haskell.org> Message-ID: <064.0aabe1c7977105dedd2164825f0e7ec7@haskell.org> #15733: Several links in GHC.Exts.Heap documentation are broken -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D5257 Wiki Page: | -------------------------------------+------------------------------------- Comment (by fangyizhou): I grepped through ghc git repo and submitted Phab:D5257 Phab:D5262 Phab:D5261 Phab:D5260 Phab:D5259 https://github.com/haskell/win32/pull/116 and https://github.com/haskell/bytestring/pull/166 I think that's all hackage.haskell.org/trac converted to ghc.haskell.org/trac -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 23:03:43 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 23:03:43 -0000 Subject: [GHC] #15801: "ASSERT failed!" with visible kind applications Message-ID: <051.20ccd7e9fd8211110da568093d1b0ef6@haskell.org> #15801: "ASSERT failed!" with visible kind applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Sorry for the workload mnguyen. This gives a very short error (using diff for visible kind application: https://phabricator.haskell.org/D5229) {{{#!hs {-# Language CPP #-} {-# Language QuantifiedConstraints #-} {-# Language TypeApplications #-} {-# Language PolyKinds #-} {-# Language TypeOperators #-} {-# Language DataKinds #-} {-# Language TypeFamilies #-} {-# Language TypeSynonymInstances #-} {-# Language FlexibleInstances #-} {-# Language GADTs #-} {-# Language UndecidableInstances #-} {-# Language MultiParamTypeClasses #-} {-# Language FlexibleContexts #-} import Data.Coerce import Data.Kind type Cat ob = ob -> ob -> Type type Obj = Type class Coercible (op_a --> b) (b <-- op_a) => (op_a -#- b) instance Coercible (op_a --> b) (b <-- op_a) => (op_a -#- b) class (forall (op_a :: obj) (b :: obj). op_a -#- b) => OpOpNoOp obj instance (forall (op_a :: obj) (b :: obj). op_a -#- b) => OpOpNoOp obj class Ríki (obj :: Obj) where type (-->) :: obj -> obj -> Type ið :: a --> (a::obj) class OpOpNoOp obj => OpRíki (obj :: Obj) where type (<--) :: obj -> obj -> Type data Op a = Op a type family UnOp op where UnOp ('Op obj) = obj newtype Y :: Cat (Op a) where Y :: (UnOp b --> UnOp a) -> Y a b instance Ríki Type where type (-->) = (->) ið x = x instance OpRíki (Op Type) where type (<--) @(Op Type) = Y @Type }}} {{{ $ ghci -ignore-dot-ghci 577.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 577.hs, interpreted ) *** Exception: ASSERT failed! file compiler/typecheck/TcFlatten.hs, line 1285 > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 23:07:04 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 23:07:04 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow In-Reply-To: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> References: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> Message-ID: <057.a24401b5b6b4c6be46c193ae10dfd9aa@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof recomp007 | space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrp): {{{ === STAGE 1 TESTS ==== SUMMARY for test run started at Thu Oct 25 00:01:26 2018 BST 0:00:05 spent to go through 2 total tests, which gave rise to 10 test cases, of which 0 were skipped 0 had missing libraries 10 expected passes 0 expected failures 0 caused framework failures 0 caused framework warnings 0 unexpected passes 0 unexpected failures 0 unexpected stat failures ==== STAGE 2 TESTS ==== Unexpected results from: TEST="CPUTime001 EtaExpandLevPoly T14936 T2783 T3816 T4334 T7919 haddock.Cabal haddock.base haddock.compiler hpc_fork recomp007 space_leak_001 user001" SUMMARY for test run started at Wed Oct 24 22:57:00 2018 BST 1:04:23 spent to go through 6614 total tests, which gave rise to 29751 test cases, of which 5922 were skipped 256 had missing libraries 23277 expected passes 257 expected failures 0 caused framework failures 0 caused framework warnings 3 unexpected passes 23 unexpected failures 13 unexpected stat failures Unexpected passes: /tmp/ghctest-49fz3kus/test spaces/rts/T2783.run T2783 [unexpected] (threaded1) /tmp/ghctest-49fz3kus/test spaces/typecheck/should_run/EtaExpandLevPoly.run EtaExpandLevPoly [unexpected] (profasm) /tmp/ghctest-49fz3kus/test spaces/typecheck/should_run/EtaExpandLevPoly.run EtaExpandLevPoly [unexpected] (profthreaded) Unexpected failures: /tmp/ghctest-49fz3kus/test spaces/driver/recomp007/recomp007.run recomp007 [bad stderr] (normal) /tmp/ghctest-49fz3kus/test spaces/rts/T7919.run T7919 [bad exit code] (ghci) /tmp/ghctest-49fz3kus/test spaces/libraries/base/tests/CPUTime001.run CPUTime001 [bad stdout] (threaded2) /tmp/ghctest-49fz3kus/test spaces/libraries/hpc/tests/fork/hpc_fork.run hpc_fork [bad heap profile] (profasm) /tmp/ghctest-49fz3kus/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (normal) /tmp/ghctest-49fz3kus/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (hpc) /tmp/ghctest-49fz3kus/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (optasm) /tmp/ghctest-49fz3kus/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (profasm) /tmp/ghctest-49fz3kus/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (threaded1) /tmp/ghctest-49fz3kus/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (threaded2) /tmp/ghctest-49fz3kus/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (dyn) /tmp/ghctest-49fz3kus/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (profthreaded) /tmp/ghctest-49fz3kus/test spaces/libraries/unix/tests/user001.run user001 [bad stdout] (optllvm) /tmp/ghctest-49fz3kus/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (normal) /tmp/ghctest-49fz3kus/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (hpc) /tmp/ghctest-49fz3kus/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (optasm) /tmp/ghctest-49fz3kus/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (profasm) /tmp/ghctest-49fz3kus/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (ghci) /tmp/ghctest-49fz3kus/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (threaded1) /tmp/ghctest-49fz3kus/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (threaded2) /tmp/ghctest-49fz3kus/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (dyn) /tmp/ghctest-49fz3kus/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (profthreaded) /tmp/ghctest-49fz3kus/test spaces/libraries/unix/tests/T3816.run T3816 [bad exit code] (optllvm) Unexpected stat failures: /tmp/ghctest-49fz3kus/test spaces/perf/haddock/haddock.base.run haddock.base [stat not good enough] (normal) /tmp/ghctest-49fz3kus/test spaces/perf/haddock/haddock.Cabal.run haddock.Cabal [stat not good enough] (normal) /tmp/ghctest-49fz3kus/test spaces/perf/haddock/haddock.compiler.run haddock.compiler [stat not good enough] (normal) /tmp/ghctest-49fz3kus/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (hpc) /tmp/ghctest-49fz3kus/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (profasm) /tmp/ghctest-49fz3kus/test spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (hpc) /tmp/ghctest-49fz3kus/test spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (optasm) /tmp/ghctest-49fz3kus/test spaces/perf/space_leaks/T4334.run T4334 [stat not good enough] (threaded2) /tmp/ghctest-49fz3kus/test spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (dyn) /tmp/ghctest-49fz3kus/test spaces/perf/space_leaks/space_leak_001.run space_leak_001 [stat too good] (optllvm) /tmp/ghctest-49fz3kus/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (threaded1) /tmp/ghctest-49fz3kus/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (threaded2) /tmp/ghctest-49fz3kus/test spaces/perf/should_run/T14936.run T14936 [stat not good enough] (profthreaded) == Start post-testsuite package check GHC package manager version 8.7.20181024 Timestamp 2018-10-24 21:56:55.28783947 UTC for /home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181024/package.conf.d/package.cache using cache: /home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181024/package.conf.d/package.cache db stack: ["/home/jrp/.ghc/x86_64-linux-8.7.20181024/package.conf.d","/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181024/package.conf.d"] flag db stack: ["/home/jrp/.ghc/x86_64-linux-8.7.20181024/package.conf.d","/home/jrp/Projects/ghc/bindisttest/install dir/lib/ghc-8.7.20181024/package.conf.d"] == End post-testsuite package check ------------------------------------------------------------------- Oops! Looks like you have some unexpected test results or framework failures. Please fix them before pushing/sending patches. ------------------------------------------------------------------- }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 23:09:29 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 23:09:29 -0000 Subject: [GHC] #15801: "ASSERT failed!" with visible kind applications In-Reply-To: <051.20ccd7e9fd8211110da568093d1b0ef6@haskell.org> References: <051.20ccd7e9fd8211110da568093d1b0ef6@haskell.org> Message-ID: <066.c0d2c2ca2de13e3b36da6cac5065d86d@haskell.org> #15801: "ASSERT failed!" with visible kind applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Can also be triggered with {{{ >> :t coerce @(Y @Type _ _) *** Exception: ASSERT failed! file compiler/typecheck/TcFlatten.hs, line 1285 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 24 23:53:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Oct 2018 23:53:42 -0000 Subject: [GHC] #15799: GHC panic (and warnings) In-Reply-To: <051.9f403c90f37670c8d3e47780b16a76ec@haskell.org> References: <051.9f403c90f37670c8d3e47780b16a76ec@haskell.org> Message-ID: <066.965a51bd2b5b646c4b57f8f3e90aee02@haskell.org> #15799: GHC panic (and warnings) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #12045 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * cc: mnguyen (added) * related: => #12045 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 00:01:08 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 00:01:08 -0000 Subject: [GHC] #15802: Inlining of constant fails when both cross-module and recursive Message-ID: <046.641b42683ec0810e689b9d1da7b20b44@haskell.org> #15802: Inlining of constant fails when both cross-module and recursive -------------------------------------+------------------------------------- Reporter: j6carey | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When an inline recursive function is applied to a constant, that application may reduce if it is in the same module, but will not reduce when in a different module. (Naturally, this harms the ability to split a program into modules while retaining efficiency.) For example, consider the following files: T1.hs: {{{#!hs module T1 where data IntList = Nil | Cons Int IntList mapIntList :: (Int -> Int) -> IntList -> IntList mapIntList f Nil = Nil mapIntList f (Cons x xs) = Cons (f x) (mapIntList f xs) {-# INLINE mapIntList #-} mappedNil :: IntList mappedNil = mapIntList id Nil }}} T2.hs: {{{#!hs module T2 where data IntList = Nil | Cons Int IntList mapIntList :: (Int -> Int) -> IntList -> IntList mapIntList f Nil = Nil mapIntList f (Cons x xs) = Cons (f x) (mapIntList f xs) {-# INLINE mapIntList #-} }}} T3.hs: {{{#!hs module T3 where import T2 mappedNil :: IntList mappedNil = mapIntList id Nil }}} The program built from T1.hs should be equivalent to the one built from T2.hs and T3.hs; however, the core output from GHC 8.6.1 with -O2 differs significantly. In the single-module case we obtain: {{{#!hs mappedNil = T1.Nil }}} Whereas in the two-module case we see: {{{#!hs mappedNil = mapIntList (id @ Int) T2.Nil }}} Recursion is relevant; the problem disappears if we make this change: {{{#!hs data IntList = Nil | Cons Int Int mapIntList :: (Int -> Int) -> IntList -> IntList mapIntList f Nil = Nil mapIntList f (Cons x xs) = Cons (f x) (f xs) {-# INLINE mapIntList #-} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 00:01:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 00:01:36 -0000 Subject: [GHC] #15802: Inlining of constant fails when both cross-module and recursive In-Reply-To: <046.641b42683ec0810e689b9d1da7b20b44@haskell.org> References: <046.641b42683ec0810e689b9d1da7b20b44@haskell.org> Message-ID: <061.af035e7fa1d31a78285cfca0f35897b9@haskell.org> #15802: Inlining of constant fails when both cross-module and recursive -------------------------------------+------------------------------------- Reporter: j6carey | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by j6carey): * Attachment "T1.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 00:01:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 00:01:47 -0000 Subject: [GHC] #15802: Inlining of constant fails when both cross-module and recursive In-Reply-To: <046.641b42683ec0810e689b9d1da7b20b44@haskell.org> References: <046.641b42683ec0810e689b9d1da7b20b44@haskell.org> Message-ID: <061.5741597b3613eba1e75d60fc48e1522a@haskell.org> #15802: Inlining of constant fails when both cross-module and recursive -------------------------------------+------------------------------------- Reporter: j6carey | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by j6carey): * Attachment "T2.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 00:02:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 00:02:01 -0000 Subject: [GHC] #15802: Inlining of constant fails when both cross-module and recursive In-Reply-To: <046.641b42683ec0810e689b9d1da7b20b44@haskell.org> References: <046.641b42683ec0810e689b9d1da7b20b44@haskell.org> Message-ID: <061.f420169eb7ea53751b8ffac4576f4739@haskell.org> #15802: Inlining of constant fails when both cross-module and recursive -------------------------------------+------------------------------------- Reporter: j6carey | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by j6carey): * Attachment "T3.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 01:18:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 01:18:46 -0000 Subject: [GHC] #14398: Fail to install haskell platform on Windows In-Reply-To: <045.d86ee14cadb946edd5536f02e4b96185@haskell.org> References: <045.d86ee14cadb946edd5536f02e4b96185@haskell.org> Message-ID: <060.36333bcf7114e242766684c7b1e0c45e@haskell.org> #14398: Fail to install haskell platform on Windows -------------------------------------+------------------------------------- Reporter: KAAAsS | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.2.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: #14168 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by PaladinOfHonour): Replying to [comment:8 Phyx-]: > Thanks! the trace shows nothing really wrong, I think 8.2 has a memory corruption somewhere that's causing invalid characters to manifest in the strings. I'll have to figure out a way to track it down to verify if it's actually fixed or just happens to work in 8.4. This will be a very late reply to this thread, however, I encountered the exact same internal error issue. I run Windows 10 64-bit with Japanese as the OS language. After troubleshooting, and ruling out the similar #15021 chcp ticket, upgrading from 8.2 to 8.4 did do the job and resolved the error. As I noticed the error hasn't been closed yet and it's exact origin not quite yet discovered, I thought I'd give some extra information. Certain Japanese fonts map the ¥ sign to the \ , causing paths to take the visual form of C:¥Users¥User etc. This is most often merely visual, however, can cause problems within certain programs. Furthermore, OS specific directories might be in Japanese (user = ユーザー ), however, this should once again be merely a visual change. As the original poster was running a Chinese system, I suspect the error is caused by either of the above, or similar, effects. Thanks for the suggestion of upgrading and if there's still an interest in the bug I hope a second error report might elucidate the problem a bit. Kind Regards, Pally -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 07:20:13 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 07:20:13 -0000 Subject: [GHC] #15733: Several links in GHC.Exts.Heap documentation are broken In-Reply-To: <049.e71035ad0f7b2d4e40b57a77fc8c9c35@haskell.org> References: <049.e71035ad0f7b2d4e40b57a77fc8c9c35@haskell.org> Message-ID: <064.ccd58fe83360ce16168d96c6f0530d82@haskell.org> #15733: Several links in GHC.Exts.Heap documentation are broken -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D5257 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ömer Sinan Ağacan ): In [changeset:"49c7a51ef614068ba664422c48e97d3ec76178a5/ghc" 49c7a51/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="49c7a51ef614068ba664422c48e97d3ec76178a5" Fix some broken links (#15733) Change some URLs from hackage.haskell.org/trac to ghc.haskell.org/trac Test Plan: manually verify links work Reviewers: bgamari, simonmar, mpickering Reviewed By: bgamari, mpickering Subscribers: mpickering, rwbarton, carter GHC Trac Issues: #15733 Differential Revision: https://phabricator.haskell.org/D5257 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 08:10:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 08:10:11 -0000 Subject: [GHC] #15648: Core Lint error with source-level unboxed equality In-Reply-To: <050.b1c8c377aa63cdac74b3d157d20320e2@haskell.org> References: <050.b1c8c377aa63cdac74b3d157d20320e2@haskell.org> Message-ID: <065.9730b19d4f1a32c994fe3d75d267fc39@haskell.org> #15648: Core Lint error with source-level unboxed equality -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15209 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a3476aa265a4448df9c8d3333d6829a898108af6/ghc" a3476aa2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a3476aa265a4448df9c8d3333d6829a898108af6" Test Trac #15648 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 08:10:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 08:10:11 -0000 Subject: [GHC] #15300: Unboxed Sums Crash In-Reply-To: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> References: <049.da823730f37eb5827e9ed90ef407327a@haskell.org> Message-ID: <064.1ba817b1bd21ee9c0dbae52c13aa6d48@haskell.org> #15300: Unboxed Sums Crash -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: osa1 Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: UnboxedSums Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4962 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"232b0cb35c1f731be66a032a4deee87bc47db3c9/ghc" 232b0cb3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="232b0cb35c1f731be66a032a4deee87bc47db3c9" Add comments for StgCse and Unarise This just improves docmentation for the fix to Trac #15300 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 08:10:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 08:10:11 -0000 Subject: [GHC] #15778: GHC HEAD-only panic (zonkTcTyVarToTyVar) In-Reply-To: <050.3cd9086426b45d98a8ca89f3f02fc672@haskell.org> References: <050.3cd9086426b45d98a8ca89f3f02fc672@haskell.org> Message-ID: <065.a81769a8572149a5f96eedc1540a5b23@haskell.org> #15778: GHC HEAD-only panic (zonkTcTyVarToTyVar) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"29978ef1f834d77dc31bf7054590d526d068df7e/ghc" 29978ef/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="29978ef1f834d77dc31bf7054590d526d068df7e" Remove a zonkTcTyVarToTyVar This patch fixes Trac #15778 by removing a zonkTcTyVarToTyVar from tcHsSigType. Nww that a pattern-bound type variable can refer to a type, it's obvoiusly wrong to expect it to be a TyVar! Moreover, that zonk is entirely unnecessary. I added a new Note [Type variables in the type environment] in TcRnTypes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 08:25:51 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 08:25:51 -0000 Subject: [GHC] #15802: Inlining of constant fails when both cross-module and recursive In-Reply-To: <046.641b42683ec0810e689b9d1da7b20b44@haskell.org> References: <046.641b42683ec0810e689b9d1da7b20b44@haskell.org> Message-ID: <061.79c8692f462409ece393169f86c23c41@haskell.org> #15802: Inlining of constant fails when both cross-module and recursive -------------------------------------+------------------------------------- Reporter: j6carey | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): This is because SpecConstr doesn't work across modules. See https://phabricator.haskell.org/D3566 and #10346 However, your intuition that if you apply a function to a constantly known value then it should reduce is misguided. SpecConstr only works in a narrow set of circumstances and the inliner will never inline recursive functions. If you want to guarantee performance then the only way that I know is to use (typed) template haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 08:48:25 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 08:48:25 -0000 Subject: [GHC] #15800: Overlapping instances error with single instance In-Reply-To: <045.2e1fce9b901f82fa18c2e6cad6f62eea@haskell.org> References: <045.2e1fce9b901f82fa18c2e6cad6f62eea@haskell.org> Message-ID: <060.ef029f84096580d05c1a9fcd84ae36cd@haskell.org> #15800: Overlapping instances error with single instance -------------------------------------+------------------------------------- Reporter: roland | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"09481a708caad699b65712dedd321cbbc19851a7/ghc" 09481a70/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="09481a708caad699b65712dedd321cbbc19851a7" Improve documentation about overlapping instances An attempt to help with Trac #15800 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 09:02:22 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 09:02:22 -0000 Subject: [GHC] #15648: Core Lint error with source-level unboxed equality In-Reply-To: <050.b1c8c377aa63cdac74b3d157d20320e2@haskell.org> References: <050.b1c8c377aa63cdac74b3d157d20320e2@haskell.org> Message-ID: <065.b841677b27357e346b04561ff9bcddce@haskell.org> #15648: Core Lint error with source-level unboxed equality -------------------------------------+------------------------------------- Reporter: RyanGlScott | 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: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15209 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 09:03:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 09:03:00 -0000 Subject: [GHC] #15778: GHC HEAD-only panic (zonkTcTyVarToTyVar) In-Reply-To: <050.3cd9086426b45d98a8ca89f3f02fc672@haskell.org> References: <050.3cd9086426b45d98a8ca89f3f02fc672@haskell.org> Message-ID: <065.9f92e2edfa96ceca2f7e5e310c5f8cf3@haskell.org> #15778: GHC HEAD-only panic (zonkTcTyVarToTyVar) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_compile/T15778 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_compile/T15778 * status: new => merge Comment: Thanks! fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 09:05:33 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 09:05:33 -0000 Subject: [GHC] #15800: Overlapping instances error with single instance In-Reply-To: <045.2e1fce9b901f82fa18c2e6cad6f62eea@haskell.org> References: <045.2e1fce9b901f82fa18c2e6cad6f62eea@haskell.org> Message-ID: <060.a6d9f45a13a019e11f2c2a7b05a90611@haskell.org> #15800: Overlapping instances error with single instance -------------------------------------+------------------------------------- Reporter: roland | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I've tried to improve the docs. The key is that GHC looks at ''both'' top level instances ''and'' in-scope constraints, not just the former. In the error messages they are listed as "Matching instances" and "Matching givens" respectively. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 10:19:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 10:19:17 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow In-Reply-To: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> References: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> Message-ID: <057.1f8e8af13fa3a98aed09dddf52b26d79@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof recomp007 | space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It would be great to get to 'green' on the slow tests -- otherwise they aren't very useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 10:24:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 10:24:23 -0000 Subject: [GHC] #14859: Allow explicit impredicativity In-Reply-To: <046.bce52cd0cbee25c5f867b88fe7e6b527@haskell.org> References: <046.bce52cd0cbee25c5f867b88fe7e6b527@haskell.org> Message-ID: <061.428be3fca39d9322d6928fd0d7e98462@haskell.org> #14859: Allow explicit impredicativity -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think it's at least ''plausible'' that explicit type application to polytypes would be OK. It would take a little work make ''sure'' it was OK, but it is, as you say, much less ambitious than "Guarded impredicative polymorphism". A good project for someone. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 10:39:52 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 10:39:52 -0000 Subject: [GHC] #15778: GHC HEAD-only panic (zonkTcTyVarToTyVar) In-Reply-To: <050.3cd9086426b45d98a8ca89f3f02fc672@haskell.org> References: <050.3cd9086426b45d98a8ca89f3f02fc672@haskell.org> Message-ID: <065.32ea7873f783726620210b58963304aa@haskell.org> #15778: GHC HEAD-only panic (zonkTcTyVarToTyVar) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_compile/T15778 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: merge => closed * resolution: => fixed Comment: This shouldn't be merged. This fix relies on commit 4d91cabcd5e3c603997d9876f6d30204a9b029c6, which wasn't merged to the 8.6 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 11:33:48 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 11:33:48 -0000 Subject: [GHC] #15803: Put more info with flag description Message-ID: <046.c46c3af0177d000e9d7ddd302de72349@haskell.org> #15803: Put more info with flag description -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In the user manual, consider flag `-fcase-folding`. * It appears in [http://downloads.haskell.org/~ghc/master/users- guide/flags.html#individual-optimisations this table] where we learn that it is implied by `-O`. * But if you click on the flag name to [http://downloads.haskell.org/~ghc/master/users-guide/using- optimisation.html#ghc-flag--fcase-folding get more detail here], we no longer see that it's implied by -O. We just see that it defaults "on" which suggests it might be on with -O0. The source material, in `using-optimisation.rst` looks like this {{{ .. ghc-flag:: -fcase-folding :shortdesc: Enable constant folding in case expressions. Implied by :ghc-flag:`-O`. :type: dynamic :reverse: -fno-case-folding :category: :default: on Allow constant folding in case expressions that scrutinise some primops: }}} I think that in the "more details" page we should definitely display the "implied by -O" part, and the "reverse flag". Could we do that? I'm not sure about the "default". It's bizarre to be implied by -O but by-default on! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 11:43:55 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 11:43:55 -0000 Subject: [GHC] #15135: Overlapping typeclass instance selection depends on the optimisation level In-Reply-To: <046.e35da1b896548effba77cf7dc5003beb@haskell.org> References: <046.e35da1b896548effba77cf7dc5003beb@haskell.org> Message-ID: <061.3e9c823d625102de08ff6aec2149c716@haskell.org> #15135: Overlapping typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This is all caused by `-fsolve-constant-dicts`: see [http://downloads.haskell.org/~ghc/master/users-guide/using- optimisation.html#ghc-flag--fsolve-constant-dicts the manual], and Trac #12791 and #5835. The reason that behaviour differs with -O is because `-fsolve-constant- dicts` is implied by `-O`. The problem comes in {{{ instance Project a b => Project a (B b) where project (B a) = project a }}} From the RHS we get {{{ [W] Project a b }}} Shall we solve it from the dict passed into the instance? Or from the top-level instance declaration? {{{ instance {-# OVERLAPPING #-} Project a b where project _ = Nothing }}} With `-fsolve-constant-dicts`, GHC chooses the latter, wrongly. When you declare that instance as OVERLAPPABLE, thus {{{ instance {-# OVERLAPPABLE #-} Project a b where project _ = Nothing }}} GHC carefully refrains from using it, precisely because it might be overlapped (Trac #14434). Sadly, ''any'' instance declaration can be overlapped; GHC gives no way to say "this instance declaration cannot and must not be overlapped". Instead, in the presence of overlapping instances, the soundness of `-fsolve-constant-dicts` relies on the user specifying that an instance can be overlapped, by saying OVERLAPPABLE. This is terribly unsatisfactory, but at least we now understand what is going on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 11:49:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 11:49:17 -0000 Subject: [GHC] #15135: Overlapping typeclass instance selection depends on the optimisation level In-Reply-To: <046.e35da1b896548effba77cf7dc5003beb@haskell.org> References: <046.e35da1b896548effba77cf7dc5003beb@haskell.org> Message-ID: <061.91f10e4864a9c87484203f83ad392153@haskell.org> #15135: Overlapping typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a9a09b53c3f50df576564e8616b6dd4be029dcf6/ghc" a9a09b53/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a9a09b53c3f50df576564e8616b6dd4be029dcf6" Improve comments, triggered by Trac #15135 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 12:05:01 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 12:05:01 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.a340766a88a75ad7a87a3edd973e113c@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Have been trying to create the expression referred to by SPJ in comment:24 in `MatchList.hs` but having trouble creating core. {{{ HsRat _ fl ty -> case fl of FL { fl_signi = i, fl_exp = e } -> return (mkApps (Var "makeRational") [(mkIntegerExpr i) (mkIntegerExpr e)]) }}} I don't know how to make a `Var`. The `String` above is clearly wrong, but I couldn't find out how to construct one from scratch. I read through `MkId.hs`, `Id.hs` and `Var.hs` but it's not clear to me what I should be doing. Also, comment:24 refers to making "a new library function" which seems easy enough, but I don't know what a library function is (like... where should it go such that it gets picked up at runtime and registered in the list of available variables, available to core?). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 12:56:16 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 12:56:16 -0000 Subject: [GHC] #14859: Allow explicit impredicativity In-Reply-To: <046.bce52cd0cbee25c5f867b88fe7e6b527@haskell.org> References: <046.bce52cd0cbee25c5f867b88fe7e6b527@haskell.org> Message-ID: <061.0382f80c77966eb4e080d12bbf40e018@haskell.org> #14859: Allow explicit impredicativity -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.2.2 Resolution: | Keywords: | ImpredicativeTypes Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Impredicativity is perfectly fine in Core. (At least in theory. I'm sure panics await.) So giving users controlled access to it in source Haskell is safe, in that we won't launch the rockets. As we open this gate, horrors might await us on the other side, but they should all be type inference horrors, not type safety ones. I am thus in support of this direction of travel. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 13:04:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 13:04:56 -0000 Subject: [GHC] #15804: GHC panic (Visible kind application diff): data T :: (a :: k) -> * Message-ID: <051.4c772d74d494656c0a25536f5b92f8ed@haskell.org> #15804: GHC panic (Visible kind application diff): data T :: (a :: k) -> * -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (using [https://phabricator.haskell.org/D5229 Visual Kind Application (D5229)]) This might be the root cause of some of my previous {{{#!hs {-# Language PolyKinds #-} data T :: (a :: k) -> * }}} {{{ $ ghci -ignore-dot-ghci 580.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 580.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181017 for x86_64-unknown-linux): ASSERT failed! Type-correct unfilled coercion hole {co_a1xI} Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:1805:99 in ghc:TcHsSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} on 8.6.1 this gives {{{ $ ~/.stack/programs/x86_64-linux/ghc-8.6.1/bin/ghci -ignore-dot-ghci 580.hs GHCi, version 8.6.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /home/baldur/hs/580.hs, interpreted ) /home/baldur/hs/580.hs:3:11: error: • Expected a type, but ‘(a :: k)’ has kind ‘k’ • In the kind ‘(a :: k) -> *’ | 3 | data T :: (a :: k) -> * | ^^^^^^^^ Failed, no modules loaded. Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 13:08:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 13:08:32 -0000 Subject: [GHC] #15804: GHC panic (Visible kind application diff): data T :: (a :: k) -> * In-Reply-To: <051.4c772d74d494656c0a25536f5b92f8ed@haskell.org> References: <051.4c772d74d494656c0a25536f5b92f8ed@haskell.org> Message-ID: <066.c227735ed42cc4e54e449ead9d442e27@haskell.org> #15804: GHC panic (Visible kind application diff): data T :: (a :: k) -> * -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): It's entirely possible that this is due to some other change that was introduced between 8.6.1 and HEAD. Since you're filing bug reports about code that hasn't even shipped yet, I'd think the task falls upon you to check this :) Do you mind building GHC HEAD from `master` and seeing if this bug can be reproduced from there as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 13:09:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 13:09:10 -0000 Subject: [GHC] #15805: Bug in anyRewritableTyVar Message-ID: <047.87fb715ef5d84b486e63a473ac81c384@haskell.org> #15805: Bug in anyRewritableTyVar -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14363 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The current implementation of `TcType.anyRewritableTyVar` has one wrong case: {{{#!hs go_tc ReprEq bvs tc tys = foldr ((&&) . go_arg bvs) False $ (tyConRolesRepresentational tc `zip` tys) }}} Here `foldr` uses `&&` in the function and a `False` as the initial value, which causes this case to always return `False` no matter what the inputs are. This bug is introduced in [changeset:"3acd6164fea6d4d5d87521a291455a18c9c9a8ee/ghc" 3acd616/ghc], which is for fixing #14363. The correct implementation (I think) should use `||` instead of `&&`: {{{#!hs go_tc ReprEq bvs tc tys = foldr ((||) . go_arg bvs) False $ (tyConRolesRepresentational tc `zip` tys) -- or just go_tc ReprEq bvs tc tys = any (go_arg bvs) (tyConRolesRepresentational tc `zip` tys) }}} We presume that there might be some program which loops because of this bug. Patch incoming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 13:12:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 13:12:24 -0000 Subject: [GHC] #15805: Bug in anyRewritableTyVar In-Reply-To: <047.87fb715ef5d84b486e63a473ac81c384@haskell.org> References: <047.87fb715ef5d84b486e63a473ac81c384@haskell.org> Message-ID: <062.f9da7285ba407efd766253e6dd00ff1c@haskell.org> #15805: Bug in anyRewritableTyVar -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14363 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Wow -- good catch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 13:12:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 13:12:44 -0000 Subject: [GHC] #15804: GHC panic (Visible kind application diff): data T :: (a :: k) -> * In-Reply-To: <051.4c772d74d494656c0a25536f5b92f8ed@haskell.org> References: <051.4c772d74d494656c0a25536f5b92f8ed@haskell.org> Message-ID: <066.1c6630632f129efbbcffa0fa07947968@haskell.org> #15804: GHC panic (Visible kind application diff): data T :: (a :: k) -> * -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Actually, I should clarify my previous statement: you will never see an `ASSERT` failure on a released version of GHC, since they only appear when you build GHC with extra compile-time checks. (I'm guessing you're building with the `devel2` build flavour or something similar.) So it's not at all surprising that this doesn't fire on 8.6.1. Another possibility is that if you built 8.6.1 with `ASSERT`s enabled, then you'd also see this failure there. That would be worth a try. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 13:19:07 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 13:19:07 -0000 Subject: [GHC] #15806: Impredicativity behavior in `:k` command in GHCi Message-ID: <047.f58636059e2229b0e75e579e133e8b67@haskell.org> #15806: Impredicativity behavior in `:k` command in GHCi -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #14859 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In GHCi, the following command works: {{{#!hs Prelude> :set -XRankNTypes Prelude> :k (Maybe (forall a. a -> a)) (Maybe (forall a. a -> a)) :: * }}} Note here the type argument of `Maybe` is a polymorphic type. However the following would be (correctly) rejected: {{{#!hs Prelude> let f :: (Maybe (forall a. a -> a)) -> Int; f _ = 1 :4:10: error: • Illegal polymorphic type: forall a. a -> a GHC doesn't yet support impredicative polymorphism • In the type signature: f :: (Maybe (forall a. a -> a)) -> Int }}} Question: why does `:k` behave differently and is it what is expected? I think if we have #14859 those are both acceptable though? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 13:33:24 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 13:33:24 -0000 Subject: [GHC] #15806: Impredicativity behavior in `:k` command in GHCi In-Reply-To: <047.f58636059e2229b0e75e579e133e8b67@haskell.org> References: <047.f58636059e2229b0e75e579e133e8b67@haskell.org> Message-ID: <062.5d629261dbd861d179d412d4e97360fb@haskell.org> #15806: Impredicativity behavior in `:k` command in GHCi -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14859 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think the `:k` should be rejected to -- maybe we are missing a call to `checkValidType` somewhere? Yes if we had explicit impredicativity we should be ok -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 14:02:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 14:02:34 -0000 Subject: [GHC] #15497: Coercion Quantification In-Reply-To: <047.3a4a4e067b87a899efdf8c3f044fd1ac@haskell.org> References: <047.3a4a4e067b87a899efdf8c3f044fd1ac@haskell.org> Message-ID: <062.5b605a7f5dcc9725101d10694eec081b@haskell.org> #15497: Coercion Quantification -------------------------------------+------------------------------------- Reporter: ningning | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5054 Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Phase2| -------------------------------------+------------------------------------- Comment (by Ningning Xie ): In [changeset:"3905c3c07ba2735e5b3d2dc3389272d5dbb1c503/ghc" 3905c3c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3905c3c07ba2735e5b3d2dc3389272d5dbb1c503" Update core-spec for Coercion Quantification Summary: Update details for `ForAllTy` and `ForAllCo` in core-spec, as they can now quantify over coercion variables. Test Plan: Please read core-spec.pdf Reviewers: goldfire, simonpj, bgamari Reviewed By: goldfire Subscribers: rwbarton, carter GHC Trac Issues: #15497, #15589 Differential Revision: https://phabricator.haskell.org/D5247 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 14:02:34 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 14:02:34 -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.f22699d304493fcd6c475767664a9917@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 Ningning Xie ): In [changeset:"3905c3c07ba2735e5b3d2dc3389272d5dbb1c503/ghc" 3905c3c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3905c3c07ba2735e5b3d2dc3389272d5dbb1c503" Update core-spec for Coercion Quantification Summary: Update details for `ForAllTy` and `ForAllCo` in core-spec, as they can now quantify over coercion variables. Test Plan: Please read core-spec.pdf Reviewers: goldfire, simonpj, bgamari Reviewed By: goldfire Subscribers: rwbarton, carter GHC Trac Issues: #15497, #15589 Differential Revision: https://phabricator.haskell.org/D5247 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 14:14:02 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 14:14:02 -0000 Subject: [GHC] #15805: Bug in anyRewritableTyVar In-Reply-To: <047.87fb715ef5d84b486e63a473ac81c384@haskell.org> References: <047.87fb715ef5d84b486e63a473ac81c384@haskell.org> Message-ID: <062.6286db9a80663b42c1acd4a83c53760f@haskell.org> #15805: Bug in anyRewritableTyVar -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14363 | Differential Rev(s): Phab:D5263 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ningning): * owner: (none) => ningning * differential: => Phab:D5263 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 14:26:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 14:26:43 -0000 Subject: [GHC] #14332: Deriving clauses can have forall types In-Reply-To: <050.6c2c9b47d51bbd6274ba7997829a8360@haskell.org> References: <050.6c2c9b47d51bbd6274ba7997829a8360@haskell.org> Message-ID: <065.16117e52f7fb6846aa133ea186c1097b@haskell.org> #14332: Deriving clauses can have forall types -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.2.1 checker) | Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #14331 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #14331 Comment: It turns out that the changes in the parser necessary to accommodate `forall`s in `deriving` clauses (without the double parentheses junk) is essentially just this: {{{#!diff diff --git a/compiler/parser/Parser.y b/compiler/parser/Parser.y index af8c95f..7ad3025 100644 --- a/compiler/parser/Parser.y +++ b/compiler/parser/Parser.y @@ -1979,9 +1985,9 @@ inst_type :: { LHsSigType GhcPs } : sigtype { mkLHsSigType $1 } deriv_types :: { [LHsSigType GhcPs] } - : typedoc { [mkLHsSigType $1] } + : ktypedoc { [mkLHsSigType $1] } - | typedoc ',' deriv_types {% addAnnotation (gl $1) AnnComma (gl $2) + | ktypedoc ',' deriv_types {% addAnnotation (gl $1) AnnComma (gl $2) >> return (mkLHsSigType $1 : $3) } comma_types0 :: { [LHsType GhcPs] } -- Zero or more: ty,ty,ty }}} I'm not going to open a Diff for this now, since it would be nice to combine the fix for this ticket with that of #14331. But I'll record this here for posterity's sake. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 14:31:32 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 14:31:32 -0000 Subject: [GHC] #15804: GHC panic (Visible kind application diff): data T :: (a :: k) -> * In-Reply-To: <051.4c772d74d494656c0a25536f5b92f8ed@haskell.org> References: <051.4c772d74d494656c0a25536f5b92f8ed@haskell.org> Message-ID: <066.c88e68e7e81b2a0e3ddf38f723065ae2@haskell.org> #15804: GHC panic (Visible kind application diff): data T :: (a :: k) -> * -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Just built head and it panics the same {{{ $ ./ghc-stage2 -ignore-dot-ghci --interactive ~/hs/583.hs GHCi, version 8.7.20181025: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /home/baldur/hs/583.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181025 for x86_64-unknown-linux): ASSERT failed! Type-correct unfilled coercion hole {co_a1xI} Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:1805:99 in ghc:TcHsSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 14:37:41 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 14:37:41 -0000 Subject: [GHC] #15804: GHC panic (Visible kind application diff): data T :: (a :: k) -> * In-Reply-To: <051.4c772d74d494656c0a25536f5b92f8ed@haskell.org> References: <051.4c772d74d494656c0a25536f5b92f8ed@haskell.org> Message-ID: <066.e3cab105805ccc88495b2690535d78b4@haskell.org> #15804: GHC panic (Visible kind application diff): data T :: (a :: k) -> * -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: mnguyen (removed) * keywords: TypeApplications => Comment: Thanks! So that confirms one thing: this is not the fault of the VKA patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 14:38:17 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 14:38:17 -0000 Subject: [GHC] #15804: GHC panic: data T :: (a :: k) -> * (was: GHC panic (Visible kind application diff): data T :: (a :: k) -> *) In-Reply-To: <051.4c772d74d494656c0a25536f5b92f8ed@haskell.org> References: <051.4c772d74d494656c0a25536f5b92f8ed@haskell.org> Message-ID: <066.e967fcf70bcaa4747444fc015552c6f4@haskell.org> #15804: GHC panic: data T :: (a :: k) -> * -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * keywords: => TypeApplications * cc: mnguyen (added) Old description: > (using [https://phabricator.haskell.org/D5229 Visual Kind Application > (D5229)]) > > This might be the root cause of some of my previous > > {{{#!hs > {-# Language PolyKinds #-} > > data T :: (a :: k) -> * > }}} > {{{ > $ ghci -ignore-dot-ghci 580.hs > GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( 580.hs, interpreted ) > ghc-stage2: panic! (the 'impossible' happened) > (GHC version 8.7.20181017 for x86_64-unknown-linux): > ASSERT failed! > Type-correct unfilled coercion hole {co_a1xI} > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in > ghc:Outputable > pprPanic, called at compiler/utils/Outputable.hs:1219:5 in > ghc:Outputable > assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:1805:99 > in ghc:TcHsSyn > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > > > }}} > > on 8.6.1 this gives > > {{{ > $ ~/.stack/programs/x86_64-linux/ghc-8.6.1/bin/ghci -ignore-dot-ghci > 580.hs > GHCi, version 8.6.1: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( /home/baldur/hs/580.hs, interpreted > ) > > /home/baldur/hs/580.hs:3:11: error: > • Expected a type, but ‘(a :: k)’ has kind ‘k’ > • In the kind ‘(a :: k) -> *’ > | > 3 | data T :: (a :: k) -> * > | ^^^^^^^^ > Failed, no modules loaded. > Prelude> > }}} New description: This might be the root cause of some of my previous {{{#!hs {-# Language PolyKinds #-} data T :: (a :: k) -> * }}} {{{ $ ghci -ignore-dot-ghci 580.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 580.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181017 for x86_64-unknown-linux): ASSERT failed! Type-correct unfilled coercion hole {co_a1xI} Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/TcHsSyn.hs:1805:99 in ghc:TcHsSyn Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} on 8.6.1 this gives {{{ $ ~/.stack/programs/x86_64-linux/ghc-8.6.1/bin/ghci -ignore-dot-ghci 580.hs GHCi, version 8.6.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /home/baldur/hs/580.hs, interpreted ) /home/baldur/hs/580.hs:3:11: error: • Expected a type, but ‘(a :: k)’ has kind ‘k’ • In the kind ‘(a :: k) -> *’ | 3 | data T :: (a :: k) -> * | ^^^^^^^^ Failed, no modules loaded. Prelude> }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 14:38:58 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 14:38:58 -0000 Subject: [GHC] #15804: GHC panic: data T :: (a :: k) -> * In-Reply-To: <051.4c772d74d494656c0a25536f5b92f8ed@haskell.org> References: <051.4c772d74d494656c0a25536f5b92f8ed@haskell.org> Message-ID: <066.4014f8a3b77b63cd7bfd7fa480487db5@haskell.org> #15804: GHC panic: data T :: (a :: k) -> * -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: mnguyen (removed) * keywords: TypeApplications => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 14:39:11 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 14:39:11 -0000 Subject: [GHC] #15804: GHC panic: data T :: (a :: k) -> * In-Reply-To: <051.4c772d74d494656c0a25536f5b92f8ed@haskell.org> References: <051.4c772d74d494656c0a25536f5b92f8ed@haskell.org> Message-ID: <066.62c9eca9a6914b6008d7ceea9b24ce38@haskell.org> #15804: GHC panic: data T :: (a :: k) -> * -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): oops, edit clash -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 15:35:56 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 15:35:56 -0000 Subject: [GHC] #15807: GHC panic with visible kind applications Message-ID: <051.23fa71fd3c8f35b741fff4c2f0658791@haskell.org> #15807: GHC panic with visible kind applications ----------------------------------------+--------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: TypeApplications | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- Using the https://phabricator.haskell.org/D5229 diff This is '''fine''' {{{#!hs {-# Language RankNTypes #-} {-# Language TypeApplications #-} {-# Language PolyKinds #-} {-# Language GADTs #-} import Data.Kind data App :: forall (f :: Type -> Type). Type -> Type where MkApp :: f a -> App @f a }}} Kind polymorphic is '''fine''' {{{#!hs {-# Language RankNTypes #-} {-# Language TypeApplications #-} {-# Language PolyKinds #-} {-# Language GADTs #-} import Data.Kind data App :: forall k (f :: k -> Type). k -> Type where MkApp :: f a -> App @k @(f :: k -> Type) (a :: k) }}} But offing the visibility of `k` '''fails''' {{{#!hs {-# Language RankNTypes #-} {-# Language TypeApplications #-} {-# Language PolyKinds #-} {-# Language GADTs #-} import Data.Kind data App :: forall (f :: k -> Type). k -> Type where MkApp :: f a -> App @(f :: k -> Type) (a :: k) }}} {{{#!hs {-# Language RankNTypes #-} {-# Language TypeApplications #-} {-# Language PolyKinds #-} {-# Language GADTs #-} import Data.Kind data App :: forall (f :: k -> Type). k -> Type where MkApp :: f a -> App @f a }}} {{{ $ ghci -ignore-dot-ghci 581_bug.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 581_bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181017 for x86_64-unknown-linux): ASSERT failed! 2 1 f_a1yB[tau:1] f_a1yx[sk:1] 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:778:54 in ghc:TcMType Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 15:37:10 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 15:37:10 -0000 Subject: [GHC] #15559: fromJust has no HasCallStack In-Reply-To: <046.0c0fc309394993486a792a626e8db1e1@haskell.org> References: <046.0c0fc309394993486a792a626e8db1e1@haskell.org> Message-ID: <061.0caedc37e08cde0865d5efe739e72a49@haskell.org> #15559: fromJust has no HasCallStack -------------------------------------+------------------------------------- Reporter: nomeata | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.1 Component: Core Libraries | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5256 Wiki Page: | -------------------------------------+------------------------------------- Changes (by potato44): * differential: D5256 => Phab:D5256 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 15:42:19 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 15:42:19 -0000 Subject: [GHC] #15645: TypeChecking of Monad patterns incorrect with RebindableSyntax and OverloadedStrings In-Reply-To: <051.1afac0be4b689267d905f3e66b5a2d7d@haskell.org> References: <051.1afac0be4b689267d905f3e66b5a2d7d@haskell.org> Message-ID: <066.83189fa31556723de504988c897b65ff@haskell.org> #15645: TypeChecking of Monad patterns incorrect with RebindableSyntax and OverloadedStrings -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: shayne- | fletcher-da Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5251 Wiki Page: | -------------------------------------+------------------------------------- Changes (by potato44): * differential: D5251 => Phab:D5251 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 16:06:21 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 16:06:21 -0000 Subject: [GHC] #15765: Make the "extract" functions in RnTypes pure In-Reply-To: <047.96044c33162b65d98275c8947da2911e@haskell.org> References: <047.96044c33162b65d98275c8947da2911e@haskell.org> Message-ID: <062.050338e0b5481bf7a0531e940629cb4e@haskell.org> #15765: Make the "extract" functions in RnTypes pure -------------------------------------+------------------------------------- Reporter: goldfire | Owner: simonpj Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: (none) => simonpj -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 16:36:15 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 16:36:15 -0000 Subject: [GHC] #15495: Handling Source Locations via TTG In-Reply-To: <050.b9166c5b755fb618e3ff0003339d26df@haskell.org> References: <050.b9166c5b755fb618e3ff0003339d26df@haskell.org> Message-ID: <065.dfd29296cf18fdddce1fe77d0145ac57@haskell.org> #15495: Handling Source Locations via TTG -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5036 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * differential: => Phab:D5036 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 16:46:00 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 16:46:00 -0000 Subject: [GHC] #15495: Handling Source Locations via TTG In-Reply-To: <050.b9166c5b755fb618e3ff0003339d26df@haskell.org> References: <050.b9166c5b755fb618e3ff0003339d26df@haskell.org> Message-ID: <065.7ee98375761e9b43a406ef92cf407aa0@haskell.org> #15495: Handling Source Locations via TTG -------------------------------------+------------------------------------- Reporter: Shayan-Najd | Owner: (none) Type: task | Status: new Priority: normal | Milestone: ⊥ Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5036 Wiki Page: | -------------------------------------+------------------------------------- Comment (by alanz): The buildable version, with haddock changes, is at `wip/az-D5036-2`. It has also been rebased to master of 2 days ago. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 17:21:59 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 17:21:59 -0000 Subject: [GHC] #15768: Using oneshot kqueue() on macOS In-Reply-To: <052.23d28fc3421f1bb560c819068174239d@haskell.org> References: <052.23d28fc3421f1bb560c819068174239d@haskell.org> Message-ID: <067.5f956bb780efd056575f617cef2eb210@haskell.org> #15768: Using oneshot kqueue() on macOS -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Core Libraries | Version: 8.6.1 Resolution: | Keywords: KQueue, | oneshot, parallel build Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): just curious, 13903 was on many platforms, right? So why did it only affect oneshot kqueue() on only the Mac? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 18:04:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 18:04:35 -0000 Subject: [GHC] #12160: MonadFail instance for (Either String)? In-Reply-To: <050.c741533f1a8cf09b525d8cc1127b4d5b@haskell.org> References: <050.c741533f1a8cf09b525d8cc1127b4d5b@haskell.org> Message-ID: <065.30a888f30bb9a3dc75bccb49436374e6@haskell.org> #12160: MonadFail instance for (Either String)? -------------------------------------+------------------------------------- Reporter: lexi.lambda | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries | Version: 8.0.1 (other) | Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9588 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dmbergey): * status: new => closed * resolution: => wontfix Comment: As of 2018, the libraries committee has rejected this change. The mailing list discussion is at: https://mail.haskell.org/pipermail/libraries/2018-October/028988.html The concerns are that: - the instances "get in the way of a user who wants to treat the parameter uniformly" - `IsString` is too far from standard Haskell (and unlikely to be added to the standard) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 18:26:35 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 18:26:35 -0000 Subject: [GHC] #15808: Master sefaults on windows during aeson build when stage2 libs have dwarf enabled. Message-ID: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> #15808: Master sefaults on windows during aeson build when stage2 libs have dwarf enabled. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I haven't had any luck with reproducing it outside of building the aeson package with cabal yet. So for now just documenting the fact. build.mk used {{{ GhcLibHcOpts += -g3 GhcRtsHcOpts += -g3 STRIP_CMD = : BUILD_PROF_LIBS = NO SplitObjs = NO SplitSections = NO HADDOCK_DOCS = NO BUILD_SPHINX_HTML = NO BUILD_SPHINX_PDF = NO BUILD_MAN = NO }}} Error log: {{{ "E:/ghc_dwarf/inplace/bin/ghc-stage2.exe" "--make" "-fbuilding-cabal- package" "-O" "-outputdir" "C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build" "-odir" "C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build" "-hidir" "C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build" "-stubdir" "C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build""-i" "-iC:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build" "-i." "-iattoparsec-iso8601/" "-ipure" "-iC:\ghc\msys64\home\Andi\aeson_repro \dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\autogen" "-iC:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\global- autogen" "-IC:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\autogen" "-IC:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\global- autogen" "-IC:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build" "-Iinclude" "-IC:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\include" "-optP-include" "-optPC:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\autogen\cabal_macros.h" "-this-unit-id" "aeson-1.4.1.0-inplace" "-hide-all-packages" "-Wmissing- home-modules" "-no-user-package-db" "-package-db" "C:\Users\Andi\AppData\Roaming\cabal\store\ghc-8.7.20181025\package.db" "-package-db" "C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\packagedb\ghc-8.7.20181025" "-package-db" "C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\package.conf.inplace" "-package-id" "attoparsec-0.13.2.2-8913a968506e9e83757f6fe696d6fe61e0d4b4a8" "-package- id" "base-4.12.0.0" "-package-id" "base- compat-0.10.5-34e11ceb2d98e0262d1d958bca2afc3184e70c60" "-package-id" "bytestring-0.10.8.2" "-package-id" "containers-0.6.0.1" "-package-id" "deepseq-1.4.4.0" "-package-id" "dlist-0.8.0.5-681a0f929505417757ba9f9981a50ab1d7c8a0e0" "-package-id" "ghc-prim-0.5.3" "-package-id" "hashable-1.2.7.0-50f89c5dee92df34fc2d6540cfde1983f26d8e31" "-package-id" "primitive-0.6.4.0-c08c185073660c1604acdddfe5c369afae583ba2" "-package-id" "scientific-0.3.6.2-4bea197b4523e02da61c34a1eed01432d9fefff6" "-package- id" "tagged-0.8.6-d3cce1acba663b646f565adb64d80579664d8caa" "-package-id" "template-haskell-2.14.0.0" "-package-id" "text-1.2.3.1" "-package-id" "th-abstraction-0.2.8.0-e197ba78a6de8bf8fc5d00ecb5a358a8b27bcc92" "-package-id" "time-1.8.0.2" "-package-id" "time-locale- c_-0.1.1.5-7549537073e62ce01921c89c30cc6cafeed99b5b" "-package-id" "unordered-con_-0.2.9.0-f5cd33176070f516c88b1aac3ef61959b09fcfa6" "-package-id" "uuid-types-1.0.3-f68643250767dce83d2c227104d15a0aa9c3c77f" "-package-id" "vector-0.12.0.1-3a9a26f81a463f0efefa41528af3e27d3a88cc7d" "-XHaskell2010" "Data.Aeson" "Data.Aeson.Encoding" "Data.Aeson.Parser" "Data.Aeson.Text" "Data.Aeson.Types" "Data.Aeson.TH" "Data.Aeson.QQ.Simple" "Data.Aeson.Encoding.Internal" "Data.Aeson.Internal" "Data.Aeson.Internal.Time" "Data.Aeson.Parser.Internal" "Data.Aeson.Encode" "Data.Aeson.Compat" "Data.Aeson.Encoding.Builder" "Data.Aeson.Internal.Functions" "Data.Aeson.Parser.Unescape" "Data.Aeson.Parser.Time" "Data.Aeson.Types.FromJSON" "Data.Aeson.Types.Generic" "Data.Aeson.Types.ToJSON" "Data.Aeson.Types.Class" "Data.Aeson.Types.Internal" "Data.Attoparsec.Time" "Data.Attoparsec.Time.Internal" "Data.Aeson.Parser.UnescapePure" "-Wall" "-O2" "-hide-all-packages" "-g13" [ 2 of 25] Compiling Data.Aeson.Internal.Functions ( Data\Aeson\Internal\Functions.hs, C:\ghc\msys64\home\Andi\aeson_repro \dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Internal\Functions.o ) [Data.HashMap.Strict changed] [ 5 of 25] Compiling Data.Aeson.Types.Generic ( Data\Aeson\Types\Generic.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Types\Generic.o ) [Prelude.Compat changed] [ 6 of 25] Compiling Data.Aeson.Types.Internal ( Data\Aeson\Types\Internal.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Types\Internal.o ) [Data.Vector changed] [ 7 of 25] Compiling Data.Aeson.Parser.Internal ( Data\Aeson\Parser\Internal.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Parser\Internal.o ) [Data.Scientific changed] [ 8 of 25] Compiling Data.Aeson.Parser ( Data\Aeson\Parser.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Parser.o ) [Data.Aeson.Parser.Internal changed] [ 9 of 25] Compiling Data.Attoparsec.Time.Internal ( attoparsec- iso8601\Data\Attoparsec\Time\Internal.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Attoparsec\Time\Internal.o ) [Prelude.Compat changed] attoparsec-iso8601\Data\Attoparsec\Time\Internal.hs:24:1: warning: [-Wunused-imports] The import of `Unsafe.Coerce' is redundant except perhaps to import instances from `Unsafe.Coerce' To import instances alone, use: import Unsafe.Coerce() | 24 | import Unsafe.Coerce (unsafeCoerce) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [10 of 25] Compiling Data.Attoparsec.Time ( attoparsec- iso8601\Data\Attoparsec\Time.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Attoparsec\Time.o ) [Data.Attoparsec.Text changed] [11 of 25] Compiling Data.Aeson.Parser.Time ( Data\Aeson\Parser\Time.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Parser\Time.o ) [Data.Attoparsec.Text changed] [12 of 25] Compiling Data.Aeson.Types.FromJSON ( Data\Aeson\Types\FromJSON.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Types\FromJSON.o ) [Data.Primitive.PrimArray changed] [13 of 25] Compiling Data.Aeson.Internal ( Data\Aeson\Internal.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Internal.o ) [Data.Aeson.Types.FromJSON changed] [14 of 25] Compiling Data.Aeson.Internal.Time ( Data\Aeson\Internal\Time.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Internal\Time.o ) [Data.Attoparsec.Time.Internal changed] [15 of 25] Compiling Data.Aeson.Encoding.Builder ( Data\Aeson\Encoding\Builder.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Encoding\Builder.o ) [Data.Vector changed] [16 of 25] Compiling Data.Aeson.Encoding.Internal ( Data\Aeson\Encoding\Internal.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Encoding\Internal.o ) [Data.Scientific changed] [17 of 25] Compiling Data.Aeson.Encoding ( Data\Aeson\Encoding.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Encoding.o ) [Data.Aeson.Encoding.Internal changed] [18 of 25] Compiling Data.Aeson.Types.ToJSON ( Data\Aeson\Types\ToJSON.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Types\ToJSON.o ) [Data.Primitive.PrimArray changed] Access violation in generated code when executing data at 0x103fec440 Attempting to reconstruct a stack trace... Frame Code address * 0x845d9c0 0x103fec440 * 0x845da20 0x400c0f8 E:\ghc_dwarf\inplace\bin\ghc- stage2.exe+0x3c0c0f8 * 0x845da80 0x3fec9a1 E:\ghc_dwarf\inplace\bin\ghc- stage2.exe+0x3bec9a1 * 0x845dab0 0x3feca31 E:\ghc_dwarf\inplace\bin\ghc- stage2.exe+0x3beca31 * 0x845dab8 0x34c8934 E:\ghc_dwarf\inplace\bin\ghc- stage2.exe+0x30c8934 * 0x845dac0 0xfa340 * 0x845dac8 0x2a940b78 * 0x845dad0 0x2a98cd69 * 0x845dad8 0x2a98d7d0 CallStack (from HasCallStack): die', called at .\\Distribution\\Client\\ProjectOrchestration.hs:977:55 in main:Distribution.Client.ProjectOrchestration cabal.exe: Failed to build aeson-1.4.1.0-inplace. The build process terminated with exit code 11 }}} I could only reproduce it with master on Windows so far. It always triggers but under very specific circumstances: * GHC built with the flags above, adding dwarf info to the ghc executable or removing dwarf info eliminates the issue. * Only on a complete rebuild of aeson. Restarting the crashed build finishes without an error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 19:02:31 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 19:02:31 -0000 Subject: [GHC] #15802: Inlining of constant fails when both cross-module and recursive In-Reply-To: <046.641b42683ec0810e689b9d1da7b20b44@haskell.org> References: <046.641b42683ec0810e689b9d1da7b20b44@haskell.org> Message-ID: <061.3743fb06cb396a6a46605169ca01d9b2@haskell.org> #15802: Inlining of constant fails when both cross-module and recursive -------------------------------------+------------------------------------- Reporter: j6carey | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j6carey): Sorry to be unclear; I was mentioning INLINE because it ensures that the function definition is available to other modules, and therefore ensures that a reduction would be possible, not because I expect general inlining of recursive functions. I am pretty sure that [https://ghc.haskell.org/trac/ghc/ticket/10346] would do everything that I need. It also suggests that meanwhile I might be able to find an alternative design using type classes; I'll see what I can do. Thanks for spotting that this is a duplicate issue! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 19:05:47 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 19:05:47 -0000 Subject: [GHC] #15802: Inlining of constant fails when both cross-module and recursive In-Reply-To: <046.641b42683ec0810e689b9d1da7b20b44@haskell.org> References: <046.641b42683ec0810e689b9d1da7b20b44@haskell.org> Message-ID: <061.b6df0d97722d3aeab230583a36f93441@haskell.org> #15802: Inlining of constant fails when both cross-module and recursive -------------------------------------+------------------------------------- Reporter: j6carey | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: 10346 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by j6carey): * priority: normal => highest * related: => 10346 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 19:06:23 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 19:06:23 -0000 Subject: [GHC] #15802: Inlining of constant fails when both cross-module and recursive In-Reply-To: <046.641b42683ec0810e689b9d1da7b20b44@haskell.org> References: <046.641b42683ec0810e689b9d1da7b20b44@haskell.org> Message-ID: <061.c9b762e687a2d01b5c6319abe33145ab@haskell.org> #15802: Inlining of constant fails when both cross-module and recursive -------------------------------------+------------------------------------- Reporter: j6carey | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: Component: Compiler | Version: 8.6.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: 10346 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by j6carey): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 19:20:44 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 19:20:44 -0000 Subject: [GHC] #15789: GHC panic using visible kind applications and a higher-rank kind In-Reply-To: <051.0cec3213d5885cf112eba4e0f29633b7@haskell.org> References: <051.0cec3213d5885cf112eba4e0f29633b7@haskell.org> Message-ID: <066.230833f30dc7169e2c08725b5e4cf86b@haskell.org> #15789: GHC panic using visible kind applications and a higher-rank kind -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * cc: mnguyen (removed) * keywords: => TypeInType Comment: This also fails without visible kind application -- any DEBUG compiler will trigger it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 19:27:46 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 19:27:46 -0000 Subject: [GHC] #15787: GHC panic using kind application In-Reply-To: <051.88158355ed422210999943d4c175f35d@haskell.org> References: <051.88158355ed422210999943d4c175f35d@haskell.org> Message-ID: <066.004a0332ef37931efba13e2b0466ee13@haskell.org> #15787: GHC panic using kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * cc: mnguyen (removed) * keywords: TypeApplications => TypeInType Comment: Also not My's fault. The following code panics similarly in HEAD: {{{#!hs {-# Language RankNTypes #-} {-# Language TypeApplications #-} {-# Language DataKinds #-} {-# Language PolyKinds #-} {-# Language GADTs #-} {-# Language TypeFamilies #-} import Data.Kind class Ríki (ob :: Type) where type Hom :: ob -> ob -> Type data Kl_kind :: forall ob . (ob -> ob) -> ob -> Type where Kl :: k -> Kl_kind (m :: ob -> ob) k type family UnKl (kl :: Kl_kind m k) = (res :: k) where UnKl (Kl a) = a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 20:10:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 20:10:36 -0000 Subject: [GHC] #15788: Core Lint error, from visible kind applications In-Reply-To: <051.9512af2451069a0fc0b33528cf855ee3@haskell.org> References: <051.9512af2451069a0fc0b33528cf855ee3@haskell.org> Message-ID: <066.7f35c5608b83bd5d405cca0db4385aa0@haskell.org> #15788: Core Lint error, from visible kind applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: #12045 Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This is really #15743 in deep disguise. GHC correctly infers `A :: forall {k1} (k :: k1). Type`. We have `MkA :: A @p` (I've changed the variable name). Currently, the kind application branch has a bug that means we don't skip Inferred variables when instantiating. So, the `p` instantiates the `k1`. But, the kind of a data constructor has kind `Type`, while `A @p :: forall (k :: p). Type`. So we instantiate with a metavariable, getting `A @p @alpha`, where `alpha :: p`. Then, we try to generalize, skolemizing `alpha := a`.. Generalization tries putting Inferred things before Specified things, and so we get `forall (a :: p) p. A p a`, which is clearly hogwash. I hope that once my Phab:D5208 patch lands, this will be fixed. Meanwhile, My will fix the forgetting-to-skip-Inferred variables bug. (See point (4) in https://phabricator.haskell.org/D5229#144361 .) Keeping this open, as we should test that it all works in the end. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 20:11:37 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 20:11:37 -0000 Subject: [GHC] #15743: Nail down the Required/Inferred/Specified story In-Reply-To: <046.20125fa3baabaa154b0336067d36471f@haskell.org> References: <046.20125fa3baabaa154b0336067d36471f@haskell.org> Message-ID: <061.943489ebcfcd73d277dec33b68080918@haskell.org> #15743: Nail down the Required/Inferred/Specified story -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): See #15788 for another test case, this time in the process of generalizing a data constructor. (That bug is in the context of visible kind application, but the visible kind application is somewhat incidental in that ticket.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 21:20:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 21:20:36 -0000 Subject: [GHC] #15800: Overlapping instances error with single instance In-Reply-To: <045.2e1fce9b901f82fa18c2e6cad6f62eea@haskell.org> References: <045.2e1fce9b901f82fa18c2e6cad6f62eea@haskell.org> Message-ID: <060.0ea70fdb97b8a5a9c217f5a18982edf3@haskell.org> #15800: Overlapping instances error with single instance -------------------------------------+------------------------------------- Reporter: roland | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by roland): Thanks, this indeed clarifies things! I was trying to trigger the search procedure with `C a Int` as the target constraint. It seems that for the ambiguity check it ended up not only as the target, but also as one of the givens, at which point the error is to be expected. Replacing `()` with `a` (thus making the type non-ambiguous) or adding the AllowAmbiguousTypes pragma both make the program type-check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 22:06:03 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 22:06:03 -0000 Subject: [GHC] #15768: Using oneshot kqueue() on macOS In-Reply-To: <052.23d28fc3421f1bb560c819068174239d@haskell.org> References: <052.23d28fc3421f1bb560c819068174239d@haskell.org> Message-ID: <067.4d3e58c1a15f103f19eec35a8e535486@haskell.org> #15768: Using oneshot kqueue() on macOS -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Core Libraries | Version: 8.6.1 Resolution: | Keywords: KQueue, | oneshot, parallel build Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kazu-yamamoto): kqueue() is used on MacOS and BSD variants. But when we implemented Mio, we only tested it on MacOS and Linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 23:05:43 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 23:05:43 -0000 Subject: [GHC] #15733: Several links in GHC.Exts.Heap documentation are broken In-Reply-To: <049.e71035ad0f7b2d4e40b57a77fc8c9c35@haskell.org> References: <049.e71035ad0f7b2d4e40b57a77fc8c9c35@haskell.org> Message-ID: <064.fd76a77573d196f15ac6f212be0d451a@haskell.org> #15733: Several links in GHC.Exts.Heap documentation are broken -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D5257 Wiki Page: | -------------------------------------+------------------------------------- Changes (by fangyizhou): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Oct 25 23:17:36 2018 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Oct 2018 23:17:36 -0000 Subject: [GHC] #15770: Missing optimisation opportunity in code gen for always-saturated applications? In-Reply-To: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> References: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> Message-ID: <058.fc2472ba7f7e3f3c66c4d1f8920dd4fb@haskell.org> #15770: Missing optimisation opportunity in code gen for always-saturated applications? -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5232 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Commit this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 02:26:15 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 02:26:15 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.bc49c5fa14e91b59ec3bd0a6c79f652e@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): Phab:D5170 #12753 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ericson2314): That patch seems...odd to me. I think we might have a simpler problem: I did on nixos unstable (but I think 18.09 would also work) - clone recentish Cabal - `nix-shell -p 'haskellPackages.ghcWithPackages (p: [ p.zlib ])' -p zlib -p haskellPackages.happy -p haskellPackages.alex` - `new-configure -O0 --enable-tests --extra-lib- dirs=/nix/store/...-zlib-1.2.11/lib` - `cabal new-repl cabal-install` `-L` from `--extra-lib-dirs` did make it to ghci, but it fails with {{{ : can't load .so/.DLL for: libz.so (libz.so: cannot open shared object file: No such file or directory) }}} and `ghci -v` gives me {{{ *** gcc: /nix/store/10yq7kwlvbc6h658izmrlsspry1g9f3c-gcc-wrapper-7.3.0/bin/cc -fno- stack-protector -DTABLES_NEXT_TO_CODE -B/home/jcericson/.cabal/store/ghc-8.4.3/digest-0.0.1.2-14fe411601bb13fe646394df438bbd46ddfbff1cdb12e63d463c3cc847a007ff/lib --print-file-name libz.so *** gcc: /nix/store/10yq7kwlvbc6h658izmrlsspry1g9f3c-gcc-wrapper-7.3.0/bin/cc -fno- stack-protector -DTABLES_NEXT_TO_CODE -B/home/jcericson/.cabal/store/ghc-8.4.3/digest-0.0.1.2-14fe411601bb13fe646394df438bbd46ddfbff1cdb12e63d463c3cc847a007ff/lib --print-file-name liblibz.so *** gcc: /nix/store/10yq7kwlvbc6h658izmrlsspry1g9f3c-gcc-wrapper-7.3.0/bin/cc -fno- stack-protector -DTABLES_NEXT_TO_CODE -B/home/jcericson/.cabal/store/ghc-8.4.3/digest-0.0.1.2-14fe411601bb13fe646394df438bbd46ddfbff1cdb12e63d463c3cc847a007ff/lib --print-file-name z.lib *** gcc: /nix/store/10yq7kwlvbc6h658izmrlsspry1g9f3c-gcc-wrapper-7.3.0/bin/cc -fno- stack-protector -DTABLES_NEXT_TO_CODE -B/home/jcericson/.cabal/store/ghc-8.4.3/digest-0.0.1.2-14fe411601bb13fe646394df438bbd46ddfbff1cdb12e63d463c3cc847a007ff/lib --print-file-name libz.lib *** gcc: /nix/store/10yq7kwlvbc6h658izmrlsspry1g9f3c-gcc-wrapper-7.3.0/bin/cc -fno- stack-protector -DTABLES_NEXT_TO_CODE -B/home/jcericson/.cabal/store/ghc-8.4.3/digest-0.0.1.2-14fe411601bb13fe646394df438bbd46ddfbff1cdb12e63d463c3cc847a007ff/lib --print-file-name libz.dll.a *** gcc: /nix/store/10yq7kwlvbc6h658izmrlsspry1g9f3c-gcc-wrapper-7.3.0/bin/cc -fno- stack-protector -DTABLES_NEXT_TO_CODE -B/home/jcericson/.cabal/store/ghc-8.4.3/digest-0.0.1.2-14fe411601bb13fe646394df438bbd46ddfbff1cdb12e63d463c3cc847a007ff/lib --print-file-name z.dll.a *** gcc: /nix/store/10yq7kwlvbc6h658izmrlsspry1g9f3c-gcc-wrapper-7.3.0/bin/cc -fno- stack-protector -DTABLES_NEXT_TO_CODE -B/home/jcericson/.cabal/store/ghc-8.4.3/digest-0.0.1.2-14fe411601bb13fe646394df438bbd46ddfbff1cdb12e63d463c3cc847a007ff/lib --print-file-name libz.a *** gcc: /nix/store/10yq7kwlvbc6h658izmrlsspry1g9f3c-gcc-wrapper-7.3.0/bin/cc -fno- stack-protector -DTABLES_NEXT_TO_CODE -B/home/jcericson/.cabal/store/ghc-8.4.3/digest-0.0.1.2-14fe411601bb13fe646394df438bbd46ddfbff1cdb12e63d463c3cc847a007ff/lib --print-file-name z.a Loading package digest-0.0.1.2 ... *** Deleting temp files: Deleting: *** Deleting temp dirs: }}} There's plenty to minimize and control here (e.g. `~/.cabal/store/ghc-8.4.3/package.db` populated in different nix-shells), but I want to ask the simple check, if ghc is looking up libz.so, why isn't it using -L? (Maybe the directories listed in the package db override it?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 03:13:01 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 03:13:01 -0000 Subject: [GHC] #15632: Undependable Dependencies In-Reply-To: <043.01997ce1746c591111a0a2273155036b@haskell.org> References: <043.01997ce1746c591111a0a2273155036b@haskell.org> Message-ID: <058.a9ed94482a5f08d2d7d4c0c96e6ebe8d@haskell.org> #15632: Undependable Dependencies -------------------------------------+------------------------------------- Reporter: AntC | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.6.1-beta1 Resolution: | Keywords: | FunctionalDependencies, | OverlappingInstances Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 10675, 9210, | Differential Rev(s): 8634, 15135 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by AntC): * related: 10675, 9210, 8634 => 10675, 9210, 8634, 15135 Comment: Adding related ticket, particularly ticket:15135#comment:3 and SPJ's reply at comment 6 "This is terribly unsatisfactory". Changing the optimisation level or the per-instance pragmas can change which instance is selected, and thereby the meaning of the program -- even within a single module. (The O.P. for that ticket is the familiar 'orphan instances'/separate modules -- which is at least a devil we know.) The linked manual for `-fsolve-constant-dicts` says > we can often produce much better code by directly solving for an available `Num Int` dictionary we might have at hand. This removes potentially many layers of indirection and crucially allows other optimisations to fire ... This seems to be muddling up concerns: - selecting which instance satisfies a Wanted constraint (in case of Overlapping instances, this means 'best'/most closely satisfies); - vs: having resolved which instance, ''and'' determined it's the same instance as for a dictionary available at hand, ''then'' sharing the at-hand dictionary/removing layers of indirection, etc. I can see that under separate compilation, we can't be sure whether the 'best' instance in scope in the current module might get gazumped by an instance in another module. Then we can only go by the `OVERLAPPABLE` pragma. But we should always search all instances in scope in the current module, irrespective of pragmas or optimisation(?) OK that search is adding a performance hit for the compiler and it only makes a difference in case of overlap; but it shouldn't impact object code, presuming it does resolve to an at-hand dictionary. I didn't realise the pragmas had that dramatic of an effect on selecting instances. Then this applies from comment 1 > I think it's arguable that an instance should only be overlappable if it says {-# OVERLAPPABLE #-}. But that's not our current spec. Making that the rule (in some form) could detect/warn of problematic 'orphan instances'. Interpreting the rule for instances that are in no substitution order (the O.P. on this ticket #15632) still needs some head- scratching. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 03:31:20 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 03:31:20 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.ab2746f8062a0c0069baf0303680269e@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): Phab:D5170 #12753 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ericson2314): Hmm, this may be a cabal my error, but I nuked my `~/.cabal/cache`, did a `cabal new-configure --extra-lib-dir=.*`, and the package conf for `digest` in the new cache still didn't have `library-dirs: ...nix's-zlib`, causing a failure when GHCi attempted to load `digest`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 03:31:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 03:31:57 -0000 Subject: [GHC] #15135: Overlapping typeclass instance selection depends on the optimisation level In-Reply-To: <046.e35da1b896548effba77cf7dc5003beb@haskell.org> References: <046.e35da1b896548effba77cf7dc5003beb@haskell.org> Message-ID: <061.c85943f666bc0993bdab51d6ef2cd835@haskell.org> #15135: Overlapping typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AntC): Replying to [comment:6 simonpj]: Thank you Simon for such a clear explanation. Oh dear! I see GHC has to do something like this under separate compilation. I'm not seeing why in a single module it doesn't at least inspect all instances in scope. > > Sadly, ''any'' instance declaration can be overlapped; GHC gives no way to say "this instance declaration cannot and must not be overlapped". This is terribly unsatisfactory, but at least we now understand what is going on. Then (?) we need a pragma for that, and it might need to be used in combo with other pragmas {-# OVERLAPPING, NOTOVERLAPPABLE #-}. Ugh! This'll get particularly ugh!ly if instances are in no substitution ordering. There's something to be said for statically validating all instances are in a strict substitution order. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 06:33:38 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 06:33:38 -0000 Subject: [GHC] #15770: Missing optimisation opportunity in code gen for always-saturated applications? In-Reply-To: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> References: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> Message-ID: <058.34161af6d97ad6afac3080eef36310ac@haskell.org> #15770: Missing optimisation opportunity in code gen for always-saturated applications? -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5232 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): You mean Phab:D5232? sgraf is using StgBinderInfo for late lambda lift so I thought we probably shouldn't remove it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 06:43:51 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 06:43:51 -0000 Subject: [GHC] #15770: Missing optimisation opportunity in code gen for always-saturated applications? In-Reply-To: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> References: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> Message-ID: <058.032cc09f0c5488a7ca7ec2d7416ab524@haskell.org> #15770: Missing optimisation opportunity in code gen for always-saturated applications? -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5232 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): I'm convinced Phab:D5232 makes sense, so we should do this. Phab:D5224 can wait. Will there be an analysis that recovers the functionality or do I have to write my own (occurrence analyser on STG)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 08:35:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 08:35:56 -0000 Subject: [GHC] #15806: Impredicativity behavior in `:k` command in GHCi In-Reply-To: <047.f58636059e2229b0e75e579e133e8b67@haskell.org> References: <047.f58636059e2229b0e75e579e133e8b67@haskell.org> Message-ID: <062.cafa603e6bffd0b9be6824f99bc624d1@haskell.org> #15806: Impredicativity behavior in `:k` command in GHCi -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14859 | Differential Rev(s): Phab:D5265 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ningning): * owner: (none) => ningning * differential: => Phab:D5265 Comment: Yes that's exactly the reason! Just pushed a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 09:14:19 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 09:14:19 -0000 Subject: [GHC] #15791: typeKind confuses Type and Constraint In-Reply-To: <047.14fa0e2dfd42db4b54f79032d932ab60@haskell.org> References: <047.14fa0e2dfd42db4b54f79032d932ab60@haskell.org> Message-ID: <062.92d77d8c72ea6969bd0713141e3cdf92@haskell.org> #15791: typeKind confuses Type and Constraint -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I tried this, but got stuck here, in `GHC.Err`: {{{ undefined :: forall (r :: RuntimeRep). forall (a :: TYPE r). HasCallStack => a }}} What is the kind of `undefined`'s type? With `typeKind` we get `Type`. But with `tcTypeKind` we dive into the body of the `=>`, and take the kind of `a`; but alas that mentions the universally quantified `r`, so we get a panic. And indeed the type `forall r (a::TYPE r). a` is indeed ill-formed. But with the `HasCallStack` it is actually fine. What to do? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 09:54:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 09:54:32 -0000 Subject: [GHC] #15765: Make the "extract" functions in RnTypes pure In-Reply-To: <047.96044c33162b65d98275c8947da2911e@haskell.org> References: <047.96044c33162b65d98275c8947da2911e@haskell.org> Message-ID: <062.e3923abb93123a39c0046991a52815a5@haskell.org> #15765: Make the "extract" functions in RnTypes pure -------------------------------------+------------------------------------- Reporter: goldfire | Owner: simonpj Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"e6bf96c9700aacbd75169dbf2cc14c9216c0133f/ghc" e6bf96c9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e6bf96c9700aacbd75169dbf2cc14c9216c0133f" De-monadise the 'extract' functions in RnTypes As Trac #15765 says, Once upon a time, the extract functions at the bottom of RnTypes were pure. Then, along came -XTypeInType, which needed to do a check in these functions for users mixing type variables with kind variables. Now, however, with -XTypeInType gone again, we no longer do this check. Thus, there is no reason to keep these functions monadic. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 09:56:58 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 09:56:58 -0000 Subject: [GHC] #15765: Make the "extract" functions in RnTypes pure In-Reply-To: <047.96044c33162b65d98275c8947da2911e@haskell.org> References: <047.96044c33162b65d98275c8947da2911e@haskell.org> Message-ID: <062.4dd3881d8d3c1a482e702e712e9345b5@haskell.org> #15765: Make the "extract" functions in RnTypes pure -------------------------------------+------------------------------------- Reporter: goldfire | Owner: simonpj Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 09:58:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 09:58:53 -0000 Subject: [GHC] #15791: typeKind confuses Type and Constraint In-Reply-To: <047.14fa0e2dfd42db4b54f79032d932ab60@haskell.org> References: <047.14fa0e2dfd42db4b54f79032d932ab60@haskell.org> Message-ID: <062.706942de4f868bf8d8296e858061cc7e@haskell.org> #15791: typeKind confuses Type and Constraint -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I've pushed my work in progress to `wip/T15791` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 09:59:12 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 09:59:12 -0000 Subject: [GHC] #15791: typeKind confuses Type and Constraint In-Reply-To: <047.14fa0e2dfd42db4b54f79032d932ab60@haskell.org> References: <047.14fa0e2dfd42db4b54f79032d932ab60@haskell.org> Message-ID: <062.26922672aeb492d0335da8cebd44b663@haskell.org> #15791: typeKind confuses Type and Constraint -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Branch: Wiki Page: | wip/T15791 -------------------------------------+------------------------------------- Changes (by simonpj): * differential: => Branch: wip/T15791 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 10:00:35 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 10:00:35 -0000 Subject: [GHC] #15770: Missing optimisation opportunity in code gen for always-saturated applications? In-Reply-To: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> References: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> Message-ID: <058.56cedc97d665ba6afd089244fd6d0b35@haskell.org> #15770: Missing optimisation opportunity in code gen for always-saturated applications? -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5232 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Will there be an analysis that recovers the functionality or do I have to write my own (occurrence analyser on STG)? I think the latter. It's extremely easy of course. The only tricky bit is to decide how to record the results in the tree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 10:10:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 10:10:54 -0000 Subject: [GHC] #15809: Use level numbers for generalisation Message-ID: <046.a6e0ab66a770cc4806a0fa3da3482ff2@haskell.org> #15809: Use level numbers for generalisation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | 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's type inference engine goes to quite a bit of effort to pin a ''level number'' on every type variable (both skolems and unification variables). '''Idea''': when generalising a type or kind, use those level numbers to decide which variables to generalise. This could completely replace the "global tyvars" field of the `TcLclEnv` (the `tcl_tyvars` field), which is very tiresome to maintain. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 10:13:00 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 10:13:00 -0000 Subject: [GHC] #15780: ghc-8.4.4 failed to build on armv7 and aarch64 In-Reply-To: <050.81668a88e354aac40559f0e53fb7e269@haskell.org> References: <050.81668a88e354aac40559f0e53fb7e269@haskell.org> Message-ID: <065.fa3325bd622a6789a42f4da25d0169cd@haskell.org> #15780: ghc-8.4.4 failed to build on armv7 and aarch64 ----------------------------------------+------------------------------ Reporter: juhpetersen | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.6.2 Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by juhpetersen): (and the workaround is to revert the above commit - I am not sure if a partial workaround is workable) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 11:21:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 11:21:57 -0000 Subject: [GHC] #15808: Master sefaults on windows during aeson build when stage2 libs have dwarf enabled. In-Reply-To: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> References: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> Message-ID: <062.f02f26764b901649d47d7a62e146732b@haskell.org> #15808: Master sefaults on windows during aeson build when stage2 libs have dwarf enabled. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): The error happens during linking (for TH I assume): The exact moment it happens differs when the memory usage of the compiler changes. If I pass different -H values, different verbosity flags and so on it either fails earlier, later or not at all. When it fails it's always during linking. So I assume there is some issue that arises when GC kicks in during linking, where we then access a pointer that hasn't been updated properly. {{{ !!! ByteCodeGen [Ghci1]: finished in 0.00 milliseconds, allocated 0.049 megabytes *** gcc: "E:\ghc_dwarf\inplace\lib\../mingw/bin/gcc.exe" "-fno-stack-protector" "-DTABLES_NEXT_TO_CODE" "--print-search-dirs" Loading package ghc-prim-0.5.3 ... linking ... done. Loading package integer-gmp-1.0.2.0 ... linking ... done. Loading package base-4.12.0.0 ... linking ... done. Loading package array-0.5.2.0 ... linking ... done. Loading package deepseq-1.4.4.0 ... linking ... done. Loading package transformers-0.5.5.0 ... linking ... done. Loading package primitive-0.6.4.0 ... linking ... done. Loading package vector-0.12.0.1 ... linking ... done. Loading package bytestring-0.10.8.2 ... linking ... done. Loading package containers-0.6.0.1 ... linking ... done. Loading package binary-0.8.6.0 ... linking ... done. Loading package text-1.2.3.1 ... linking ... done. Loading package hashable-1.2.7.0 ... linking ... done. Loading package filepath-1.4.2.1 ... linking ... done. Loading package Win32-2.6.1.0 ... linking ... done. Loading package time-1.8.0.2 ... linking ... done. Loading package random-1.1 ... linking ... done. Loading package uuid-types-1.0.3 ... linking ... done. Loading package unordered-containers-0.2.9.0 ... linking ... done. Loading package time-locale-compat-0.1.1.5 ... linking ... done. Loading package ghc-boot-th-8.7 ... linking ... done. Loading package pretty-1.1.3.6 ... linking ... done. Loading package template-haskell-2.14.0.0 ... linking ... done. Loading package th-abstraction-0.2.8.0 ... linking ... done. Loading package tagged-0.8.6 ... linking ... done. Loading package dlist-0.8.0.5 ... linking ... done. Loading package base-compat-0.10.5 ... linking ... done. Loading package integer-logarithms-1.0.2.2 ... linking ... done. Loading package scientific-0.3.6.2 ... linking ... done. Loading package attoparsec-0.13.2.2 ... linking ... done. Search directories (user): Search directories (gcc): E://ghc_dwarf//inplace//mingw//bin/ E://ghc_dwarf//inplace//mingw//bin/../lib/ E://ghc_dwarf//inplace//mingw//bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/ E:/ghc_dwarf/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/ E:/ghc_dwarf/inplace/mingw/bin/../lib/gcc/ E:/ghc_dwarf/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/lib/../lib/ E:/ghc_dwarf/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../lib/ E:/ghc_dwarf/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/lib/ E:/ghc_dwarf/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../ C:\WINDOWS\system32 Loading object (static archive) E:/ghc_dwarf/inplace/mingw/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/lib/../lib/libpthread.dll.a ... done final link ... done Access violation in generated code when executing data at 0xffffffff800ba2c8 Attempting to reconstruct a stack trace... Frame Code address * 0x845dae0 0xffffffff800ba2c8 }}} Another variant: {{{ !!! CorePrep [Data.Aeson.Encoding]: finished in 0.00 milliseconds, allocated 0.061 megabytes *** Stg2Stg: *** CodeGen [Data.Aeson.Encoding]: !!! CodeGen [Data.Aeson.Encoding]: finished in 0.00 milliseconds, allocated 0.514 megabytes *** Assembler: "E:\ghc_dwarf\inplace\lib\../mingw/bin/gcc.exe" "-fno-stack-protector" "-DTABLES_NEXT_TO_CODE" "-iquote.\Data\Aeson" "-IC:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build" "-IC:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build" "-IC:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\autogen" "-IC:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\global- autogen" "-IC:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build" "-Iinclude" "-IC:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\include" "-no-pie" "-x" "assembler" "-c" "C:\ghc\msys64\tmp\ghc173148_0\ghc_72.s" "-o" "C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Encoding.o" *** Deleting temp files: Deleting: C:\ghc\msys64\tmp\ghc173148_0\ghc_71.s C:\ghc\msys64\tmp\ghc173148_0\ghc_72.s C:\ghc\msys64\tmp\ghc173148_0\ghc_73.c Warning: deleting non-existent C:\ghc\msys64\tmp\ghc173148_0\ghc_71.s Warning: deleting non-existent C:\ghc\msys64\tmp\ghc173148_0\ghc_73.c compile: input file C:\ghc\msys64\tmp\ghc173148_0\ghc_15.hscpp *** Checking old interface for Data.Aeson.Types.ToJSON (use -ddump-hi- diffs for more details): [18 of 25] Compiling Data.Aeson.Types.ToJSON ( Data\Aeson\Types\ToJSON.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Types\ToJSON.o ) *** Parser [Data.Aeson.Types.ToJSON]: !!! Parser [Data.Aeson.Types.ToJSON]: finished in 15.63 milliseconds, allocated 109.276 megabytes *** Renamer/typechecker [Data.Aeson.Types.ToJSON]: *** Simplify [expr]: !!! Simplify [expr]: finished in 0.00 milliseconds, allocated 0.554 megabytes *** CorePrep [expr]: !!! CorePrep [expr]: finished in 0.00 milliseconds, allocated 0.011 megabytes *** ByteCodeGen [Ghci1]: !!! ByteCodeGen [Ghci1]: finished in 0.00 milliseconds, allocated 0.049 megabytes *** gcc: "E:\ghc_dwarf\inplace\lib\../mingw/bin/gcc.exe" "-fno-stack-protector" "-DTABLES_NEXT_TO_CODE" "--print-search-dirs" Loading package ghc-prim-0.5.3 ... linking ... done. Loading package integer-gmp-1.0.2.0 ... linking ... done. Loading package base-4.12.0.0 ... linking ... Access violation in generated code when executing data at 0x103fec440 Attempting to reconstruct a stack trace... Frame Code address * 0x845d9c0 0x103fec440 * 0x845da20 0x400c0f8 E:\ghc_dwarf\inplace\bin\ghc- stage2.crash.exe+0x3c0c0f8 * 0x845da80 0x3fec9a1 E:\ghc_dwarf\inplace\bin\ghc- stage2.crash.exe+0x3bec9a1 * 0x845dab0 0x3feca31 E:\ghc_dwarf\inplace\bin\ghc- stage2.crash.exe+0x3beca31 * 0x845dab8 0x34c8934 E:\ghc_dwarf\inplace\bin\ghc- stage2.crash.exe+0x30c8934 * 0x845dac0 0x1 * 0x845dac8 0xa5c2030 * 0x845dad0 0xc * 0x845dad8 0x231c3190 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 11:32:18 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 11:32:18 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.2250b244835586ebe0457d572a941ec9@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by sgraf): Re: ticket:15770#comment:11 (StgBinderInfo is going to be removed in Phab:D5232) I can probably just reuse [https://github.com/sgraf812/ghc/compare/sgraf812:46933fe...sgraf812:96d1401 a branch I had lying around] that didn't have any consequences for benchmark performance. Still, I'll probably need to wait for the changes from Phab:D5232 to hit master. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 11:33:08 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 11:33:08 -0000 Subject: [GHC] #15770: Missing optimisation opportunity in code gen for always-saturated applications? In-Reply-To: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> References: <043.c2bf19b6a55043952dd3a304f2716a5e@haskell.org> Message-ID: <058.9f7265368feb0df485f4ac9aa29d0567@haskell.org> #15770: Missing optimisation opportunity in code gen for always-saturated applications? -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5232 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): I continued discussion of the consequences of this ticket for LLF in https://ghc.haskell.org/trac/ghc/ticket/9476#comment:49. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 12:10:09 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 12:10:09 -0000 Subject: [GHC] #15789: GHC panic using visible kind applications and a higher-rank kind In-Reply-To: <051.0cec3213d5885cf112eba4e0f29633b7@haskell.org> References: <051.0cec3213d5885cf112eba4e0f29633b7@haskell.org> Message-ID: <066.7811ab467f5d25ec064252d24c8ed805@haskell.org> #15789: GHC panic using visible kind applications and a higher-rank kind -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I have a fix for this -- as part of #15809 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 12:59:02 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 12:59:02 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.96c8998b417511f381540e6d57957f43@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Nevermind, mpickering on irc helped me work out where to look. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 13:04:55 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 13:04:55 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.6379985ef1d57daac7d454cc8652b088@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.6.2 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: 15592 Related Tickets: #15076 | Differential Rev(s): Phab:D4769, | Phab:D5141, Phab:D5147, Phab:D5150, Wiki Page: | Phab:D5208 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"503514b94f8dc7bd9eab5392206649aee45f140b/ghc" 503514b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="503514b94f8dc7bd9eab5392206649aee45f140b" Fix nasty bug in the type free-var finder, at last Consider the type forall k. b -> k where b :: k -> Type Here the 'k' in b's kind must be a different 'k' to the forall k, because 'b' is free in the expression. So we must return 'k' among the free vars returned from tyCoVarsOfType applied that type. But we weren't. This is an outright bug, although we don't have a program that fails because of it. It's easy to fix, too: see TyCoRep Note [Closing over free variable kinds] This fix has been in the pipeline for ages because it fell into the Trac #14880 swamp. But this patch nails it. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 13:06:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 13:06:53 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.c9853a4157c870cb30d274dde5137864@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.6.2 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: 15592 Related Tickets: #15076 | Differential Rev(s): Phab:D4769, | Phab:D5141, Phab:D5147, Phab:D5150, Wiki Page: | Phab:D5208 -------------------------------------+------------------------------------- Comment (by simonpj): OK good. We are done with Step 2. Now we just need Richard's patch, Phab:D5208. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 13:08:43 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 13:08:43 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.8c141d91c12dc4bce660e29343db333d@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.6.2 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: 15592 Related Tickets: #15076 | Differential Rev(s): Phab:D4769, | Phab:D5141, Phab:D5147, Phab:D5150, Wiki Page: | Phab:D5208 -------------------------------------+------------------------------------- Comment (by simonpj): This patch {{{ commit 4de4b2253caa685a39cc654d553cdf63b8babbee Author: Simon Peyton Jones Date: Thu Oct 25 15:16:19 2018 +0100 Fix generalisation for type constructors Fixing the way that we close-over-kinds when taking the free vars of a type revealed that the way we generalise type constructors was a bit wrong. This fixes it. See TcTyClDecls Note [Generalisation for type constructors] >--------------------------------------------------------------- 4de4b2253caa685a39cc654d553cdf63b8babbee compiler/typecheck/TcTyClsDecls.hs | 58 +++++++++++++++++++++--- compiler/typecheck/TcValidity.hs | 92 +++++++++++++++----------------------- 2 files changed, 86 insertions(+), 64 deletions(-) }}} turned out to be necessary as a precursor to the patch in comment:153. The lack of it was the reason for the two validation failures mentioned in comment:152. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 13:20:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 13:20:53 -0000 Subject: [GHC] #15809: Use level numbers for generalisation In-Reply-To: <046.a6e0ab66a770cc4806a0fa3da3482ff2@haskell.org> References: <046.a6e0ab66a770cc4806a0fa3da3482ff2@haskell.org> Message-ID: <061.0f5492abc6cd6728c3ae5389676113e4@haskell.org> #15809: Use level numbers for generalisation -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Just to record: I think I've fixed #15789 en route to the main story here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 13:21:50 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 13:21:50 -0000 Subject: [GHC] #15135: Overlapping typeclass instance selection depends on the optimisation level In-Reply-To: <046.e35da1b896548effba77cf7dc5003beb@haskell.org> References: <046.e35da1b896548effba77cf7dc5003beb@haskell.org> Message-ID: <061.65c7fb9d674a7bb54bf6ac8f9a033fd6@haskell.org> #15135: Overlapping typeclass instance selection depends on the optimisation level -------------------------------------+------------------------------------- Reporter: nicuveo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I don't think this has anything to do with separate compilation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 13:48:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 13:48:10 -0000 Subject: [GHC] #13913: Can't apply higher-ranked kind in type family In-Reply-To: <050.5f4c4ea8193a5e7095f6124ed594e16e@haskell.org> References: <050.5f4c4ea8193a5e7095f6124ed594e16e@haskell.org> Message-ID: <065.268265071604dec3aabf5ff322c6afb8@haskell.org> #13913: Can't apply higher-ranked kind in type family -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1 checker) | Keywords: TypeFamilies, Resolution: duplicate | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11719 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeFamilies, TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 13:51:56 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 13:51:56 -0000 Subject: [GHC] #15810: Kind inference error in classes Message-ID: <047.233e3575916e674e22c670b1bfed9d52@haskell.org> #15810: Kind inference error in classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | 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 rejected today, but it shouldn't be: {{{#!hs class C a where meth :: Proxy (a :: k) }}} It's the kind signature that kills it. Expected solution: change `tcImplicitTKBndrs` to `kcImplicitTKBndrs` in `kcHsKindSig`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 13:57:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 13:57:10 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.37aab047f6f0002e2d4c4b4a168e00a1@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Comment (by simonpj): > I realised that while the heuristics currently employed work quite well, we are too pessimistic wrt. unsaturated applications. As I say on Phab, we really need a Note summarising the heuristics. (And of course the paper will help a lot.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 14:06:07 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 14:06:07 -0000 Subject: [GHC] #15791: typeKind confuses Type and Constraint In-Reply-To: <047.14fa0e2dfd42db4b54f79032d932ab60@haskell.org> References: <047.14fa0e2dfd42db4b54f79032d932ab60@haskell.org> Message-ID: <062.3525ba730c29c6a8a5841c4cc06b9182@haskell.org> #15791: typeKind confuses Type and Constraint -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Branch: Wiki Page: | wip/T15791 -------------------------------------+------------------------------------- Comment (by goldfire): Here are the typing rules, as I see it: {{{ t1 : Constraint t2 : TYPE rep -- rep is a metavariable ---------------- t1 => t2 : Type t1 : Constraint t2 : Constraint --------------------- t1 => t2 : Constraint ty : TYPE rep `a` is not free in rep ----------------------- forall a. ty : TYPE rep ty : Constraint ------------------------- forall a. ty : Constraint }}} The rules might be missing some side conditions for type safety, etc., but this should be enough to get `typeKind` working. Specifically: because the kind of `a` is `TYPE blah`, then `HasCallStack => a` has kind `Type`. Maybe you were thinking that `t1 => t2` has the kind of `t2`? That wouldn't work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 14:40:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 14:40:22 -0000 Subject: [GHC] #15743: Nail down the Required/Inferred/Specified story In-Reply-To: <046.20125fa3baabaa154b0336067d36471f@haskell.org> References: <046.20125fa3baabaa154b0336067d36471f@haskell.org> Message-ID: <061.f715689980547d58ae3fba6a2dd8aa88@haskell.org> #15743: Nail down the Required/Inferred/Specified story -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yikes. See {{{ Note [Kind variable ordering for associated types] }}} in `TcHsType`. I think that for {{{ class C (a :: Type) where type T (x :: f a) }}} it'd be much more straightforard to say that `f` comes before `a` in `T`'s kind, contrary to that Note. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 14:57:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 14:57:32 -0000 Subject: [GHC] #15791: typeKind confuses Type and Constraint In-Reply-To: <047.14fa0e2dfd42db4b54f79032d932ab60@haskell.org> References: <047.14fa0e2dfd42db4b54f79032d932ab60@haskell.org> Message-ID: <062.1993c2ab5fc30a68fc89ed8485e574dd@haskell.org> #15791: typeKind confuses Type and Constraint -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Branch: Wiki Page: | wip/T15791 -------------------------------------+------------------------------------- Comment (by simonpj): > Maybe you were thinking that t1 => t2 has the kind of t2? That wouldn't work. Yes, that's what the code currently says. OK; now I think I see what to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 15:02:36 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 15:02:36 -0000 Subject: [GHC] #15743: Nail down the Required/Inferred/Specified story In-Reply-To: <046.20125fa3baabaa154b0336067d36471f@haskell.org> References: <046.20125fa3baabaa154b0336067d36471f@haskell.org> Message-ID: <061.3963fe93d4ae3e45512ce177fbd34169@haskell.org> #15743: Nail down the Required/Inferred/Specified story -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Why? Consider {{{#!hs class C b where meth :: a -> b -> b }}} The full type for `meth` is `meth :: forall b. C b => forall a. a -> b -> b`. Note that `b` comes first, even though it is mentioned lexically second in the type of `meth`. I suppose we ''could'' pull the `a` all the way out to the front, but I think the current treatment is nice and predictable. What about {{{#!hs class C2 a b | a -> b where meth2 :: c -> a -> a }}} Using the same reasoning, we get `meth2 :: forall a b. C2 a b => forall c. c -> a -> a`. Note that `b` is Specified in the type of `meth2`. Returning to associated types (and the example from comment:12), we want associated types to behave somewhat like terms. Let's suppose we have Constrained Type Families, as I think that's the right model for all this. Then, we would get `T :: forall {k} (a :: k). C @k a => forall (f :: k -> Type). f a -> Type`. See now nicely that parallels the term-level treatment! Of course, we don't get the `C a` constraint these days, but that leaves us with `forall {k} (a :: k) (f :: k -> Type). f a -> Type`, as suggested by that Note. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 15:10:17 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 15:10:17 -0000 Subject: [GHC] #15811: Comment out CONSTANT_FOLDED annotation for some GHC.Natural functions Message-ID: <046.3d65654e0c3d431e5ff8ed7b7fa13c62@haskell.org> #15811: Comment out CONSTANT_FOLDED annotation for some GHC.Natural functions -------------------------------------+------------------------------------- Reporter: darchon | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D5267 | Wiki Page: -------------------------------------+------------------------------------- Some functions in GHC.Natural with a CONSTANT_FOLDED annotation don't have actual builtin rules (nor a builtin name in PrelNames and friends). This is hurting the Clash compiler because the workers for these functions do not end up in the .hi interface files, nor can we reliably define primops; meaning Clash cannot translate functions over Natural. This is doubly problematic because Natural is the underlying representation for KnownNat which Clash uses extensively. This feature request is simply a backstop for GHC 8.6.2 until proper builtin rules have been defined for the functions over the relevant Natural functions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 15:13:04 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 15:13:04 -0000 Subject: [GHC] #15811: Comment out CONSTANT_FOLDED annotation for some GHC.Natural functions In-Reply-To: <046.3d65654e0c3d431e5ff8ed7b7fa13c62@haskell.org> References: <046.3d65654e0c3d431e5ff8ed7b7fa13c62@haskell.org> Message-ID: <061.57cb2b5d03e724de58440d7869296e93@haskell.org> #15811: Comment out CONSTANT_FOLDED annotation for some GHC.Natural functions -------------------------------------+------------------------------------- Reporter: darchon | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5267 Wiki Page: | -------------------------------------+------------------------------------- Changes (by darchon): * status: new => patch Old description: > Some functions in GHC.Natural with a CONSTANT_FOLDED annotation don't > have actual builtin rules (nor a builtin name in PrelNames and friends). > > This is hurting the Clash compiler because the workers for these > functions do not end up in the .hi interface files, nor can we reliably > define primops; meaning Clash cannot translate functions over Natural. > This is doubly problematic because Natural is the underlying > representation for KnownNat which Clash uses extensively. > > This feature request is simply a backstop for GHC 8.6.2 until proper > builtin rules have been defined for the functions over the relevant > Natural functions. New description: Some functions in GHC.Natural with a CONSTANT_FOLDED annotation don't have actual builtin rules (nor a builtin name in PrelNames and friends). This is hurting the Clash compiler because the workers for these functions do not end up in the .hi interface files, nor can we reliably define primops; meaning Clash cannot translate functions over Natural. This is doubly problematic because Natural is the underlying representation for KnownNat which Clash uses extensively. This feature request is simply a backstop for GHC 8.6.2 until proper builtin rules are defined for the referred to functions in GHC.Natural -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 18:31:32 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 18:31:32 -0000 Subject: [GHC] #15812: add System.Mem.Address to base Message-ID: <045.b345df82d6f6da10bcf57adbf4aa903f@haskell.org> #15812: add System.Mem.Address to base -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: | Version: 8.7 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): D5268 | Wiki Page: -------------------------------------+------------------------------------- per libraries in progress discussion and https://phabricator.haskell.org/D5268 current state is this {{{ {-# LANGUAGE MagicHash #-} Module System.Mem.Address ( -- * Types Addr(..), -- * Address arithmetic nullAddr, plusAddr, minusAddr, remAddr, -- * Conversion addrToInt, addrToPtr, ptrToAddr ) where import GHC.Base ( Int(..) ) import GHC.Prim import GHC.Exts (isTrue#) import GHC.Ptr import Foreign.Marshal.Utils import Data.Typeable ( Typeable ) import Data.Data ( Data(..), mkNoRepType ) -- | A machine address data Addr = Addr Addr# deriving ( Typeable ) instance Show Addr where showsPrec _ (Addr a) = showString "0x" . showHex (fromIntegral (I# (addr2Int# a)) :: Word) instance Eq Addr where Addr a# == Addr b# = isTrue# (eqAddr# a# b#) Addr a# /= Addr b# = isTrue# (neAddr# a# b#) instance Ord Addr where Addr a# > Addr b# = isTrue# (gtAddr# a# b#) Addr a# >= Addr b# = isTrue# (geAddr# a# b#) Addr a# < Addr b# = isTrue# (ltAddr# a# b#) Addr a# <= Addr b# = isTrue# (leAddr# a# b#) instance Data Addr where toConstr _ = error "toConstr" gunfold _ _ = error "gunfold" dataTypeOf _ = mkNoRepType "Data.Primitive.Types.Addr" -- | The null address nullAddr :: Addr nullAddr = Addr nullAddr# infixl 6 `plusAddr`, `minusAddr` infixl 7 `remAddr` -- | Offset an address by the given number of bytes plusAddr :: Addr -> Int -> Addr plusAddr (Addr a#) (I# i#) = Addr (plusAddr# a# i#) -- | Distance in bytes between two addresses. The result is only valid if the -- difference fits in an 'Int'. minusAddr :: Addr -> Addr -> Int minusAddr (Addr a#) (Addr b#) = I# (minusAddr# a# b#) -- | The remainder of the address and the integer. remAddr :: Addr -> Int -> Int remAddr (Addr a#) (I# i#) = I# (remAddr# a# i#) -- | Convert an 'Addr' to an 'Int'. addrToInt :: Addr -> Int {-# INLINE addrToInt #-} addrToInt (Addr addr#) = I# (addr2Int# addr#) -- | convert `Addr` to `Ptr a` addrToPtr :: Addr -> Ptr a addrToPtr (Addr addr#) = Ptr addr# -- | convert `Ptr a` to `Addr` ptrToAddr :: Ptr a -> Addr ptrToAddr (Ptr p) = Addr p }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 18:34:59 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 18:34:59 -0000 Subject: [GHC] #15812: add System.Mem.Address to base In-Reply-To: <045.b345df82d6f6da10bcf57adbf4aa903f@haskell.org> References: <045.b345df82d6f6da10bcf57adbf4aa903f@haskell.org> Message-ID: <060.b2f2ed0ed98444aa255b46d1ff1eb46d@haskell.org> #15812: add System.Mem.Address to base -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: libraries/base | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D5268 Wiki Page: | -------------------------------------+------------------------------------- Changes (by carter): * status: new => patch * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 19:58:44 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 19:58:44 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow In-Reply-To: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> References: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> Message-ID: <057.5ea071bc9b1f84607784e37dff9a9533@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof recomp007 | space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrp): Well ` spaces/libraries/base/tests/CPUTime001.run CPUTime001}` now passes again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 21:07:54 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 21:07:54 -0000 Subject: [GHC] #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented In-Reply-To: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> References: <046.a4c8c72c9e9d68a07b93ce24b1eed9ca@haskell.org> Message-ID: <061.0e04f0cde394fa31cf9ec4d4d5830da8@haskell.org> #15078: base: Customary type class laws (e.g. for Eq) and non-abiding instances (e.g. Float) should be documented -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: Azel Type: feature request | Status: new Priority: normal | Milestone: 8.8.1 Component: Core Libraries | Version: 8.4.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:D4736 Wiki Page: | -------------------------------------+------------------------------------- Comment (by jpath): For `Num` I would expect `fromIntegral` to be a ring homomorphism. φ is a ring homomorphism if: 1. φ(x + y) = φ(x) + φ(y) 2. φ(x · y) = φ(x) · φ(y) 3. φ(1) = 1 We get φ(0) = 0, because φ(0) = φ(1 - 1) = φ(1) - φ(1) = 0, but we do need the “`fromIntegral 0` is addivite identity” law, to state the ring laws in the first place. In the case of dom φ = ℤ, we can also drop the second law, as φ is already uniquely defined by laws 1 and 3. So I would like to add `fromIntegral (a + b) = fromIntegral a + fromIntegral b` and maybe `fromIntegral (a * b) = fromIntegral a * fromIntegral b` even though it is redundant. Similarly I would like `fromRational` to be a ring homomorphism, again law 2 would be redundant, but we may still want it anyway. Note that these laws do not require any additional structure, as ℤ is the initial object in the category of rings and ℚ the initial object in the category of fields, so for every ring R a unique ring homomorphism φ: ℤ → R exists and for every field F a unique field homomorphism ℚ → F exists. The laws just ask that `fromIntegral` and `fromRational` are indeed these homomorphisms. Also `a / b = a * recip b`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 21:54:22 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 21:54:22 -0000 Subject: [GHC] #15813: -Wredundant-constrains emits warning even if constraint is narrowing type Message-ID: <050.e962430edfc77ee7de83579b620f9675@haskell.org> #15813: -Wredundant-constrains emits warning even if constraint is narrowing type -------------------------------------+------------------------------------- Reporter: jvanbruegge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Incorrect (amd64) | error/warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I am not sure if this is the same as #12700 , but when having a constraint that uses type equality to narrow down a type, -Wredundant-constraints still emits the warning. My particular example is: {{{#!hs class RowCons (label :: Symbol) (ty :: k) (tail :: Row k) (row :: Row k) | label row -> ty tail, label ty tail -> row instance (RowDelete s r ~ tail, RowPrepend s ty tail ~ r) => RowCons s ty tail r get :: forall s ty t r. RowCons s ty t r => Record r -> Proxy s -> ty get _ _ = undefined test_rec = get (Proxy :: Record ('Cons "foo" '[String]) (Proxy :: Proxy "foo") }}} With the RowCons constraint, the inferred type of test_rec is String (or [Char]), but without it it is an ambiguous `ty`. If the implementation of the type classes is needed, they can be found here: https://github.com/jvanbruegge/Megarecord/blob/f65fa5f29dc393e32d42fc87872416ec02405784/src/Megarecord.hs I tested this with 8.6.1 and 8.4.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 21:56:57 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 21:56:57 -0000 Subject: [GHC] #15813: -Wredundant-constrains emits warning even if constraint is narrowing type In-Reply-To: <050.e962430edfc77ee7de83579b620f9675@haskell.org> References: <050.e962430edfc77ee7de83579b620f9675@haskell.org> Message-ID: <065.79358a26d1849997abc583773ac788d5@haskell.org> #15813: -Wredundant-constrains emits warning even if constraint is narrowing type -------------------------------------+------------------------------------- Reporter: jvanbruegge | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) error/warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by jvanbruegge: Old description: > I am not sure if this is the same as #12700 , but when having a > constraint that uses type equality to narrow down a type, -Wredundant- > constraints still emits the warning. My particular example is: > > {{{#!hs > class RowCons (label :: Symbol) (ty :: k) (tail :: Row k) (row :: Row k) > | label row -> ty tail, label ty tail -> row > > instance (RowDelete s r ~ tail, RowPrepend s ty tail ~ r) => RowCons s ty > tail r > > get :: forall s ty t r. RowCons s ty t r => Record r -> Proxy s -> ty > get _ _ = undefined > > test_rec = get (Proxy :: Record ('Cons "foo" '[String]) (Proxy :: Proxy > "foo") > }}} > With the RowCons constraint, the inferred type of test_rec is String (or > [Char]), but without it it is an ambiguous `ty`. > > If the implementation of the type classes is needed, they can be found > here: > https://github.com/jvanbruegge/Megarecord/blob/f65fa5f29dc393e32d42fc87872416ec02405784/src/Megarecord.hs > > I tested this with 8.6.1 and 8.4.3 New description: I am not sure if this is the same as #12700 , but when having a constraint that uses type equality to narrow down a type, -Wredundant-constraints still emits the warning. My particular example is: {{{#!hs class RowCons (label :: Symbol) (ty :: k) (tail :: Row k) (row :: Row k) | label row -> ty tail, label ty tail -> row instance (RowDelete s r ~ tail, RowPrepend s ty tail ~ r) => RowCons s ty tail r get :: forall s ty t r. RowCons s ty t r => Record r -> Proxy s -> ty get _ _ = undefined test_rec = get (Proxy :: Record ('Cons "foo" '[String])) (Proxy :: Proxy "foo") }}} With the RowCons constraint, the inferred type of test_rec is String (or [Char]), but without it it is an ambiguous `ty`. If the implementation of the type families is needed, they can be found here: https://github.com/jvanbruegge/Megarecord/blob/f65fa5f29dc393e32d42fc87872416ec02405784/src/Megarecord.hs I tested this with 8.6.1 and 8.4.3 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 23:00:12 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 23:00:12 -0000 Subject: [GHC] #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity In-Reply-To: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> References: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> Message-ID: <060.3fd3a534d82c1d0f75238854b7df11d8@haskell.org> #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity -------------------------------------+------------------------------------- Reporter: claude | 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 fangyizhou): I digged into this and I am suspecting there is an integer overflow at `fromRat''` in `GHC.Float`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 23:02:53 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 23:02:53 -0000 Subject: [GHC] #4861: Documentation for base does not include special items In-Reply-To: <051.5ee4c1527610ef4964c665e655014652@haskell.org> References: <051.5ee4c1527610ef4964c665e655014652@haskell.org> Message-ID: <066.c07423680f9df1a612368d5f2a61a4e8@haskell.org> #4861: Documentation for base does not include special items -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: closed Priority: low | Milestone: 8.8.1 Component: Core Libraries | Version: 7.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: #10353 | Differential Rev(s): Phab:D5167 Wiki Page: | -------------------------------------+------------------------------------- Changes (by harpocrates): * related: => #10353 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 23:04:10 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 23:04:10 -0000 Subject: [GHC] #10353: Haddock for Data.List should list instances In-Reply-To: <047.1cc6b80fad871b5f70060a95f0b113c7@haskell.org> References: <047.1cc6b80fad871b5f70060a95f0b113c7@haskell.org> Message-ID: <062.bdb3d6c03ce2c6585f9d9f67a4f464fd@haskell.org> #10353: Haddock for Data.List should list instances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: harpocrates Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.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: | -------------------------------------+------------------------------------- Changes (by harpocrates): * owner: (none) => harpocrates Comment: This will be fixed with some upcoming Haddock-side changes (see https://github.com/haskell/haddock/issues/368). I'll close this when said changes are merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Oct 26 23:21:18 2018 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Oct 2018 23:21:18 -0000 Subject: [GHC] #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity In-Reply-To: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> References: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> Message-ID: <060.146713f655446068f769db0d45af4a03@haskell.org> #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity -------------------------------------+------------------------------------- Reporter: claude | 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 fangyizhou): {{{ main = do print 1e646457008 -- This is infinity print 1e646457009 -- This incorrectly printed 0.0 print 1e1555550000 -- This is still infinity print 1e1000000000 -- This incorrectly printed 0.0 }}} This is some wraparound behaviour, which is why I thought there is an integer overflow. I used `trace` to print the value of `(I# (ln# -# ld# +# 1# -# md#))` (https://github.com/ghc/ghc/blob/21f0f56164f50844c2150c62f950983b2376f8b6/libraries/base/GHC/Float.hs#L1072) 1e646457008 -> 2147483645 (infinity) 1e646457009 -> 2147483648 (0.0, overflow to negative) 1e1000000000 -> 3321928042 (infinity, overflow to positive) 1e1555550000 -> 5167425196 (0.0, overflow to negative) Any suggestions on how to fix? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 00:16:15 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 00:16:15 -0000 Subject: [GHC] #11238: Redesign the dynamic linking on ELF systems In-Reply-To: <047.b64204058d590ba33e44f36f6140b2e6@haskell.org> References: <047.b64204058d590ba33e44f36f6140b2e6@haskell.org> Message-ID: <062.6f4726deec1d9b1ca8f2adb24fad3e11@haskell.org> #11238: Redesign the dynamic linking on ELF systems -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: task | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.3 (Linker) | Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: 9237, 9498, | 11042, 11499, 12684 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 Sat Oct 27 00:16:56 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 00:16:56 -0000 Subject: [GHC] #11042: Template Haskell / GHCi does not respect extra-lib-dirs In-Reply-To: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> References: <044.eb43e7f9b5666e68e3df817728c4c87b@haskell.org> Message-ID: <059.2c0d508f5ed82c92c48052e299580a2a@haskell.org> #11042: Template Haskell / GHCi does not respect extra-lib-dirs -------------------------------------+------------------------------------- Reporter: mboes | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 #5289 | Differential Rev(s): Phab:D5170 #12753 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by Ericson2314): * cc: Ericson2314 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 01:48:00 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 01:48:00 -0000 Subject: [GHC] #15786: Hi Haddock: Enable haddock to generate docs from .hi-files In-Reply-To: <046.3eb0cf9aabf2ed86b7408b08e6e3c569@haskell.org> References: <046.3eb0cf9aabf2ed86b7408b08e6e3c569@haskell.org> Message-ID: <061.88a008f677b28a14c0d8cd4b504d198f@haskell.org> #15786: Hi Haddock: Enable haddock to generate docs from .hi-files -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5067 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sjakobi): One subproblem of Hi Haddock is that if we serialize a module's avails in the order in which they ought to appear in the haddocks, we create some redundancy with the existing `mi_exports`. I have opened https://github.com/haskell/haddock/issues/956 to discuss this issue. Comments are very welcome! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 03:38:30 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 03:38:30 -0000 Subject: [GHC] #15814: Orphan Instance Overlap Error Message Message-ID: <050.c7dbb48503048a9c450a5cfe725f299f@haskell.org> #15814: Orphan Instance Overlap Error Message -------------------------------------+------------------------------------- Reporter: parsonsmatt | 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: -------------------------------------+------------------------------------- I'm working on moving some code around which unfortunately relies on orphan instances. This is the error I get: {{{ /home/matt/Projects/cardano-sl/wallet- new/src/Cardano/Wallet/API/V1/Types.hs:1794:27: error: • Overlapping instances for Arbitrary (NonEmpty PaymentDistribution) arising from a use of ‘arbitrary’ Matching instances: instance Arbitrary a => Arbitrary (NonEmpty a) -- Defined in ‘Pos.Util.Example’ instance [safe] Arbitrary a => Arbitrary (NonEmpty a) -- Defined in ‘quickcheck- instances-0.3.18:Test.QuickCheck.Instances.Semigroup’ • In the second argument of ‘(<*>)’, namely ‘arbitrary’ In the first argument of ‘(<*>)’, namely ‘Payment <$> arbitrary <*> arbitrary’ In the first argument of ‘(<*>)’, namely ‘Payment <$> arbitrary <*> arbitrary <*> arbitrary’ | 1794 | <*> arbitrary | ^^^^^^^^^ }}} The first instance is the one that I have defined. The second is defined in library code upstream -- great! I want to use that one instead. However, I don't have a clue which module import is providing that instance. It would be *fantastic* if there was an additional line that says which module imported the instance, or brought it into scope. Multiple modules might do this; in this case, reporting any of them would be fine. Eg: {{{ /home/matt/Projects/cardano-sl/wallet- new/src/Cardano/Wallet/API/V1/Types.hs:1794:27: error: • Overlapping instances for Arbitrary (NonEmpty PaymentDistribution) arising from a use of ‘arbitrary’ Matching instances: instance Arbitrary a => Arbitrary (NonEmpty a) -- Defined in ‘Pos.Util.Example’ -- and imported via | 186 | import Cardano.Wallet.API.V1.Swagger.Example | instance [safe] Arbitrary a => Arbitrary (NonEmpty a) -- Defined in ‘quickcheck- instances-0.3.18:Test.QuickCheck.Instances.Semigroup’ -- and imported via | ??? | this information would literally make my day | • In the second argument of ‘(<*>)’, namely ‘arbitrary’ In the first argument of ‘(<*>)’, namely ‘Payment <$> arbitrary <*> arbitrary’ In the first argument of ‘(<*>)’, namely ‘Payment <$> arbitrary <*> arbitrary <*> arbitrary’ | 1794 | <*> arbitrary | ^^^^^^^^^ }}} I'll have to binary search the import list to try and figure out which module is bringing the instance into scope otherwise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 06:35:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 06:35:11 -0000 Subject: [GHC] #15779: Follow-ups to D5169 In-Reply-To: <046.2d2f72ea3821ecb52abedacaf1c0155d@haskell.org> References: <046.2d2f72ea3821ecb52abedacaf1c0155d@haskell.org> Message-ID: <061.0587251f523192ba7422b3830759a6c4@haskell.org> #15779: Follow-ups to D5169 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5270 Wiki Page: | -------------------------------------+------------------------------------- Changes (by watashi): * differential: => Phab:D5270 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 06:38:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 06:38:22 -0000 Subject: [GHC] #15779: Follow-ups to D5169 In-Reply-To: <046.2d2f72ea3821ecb52abedacaf1c0155d@haskell.org> References: <046.2d2f72ea3821ecb52abedacaf1c0155d@haskell.org> Message-ID: <061.31b4501cbb0ce413c4f3ad9528b1705f@haskell.org> #15779: Follow-ups to D5169 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5270 Wiki Page: | -------------------------------------+------------------------------------- Comment (by watashi): For (2), I put up Phab:D5270 to build profiling LibGhci in Hadrian as well. For (1), is LibGhci only used by statically linked ghci? So only windows distribution is affected by this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 07:33:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 07:33:14 -0000 Subject: [GHC] #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity In-Reply-To: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> References: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> Message-ID: <060.87979f613c4f34fe0e2b9befec40d625@haskell.org> #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity -------------------------------------+------------------------------------- Reporter: claude | 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: | -------------------------------------+------------------------------------- Changes (by osa1): * cc: osa1 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 08:37:00 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 08:37:00 -0000 Subject: [GHC] #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity In-Reply-To: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> References: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> Message-ID: <060.b2cfe52afd37649e5a2f45ffd3cdcac7@haskell.org> #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity -------------------------------------+------------------------------------- Reporter: claude | 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 fangyizhou): I found the issue. In `rtsPrimFloat.c`, a `StgInt` is passed as an argument to `ldexp`, which expects an `int` for the argument. On platforms where `StgInt` is 64-bit and `int` is 32-bit wraparound behaviour will be observed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 09:31:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 09:31:07 -0000 Subject: [GHC] #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity In-Reply-To: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> References: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> Message-ID: <060.a641873bc900953e75de903d23d555fd@haskell.org> #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity -------------------------------------+------------------------------------- Reporter: claude | Owner: fangyizhou 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: | PhabLink:D5271 -------------------------------------+------------------------------------- Changes (by fangyizhou): * owner: (none) => fangyizhou * differential: => PhabLink:D5271 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 09:36:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 09:36:47 -0000 Subject: [GHC] #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity In-Reply-To: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> References: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> Message-ID: <060.87dd4d655d659c3153f3e6844e3697ea@haskell.org> #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity -------------------------------------+------------------------------------- Reporter: claude | Owner: fangyizhou Type: bug | Status: patch 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): Phab:D5271 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: PhabLink:D5271 => Phab:D5271 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 10:13:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 10:13:39 -0000 Subject: [GHC] #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity In-Reply-To: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> References: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> Message-ID: <060.611a1d3849fb1b414b22db7a597a0e84@haskell.org> #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity -------------------------------------+------------------------------------- Reporter: claude | Owner: fangyizhou Type: bug | Status: patch 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): Phab:D5271 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): @fangyizhou, have you tested Phab:D5271 with the last case in the description ? Even on Windows 64, `1e1000000000 :: Double` consumes GBs of memory. Maybe the problem still exists with this patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 10:33:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 10:33:25 -0000 Subject: [GHC] #15808: Master sefaults on windows during aeson build when stage2 libs have dwarf enabled. In-Reply-To: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> References: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> Message-ID: <062.ccfd9b437020ef8b3075d5f29daa78d3@haskell.org> #15808: Master sefaults on windows during aeson build when stage2 libs have dwarf enabled. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): I've traced it back to ocRunInit_PEi386 so far. There in the call to `(*init)` we trigger an access exception by calling into the target address. I've seen some changes in related linker code were made recently. I will try to bisect that. {{{ bool ocRunInit_PEi386 ( ObjectCode *oc ) { if (!oc || !oc->info || !oc->info->init) { return true; } int argc, envc; char **argv, **envv; getProgArgv(&argc, &argv); getProgEnvv(&envc, &envv); Section section = *oc->info->init; ASSERT(SECTIONKIND_INIT_ARRAY == section.kind); uint8_t *init_startC = section.start; init_t *init_start = (init_t*)init_startC; init_t *init_end = (init_t*)(init_startC + section.size); // ctors are run *backwards*! for (init_t *init = init_end - 1; init >= init_start; init--) (*init)(argc, argv, envv); freeProgEnvv(envc, envv); releaseOcInfo (oc); return true; } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 10:38:51 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 10:38:51 -0000 Subject: [GHC] #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity In-Reply-To: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> References: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> Message-ID: <060.723876f2cf0581030dc7de416a62e6f0@haskell.org> #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity -------------------------------------+------------------------------------- Reporter: claude | Owner: fangyizhou Type: bug | Status: patch 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): Phab:D5271 Wiki Page: | -------------------------------------+------------------------------------- Comment (by fangyizhou): Replying to [comment:10 sighingnow]: > @fangyizhou, have you tested Phab:D5271 with the last case in the description ? Even on Windows 64, `1e1000000000 :: Double` consumes GBs of memory. Maybe the problem still exists with this patch. What do you mean? I didn't fix the memory issue because line 1 of this bug report says this matters correctness instead of performace -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 10:45:22 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 10:45:22 -0000 Subject: [GHC] #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity In-Reply-To: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> References: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> Message-ID: <060.ebee912a01cfb56ad322e8a534e4f4b8@haskell.org> #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity -------------------------------------+------------------------------------- Reporter: claude | Owner: fangyizhou Type: bug | Status: patch 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): Phab:D5271 Wiki Page: | -------------------------------------+------------------------------------- Comment (by sighingnow): Replying to [comment:11 fangyizhou]: > What do you mean? I didn't fix the memory issue because line 1 of this bug report says this matters correctness instead of performace Well, thanks for the clarification :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 11:21:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 11:21:09 -0000 Subject: [GHC] #15529: runtime bug when profiling retainers In-Reply-To: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> References: <046.4c9b79c30f29fd493993be5df7c9cc48@haskell.org> Message-ID: <061.13fd4d9bd10292470d26104d2386b3e8@haskell.org> #15529: runtime bug when profiling retainers -------------------------------------+------------------------------------- Reporter: flip101 | 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:D5075 Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): User plea: could you milestone this to 8.4.5 once such milestone exists? Ömer says this should be rather safe to merge and possibly it's the last bit needed for my code to retainer and biographical profile correctly (I'm stuck at 8.4 due to Windows Vista compatibility, ghcjs compatiblity and a couple of other packages that haven't yet caught up with 8.6). Thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 11:42:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 11:42:25 -0000 Subject: [GHC] #15608: Segfault in retainer profiling In-Reply-To: <043.5de2d12576332caf387b4ed18691b19e@haskell.org> References: <043.5de2d12576332caf387b4ed18691b19e@haskell.org> Message-ID: <058.ed747fa16450efc9702a8d8f58de10ae@haskell.org> #15608: Segfault in retainer profiling -------------------------------------+------------------------------------- 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:D5134 Wiki Page: | -------------------------------------+------------------------------------- Comment (by MikolajKonarski): I see that Phab:D5134 is merged, but not to 8.4 branch. Could we milestone this to 8.4.5 once such milestone exists? Ömer says this should be rather safe to merge to 8.4. Thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 12:57:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 12:57:09 -0000 Subject: [GHC] #15814: Orphan Instance Overlap Error Message In-Reply-To: <050.c7dbb48503048a9c450a5cfe725f299f@haskell.org> References: <050.c7dbb48503048a9c450a5cfe725f299f@haskell.org> Message-ID: <065.4433a4236f5ac6b95ad3a5c4fc2e7f68@haskell.org> #15814: Orphan Instance Overlap Error Message -------------------------------------+------------------------------------- Reporter: parsonsmatt | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => newcomer Comment: Good idea. I don't think this would be that hard to do, given that we do something similar for other errors already. Here is an example of an ambiguous name occurrence error message (taken from the `tcfail037` test case): {{{ tcfail037.hs:7:11: error: Ambiguous occurrence ‘+’ It could refer to either ‘Prelude.+’, imported from ‘Prelude’ at tcfail037.hs:3:8-17 (and originally defined in ‘GHC.Num’) or ‘ShouldFail.+’, defined at tcfail037.hs:10:5 }}} That "and originally defined in ..." part is exactly what we need. The code for this error message can be found [http://git.haskell.org/ghc.git/blob/23956b2ada690c78a134fe6d149940c777c7efcc:/compiler/basicTypes/RdrName.hs#l1251 here], in `ppr_defn_site`. We'd just need to incorporate similar logic to the function [http://git.haskell.org/ghc.git/blob/23956b2ada690c78a134fe6d149940c777c7efcc:/compiler/typecheck/TcErrors.hs#l2534 here] which constructs error messages for overlapping instances. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 15:55:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 15:55:21 -0000 Subject: [GHC] #15786: Hi Haddock: Enable haddock to generate docs from .hi-files In-Reply-To: <046.3eb0cf9aabf2ed86b7408b08e6e3c569@haskell.org> References: <046.3eb0cf9aabf2ed86b7408b08e6e3c569@haskell.org> Message-ID: <061.58d9eadd1310e055c4e66f95e7248e48@haskell.org> #15786: Hi Haddock: Enable haddock to generate docs from .hi-files -------------------------------------+------------------------------------- Reporter: sjakobi | Owner: sjakobi Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5067 Wiki Page: | -------------------------------------+------------------------------------- Changes (by sjakobi): * owner: (none) => sjakobi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 15:57:34 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 15:57:34 -0000 Subject: [GHC] #15812: add System.Mem.Address to base In-Reply-To: <045.b345df82d6f6da10bcf57adbf4aa903f@haskell.org> References: <045.b345df82d6f6da10bcf57adbf4aa903f@haskell.org> Message-ID: <060.9df196202569a2181663b1bdc24236c1@haskell.org> #15812: add System.Mem.Address to base -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: libraries/base | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5268 Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * differential: D5268 => Phab:D5268 Comment: Fixed Phabricator link. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 16:37:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 16:37:28 -0000 Subject: [GHC] #15815: problem with splicing type into constraint Message-ID: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> #15815: problem with splicing type into constraint -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.6.1 Haskell | 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: -------------------------------------+------------------------------------- Consider the following two-module example. (as gist: https://gist.github.com/int-e/a666991423c10150bd99dd0e874d6150) {{{#!hs {-# LANGUAGE TemplateHaskell #-} module A where mkFoo tyQ = [d| foo :: a ~ $(tyQ) => a foo = undefined |] }}} {{{#!hs {-# LANGUAGE TemplateHaskell, GADTs #-} module B where import A mkFoo [t| Int -> Int |] }}} This loads fine in ghc-8.4.2, but with ghc-8.6.1 and current head (commit 578012be13eb1548050d51c0a23bd1a98423f03e), the splice goes wrong: {{{ $ ghci B.hs GHCi, version 8.6.1: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling A ( A.hs, interpreted ) [2 of 2] Compiling B ( B.hs, interpreted ) B.hs:7:1: error: • Expected a type, but ‘a_a4uD ~ Int’ has kind ‘Constraint’ • In the type signature: foo :: a_a4uD ~ Int -> Int => a_a4uD | 7 | mkFoo [t| Int -> Int |] | ^^^^^^^^^^^^^^^^^^^^^^^ Failed, one module loaded. *A> }}} As a workaround one can define a type alias for the `Int -> Int` type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 16:58:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 16:58:36 -0000 Subject: [GHC] #15645: TypeChecking of Monad patterns incorrect with RebindableSyntax and OverloadedStrings In-Reply-To: <051.1afac0be4b689267d905f3e66b5a2d7d@haskell.org> References: <051.1afac0be4b689267d905f3e66b5a2d7d@haskell.org> Message-ID: <066.2baf273b6ffc7f99abb2bd21cff9f76a@haskell.org> #15645: TypeChecking of Monad patterns incorrect with RebindableSyntax and OverloadedStrings -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: shayne- | fletcher-da Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5251 Wiki Page: | -------------------------------------+------------------------------------- Comment (by shayne-fletcher-da): Updated revision to Diff 18486. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 17:56:39 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 17:56:39 -0000 Subject: [GHC] #15351: QuantifiedConstraints ignore FunctionalDependencies In-Reply-To: <049.c965c400807873236afd2b5848198ad6@haskell.org> References: <049.c965c400807873236afd2b5848198ad6@haskell.org> Message-ID: <064.1f45d4ca7f490516ddd48e54c74feca8@haskell.org> #15351: QuantifiedConstraints ignore FunctionalDependencies -------------------------------------+------------------------------------- Reporter: aaronvargo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.5 checker) | Keywords: Resolution: | QuantifiedConstraints Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | 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 Oct 27 18:23:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 18:23:47 -0000 Subject: [GHC] #15815: problem with splicing type into constraint In-Reply-To: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> References: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> Message-ID: <059.6196a9e5f655198107c8fc66cb46ffdf@haskell.org> #15815: problem with splicing type into constraint -------------------------------------+------------------------------------- Reporter: int-e | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.1 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: | -------------------------------------+------------------------------------- Description changed by int-e: Old description: > Consider the following two-module example. (as gist: > https://gist.github.com/int-e/a666991423c10150bd99dd0e874d6150) > {{{#!hs > {-# LANGUAGE TemplateHaskell #-} > module A where > > mkFoo tyQ = [d| > foo :: a ~ $(tyQ) => a > foo = undefined > |] > }}} > > {{{#!hs > {-# LANGUAGE TemplateHaskell, GADTs #-} > module B where > > import A > > mkFoo [t| Int -> Int |] > }}} > > This loads fine in ghc-8.4.2, but with ghc-8.6.1 and current head (commit > 578012be13eb1548050d51c0a23bd1a98423f03e), the splice goes wrong: > {{{ > $ ghci B.hs > GHCi, version 8.6.1: http://www.haskell.org/ghc/ :? for help > [1 of 2] Compiling A ( A.hs, interpreted ) > [2 of 2] Compiling B ( B.hs, interpreted ) > > B.hs:7:1: error: > • Expected a type, but ‘a_a4uD ~ Int’ has kind ‘Constraint’ > • In the type signature: foo :: a_a4uD ~ Int -> Int => a_a4uD > | > 7 | mkFoo [t| Int -> Int |] > | ^^^^^^^^^^^^^^^^^^^^^^^ > Failed, one module loaded. > *A> > }}} > > As a workaround one can define a type alias for the `Int -> Int` type. New description: Consider the following two-module example. (as gist: https://gist.github.com/int-e/a666991423c10150bd99dd0e874d6150) {{{#!hs {-# LANGUAGE TemplateHaskell #-} module A where mkFoo tyQ = [d| foo :: a ~ $(tyQ) => a foo = undefined |] }}} {{{#!hs {-# LANGUAGE TemplateHaskell, GADTs #-} module B where import A mkFoo [t| Int -> Int |] }}} This loads fine in ghc-8.4.2, but with ghc-8.6.1 and current head (commit 23956b2ada690c78a134fe6d149940c777c7efcc), the splice goes wrong: {{{ $ ghci B.hs GHCi, version 8.6.1: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling A ( A.hs, interpreted ) [2 of 2] Compiling B ( B.hs, interpreted ) B.hs:7:1: error: • Expected a type, but ‘a_a4uD ~ Int’ has kind ‘Constraint’ • In the type signature: foo :: a_a4uD ~ Int -> Int => a_a4uD | 7 | mkFoo [t| Int -> Int |] | ^^^^^^^^^^^^^^^^^^^^^^^ Failed, one module loaded. *A> }}} As a workaround one can define a type alias for the `Int -> Int` type. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 18:37:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 18:37:52 -0000 Subject: [GHC] #15816: Visible kind applications + data family: `U :: Type' said to be of kind `k0 -> k1` in error message Message-ID: <051.7ad8c9c507f1bdc5ee6ac158821e5a9c@haskell.org> #15816: Visible kind applications + data family: `U :: Type' said to be of kind `k0 -> k1` in error message -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Using the [https://phabricator.haskell.org/D5229 visible kind applications (D5229)] (#12045) patch. GHC erroneously calls `U :: Type` a "function" of kind `k0 -> k1` if I understand this right, {{{ $ ghci GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help Prelude> :set prompt "> " > import Data.Kind (Type) > > :set -XTypeFamilies > :set -XTypeApplications > > data family U :: Type > data instance U @Int :7:1: error: • Cannot apply function of kind ‘k0 -> k1’ to visible kind argument ‘Int’ • In the data instance declaration for ‘U’ > }}} I expect something like "Cannot apply type `U` to visible kind argument `Int`" or {{{ > data instance U Int = MkU :7:1: error: • Expected kind ‘* -> *’, but ‘U’ has kind ‘*’ • In the data instance declaration for ‘U’ > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 18:51:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 18:51:14 -0000 Subject: =?utf-8?q?=5BGHC=5D_=2315817=3A_Visible_kind_application_+_data_?= =?utf-8?b?ZmFtaWx5ID0gR0hDIHBhbmljLCDigJhpbXBvc3NpYmxl4oCZIGhh?= =?utf-8?q?ppened?= Message-ID: <051.141a919b387f59325ecc3d36f5a6a348@haskell.org> #15817: Visible kind application + data family = GHC panic, ‘impossible’ happened -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# Language RankNTypes #-} {-# Language TypeApplications #-} {-# Language PolyKinds #-} {-# Language KindSignatures #-} {-# Language TypeFamilies #-} data family Pair :: forall a. forall b. * data instance Pair @a @b = MkPair a b }}} {{{ $ ghci -ignore-dot-ghci 593_bug.hs GHCi, version 8.7.20181017: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 593_bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181017 for x86_64-unknown-linux): ASSERT failed! kind axiom D:R:Pairabab0 :: forall a b (a :: a) (b :: b). Pair = R:Pairabab -- Defined at 593_bug.hs:8:15 forall k k (a :: k) (b :: k). * forall a b -> a -> b -> * Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/FamInst.hs:158:61 in ghc:FamInst Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 18:55:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 18:55:07 -0000 Subject: [GHC] #14268: Implement Explicit Foralls Proposal In-Reply-To: <046.b2c6e5199adb1a263d1f797400e3472d@haskell.org> References: <046.b2c6e5199adb1a263d1f797400e3472d@haskell.org> Message-ID: <061.fe62ca6500416493fa2ce79f942f0e08@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: #11719, #13809 | Differential Rev(s): Phab:D4894 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"512eeb9bb9a81e915bfab25ca16bc87c62252064/ghc" 512eeb9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="512eeb9bb9a81e915bfab25ca16bc87c62252064" More explicit foralls (GHC Proposal 0007) Allow the user to explicitly bind type/kind variables in type and data family instances (including associated instances), closed type family equations, and RULES pragmas. Follows the specification of GHC Proposal 0007, also fixes #2600. Advised by Richard Eisenberg. This modifies the Template Haskell AST -- old code may break! Other Changes: - convert HsRule to a record - make rnHsSigWcType more general - add repMaybe to DsMeta Includes submodule update for Haddock. Test Plan: validate Reviewers: goldfire, bgamari, alanz Subscribers: simonpj, RyanGlScott, goldfire, rwbarton, thomie, mpickering, carter GHC Trac Issues: #2600, #14268 Differential Revision: https://phabricator.haskell.org/D4894 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 18:55:07 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 18:55:07 -0000 Subject: [GHC] #2600: Bind type variables in RULES In-Reply-To: <046.60d3c1925e5a0ef8b7d1f9b2b5ebeabc@haskell.org> References: <046.60d3c1925e5a0ef8b7d1f9b2b5ebeabc@haskell.org> Message-ID: <061.788eff49ae26f156ecd0a824598a228f@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: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"512eeb9bb9a81e915bfab25ca16bc87c62252064/ghc" 512eeb9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="512eeb9bb9a81e915bfab25ca16bc87c62252064" More explicit foralls (GHC Proposal 0007) Allow the user to explicitly bind type/kind variables in type and data family instances (including associated instances), closed type family equations, and RULES pragmas. Follows the specification of GHC Proposal 0007, also fixes #2600. Advised by Richard Eisenberg. This modifies the Template Haskell AST -- old code may break! Other Changes: - convert HsRule to a record - make rnHsSigWcType more general - add repMaybe to DsMeta Includes submodule update for Haddock. Test Plan: validate Reviewers: goldfire, bgamari, alanz Subscribers: simonpj, RyanGlScott, goldfire, rwbarton, thomie, mpickering, carter GHC Trac Issues: #2600, #14268 Differential Revision: https://phabricator.haskell.org/D4894 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 18:58:06 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 18:58:06 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2315817=3A_Visible_kind_application_+?= =?utf-8?q?_data_family_=3D_GHC_panic=2C_=E2=80=98impossible?= =?utf-8?b?4oCZIGhhcHBlbmVk?= In-Reply-To: <051.141a919b387f59325ecc3d36f5a6a348@haskell.org> References: <051.141a919b387f59325ecc3d36f5a6a348@haskell.org> Message-ID: <066.ec6cab01fcaaaad0ffb822acd18ae300@haskell.org> #15817: Visible kind application + data family = GHC panic, ‘impossible’ happened -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * keywords: TypeApplications => TypeInType * cc: mnguyen (removed) Comment: Minimized example that compiles fine on GHC 8.6.1 but fails on HEAD {{{#!hs {-# Language RankNTypes #-} {-# Language PolyKinds #-} {-# Language TypeFamilies #-} data family X :: forall (a :: *). * data instance X = MkX }}} {{{ $ ghci-stage2 -ignore-dot-ghci --interactive ~/hs/593_bug.hs GHCi, version 8.7.20181025: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /home/baldur/hs/593_bug.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.7.20181025 for x86_64-unknown-linux): ASSERT failed! kind axiom D:R:Xa0 :: X = R:Xa -- Defined at /home/baldur/hs/593_bug.hs:6:15 forall a. * * -> * Call stack: CallStack (from HasCallStack): callStackDoc, called at compiler/utils/Outputable.hs:1160:37 in ghc:Outputable pprPanic, called at compiler/utils/Outputable.hs:1219:5 in ghc:Outputable assertPprPanic, called at compiler/typecheck/FamInst.hs:158:61 in ghc:FamInst Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} so it does not actually depend on VKA. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 19:08:52 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 19:08:52 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2315817=3A_Data_family_quantification?= =?utf-8?b?ID0gR0hDIHBhbmljLCDigJhpbXBvc3NpYmxl4oCZIGhhcHBlbmVk?= =?utf-8?q?_=28was=3A_Visible_kind_application_+_data_family_=3D_?= =?utf-8?b?R0hDIHBhbmljLCDigJhpbXBvc3NpYmxl4oCZIGhhcHBlbmVkKQ==?= In-Reply-To: <051.141a919b387f59325ecc3d36f5a6a348@haskell.org> References: <051.141a919b387f59325ecc3d36f5a6a348@haskell.org> Message-ID: <066.96830bb77f6c672e158c0580c4b9806b@haskell.org> #15817: Data family quantification = GHC panic, ‘impossible’ happened -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 20:21:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 20:21:32 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.207d52e9b99244c3bf709ffb18810d77@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): i'll see about doing the nofib runs this weekend -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 21:03:44 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 21:03:44 -0000 Subject: [GHC] #15815: problem with splicing type into constraint In-Reply-To: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> References: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> Message-ID: <059.c8474271afb37e3ff86469cfc7c0c5e4@haskell.org> #15815: problem with splicing type into constraint -------------------------------------+------------------------------------- Reporter: int-e | Owner: RyanGlScott Type: bug | Status: new Priority: highest | Milestone: Component: Template Haskell | Version: 8.6.1 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): * owner: (none) => RyanGlScott * priority: normal => highest Comment: This appears to be my fault, since this regression was introduced in commit b9483981d128f55d8dae3f434f49fa6b5b30c779 (`Remove HsEqTy and XEqTy`). I'll take a look. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 21:15:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 21:15:37 -0000 Subject: [GHC] #15815: problem with splicing type into constraint In-Reply-To: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> References: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> Message-ID: <059.10b247948aee0efd5604a730e46a329a@haskell.org> #15815: problem with splicing type into constraint -------------------------------------+------------------------------------- Reporter: int-e | Owner: RyanGlScott Type: bug | Status: new Priority: highest | Milestone: Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Simpler example that only requires one module: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TemplateHaskell #-} module Bug where $([d| foo :: a ~ (Int -> Int) => a foo = undefined |]) }}} {{{ $ /opt/ghc/8.4.4/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) $ /opt/ghc/8.6.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:5:3: error: • Expected a type, but ‘a_a44c ~ Int’ has kind ‘Constraint’ • In the type signature: foo :: a_a44c ~ Int -> Int => a_a44c | 5 | $([d| foo :: a ~ (Int -> Int) => a | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... }}} Or, using fewer quotes: {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE TemplateHaskell #-} module Bug where import Language.Haskell.TH $(do foo <- newName "foo" a <- newName "a" pure [ SigD foo (ForallT [] [AppT (AppT EqualityT (VarT a)) (AppT (AppT ArrowT (ConT ''Int)) (ConT ''Int))] (VarT a)) , ValD (VarP foo) (NormalB (VarE 'undefined)) [] ]) }}} {{{ $ /opt/ghc/8.4.4/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) $ /opt/ghc/8.6.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:7:3: error: • Expected a type, but ‘a_a452 ~ Int’ has kind ‘Constraint’ • In the type signature: foo :: a_a452 ~ Int -> Int => a_a452 | 7 | $(do foo <- newName "foo" | ^^^^^^^^^^^^^^^^^^^^^^^... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 22:15:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 22:15:55 -0000 Subject: [GHC] #15815: problem with splicing type into constraint In-Reply-To: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> References: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> Message-ID: <059.1d638792009fc4fd8bac658087848957@haskell.org> #15815: problem with splicing type into constraint -------------------------------------+------------------------------------- Reporter: int-e | Owner: RyanGlScott Type: bug | Status: new Priority: highest | Milestone: Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #15760 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: goldfire (added) * related: => #15760 Comment: I believe I understand what is happening here. The problem is that when you roundtrip the following declaration through Template Haskell: {{{#!hs $([d| foo :: a ~ (Int -> Int) => a foo = undefined |]) }}} Then all parentheses are stripped away when converting this to the GHC AST. This has important consequences when processing `foo`'s type signature. Before the offending commit (that I linked to in comment:2), the context of `foo`'s type signature would become: {{{ HsEqTy a (HsOpTy Int (->) Int) }}} But after the offending commit, this becomes: {{{ HsOpTy a (~) (HsOpTy Int (->) Int) }}} Upon first glance, these would appear to be identical. But as it turns out, `HsEqTy` actually had special treatment in the renamer, which means that it was renamed as though one had implicitly added `HsParTy`s around both of its arguments. On the other hand, when GHC renaming sequences of `HsOpTy`s (as in the second example), no such thing happens. In essence, that AST corresponds to: {{{#!hs a ~ Int -> Int }}} GHC thinks that should be parenthesized as: {{{#!hs (a ~ Int) -> Int }}} Which leads to the error that we see in this ticket. A quick-and-dirty way to fix this would be to change `cvtTypeKind` such that when we convert an `EqualityT`, we parenthesize `~`'s arguments if they aren't parenthesized. In other words, apply this patch: {{{#!diff diff --git a/compiler/hsSyn/Convert.hs b/compiler/hsSyn/Convert.hs index 8b12a78..74a6011 100644 --- a/compiler/hsSyn/Convert.hs +++ b/compiler/hsSyn/Convert.hs @@ -1437,7 +1437,9 @@ cvtTypeKind ty_str ty EqualityT | [x',y'] <- tys' -> - returnL (HsOpTy noExt x' (noLoc eqTyCon_RDR) y') + let px = parenthesizeHsType opPrec x' + py = parenthesizeHsType opPrec y' + in returnL (HsOpTy noExt px (noLoc eqTyCon_RDR) py) | otherwise -> mk_apps (HsTyVar noExt NotPromoted (noLoc eqTyCon_RDR)) tys' }}} That makes the original program compile again, although it's just applying a bandage over a deeper wound—namely, that TH conversion strips away parentheses in the first place. goldfire, weren't you looking into fixing the parentheses issue in #15760? If so, perhaps your patch there would make for a more elegant fix for this ticket. On the other hand, if that still needs some work, I could whip up a stopgap solution now (based on the code above) so that this could be backported to a patch release if necessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 22:16:55 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 22:16:55 -0000 Subject: [GHC] #15760: Preserve parens in TH In-Reply-To: <047.bd515b636bed31bfe65d883c11cd9bb1@haskell.org> References: <047.bd515b636bed31bfe65d883c11cd9bb1@haskell.org> Message-ID: <062.4007497dd31362bf462165efa7ba1d47@haskell.org> #15760: Preserve parens in TH -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15815 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * related: => #15815 Comment: See #15815 for a notable example of a bug that this issue causes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 22:58:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 22:58:37 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.f6e2ad89a92133eddf4dfe94a1f86042@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Changes (by carter): * Attachment "nofib-report-two.txt" added. comparsion of clang and gcc built GHC at commit 578012be13eb1548050d51c0a23bd1a98423f03e on mac -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 23:05:21 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 23:05:21 -0000 Subject: [GHC] #15818: Bump template-haskell version to 2.15.0.0 Message-ID: <050.7dd82309efae97acbaeca8205c2e0f7b@haskell.org> #15818: Bump template-haskell version to 2.15.0.0 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template | Version: 8.7 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #2600, #14268 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Commit 512eeb9bb9a81e915bfab25ca16bc87c62252064 (`More explicit foralls (GHC Proposal 0007)`) introduced breaking changes to the Template Haskell AST. As a consequence of this, there are libraries in the wild that now fail to build on GHC HEAD (for instance, [https://github.com/glguy/th- abstraction/issues/55 th-abstraction]). We should properly bump the `template-haskell` library's version number to `2.15.0.0` so that these libraries can guard against these changes using `MIN_VERSION_template_haskell`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 23:07:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 23:07:43 -0000 Subject: [GHC] #15818: Bump template-haskell version to 2.15.0.0 In-Reply-To: <050.7dd82309efae97acbaeca8205c2e0f7b@haskell.org> References: <050.7dd82309efae97acbaeca8205c2e0f7b@haskell.org> Message-ID: <065.d2dc6844bc23716174afb8f5df761471@haskell.org> #15818: Bump template-haskell version to 2.15.0.0 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2600, #14268 | Differential Rev(s): Phab:D5272 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5272 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 23:12:00 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 23:12:00 -0000 Subject: [GHC] #14268: Implement Explicit Foralls Proposal In-Reply-To: <046.b2c6e5199adb1a263d1f797400e3472d@haskell.org> References: <046.b2c6e5199adb1a263d1f797400e3472d@haskell.org> Message-ID: <061.0a4f4425e853cb419354df5b3b8106c3@haskell.org> #14268: Implement Explicit Foralls Proposal -------------------------------------+------------------------------------- Reporter: johnleo | Owner: mayac Type: task | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.2.1 Resolution: fixed | Keywords: GHCProposal Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: 13809, 14198 Related Tickets: #11719, #13809 | Differential Rev(s): Phab:D4894 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: This is now fixed. Thanks, mayac! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 23:12:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 23:12:09 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.bc0d9467af59ee571fd58978d6562901@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): my GCC build is using my D4780 patch for stgcrun.c notable difference: compile times are like 5% better on average with the GCC built ghc, there also seems to be an average 2 percent advantage in GC times ... though i could be reading this wrong -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 23:13:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 23:13:01 -0000 Subject: [GHC] #2600: Bind type variables in RULES In-Reply-To: <046.60d3c1925e5a0ef8b7d1f9b2b5ebeabc@haskell.org> References: <046.60d3c1925e5a0ef8b7d1f9b2b5ebeabc@haskell.org> Message-ID: <061.53979020813d6ef9e55e4098074f2ffc@haskell.org> #2600: Bind type variables in RULES -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: feature request | Status: closed Priority: lowest | Milestone: 8.8.1 Component: Compiler | Version: 6.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | rename/should_compile/T2600 Blocked By: | Blocking: Related Tickets: #2110 | Differential Rev(s): Phab:D4894 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => rename/should_compile/T2600 * status: new => closed * resolution: => fixed * milestone: => 8.8.1 Comment: Thanks to mayac's hard work, we can now finally close this 10-year-old ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 23:18:23 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 23:18:23 -0000 Subject: [GHC] #11719: Cannot use higher-rank kinds with type families In-Reply-To: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> References: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> Message-ID: <062.c3bc3bd645a2895467466f02aab06dcd@haskell.org> #11719: Cannot use higher-rank kinds with type families -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | dependent/should_compile/T11719 Blocked By: | Blocking: Related Tickets: #13913, #14268 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Now that #14268 is implemented, we can work around this issue in a much less hacky way: {{{#!hs type family BaseType (k :: forall a. a ~> Type) (x :: b) :: Type where forall (k :: forall a. a ~> Type) x. BaseType k x = (@@) k x }}} That being said, the way that I originally thought this type family should have been defined: {{{#!hs type family BaseType (k :: forall a. a ~> Type) (x :: b) :: Type where BaseType (k :: forall a. a ~> Type) x = (@@) k x }}} Still does not kind-check: {{{ $ ghc/inplace/bin/ghc-stage2 Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:22:13: error: • Expected kind ‘forall a. a ~> *’, but ‘k’ has kind ‘a0 ~> *’ • In the first argument of ‘BaseType’, namely ‘(k :: forall a. a ~> Type)’ In the type family declaration for ‘BaseType’ | 22 | BaseType (k :: forall a. a ~> Type) x = (@@) k x | ^ }}} This feels like it ought to Just Work™, though. Should we keep this ticket open until this is possible? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 23:22:50 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 23:22:50 -0000 Subject: [GHC] #13809: TH-reified type family and data family instances have a paucity of kinds In-Reply-To: <050.0c3063c06a387a87a3b53a78ba487043@haskell.org> References: <050.0c3063c06a387a87a3b53a78ba487043@haskell.org> Message-ID: <065.e658df829c720426f18053aba62dcfc4@haskell.org> #13809: TH-reified type family and data family instances have a paucity of kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.0.1 Resolution: fixed | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14268 | Blocking: Related Tickets: #8953, #14268 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed * milestone: => 8.8.1 Comment: Now that #14268 is implemented, I claim that this is fixed. That is because when you reify `Foo` now, you get the following information: {{{#!hs FamilyI (DataFamilyD Foo.Foo [KindedTV a_6989586621679015908 StarT] (Just StarT)) [ DataInstD [] Foo.Foo (Just [KindedTV f_6989586621679015938 (AppT (AppT ArrowT (AppT (AppT ArrowT StarT) StarT)) StarT),KindedTV a_6989586621679015939 (AppT (AppT ArrowT StarT) StarT)]) [AppT (VarT f_6989586621679015938) (VarT a_6989586621679015939)] Nothing [] [] , DataInstD [] Foo.Foo (Just [KindedTV f_6989586621679015958 (AppT (AppT ArrowT StarT) StarT),KindedTV a_6989586621679015959 StarT]) [AppT (VarT f_6989586621679015958) (VarT a_6989586621679015959)] Nothing [] [] ] }}} In particular, we now have access to the exact kinds of `f` and `a` in each instance, which lets us properly distinguish them. Hooray! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Oct 27 23:45:13 2018 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Oct 2018 23:45:13 -0000 Subject: [GHC] #2600: Bind type variables in RULES In-Reply-To: <046.60d3c1925e5a0ef8b7d1f9b2b5ebeabc@haskell.org> References: <046.60d3c1925e5a0ef8b7d1f9b2b5ebeabc@haskell.org> Message-ID: <061.e590e8347585bfae505725f5a291d2d6@haskell.org> #2600: Bind type variables in RULES -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: feature request | Status: closed Priority: lowest | Milestone: 8.8.1 Component: Compiler | Version: 6.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | rename/should_compile/T2600 Blocked By: | Blocking: Related Tickets: #2110 | Differential Rev(s): Phab:D4894 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mayac): It's worth mentioning that this has not been ''completely'' addressed. The following is now accepted: {{{ {-# RULES "myrule" forall t a. forall f x. from (tmap f (to x :: t a)) = map f (from (to x :: t a)) #-} }}} but, as per #10595, it does not behave as one would expect – the rules `"Class op tmap"` and `"Class op to"` may fire first. See that ticket for the appropriate workaround. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 00:03:45 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 00:03:45 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.3daf07518e61e4cbca7649a7bd0bd725@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): seems theres still a performance gap in gcc vs clang, as per historical ticket https://ghc.haskell.org/trac/ghc/ticket/7602 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 00:10:17 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 00:10:17 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.90fed479379a4b32ff6d139de341c751@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): disregard this nofib report, i didn't do threaded executions -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 00:34:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 00:34:43 -0000 Subject: [GHC] #15819: COMPLETE pragma not listed in GHC manual index Message-ID: <047.48f16142afcc3744bbc0b8a826cce183@haskell.org> #15819: COMPLETE pragma not listed in GHC manual index -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I wanted information on the `COMPLETE` pragma. So I went to GHC's manual's index. And it isn't there! We should likely have some RST gubbins to support pragmas, in much the same way that we do for flags, as I'm sure this isn't only `COMPLETE`'s problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 02:08:33 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 02:08:33 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.b35160ef9336adf3278d0c02b30b74af@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): i did two different threaded runs, thres a clean HUGE difference on clang vs gcc, favoring gcc in the GC timings, the one program where this is strongly not the case is k nucleo tide, I'll attach these two sets of nofib runs here. nofib report i name "dirty" is merely "i didn't clean and rebuild right before running nofib". so its likely to be cleaner measurements if thermal throttling were an issue (i used the intel power gadget during the first run, and I idn't see a difference in peak average frequency between the two, at least when eyeballing it) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 02:09:10 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 02:09:10 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.1d3084d6dd71bdfa5032cff6fc2465fe@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Changes (by carter): * Attachment "cool-nofib-threaded-n4-report.txt" added. threaded with time to cool nofib, N4 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 02:09:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 02:09:46 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.dc4580a6b5042cd02f8a6042edbffa66@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Changes (by carter): * Attachment "dirty-cool-nofib-threaded-n4-report.txt" added. even more time to cool threaded n4 nofib comparison -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 02:15:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 02:15:37 -0000 Subject: [GHC] #15820: Document the proposals process in the GHC manual Message-ID: <047.f26a3edc97953dc3d8f97d5632ba8107@haskell.org> #15820: Document the proposals process in the GHC manual -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.1 Keywords: | 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-proposals process has proved robust, in my opinion. We should explicitly state that such a process exists and point users to it from the manual. This came up as I was documenting the solution to #15743 in the manual. The end result there is very much a free design decision, and I wanted to invite readers to propose changes if they disagree with the design. But there's no good way to do so, currently. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 03:49:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 03:49:02 -0000 Subject: [GHC] #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) In-Reply-To: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> References: <045.e2cdce9a070d6021bb0b0eba210932b9@haskell.org> Message-ID: <060.463d27824c12f28780e9d554662e9bd3@haskell.org> #15207: bad dwarf frame in stgRun.c when compiled with with gcc on mac and assembled by as/gcc/clang (aka apple clang assembler) -------------------------------------+------------------------------------- Reporter: carter | Owner: (none) Type: bug | Status: infoneeded Priority: normal | Milestone: 8.8.1 Component: Runtime System | Version: 8.4.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4781 Wiki Page: | -------------------------------------+------------------------------------- Changes (by carter): * Attachment "no-ht-dirty-cool-nofib-threaded-n4-report.txt" added. hyper threading disabled quad core threaded rts nofib -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 05:34:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 05:34:54 -0000 Subject: [GHC] #15646: ghci takes super long time to find the type of large fractional number In-Reply-To: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> References: <050.bf3dc390139c3159296f75808c90ac8d@haskell.org> Message-ID: <065.d6b943317c1041d2020651f5c8efd11c@haskell.org> #15646: ghci takes super long time to find the type of large fractional number -------------------------------------+------------------------------------- Reporter: Johannkokos | Owner: | JulianLeviston Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: GHCi | Version: 8.4.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by JulianLeviston): Still floundering :). Anyone have any suggestions about the following? it's still just as slow as before, it seems. {{{ HsRat _ fl _ -> case fl of FL { fl_signi = fl_signi, fl_exp = fl_exp } -> do mkRational <- dsLookupGlobalId mkRationalName litI <- mkIntegerExpr fl_signi litE <- mkIntegerExpr fl_exp return ((Var mkRational) `App` litI `App` litE) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 06:30:20 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 06:30:20 -0000 Subject: [GHC] #15608: Segfault in retainer profiling In-Reply-To: <043.5de2d12576332caf387b4ed18691b19e@haskell.org> References: <043.5de2d12576332caf387b4ed18691b19e@haskell.org> Message-ID: <058.266fabbee06f886eeb9e75ddad43aa57@haskell.org> #15608: Segfault in retainer profiling -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.5 Component: Profiling | Version: 8.5 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5134 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.6.1 => 8.4.5 Comment: I am quite doubtful that there will be a 8.4.5 but nevertheless, done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 08:36:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 08:36:01 -0000 Subject: [GHC] #9163: Ptr should have a phantom role In-Reply-To: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> References: <046.5c3968c593d0962ddf27c141bd7f78b5@haskell.org> Message-ID: <061.eca3e2f5eea247ce2cdf43b103949d4c@haskell.org> #9163: Ptr should have a phantom role -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | roles/should_compile/Roles2 Blocked By: | Blocking: Related Tickets: #9164 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dominic): My concerns are fixed here: https://github.com/haskell/vector/pull/224 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 12:06:47 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 12:06:47 -0000 Subject: [GHC] #15736: Testsuite failures from validate --slow In-Reply-To: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> References: <042.ee72b17740328cbf0fdbd62e4803427a@haskell.org> Message-ID: <057.642ab2cad5c2ceddd57b00646129db7c@haskell.org> #15736: Testsuite failures from validate --slow -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: at runtime | EtaExpandLevPoly T14936 T15349 | T2783 T4334 T7919 haddock.Cabal | haddock.base haddock.compiler | hpc_fork plugin-recomp-change | plugin-recomp-change-prof recomp007 | space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jrp): Some more detailed diagnostics: {{{ --- user001.run/user001.stdout.normalised 2018-10-28 11:40:13.328953922 +0000 +++ user001.run/user001.run.stdout.normalised 2018-10-28 11:40:13.328953922 +0000 @@ -6,6 +6,6 @@ getEffectiveUserName: OK getGroupEntryForID: OK getGroupEntryForName: OK -getAllGroupEntries: OK +getAllGroupEntries: ERROR: getAllGroupEntries: does not exist (No such file or directory) getUserEntryForID: OK -getAllUserEntries: OK +getAllUserEntries: ERROR: getAllUserEntries: does not exist (No such file or directory) *** unexpected failure for user001(normal) }}} Similarly {{{ Wrong exit code for T3816(normal)(expected 0 , actual 1 ) Stderr ( T3816 ): T3816: getAllGroupEntries: does not exist (No such file or directory) *** unexpected failure for T3816(normal) }}} For T7919, `GhostScript not available for hp2ps tests` sounds like it's my setup that's the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 15:02:03 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 15:02:03 -0000 Subject: [GHC] #15820: Document the proposals process in the GHC manual In-Reply-To: <047.f26a3edc97953dc3d8f97d5632ba8107@haskell.org> References: <047.f26a3edc97953dc3d8f97d5632ba8107@haskell.org> Message-ID: <062.ec69e4fc9206710594e90146990bb6b1@haskell.org> #15820: Document the proposals process in the GHC manual -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.1 Resolution: | Keywords: Operating System: 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 Sun Oct 28 15:25:40 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 15:25:40 -0000 Subject: [GHC] #15821: Implement constant folding for Naturals Message-ID: <046.f9a66ca4226a20e909943f505947aaf5@haskell.org> #15821: Implement constant folding for Naturals -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- #14465 has already gone a long way in improving the runtime performance of `Natural` numbers. However, we still lack constant folding for these numbers so there is money left on the table. To fix this you will want to implement rules similar to those for `Integer` in the `PrelRules` module. Additionally, you will need to comment back in the `CONSTANT_FOLDED` pragmas in `GHC.Natural` (see Phab:D5267) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 15:40:11 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 15:40:11 -0000 Subject: [GHC] #15822: template-haskell package lacks any real documentation Message-ID: <046.4b18e81891e57eeb8884a446a895125c@haskell.org> #15822: template-haskell package lacks any real documentation -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Just as it says on the tin. Your mission, if you choose to accept it: Look at the Haddocks for [Language.Haskell.TH.Syntax](http://hackage.haskell.org/package/template- haskell-2.14.0.0/docs/Language-Haskell-TH-Syntax.html), choose an undocumented declaration, and start writing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 15:44:25 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 15:44:25 -0000 Subject: [GHC] #15818: Bump template-haskell version to 2.15.0.0 In-Reply-To: <050.7dd82309efae97acbaeca8205c2e0f7b@haskell.org> References: <050.7dd82309efae97acbaeca8205c2e0f7b@haskell.org> Message-ID: <065.1565034f64f5c6bf554b25af35adcae5@haskell.org> #15818: Bump template-haskell version to 2.15.0.0 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2600, #14268 | Differential Rev(s): Phab:D5272 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"32f47e33f75efba9d61f7cca33158ea8a342b07e/ghc" 32f47e33/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="32f47e33f75efba9d61f7cca33158ea8a342b07e" Bump template-haskell version to 2.15.0.0 Summary: Commit 512eeb9bb9a81e915bfab25ca16bc87c62252064 (`More explicit foralls (GHC Proposal 0007)`) introduced breaking changes to the Template Haskell AST. As a consequence of this, there are libraries in the wild that now fail to build on GHC HEAD (for instance, `th-abstraction`). This properly bumps the `template-haskell` library's version number to `2.15.0.0` so that these libraries can guard against these changes using `MIN_VERSION_template_haskell`. Test Plan: ./validate Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15818 Differential Revision: https://phabricator.haskell.org/D5272 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 15:45:36 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 15:45:36 -0000 Subject: [GHC] #15818: Bump template-haskell version to 2.15.0.0 In-Reply-To: <050.7dd82309efae97acbaeca8205c2e0f7b@haskell.org> References: <050.7dd82309efae97acbaeca8205c2e0f7b@haskell.org> Message-ID: <065.a202a8986c6a790dbebda45390b4b65d@haskell.org> #15818: Bump template-haskell version to 2.15.0.0 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2600, #14268 | Differential Rev(s): Phab:D5272 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 15:50:51 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 15:50:51 -0000 Subject: [GHC] #14465: Performance of Natural In-Reply-To: <047.dbabb1127ee36a01bf1bf2eb91b6c532@haskell.org> References: <047.dbabb1127ee36a01bf1bf2eb91b6c532@haskell.org> Message-ID: <062.95b9b115a4d0a15daf046aea03a18338@haskell.org> #14465: Performance of Natural -------------------------------------+------------------------------------- Reporter: Bodigrim | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.2.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14170, #15821 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: #14170 => #14170, #15821 Comment: I've opened #15821 to track constant folding for the remaining operations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 15:51:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 15:51:01 -0000 Subject: [GHC] #15821: Implement more constant folding for Naturals (was: Implement constant folding for Naturals) In-Reply-To: <046.f9a66ca4226a20e909943f505947aaf5@haskell.org> References: <046.f9a66ca4226a20e909943f505947aaf5@haskell.org> Message-ID: <061.9ba484c758e5608380f6c7cecbd7befa@haskell.org> #15821: Implement more constant folding for Naturals -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 15:57:19 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 15:57:19 -0000 Subject: [GHC] #15821: Implement more constant folding for Naturals In-Reply-To: <046.f9a66ca4226a20e909943f505947aaf5@haskell.org> References: <046.f9a66ca4226a20e909943f505947aaf5@haskell.org> Message-ID: <061.69c46ffa8497f42316121aad1e3f2caa@haskell.org> #15821: Implement more constant folding for Naturals -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Additionally, working out why we fail to reduce the case in [T14465](https://phabricator.haskell.org/D5267#inline-41421) would be great. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 16:08:04 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 16:08:04 -0000 Subject: [GHC] #15815: problem with splicing type into constraint In-Reply-To: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> References: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> Message-ID: <059.7d5b8617629a56c2a7c43ec19977e5f3@haskell.org> #15815: problem with splicing type into constraint -------------------------------------+------------------------------------- Reporter: int-e | Owner: RyanGlScott Type: bug | Status: new Priority: highest | Milestone: Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #15760 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-index): * cc: int-index (added) Comment: Ryan, why do you believe that preserving parentheses would solve this issue? The original code does not have any parentheses (unlike your minimised version). The issue here appears to be manyfold 1. We reassociate type operators according to their fixities, so with `a ~ $(tyQ)` and `[t| Int -> Int |]` from the original report we get `a ~ Int -> Int` (no parens!) which gets correctly associated as `(a ~ Int) -> Int`. That's not the behaviour I would expect, but I've just learned that it's documented in `Note [Converting UInfix]`. 2. However, we map all three of `(~) a b`, `a ~ b`, and `(a ~ b)` to `AppT (AppT EqualityT a) b`. So we discard both parenthesization information (as you noted) and whether equality was applied in an infix or a prefix fashion. 3. When we convert back to `HsType`, we use `HsOpTy` if there are two operands, even if `(~)` was prefix in the original code. This means that even if we fix #15760, we will still get incorrect behaviour in the `(~) a b` case. For expressions, we have a distinction between `UInfixE` and `InfixE`: * `UInfixE` gets reassociated as necessary (documented in `See Note [Operator association]`) * `InfixE` gets parenthesised as necessary (documented in `Note [Converting UInfix]`) In types we have a similar distinction – `UInfixT` and `InfixT`. The former must get reassociated, and the latter parenthesised. NB. Looking at the code that handles `InfixT` it appears broken to me (because unlike code for expressions, it does not call `parenthesizeHsType`). But this is either a bug or I'm missing something. For the sake of the argument let's assume `InfixT` is treated the same way as `InfixE` – by parenthesising arguments as necessary. The question is: do we treat `AppT (AppT (EqualityT a)) b` as a moral equivalent of `UInfixT` or `InfixT`? The bug seems to be that we used to treat it as `InfixT`, now we treat it as `UInfixT`. Your patch with adding `parenthesizeHsType` seems to make it treated like `InfixT` again, but ideally the fix should be * to stop confusing `(~) a b` and `a ~ b`: map the former to `AppT (AppT (EqualityT a)) b` and the latter to `InfixT a EqualityT b` * to fix the treatment of `InfixT` in `cvtTypeKind` – parenthesise as necessary in expressions * drop this silly special case: {{{ | [x',y'] <- tys' -> returnL (HsOpTy noExt x' (noLoc eqTyCon_RDR) y') }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 16:26:28 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 16:26:28 -0000 Subject: [GHC] #15806: Impredicativity behavior in `:k` command in GHCi In-Reply-To: <047.f58636059e2229b0e75e579e133e8b67@haskell.org> References: <047.f58636059e2229b0e75e579e133e8b67@haskell.org> Message-ID: <062.2b0ebb352c7742e96ee40f73dc69d954@haskell.org> #15806: Impredicativity behavior in `:k` command in GHCi -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: merge Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14859 | Differential Rev(s): Phab:D5265 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge * milestone: => 8.6.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 16:41:37 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 16:41:37 -0000 Subject: [GHC] #15815: problem with splicing type into constraint In-Reply-To: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> References: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> Message-ID: <059.10a7ee14a01bcacd295383555620931b@haskell.org> #15815: problem with splicing type into constraint -------------------------------------+------------------------------------- Reporter: int-e | Owner: RyanGlScott Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Template Haskell | Version: 8.6.1 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): * cc: goldfire (removed) * related: #15760 => * milestone: => 8.6.2 Comment: You're right, I misspoke about #15760 fixing this issue. Forget I said anything about that. Your fix smells correct to me, and if there weren't any other extenuating circumstances, I'd endorse it as the one true solution. Unfortunately, there's a bit of a thorny issue in that this code no longer works on GHC 8.6, and I don't see a simple way to work around the issue at the moment. We need to backport //something// to fix this, but the question is //what//. Alas, changing the way we desugar infix types to use `InfixT` would constitute a breaking change in practice, so I'm reluctant to backport that. There is quite a bit of code in the wild which, for better or worse, assumes that `InfixT` only ever appears in user written code (i.e., `InfixT` never appears in desugared or reified TH ASTs). See [https://github.com/glguy/th- abstraction/blob/5123c6d054d0949cb444590269f13e5d44699ab2/src/Language/Haskell/TH/Datatype.hs#L1156-L1160 this function] from `th-abstraction` as one example. I'm not sure what exactly would happen if we started feeding that function `InfixT`s, but I imagine that something or another would change at runtime, which would be awful for a point release. Therefore, I'm inclined to adopt the patch in comment:4 as a crude (and ideally, temporary) fix for this issue in an 8.6 point release (hopefully 8.6.2), and work towards implementing your more robust solution for 8.8. Does that sound reasonable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 17:04:33 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 17:04:33 -0000 Subject: [GHC] #15815: problem with splicing type into constraint In-Reply-To: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> References: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> Message-ID: <059.b382b35140c8a1967a6663dbe1d13317@haskell.org> #15815: problem with splicing type into constraint -------------------------------------+------------------------------------- Reporter: int-e | Owner: RyanGlScott Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): Sounds reasonable to me, although I'm unsure if we should target 8.8 for the more robust fix rather than 8.10. When #15760 is fixed, `decomposeType` in `th-abstraction` that you linked would have to start to care about parentheses as well, so I believe it's better to do both changes at once. And since the merge window for 8.8 closes in a couple of days, and these are breaking changes, then a more realistic target is probably 8.10 – what do you think? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 17:09:32 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 17:09:32 -0000 Subject: [GHC] #15823: Incorrect link in the doc (TH API) Message-ID: <045.b4c1082cd516162e544a244b201af7c5@haskell.org> #15823: Incorrect link in the doc (TH API) -------------------------------------+------------------------------------- Reporter: hsyl20 | Owner: (none) Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The "Haddock reference documentation" link for TH in the doc is incorrectly generated at https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html #template-haskell -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 17:14:08 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 17:14:08 -0000 Subject: [GHC] #15815: problem with splicing type into constraint In-Reply-To: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> References: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> Message-ID: <059.709c393e9e1044faa527d4c6ff0b8cb5@haskell.org> #15815: problem with splicing type into constraint -------------------------------------+------------------------------------- Reporter: int-e | Owner: RyanGlScott Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:7 int-index]: > When #15760 is fixed, `decomposeType` in `th-abstraction` that you linked would have to start to care about parentheses as well Egads, I hadn't thought about that. That's a very good point, and I agree that it would be best to try and ship these fixes together. > And since the merge window for 8.8 closes in a couple of days Wow. Really? That deadline crept up faster than I ever thought possible... > then a more realistic target is probably 8.10 – what do you think? Sure. I'd be fine with putting this off later than 8.8 if need be (be it 8.10, 8.12, or whenever). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 17:30:12 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 17:30:12 -0000 Subject: [GHC] #15815: problem with splicing type into constraint In-Reply-To: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> References: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> Message-ID: <059.587a8249d0ce67b06484a70baa63e9e8@haskell.org> #15815: problem with splicing type into constraint -------------------------------------+------------------------------------- Reporter: int-e | Owner: RyanGlScott Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Template Haskell | Version: 8.6.1 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): Phab:D5274 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5274 Comment: I've submitted Phab:D5274 with the short-term fix from comment:4 (that ought to be backported to 8.6.2). int-index, can you open a new ticket tracking the long-term goal of desugaring/reifying uses of infix types to `InfixT`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 17:36:46 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 17:36:46 -0000 Subject: [GHC] #15780: ghc-8.4.4 failed to build on armv7 and aarch64 In-Reply-To: <050.81668a88e354aac40559f0e53fb7e269@haskell.org> References: <050.81668a88e354aac40559f0e53fb7e269@haskell.org> Message-ID: <065.01779ce6a1e869e07e6cda4eb08eaf8a@haskell.org> #15780: ghc-8.4.4 failed to build on armv7 and aarch64 ----------------------------------------+------------------------------ Reporter: juhpetersen | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.4.5 Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Changes (by bgamari): * status: new => merge * milestone: 8.6.2 => 8.4.5 Comment: This is fixed by c36a2b596a6ba9d7a0a80df01b3c041720c727ca. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 17:40:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 17:40:54 -0000 Subject: [GHC] #14251: LLVM Code Gen messes up registers In-Reply-To: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> References: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> Message-ID: <062.6173965cad3e22e06b5ab3d02ccdfee1@haskell.org> #14251: LLVM Code Gen messes up registers -------------------------------------+------------------------------------- Reporter: angerman | Owner: kavon Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: Compiler (LLVM) | Version: 8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5190 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d8495549ba9d194815c2d0eaee6797fc7c00756a/ghc" d849554/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d8495549ba9d194815c2d0eaee6797fc7c00756a" Fix for T14251 on ARM We now calculate the SSE register padding needed to fix the calling convention in LLVM in a robust way: grouping them by whether registers in that class overlap (with the same class overlapping itself). My prior patch assumed that no matter the platform, physical register Fx aliases with Dx, etc, for our calling convention. This is unfortunately not the case for any platform except x86-64. Test Plan: Only know how to test on x86-64, but it should be tested on ARM with: `make test WAYS=llvm && make test WAYS=optllvm` Reviewers: bgamari, angerman Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15780, #14251, #15747 Differential Revision: https://phabricator.haskell.org/D5254 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 17:40:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 17:40:54 -0000 Subject: [GHC] #15747: GHC panics when builds for arm as: ghc-stage1: panic! (the 'impossible' happened): padLiveArgs -- i > regNum ?? In-Reply-To: <045.cba5326f4d617f1d05fcc7dfa664973a@haskell.org> References: <045.cba5326f4d617f1d05fcc7dfa664973a@haskell.org> Message-ID: <060.4dfab3798510e507cea0c651b9eb10a9@haskell.org> #15747: GHC panics when builds for arm as: ghc-stage1: panic! (the 'impossible' happened): padLiveArgs -- i > regNum ?? -------------------------------------+------------------------------------- Reporter: slyfox | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d8495549ba9d194815c2d0eaee6797fc7c00756a/ghc" d849554/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d8495549ba9d194815c2d0eaee6797fc7c00756a" Fix for T14251 on ARM We now calculate the SSE register padding needed to fix the calling convention in LLVM in a robust way: grouping them by whether registers in that class overlap (with the same class overlapping itself). My prior patch assumed that no matter the platform, physical register Fx aliases with Dx, etc, for our calling convention. This is unfortunately not the case for any platform except x86-64. Test Plan: Only know how to test on x86-64, but it should be tested on ARM with: `make test WAYS=llvm && make test WAYS=optllvm` Reviewers: bgamari, angerman Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15780, #14251, #15747 Differential Revision: https://phabricator.haskell.org/D5254 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 17:40:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 17:40:54 -0000 Subject: [GHC] #15780: ghc-8.4.4 failed to build on armv7 and aarch64 In-Reply-To: <050.81668a88e354aac40559f0e53fb7e269@haskell.org> References: <050.81668a88e354aac40559f0e53fb7e269@haskell.org> Message-ID: <065.ad687676d4752510993c23fe746d09ea@haskell.org> #15780: ghc-8.4.4 failed to build on armv7 and aarch64 ----------------------------------------+------------------------------ Reporter: juhpetersen | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.4.5 Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by Ben Gamari ): In [changeset:"d8495549ba9d194815c2d0eaee6797fc7c00756a/ghc" d849554/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d8495549ba9d194815c2d0eaee6797fc7c00756a" Fix for T14251 on ARM We now calculate the SSE register padding needed to fix the calling convention in LLVM in a robust way: grouping them by whether registers in that class overlap (with the same class overlapping itself). My prior patch assumed that no matter the platform, physical register Fx aliases with Dx, etc, for our calling convention. This is unfortunately not the case for any platform except x86-64. Test Plan: Only know how to test on x86-64, but it should be tested on ARM with: `make test WAYS=llvm && make test WAYS=optllvm` Reviewers: bgamari, angerman Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15780, #14251, #15747 Differential Revision: https://phabricator.haskell.org/D5254 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 17:40:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 17:40:54 -0000 Subject: [GHC] #14784: RTS header files can't be used with a C++ compiler In-Reply-To: <046.915be18a946df960093f8bf95e37faf5@haskell.org> References: <046.915be18a946df960093f8bf95e37faf5@haskell.org> Message-ID: <061.2b81af6eb7451fe743117fb926754485@haskell.org> #14784: RTS header files can't be used with a C++ compiler -------------------------------------+------------------------------------- Reporter: niteria | Owner: hvr Type: bug | Status: patch Priority: highest | Milestone: 8.6.3 Component: Runtime System | 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:D5244 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"134de45117bdbb031f513734b84403443e083fbe/ghc" 134de451/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="134de45117bdbb031f513734b84403443e083fbe" includes: Allow headers to be built with C++11 compilers Summary: Fixes #14784. Note that C++11 is quite conservative; we could likely accept C++03 as well. Test Plan: ``` $ cat >hi.c < EOF $ g++ -std=c++11 hi.c ``` Reviewers: simonmar, hvr Subscribers: rwbarton, carter GHC Trac Issues: #14784 Differential Revision: https://phabricator.haskell.org/D5244 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 17:40:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 17:40:54 -0000 Subject: [GHC] #15806: Impredicativity behavior in `:k` command in GHCi In-Reply-To: <047.f58636059e2229b0e75e579e133e8b67@haskell.org> References: <047.f58636059e2229b0e75e579e133e8b67@haskell.org> Message-ID: <062.d7f89bb8cea9f0ef68cfe405a165575a@haskell.org> #15806: Impredicativity behavior in `:k` command in GHCi -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: merge Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14859 | Differential Rev(s): Phab:D5265 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c4a876d5f99554e87400946dd26ca11819d11673/ghc" c4a876d5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c4a876d5f99554e87400946dd26ca11819d11673" Fix `:k` command: add validity checking Summary: This patch fixes #15806, where we found that the `:k` command in GHCi misses a validity checking for the type. Missing validity checking causes `:k` to accept types that are not validated. For example, `:k (Maybe (forall a. a -> a))` (incorrectly) returns `*`, while impredictivity of type instantiation shouldn't be allowed. Test Plan: ./validate Reviewers: simonpj, goldfire, bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15806 Differential Revision: https://phabricator.haskell.org/D5265 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 17:40:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 17:40:54 -0000 Subject: [GHC] #15805: Bug in anyRewritableTyVar In-Reply-To: <047.87fb715ef5d84b486e63a473ac81c384@haskell.org> References: <047.87fb715ef5d84b486e63a473ac81c384@haskell.org> Message-ID: <062.8ad83800c53cd27e4b93251bf325184e@haskell.org> #15805: Bug in anyRewritableTyVar -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14363 | Differential Rev(s): Phab:D5263 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a7f64c6cbfc5562adff207945576d1c9db2a58d9/ghc" a7f64c6c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a7f64c6cbfc5562adff207945576d1c9db2a58d9" Fix TcType.anyRewritableTyVar Summary: This patch fixes #15805, where we found that `TcType.anyRewritableTyVar` has one wrong case. Besides the fix, it also: - removed some unnecessary `ASSERT2(tcIsTcTyVar...)` in `TcType`, as now we have `tcIsTcTyVar = isTyVar`. - fixed some comments Test Plan: ./validate Reviewers: goldfire, simonpj, bgamari Reviewed By: simonpj Subscribers: rwbarton, carter GHC Trac Issues: #15805 Differential Revision: https://phabricator.haskell.org/D5263 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 17:40:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 17:40:54 -0000 Subject: [GHC] #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity In-Reply-To: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> References: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> Message-ID: <060.7dc44eda96f6d060fa4ca8fa79d14fb8@haskell.org> #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity -------------------------------------+------------------------------------- Reporter: claude | Owner: fangyizhou Type: bug | Status: patch 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): Phab:D5271 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8e1a5593f940b9d2882a5e81abf028e7b99aff3a/ghc" 8e1a559/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8e1a5593f940b9d2882a5e81abf028e7b99aff3a" Fix integer overflow when encoding doubles (Trac #15271) Summary: Ticket #15271 reports a case where 1e1000000000 is incorrectly converted to 0.0. After some investigation, I discovered the number is converted to rational correctly, but converting the ratio into a double introduced an error. Tracking down to how the conversion is done, I found the rts float implementation uses `ldexp`, whose signature is `double ldexp (double x, int exp);` The callsite passes an `I_` to the second argument, which is platform-dependent. On machines where `I_` is 64 bits and `int` is 32 bits, we observe integer overflow behaviour. Here is a mapping from rational to exponent with observations 1e646457008 -> 2147483645 (result = infinity, positive in int32) 1e646457009 -> 2147483648 (result = 0.0, overflow to negative in int32) 1e1000000000 -> 3321928042 (result = infinity, overflow to positive in int32) 1e1555550000 -> 5167425196 (result = 0.0, overflow to negative in int32) We fix this issue by comparing STG_INT_MIN/MAX and INT_MIN/MAX and bound the value appropriately. Test Plan: New test cases Reviewers: bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15271 Differential Revision: https://phabricator.haskell.org/D5271 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 17:40:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 17:40:54 -0000 Subject: [GHC] #14854: The size of FastString table is suboptimal for large codebases In-Reply-To: <046.96a71a8566a954e21839a1a60572305e@haskell.org> References: <046.96a71a8566a954e21839a1a60572305e@haskell.org> Message-ID: <061.a420b03034d72416b2cc3086cd8a0cb2@haskell.org> #14854: The size of FastString table is suboptimal for large codebases -------------------------------------+------------------------------------- Reporter: niteria | Owner: watashi Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5211 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5126764be614cc43b435e3f5ff34ea593c30269a/ghc" 5126764b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5126764be614cc43b435e3f5ff34ea593c30269a" Rewrite FastString table in concurrent hashtable Summary: Reimplement global FastString table using a concurrent hashatable with fixed size segments and dynamically growing buckets instead of fixed size buckets. This addresses the problem that `mkFastString` was not linear when the total number of entries was large. Test Plan: ./validate ``` inplace/bin/ghc-stage2 --interactive -dfaststring-stats < /dev/null GHCi, version 8.7.20181005: http://www.haskell.org/ghc/ :? for help Prelude> Leaving GHCi. FastString stats: segments: 256 buckets: 16384 entries: 7117 largest segment: 64 smallest segment: 64 longest bucket: 5 has z-encoding: 0% ``` Also comapre the two implementation using {P187} The new implementation is on a par with the old version with different conbination of parameters and perform better when the number of FastString's are large. {P188} Reviewers: simonmar, bgamari, niteria Reviewed By: simonmar, bgamari Subscribers: rwbarton, carter GHC Trac Issues: #14854 Differential Revision: https://phabricator.haskell.org/D5211 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 17:40:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 17:40:54 -0000 Subject: [GHC] #15700: Plugins cause GHC to panic: cannot find dynamic libraries In-Reply-To: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> References: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> Message-ID: <059.6380d49fc104e3f450a64289288af65a@haskell.org> #15700: Plugins cause GHC to panic: cannot find dynamic libraries -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15492 | Differential Rev(s): Phab:D5253 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"be88c818a2962adbdaca0eda539412a9bfec4384/ghc" be88c818/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="be88c818a2962adbdaca0eda539412a9bfec4384" plugins: search for .a files if necessary Summary: on windows, plugins are loaded via .a files, but those paths were not being searched when loading plugins Test Plan: ./validate Reviewers: Phyx, bgamari Reviewed By: Phyx Subscribers: RyanGlScott, rwbarton, carter GHC Trac Issues: #15700 Differential Revision: https://phabricator.haskell.org/D5253 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 17:40:54 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 17:40:54 -0000 Subject: [GHC] #15066: EtaExpandLevPoly triggers a core lint error in profasm/profthreaded ways In-Reply-To: <048.d54d45a802f9d9d37b6c6fc6639d5d39@haskell.org> References: <048.d54d45a802f9d9d37b6c6fc6639d5d39@haskell.org> Message-ID: <063.e798f7edb7128676e1c2ff1f44b27f2d@haskell.org> #15066: EtaExpandLevPoly triggers a core lint error in profasm/profthreaded ways ---------------------------------+---------------------------------------- Reporter: alpmestan | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.5 Resolution: fixed | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: EtaExpandLevPoly Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"e69590f1bdbbb605921f125050929c7b84f00d28/ghc" e69590f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e69590f1bdbbb605921f125050929c7b84f00d28" testsuite: EtaExpandLevPoly now passes in profiled ways Summary: This failure was originally tracked in #15066 but it seems the problem has somehow resolved itself. Reviewers: alpmestan Reviewed By: alpmestan Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5242 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 18:02:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 18:02:48 -0000 Subject: [GHC] #15263: Fuse zipWith3 In-Reply-To: <047.9d2de90ae6f11d155cd01f5a30989bf4@haskell.org> References: <047.9d2de90ae6f11d155cd01f5a30989bf4@haskell.org> Message-ID: <062.e21ff11f016db132673530b09b2198f4@haskell.org> #15263: Fuse zipWith3 -------------------------------------+------------------------------------- Reporter: goldfire | Owner: TDecki 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: #14037 | Differential Rev(s): Phab:D5241 Wiki Page: | -------------------------------------+------------------------------------- Changes (by TDecki): * related: => #14037 Comment: Related Ticket also wants to do this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 18:28:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 18:28:02 -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.8a272c860771d13d70e9a649c78c5814@haskell.org> #14037: Fix fusion for GHC's utility functions -------------------------------------+------------------------------------- Reporter: goldfire | Owner: rockbmb Type: bug | Status: patch 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: #15263 | Differential Rev(s): Phab:D5249 Wiki Page: | -------------------------------------+------------------------------------- Changes (by TDecki): * related: => #15263 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 18:39:43 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 18:39:43 -0000 Subject: [GHC] #15821: Implement more constant folding for Naturals In-Reply-To: <046.f9a66ca4226a20e909943f505947aaf5@haskell.org> References: <046.f9a66ca4226a20e909943f505947aaf5@haskell.org> Message-ID: <061.c030a3bd3e6dc0fdbc099a896aaf6ead@haskell.org> #15821: Implement more constant folding for Naturals -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hsyl20): I'm currently resurrecting my work-in-progress on this topic. It's taking some time because I would like to make it generic enough that it would be easy to add new rules for Int8#, Int16# and the like when they will be merged in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 18:49:01 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 18:49:01 -0000 Subject: [GHC] #15824: Prefix/infix distinction in TemplateHaskell types is lost Message-ID: <048.883a1d02b1bc7b28f89bc3fdf731a91f@haskell.org> #15824: Prefix/infix distinction in TemplateHaskell types is lost -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.6.1 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #15815, #15760 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider `data T a b = a :. b`. In the declaration, `:.` is mapped to `InfixC`: {{{ ghci> putStrLn $(reify ''T >>= stringE . show) TyConI (DataD [] T [KindedTV a StarT,KindedTV b StarT] Nothing [InfixC (Bang NoSourceUnpackedness NoSourceStrictness,VarT a) :. (Bang NoSourceUnpackedness NoSourceStrictness,VarT b)] []) }}} In expressions, `a :. b` is mapped to `InfixE`: {{{ ghci> runQ [e| 1 :+ 2 |] >>= print InfixE (Just (LitE (IntegerL 1))) (ConE :+) (Just (LitE (IntegerL 2))) }}} In patterns, `a :. b` is mapped to `InfixP`: {{{ ghci> runQ [p| 1 :. 2 |] >>= print InfixP (LitP (IntegerL 1)) :. (LitP (IntegerL 2)) }}} In types, `a :. b` is mapped to `InfixT`: {{{ ghci> runQ [t| 1 :. 2 |] >>= print InfixT (LitT (NumTyLit 1)) (PromotedT :.) (LitT (NumTyLit 2)) }}} That last one was a lie. In reality, in types `a :. b` is mapped to nested `AppT`: {{{ ghci> runQ [t| 1 :. 2 |] >>= print AppT (AppT (PromotedT :.) (LitT (NumTyLit 1))) (LitT (NumTyLit 2)) }}} This is despite the existence of `InfixT`. The same issue can be observed when reifying types: {{{ ghci> type A = 1 :. 2 ghci> putStrLn $(reify ''A >>= stringE . show) TyConI (TySynD A [] (AppT (AppT (PromotedT :.) (LitT (NumTyLit 1))) (LitT (NumTyLit 2)))) }}} This is not specific to infix constructors and can be observed with any infix (type) operators. It's best to change this in the same release as we fix #15760, as there is code in the wild that is prepared to face neither `InfixT` nor `ParensT`, and it would break silently. RyanGlScott gives an example of such code: [https://github.com/glguy/th- abstraction/blob/5123c6d054d0949cb444590269f13e5d44699ab2/src/Language/Haskell/TH/Datatype.hs#L1156-L1160 decomposeType from th-desugar]. This issue is in part responsible for #15815, see comment:5:ticket:15815. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 19:11:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 19:11:09 -0000 Subject: [GHC] #15815: problem with splicing type into constraint In-Reply-To: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> References: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> Message-ID: <059.5f449ceb0e86107148e7d37b6df47396@haskell.org> #15815: problem with splicing type into constraint -------------------------------------+------------------------------------- Reporter: int-e | Owner: RyanGlScott Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Template Haskell | Version: 8.6.1 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): Phab:D5274 Wiki Page: | -------------------------------------+------------------------------------- Comment (by int-index): > Wow. Really? That deadline crept up faster than I ever thought possible... Sorry to mislead – I thought "cut release branch in November 2018" meant November 1st, turns out it's November 18th, so there are three weeks left. > int-index, can you open a new ticket tracking the long-term goal of desugaring/reifying uses of infix types to `InfixT`? I created #15824. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 19:28:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 19:28:14 -0000 Subject: [GHC] #15780: ghc-8.4.4 failed to build on armv7 and aarch64 In-Reply-To: <050.81668a88e354aac40559f0e53fb7e269@haskell.org> References: <050.81668a88e354aac40559f0e53fb7e269@haskell.org> Message-ID: <065.77f9dd13130eb89e48e81e047a41de0f@haskell.org> #15780: ghc-8.4.4 failed to build on armv7 and aarch64 ----------------------------------------+------------------------------ Reporter: juhpetersen | Owner: (none) Type: bug | Status: merge Priority: high | Milestone: 8.4.5 Component: Compiler | Version: 8.4.4 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+------------------------------ Comment (by bgamari): Fixed in `ghc-8.6` with 2e23e1c7de01c92b038e55ce53d11bf9db993dd4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 19:28:57 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 19:28:57 -0000 Subject: [GHC] #15806: Impredicativity behavior in `:k` command in GHCi In-Reply-To: <047.f58636059e2229b0e75e579e133e8b67@haskell.org> References: <047.f58636059e2229b0e75e579e133e8b67@haskell.org> Message-ID: <062.efe4422c9216411d1379840d442d45af@haskell.org> #15806: Impredicativity behavior in `:k` command in GHCi -------------------------------------+------------------------------------- Reporter: ningning | Owner: ningning Type: bug | Status: closed Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #14859 | Differential Rev(s): Phab:D5265 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.6` with 804518f703076829aa1f5206beaf83e4c1e0c68f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 19:29:30 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 19:29:30 -0000 Subject: [GHC] #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity In-Reply-To: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> References: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> Message-ID: <060.607f8fbfcf52e69eb4561b2d38a5fb07@haskell.org> #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity -------------------------------------+------------------------------------- Reporter: claude | Owner: fangyizhou Type: bug | Status: closed Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5271 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: 8.8.1 => 8.6.2 Comment: Merged to `ghc-8.6` with 37d14601af6ff5c2c590d30fccbb6eb56b88780e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 19:30:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 19:30:02 -0000 Subject: [GHC] #15700: Plugins cause GHC to panic: cannot find dynamic libraries In-Reply-To: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> References: <044.d3a1fd1f73fafd7f46d850c6d3cc8739@haskell.org> Message-ID: <059.5c994e7ba8d6704dd03e55a99bf3fd9c@haskell.org> #15700: Plugins cause GHC to panic: cannot find dynamic libraries -------------------------------------+------------------------------------- Reporter: sheaf | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Windows | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #15492 | Differential Rev(s): Phab:D5253 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.6.2 Comment: Merged to `ghc-8.6` with d2cd150eda599d0de83fc687efc48e22a2e74a5e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 19:32:26 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 19:32:26 -0000 Subject: [GHC] #15371: Eventlog framework outputs environment variables which may cause a security issue In-Reply-To: <043.e0598f3eff95a3e71b8c6103a2d86a17@haskell.org> References: <043.e0598f3eff95a3e71b8c6103a2d86a17@haskell.org> Message-ID: <058.17eaa305a7431b13c79288339a7b7074@haskell.org> #15371: Eventlog framework outputs environment variables which may cause a security issue -------------------------------------+------------------------------------- Reporter: maoe | Owner: (none) Type: feature request | 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: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5187 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.8.1 Comment: I'm going to punt this to 8.8 since doing otherwise would imply a functional change in a minor release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 19:40:00 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 19:40:00 -0000 Subject: [GHC] #15685: Pattern signature not inferred In-Reply-To: <051.c5171c2fbdeaddb4c2ac22c9d434e0a0@haskell.org> References: <051.c5171c2fbdeaddb4c2ac22c9d434e0a0@haskell.org> Message-ID: <066.11508be5d72861376188b3c9257c1cdf@haskell.org> #15685: Pattern signature not inferred -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | patsyn/should_fail/T15685 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.6` with 3e050064511ce67ee9150d51cb9db487187be39e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 19:56:48 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 19:56:48 -0000 Subject: [GHC] #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity In-Reply-To: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> References: <045.19d5cc4c2c6f48e9e65c22442157739b@haskell.org> Message-ID: <060.99d429a59fb706d092a7461ad860e289@haskell.org> #15271: 1e1000000000 :: Double yields 0.0 instead of Infinity -------------------------------------+------------------------------------- Reporter: claude | Owner: fangyizhou Type: bug | Status: merge Priority: normal | Milestone: 8.4.5 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5271 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => merge * milestone: 8.6.2 => 8.4.5 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 20:08:09 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 20:08:09 -0000 Subject: [GHC] #15824: Prefix/infix distinction in TemplateHaskell types is lost In-Reply-To: <048.883a1d02b1bc7b28f89bc3fdf731a91f@haskell.org> References: <048.883a1d02b1bc7b28f89bc3fdf731a91f@haskell.org> Message-ID: <063.85b4c182ba49a9907b7eeccdf696f9c7@haskell.org> #15824: Prefix/infix distinction in TemplateHaskell types is lost -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15815, #15760 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by int-index: Old description: > Consider `data T a b = a :. b`. > > In the declaration, `:.` is mapped to `InfixC`: > > {{{ > ghci> putStrLn $(reify ''T >>= stringE . show) > TyConI (DataD [] T [KindedTV a StarT,KindedTV b StarT] Nothing [InfixC > (Bang NoSourceUnpackedness NoSourceStrictness,VarT a) :. (Bang > NoSourceUnpackedness NoSourceStrictness,VarT b)] []) > }}} > > In expressions, `a :. b` is mapped to `InfixE`: > > {{{ > ghci> runQ [e| 1 :+ 2 |] >>= print > InfixE (Just (LitE (IntegerL 1))) (ConE :+) (Just (LitE (IntegerL 2))) > }}} > > In patterns, `a :. b` is mapped to `InfixP`: > > {{{ > ghci> runQ [p| 1 :. 2 |] >>= print > InfixP (LitP (IntegerL 1)) :. (LitP (IntegerL 2)) > }}} > > In types, `a :. b` is mapped to `InfixT`: > > {{{ > ghci> runQ [t| 1 :. 2 |] >>= print > InfixT (LitT (NumTyLit 1)) (PromotedT :.) (LitT (NumTyLit 2)) > }}} > > That last one was a lie. In reality, in types `a :. b` is mapped to > nested `AppT`: > > {{{ > ghci> runQ [t| 1 :. 2 |] >>= print > AppT (AppT (PromotedT :.) (LitT (NumTyLit 1))) (LitT (NumTyLit 2)) > }}} > > This is despite the existence of `InfixT`. > > The same issue can be observed when reifying types: > > {{{ > ghci> type A = 1 :. 2 > ghci> putStrLn $(reify ''A >>= stringE . show) > TyConI (TySynD A [] (AppT (AppT (PromotedT :.) (LitT (NumTyLit 1))) (LitT > (NumTyLit 2)))) > }}} > > This is not specific to infix constructors and can be observed with any > infix (type) operators. > > It's best to change this in the same release as we fix #15760, as there > is code in the wild that is prepared to face neither `InfixT` nor > `ParensT`, and it would break silently. RyanGlScott gives an example of > such code: [https://github.com/glguy/th- > abstraction/blob/5123c6d054d0949cb444590269f13e5d44699ab2/src/Language/Haskell/TH/Datatype.hs#L1156-L1160 > decomposeType from th-desugar]. > > This issue is in part responsible for #15815, see comment:5:ticket:15815. New description: Consider `data T a b = a :. b`. In the declaration, `:.` is mapped to `InfixC`: {{{ ghci> putStrLn $(reify ''T >>= stringE . show) TyConI (DataD [] T [KindedTV a StarT,KindedTV b StarT] Nothing [InfixC (Bang NoSourceUnpackedness NoSourceStrictness,VarT a) :. (Bang NoSourceUnpackedness NoSourceStrictness,VarT b)] []) }}} In expressions, `a :. b` is mapped to `InfixE`: {{{ ghci> runQ [e| 1 :+ 2 |] >>= print InfixE (Just (LitE (IntegerL 1))) (ConE :+) (Just (LitE (IntegerL 2))) }}} In patterns, `a :. b` is mapped to `InfixP`: {{{ ghci> runQ [p| 1 :. 2 |] >>= print InfixP (LitP (IntegerL 1)) :. (LitP (IntegerL 2)) }}} In types, `a :. b` is mapped to `InfixT`: {{{ ghci> runQ [t| 1 :. 2 |] >>= print InfixT (LitT (NumTyLit 1)) (PromotedT :.) (LitT (NumTyLit 2)) }}} That last one was a lie. In reality, in types `a :. b` is mapped to nested `AppT`, as if it was written as `(:.) a b`: {{{ ghci> runQ [t| 1 :. 2 |] >>= print AppT (AppT (PromotedT :.) (LitT (NumTyLit 1))) (LitT (NumTyLit 2)) }}} This is despite the existence of `InfixT`. The same issue can be observed when reifying types: {{{ ghci> type A = 1 :. 2 ghci> putStrLn $(reify ''A >>= stringE . show) TyConI (TySynD A [] (AppT (AppT (PromotedT :.) (LitT (NumTyLit 1))) (LitT (NumTyLit 2)))) }}} This is not specific to infix constructors and can be observed with any infix (type) operators. It's best to change this in the same release as we fix #15760, as there is code in the wild that is prepared to face neither `InfixT` nor `ParensT`, and it would break silently. RyanGlScott gives an example of such code: [https://github.com/glguy/th- abstraction/blob/5123c6d054d0949cb444590269f13e5d44699ab2/src/Language/Haskell/TH/Datatype.hs#L1156-L1160 decomposeType from th-desugar]. This issue is in part responsible for #15815, see comment:5:ticket:15815. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 20:09:02 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 20:09:02 -0000 Subject: [GHC] #15787: GHC panic using kind application In-Reply-To: <051.88158355ed422210999943d4c175f35d@haskell.org> References: <051.88158355ed422210999943d4c175f35d@haskell.org> Message-ID: <066.2d206a5f7e68fec206bee5c0d2778c24@haskell.org> #15787: GHC panic using kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5275 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * differential: => Phab:D5275 Comment: Patch posted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 20:10:41 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 20:10:41 -0000 Subject: [GHC] #15824: Prefix/infix distinction in TemplateHaskell types is lost In-Reply-To: <048.883a1d02b1bc7b28f89bc3fdf731a91f@haskell.org> References: <048.883a1d02b1bc7b28f89bc3fdf731a91f@haskell.org> Message-ID: <063.9d76eb79ec0366a98f21aae1c337fddc@haskell.org> #15824: Prefix/infix distinction in TemplateHaskell types is lost -------------------------------------+------------------------------------- Reporter: int-index | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15815, #15760 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-e): * cc: int-e (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 20:11:16 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 20:11:16 -0000 Subject: [GHC] #15760: Preserve parens in TH In-Reply-To: <047.bd515b636bed31bfe65d883c11cd9bb1@haskell.org> References: <047.bd515b636bed31bfe65d883c11cd9bb1@haskell.org> Message-ID: <062.ebc70932d7d852f6a6aec36db944ea9a@haskell.org> #15760: Preserve parens in TH -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #15815 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-e): * cc: int-e (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 21:29:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 21:29:29 -0000 Subject: [GHC] #15820: Document the proposals process in the GHC manual In-Reply-To: <047.f26a3edc97953dc3d8f97d5632ba8107@haskell.org> References: <047.f26a3edc97953dc3d8f97d5632ba8107@haskell.org> Message-ID: <062.0438bd48606ac08560a49e399365ffba@haskell.org> #15820: Document the proposals process in the GHC manual -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 8.6.1 Resolution: | Keywords: Operating System: 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: Iceland_jack (removed) Comment: Agreed; ultimately I would like to have better contributor documentation in the users guide (and users have also indicated in the survey that they feel our contributor documentation is a bit scattered). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 21:39:14 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 21:39:14 -0000 Subject: [GHC] #15819: COMPLETE pragma not listed in GHC manual index In-Reply-To: <047.48f16142afcc3744bbc0b8a826cce183@haskell.org> References: <047.48f16142afcc3744bbc0b8a826cce183@haskell.org> Message-ID: <062.f6a039310b4245ac1318eae81d6409ca@haskell.org> #15819: COMPLETE pragma not listed in GHC manual index -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Documentation | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.8.1 Comment: I actually had a branch kicking around that does precisely this. I've rebased it and pushed to Phabricator as Phab:D5276. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Oct 28 23:11:29 2018 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Oct 2018 23:11:29 -0000 Subject: [GHC] #15819: COMPLETE pragma not listed in GHC manual index In-Reply-To: <047.48f16142afcc3744bbc0b8a826cce183@haskell.org> References: <047.48f16142afcc3744bbc0b8a826cce183@haskell.org> Message-ID: <062.7b304e2ea586da5851e7db928ea1395c@haskell.org> #15819: COMPLETE pragma not listed in GHC manual index -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Documentation | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5276 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ulysses4ever): * owner: (none) => bgamari * differential: => Phab:D5276 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 00:26:36 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 00:26:36 -0000 Subject: [GHC] #13253: Exponential compilation time with RWST & ReaderT stack with `-02` In-Reply-To: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> References: <045.b3c468c50b4e8e33ee0981a3ab0c6b4b@haskell.org> Message-ID: <060.563eec5ac67f93ad99af8eaad72e8692@haskell.org> #13253: Exponential compilation time with RWST & ReaderT stack with `-02` -------------------------------------+------------------------------------- Reporter: phadej | Owner: bgamari, osa1 Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #15630 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high Comment: Bumping in priority so we don't lose track of it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 01:49:44 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 01:49:44 -0000 Subject: [GHC] #15825: Core Lint error from Explicit Foralls Proposal Message-ID: <051.14c6056f3f80a08cd54db3d963a264a6@haskell.org> #15825: Core Lint error from Explicit Foralls Proposal -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is using the recent Explicit Foralls Proposal #14268 {{{#!hs {-# Language RankNTypes #-} {-# Language PolyKinds #-} {-# Language KindSignatures #-} {-# Language DataKinds #-} {-# Language FlexibleInstances #-} {-# Options_GHC -dcore-lint #-} type C k = (forall (x::k). *) class X (a :: *) instance forall (a :: C k). X (a :: *) }}} {{{ $ ./inplace/bin/ghc-stage2 --interactive -ignore-dot-ghci /tmp/599_bug.hs GHCi, version 8.7.20181025: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( 599_bug.hs, interpreted ) *** Core Lint errors : in result of Desugar (before optimization) *** : warning: In the expression: C:X @ a_a1yJ Kind application error in type ‘a_a1yJ’ Function kind = C k_a1yI Arg kinds = [(x_a1yH, k_a1yG)] Forall: x_a1xE k_a1yI (x_a1yH, k_a1yG) : warning: In the expression: C:X @ a_a1xG Kind application error in type ‘a_a1xG’ Function kind = C k_X1xQ Arg kinds = [(x_a1yv, k_a1xF)] Forall: x_a1xE k_X1xQ (x_a1yv, k_a1xF) *** Offending Program *** Rec { $tcX :: TyCon [LclIdX] $tcX = TyCon 6136962148358085538## 2047526523769221729## $trModule (TrNameS "X"#) 0# $krep_a1zH $tc'C:X :: TyCon [LclIdX] $tc'C:X = TyCon 12994509767826319747## 2028070155085790741## $trModule (TrNameS "'C:X"#) 1# $krep_a1zJ $krep_a1zK [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1zK = $WKindRepVar (I# 0#) $krep_a1zH [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1zH = KindRepFun krep$* $krep_a1zI $krep_a1zI [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1zI = KindRepTyConApp $tcConstraint ([] @ KindRep) $krep_a1zJ [InlPrag=NOUSERINLINE[~]] :: KindRep [LclId] $krep_a1zJ = KindRepTyConApp $tcX (: @ KindRep $krep_a1zK ([] @ KindRep)) $trModule :: Module [LclIdX] $trModule = Module (TrNameS "main"#) (TrNameS "Main"#) $fXa [InlPrag=NOUSERINLINE CONLIKE] :: forall k (x :: k) k (a :: C k). X a [LclIdX[DFunId], Unf=DFun: \ (@ k_a1xF) (@ (x_a1yv :: k_a1xF)) (@ k_a1xF) (@ (a_a1xG :: C k_a1xF)) -> C:X TYPE: a_a1xG] $fXa = \ (@ k_a1yG) (@ (x_a1yH :: k_a1yG)) (@ k_a1yI) (@ (a_a1yJ :: C k_a1yI)) -> C:X @ a_a1yJ end Rec } *** End of Offense *** : error: Compilation had errors *** Exception: ExitFailure 1 > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 01:59:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 01:59:32 -0000 Subject: [GHC] #15811: Comment out CONSTANT_FOLDED annotation for some GHC.Natural functions In-Reply-To: <046.3d65654e0c3d431e5ff8ed7b7fa13c62@haskell.org> References: <046.3d65654e0c3d431e5ff8ed7b7fa13c62@haskell.org> Message-ID: <061.073c2addd9057056558845509ead15c2@haskell.org> #15811: Comment out CONSTANT_FOLDED annotation for some GHC.Natural functions -------------------------------------+------------------------------------- Reporter: darchon | Owner: (none) Type: feature request | Status: closed Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5267 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged de9a8febde8cb7945d36d7e0bb7e12ddffca50bd. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 02:00:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 02:00:49 -0000 Subject: [GHC] #14251: LLVM Code Gen messes up registers In-Reply-To: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> References: <047.9ece2514d7c7f668525c93ec15fb841a@haskell.org> Message-ID: <062.d3e3fa1f700a841c44c93430b64c0082@haskell.org> #14251: LLVM Code Gen messes up registers -------------------------------------+------------------------------------- Reporter: angerman | Owner: kavon Type: bug | Status: closed Priority: highest | Milestone: 8.6.2 Component: Compiler (LLVM) | Version: 8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5190 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Merged to `ghc-8.6` with 2e23e1c7de01c92b038e55ce53d11bf9db993dd4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 02:04:02 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 02:04:02 -0000 Subject: [GHC] #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect In-Reply-To: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> References: <045.264efab2550e6c0c57011c9dec16d7f2@haskell.org> Message-ID: <060.81b5bc797f851a3a439b8bb0902443ef@haskell.org> #15696: Derived Ord instance for enumerations with more than 8 elements seems to be incorrect -------------------------------------+------------------------------------- Reporter: mrkkrp | Owner: osa1 Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #14677, #15155 | Differential Rev(s): Phab:D5196, Wiki Page: | Phab:D5201, Phab:D5226 -------------------------------------+------------------------------------- Comment (by bgamari): The core problem here was fixed with comment:66. There are several additional tasks that can be done, however, as described in comment:77. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 02:14:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 02:14:37 -0000 Subject: [GHC] #15825: Core Lint error from Explicit Foralls Proposal In-Reply-To: <051.14c6056f3f80a08cd54db3d963a264a6@haskell.org> References: <051.14c6056f3f80a08cd54db3d963a264a6@haskell.org> Message-ID: <066.0349122e8bc4da2caa2f72b9d91934dc@haskell.org> #15825: Core Lint error from Explicit Foralls Proposal -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Note that nothing in this program is making use of functionality that was added in the Explicit Foralls proposal. In fact, this program exhibits a Core Lint error all the way back to GHC 8.2.2 (you'll have to enable `TypeInType` and import `Data.Kind` to make it compile on older GHCs, though). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 02:15:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 02:15:33 -0000 Subject: [GHC] #15826: Allow using (Source)Plugins through the GHC API Message-ID: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> #15826: Allow using (Source)Plugins through the GHC API -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- One might expect to be able to load plugins through the GHC API by doing something like: {{{ runGHC $ do dflags <- getSessionDynFlags setSessionDynFlags dflags { plugins = [LoadedPlugin some_plugin _conjure_up_modiface []] } }}} but this doesn't actually work because the `plugins` field in `DynFlags` is used as a cache and overwritten by `initializePlugins` whenever plugins loaded through the command-line need reloading. Not to mention that there isn't a meaningful way to fill the `_conjure_up_modiface` hole AFAIK. While in principle it might be possible to use source plugins via the API right now by messing with the exposed cmdline flags the right way it feels much cleaner to just have a new type of plugin that can be added to GHC right through the API. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 02:16:02 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 02:16:02 -0000 Subject: [GHC] #15826: Allow registering (Source)Plugins through the GHC API (was: Allow using (Source)Plugins through the GHC API) In-Reply-To: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> References: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> Message-ID: <061.6a45a822a0b0a801c185e2ceed596198@haskell.org> #15826: Allow registering (Source)Plugins through the GHC API -------------------------------------+------------------------------------- Reporter: DanielG | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 02:26:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 02:26:21 -0000 Subject: [GHC] #15826: Allow registering (Source)Plugins through the GHC API In-Reply-To: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> References: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> Message-ID: <061.212f8480e56e3d7e3a80a15f27d64107@haskell.org> #15826: Allow registering (Source)Plugins through the GHC API -------------------------------------+------------------------------------- Reporter: DanielG | Owner: DanielG Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by DanielG): * owner: (none) => DanielG * component: Compiler => GHC API -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 02:32:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 02:32:09 -0000 Subject: [GHC] #15826: Allow registering (Source)Plugins through the GHC API In-Reply-To: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> References: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> Message-ID: <061.d2b751ff508c2dceb4660ca37e32989d@haskell.org> #15826: Allow registering (Source)Plugins through the GHC API -------------------------------------+------------------------------------- Reporter: DanielG | Owner: DanielG Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D5278 Wiki Page: | -------------------------------------+------------------------------------- Changes (by DanielG): * differential: => D5278 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 02:35:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 02:35:15 -0000 Subject: [GHC] #15818: Bump template-haskell version to 2.15.0.0 In-Reply-To: <050.7dd82309efae97acbaeca8205c2e0f7b@haskell.org> References: <050.7dd82309efae97acbaeca8205c2e0f7b@haskell.org> Message-ID: <065.4fefc0867d8ba93e2763bbf7464fe98c@haskell.org> #15818: Bump template-haskell version to 2.15.0.0 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2600, #14268 | Differential Rev(s): Phab:D5272 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"e8a652f65318cf60e856f7c2777a003eba10ddc6/ghc" e8a652f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e8a652f65318cf60e856f7c2777a003eba10ddc6" Bump template-haskell version to 2.15.0.0 Summary: Commit 512eeb9bb9a81e915bfab25ca16bc87c62252064 (`More explicit foralls (GHC Proposal 0007)`) introduced breaking changes to the Template Haskell AST. As a consequence of this, there are libraries in the wild that now fail to build on GHC HEAD (for instance, `th-abstraction`). This properly bumps the `template-haskell` library's version number to `2.15.0.0` so that these libraries can guard against these changes using `MIN_VERSION_template_haskell`. Test Plan: ./validate Reviewers: bgamari Reviewed By: bgamari Subscribers: rwbarton, carter GHC Trac Issues: #15818 Differential Revision: https://phabricator.haskell.org/D5272 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 02:36:12 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 02:36:12 -0000 Subject: [GHC] #15818: Bump template-haskell version to 2.15.0.0 In-Reply-To: <050.7dd82309efae97acbaeca8205c2e0f7b@haskell.org> References: <050.7dd82309efae97acbaeca8205c2e0f7b@haskell.org> Message-ID: <065.8ef8377c061f23c3443e5d99a621107a@haskell.org> #15818: Bump template-haskell version to 2.15.0.0 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #2600, #14268 | Differential Rev(s): Phab:D5272 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Thanks, Ryan! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 03:17:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 03:17:59 -0000 Subject: [GHC] #15592: Type families without CUSKs cannot be given visible kind variable binders In-Reply-To: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> References: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> Message-ID: <065.b6440e24b050a5661e9d2253dc68db98@haskell.org> #15592: Type families without CUSKs cannot be given visible kind variable binders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | TypeApplications, TypeFamilies, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14880 | Blocking: Related Tickets: #15591 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3/ghc" 5e45ad10/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3" Finish fix for #14880. The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. Fixing this required reworking candidateQTyVarsOfType, the function that extracts free variables as candidates for quantification. One consequence is that we now must be more careful when quantifying: any skolems around must be quantified manually, and quantifyTyVars will now only quantify over metavariables. This makes good sense, as skolems are generally user-written and are listed in the AST. As a bonus, we now have more control over the ordering of such skolems. Along the way, this commit fixes #15711 and refines the fix to #14552 (by accepted a program that was previously rejected, as we can now accept that program by zapping variables to Any). This commit also does a fair amount of rejiggering kind inference of datatypes. Notably, we now can skip the generalization step in kcTyClGroup for types with CUSKs, because we get the kind right the first time. This commit also thus fixes #15743 and #15592, which both concern datatype kind generalisation. (#15591 is also very relevant.) For this aspect of the commit, see Note [Required, Specified, and Inferred in types] in TcTyClsDecls. Test cases: dependent/should_fail/T14880{,-2}, dependent/should_fail/T15743[cd] dependent/should_compile/T15743{,e} ghci/scripts/T15743b polykinds/T15592 dependent/should_fail/T15591[bc] ghci/scripts/T15591 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 03:17:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 03:17:59 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.b3a3afb333dbcf19857105a0ca5df46f@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.6.2 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: 15592 Related Tickets: #15076 | Differential Rev(s): Phab:D4769, | Phab:D5141, Phab:D5147, Phab:D5150, Wiki Page: | Phab:D5208 -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3/ghc" 5e45ad10/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3" Finish fix for #14880. The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. Fixing this required reworking candidateQTyVarsOfType, the function that extracts free variables as candidates for quantification. One consequence is that we now must be more careful when quantifying: any skolems around must be quantified manually, and quantifyTyVars will now only quantify over metavariables. This makes good sense, as skolems are generally user-written and are listed in the AST. As a bonus, we now have more control over the ordering of such skolems. Along the way, this commit fixes #15711 and refines the fix to #14552 (by accepted a program that was previously rejected, as we can now accept that program by zapping variables to Any). This commit also does a fair amount of rejiggering kind inference of datatypes. Notably, we now can skip the generalization step in kcTyClGroup for types with CUSKs, because we get the kind right the first time. This commit also thus fixes #15743 and #15592, which both concern datatype kind generalisation. (#15591 is also very relevant.) For this aspect of the commit, see Note [Required, Specified, and Inferred in types] in TcTyClsDecls. Test cases: dependent/should_fail/T14880{,-2}, dependent/should_fail/T15743[cd] dependent/should_compile/T15743{,e} ghci/scripts/T15743b polykinds/T15592 dependent/should_fail/T15591[bc] ghci/scripts/T15591 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 03:17:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 03:17:59 -0000 Subject: [GHC] #15711: Kind inference of class variables does not examine associated types In-Reply-To: <047.36e9feede9f94c1f90dd44b967991991@haskell.org> References: <047.36e9feede9f94c1f90dd44b967991991@haskell.org> Message-ID: <062.7518d530ed11b08eae7b81ad70503f7e@haskell.org> #15711: Kind inference of class variables does not examine associated types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3/ghc" 5e45ad10/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3" Finish fix for #14880. The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. Fixing this required reworking candidateQTyVarsOfType, the function that extracts free variables as candidates for quantification. One consequence is that we now must be more careful when quantifying: any skolems around must be quantified manually, and quantifyTyVars will now only quantify over metavariables. This makes good sense, as skolems are generally user-written and are listed in the AST. As a bonus, we now have more control over the ordering of such skolems. Along the way, this commit fixes #15711 and refines the fix to #14552 (by accepted a program that was previously rejected, as we can now accept that program by zapping variables to Any). This commit also does a fair amount of rejiggering kind inference of datatypes. Notably, we now can skip the generalization step in kcTyClGroup for types with CUSKs, because we get the kind right the first time. This commit also thus fixes #15743 and #15592, which both concern datatype kind generalisation. (#15591 is also very relevant.) For this aspect of the commit, see Note [Required, Specified, and Inferred in types] in TcTyClsDecls. Test cases: dependent/should_fail/T14880{,-2}, dependent/should_fail/T15743[cd] dependent/should_compile/T15743{,e} ghci/scripts/T15743b polykinds/T15592 dependent/should_fail/T15591[bc] ghci/scripts/T15591 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 03:17:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 03:17:59 -0000 Subject: [GHC] #15591: Inconsistent kind variable binder visibility between associated and non-associated type families In-Reply-To: <050.8a27896ec689dcb3ecd15da9e935f56e@haskell.org> References: <050.8a27896ec689dcb3ecd15da9e935f56e@haskell.org> Message-ID: <065.d308b8deebba26164ca0d697631fd3b2@haskell.org> #15591: Inconsistent kind variable binder visibility between associated and non- associated type families -------------------------------------+------------------------------------- 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: | ghci/scripts/T15591 Blocked By: | Blocking: Related Tickets: #15592 | Differential Rev(s): Phab:D5159 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3/ghc" 5e45ad10/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3" Finish fix for #14880. The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. Fixing this required reworking candidateQTyVarsOfType, the function that extracts free variables as candidates for quantification. One consequence is that we now must be more careful when quantifying: any skolems around must be quantified manually, and quantifyTyVars will now only quantify over metavariables. This makes good sense, as skolems are generally user-written and are listed in the AST. As a bonus, we now have more control over the ordering of such skolems. Along the way, this commit fixes #15711 and refines the fix to #14552 (by accepted a program that was previously rejected, as we can now accept that program by zapping variables to Any). This commit also does a fair amount of rejiggering kind inference of datatypes. Notably, we now can skip the generalization step in kcTyClGroup for types with CUSKs, because we get the kind right the first time. This commit also thus fixes #15743 and #15592, which both concern datatype kind generalisation. (#15591 is also very relevant.) For this aspect of the commit, see Note [Required, Specified, and Inferred in types] in TcTyClsDecls. Test cases: dependent/should_fail/T14880{,-2}, dependent/should_fail/T15743[cd] dependent/should_compile/T15743{,e} ghci/scripts/T15743b polykinds/T15592 dependent/should_fail/T15591[bc] ghci/scripts/T15591 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 03:17:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 03:17:59 -0000 Subject: [GHC] #14552: GHC panic on pattern synonym In-Reply-To: <051.4b03121ed30f162401f20f20b19c9597@haskell.org> References: <051.4b03121ed30f162401f20f20b19c9597@haskell.org> Message-ID: <066.4cd493604189f52a3d3f308cc0b0f21d@haskell.org> #14552: GHC panic on pattern synonym -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.3 Resolution: fixed | Keywords: | PatternSynonyms, TypeInType, | ViewPatterns Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | testsuite/tests/patsyn/should_fail/T14552 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3/ghc" 5e45ad10/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3" Finish fix for #14880. The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. Fixing this required reworking candidateQTyVarsOfType, the function that extracts free variables as candidates for quantification. One consequence is that we now must be more careful when quantifying: any skolems around must be quantified manually, and quantifyTyVars will now only quantify over metavariables. This makes good sense, as skolems are generally user-written and are listed in the AST. As a bonus, we now have more control over the ordering of such skolems. Along the way, this commit fixes #15711 and refines the fix to #14552 (by accepted a program that was previously rejected, as we can now accept that program by zapping variables to Any). This commit also does a fair amount of rejiggering kind inference of datatypes. Notably, we now can skip the generalization step in kcTyClGroup for types with CUSKs, because we get the kind right the first time. This commit also thus fixes #15743 and #15592, which both concern datatype kind generalisation. (#15591 is also very relevant.) For this aspect of the commit, see Note [Required, Specified, and Inferred in types] in TcTyClsDecls. Test cases: dependent/should_fail/T14880{,-2}, dependent/should_fail/T15743[cd] dependent/should_compile/T15743{,e} ghci/scripts/T15743b polykinds/T15592 dependent/should_fail/T15591[bc] ghci/scripts/T15591 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 03:17:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 03:17:59 -0000 Subject: [GHC] #15743: Nail down the Required/Inferred/Specified story In-Reply-To: <046.20125fa3baabaa154b0336067d36471f@haskell.org> References: <046.20125fa3baabaa154b0336067d36471f@haskell.org> Message-ID: <061.32f4cde0e7e6a8aa5244cb258ff0e8ac@haskell.org> #15743: Nail down the Required/Inferred/Specified story -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3/ghc" 5e45ad10/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3" Finish fix for #14880. The real change that fixes the ticket is described in Note [Naughty quantification candidates] in TcMType. Fixing this required reworking candidateQTyVarsOfType, the function that extracts free variables as candidates for quantification. One consequence is that we now must be more careful when quantifying: any skolems around must be quantified manually, and quantifyTyVars will now only quantify over metavariables. This makes good sense, as skolems are generally user-written and are listed in the AST. As a bonus, we now have more control over the ordering of such skolems. Along the way, this commit fixes #15711 and refines the fix to #14552 (by accepted a program that was previously rejected, as we can now accept that program by zapping variables to Any). This commit also does a fair amount of rejiggering kind inference of datatypes. Notably, we now can skip the generalization step in kcTyClGroup for types with CUSKs, because we get the kind right the first time. This commit also thus fixes #15743 and #15592, which both concern datatype kind generalisation. (#15591 is also very relevant.) For this aspect of the commit, see Note [Required, Specified, and Inferred in types] in TcTyClsDecls. Test cases: dependent/should_fail/T14880{,-2}, dependent/should_fail/T15743[cd] dependent/should_compile/T15743{,e} ghci/scripts/T15743b polykinds/T15592 dependent/should_fail/T15591[bc] ghci/scripts/T15591 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 03:17:59 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 03:17:59 -0000 Subject: [GHC] #15787: GHC panic using kind application In-Reply-To: <051.88158355ed422210999943d4c175f35d@haskell.org> References: <051.88158355ed422210999943d4c175f35d@haskell.org> Message-ID: <066.b5b4fefec65b5508e1af7933019caf31@haskell.org> #15787: GHC panic using kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5275 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"4427315a65b25db22e1754d41b43dd4b782b022f/ghc" 4427315/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4427315a65b25db22e1754d41b43dd4b782b022f" Fix #15787 by squashing a coercion hole. In type-incorrect code, we can sometimes let a coercion hole make it through the zonker. If this coercion hole then ends up in the environment (e.g., in the type of a data constructor), then it causes trouble later. This patch avoids trouble by substituting the coercion hole for its representative CoVar. Really, any coercion would do, but the CoVar was very handy. test case: polykinds/T15787 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 03:31:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 03:31:39 -0000 Subject: [GHC] #15787: GHC panic using kind application In-Reply-To: <051.88158355ed422210999943d4c175f35d@haskell.org> References: <051.88158355ed422210999943d4c175f35d@haskell.org> Message-ID: <066.93813d614263e0eaec998cdecf1c8110@haskell.org> #15787: GHC panic using kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T15787 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5275 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => polykinds/T15787 Comment: Should be easy to merge this one. If it isn't, no worries, as I think it's only an assertion failure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 03:34:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 03:34:49 -0000 Subject: [GHC] #15743: Nail down the Required/Inferred/Specified story In-Reply-To: <046.20125fa3baabaa154b0336067d36471f@haskell.org> References: <046.20125fa3baabaa154b0336067d36471f@haskell.org> Message-ID: <061.3af24feb5a9a28ad2c0badd085684207@haskell.org> #15743: Nail down the Required/Inferred/Specified story -------------------------------------+------------------------------------- Reporter: simonpj | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_fail/T15743[cd], | dependent/should_compile/T15743{,e}, | ghci/scripts/T15743b Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => dependent/should_fail/T15743[cd], dependent/should_compile/T15743{,e}, ghci/scripts/T15743b * status: new => closed * resolution: => fixed Comment: The design decisions are written in {{{ {- Note [Required, Specified, and Inferred for types] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We have some design choices in how we classify the tyvars bound in a type declaration. (Here, I use "type" to refer to any TyClDecl.) Much of the debate is memorialized in #15743. This Note documents the final conclusion. First, a reminder: * a Required argument is one that must be provided at every call site * a Specified argument is one that can be inferred at call sites, but may be instantiated with visible type application * an Inferred argument is one that must be inferred at call sites; it is unavailable for use with visible type application. Why have Inferred at all? Because we just can't make user-facing promises about the ordering of some variables. These might swizzle around even between minor released. By forbidding visible type application, we ensure users aren't caught unawares. See also Note [VarBndrs, TyCoVarBinders, TyConBinders, and visibility] in TyCoRep. When inferring the ordering of variables (that is, for those variables that he user has not specified the order with an explicit `forall`) we use the following order: 1. Inferred variables from an enclosing class (associated types only) 2. Specified variables from an enclosing class (associated types only) 3. Inferred variables not from an enclosing class 4. Specified variables not from an enclosing class 5. Required variables before a top-level :: 6. All variables after a top-level :: If this ordering does not make a valid telescope, we reject the definition. This idea is implemented in the generalise function within kcTyClGroup (for declarations without CUSKs), and in kcLHsQTyVars (for declarations with CUSKs). Note that neither definition worries about point (6) above, as this is nicely handled by not mangling the res_kind. (Mangling res_kinds is done *after* all this stuff, in tcDataDefn's call to tcDataKindSig.) We can easily tell Inferred apart from Specified by looking at the scoped tyvars; Specified are always included there. One other small open question here: how to classify variables from an enclosing class? Here is an example: class C (a :: k) where type F a In the kind of F, should k be Inferred or Specified? Currently, we mark it as Specified, as we can commit to an ordering, based on the ordering of class variables in the enclosing class declaration. If k were not mentioned in the class head, then it would be Inferred. The alternative to this approach is to make the Inferred/Specified distinction locally, by just looking at the declaration for F. This lowers the availability of type application, but makes the reasoning more local. However, this alternative also disagrees with the treatment for methods, where all class variables are Specified, regardless of whether or not the variable is mentioned in the method type. A few points of motivation for the ordering above: * We put the class variables before the local variables in a nod to the treatment for class methods, where class variables (and the class constraint) come first. While this is an unforced design decision, it never rejects more declarations, as class variables can never depend on local variables. * We rigidly require the ordering above, even though we could be much more permissive. Relevant musings are at https://ghc.haskell.org/trac/ghc/ticket/15743#comment:7 The bottom line conclusion is that, if the user wants a different ordering, then can specify it themselves, and it is better to be predictable and dumb than clever and capricious. I (Richard) conjecture we could be fully permissive, allowing all classes of variables to intermix. We would have to augment ScopedSort to refuse to reorder Required variables (or check that it wouldn't have). But this would allow more programs. See #15743 for examples. Interestingly, Idris seems to allow this intermixing. The intermixing would be fully specified, in that we can be sure that inference wouldn't change between versions. However, would users be able to predict it? That I cannot answer. Test cases (and tickets) relevant to these design decisions: T15591* T15592* T15743* -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 03:36:42 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 03:36:42 -0000 Subject: [GHC] #15711: Kind inference of class variables does not examine associated types In-Reply-To: <047.36e9feede9f94c1f90dd44b967991991@haskell.org> References: <047.36e9feede9f94c1f90dd44b967991991@haskell.org> Message-ID: <062.4ea098681fc04c90ce754e2ff34b1ac1@haskell.org> #15711: Kind inference of class variables does not examine associated types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): It looks like I forgot to add a test case. If someone gets to this before I do, I'd be grateful. Perhaps tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 03:38:06 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 03:38:06 -0000 Subject: [GHC] #14880: GHC panic: updateRole In-Reply-To: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> References: <050.cdd24a949fb0169408d9edbb528c50d3@haskell.org> Message-ID: <065.5ecac21cce83f806842b18f7caf8bfd7@haskell.org> #14880: GHC panic: updateRole -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.6.2 Component: Compiler (Type | Version: 8.2.2 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | dependent/should_fail/T14880{,-2} Blocked By: | Blocking: 15592 Related Tickets: #15076 | Differential Rev(s): Phab:D4769, | Phab:D5141, Phab:D5147, Phab:D5150, Wiki Page: | Phab:D5208 -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => dependent/should_fail/T14880{,-2} * status: new => closed * resolution: => fixed Comment: I believe that this, finally, can be put to bed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 03:52:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 03:52:03 -0000 Subject: [GHC] #15816: Visible kind applications + data family: `U :: Type' said to be of kind `k0 -> k1` in error message In-Reply-To: <051.7ad8c9c507f1bdc5ee6ac158821e5a9c@haskell.org> References: <051.7ad8c9c507f1bdc5ee6ac158821e5a9c@haskell.org> Message-ID: <066.90ef0fb983ee45a553323e7ca989a7ba@haskell.org> #15816: Visible kind applications + data family: `U :: Type' said to be of kind `k0 -> k1` in error message -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * cc: mnguyen (added) Comment: This one looks like a legit bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 04:21:14 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 04:21:14 -0000 Subject: [GHC] #15788: Core Lint error, from visible kind applications In-Reply-To: <051.9512af2451069a0fc0b33528cf855ee3@haskell.org> References: <051.9512af2451069a0fc0b33528cf855ee3@haskell.org> Message-ID: <066.5ee5eaaf66d86109ec4d80355974ea50@haskell.org> #15788: Core Lint error, from visible kind applications -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: #12045 Operating System: 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): #15743 is solved now. When the kind applications patch is rebased, I expect this will be fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 10:38:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 10:38:21 -0000 Subject: [GHC] #15592: Type families without CUSKs cannot be given visible kind variable binders In-Reply-To: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> References: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> Message-ID: <065.b22025ed35e8c3b9d60b476d23c24ac7@haskell.org> #15592: Type families without CUSKs cannot be given visible kind variable binders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | TypeApplications, TypeFamilies, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14880 | Blocking: Related Tickets: #15591 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): After the commit in comment:15, the program from comment:9: {{{#!hs class C a where type T (x :: (f :: k -> Type) a) }}} Now typechecks again. There doesn't appear to be a test case for this, however. Worth checking in? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 10:41:09 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 10:41:09 -0000 Subject: [GHC] #15076: Typed hole with higher-rank kind causes GHC to panic (No skolem info) In-Reply-To: <050.9e6ebeaf2e39bca10b356bf245888851@haskell.org> References: <050.9e6ebeaf2e39bca10b356bf245888851@haskell.org> Message-ID: <065.67f92d5ebe3c39cd98b740bd9df5a6d2@haskell.org> #15076: Typed hole with higher-rank kind causes GHC to panic (No skolem info) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: TypedHoles, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14040, #14880 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): After commit 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3 (Finish fix for #14880.), the programs in this ticket no longer panic/throw a Core Lint error. Should we claim victory on this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 10:44:40 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 10:44:40 -0000 Subject: [GHC] #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] In-Reply-To: <050.973ad933fee1878607a6ab042ec05467@haskell.org> References: <050.973ad933fee1878607a6ab042ec05467@haskell.org> Message-ID: <065.564fa4db1f45db82f1d4bbf71ca348ac@haskell.org> #14040: Typed holes regression in GHC 8.0.2: No skolem info: z_a1sY[sk:2] -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.0.2 checker) | Keywords: TypeInType, Resolution: | TypeFamilies, | PartialTypeSignatures, TypedHoles Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: partial- crash or panic | sigs/should_fail/T14040a Blocked By: | Blocking: Related Tickets: #13877, #15076 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): simonpj, isn't it expected that GHC would complain if you implemented `elimWeirdList` as `elimWeirdList x = error "urk"`? After all, `elimWeirdList` contains higher-rank arguments, and trying to instantiate them with `error "urk" :: forall a. a` would require instantiating `a` with a polytype, which is impredicative. Also, it's worth noting that on GHC HEAD, you get one fewer error than you do in comment:12: {{{ GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:37:1: error: Can't quantify over ‘a’ bound by the partial type signature: elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl | 37 | elimWeirdList x = error "urk" | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Bug.hs:37:1: error: Can't quantify over ‘wl’ bound by the partial type signature: elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl | 37 | elimWeirdList x = error "urk" | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Bug.hs:37:1: error: Can't quantify over ‘p’ bound by the partial type signature: elimWeirdList :: forall (a :: Type) (wl :: WeirdList a) (p :: forall (x :: Type). x -> WeirdList x -> Type). Sing wl -> (forall (y :: Type). p _ WeirdNil) -> (forall (z :: Type) (x :: z) (xs :: WeirdList (WeirdList z)). Sing x -> Sing xs -> p _ xs -> p _ (WeirdCons x xs)) -> p _ wl | 37 | elimWeirdList x = error "urk" | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Failed, no modules loaded. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 10:50:27 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 10:50:27 -0000 Subject: [GHC] #15825: Core Lint error from Explicit Foralls Proposal In-Reply-To: <051.14c6056f3f80a08cd54db3d963a264a6@haskell.org> References: <051.14c6056f3f80a08cd54db3d963a264a6@haskell.org> Message-ID: <066.a3b3abf7a93a78e7f8f175e8fe228b87@haskell.org> #15825: Core Lint error from Explicit Foralls Proposal -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This is fixed on GHC HEAD as of commit 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3 (Finish fix for #14880.). It now gives a proper error message: {{{ $ ghc2/inplace/bin/ghc-stage2 --interactive Bug.hs -fprint-explicit-kinds GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Main ( Bug.hs, interpreted ) Bug.hs:12:29: error: • Illegal type synonym family application ‘GHC.Types.Any k’ in instance: X (a (GHC.Types.Any k)) • In the instance declaration for ‘X (a :: *)’ | 12 | instance forall (a :: C k). X (a :: *) | ^^^^^^^^^^ }}} TODO: Check this program in as a test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 10:52:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 10:52:32 -0000 Subject: [GHC] #15787: GHC panic using kind application In-Reply-To: <051.88158355ed422210999943d4c175f35d@haskell.org> References: <051.88158355ed422210999943d4c175f35d@haskell.org> Message-ID: <066.47251735caf0a1252b54b91d23fe11f6@haskell.org> #15787: GHC panic using kind application -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T15787 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5275 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: => 8.6.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 11:22:03 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 11:22:03 -0000 Subject: [GHC] #15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7 In-Reply-To: <048.2e4683ede5797175b196c3bdda927d9f@haskell.org> References: <048.2e4683ede5797175b196c3bdda927d9f@haskell.org> Message-ID: <063.587ba3ae60174a44686c356d71f27292@haskell.org> #15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7 -------------------------------------+------------------------------------- Reporter: ki11men0w | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: ghc-pkg | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4917 Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamse): The fix for this did not make it into 8.4.4, making the windows 32bit binaries not very useable. Can this patch be considered for inclusion if there is a 8.4.5 release? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 11:41:23 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 11:41:23 -0000 Subject: [GHC] #15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7 In-Reply-To: <048.2e4683ede5797175b196c3bdda927d9f@haskell.org> References: <048.2e4683ede5797175b196c3bdda927d9f@haskell.org> Message-ID: <063.d934ac4053abfc08a16cf234ae8ea8bf@haskell.org> #15154: Segmentation fault of ghc-pkg.exe from 32-bit distribution of ghc-8.2.2 on Windows 7 -------------------------------------+------------------------------------- Reporter: ki11men0w | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.1 Component: ghc-pkg | Version: 8.2.2 Resolution: fixed | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Compile-time | Test Case: crash or panic | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4917 Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamse): * cc: adamse (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 12:55:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 12:55:01 -0000 Subject: [GHC] #15827: Explicit foralls in type family equations are pretty-printed inconsistently (and strangely, at times) Message-ID: <050.3fc87a286139ce270bb50311698ddbd5@haskell.org> #15827: Explicit foralls in type family equations are pretty-printed inconsistently (and strangely, at times) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: TypeFamilies | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Load the following code into GHCi HEAD (8.7+): {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Kind type family F1 a type instance forall a. F1 a = Maybe a type family F2 a where forall a. F2 a = Maybe a data family D a data instance forall a. D a = MkD (Maybe a) }}} And make sure you have the `-fprint-explicit-foralls` flag enabled. Now let's see what happens when we look up the `:info` for each of these type families: {{{ $ ~/Software/ghc2/inplace/bin/ghc-stage2 --interactive Bug.hs -fprint- explicit-foralls GHCi, version 8.7.20181029: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Ok, one module loaded. λ> :i F1 type family F1 a :: * -- Defined at Bug.hs:7:1 type instance F1 a = Maybe a -- Defined at Bug.hs:8:25 λ> :i F2 type family F2 a :: * where [a] F2 a = Maybe a -- Defined at Bug.hs:10:1 λ> :i D data family D a -- Defined at Bug.hs:13:1 data instance D a = MkD (Maybe a) -- Defined at Bug.hs:14:25 }}} There are two strange things of note here: * The equations for `F1` and `D` do not have any explicit `forall`s displayed at all, despite the fact that `-fprint-explicit-foralls` is enabled. * The equation for `F2` //does// have an explicit `forall` displayed, but in a rather bizarre fashion: {{{ λ> :i F2 type family F2 a :: * where [a] F2 a = Maybe a -- Defined at Bug.hs:10:1 }}} I certainly wasn't expecting to see the type variables in square brackets. I would have hoped to see something like this instead: {{{ λ> :i F2 type family F2 a :: * where forall a. F2 a = Maybe a -- Defined at Bug.hs:10:1 }}} Now that the "more explicit `forall`s" proposal is implemented, my hope is that it will be somewhat simple to change the way that this is pretty- printed (we already store the explicit `forall` information within the AST, after all). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 13:00:23 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 13:00:23 -0000 Subject: [GHC] #15828: Type family equation foralls allow strange re-quantification of class-bound type variables Message-ID: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> #15828: Type family equation foralls allow strange re-quantification of class-bound type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: TypeFamilies | 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 typechecks on GHC HEAD (8.7+): {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} module Bug where import Data.Kind class C1 a where type T1 a b class C2 a where type T2 a b instance C1 (Maybe a) where type forall a b. T1 (Maybe a) b = b instance C2 (Maybe a) where type forall b. T2 (Maybe a) b = b }}} But ought it to? There is something funny happening in the `C1` instance: it's explicitly quantifying `a`, despite the fact that it had previously been quantified by the class head! Moreover, it appears that you can safely drop the `a` in the explicit `forall`, as the `C2 (Maybe a)` instance witnesses. What does the documentation have to say on this topic? This is all I could find: > When an explicit `forall` is present, all //type// variables mentioned must be bound by the `forall`. I couldn't find anything on the interaction between this feature and associated type families. We should: 1. Decide which of the two programs above should be accepted, and 2. Update the documentation to reflect this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 13:11:18 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 13:11:18 -0000 Subject: [GHC] #15827: Explicit foralls in type family equations are pretty-printed inconsistently (and strangely, at times) In-Reply-To: <050.3fc87a286139ce270bb50311698ddbd5@haskell.org> References: <050.3fc87a286139ce270bb50311698ddbd5@haskell.org> Message-ID: <065.3662e9309e7d9eb872879e0a90bf8df4@haskell.org> #15827: Explicit foralls in type family equations are pretty-printed inconsistently (and strangely, at times) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Hm, it appears that fixing this may not be as straightforward as I would have hoped. The main issue that I encountered is that `:info` displays type family equations by first converting them to their interface file equivalents and then pretty-printing them. Take a look at [http://git.haskell.org/ghc.git/blob/4427315a65b25db22e1754d41b43dd4b782b022f:/compiler/iface/IfaceSyn.hs#l215 IfaceAxBranch] (which is the interface file incarnation of a type family equation), for instance: {{{#!hs data IfaceAxBranch = IfaceAxBranch { ifaxbTyVars :: [IfaceTvBndr] , ifaxbCoVars :: [IfaceIdBndr] , ... } }}} Notice that this stores type variable information (`ifaxbTyVars`) as `IfaceTvBndr`s instead of `IfaceTyConBinder`s. This is an important distinction because essentially all of the machinery within `IfaceType` that pretty-prints explicit `forall`s works over `IfaceTyConBinder`s, not `IfaceTvBndr`s. (This makes some amount of sense since an `IfaceTyConBinder` stores visibility information but an `IfaceTvBinder` does not.) I suppose that we could just convert the `ifaxbTyVars` to `IfaceTyConBinder`s (defaulting each variable's visibility to specified) before pretty-printing. But there's another challenge: how should we print the `ifaxbCoVars`? The [http://git.haskell.org/ghc.git/blob/4427315a65b25db22e1754d41b43dd4b782b022f:/compiler/iface/IfaceSyn.hs#l560 existing code] for pretty-printing `IfaceAxBranch`es actually does take `ifaxbCoVars` into account at the moment: {{{#!hs pprAxBranch pp_tc (IfaceAxBranch { ifaxbTyVars = tvs , ifaxbCoVars = cvs , ifaxbLHS = pat_tys , ifaxbRHS = rhs , ifaxbIncomps = incomps }) = hang ppr_binders 2 (hang pp_lhs 2 (equals <+> ppr rhs)) $+$ nest 2 maybe_incomps where ppr_binders = sdocWithDynFlags $ \dflags -> ppWhen (gopt Opt_PrintExplicitForalls dflags) ppr_binders' ppr_binders' | null tvs && null cvs = empty | null cvs = brackets (pprWithCommas (pprIfaceTvBndr True) tvs) | otherwise = brackets (pprWithCommas (pprIfaceTvBndr True) tvs <> semi <+> pprWithCommas pprIfaceIdBndr cvs) }}} I'm not sure what this code should become if we start using the `forall` keyword instead. To make things even more confusing, the [http://git.haskell.org/ghc.git/blob/4427315a65b25db22e1754d41b43dd4b782b022f:/compiler/types/CoAxiom.hs#l219 comments] for `CoAxBranch`: {{{#!hs data CoAxBranch = CoAxBranch { ... , cab_tvs :: [TyVar] -- Bound type variables; not necessarily fresh -- See Note [CoAxBranch type variables] -- May be eta-reduded; see FamInstEnv -- Note [Eta reduction for data families] , cab_cvs :: [CoVar] -- Bound coercion variables -- Always empty, for now. -- See Note [Constraints in patterns] -- in TcTyClsDecls , ... } }}} Suggest that the bound coercion variables in a coaxiom branch are always empty in practice! So is it even worth fretting over them? Perhaps an expert in this area could answer this question, but I'm far from that expert. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 13:23:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 13:23:01 -0000 Subject: [GHC] #15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable In-Reply-To: <043.18564262c59dae41f0454bb2c0047a1d@haskell.org> References: <043.18564262c59dae41f0454bb2c0047a1d@haskell.org> Message-ID: <058.10d787f8d3dbaf2df93ff6a612ad178d@haskell.org> #15758: hsc2hs broken due to incorrect argument passing to the hsc2hs executable -------------------------------------+------------------------------------- Reporter: osa1 | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5238, Wiki Page: | Phab:D5250 -------------------------------------+------------------------------------- Changes (by ckoparkar): * status: new => closed * differential: Phab:D5238 => Phab:D5238, Phab:D5250 * resolution: => fixed Comment: Now that Phab:D5238 and Phab:D5250 have landed, and hsc2hs-0.68.4 has been updated to have the correct revision on Hackage, I believe we've addressed all the issues uncovered by this ticket. I verified that I can build {{{regex-posix}}} with GHC HEAD, and also the simple {{{Foo.hsc}}} example from comment:3 works. I'll go ahead and close this. (Let's re-open if there are more things that need to be done.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 13:35:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 13:35:15 -0000 Subject: [GHC] #15827: Explicit foralls in type family equations are pretty-printed inconsistently (and strangely, at times) In-Reply-To: <050.3fc87a286139ce270bb50311698ddbd5@haskell.org> References: <050.3fc87a286139ce270bb50311698ddbd5@haskell.org> Message-ID: <065.4413744f1c1ae37a151a30b90e982651@haskell.org> #15827: Explicit foralls in type family equations are pretty-printed inconsistently (and strangely, at times) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The covars are always empty. That comment is right. Along the way to `-XTypeInType`, there were some scenarios where the covars weren't empty. Mutterings to self are memorialized [https://ghc.haskell.org/trac/ghc/wiki/DependentHaskell/Internal#Matchingaxioms here]. As for pretty-printing behavior, I have a few observations: - The AST indeed stores whether or not the user wrote a `forall`, because some of the warnings, etc., are different based on this choice. However, once a type family equation is accepted, the presence/absence of the `forall` is immaterial. - The order of variables in the `forall` is immaterial to users. Not sure if this is a problem at all, but there's never a way to manually instantiate the variables, so we don't have to care about order. - Visibility/specificity is simply not a thing for the variables bound in a type family equation, also because the user can't ever instantiate these manually. - The funny `[a]` syntax was invented because using `forall` here is a tiny bit of a lie: `forall` is a specific construct in Core that does not exist in type family equations (i.e. coercion axioms). I don't think this is useful or friendly to users, though. Do these design points help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 13:38:32 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 13:38:32 -0000 Subject: [GHC] #15828: Type family equation foralls allow strange re-quantification of class-bound type variables In-Reply-To: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> References: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> Message-ID: <065.9e1f3b67b124c8674965ad20426fbd1a@haskell.org> #15828: Type family equation foralls allow strange re-quantification of class-bound type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * cc: mayac (added) Comment: I vote strongly for `C2`. `C1` should be rejected because the local `a` shadows the class-bound `a`, and so the associated type family equation doesn't match its template. You forgot to mention that we need to 3. Fix the implementation. @mayac, do you want to see this (and any other oddities that pop up) through? Or would you prefer that others (perhaps me) fix any problems that arise? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 13:39:22 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 13:39:22 -0000 Subject: [GHC] #15827: Explicit foralls in type family equations are pretty-printed inconsistently (and strangely, at times) In-Reply-To: <050.3fc87a286139ce270bb50311698ddbd5@haskell.org> References: <050.3fc87a286139ce270bb50311698ddbd5@haskell.org> Message-ID: <065.df31f38f50ef8c45ae63b1da857e0595@haskell.org> #15827: Explicit foralls in type family equations are pretty-printed inconsistently (and strangely, at times) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): OK. In that case, my tentative plan is to: * Not print the coercion variables at all. * Pretty-print the type variables by first converting them to `IfaceForAllBinder`s (defaulting their visibilities to specified //à la// `mkSpecForAllTys`) and then using a function like `pprIfaceForAll` to pretty-print them with the explicit `forall` syntax. Does that sound reasonable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 13:40:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 13:40:50 -0000 Subject: [GHC] #15827: Explicit foralls in type family equations are pretty-printed inconsistently (and strangely, at times) In-Reply-To: <050.3fc87a286139ce270bb50311698ddbd5@haskell.org> References: <050.3fc87a286139ce270bb50311698ddbd5@haskell.org> Message-ID: <065.795f6b5358d0449dc806203759b72622@haskell.org> #15827: Explicit foralls in type family equations are pretty-printed inconsistently (and strangely, at times) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes. Without looking at the implementation, I'm not sure: will this print the kind of the type variables whose kind is not `Type`? If so (as I imagine it is), then full speed ahead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 13:48:39 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 13:48:39 -0000 Subject: [GHC] #15825: Core Lint error from Explicit Foralls Proposal In-Reply-To: <051.14c6056f3f80a08cd54db3d963a264a6@haskell.org> References: <051.14c6056f3f80a08cd54db3d963a264a6@haskell.org> Message-ID: <066.7e91991e449bd57a78ed94f0aa6a213b@haskell.org> #15825: Core Lint error from Explicit Foralls Proposal -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Is that error message "proper"? I'm not sure. But at least it's technically correct, and I'd be hard-pressed to do better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 13:54:14 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 13:54:14 -0000 Subject: [GHC] #15711: Kind inference of class variables does not examine associated types In-Reply-To: <047.36e9feede9f94c1f90dd44b967991991@haskell.org> References: <047.36e9feede9f94c1f90dd44b967991991@haskell.org> Message-ID: <062.0807b6dde7953d023980e91f0a02d2f2@haskell.org> #15711: Kind inference of class variables does not examine associated types -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T15711 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => indexed-types/should_compile/T15711 * status: new => closed * resolution: => fixed Comment: Test case added in c1db1eb028b6962bac904975a6730edc6935ca8f -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 15:07:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 15:07:43 -0000 Subject: [GHC] #15828: Type family equation foralls allow strange re-quantification of class-bound type variables In-Reply-To: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> References: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> Message-ID: <065.55159df5473440e3d70a1201dc951a4d@haskell.org> #15828: Type family equation foralls allow strange re-quantification of class-bound type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mayac): I also agree `C1` should be rejected, though I'm quite baffled by why that is currently not the case. It appears that the two `a`s in the `C1` example truly do have the same name post-`GhcRn`. Shouldn't `bindLHsTyVarBndrs` be coming up with a fresh name for each explicitly quantified type variable anyway? I don't think I understand enough about the way GHC comes up with new names to see where this goes wrong... In response to @goldfire, I would be happy to address these things as they come up! Of course, if someone finds a fix faster than I do they should feel free to go ahead with the change. In this case, I would need some guidance as I expressed above. As for the documentation, how about the following: > When an explicit `forall` is present, all ''type'' variables mentioned which are not already in scope must be bound by the `forall`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 15:09:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 15:09:49 -0000 Subject: [GHC] #15732: getArgsWithResponseFiles does not filter out RTS options In-Reply-To: <048.b4d2648ba00dd69525e93686e30914e8@haskell.org> References: <048.b4d2648ba00dd69525e93686e30914e8@haskell.org> Message-ID: <063.433dfba9efb90c38da0b9902d5163c8c@haskell.org> #15732: getArgsWithResponseFiles does not filter out RTS options -------------------------------------+------------------------------------- Reporter: ckoparkar | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: libraries/base | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: 15072 Related Tickets: #13896 | Differential Rev(s): Phab:D5280 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ckoparkar): * status: new => patch * differential: => Phab:D5280 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 15:09:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 15:09:58 -0000 Subject: [GHC] #15389: -Wall-missed-specialisations warnings not fatal with -Werror In-Reply-To: <047.4a848908677d999f3174dbe93ce4db9f@haskell.org> References: <047.4a848908677d999f3174dbe93ce4db9f@haskell.org> Message-ID: <062.26cb9b0b8c97c4aaf4e9d882b6b56fbe@haskell.org> #15389: -Wall-missed-specialisations warnings not fatal with -Werror -------------------------------------+------------------------------------- Reporter: ChaiTRex | 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 RolandSenn): This is not a bug! The behavior described above is documented in the [https://downloads.haskell.org/~ghc/master/users-guide/using-warnings.html users guide] in section ''7.2. Warnings and sanity-checking'': The documentations for **-Wmissed-specialisations** and **-Wall-missed- specialisations** clearly states: ''Note that this warning will not throw errors if used with -Werror.'' -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 16:08:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 16:08:25 -0000 Subject: [GHC] #15389: -Wall-missed-specialisations warnings not fatal with -Werror In-Reply-To: <047.4a848908677d999f3174dbe93ce4db9f@haskell.org> References: <047.4a848908677d999f3174dbe93ce4db9f@haskell.org> Message-ID: <062.f071fd0d78a6b49215a933dc67d28463@haskell.org> #15389: -Wall-missed-specialisations warnings not fatal with -Werror -------------------------------------+------------------------------------- Reporter: ChaiTRex | 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 ChaiTRex): It still would be a bug. The [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/using- warnings.html#ghc-flag--Werror documentation for -Werror] is: > **-Werror** > > Makes any warning into a fatal error. Useful so that you don’t miss warnings when doing batch compilation. If that documentation (and perhaps other documentation for `-Werror`) is incorrect, it should be changed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 16:37:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 16:37:25 -0000 Subject: [GHC] #15825: Core Lint error from Explicit Foralls Proposal In-Reply-To: <051.14c6056f3f80a08cd54db3d963a264a6@haskell.org> References: <051.14c6056f3f80a08cd54db3d963a264a6@haskell.org> Message-ID: <066.a9b3e603190a95602fc8161d1111931e@haskell.org> #15825: Core Lint error from Explicit Foralls Proposal -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"731c95f5167246aecd2205743a9b0d8d21bcccf9/ghc" 731c95f5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="731c95f5167246aecd2205743a9b0d8d21bcccf9" Test #15825 in dependent/should_fail/T15825 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 16:37:25 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 16:37:25 -0000 Subject: [GHC] #15076: Typed hole with higher-rank kind causes GHC to panic (No skolem info) In-Reply-To: <050.9e6ebeaf2e39bca10b356bf245888851@haskell.org> References: <050.9e6ebeaf2e39bca10b356bf245888851@haskell.org> Message-ID: <065.4a5134604ba0dd3a3ceae8d60b2e0179@haskell.org> #15076: Typed hole with higher-rank kind causes GHC to panic (No skolem info) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: TypedHoles, Resolution: | TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: #14040, #14880 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"2adffd854effc0708b9fb268749aceaf3c20a169/ghc" 2adffd8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2adffd854effc0708b9fb268749aceaf3c20a169" Test #15076 in dependent/should_compile/T15076* }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 16:38:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 16:38:37 -0000 Subject: [GHC] #15076: Typed hole with higher-rank kind causes GHC to panic (No skolem info) In-Reply-To: <050.9e6ebeaf2e39bca10b356bf245888851@haskell.org> References: <050.9e6ebeaf2e39bca10b356bf245888851@haskell.org> Message-ID: <065.ebf9a1023e22b842613c099e3cd97bd4@haskell.org> #15076: Typed hole with higher-rank kind causes GHC to panic (No skolem info) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.2.2 checker) | Keywords: TypedHoles, Resolution: fixed | TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | dependent/should_compile/T15076{,b,c} Blocked By: | Blocking: Related Tickets: #14040, #14880 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => dependent/should_compile/T15076{,b,c} * resolution: => fixed Comment: Victory! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 16:39:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 16:39:21 -0000 Subject: [GHC] #15825: Core Lint error from Explicit Foralls Proposal In-Reply-To: <051.14c6056f3f80a08cd54db3d963a264a6@haskell.org> References: <051.14c6056f3f80a08cd54db3d963a264a6@haskell.org> Message-ID: <066.b9db9924aa2a4f32fba59a194faae20a@haskell.org> #15825: Core Lint error from Explicit Foralls Proposal -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_fail/T15825 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: => dependent/should_fail/T15825 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 16:45:13 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 16:45:13 -0000 Subject: [GHC] #13408: Consider inferring a higher-rank kind for type synonyms In-Reply-To: <047.eeced9ac447a8f829efccd3a23d61888@haskell.org> References: <047.eeced9ac447a8f829efccd3a23d61888@haskell.org> Message-ID: <062.50388e036c6ab13cb3c9e5977d69c2a3@haskell.org> #13408: Consider inferring a higher-rank kind for type synonyms -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: closed => new * resolution: wontfix => Comment: I talked with goldfire today about this issue, but in a slightly different context. The issue this time was that I had: {{{#!hs data A :: Type -> Type data B a :: A a -> Type }}} And I wanted to define a type synonym alias for `B`: {{{#!hs type C = B }}} This time, we came to the opposite conclusion of comment:2 — that is, GHC //should// be able to accept this. There are two main reasons why: * Unlike in the original example, in which the RHS of a type synonym was attempting to partially apply a type synonym (which is problematic), there is no problem with partially applying a data type constructor such as `B`. * The implementation might be easier than what goldfire had originally thought when writing comment:2. In the code that kind-checks type synonym declarations, we would need to check that the type synonym is the sole declaration in a mutually recursive group. (That is to say, no funny business with recursion is going on.) If this holds true, then we could grab the kind from the RHS (even if it's fancy, like the kind of `B :: forall a -> A a -> Type`) and use that to infer the kind of the whole type synonym. Having this work is especially important in the context of this particular example since there is currently no way to write the kind `forall a -> A a -> Type` in source Haskell. (If there were a way to write this, then `type C = (B :: forall a -> A a -> Type)` would already be a suitable workaround.) goldfire, please correct me if I got any details wrong here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 16:51:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 16:51:35 -0000 Subject: [GHC] #15829: Add a test case for tricky type synonyms involving visible dependent kinds Message-ID: <050.ba2c2069958cbb45ab555b34d4496b12@haskell.org> #15829: Add a test case for tricky type synonyms involving visible dependent kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 (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: -------------------------------------+------------------------------------- This code does not typecheck on GHC 8.6.1: {{{#!hs {-# LANGUAGE DataKinds #-} {-# LANGUAGE PolyKinds #-} module Bug where import Data.Kind data A :: Type -> Type data B a :: A a -> Type type C a = B a }}} However, it //does// typecheck on GHC HEAD, after commit 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3 (Finish fix for #14880.). This is very cool, although it does alarm me that there is no test case which checks for this at the moment. Let's add one to ensure that this stays fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 17:01:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 17:01:33 -0000 Subject: [GHC] #15829: Add a test case for tricky type synonyms involving visible dependent kinds In-Reply-To: <050.ba2c2069958cbb45ab555b34d4496b12@haskell.org> References: <050.ba2c2069958cbb45ab555b34d4496b12@haskell.org> Message-ID: <065.57db9e3a25a2ef5ebc23505b75caa44c@haskell.org> #15829: Add a test case for tricky type synonyms involving visible dependent kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 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 Ryan Scott ): In [changeset:"331081b03f67c94b908136339aebf36d07d45c21/ghc" 331081b0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="331081b03f67c94b908136339aebf36d07d45c21" Add a test case for #15829 This happened to get fixed as a consequence of commit 5e45ad10ffca1ad175b10f6ef3327e1ed8ba25f3. This adds a test case to ensure that it stays fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 17:02:26 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 17:02:26 -0000 Subject: [GHC] #15829: Add a test case for tricky type synonyms involving visible dependent kinds In-Reply-To: <050.ba2c2069958cbb45ab555b34d4496b12@haskell.org> References: <050.ba2c2069958cbb45ab555b34d4496b12@haskell.org> Message-ID: <065.b131c674cdd151f7850826fd4b673419@haskell.org> #15829: Add a test case for tricky type synonyms involving visible dependent kinds -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.7 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | dependent/should_compile/T15829 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * testcase: => dependent/should_compile/T15829 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 17:48:21 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 17:48:21 -0000 Subject: [GHC] #15830: Plugins Tests are Skipped Message-ID: <045.52d150fd01a9dad256f263d57b29b82d@haskell.org> #15830: Plugins Tests are Skipped -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | Keywords: plugins test | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: plugins01 | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The test driver skips the plugins01 test after building the default flavour with hadrian. testsuite/tests/plugins/all.T specifies `only_ways([config.ghc_plugin_way]`. Some how this condition is not met. Open questions: * Are all plugin* tests skipped? * Are these tests also skipped when built/run via make? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 17:48:38 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 17:48:38 -0000 Subject: [GHC] #15830: Plugins Tests are Skipped In-Reply-To: <045.52d150fd01a9dad256f263d57b29b82d@haskell.org> References: <045.52d150fd01a9dad256f263d57b29b82d@haskell.org> Message-ID: <060.040c09a7702143c04803d4739334ddce@haskell.org> #15830: Plugins Tests are Skipped -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | Resolution: | Keywords: plugins test Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: plugins01 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 Mon Oct 29 18:03:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 18:03:01 -0000 Subject: [GHC] #15831: DerivingVia allows bogus implicit quantification in `via` type Message-ID: <050.6e53147acb2c1b22346936cc921972a0@haskell.org> #15831: DerivingVia allows bogus implicit quantification in `via` type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: deriving | 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: -------------------------------------+------------------------------------- Consider the following code: {{{#!hs {-# LANGUAGE DerivingVia #-} {-# LANGUAGE PolyKinds #-} module Bug where import Data.Functor.Const (Const(..)) import GHC.Exts (Any) newtype Age = MkAge Int deriving Eq via Const Int Any }}} This fails to compile with a spectacularly unhelpful error message: {{{ $ /opt/ghc/8.6.1/bin/ghc -ddump-deriv Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) ==================== Derived instances ==================== Derived class instances: instance GHC.Classes.Eq Bug.Age where (GHC.Classes.==) = GHC.Prim.coerce @((Data.Functor.Const.Const GHC.Types.Int (GHC.Types.Any :: k_a24l) :: TYPE GHC.Types.LiftedRep) -> (Data.Functor.Const.Const GHC.Types.Int (GHC.Types.Any :: k_a24l) :: TYPE GHC.Types.LiftedRep) -> GHC.Types.Bool) @(Bug.Age -> Bug.Age -> GHC.Types.Bool) (GHC.Classes.==) :: Bug.Age -> Bug.Age -> GHC.Types.Bool (GHC.Classes./=) = GHC.Prim.coerce @((Data.Functor.Const.Const GHC.Types.Int (GHC.Types.Any :: k_a24l) :: TYPE GHC.Types.LiftedRep) -> (Data.Functor.Const.Const GHC.Types.Int (GHC.Types.Any :: k_a24l) :: TYPE GHC.Types.LiftedRep) -> GHC.Types.Bool) @(Bug.Age -> Bug.Age -> GHC.Types.Bool) (GHC.Classes./=) :: Bug.Age -> Bug.Age -> GHC.Types.Bool Derived type family instances: Bug.hs:9:12: error: The exact Name ‘k’ 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 | 9 | deriving Eq | ^^ Bug.hs:9:12: error: The exact Name ‘k’ 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 | 9 | deriving Eq | ^^ Bug.hs:9:12: error: The exact Name ‘k’ 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 | 9 | deriving Eq | ^^ Bug.hs:9:12: error: The exact Name ‘k’ 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 | 9 | deriving Eq | ^^ }}} There are two things that are strange here: * Notice that in the derived `Eq` instance, there are references to `(GHC.Types.Any :: k_a24l)`, where `k_a24l` is completely free! This should never happen, and is almost surely the cause of the resulting volley of errors. * It's quite odd that we didn't reject this `deriving` clause outright //before// generating the derived code. In fact, if we explicitly mention the kind `k`: {{{#!hs newtype Age = MkAge Int deriving Eq via Const Int (Any :: k) }}} //Then// it's rejected properly: {{{ $ /opt/ghc/8.6.1/bin/ghc Bug.hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:12: error: Type variable ‘k’ is bound in the ‘via’ type ‘Const Int (Any :: k)’ but is not mentioned in the derived class ‘Eq’, which is illegal | 9 | deriving Eq | ^^ }}} Something about implicit quantification must be sneaking by this validity check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 18:13:46 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 18:13:46 -0000 Subject: [GHC] #15831: DerivingVia allows bogus implicit quantification in `via` type In-Reply-To: <050.6e53147acb2c1b22346936cc921972a0@haskell.org> References: <050.6e53147acb2c1b22346936cc921972a0@haskell.org> Message-ID: <065.0dc8254a2378c334eec0329b71ee13e4@haskell.org> #15831: DerivingVia allows bogus implicit quantification in `via` type -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: deriving Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * milestone: => 8.8.1 Comment: I think I see what's going on here. The aforementioned validity check is currently implemented in the renamer (in [http://git.haskell.org/ghc.git/blob/331081b03f67c94b908136339aebf36d07d45c21:/compiler/rename/RnSource.hs#l1746 rnAndReportFloatingViaTvs]), but the renamer is completely oblivious to the existence of inferred kind variables (such as `k` in the original example). This leads me to believe that the renamer is the wrong place to put this check, and that it should really live in the typechecker, where we do know about the existence of `k`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 18:39:04 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 18:39:04 -0000 Subject: [GHC] #15768: Using oneshot kqueue() on macOS In-Reply-To: <052.23d28fc3421f1bb560c819068174239d@haskell.org> References: <052.23d28fc3421f1bb560c819068174239d@haskell.org> Message-ID: <067.a9b94a6f119fd395b95bd7de8ad4f7b7@haskell.org> #15768: Using oneshot kqueue() on macOS -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: (none) Type: bug | Status: patch Priority: highest | Milestone: 8.8.1 Component: Core Libraries | Version: 8.6.1 Resolution: | Keywords: KQueue, | oneshot, parallel build Operating System: MacOS X | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): Ah ok, I was wondering why we didn't see this on Linux but the papers says we weren't using it there. We used epoll. From the paper: "The registerFd func- tion takes the callback table lock, and then inserts (or modifies) an entry in the callback table and registers the event subscription us- ing the underlying OS event notification mechanism, for example epoll [8] on Linux, kqueue [7] on BSD variants, and poll on other OSes" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 18:47:37 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 18:47:37 -0000 Subject: [GHC] #15071: :set usage in ghci tests breaks platform independence of output In-Reply-To: <046.ca930388c371dd0f2b55a7ae0becdca1@haskell.org> References: <046.ca930388c371dd0f2b55a7ae0becdca1@haskell.org> Message-ID: <061.199511f20737b93822a484e0b50798ac@haskell.org> #15071: :set usage in ghci tests breaks platform independence of output -------------------------------------+------------------------------------- Reporter: bgamari | Owner: RolandSenn Type: bug | Status: closed Priority: high | Milestone: 8.8.1 Component: Test Suite | Version: 8.2.2 Resolution: fixed | Keywords: ci-breakage Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Windows: make | test TESTS="ghci057 T9293" Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5125 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 19:10:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 19:10:35 -0000 Subject: [GHC] #15815: problem with splicing type into constraint In-Reply-To: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> References: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> Message-ID: <059.6e7d716bd213048f47358f03dcf4e7f5@haskell.org> #15815: problem with splicing type into constraint -------------------------------------+------------------------------------- Reporter: int-e | Owner: RyanGlScott Type: bug | Status: patch Priority: highest | Milestone: 8.6.2 Component: Template Haskell | Version: 8.6.1 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): Phab:D5274 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b8a797ecc34a309bd78f5a290e3554642a3a478a/ghc" b8a797e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b8a797ecc34a309bd78f5a290e3554642a3a478a" Fix #15815 by parenthesizing the arguments to infix ~ An unfortunate consequence of commit b9483981d128f55d8dae3f434f49fa6b5b30c779 (`Remove HsEqTy and XEqTy`) is infix uses of `~` in TH quotes now desugar differently than before. In particular, we have that: ```haskell a ~ (Int -> Int) ``` Now desugars to: ```haskell HsOpTy a (~) (HsOpTy Int (->) Int) ``` Which GHC interprets as being: ```haskell a ~ Int -> Int ``` Or, equivalently: ```haskell (a ~ Int) -> Int ``` Which is different than what was intended! This is the cause of #15815. All of this has revealed that we likely need to renovate the way we desugar infix type operators to be more consistent with the treatment for infix expressions (see https://ghc.haskell.org/trac/ghc/ticket/15815#comment:5 for more on this.) Doing so would constitute a breaking change, however, so we will likely want to wait until another major GHC release to do this. In the meantime, this patch offers a non-invasive change to the way that infix uses of `~` are desugared. This makes the program in #15815 compile again by inserting extra `HsParTy`s around the arguments to `~` if they are lacking them. Test Plan: make test TEST=T15815 Reviewers: int-index, goldfire, bgamari Reviewed By: int-index Subscribers: int-e, rwbarton, carter GHC Trac Issues: #15815 Differential Revision: https://phabricator.haskell.org/D5274 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 19:12:54 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 19:12:54 -0000 Subject: [GHC] #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory In-Reply-To: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> References: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> Message-ID: <063.f9503db6e0681ad41cc52cd3a853b0b6@haskell.org> #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.6.2 Component: None | Version: Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"78fb31077e58d949ea644c9d51abe53de9a9d2cb/ghc" 78fb310/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="78fb31077e58d949ea644c9d51abe53de9a9d2cb" circleci: Build with in-tree GMP on Darwin Fixes #15404. (cherry picked from commit 578012be13eb1548050d51c0a23bd1a98423f03e) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 20:01:29 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 20:01:29 -0000 Subject: [GHC] #13408: Consider inferring a higher-rank kind for type synonyms In-Reply-To: <047.eeced9ac447a8f829efccd3a23d61888@haskell.org> References: <047.eeced9ac447a8f829efccd3a23d61888@haskell.org> Message-ID: <062.a0365c153a271dcdc25e59bf2ea4b761@haskell.org> #13408: Consider inferring a higher-rank kind for type synonyms -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): You got it. I do think a little twiddling in `kcTyClGroup` will get you what you want. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 20:08:58 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 20:08:58 -0000 Subject: [GHC] #15828: Type family equation foralls allow strange re-quantification of class-bound type variables In-Reply-To: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> References: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> Message-ID: <065.6dd7a63323cda33543993e26954fff93@haskell.org> #15828: Type family equation foralls allow strange re-quantification of class-bound type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Shamefully, the answer is not to pass the `mb_cls` to the call to `bindLHsTyVarBndrs` in `rnFamInstEqn` -- always pass `Nothing`. If an associated class is passed in, then `bindLHsTyVarBndrs` uses the in-scope class variables, which is not what's wanted here. Really, only `bindHsQTyVars` should pass a non-`Nothing` in this parameter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 20:13:01 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 20:13:01 -0000 Subject: [GHC] #15592: Type families without CUSKs cannot be given visible kind variable binders In-Reply-To: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> References: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> Message-ID: <065.f3d7c85a3f3a0ecb4aef50882182e5c7@haskell.org> #15592: Type families without CUSKs cannot be given visible kind variable binders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | TypeApplications, TypeFamilies, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14880 | Blocking: Related Tickets: #15591 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I thought I did add this, though perhaps to a T15991 test. I'm out of cycles now for a few days, but please add if you can't find it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 20:40:49 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 20:40:49 -0000 Subject: [GHC] #11719: Cannot use higher-rank kinds with type families In-Reply-To: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> References: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> Message-ID: <062.32b53263bfa700b44be50732fbc5761a@haskell.org> #11719: Cannot use higher-rank kinds with type families -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | dependent/should_compile/T11719 Blocked By: | Blocking: Related Tickets: #13913, #14268 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): comment:23 is a feature request. The use of a type variable in a type family equation -- even on the left-hand side -- is an occurrence, not a binding site. Type families aren't functions! So I think it's OK as is, myself. Someday, we'll just have type-level functions, and then all of this will be better. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 20:43:40 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 20:43:40 -0000 Subject: [GHC] #11719: Cannot use higher-rank kinds with type families In-Reply-To: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> References: <047.7d1567263c03c83c3feb5d4cd6d08b50@haskell.org> Message-ID: <062.cf30d90a74666b38cbf91dc44dfafa03@haskell.org> #11719: Cannot use higher-rank kinds with type families -------------------------------------+------------------------------------- Reporter: ocharles | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | dependent/should_compile/T11719 Blocked By: | Blocking: Related Tickets: #13913, #14268 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => closed * resolution: => fixed Comment: Alright, you've convinced me. In that case, let's close this ticket. (We can always open a new one in the event that we want to accept the program in comment:23). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 22:43:15 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 22:43:15 -0000 Subject: [GHC] #15827: Explicit foralls in type family equations are pretty-printed inconsistently (and strangely, at times) In-Reply-To: <050.3fc87a286139ce270bb50311698ddbd5@haskell.org> References: <050.3fc87a286139ce270bb50311698ddbd5@haskell.org> Message-ID: <065.cf08a2a3b38f73d996748935ca05dafd@haskell.org> #15827: Explicit foralls in type family equations are pretty-printed inconsistently (and strangely, at times) -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5282 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D5282 * milestone: => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 22:50:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 22:50:50 -0000 Subject: [GHC] #15815: problem with splicing type into constraint In-Reply-To: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> References: <044.97d50669b42166709d35ea9a7fe9519c@haskell.org> Message-ID: <059.67e1490c85e6de1a685a6952d386c198@haskell.org> #15815: problem with splicing type into constraint -------------------------------------+------------------------------------- Reporter: int-e | Owner: RyanGlScott Type: bug | Status: merge Priority: highest | Milestone: 8.6.2 Component: Template Haskell | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: th/T15815 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5274 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => th/T15815 * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 23:18:35 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 23:18:35 -0000 Subject: [GHC] #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory In-Reply-To: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> References: <048.91f0063a16a79288b7c518f96b6fa60f@haskell.org> Message-ID: <063.55d9b31e989af136950f0de1072866ed@haskell.org> #15404: ghc-8.6 uninstallable on macos due to hard coded libgmp directory -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: closed Priority: highest | Milestone: 8.6.2 Component: None | Version: Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Fixed with 78fb31077e58d949ea644c9d51abe53de9a9d2cb. Merged to `ghc-8.6` with 578012be13eb1548050d51c0a23bd1a98423f03e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 23:20:43 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 23:20:43 -0000 Subject: [GHC] #9476: Implement late lambda-lifting In-Reply-To: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> References: <046.35548079b7f5bfa7d29f786dd2f07078@haskell.org> Message-ID: <061.904426639c7352db9548370e4a95246c@haskell.org> #9476: Implement late lambda-lifting -------------------------------------+------------------------------------- Reporter: simonpj | Owner: sgraf Type: feature request | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: LateLamLift Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8763 #13286 | Differential Rev(s): Phab:D5224 Wiki Page: LateLamLift | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 23:26:50 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 23:26:50 -0000 Subject: [GHC] #13064: Incorrect redudant imports warning In-Reply-To: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> References: <045.fe3c1c6b618d0b4877de88fc27add363@haskell.org> Message-ID: <060.8a2b882727ae49d6a1ee81c5facd8805@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 ekmett): The CLC has a pretty clear consensus on making this happen. Let's do it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 23:45:45 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 23:45:45 -0000 Subject: [GHC] #9374: Investigate Static Argument Transformation In-Reply-To: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> References: <048.23fff567ef50b1dc01dc4be619333c72@haskell.org> Message-ID: <063.a0bede8e4efa6ff1b4e726c316be02a6@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: 14816 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Oct 29 23:58:33 2018 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Oct 2018 23:58:33 -0000 Subject: [GHC] #9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build In-Reply-To: <045.67b198827318e5a03441f1825701405b@haskell.org> References: <045.67b198827318e5a03441f1825701405b@haskell.org> Message-ID: <060.07a151c307dc1b47414315d18795254b@haskell.org> #9545: Evaluate Takano Akio's foldrW/buildW fusion framework as a possible replacement for foldr/build -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: (none) Type: task | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.9 Resolution: wontfix | Keywords: | StaticArgumentTransformation Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 01:42:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 01:42:47 -0000 Subject: [GHC] #14512: System-wide installed profile build cannot load libHSghc-prim.0.5.2.0.so In-Reply-To: <047.5a0900c5c72a8eef1106855d270e16d7@haskell.org> References: <047.5a0900c5c72a8eef1106855d270e16d7@haskell.org> Message-ID: <062.2f2f0ecae1fed26d5d52c3c2ef885f51@haskell.org> #14512: System-wide installed profile build cannot load libHSghc-prim.0.5.2.0.so -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.3 (make) | 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 _deepfire): I didn't go all the way to narrow down the reproduction, but here is another potential case for this: https://github.com/goldfirere/th- desugar/issues/96 To quote: {{{ [11 of 11] Compiling Language.Haskell.TH.Desugar.Lift ( Language/Haskell/TH/Desugar/Lift.hs, dist/build/Language/Haskell/TH/Desugar/Lift.p_o ) Preprocessing test suite 'spec' for th-desugar-1.8.. Building test suite 'spec' for th-desugar-1.8.. [1 of 4] Compiling Splices ( Test/Splices.hs, dist/build/spec /spec-tmp/Splices.o ) [2 of 4] Compiling DsDec ( Test/DsDec.hs, dist/build/spec/spec- tmp/DsDec.o ) : error: ghc: panic! (the 'impossible' happened) (GHC version 8.6.1 for x86_64-unknown-linux): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [3 of 4] Compiling Dec ( Test/Dec.hs, dist/build/spec/spec- tmp/Dec.o ) : error: : can't load .so/.DLL for: /run/user/1000/nix-build-th- desugar-1.8.drv-0/source/dist/build/libHSth-desugar-1.8 -KFOywxTzF8CA5cwAvr5NgA-ghc8.6.1.so (/run/user/1000/nix-build-th- desugar-1.8.drv-0/source/dist/build/libHSth-desugar-1.8 -KFOywxTzF8CA5cwAvr5NgA-ghc8.6.1.so: undefined symbol: thzmdesugarzm1zi8zmKFOywxTzzF8CA5cwAvr5NgA_LanguageziHaskellziTHziDesugarziAST_DAppPr_closure) builder for '/nix/store/yn634096vg0ih9mk35f2kx3hv80rx71v-th- desugar-1.8.drv' failed with exit code 1 error: build of '/nix/store/yn634096vg0ih9mk35f2kx3hv80rx71v-th- desugar-1.8.drv' failed [nix-shell:~/holotype]$ cat pkgs/def/github/th-desugar.rev 1d164b669079fe57181af95bbbe4749dbf08ab78 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 02:42:30 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 02:42:30 -0000 Subject: [GHC] #15828: Type family equation foralls allow strange re-quantification of class-bound type variables In-Reply-To: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> References: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> Message-ID: <065.cd3b0c72da0844a7560e8ecea3b6a086@haskell.org> #15828: Type family equation foralls allow strange re-quantification of class-bound type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5283 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mayac): * differential: => Phab:D5283 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 03:09:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 03:09:52 -0000 Subject: [GHC] #15828: Type family equation foralls allow strange re-quantification of class-bound type variables In-Reply-To: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> References: <050.dcf3e4d24d64ef4d232f34290f98b42e@haskell.org> Message-ID: <065.4104233d85a4019fff157792af075181@haskell.org> #15828: Type family equation foralls allow strange re-quantification of class-bound type variables -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5283 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mayac): @goldfire do you think it would be worth including in this fix a comment to the type signature of `bindLHsTyVarBndrs` mentioning that the `mb_cls` argument should usually be `Nothing`? For example: {{{ bindLHsTyVarBndrs :: HsDocContext -> Maybe SDoc -- Just d => check for unused tvs -- d is a phrase like "in the type ..." -> Maybe a -- Just _ => an associated type decl + -- (should be Nothing unless in bindHsQTyVars) -> [LHsTyVarBndr GhcPs] -- User-written tyvars -> ([LHsTyVarBndr GhcRn] -> RnM (b, FreeVars)) -> RnM (b, FreeVars) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 06:06:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 06:06:23 -0000 Subject: [GHC] #15832: returnIO/bindIO destroys runtime explicit stack information in some cases Message-ID: <048.4f171325e6580b41c039ea3becfab225@haskell.org> #15832: returnIO/bindIO destroys runtime explicit stack information in some cases -------------------------------------+------------------------------------- Reporter: infinity0 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Tested in GHC 8.2.2, 8.4.3 and 8.6.1: Test-good.hs {{{#!hs import GHC.Base data X = X Int deriving (Eq, Show) main :: IO () main = (returnIO undefined) `bindIO` (const (print $ X (error "XXX"))) }}} Test-bad.hs {{{#!hs import GHC.Base data X = X Int deriving (Eq, Show) main :: IO () main = (returnIO undefined) `bindIO` (\_ -> (print $ X (error "XXX"))) }}} build.sh {{{#!shell #!/bin/sh set -e p="${1:-stg}" for i in good bad; do rm -rf ghc*_* Test-$i Test-$i.dump-* Test-$i.hi Test-$i.o ghc "-ddump-$p" -dsuppress-module-prefixes -dsuppress-uniques \ -keep-tmp-files -dumpdir . -ddump-to-file \ -fno-cse -prof -fprof-auto -fprof-auto-calls -fprof-cafs \ -dinitial-unique=0 -dunique-increment=1 \ Test-$i.hs ./Test-$i +RTS -xc || true done colordiff -ruw Test-*.dump-"$p" | less -R }}} Running `sh build.sh` gives the following output: {{{ [1 of 1] Compiling Main ( Test-good.hs, Test-good.o ) Linking Test-good ... *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: Main.main, called from Main.main, called from Main.main, called from Main.main, called from Main.main, called from Main.CAF:main --> evaluated by: Main.main, called from Main.main, called from Main.main, called from Main.CAF:main --> evaluated by: Main.main, called from Main.main, called from Main.main Test-good: XXX CallStack (from HasCallStack): error, called at Test-good.hs:6:57 in main:Main CallStack (from -prof): Main.main (Test-good.hs:6:57-67) Main.main (Test-good.hs:6:54-68) Main.main (Test-good.hs:6:46-68) Main.main (Test-good.hs:6:39-69) Main.main (Test-good.hs:6:8-70) Main.CAF:main (Test-good.hs:6:1-4) [1 of 1] Compiling Main ( Test-bad.hs, Test-bad.o ) Linking Test-bad ... *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: Main.main, called from Main.main, called from Main.main, called from Main.main Test-bad: XXX CallStack (from HasCallStack): error, called at Test-bad.hs:6:57 in main:Main CallStack (from -prof): Main.main (Test-bad.hs:6:57-67) Main.main (Test-bad.hs:6:54-68) Main.main (Test-bad.hs:6:46-68) Main.main (Test-bad.hs:6:8-70) }}} As you can see, in Test-bad.hs all the entries below "evaluated by" are missing. I am not familiar with STG output, but running the script also shows you a diff of the STG dump. It seems innocent enough. Running `sh build.sh cmm` shows many more differences. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 06:10:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 06:10:02 -0000 Subject: [GHC] #15832: returnIO/bindIO destroys runtime explicit stack information in some cases In-Reply-To: <048.4f171325e6580b41c039ea3becfab225@haskell.org> References: <048.4f171325e6580b41c039ea3becfab225@haskell.org> Message-ID: <063.f884094c67a3a00644dd256e10bfd6e5@haskell.org> #15832: returnIO/bindIO destroys runtime explicit stack information in some cases -------------------------------------+------------------------------------- Reporter: infinity0 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by infinity0): Some more examples: Good: {{{#!hs data X = X Int deriving (Eq, Show) main :: IO () main = do return undefined print $ X (error "XXX") }}} Bad: {{{#!hs data X = X Int deriving (Eq, Show) main :: IO () main = do _ <- return undefined print $ X (error "XXX") }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 06:17:53 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 06:17:53 -0000 Subject: [GHC] #15832: returnIO/bindIO destroys runtime explicit stack information in some cases In-Reply-To: <048.4f171325e6580b41c039ea3becfab225@haskell.org> References: <048.4f171325e6580b41c039ea3becfab225@haskell.org> Message-ID: <063.9a6e14f74007b4f93780f58671bc623a@haskell.org> #15832: returnIO/bindIO destroys runtime explicit stack information in some cases -------------------------------------+------------------------------------- Reporter: infinity0 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by infinity0): I forgot to add, adding `-O2` to `build.sh` makes the bad behaviours go away in these specific reduced cases. However it does not help in a larger "real world" case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 10:20:29 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 10:20:29 -0000 Subject: [GHC] #15833: Typed template haskell quote fails to typecheck when spliced due to an ambiguous type variable Message-ID: <049.9c2fa9e6abd9dac498eb7d8403e15a78@haskell.org> #15833: Typed template haskell quote fails to typecheck when spliced due to an ambiguous type variable -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It should be the case that a code value constructed using typed template haskell should never fail to type check when spliced. Running `ghc Test.hs` with the following two modules produces an error about an ambiguous type variable. https://gist.github.com/5890c14dda73da738d2041c7f677b786 {{{ {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -Wall #-} module Compiler where import Language.Haskell.TH data Operator = Scan | Join Operator Operator deriving Show queryJoin :: Operator queryJoin = Join Scan Scan type QTExp a = Q (TExp a) fix :: (a -> a) -> a fix f = let x = f x in x while :: Monoid m => QTExp (IO m -> IO m) -> QTExp (IO m) while b = [|| fix (\r -> whenM True ($$b r)) ||] whenM :: Monoid m => Bool -> m -> m whenM b act = if b then act else mempty execOp :: Monoid m => Operator -> QTExp (IO m) -> QTExp (IO m) execOp op yld = case op of Scan -> while [|| \r -> ($$(yld) >> r)||] Join left right -> execOp left (execOp right yld) runQuery :: QTExp (IO ()) runQuery = execOp (Join Scan Scan) ([|| return () ||]) }}} {{{ {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Test where import qualified Compiler as C main :: IO () main = do $$(C.runQuery) }}} {{{ Test.hs:9:6: error: • Ambiguous type variable ‘a0’ arising from a use of ‘C.whenM’ prevents the constraint ‘(Monoid a0)’ from being solved. Relevant bindings include r_a5GX :: IO a0 (bound at Test.hs:9:6) Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instances exist: instance Monoid a => Monoid (IO a) -- Defined in ‘GHC.Base’ instance Monoid Ordering -- Defined in ‘GHC.Base’ instance Semigroup a => Monoid (Maybe a) -- Defined in ‘GHC.Base’ ...plus 7 others (use -fprint-potential-instances to see them all) • In the expression: (C.whenM True) ((\ r_a5GY -> ((return ()) >> r_a5GY)) r_a5GX) In the first argument of ‘C.fix’, namely ‘(\ r_a5GX -> (C.whenM True) ((\ r_a5GY -> ((return ()) >> r_a5GY)) r_a5GX))’ In the first argument of ‘(>>)’, namely ‘(C.fix (\ r_a5GX -> (C.whenM True) ((\ r_a5GY -> ((return ()) >> r_a5GY)) r_a5GX)))’ | 9 | $$(C.runQuery) | }}} The generated code {{{ Test.hs:9:6-15: Splicing expression C.runQuery ======> C.fix (\ r_a5GV -> (C.whenM True) ((\ r_a5GW -> ((C.fix (\ r_a5GX -> (C.whenM True) ((\ r_a5GY -> ((return GHC.Tuple.()) >> r_a5GY)) r_a5GX))) >> r_a5GW)) r_a5GV)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 10:35:03 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 10:35:03 -0000 Subject: [GHC] #15834: genSym is not thread safe with respect to setNumCapabilities Message-ID: <051.bde0eea937a5b36058462e4d3b9ef835@haskell.org> #15834: genSym is not thread safe with respect to setNumCapabilities ----------------------------------------+--------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- In a large proprietary application using the GHC API, we observe really weird errors (e.g. overlapping instances for {{{Eq Foo}}} and {{{Eq Bar}}}, where {{{Foo}}} and {{{Bar}}} are completely unrelated, and come from different modules). The pattern we follow is: * Running with the threaded RTS, 1 initial thread * Create a new unique supply with {{{mkSplitUniqSupply}}} and put it in an {{{MVar}}}. * Repeating many times: * Set the thread count higher (e.g. 8) using {{{setNumCapabilities}}} * On many threads in parallel: * Obtain a new unique supply on the original with {{{splitUniqSupply}}}, protected by the {{{MVar}}}, and update the other one in the {{{MVar}}} * Use that unique supply to interact with the GHC API * Set the thread count back to 1 Our observations of the errors are best explained by the unique names not being nearly as unique as they might be expected to be. Reading the code for {{{genSym}}}: {{{#!c if (n_capabilities == 1) { GenSymCounter = (GenSymCounter + GenSymInc) & UNIQUE_MASK; checkUniqueRange(GenSymCounter); return GenSymCounter; } else { HsInt n = atomic_inc((StgWord *)&GenSymCounter, GenSymInc) & UNIQUE_MASK; checkUniqueRange(n); return n; } }}} It only does an {{{atomic_inc}}} if {{{n_capabilities == 1}}}, but it doesn't read {{{n_capabilities}}} atomically, so is it suffering a race? The solution was to set the thread count initially, before any interactions with the GHC API, which seems to solve the problem. Alas, we don't have a reproducible test case, and in fact were unable to reproduce it anywhere but our Linux CI, and even then non-deterministically. The problem does not currently impact us (the workaround is robust), but it seemed worth sharing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 10:35:13 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 10:35:13 -0000 Subject: [GHC] #15834: genSym is not thread safe with respect to setNumCapabilities In-Reply-To: <051.bde0eea937a5b36058462e4d3b9ef835@haskell.org> References: <051.bde0eea937a5b36058462e4d3b9ef835@haskell.org> Message-ID: <066.a3b349677abac1f362f5be074892eaf2@haskell.org> #15834: genSym is not thread safe with respect to setNumCapabilities ---------------------------------+---------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | 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 NeilMitchell): * cc: ndmitchell@… (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 11:18:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 11:18:56 -0000 Subject: [GHC] #15833: Typed template haskell quote fails to typecheck when spliced due to an ambiguous type variable In-Reply-To: <049.9c2fa9e6abd9dac498eb7d8403e15a78@haskell.org> References: <049.9c2fa9e6abd9dac498eb7d8403e15a78@haskell.org> Message-ID: <064.169fcb7d3840335a87d89c7d8257a52e@haskell.org> #15833: Typed template haskell quote fails to typecheck when spliced due to an ambiguous type variable -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): If I inline both recursive calls to `execOp` then the code in `Compiler` fails to typecheck. {{{ 26 execOp :: Monoid m => Operator -> QTExp (IO m) -> QTExp (IO m) 27 execOp op yld = 28 case op of 29 Scan -> 30 while [|| \r -> ($$(yld) >> r)||] 31 Join left right -> 32 while [|| \r -> $$(while [|| \r -> ($$(yld) >> r) ||]) >> r ||] }}} {{{ Compiler.hs:32:26: error: • Could not deduce (Monoid a0) arising from a use of ‘while’ from the context: Monoid m bound by the type signature for: execOp :: forall m. Monoid m => Operator -> QTExp (IO m) -> QTExp (IO m) at Compiler.hs:26:1-62 The type variable ‘a0’ is ambiguous These potential instances exist: instance Monoid a => Monoid (IO a) -- Defined in ‘GHC.Base’ instance Monoid Ordering -- Defined in ‘GHC.Base’ instance Semigroup a => Monoid (Maybe a) -- Defined in ‘GHC.Base’ ...plus 7 others (use -fprint-potential-instances to see them all) • In the expression: while [|| \ r -> ($$(yld) >> r) ||] In the Template Haskell splice $$(while [|| \ r -> ($$(yld) >> r) ||]) In the first argument of ‘(>>)’, namely ‘$$(while [|| \ r -> ($$(yld) >> r) ||])’ | 32 | while [|| \r -> $$(while [|| \r -> ($$(yld) >> r) ||]) >> r ||] | }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 11:29:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 11:29:33 -0000 Subject: [GHC] #15835: Internal error when splicing value constructed using typed template haskell Message-ID: <049.9e9d696239ebb85d54fd0730367bda33@haskell.org> #15835: Internal error when splicing value constructed using typed template haskell -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Related to #15833 Compiling Test.hs leads to an internal compiler error. https://gist.github.com/f04a613bb5e20c241c5b91c2f38b8f06 {{{ {-# LANGUAGE TemplateHaskell #-} {-# OPTIONS_GHC -ddump-splices #-} module Test where import qualified Compiler as C main :: IO () main = do $$(C.runQuery) }}} {{{ {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# OPTIONS_GHC -Wall #-} module Compiler where import Language.Haskell.TH type QTExp a = Q (TExp a) fix :: (a -> a) -> a fix f = let x = f x in x while :: forall m . Monoid m => QTExp (IO m -> IO m) -> QTExp (IO m) while b = [|| fix (\r -> whenM @(IO m) ($$b r)) ||] whenM :: Monoid m => m -> m whenM _ = mempty execOp :: forall m . Monoid m => QTExp (IO m) execOp = while [|| \r -> $$(while @m [|| id ||]) >> r ||] runQuery :: QTExp (IO ()) runQuery = execOp }}} Leads to the following internal errors even though `Compiler` type checked. {{{ Prelude> :r [1 of 2] Compiling Compiler ( Compiler.hs, interpreted ) [2 of 2] Compiling Test ( Test.hs, interpreted ) Test.hs:9:6-15: Splicing expression C.runQuery ======> C.fix (\ r_a7K7 -> (C.whenM @(IO m_a7Gp)) ((\ r_a7K8 -> ((C.fix (\ r_a7K9 -> (C.whenM @(IO m_a7Gp)) (id r_a7K9))) >> r_a7K8)) r_a7K7)) Test.hs:9:6: error: • The exact Name ‘m’ 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 result of the splice: $C.runQuery To see what the splice expanded to, use -ddump-splices In the Template Haskell splice $$(C.runQuery) In a stmt of a 'do' block: $$(C.runQuery) | 9 | $$(C.runQuery) | ^^^^^^^^^^ Test.hs:9:6: error: • The exact Name ‘m’ 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 result of the splice: $C.runQuery To see what the splice expanded to, use -ddump-splices In the Template Haskell splice $$(C.runQuery) In a stmt of a 'do' block: $$(C.runQuery) | 9 | $$(C.runQuery) | ^^^^^^^^^^ Test.hs:9:6: error: • GHC internal error: ‘m’ is not in scope during type checking, but it passed the renamer tcl_env of environment: [a7K7 :-> Identifier[r_a7K7::a0, NotLetBound], r5Fg :-> Identifier[main::IO (), TopLevelLet [] True]] • In the first argument of ‘IO’, namely ‘m’ In the type ‘(IO m)’ In the expression: (C.whenM @(IO m)) ((\ r_a7K8 -> ((C.fix (\ r_a7K9 -> (C.whenM @(IO m)) (id r_a7K9))) >> r_a7K8)) r_a7K7) | 9 | $$(C.runQuery) | }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 11:30:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 11:30:52 -0000 Subject: [GHC] #15835: Internal error when splicing value constructed using typed template haskell In-Reply-To: <049.9e9d696239ebb85d54fd0730367bda33@haskell.org> References: <049.9e9d696239ebb85d54fd0730367bda33@haskell.org> Message-ID: <064.713f529884950f9e69373f1573936833@haskell.org> #15835: Internal error when splicing value constructed using typed template haskell -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): To be clear, the error is induced by adding the type application in `while`. Removing that leads to #15833 {{{ whenM @(IO m) ($$b r)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 11:33:39 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 11:33:39 -0000 Subject: [GHC] #15833: Typed template haskell quote fails to typecheck when spliced due to an ambiguous type variable In-Reply-To: <049.9c2fa9e6abd9dac498eb7d8403e15a78@haskell.org> References: <049.9c2fa9e6abd9dac498eb7d8403e15a78@haskell.org> Message-ID: <064.5947fd604d462c34a70381550d661dc2@haskell.org> #15833: Typed template haskell quote fails to typecheck when spliced due to an ambiguous type variable -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Here is a minimised version which still exhibits the same failure. {{{ {-# LANGUAGE TemplateHaskell #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeApplications #-} {-# OPTIONS_GHC -Wall #-} module Compiler where import Language.Haskell.TH type QTExp a = Q (TExp a) fix :: (a -> a) -> a fix f = let x = f x in x while :: Monoid m => QTExp (IO m -> IO m) -> QTExp (IO m) while b = [|| fix (\r -> whenM ($$b r)) ||] whenM :: Monoid m => a -> m whenM _ = mempty execOp :: forall m . Monoid m => QTExp (IO m) execOp = while [|| \r -> $$(while @m [|| id ||]) >> r ||] runQuery :: QTExp (IO ()) runQuery = execOp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 11:36:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 11:36:26 -0000 Subject: [GHC] #15437: Internal error when applying a scoped type variable inside a typed expression quotation In-Reply-To: <047.2c380fe49bc2106873d739da05bad0b7@haskell.org> References: <047.2c380fe49bc2106873d739da05bad0b7@haskell.org> Message-ID: <062.7e7e77324dcfc42eb3326a6c3727d217@haskell.org> #15437: Internal error when applying a scoped type variable inside a typed expression quotation -------------------------------------+------------------------------------- Reporter: dminuoso | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #13587, #15835 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * related: #13587 => #13587, #15835 Comment: Also #15835 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 12:05:56 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 12:05:56 -0000 Subject: [GHC] #15826: Allow registering (Source)Plugins through the GHC API In-Reply-To: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> References: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> Message-ID: <061.9949f90fc3a61c9f16fe6bf1f5a3cbd2@haskell.org> #15826: Allow registering (Source)Plugins through the GHC API -------------------------------------+------------------------------------- Reporter: DanielG | Owner: DanielG Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D5278 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): The reason for the existence of the `ModIface` is for recompilation checking. How do you imagine recompilation checking working for functions added using the API? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 12:27:47 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 12:27:47 -0000 Subject: [GHC] #15826: Allow registering (Source)Plugins through the GHC API In-Reply-To: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> References: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> Message-ID: <061.653e6692b8d8c45f93de25e2604d5da4@haskell.org> #15826: Allow registering (Source)Plugins through the GHC API -------------------------------------+------------------------------------- Reporter: DanielG | Owner: DanielG Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D5278 Wiki Page: | -------------------------------------+------------------------------------- Comment (by DanielG): I guess "plugin" is the wrong term here, so that might be causing some confusion. The whole point of this endeavor is to be able to use plugins already compiled into the programm calling the GHC API, without loading anything dynamically, so recompilation checking simply isn't needed here. The idea is that since GHC now has plugin support lots of people will build interresintg plugins and I'd like to be able to use these in tooling projects without mucking about with having to `cabal install` them at runtime. So instead I figure since plugins are just regular packages/modules why not just link against them at build time? If I just wanted to just load some (dynamically) loaded plugins through the GHC API you are right, what I'm doing wouldn't make much sense. That just not the use-case though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 13:05:25 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 13:05:25 -0000 Subject: [GHC] #15611: scope errors lie about what modules are imported In-Reply-To: <044.35c05a6ccad9dc15d82e16ecd787e95b@haskell.org> References: <044.35c05a6ccad9dc15d82e16ecd787e95b@haskell.org> Message-ID: <059.e87690a382b2cf78c52d066302623807@haskell.org> #15611: scope errors lie about what modules are imported -------------------------------------+------------------------------------- Reporter: dmwit | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST="T15611a T15611b" Blocked By: | Blocking: Related Tickets: #14225 | Differential Rev(s): Phab:D5284 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * status: new => patch * testcase: => make test TEST="T15611a T15611b" * differential: => Phab:D5284 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 13:15:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 13:15:12 -0000 Subject: [GHC] #15611: scope errors lie about what modules are imported In-Reply-To: <044.35c05a6ccad9dc15d82e16ecd787e95b@haskell.org> References: <044.35c05a6ccad9dc15d82e16ecd787e95b@haskell.org> Message-ID: <059.c919f1856f98590252fd0b4b3953859e@haskell.org> #15611: scope errors lie about what modules are imported -------------------------------------+------------------------------------- Reporter: dmwit | Owner: RolandSenn Type: bug | Status: patch Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: make test | TEST="T15611a T15611b" Blocked By: | Blocking: Related Tickets: #14225 | Differential Rev(s): Phab:D5284 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RolandSenn): * milestone: 8.6.1 => 8.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 14:03:59 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 14:03:59 -0000 Subject: [GHC] #15836: ghc-in-ghci script fails when there is a Main.hs in the top-level directory Message-ID: <049.6d22df5e6bd2414b533bdbc96e762abd@haskell.org> #15836: ghc-in-ghci script fails when there is a Main.hs in the top-level directory -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I had a file called `Main.hs` in my top-level GHC folder. When running `./utils/ghc-in-ghci/run.sh`, the script tried to load this random file. I'm not sure which `Main` it is trying to load but it was not the right one! Workaround: Don't have a file called `Main.hs` in the top-level directory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 14:06:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 14:06:35 -0000 Subject: [GHC] #15837: Hadrian should build dynamically linked ghc binary Message-ID: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> #15837: Hadrian should build dynamically linked ghc binary -------------------------------------+------------------------------------- Reporter: davide | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The ghc binary is dynamically linked via make in various flavors (e.g. quick). Hadrian builds a static linked binary in these cases (this is a bug). Various change are needed to fix this: 1. Add new .cabal file field extra-dynamic-library-flavours (see [https://github.com/haskell/cabal/pull/5606 this PR]). 2. Use .cabal extra-dynamic-library-flavours for the RTS (see [https://github.com/snowleopard/hadrian/issues/695#issue-367436377 this comment], depends on 1.) 3. Hadrian: fix management of nontrivial dynamic flavours of libHSrts (see [https://github.com/snowleopard/hadrian/pull/698 this PR]). 4. Hadrian should build ghc with the `-fPIC -dynamic` options (see [https://github.com/DavidEichmann/ghc/commit/752021f69f577b678630302b567fd712c565624b #diff-408bbe46d4afae11991cbadb2c531b78 this comment], depends on 3.). 5. Use the correct relative path to the dynamically linked libraries (see [https://phabricator.haskell.org/D5281 this change], depends on 3. and 4.). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 14:07:12 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 14:07:12 -0000 Subject: [GHC] #15837: Hadrian should build dynamically linked ghc binary In-Reply-To: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> References: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> Message-ID: <060.3729887454f433a6d658eb78cf52bb67@haskell.org> #15837: Hadrian should build dynamically linked ghc binary -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by davide): * owner: (none) => davide -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 14:12:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 14:12:09 -0000 Subject: [GHC] #15837: Hadrian should build dynamically linked ghc binary In-Reply-To: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> References: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> Message-ID: <060.c1c315fc6a86fb316e4fc5eff51b4b88@haskell.org> #15837: Hadrian should build dynamically linked ghc binary -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by davide): * cc: alpmestan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 14:31:52 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 14:31:52 -0000 Subject: [GHC] #13408: Consider inferring a higher-rank kind for type synonyms In-Reply-To: <047.eeced9ac447a8f829efccd3a23d61888@haskell.org> References: <047.eeced9ac447a8f829efccd3a23d61888@haskell.org> Message-ID: <062.5c332405a22304571402c785b910904b@haskell.org> #13408: Consider inferring a higher-rank kind for type synonyms -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): To be clear, I have no idea what "a little twiddling" constitutes in the slightest. The only clues I have are: * The [http://git.haskell.org/ghc.git/blob/0bdbbd4a637b169aa7043e0d9898ad1ecd5d14ef:/compiler/typecheck/TcBinds.hs#l1253 code] around `Note [Single function non-recursive binding special-case]` looks relevant: {{{#!hs -- Single function binding, | NonRecursive <- is_rec -- ...binder isn't mentioned in RHS , Nothing <- sig_fn name -- ...with no type signature = -- Note [Single function non-recursive binding special-case] -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- In this very special case we infer the type of the -- right hand side first (it may have a higher-rank type) -- and *then* make the monomorphic Id for the LHS -- e.g. f = \(x::forall a. a->a) -> -- We want to infer a higher-rank type for f setSrcSpan b_loc $ do { ((co_fn, matches'), rhs_ty) <- tcInferInst $ \ exp_ty -> -- tcInferInst: see TcUnify, -- Note [Deep instantiation of InferResult] tcExtendBinderStack [TcIdBndr_ExpType name exp_ty NotTopLevel] $ -- We extend the error context even for a non-recursive -- function so that in type error messages we show the -- type of the thing whose rhs we are type checking tcMatchesFun (L nm_loc name) matches exp_ty ; ... } }}} I'm guessing that the type that you get from `tcInferInst` is important here. * [http://git.haskell.org/ghc.git/blob/849d3848f6a43c36eb0fffe45894be947ad66bfc:/compiler/typecheck/TcTyClsDecls.hs#l826 This] appears to be the relevant code for kind-checking type synonyms: {{{#!hs getInitialKind decl@(SynDecl { tcdLName = L _ name , tcdTyVars = ktvs , tcdRhs = rhs }) = do { tycon <- kcLHsQTyVars name TypeSynonymFlavour (hsDeclHasCusk decl) ktvs $ case kind_annotation rhs of Nothing -> newMetaKindVar Just ksig -> tcLHsKindSig (TySynKindCtxt name) ksig ; return [tycon] } where -- Keep this synchronized with 'hsDeclHasCusk'. kind_annotation (L _ ty) = case ty of HsParTy _ lty -> kind_annotation lty HsKindSig _ _ k -> Just k _ -> Nothing }}} If I pass in the `[LTyClDecl GhcRn]` argument from `kcTyClGroup`, I can figure out if that type synonym is part of a recursive group or not. Similarly, if `kind_annotation rhs` returns `Nothing`, then I know that we don't have a CUSK. If those two things simultaneously hold true, then I'm in a situation where we should infer the overall kind. ...except that I'm not sure at all how to go about doing so. Several mysteries have presented itself: * Where exactly should `tcInferInst` go into this? Does the type that it give you in its callback refer to the overall kind of the type synonym? Just the return kind? Something else? * Once I have access to the type in `tcInferInst`, what do I even do with it? Do I pass it to `tcLHsKindSig`? Is there another function that's better suited to this situation? * `tcInferInst` also //returns// a type. What should I do with that? * Is the `tcExtendBinderStack` stuff from the term-level code relevant to this situation? Without some kind of direction, I'm very under-qualified to fix this, I'm afraid. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 14:51:33 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 14:51:33 -0000 Subject: [GHC] #15592: Type families without CUSKs cannot be given visible kind variable binders In-Reply-To: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> References: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> Message-ID: <065.1cbf5f6ad15d369867568eaf2a3f1c03@haskell.org> #15592: Type families without CUSKs cannot be given visible kind variable binders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: | TypeApplications, TypeFamilies, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 14880 | Blocking: Related Tickets: #15591 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ryan Scott ): In [changeset:"42faeb3bf0a167ec4d449f27d8ca37501d96d24d/ghc" 42faeb3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="42faeb3bf0a167ec4d449f27d8ca37501d96d24d" Add second test case for #15592 This adds a program from https://ghc.haskell.org/trac/ghc/ticket/15592#comment:9 (which briefly refused to typecheck on GHC HEAD) as a test case. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 14:53:05 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 14:53:05 -0000 Subject: [GHC] #15592: Type families without CUSKs cannot be given visible kind variable binders In-Reply-To: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> References: <050.651e6db8a709f8d5b684cf90e6873390@haskell.org> Message-ID: <065.83da874c9f3282411d39d9fba21ef396@haskell.org> #15592: Type families without CUSKs cannot be given visible kind variable binders -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: fixed | Keywords: | TypeApplications, TypeFamilies, | CUSKs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T15592{,b} Blocked By: 14880 | Blocking: Related Tickets: #15591 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * testcase: => polykinds/T15592{,b} * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 15:04:57 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 15:04:57 -0000 Subject: [GHC] #15838: Warn about unused dependencies Message-ID: <044.e25aa689381c4444292ccbb12f8d006d@haskell.org> #15838: Warn about unused dependencies -------------------------------------+------------------------------------- Reporter: Yuras | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC loads packages lazily, so at the end of compilation (at least in `--make` mode) it knows all the dependencies, required to compile the code. See `eps_PIT` in `ExternalPackageState`. If we compare this list with the list of packages, passed on command like via `--package-id`, then we'll get a list of unused dependencies. I propose to add a flag `-Wunused-packages`, off by default, which will report the unused packages if any. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 15:05:31 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 15:05:31 -0000 Subject: [GHC] #15838: Warn about unused dependencies In-Reply-To: <044.e25aa689381c4444292ccbb12f8d006d@haskell.org> References: <044.e25aa689381c4444292ccbb12f8d006d@haskell.org> Message-ID: <059.faafd3f9b6222a30262c4680d8ce5a6c@haskell.org> #15838: Warn about unused dependencies -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Yuras Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Yuras): * owner: (none) => Yuras -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 15:31:26 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 15:31:26 -0000 Subject: [GHC] #15832: returnIO/bindIO destroys runtime explicit stack information in some cases In-Reply-To: <048.4f171325e6580b41c039ea3becfab225@haskell.org> References: <048.4f171325e6580b41c039ea3becfab225@haskell.org> Message-ID: <063.83c80b217003b1b982d09ec06abcdc3c@haskell.org> #15832: returnIO/bindIO destroys runtime explicit stack information in some cases -------------------------------------+------------------------------------- Reporter: infinity0 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by infinity0): Adding `-debug` and `-Dp` reveals that something is preventing the relevant cost-centre from being added to the relevant CAF cost-centre- stacks. But this is necessary in order for the logic in fprintCCS_stderr to find the subsequent stacks, to print the "evaluated by" stuff. {{{ $ sh build.sh [1 of 1] Compiling Main ( Test-good.hs, Test-good.o ) Linking Test-good ... 7facde5a7740: pushing main on Appending <> to 7facde5a7740: pushing main on Appending to 7facde5a7740: pushing main on Appending to 7facde5a7740: pushing main on Appending to 7facde5a7740: pushing main on 7facde5a7740: pushing main on 7facde5a7740: pushing main on 7facde5a7740: pushing main on *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: [.. complete stack trace ..] [1 of 1] Compiling Main ( Test-bad.hs, Test-bad.o ) Linking Test-bad ... 7febf2b72740: pushing main on Appending <> to 7febf2b72740: pushing main on Appending to Appending to 7febf2b72740: pushing main on 7febf2b72740: pushing main on 7febf2b72740: pushing main on 7febf2b72740: pushing main on *** Exception (reporting due to +RTS -xc): (THUNK_2_0), stack trace: [.. incomplete stack trace ..] }}} (On Debian I also have to add `-threaded -rtsopts` because we have a `libHSrts_thr_debug_p.a` but not a plain `libHSrts_debug_p.a` for some reason.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 15:51:09 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 15:51:09 -0000 Subject: [GHC] #15808: Master sefaults on windows during aeson build when stage2 libs have dwarf enabled. In-Reply-To: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> References: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> Message-ID: <062.69a695c8b61a0bf395559e0da2b9c0ee@haskell.org> #15808: Master sefaults on windows during aeson build when stage2 libs have dwarf enabled. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): I've spent some quality time with gdb the last few days and documenting progress here: * aeson uses TH which via the GHCi machinery links in base (among other things). * During linking of base we find initialization code in base originating from foreign exports * The initialization code contains relocations. * In particular we want to jump to `foreignExportStablePtr` at the end of this function. * But something during relocation goes wrong and we jump to a wrong address. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 15:54:35 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 15:54:35 -0000 Subject: [GHC] #15838: Warn about unused dependencies In-Reply-To: <044.e25aa689381c4444292ccbb12f8d006d@haskell.org> References: <044.e25aa689381c4444292ccbb12f8d006d@haskell.org> Message-ID: <059.88a6b476e57f7be63cc619f8b317dea4@haskell.org> #15838: Warn about unused dependencies -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Yuras Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5285 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Yuras): * differential: => Phab:D5285 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 16:30:23 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 16:30:23 -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.55eec0284b8d442d8b5aa8b67e23463f@haskell.org> #15471: Polymorphism, typed splices and type inference don't mix -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Template Haskell | Version: 8.4.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5286 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * differential: => Phab:D5286 Comment: I attempted a patch: https://phabricator.haskell.org/D5286 I will add a note once it's confirmed that this is the right approach but it correctly deals with the examples in the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 17:12:02 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 17:12:02 -0000 Subject: [GHC] #15779: Follow-ups to D5169 In-Reply-To: <046.2d2f72ea3821ecb52abedacaf1c0155d@haskell.org> References: <046.2d2f72ea3821ecb52abedacaf1c0155d@haskell.org> Message-ID: <061.d0a6d49cadb625873eb0cc18a9e596fa@haskell.org> #15779: Follow-ups to D5169 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: (none) Type: task | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D5270 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): For (1), these would be used by `ghc -fextenral-interpreter -prof`, and also any statically-linked binary that uses the GHC API. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 18:57:01 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 18:57:01 -0000 Subject: [GHC] #15767: "StgCmmEnv: variable not found" with FunctionalDependencies and FlexibleContexts In-Reply-To: <045.2239633dfbb009c41762262dc87d11d7@haskell.org> References: <045.2239633dfbb009c41762262dc87d11d7@haskell.org> Message-ID: <060.f5ea05fae904bf2c58e147e8c9d9a7a6@haskell.org> #15767: "StgCmmEnv: variable not found" with FunctionalDependencies and FlexibleContexts -------------------------------------+------------------------------------- Reporter: roland | Owner: (none) Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_fail/T15767 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I'm afraid I'm seeing some spurious test output changes when cherry- picking this to `ghc-8.6`. For instance, {{{#!patch diff -uw "./rename/should_fail/mc13.run/mc13.stderr.normalised" "./rename/should_fail/mc13.run/mc13.comp.stderr.normalised" --- ./rename/should_fail/mc13.run/mc13.stderr.normalised 2018-10-30 14:54:22.690690790 -0400 +++ ./rename/should_fail/mc13.run/mc13.comp.stderr.normalised 2018-10-30 14:54:22.690690790 -0400 @@ -1,2 +1,18 @@ -mc13.hs:12:37: Variable not in scope: f :: [a] -> m a +mc13.hs:12:16: + Ambiguous type variable ‘m0’ arising from a statement in a monad comprehension + prevents the constraint ‘(Monad m0)’ from being solved. + Relevant bindings include output :: m0 () (bound at mc13.hs:12:1) + Probable fix: use a type annotation to specify what ‘m0’ should be. + These potential instances exist: + instance Monad IO -- Defined in ‘GHC.Base’ + instance Monad Maybe -- Defined in ‘GHC.Base’ + instance Monoid a => Monad ((,) a) -- Defined in ‘GHC.Base’ + ...plus one other + ...plus two instances involving out-of-scope types + (use -fprint-potential-instances to see them all) + In a stmt of a monad comprehension: then f + In the expression: [() | f <- functions, then f] + In an equation for ‘output’: output = [() | f <- functions, then f] + +mc13.hs:12:37: Variable not in scope: f :: [a] -> m0 a }}} and similar new errors in `TEST="T12529 T12921 mc13 mc14"`. Given that these are just error message regressions I'm going to go ahead and accept them (and perhaps we can fix them later if anyone knows the cause off- hand). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 19:08:27 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 19:08:27 -0000 Subject: [GHC] #15808: Loading libraries with FFI exports may cause segfaults in the compiler if they are loaded far from the rts in memory. (was: Master sefaults on windows during aeson build when stage2 libs have dwarf enabled.) In-Reply-To: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> References: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> Message-ID: <062.45049c8f941ffd47b03cf8c355b1f77d@haskell.org> #15808: Loading libraries with FFI exports may cause segfaults in the compiler if they are loaded far from the rts in memory. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.7 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by AndreasK): * component: Compiler => Compiler (Linking) * priority: normal => high * failure: None/Unknown => Compile-time crash or panic * architecture: Unknown/Multiple => x86_64 (amd64) * os: Unknown/Multiple => Windows Old description: > I haven't had any luck with reproducing it outside of building the aeson > package with cabal yet. So for now just documenting the fact. > > build.mk used > {{{ > GhcLibHcOpts += -g3 > GhcRtsHcOpts += -g3 > > STRIP_CMD = : > > BUILD_PROF_LIBS = NO > SplitObjs = NO > SplitSections = NO > HADDOCK_DOCS = NO > BUILD_SPHINX_HTML = NO > BUILD_SPHINX_PDF = NO > BUILD_MAN = NO > > }}} > > Error log: > {{{ > "E:/ghc_dwarf/inplace/bin/ghc-stage2.exe" "--make" "-fbuilding-cabal- > package" "-O" "-outputdir" "C:\ghc\msys64\home\Andi\aeson_repro\dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build" > "-odir" "C:\ghc\msys64\home\Andi\aeson_repro\dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build" > "-hidir" "C:\ghc\msys64\home\Andi\aeson_repro\dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build" > "-stubdir" "C:\ghc\msys64\home\Andi\aeson_repro\dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build""-i" > "-iC:\ghc\msys64\home\Andi\aeson_repro\dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build" "-i." > "-iattoparsec-iso8601/" "-ipure" "-iC:\ghc\msys64\home\Andi\aeson_repro > \dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\autogen" > "-iC:\ghc\msys64\home\Andi\aeson_repro\dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build > \global-autogen" "-IC:\ghc\msys64\home\Andi\aeson_repro\dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\autogen" > "-IC:\ghc\msys64\home\Andi\aeson_repro\dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build > \global-autogen" "-IC:\ghc\msys64\home\Andi\aeson_repro\dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build" > "-Iinclude" "-IC:\ghc\msys64\home\Andi\aeson_repro\dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\include" > "-optP-include" "-optPC:\ghc\msys64\home\Andi\aeson_repro\dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\autogen\cabal_macros.h" > "-this-unit-id" "aeson-1.4.1.0-inplace" "-hide-all-packages" "-Wmissing- > home-modules" "-no-user-package-db" "-package-db" > "C:\Users\Andi\AppData\Roaming\cabal\store\ghc-8.7.20181025\package.db" > "-package-db" "C:\ghc\msys64\home\Andi\aeson_repro\dist- > newstyle\packagedb\ghc-8.7.20181025" "-package-db" > "C:\ghc\msys64\home\Andi\aeson_repro\dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\package.conf.inplace" > "-package-id" > "attoparsec-0.13.2.2-8913a968506e9e83757f6fe696d6fe61e0d4b4a8" "-package- > id" "base-4.12.0.0" "-package-id" "base- > compat-0.10.5-34e11ceb2d98e0262d1d958bca2afc3184e70c60" "-package-id" > "bytestring-0.10.8.2" "-package-id" "containers-0.6.0.1" "-package-id" > "deepseq-1.4.4.0" "-package-id" > "dlist-0.8.0.5-681a0f929505417757ba9f9981a50ab1d7c8a0e0" "-package-id" > "ghc-prim-0.5.3" "-package-id" > "hashable-1.2.7.0-50f89c5dee92df34fc2d6540cfde1983f26d8e31" "-package-id" > "primitive-0.6.4.0-c08c185073660c1604acdddfe5c369afae583ba2" "-package- > id" "scientific-0.3.6.2-4bea197b4523e02da61c34a1eed01432d9fefff6" > "-package-id" "tagged-0.8.6-d3cce1acba663b646f565adb64d80579664d8caa" > "-package-id" "template-haskell-2.14.0.0" "-package-id" "text-1.2.3.1" > "-package-id" "th- > abstraction-0.2.8.0-e197ba78a6de8bf8fc5d00ecb5a358a8b27bcc92" "-package- > id" "time-1.8.0.2" "-package-id" "time-locale- > c_-0.1.1.5-7549537073e62ce01921c89c30cc6cafeed99b5b" "-package-id" > "unordered-con_-0.2.9.0-f5cd33176070f516c88b1aac3ef61959b09fcfa6" > "-package-id" "uuid-types-1.0.3-f68643250767dce83d2c227104d15a0aa9c3c77f" > "-package-id" "vector-0.12.0.1-3a9a26f81a463f0efefa41528af3e27d3a88cc7d" > "-XHaskell2010" "Data.Aeson" "Data.Aeson.Encoding" "Data.Aeson.Parser" > "Data.Aeson.Text" "Data.Aeson.Types" "Data.Aeson.TH" > "Data.Aeson.QQ.Simple" "Data.Aeson.Encoding.Internal" > "Data.Aeson.Internal" "Data.Aeson.Internal.Time" > "Data.Aeson.Parser.Internal" "Data.Aeson.Encode" "Data.Aeson.Compat" > "Data.Aeson.Encoding.Builder" "Data.Aeson.Internal.Functions" > "Data.Aeson.Parser.Unescape" "Data.Aeson.Parser.Time" > "Data.Aeson.Types.FromJSON" "Data.Aeson.Types.Generic" > "Data.Aeson.Types.ToJSON" "Data.Aeson.Types.Class" > "Data.Aeson.Types.Internal" "Data.Attoparsec.Time" > "Data.Attoparsec.Time.Internal" "Data.Aeson.Parser.UnescapePure" "-Wall" > "-O2" "-hide-all-packages" "-g13" > [ 2 of 25] Compiling Data.Aeson.Internal.Functions ( > Data\Aeson\Internal\Functions.hs, C:\ghc\msys64\home\Andi\aeson_repro > \dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Internal\Functions.o > ) [Data.HashMap.Strict changed] > [ 5 of 25] Compiling Data.Aeson.Types.Generic ( > Data\Aeson\Types\Generic.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Types\Generic.o > ) [Prelude.Compat changed] > [ 6 of 25] Compiling Data.Aeson.Types.Internal ( > Data\Aeson\Types\Internal.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Types\Internal.o > ) [Data.Vector changed] > [ 7 of 25] Compiling Data.Aeson.Parser.Internal ( > Data\Aeson\Parser\Internal.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Parser\Internal.o > ) [Data.Scientific changed] > [ 8 of 25] Compiling Data.Aeson.Parser ( Data\Aeson\Parser.hs, > C:\ghc\msys64\home\Andi\aeson_repro\dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Parser.o > ) [Data.Aeson.Parser.Internal changed] > [ 9 of 25] Compiling Data.Attoparsec.Time.Internal ( attoparsec- > iso8601\Data\Attoparsec\Time\Internal.hs, > C:\ghc\msys64\home\Andi\aeson_repro\dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Attoparsec\Time\Internal.o > ) [Prelude.Compat changed] > > attoparsec-iso8601\Data\Attoparsec\Time\Internal.hs:24:1: warning: > [-Wunused-imports] > The import of `Unsafe.Coerce' is redundant > except perhaps to import instances from `Unsafe.Coerce' > To import instances alone, use: import Unsafe.Coerce() > | > 24 | import Unsafe.Coerce (unsafeCoerce) > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > [10 of 25] Compiling Data.Attoparsec.Time ( attoparsec- > iso8601\Data\Attoparsec\Time.hs, C:\ghc\msys64\home\Andi\aeson_repro > \dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Attoparsec\Time.o > ) [Data.Attoparsec.Text changed] > [11 of 25] Compiling Data.Aeson.Parser.Time ( Data\Aeson\Parser\Time.hs, > C:\ghc\msys64\home\Andi\aeson_repro\dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Parser\Time.o > ) [Data.Attoparsec.Text changed] > [12 of 25] Compiling Data.Aeson.Types.FromJSON ( > Data\Aeson\Types\FromJSON.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Types\FromJSON.o > ) [Data.Primitive.PrimArray changed] > [13 of 25] Compiling Data.Aeson.Internal ( Data\Aeson\Internal.hs, > C:\ghc\msys64\home\Andi\aeson_repro\dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Internal.o > ) [Data.Aeson.Types.FromJSON changed] > [14 of 25] Compiling Data.Aeson.Internal.Time ( > Data\Aeson\Internal\Time.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Internal\Time.o > ) [Data.Attoparsec.Time.Internal changed] > [15 of 25] Compiling Data.Aeson.Encoding.Builder ( > Data\Aeson\Encoding\Builder.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Encoding\Builder.o > ) [Data.Vector changed] > [16 of 25] Compiling Data.Aeson.Encoding.Internal ( > Data\Aeson\Encoding\Internal.hs, C:\ghc\msys64\home\Andi\aeson_repro > \dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Encoding\Internal.o > ) [Data.Scientific changed] > [17 of 25] Compiling Data.Aeson.Encoding ( Data\Aeson\Encoding.hs, > C:\ghc\msys64\home\Andi\aeson_repro\dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Encoding.o > ) [Data.Aeson.Encoding.Internal changed] > [18 of 25] Compiling Data.Aeson.Types.ToJSON ( > Data\Aeson\Types\ToJSON.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- > newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Types\ToJSON.o > ) [Data.Primitive.PrimArray changed] > > Access violation in generated code when executing data at 0x103fec440 > > Attempting to reconstruct a stack trace... > > Frame Code address > * 0x845d9c0 0x103fec440 > * 0x845da20 0x400c0f8 E:\ghc_dwarf\inplace\bin\ghc- > stage2.exe+0x3c0c0f8 > * 0x845da80 0x3fec9a1 E:\ghc_dwarf\inplace\bin\ghc- > stage2.exe+0x3bec9a1 > * 0x845dab0 0x3feca31 E:\ghc_dwarf\inplace\bin\ghc- > stage2.exe+0x3beca31 > * 0x845dab8 0x34c8934 E:\ghc_dwarf\inplace\bin\ghc- > stage2.exe+0x30c8934 > * 0x845dac0 0xfa340 > * 0x845dac8 0x2a940b78 > * 0x845dad0 0x2a98cd69 > * 0x845dad8 0x2a98d7d0 > > CallStack (from HasCallStack): > die', called at .\\Distribution\\Client\\ProjectOrchestration.hs:977:55 > in main:Distribution.Client.ProjectOrchestration > cabal.exe: Failed to build aeson-1.4.1.0-inplace. The build process > terminated > with exit code 11 > }}} > > I could only reproduce it with master on Windows so far. It always > triggers but under very specific circumstances: > * GHC built with the flags above, adding dwarf info to the ghc executable > or removing dwarf info eliminates the issue. > * Only on a complete rebuild of aeson. Restarting the crashed build > finishes without an error. New description: Original report below. In this case we compile aeson which uses TH triggering dynamic loading of a number of libraries. Some libraries (eg base) have FFI exports which require us to place a relative jump to the RTS in order to register a stable name. Now an issue arises if base is placed more than 2G from the RTS as we can't have relative jumps are limited to a 2GB range. In the particular case this caused the jump target to underflow, resulting in a jump to unallocated memory and a segfault. In more detail the PE linker (PEi386.c:ocResolve_PEi386) fails to detect, or properly deal with the bounds violation. There seems to be some code in place to deal with an overflow already but fails to detect it. ---- I haven't had any luck with reproducing it outside of building the aeson package with cabal yet. So for now just documenting the fact. build.mk used {{{ GhcLibHcOpts += -g3 GhcRtsHcOpts += -g3 STRIP_CMD = : BUILD_PROF_LIBS = NO SplitObjs = NO SplitSections = NO HADDOCK_DOCS = NO BUILD_SPHINX_HTML = NO BUILD_SPHINX_PDF = NO BUILD_MAN = NO }}} Error log: {{{ "E:/ghc_dwarf/inplace/bin/ghc-stage2.exe" "--make" "-fbuilding-cabal- package" "-O" "-outputdir" "C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build" "-odir" "C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build" "-hidir" "C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build" "-stubdir" "C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build""-i" "-iC:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build" "-i." "-iattoparsec-iso8601/" "-ipure" "-iC:\ghc\msys64\home\Andi\aeson_repro \dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\autogen" "-iC:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\global- autogen" "-IC:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\autogen" "-IC:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\global- autogen" "-IC:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build" "-Iinclude" "-IC:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\include" "-optP-include" "-optPC:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\autogen\cabal_macros.h" "-this-unit-id" "aeson-1.4.1.0-inplace" "-hide-all-packages" "-Wmissing- home-modules" "-no-user-package-db" "-package-db" "C:\Users\Andi\AppData\Roaming\cabal\store\ghc-8.7.20181025\package.db" "-package-db" "C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\packagedb\ghc-8.7.20181025" "-package-db" "C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\package.conf.inplace" "-package-id" "attoparsec-0.13.2.2-8913a968506e9e83757f6fe696d6fe61e0d4b4a8" "-package- id" "base-4.12.0.0" "-package-id" "base- compat-0.10.5-34e11ceb2d98e0262d1d958bca2afc3184e70c60" "-package-id" "bytestring-0.10.8.2" "-package-id" "containers-0.6.0.1" "-package-id" "deepseq-1.4.4.0" "-package-id" "dlist-0.8.0.5-681a0f929505417757ba9f9981a50ab1d7c8a0e0" "-package-id" "ghc-prim-0.5.3" "-package-id" "hashable-1.2.7.0-50f89c5dee92df34fc2d6540cfde1983f26d8e31" "-package-id" "primitive-0.6.4.0-c08c185073660c1604acdddfe5c369afae583ba2" "-package-id" "scientific-0.3.6.2-4bea197b4523e02da61c34a1eed01432d9fefff6" "-package- id" "tagged-0.8.6-d3cce1acba663b646f565adb64d80579664d8caa" "-package-id" "template-haskell-2.14.0.0" "-package-id" "text-1.2.3.1" "-package-id" "th-abstraction-0.2.8.0-e197ba78a6de8bf8fc5d00ecb5a358a8b27bcc92" "-package-id" "time-1.8.0.2" "-package-id" "time-locale- c_-0.1.1.5-7549537073e62ce01921c89c30cc6cafeed99b5b" "-package-id" "unordered-con_-0.2.9.0-f5cd33176070f516c88b1aac3ef61959b09fcfa6" "-package-id" "uuid-types-1.0.3-f68643250767dce83d2c227104d15a0aa9c3c77f" "-package-id" "vector-0.12.0.1-3a9a26f81a463f0efefa41528af3e27d3a88cc7d" "-XHaskell2010" "Data.Aeson" "Data.Aeson.Encoding" "Data.Aeson.Parser" "Data.Aeson.Text" "Data.Aeson.Types" "Data.Aeson.TH" "Data.Aeson.QQ.Simple" "Data.Aeson.Encoding.Internal" "Data.Aeson.Internal" "Data.Aeson.Internal.Time" "Data.Aeson.Parser.Internal" "Data.Aeson.Encode" "Data.Aeson.Compat" "Data.Aeson.Encoding.Builder" "Data.Aeson.Internal.Functions" "Data.Aeson.Parser.Unescape" "Data.Aeson.Parser.Time" "Data.Aeson.Types.FromJSON" "Data.Aeson.Types.Generic" "Data.Aeson.Types.ToJSON" "Data.Aeson.Types.Class" "Data.Aeson.Types.Internal" "Data.Attoparsec.Time" "Data.Attoparsec.Time.Internal" "Data.Aeson.Parser.UnescapePure" "-Wall" "-O2" "-hide-all-packages" "-g13" [ 2 of 25] Compiling Data.Aeson.Internal.Functions ( Data\Aeson\Internal\Functions.hs, C:\ghc\msys64\home\Andi\aeson_repro \dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Internal\Functions.o ) [Data.HashMap.Strict changed] [ 5 of 25] Compiling Data.Aeson.Types.Generic ( Data\Aeson\Types\Generic.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Types\Generic.o ) [Prelude.Compat changed] [ 6 of 25] Compiling Data.Aeson.Types.Internal ( Data\Aeson\Types\Internal.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Types\Internal.o ) [Data.Vector changed] [ 7 of 25] Compiling Data.Aeson.Parser.Internal ( Data\Aeson\Parser\Internal.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Parser\Internal.o ) [Data.Scientific changed] [ 8 of 25] Compiling Data.Aeson.Parser ( Data\Aeson\Parser.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Parser.o ) [Data.Aeson.Parser.Internal changed] [ 9 of 25] Compiling Data.Attoparsec.Time.Internal ( attoparsec- iso8601\Data\Attoparsec\Time\Internal.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Attoparsec\Time\Internal.o ) [Prelude.Compat changed] attoparsec-iso8601\Data\Attoparsec\Time\Internal.hs:24:1: warning: [-Wunused-imports] The import of `Unsafe.Coerce' is redundant except perhaps to import instances from `Unsafe.Coerce' To import instances alone, use: import Unsafe.Coerce() | 24 | import Unsafe.Coerce (unsafeCoerce) | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [10 of 25] Compiling Data.Attoparsec.Time ( attoparsec- iso8601\Data\Attoparsec\Time.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Attoparsec\Time.o ) [Data.Attoparsec.Text changed] [11 of 25] Compiling Data.Aeson.Parser.Time ( Data\Aeson\Parser\Time.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Parser\Time.o ) [Data.Attoparsec.Text changed] [12 of 25] Compiling Data.Aeson.Types.FromJSON ( Data\Aeson\Types\FromJSON.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Types\FromJSON.o ) [Data.Primitive.PrimArray changed] [13 of 25] Compiling Data.Aeson.Internal ( Data\Aeson\Internal.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Internal.o ) [Data.Aeson.Types.FromJSON changed] [14 of 25] Compiling Data.Aeson.Internal.Time ( Data\Aeson\Internal\Time.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Internal\Time.o ) [Data.Attoparsec.Time.Internal changed] [15 of 25] Compiling Data.Aeson.Encoding.Builder ( Data\Aeson\Encoding\Builder.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Encoding\Builder.o ) [Data.Vector changed] [16 of 25] Compiling Data.Aeson.Encoding.Internal ( Data\Aeson\Encoding\Internal.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Encoding\Internal.o ) [Data.Scientific changed] [17 of 25] Compiling Data.Aeson.Encoding ( Data\Aeson\Encoding.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Encoding.o ) [Data.Aeson.Encoding.Internal changed] [18 of 25] Compiling Data.Aeson.Types.ToJSON ( Data\Aeson\Types\ToJSON.hs, C:\ghc\msys64\home\Andi\aeson_repro\dist- newstyle\build\x86_64-windows\ghc-8.7.20181025\aeson-1.4.1.0\build\Data\Aeson\Types\ToJSON.o ) [Data.Primitive.PrimArray changed] Access violation in generated code when executing data at 0x103fec440 Attempting to reconstruct a stack trace... Frame Code address * 0x845d9c0 0x103fec440 * 0x845da20 0x400c0f8 E:\ghc_dwarf\inplace\bin\ghc- stage2.exe+0x3c0c0f8 * 0x845da80 0x3fec9a1 E:\ghc_dwarf\inplace\bin\ghc- stage2.exe+0x3bec9a1 * 0x845dab0 0x3feca31 E:\ghc_dwarf\inplace\bin\ghc- stage2.exe+0x3beca31 * 0x845dab8 0x34c8934 E:\ghc_dwarf\inplace\bin\ghc- stage2.exe+0x30c8934 * 0x845dac0 0xfa340 * 0x845dac8 0x2a940b78 * 0x845dad0 0x2a98cd69 * 0x845dad8 0x2a98d7d0 CallStack (from HasCallStack): die', called at .\\Distribution\\Client\\ProjectOrchestration.hs:977:55 in main:Distribution.Client.ProjectOrchestration cabal.exe: Failed to build aeson-1.4.1.0-inplace. The build process terminated with exit code 11 }}} I could only reproduce it with master on Windows so far. It always triggers but under very specific circumstances: * GHC built with the flags above, adding dwarf info to the ghc executable or removing dwarf info eliminates the issue. * Only on a complete rebuild of aeson. Restarting the crashed build finishes without an error. -- Comment: Marking as high as we should try to get this into 8.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 19:59:17 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 19:59:17 -0000 Subject: [GHC] #15808: Loading libraries with FFI exports may cause segfaults in the compiler if they are loaded far from the rts in memory. In-Reply-To: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> References: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> Message-ID: <062.10d568054c21cabd04dd75c87b01429b@haskell.org> #15808: Loading libraries with FFI exports may cause segfaults in the compiler if they are loaded far from the rts in memory. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.7 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I recently noticed that e019ec94f12268dd92ea5d5204e9e57e7ebf10ca broke i386 (and is now reverted). This might be a good commit to check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Oct 30 20:25:08 2018 From: ghc-devs at haskell.org (GHC) Date: Tue, 30 Oct 2018 20:25:08 -0000 Subject: [GHC] #15767: "StgCmmEnv: variable not found" with FunctionalDependencies and FlexibleContexts In-Reply-To: <045.2239633dfbb009c41762262dc87d11d7@haskell.org> References: <045.2239633dfbb009c41762262dc87d11d7@haskell.org> Message-ID: <060.c9e5375699f80f43a8a19af07466db9b@haskell.org> #15767: "StgCmmEnv: variable not found" with FunctionalDependencies and FlexibleContexts -------------------------------------+------------------------------------- Reporter: roland | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: 8.6.2 Component: Compiler | Version: 8.6.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash or panic | typecheck/should_fail/T15767 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.6.2 Comment: Merged with a49f95c29b3a5f665b3ec0f1f05d78b73244b1f1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 31 00:20:03 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Oct 2018 00:20:03 -0000 Subject: [GHC] #15839: DerivingStrategies defaulting warning has no associated enable/suppress flag Message-ID: <044.8869ec0aa9a2ffb5ce3df38c8f653a62@haskell.org> #15839: DerivingStrategies defaulting warning has no associated enable/suppress flag -------------------------------------+------------------------------------- Reporter: tejon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Poor/confusing Unknown/Multiple | error message Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When `DerivingStrategies`, `DeriveAnyClass` and `GeneralizedNewtypeDeriving` are enabled together, an instance that could be derived with either `newtype` or `anyclass` throws a warning when no strategy is specified. It appears to be impossible to suppress this warning. Even `-w` doesn't work! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 31 00:32:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Oct 2018 00:32:45 -0000 Subject: [GHC] #15834: genSym is not thread safe with respect to setNumCapabilities In-Reply-To: <051.bde0eea937a5b36058462e4d3b9ef835@haskell.org> References: <051.bde0eea937a5b36058462e4d3b9ef835@haskell.org> Message-ID: <066.10567cb9f83bfbd083adc20251be4752@haskell.org> #15834: genSym is not thread safe with respect to setNumCapabilities ---------------------------------+---------------------------------------- Reporter: NeilMitchell | Owner: (none) Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: invalid | 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 NeilMitchell): * status: new => closed * resolution: => invalid Comment: Looking further, I came up with a minimal test case for generating uniques on multiple threads which produced duplicates. I was able to reproduce it on our internal build of GHC, but NOT a stock build. I am now fairly certain that the build of GHC didn't get THREADED_RTS passed to the genSym.c file, explaining the duplicate uniques. Sorry for the noise! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 31 09:13:00 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Oct 2018 09:13:00 -0000 Subject: [GHC] #15808: Loading libraries with FFI exports may cause segfaults in the compiler if they are loaded far from the rts in memory. In-Reply-To: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> References: <047.aa1b2815566548ec56bdad98551c4d3e@haskell.org> Message-ID: <062.71faab71cc12506c3fbe6fdfa297c17c@haskell.org> #15808: Loading libraries with FFI exports may cause segfaults in the compiler if they are loaded far from the rts in memory. -------------------------------------+------------------------------------- Reporter: AndreasK | Owner: (none) Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.7 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by AndreasK): The bug was already present in a commit I tried from the second half of September. So sadly a different issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 31 10:54:22 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Oct 2018 10:54:22 -0000 Subject: [GHC] #15839: DerivingStrategies defaulting warning has no associated enable/suppress flag In-Reply-To: <044.8869ec0aa9a2ffb5ce3df38c8f653a62@haskell.org> References: <044.8869ec0aa9a2ffb5ce3df38c8f653a62@haskell.org> Message-ID: <059.68534d6ad9ef15d355519387aeb44a27@haskell.org> #15839: DerivingStrategies defaulting warning has no associated enable/suppress flag -------------------------------------+------------------------------------- Reporter: tejon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: deriving, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * keywords: => deriving, newcomer Comment: To be more precise, this has nothing to do with `DerivingStrategies`, but rather the interaction between `DeriveAnyClass` and `GeneralizedNewtypeDeriving`. The following code is a minimal example of the issue: {{{#!hs {-# LANGUAGE DeriveAnyClass #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} module Bug where class C a newtype T a = MkT a deriving C }}} {{{ $ /opt/ghc/8.6.1/bin/ghci Bug.hs GHCi, version 8.6.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:6:30: warning: • Both DeriveAnyClass and GeneralizedNewtypeDeriving are enabled Defaulting to the DeriveAnyClass strategy for instantiating C • In the newtype declaration for ‘T’ | 6 | newtype T a = MkT a deriving C | ^ Ok, one module loaded. }}} Indeed, there is no flag associated with this warning, so there is currently no way to suppress this. I don't think this would be too difficult to fix, luckily. All you'd need to do is: 1. Think of a name for a flag to control this warning. 2. Toggle whether this warning gets emitted or not behind said flag. Any volunteers? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 31 10:55:20 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Oct 2018 10:55:20 -0000 Subject: [GHC] #15798: Flag to warn when deriving strategy is not explicitly specified In-Reply-To: <049.5f2057353415a55d9c8168e9d08cdca6@haskell.org> References: <049.5f2057353415a55d9c8168e9d08cdca6@haskell.org> Message-ID: <064.cb8efb57e993765ea2287c82f3548cf3@haskell.org> #15798: Flag to warn when deriving strategy is not explicitly specified -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: deriving, | 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: => deriving, newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 31 10:56:56 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Oct 2018 10:56:56 -0000 Subject: [GHC] #15836: ghc-in-ghci script fails when there is a Main.hs in the top-level directory In-Reply-To: <049.6d22df5e6bd2414b533bdbc96e762abd@haskell.org> References: <049.6d22df5e6bd2414b533bdbc96e762abd@haskell.org> Message-ID: <064.1d450bf12844b6192432daa95678836b@haskell.org> #15836: ghc-in-ghci script fails when there is a Main.hs in the top-level directory -------------------------------------+------------------------------------- Reporter: mpickering | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 31 11:10:32 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Oct 2018 11:10:32 -0000 Subject: [GHC] #15837: Hadrian should build dynamically linked ghc binary In-Reply-To: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> References: <045.a3d95f84b1c84f6d48d104d682bf2c9a@haskell.org> Message-ID: <060.5b07495dda083f42b357af22505d25be@haskell.org> #15837: Hadrian should build dynamically linked ghc binary -------------------------------------+------------------------------------- Reporter: davide | Owner: davide Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.6.1 (Hadrian) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by davide: Old description: > The ghc binary is dynamically linked via make in various flavors (e.g. > quick). Hadrian builds a static linked binary in these cases (this is a > bug). Various change are needed to fix this: > > 1. Add new .cabal file field extra-dynamic-library-flavours (see > [https://github.com/haskell/cabal/pull/5606 this PR]). > 2. Use .cabal extra-dynamic-library-flavours for the RTS (see > [https://github.com/snowleopard/hadrian/issues/695#issue-367436377 this > comment], depends on 1.) > 3. Hadrian: fix management of nontrivial dynamic flavours of libHSrts > (see [https://github.com/snowleopard/hadrian/pull/698 this PR]). > 4. Hadrian should build ghc with the `-fPIC -dynamic` options (see > [https://github.com/DavidEichmann/ghc/commit/752021f69f577b678630302b567fd712c565624b > #diff-408bbe46d4afae11991cbadb2c531b78 this comment], depends on 3.). > 5. Use the correct relative path to the dynamically linked libraries (see > [https://phabricator.haskell.org/D5281 this change], depends on 3. and > 4.). New description: The ghc binary is dynamically linked via make in various flavors (e.g. quick). Hadrian builds a static linked binary in these cases (this is a bug). Various change are needed to fix this: 1. Add new .cabal file field extra-dynamic-library-flavours (see [https://github.com/haskell/cabal/pull/5606 this PR]). 2. Use .cabal extra-dynamic-library-flavours for the RTS (see [https://github.com/snowleopard/hadrian/issues/695#issue-367436377 this comment], depends on 1.) 3. Hadrian: fix management of nontrivial dynamic flavours of libHSrts (see [https://github.com/snowleopard/hadrian/pull/698 this PR]). 4. Hadrian should build ghc with the `-fPIC -dynamic` options (see [https://github.com/DavidEichmann/ghc/commit/752021f69f577b678630302b567fd712c565624b #diff-408bbe46d4afae11991cbadb2c531b78 this comment], depends on 3.). 5. Use the correct relative path to the dynamically linked libraries (see [https://phabricator.haskell.org/D5281 this change], depends on 3. and 4.). 6. Build ghc-iserv-dyn, as it is will be required required by many tests (see/depends on [https://phabricator.haskell.org/D5255 patch for ghc- iserv-prof]) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 31 11:30:54 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Oct 2018 11:30:54 -0000 Subject: [GHC] #15798: Flag to warn when deriving strategy is not explicitly specified In-Reply-To: <049.5f2057353415a55d9c8168e9d08cdca6@haskell.org> References: <049.5f2057353415a55d9c8168e9d08cdca6@haskell.org> Message-ID: <064.eeebe9e7e5b7c8dec41e92addc1972fb@haskell.org> #15798: Flag to warn when deriving strategy is not explicitly specified -------------------------------------+------------------------------------- Reporter: andrewthad | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: deriving, | 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 monoidal): I would suggest `-Wmissing-deriving-strategies`, as there are several -Wmissing-* flags (missing-local-signatures, missing-import-lists, missing-home-modules etc.). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 31 13:45:27 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Oct 2018 13:45:27 -0000 Subject: [GHC] #14512: System-wide installed profile build cannot load libHSghc-prim.0.5.2.0.so In-Reply-To: <047.5a0900c5c72a8eef1106855d270e16d7@haskell.org> References: <047.5a0900c5c72a8eef1106855d270e16d7@haskell.org> Message-ID: <062.05e8d8ebd01fa637ed65b11729bf1932@haskell.org> #14512: System-wide installed profile build cannot load libHSghc-prim.0.5.2.0.so -------------------------------------+------------------------------------- Reporter: tdammers | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.8.1 Component: Build System | Version: 8.3 (make) | 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 RyanGlScott): I suspect that this is a duplicate of #13531. Can you try this again with GHC HEAD and see if you still experience this issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 31 14:22:45 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Oct 2018 14:22:45 -0000 Subject: [GHC] #15003: Data.List documentation should list complexities of more functions In-Reply-To: <043.7ec461499989f0acca4423edd3731e7e@haskell.org> References: <043.7ec461499989f0acca4423edd3731e7e@haskell.org> Message-ID: <058.9c8886ac16a1cd3310266470f41c3b25@haskell.org> #15003: Data.List documentation should list complexities of more functions -------------------------------------+------------------------------------- Reporter: gbaz | Owner: supersven Type: feature request | Status: new Priority: normal | Milestone: 8.4.3 Component: libraries/base | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by supersven): I already figured out a bunch of complexities last spring. Then got a bit busy with other projects... I'll update the old branch with the current master, re-check the complexities and try to get it merged. https://github.com/supersven/ghc/commits/T15003_DataList_complexities -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 31 15:28:38 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Oct 2018 15:28:38 -0000 Subject: [GHC] #15840: Inline data constructor wrappers very late Message-ID: <047.51e591151469c056f59e9972a2d6d4ce@haskell.org> #15840: Inline data constructor wrappers very late -------------------------------------+------------------------------------- Reporter: aspiwack | Owner: (none) Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.7 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This came up in the context of the implementation of linear types, where more data constructors have wrapper. But this should be of more general use. I want to share this in case someone can find an objection to this approach. Currently, writing a RULE involving a data constructor with a wrapper is perilous: the wrapper will be inlined in phase 2, probably before the RULE is even triggered (necessarily if the RULE only runs in phase 1). I want to remedy this situation. This proposal is mainly from Simon Peyton Jones, any misrepresentation is, of course, my own. The proposal is to inline all data constructor wrappers in phase 0. After all the RULE business has been dealt with. If we do that, we need to be quite careful about case-of-know-constructor: In {{{#!hs case $WK u of { K x -> e; … } }}} `$WK` wouldn't unfold until very late. But we don't want the `case` expression to be blocked! Otherwise we may, for instance, prevent the function's size to be small enough to be inlined. Hence a maybe some rules will not trigger. That would not be acceptable. Fortunately, in order to decide whether case-of-known-constructor can perform, the simplifier calls `exprIsConApp_maybe`. Also fortunate is that in the situation above, we really don't care about any RULE stuff (at least not in relation with `K`). So what we can do is make `exprIsConApp_maybe` a bit smarter and teach it to see through data constructor wrappers. Let's take an unpacking wrapper as an example: {{{#!hs data T = MkT {-# UNPACK #-} !(Int, Bool) $WMkT p = case p of (i,b) -> MkT i b }}} We have to see that `$WMkT u` is a constructor application. Hence we need to be able to peek through cases. We also need to be able to witness that we have done so. So the type of `exprIsConApp_maybe` would change from {{{#!hs exprIsConApp_maybe :: InScopeEnv -> CoreExpr -> Maybe (DataCon, [Type], [CoreExpr]) }}} to {{{#!hs exprIsConApp_maybe :: InScopeEnv -> CoreExpr -> Maybe ([Float],DataCon, [Type], [CoreExpr]) }}} Where `Float`-s are lets or cases with a single alternative (much like in the FloatOut pass). We then need to change case-of-known-constructor to also perform case-of- lets and case-of-cases when such floats are found. In summary: data constructor wrappers would be inlined in phase 0, except when they can trigger a case-of-known constructor, in which case they would be inlined immediately. Does anyone sees something which could go wrong with this plan? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 31 15:55:14 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Oct 2018 15:55:14 -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.ff3e7af23fc97204ee5f34e73e726d13@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: | -------------------------------------+------------------------------------- Comment (by fendor): The problem should be fixable by using stack in nix mode, e.g. `stack setup --nix` or adding the nix flag in the global project. E.g. packages: [] resolver: lts-12.14 nix: enable: true -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 31 22:12:42 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Oct 2018 22:12:42 -0000 Subject: [GHC] #15826: Allow registering (Source)Plugins through the GHC API In-Reply-To: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> References: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> Message-ID: <061.a67b6e55f0cbb2bef3fb42dfa5136c05@haskell.org> #15826: Allow registering (Source)Plugins through the GHC API -------------------------------------+------------------------------------- Reporter: DanielG | Owner: DanielG Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D5278 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > The reason for the existence of the ModIface is for recompilation checking. Recomopilation checking is a ''contributory'' reason. But the `Iface` data type is incredibly useful as an intermediate between the serialised bytestring form of a `.hi` file and a fully type-checked form of the module `ModDetails`. `TcIface` goes from `ModIface` to `ModDetails`. But yes, `ModIface` is a great intermediate form on which to base fingerprint generation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 31 22:22:59 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Oct 2018 22:22:59 -0000 Subject: [GHC] #15826: Allow registering (Source)Plugins through the GHC API In-Reply-To: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> References: <046.3de8f5c8670c8df506c1bddf56c2bc0d@haskell.org> Message-ID: <061.39619ddce3c92509f07694b912d6b88d@haskell.org> #15826: Allow registering (Source)Plugins through the GHC API -------------------------------------+------------------------------------- Reporter: DanielG | Owner: DanielG Type: feature request | Status: new Priority: normal | Milestone: Component: GHC API | Version: 8.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D5278 Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): That's a fair point. I should have clarified I was talking specifically about the `ModIface` field in the `LoadedPlugin` datatype. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 31 22:31:31 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Oct 2018 22:31:31 -0000 Subject: [GHC] #15839: DerivingStrategies defaulting warning has no associated enable/suppress flag In-Reply-To: <044.8869ec0aa9a2ffb5ce3df38c8f653a62@haskell.org> References: <044.8869ec0aa9a2ffb5ce3df38c8f653a62@haskell.org> Message-ID: <059.128a86bfd34ea8ada1dcf0ceaa14f469@haskell.org> #15839: DerivingStrategies defaulting warning has no associated enable/suppress flag -------------------------------------+------------------------------------- Reporter: tejon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: deriving, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tejon): Ah, good catch -- I guess I never tried without `DerivingStrategies`. I'll update the bug description, and include your minimum example. For flag name I nominate `-Wderiving-defaults`, after the pattern of `-Wtype-defaults`. It sounds like this would be an easy way to get my toes wet in the GHC codebase. If there's no argument with my flag suggestion, I'll try to implement it myself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Oct 31 22:50:24 2018 From: ghc-devs at haskell.org (GHC) Date: Wed, 31 Oct 2018 22:50:24 -0000 Subject: [GHC] #15839: DerivingStrategies defaulting warning has no associated enable/suppress flag In-Reply-To: <044.8869ec0aa9a2ffb5ce3df38c8f653a62@haskell.org> References: <044.8869ec0aa9a2ffb5ce3df38c8f653a62@haskell.org> Message-ID: <059.d86cfcf17daeb9b737a2a8a274afa055@haskell.org> #15839: DerivingStrategies defaulting warning has no associated enable/suppress flag -------------------------------------+------------------------------------- Reporter: tejon | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.6.1 Resolution: | Keywords: deriving, | newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Poor/confusing | Unknown/Multiple error message | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by tejon: Old description: > When `DerivingStrategies`, `DeriveAnyClass` and > `GeneralizedNewtypeDeriving` are enabled together, an instance that could > be derived with either `newtype` or `anyclass` throws a warning when no > strategy is specified. It appears to be impossible to suppress this > warning. Even `-w` doesn't work! New description: When `DeriveAnyClass` and `GeneralizedNewtypeDeriving` are enabled together, an instance that could be derived with either one defaults to `DeriveAnyClass` and throws a warning to that effect. There is currently no flag to suppress that warning (it appears even with `-w`). In the presence of `DerivingStrategies`, it seems desirable to be able to suppress this. Proposed flag to control it: `-Wderiving-defaults`, after the pattern of `-Wtype-defaults`. This flag should be part of the default warning set, as without `DerivingStrategies` it remains a bad idea to have both newtype and anyclass active. Minimal example (thanks RyanGIScott): {{{ {-# LANGUAGE DeriveAnyClass #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} module Bug where class C a newtype T a = MkT a deriving C }}} {{{ $ /opt/ghc/8.6.1/bin/ghci Bug.hs GHCi, version 8.6.1: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/rgscott/.ghci [1 of 1] Compiling Bug ( Bug.hs, interpreted ) Bug.hs:6:30: warning: • Both DeriveAnyClass and GeneralizedNewtypeDeriving are enabled Defaulting to the DeriveAnyClass strategy for instantiating C • In the newtype declaration for ‘T’ | 6 | newtype T a = MkT a deriving C | ^ Ok, one module loaded. }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler