From ghc-devs at haskell.org Mon Feb 1 05:22:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 05:22:39 -0000 Subject: [GHC] #11522: maxStkSize can overflow Message-ID: <047.c682131ad79ad28d6b34355aabbd4286@haskell.org> #11522: maxStkSize can overflow -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.4 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `maxStkSize` field of `GC_FLAGS` is a `nat`, or `unsigned int`. It's measured in words, but still 32G is not an unreasonable amount of memory by today's standards. Maybe it's unlikely that anyone would want to set the stack size limit to more than 32G. But if you happen to have just over 40G of physical memory then the default stack size limit will overflow to a value just above zero and then Bad Things would happen. If we want to actually enforce stack limits that are greater than 2^32^ words, we would need to increase the size of the `tot_stack_size` field of a TSO also. Simple test of overflow behavior: `ghci +RTS -K32.0001G` will exit with a stack overflow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 08:34:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 08:34:31 -0000 Subject: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled In-Reply-To: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> References: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> Message-ID: <061.3b6ccd9af2ab2e749a4b7a898b818733@haskell.org> #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK. If the reason that the ASSERT gets exponentially expensive is that the types get exponentially large, that's a good explanation. That indeed is a hard problem (see e.g. #9198). But what's odd is that it doesn't bomb out on us when the ASSERT is not there. That seems odd to me -- if the types get very large I'd expect the type checker to fail even in the absence of the ASSERT. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 08:49:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 08:49:29 -0000 Subject: [GHC] #11519: Inferring non-tau kinds In-Reply-To: <047.4d7c879b01fe33a75f5e9304ccb4f8c9@haskell.org> References: <047.4d7c879b01fe33a75f5e9304ccb4f8c9@haskell.org> Message-ID: <062.0301a85baa78a29d71ceb1f56628e80f@haskell.org> #11519: Inferring non-tau kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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): Yes I think that using `ExpType`s is exactly the right thing here. Interestingly we used to have a variant of `ExpType`, called `ExpKind`: {{{ data ExpKind = EK TcKind (TcKind -> SDoc) }}} but that has gone now. I'm not sure how you managed to keep the error messages good without that `SDoc` argument, but I'm all for the simplification. So now perhaps `ExpType` will do just fine. I also agree with Adam about explicit quantification. (Both are independently useful.) And in fact I think that the declaration he give is accepted already -- an entirely un-documented feature. Adding some docs for it would be good. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 09:12:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 09:12:46 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.1f7fa069886f60eeadb4c1a8a403901e@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): * Yes I hypothesise that when we have #11471 done (which will be soon) we can lift the restriction on partial applications of unboxed types. I don't remember why the restriction is there anyway; it may be that we can simply lift it. * The entire business of "querying the kinds at which a `TyCon` is instantiated" seems moot once types and kinds are unified. I.e. now. Doesn't the same decompose-type-application stuff work for kinds? * Yes, the main reason for `TyCon` is to be able to ask for its name, etc. Maybe other meta-data too in due course. SO I agree with comment:12. But let's not expose the internal representation of either `TypeRep` or `TyCon`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 09:24:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 09:24:30 -0000 Subject: [GHC] #11520: GHC falls into a hole if given incorrect kind signature In-Reply-To: <046.a2116e67b07177218d33d38f3453d162@haskell.org> References: <046.a2116e67b07177218d33d38f3453d162@haskell.org> Message-ID: <061.cf62e7e071dd9bd382a1ba5ed9c03c64@haskell.org> #11520: GHC falls into a hole if given incorrect kind signature -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The trouble here is this: * The kind error is indeed found and reported (i.e. collected in the bag of errors in the monad) * But we continue anyway into `checkValidInstance` * The latter calls `fvProv` to check for something like the size of instance * Which fails because the unsolved constraint has left a hole in the type Really we should not even attempt `checkValidInstance` if we fail to kind- check the type. We could use a `checkNoErrs` in `TcHsTye.TcHsClsInstType`. But there are many other uses of `solveEqualities` all of which in principle have the same concern. So I thought about adding `checkNoErrs` to `solveEqualities`. But there I see {{{ -- | Type-check a thing that emits only equality constraints, then -- solve those constraints. Emits errors -- but does not fail -- -- if there is trouble. solveEqualities :: TcM a -> TcM a }}} '''Richard''': why did you want the "...but does not fail..." bit? What goes wrong if it fais on error? In effect it always used to! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 09:25:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 09:25:14 -0000 Subject: [GHC] #11520: GHC falls into a hole if given incorrect kind signature In-Reply-To: <046.a2116e67b07177218d33d38f3453d162@haskell.org> References: <046.a2116e67b07177218d33d38f3453d162@haskell.org> Message-ID: <061.1588074c2b72e53b6a0e59c6918b0683@haskell.org> #11520: GHC falls into a hole if given incorrect kind signature -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeInType * priority: normal => highest Comment: Highest prio because I think the fix is easy and an outright crash is bad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 10:04:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 10:04:20 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case In-Reply-To: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> References: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> Message-ID: <062.826c4ed99880e9817e294127ce87aae2@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: gmainland Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 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:D1864 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thank you Geoff! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 10:37:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 10:37:13 -0000 Subject: [GHC] #11499: Loading temp shared object failed in GHCi In-Reply-To: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> References: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> Message-ID: <060.17dfe61b73b92a6320cd405906107ace@haskell.org> #11499: Loading temp shared object failed in GHCi -------------------------------------+------------------------------------- Reporter: alfa07 | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Resolution: | Keywords: dynamic | linking Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * owner: => trommler Comment: Replying to [comment:9 trommler]: > I can reproduce the issue on Linux with a GHC that has the #10458 patch: > > {{{ > GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help > ghc: panic! (the 'impossible' happened) > (GHC version 7.10.3 for x86_64-unknown-linux): > Loading temp shared object failed: /tmp/ghc29316_0/libghc_25.so: undefined symbol: tt_driver_class > }}} > > I see a different symbol missing but the missing symbol should come from `freetype2`, too. > > Redesign of dynamic linking should fix this. So marking as blocked on that ticket. I think I understand what is going on. The undefined symbols are provided by a package that is loaded at startup. Because we need to load (`dlopen`)with `RTLD_LOCAL` those symbols are not available in the temporary shared object. This will be fixed with the new design proposed in #11238. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 10:38:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 10:38:53 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.bd565857025f118d807348f3152cf19e@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka ): In [changeset:"e5a0a8903715b8717342dabeb72d69b4d5e61e5c/ghc" e5a0a89/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e5a0a8903715b8717342dabeb72d69b4d5e61e5c" Suppress substitution assertions to fix tests This is one place that I've missed with D1862. This doesn't fix the underlying problem and I prefer to suppress it now and fix it later as this is a part of a larger effort (#11371) to fix an old bug with `substTy` called with invalid `in_scope` sets. Test Plan: `make test TEST="hClose002 hClose003 hDuplicateTo001" Reviewers: thomie, austin, bgamari, trofi Reviewed By: trofi Differential Revision: https://phabricator.haskell.org/D1872 GHC Trac Issues: #11371 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 11:50:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 11:50:46 -0000 Subject: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled In-Reply-To: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> References: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> Message-ID: <061.955f0b6ad815c7c5b427a8a8a267a22c@haskell.org> #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): > But what's odd is that it doesn't bomb out on us when the ASSERT is not there. That seems odd to me -- if the types get very large I'd expect the type checker to fail even in the absence of the ASSERT. I think I can explain this. The [https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/Coercion.hs;a883c1b7b08657102a2081b55c8fe68714d8bf73$1305 unwrapNewTypeStepper] is protected by a [https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/TyCon.hs;a883c1b7b08657102a2081b55c8fe68714d8bf73$2062 checkRecTc] which will cause an abort if the same newtype constructor is unwrapped 100 times. The difference I believe is due to laziness and sharing, it's easy to create an exponentially big type by repeated substitution into `(a, a)` and unless `a` is (deeply) forced at some point you can do it in sub-exponential time. So when `substTy` began to force it by computing the free variables for the sanity check the problem became visible. In other words the recursion check in `checkRecTc` didn't need to force the type to decide it was a loop, so it wasn't bothered by it growing exponentially (made possible by sharing and laziness) before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 12:46:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 12:46:16 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.a8a9688460ac231f5a68094bcbb237f3@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have an implementation of this [[https://github.com/ghc/ghc/compare/master...bgamari:wip/ttypeable|here]]. It's quite rough, there are a variety of interface questions that remain to be resolved, and I have yet to fix up a few Typeable uses in GHC itself (e.g. the `Binary` instances) which prevents me from finishing a stage2 build. That being said most of the groundwork has been laid, * `TTypeRep :: k -> *` has replaced `TypeRep` in the definition of `Typeable`. The constructors of `TTypeRep` are entirely hidden; there are pattern synonyms for querying for the applications and type constructors. * There exists a `TypeRep` which is simply a quantified `TTypeRep` * We have `tTypeRepKind :: TypeRep (a :: k) -> TypeRep k` * The solver now preserves enough information to construct these representations. This took a bit of gymnastics due to the recursive kind relations of `(->)`, `TYPE`, and `Levity`. These representations are handled as a bit of a special case. I need to * The desugarer can produce new `Typeable` dictionaries * I get much of the way through the stage2 build before failing as I haven't yet updated the instances in `Binary`. * `withTypeable` doesn't yet exist * In order to test things I have lifted the unsaturated-unlifted- application Core Lint check mentioned above * `TrTyApp` includes the kind of the application, which I only realized recently isn't necessary; it can be derived from the kind of the thing being applied. There are a number of interface questions that remain: * do we want to provide the continuation-style queries or only pattern synonyms? * what should the typical use-case of serialization look like? * do we want to provide "paranoid" equality checks which scrutinize the entire representation, in addition to the constant-time fingerprint-based checks? * should the pattern synonyms against `TrTypeRep` provide the kind of the term in addition to the type constructor/applied types? * the usual bike-shedding regarding naming has yet to happen That's pretty much the current state of things after spending the better part of last weekend on the project. Further progress will likely be slow until I have time again next weekend. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 13:10:59 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 13:10:59 -0000 Subject: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled In-Reply-To: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> References: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> Message-ID: <061.56953abcfbd9a61c7376d541aae4e062@haskell.org> #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, but even with the new ASSERT, `checkRecTc` will cut off the recursion and so will not unwrap the newtype 100 times. So where is the big type coming from? I'm still missing that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 13:40:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 13:40:35 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case In-Reply-To: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> References: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> Message-ID: <062.f2d043de50b958fd30f1509bf12fa01e@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: gmainland Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 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:D1864 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 13:45:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 13:45:21 -0000 Subject: [GHC] #11513: Work out when GADT parameters should be specified In-Reply-To: <047.8e435f63c64a501e9ed45a384456290b@haskell.org> References: <047.8e435f63c64a501e9ed45a384456290b@haskell.org> Message-ID: <062.1004da0c16e4be1f5df6ca4a639350d0@haskell.org> #11513: Work out when GADT parameters should be specified -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 simonpj): In the ''worker'', I'm sure we should put the universals first. We always have, and I see no reason to change. Moreover in a pattern we drop the universals, so it must be easy to find them. In the ''wrapper'' can't we just do whatever we do for normal type signatures. Eg {{{ data T a b where T1 :: T [x] [x] T2 :: T [x] y }}} Here we just get `T1 :: forall x. T [x] [x]` and `T2 :: forall x y. T [x] y`. If those were ordinary functions we'd be done. So why aren't we done? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 13:47:03 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 13:47:03 -0000 Subject: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled In-Reply-To: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> References: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> Message-ID: <061.bfc21c26b9cba16f7039a57bd6cbf833@haskell.org> #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): If you unwrap it 100 times you end up with a type that has size `2^100`. Computing free vars of such type would take forever. And the ASSERT in `substTy` does exactly that. It's enough to unwrap it 30 times for it to become unbearably slow. That type is very regular and a very compact representation because of sharing. The type is essentially: {{{ a0 = () a1 = (a0, a0) -- note the sharing, but when free vars are -- computed they are computed for fst and snd independently a2 = (a1, a1) a3 = (a2, a2) a100 = (a99, a99) -- this has size 2^100, O(2^n) when naively explored, -- but it's represented as a sequence of O(n) pointers. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 13:47:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 13:47:57 -0000 Subject: [GHC] #11339: Possible type-checker regression in GHC 8.0 In-Reply-To: <042.e02f929caf8d7a3c89e3acf4b77b9340@haskell.org> References: <042.e02f929caf8d7a3c89e3acf4b77b9340@haskell.org> Message-ID: <057.7a48e4968ea0b247cfeb29dd0431b988@haskell.org> #11339: Possible type-checker regression in GHC 8.0 -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * version: 8.1 => 8.0.1-rc1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 13:50:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 13:50:08 -0000 Subject: [GHC] #11519: Inferring non-tau kinds In-Reply-To: <047.4d7c879b01fe33a75f5e9304ccb4f8c9@haskell.org> References: <047.4d7c879b01fe33a75f5e9304ccb4f8c9@haskell.org> Message-ID: <062.6654ecb110d6d1aed05a49577a49e143@haskell.org> #11519: Inferring non-tau kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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): Replying to [comment:2 simonpj]: > Yes I think that using `ExpType`s is exactly the right thing here. Interestingly we used to have a variant of `ExpType`, called `ExpKind`: > {{{ > data ExpKind = EK TcKind (TcKind -> SDoc) > }}} > but that has gone now. I'm not sure how you managed to keep the error messages good without that `SDoc` argument, but I'm all for the simplification. That was actually quite a bit of work. All the kind errors used to be reported eagerly, during constraint generation. Thus the `SDoc` argument came into play. Now kind errors are naturally reported from !TcErrors, so the `ExpKind` stuff doesn't work. Instead, look at `mkExpectedActualMsg`, which re-creates the old messages. You might notice that the function is a terrible mess.... I would love to find a theory or specification of error messages against which we can write an implementation. Because !TcErrors is inscrutable. I made it considerably worse, but it wasn't in that good a state when I arrived. In any case, that's where the error messages have gone. > > So now perhaps `ExpType` will do just fine. > > I also agree with Adam about explicit quantification. (Both are independently useful.) And in fact I think that the declaration he give is accepted already -- an entirely un-documented feature. Adding some docs for it would be good. I actually seem to recall implementing something along these lines once upon a time. But the following full module doesn't work for me: {{{ {-# LANGUAGE RankNTypes, TypeInType, GADTs, ConstraintKinds #-} module Bug where import GHC.Exts import Data.Kind data TypeRep (a :: k) -- abstract data TypeRepX :: (forall k. k -> Constraint) -> Type where TypeRepX :: forall k (c :: forall k'. k' -> Constraint) (a :: k). c a => TypeRep a -> TypeRepX c instance Show (TypeRep a) -- elsewhere instance forall (c :: forall k. k -> Constraint). Show (TypeRepX c) where show (TypeRepX tr) = show t }}} Is there something I'm missing? I haven't looked at the GHC code for instance declarations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 14:01:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 14:01:16 -0000 Subject: [GHC] #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances In-Reply-To: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> References: <045.4acfc426b373701e2c344883c3f62cf6@haskell.org> Message-ID: <060.aa21c59323dd282b0dbf78c5405a1475@haskell.org> #11480: UndecidableSuperClasses causes the compiler to spin with UndecidableInstances -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: PolyKinds, Resolution: fixed | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11480, | polykinds/T11480a, | polykinds/T11480b Blocked By: | Blocking: Related Tickets: #10318 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: typecheck/should_compile/T11480, polykinds/T11480a => typecheck/should_compile/T11480, polykinds/T11480a, polykinds/T11480b Comment: Thanks -- I've added your example to the regression suite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 14:10:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 14:10:36 -0000 Subject: [GHC] #11520: GHC falls into a hole if given incorrect kind signature In-Reply-To: <046.a2116e67b07177218d33d38f3453d162@haskell.org> References: <046.a2116e67b07177218d33d38f3453d162@haskell.org> Message-ID: <061.b0bfd04f48837307a48149228c2b90ba@haskell.org> #11520: GHC falls into a hole if given incorrect kind signature -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The `but does not fail` bit is just to accurately describe the function. As usual, failing is fine, but it means you get fewer error messages at a go. In other words, we can just change the behavior. But I much favor just fixing `fvProv` to do something other than panic on a coercion hole, like return an empty list. There are a bunch of these panics on coercion holes where I thought coercion holes should never be seen. But I've learned that erroneous code can make GHC take paths I hadn't considered. So I'll remove all of these panics and replace them with something that won't crash GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 14:12:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 14:12:56 -0000 Subject: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled In-Reply-To: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> References: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> Message-ID: <061.1ed880861093d272a27b54f99166fdb9@haskell.org> #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): But the question is: why doesn't `checkRecTc` cut off the unwrapping? That's what you seemed to say in comment:6 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 14:15:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 14:15:09 -0000 Subject: [GHC] #11519: Inferring non-tau kinds In-Reply-To: <047.4d7c879b01fe33a75f5e9304ccb4f8c9@haskell.org> References: <047.4d7c879b01fe33a75f5e9304ccb4f8c9@haskell.org> Message-ID: <062.801b41437268c87d29fd0e85752e5d18@haskell.org> #11519: Inferring non-tau kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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): What sort of "doesn't work"? I'm losing the connection -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 14:16:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 14:16:01 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.a7ecae04d2887ecba4254ddf4fd53b16@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:13 simonpj]: > * The entire business of "querying the kinds at which a `TyCon` is instantiated" seems moot once types and kinds are unified. I.e. now. Doesn't the same decompose-type-application stuff work for kinds? No. We're using "kind" here to refer to parameters in which the tycon's kind is dependent. That is, when we have `Proxy :: forall k. k -> Type`, `Proxy`'s first argument is dependent. We can't have a `TypeRep` just for plain, uninstantiated `Proxy` because `Proxy`'s kind mentions a forall, and we would need `TypeRep (forall k. k -> Type) Proxy`, which requires impredicativity. And there's the matter of writing the very intricate type for `mkAppTy :: TypeRep ... -> TypeRep ... -> TypeRep ...`, which would now need to perform substitution. Ick. So we just don't do any of it. This means that we can't decompose kind parameters. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 14:17:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 14:17:31 -0000 Subject: [GHC] #11520: GHC falls into a hole if given incorrect kind signature In-Reply-To: <046.a2116e67b07177218d33d38f3453d162@haskell.org> References: <046.a2116e67b07177218d33d38f3453d162@haskell.org> Message-ID: <061.d95e1e11f37b8477c81ec582a3f774af@haskell.org> #11520: GHC falls into a hole if given incorrect kind signature -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'd like to try wrapping `solveEqualities` in `checkNoErrs`. Yes, we fail more, but let's see if that worsens behaviour. My reasoning: if we take a type signature that has kind errors in it, and proceed onwards with a kind-incorrect type, we are likely to get hard-to- explain knock-on errors down the line. Let's fail faster. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 14:23:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 14:23:01 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.e4a89c6e813a740a5cd2d9306745a5f6@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:14 bgamari]: > * The solver now preserves enough information to construct these representations. This took a bit of gymnastics due to the recursive kind relations of `(->)`, `TYPE`, and `Levity`. These representations are handled as a bit of a special case. I need to [sic] Ooh. It's like a mystery novel. Perhaps having a type-safe language with both `* :: *` and self-reflective type representations shows that math is actually inconsistent and opened up a hole in spacetime through which bgamari has exited. :) I do hope that's not the case. Other points: * I vote only pattern synonyms. * Serialization is used in Cloud Haskell, no? * I like the idea of including the paranoid checks as an option for paranoid users. Although perhaps not, given that I believe it's likelier for a cosmic ray to flip a bit than for the fingerprints to give a false positive. As for names: I think a proper migration story needs to be articulated. In a few years, I'd hate to have all these extra `T`s lying around. Use a new module name for the new features and keep the old module with the old interface around? Maybe the new module can be `Data.Reflection`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 14:26:00 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 14:26:00 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.f0d00bb2da46f20baff454a64381de68@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Oh yes, we have section about that: 5.8 in the paper. OK then, how do we implement `spitPolyTyConApp`. The old API looked like: {{{ splitPolyTyConApp :: TypeRep -> (TyCon,[KindRep],[TypeRep]) }}} but what should the API look like now? Presumably the type args should be done with the new type-app-decomposition stuff, and when that says "not a type application" we can ask for the `TyCon` and `KindRep` args? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 14:26:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 14:26:47 -0000 Subject: [GHC] #11513: Work out when GADT parameters should be specified In-Reply-To: <047.8e435f63c64a501e9ed45a384456290b@haskell.org> References: <047.8e435f63c64a501e9ed45a384456290b@haskell.org> Message-ID: <062.cf73ec2e3105674fa577113abc9bf550@haskell.org> #11513: Work out when GADT parameters should be specified -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 goldfire): Everything in comment:1 is true. The problem comes up only when we don't have a wrapper. And right now, "the type variables are out of order" is not a reason to make a wrapper. If it were, then we'd be done. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 14:28:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 14:28:37 -0000 Subject: [GHC] #11513: Work out when GADT parameters should be specified In-Reply-To: <047.8e435f63c64a501e9ed45a384456290b@haskell.org> References: <047.8e435f63c64a501e9ed45a384456290b@haskell.org> Message-ID: <062.75fd5be38f287603d0c4b99009581de9@haskell.org> #11513: Work out when GADT parameters should be specified -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 simonpj): So why not put them in the "correct order" whatever that is, in the first place. I'm a bit lost. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 14:29:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 14:29:37 -0000 Subject: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled In-Reply-To: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> References: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> Message-ID: <061.266397aefb1908e17dc970f86ecffb90@haskell.org> #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): And why is it checking for unwrapping 100 times? I thought `checkRecTc` stopped at 2, not 100. Was there a reason to increase it? Maybe we've gone too far. Nice analysis, by the way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 14:30:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 14:30:47 -0000 Subject: [GHC] #11519: Inferring non-tau kinds In-Reply-To: <047.4d7c879b01fe33a75f5e9304ccb4f8c9@haskell.org> References: <047.4d7c879b01fe33a75f5e9304ccb4f8c9@haskell.org> Message-ID: <062.86c33b85687487ab41509942d47e20f4@haskell.org> #11519: Inferring non-tau kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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): The instance declaration with an explicit forall. And I just tried this, which is also rejected: {{{ instance forall a. Eq (a -> a) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 14:32:28 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 14:32:28 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.a0adf5be84844595cca870683d5c76fa@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): An alternative to falling back to an entirely unindexed `TyCon` would be to augment it with a type-indexed version, {{{#!hs -- Metadata describing a type constructor. Same thing we currently have. data TyCon = TyCon { module, package, con_name :: String } -- A type constructor together with the kinds it was applied to (abstract) data TTyCon (a :: k) = TTyCon { tycon :: TyCon, dep_kinds :: [TypeRep], kind :: TTypeRep k } -- A type representation (abstract) data TTypeRep (a :: k) where TrTyCon :: Fingerprint -> TyCon a -> TTypeRep a TrApp :: forall k1 k2 (a :: k1 -> k2) (b :: k1). Fingerprint -> TTypeRep a -> TTypeRep b -> TTypeRep (a b) pattern TRApp :: forall k k1 (a :: k1 -> k) (b :: k1). TTypeRep a -> TTypeRep b -> TTypeRep (a b) pattern TRCon :: forall k (a :: k). TTyCon a -> TTypeRep a tyConDepKinds :: TTyCon a -> [TypeRep] tyConKind :: TTyCon (a :: k) -> TTypeRep k }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 14:34:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 14:34:04 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.b60e17b85df46327409c58db00d6b753@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): If we have an un-indexed `TyCon` type (an idea I quite like), then we can do something like this: {{{ splitPolyTyConApp :: TypeRep a -> (TyCon, [TypeRepX]) }}} which gets you all the arguments. But it loses all connection with the original type. In other news, nowhere on Hackage (as downloaded sometime in the fall) is `splitPolyTyConApp` used. So maybe we just drop it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 14:35:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 14:35:37 -0000 Subject: [GHC] #11513: Work out when GADT parameters should be specified In-Reply-To: <047.8e435f63c64a501e9ed45a384456290b@haskell.org> References: <047.8e435f63c64a501e9ed45a384456290b@haskell.org> Message-ID: <062.f7a93ce4f072e82dcfcf524cc53ff0c6@haskell.org> #11513: Work out when GADT parameters should be specified -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 goldfire): {{{ data G a where MkG :: forall b a. b -> a -> G a }}} Currently, no wrapper is required here. Note that `G` is not a GADT. The worker has type `forall a b. b -> a -> G a`, with universals before existentials. Because we have no wrapper, the user sees the worker type. I'm proposing making a wrapper in this case. Does that clarify? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 14:43:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 14:43:08 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.1b420faa13bf95e568e2c6a50e7ca071@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > > These representations are handled as a bit of a special case. I need to > [sic] Ooh. It's like a mystery novel. :-) That was meant to say that I needed to take another careful look at the implementation surrounding the representations primitive type since it seems a bit fragile at the moment. > Other points: > - I vote only pattern synonyms. That sounds reasonable to me. > - Serialization is used in Cloud Haskell, no? Yes; it's also used in GHC (there is a `Binary` instance). I'm a bit unsure at the moment of what this should look like. > - I like the idea of including the paranoid checks as an option for paranoid users. Although perhaps not, given that I believe it's likelier for a cosmic ray to flip a bit than for the fingerprints to give a false positive. I'm not opposed to providing it, although it would be good to state clearly what our threat model is here. What guarantees are we trying to keep? This question seems to become rather hairy in the presence of serialization. > As for names: I think a proper migration story needs to be articulated. In a few years, I'd hate to have all these extra Ts lying around. Use a new module name for the new features and keep the old module with the old interface around? Maybe the new module can be Data.Reflection. I'm not sure the `T`s are necessarily bad given that the quantified `TypeRep` still serves a purpose. Especially in light of my proposal in comment:18 it seems like the `T` prefix could be a useful convention. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 14:47:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 14:47:20 -0000 Subject: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled In-Reply-To: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> References: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> Message-ID: <061.ba7c725ff277424014d28236134cccd1@haskell.org> #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): It's always been 100: [0b7e538a09bc958474ec704063eaa08836e9270e]. > why doesn't checkRecTc cut off the unwrapping? It *does* (or would if we run it long enough), but 100 is way too big in case of a type that's growing exponentially. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 14:54:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 14:54:14 -0000 Subject: [GHC] #11513: Work out when GADT parameters should be specified In-Reply-To: <047.8e435f63c64a501e9ed45a384456290b@haskell.org> References: <047.8e435f63c64a501e9ed45a384456290b@haskell.org> Message-ID: <062.33e0515b160f1daec6fd69ff936fc07a@haskell.org> #11513: Work out when GADT parameters should be specified -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 simonpj): Ah, now I see. You mean (unlike the example in the Description) when the user explicitly specifies the "wrong" order. Then let's make a wrapper! It'll get inlined away, and serves (as always) to interface the type the user wants to see with the one GHC uses internally. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 14:57:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 14:57:13 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.e52dcbc8f49dfb3ddee802da3c4cb704@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: ekmett, core-libraries-committee@? (added) Comment: It's clear that we'll continue to want bot a type-indexed and non-type- indexed representation. The only question is whether they are called * `TypeRep t`: type indexed * `TypeRepX`: non-indexed or * `TypeRepT t` or `TTypeRep t`: type indexed * `TypeRep`: non-indexed The latter has the merit of being more backward compatible. The former is nicer to my mind. Adding Edward and the Core Libraries Committee. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 16:40:11 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 16:40:11 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.8ef6cb63c68f8da3004af950a89ef20e@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mboes): * cc: mboes (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 17:02:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 17:02:18 -0000 Subject: [GHC] #8118: : commitAndReleaseBuffer: invalid argument (invalid character) In-Reply-To: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> References: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> Message-ID: <059.c8cdf6a73c55670df3e71e12147105ee@haskell.org> #8118: : commitAndReleaseBuffer: invalid argument (invalid character) -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #5666 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by HairyDude): Replying to [comment:9 RyanGlScott]: > > Also, I ''think'' this "fix" depends on if you're running from MSYS/Cygwin (where it's a sufficient fix) or `cmd.exe`/PowerShell (where it fixes the warning, put doesn't output the character correctly). Can you confirm what shell you're using? I'm using console2. But most of my program's output is to files, not the console. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 17:05:28 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 17:05:28 -0000 Subject: [GHC] #8118: : commitAndReleaseBuffer: invalid argument (invalid character) In-Reply-To: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> References: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> Message-ID: <059.0e4d8a9efaf04059a82f8d28c8fa840c@haskell.org> #8118: : commitAndReleaseBuffer: invalid argument (invalid character) -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #5666 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:10 HairyDude]: > I'm using console2. But most of my program's output is to files, not the console. I suppose I should be more specific. IIRC, you can run both `mintty` (which is what MSYS/Cygwin use) and `cmd.exe` (which PowerShell runs a variant of) from `console2`. Which particular one are you using from `console2`? And it shouldn't matter whether you're outputting to `stdout` or to files, you should still experience roughly the same errors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 17:06:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 17:06:18 -0000 Subject: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled In-Reply-To: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> References: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> Message-ID: <061.f6b914be1da94ab40e4fd75225e72583@haskell.org> #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:11 niteria]: > It's always been 100: [0b7e538a09bc958474ec704063eaa08836e9270e]. > No. Before that commit, `checkRecTc` allowed one unwrapping. The second failed (because the `TyCon` was in the `NameSet` nearby. But there's also a reference to the ticket that inspired the increase, which is helpful. I guess, in the end, we're never going to get this number correct. We could just have a flag for it, as suggested in the code there. Then, for this test, we use the flag. In the end, we're talking about a slowdown that affect only `DEBUG` compilers, yes? So I'm more worried about getting the test to pass before the end of the universe than in actually removing the exponential behavior -- especially given that the user's program indeed introduces the exponential behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 17:10:03 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 17:10:03 -0000 Subject: [GHC] #8118: : commitAndReleaseBuffer: invalid argument (invalid character) In-Reply-To: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> References: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> Message-ID: <059.5ab1da1ecda4ed7ca02777d62cd32542@haskell.org> #8118: : commitAndReleaseBuffer: invalid argument (invalid character) -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #5666 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by HairyDude): Oh, it's cmd.exe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 17:13:12 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 17:13:12 -0000 Subject: [GHC] #8118: : commitAndReleaseBuffer: invalid argument (invalid character) In-Reply-To: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> References: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> Message-ID: <059.2c14655f776148e603133e1b2927ae97@haskell.org> #8118: : commitAndReleaseBuffer: invalid argument (invalid character) -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #5666 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by HairyDude): Also I can confirm it does output correctly with `setLocaleEncoding utf8`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 17:13:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 17:13:53 -0000 Subject: [GHC] #8118: : commitAndReleaseBuffer: invalid argument (invalid character) In-Reply-To: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> References: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> Message-ID: <059.a37312bf5b464241b054f9f245ecd86f@haskell.org> #8118: : commitAndReleaseBuffer: invalid argument (invalid character) -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #5666 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): If it's `cmd.exe`, then I think `setLocaleEncoding utf8` isn't quite enough to both (1) make the error go away, and (2) actually render all Unicode characters correctly. (It might fix (1), but (2) is another question.) For example, what is the output of: {{{#!hs main = do setLocaleEncoding utf8 putStrLn "?" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 18:08:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 18:08:06 -0000 Subject: [GHC] #11511: Type family producing infinite type accepted as injective In-Reply-To: <048.97d84dbb372812585cd3199cfa06814f@haskell.org> References: <048.97d84dbb372812585cd3199cfa06814f@haskell.org> Message-ID: <063.3db291ea16f8f5407a65494cd9c41055@haskell.org> #11511: Type family producing infinite type accepted as injective -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: TypeFamilies, Resolution: | Injective Operating System: 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): > What bothers me is that we have no guarantee that FC types are indeed finite. On paper, we just define types inductively and are done with it. But how does this play out in the implementation? I suppose it might be possible to accidentally define an "infinite" type or coercion as a lazy value, but surely Core Lint would go into a loop when checking it? What other problems do you envisage? > Recall that infinite types have led to segfaults before: #8162. That's a slightly different issue: the type family overlap check was unsound because it treated `a` and `a -> a` as apart, even though `a ~ a -> a` is solvable in the presence of non-terminating type families. Crucially, it is possible to construct a ''finite'' proof of `a ~ a -> a` that contradicts the overlap check. Whereas in this case, the only "proofs" of `F Bool ~ F Char` are infinite (and hence non-constructible). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 18:36:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 18:36:01 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. Message-ID: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple UndecidableSuperClasses | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: #11480 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- There seems to be a bad interaction between `UndecidableSuperClasses` and the common trick of using a cyclic definition of a class and instance to make an alias at the constraint level: {{{#!hs class (Foo f, Bar f) => Baz f instance (Foo f, Bar f) => Baz f }}} Unfortunately, there are circumstances in which you can't eliminate it, such as {{{#!hs class (p, q) => p & q instance (p, q) => p & q }}} There we can't partially apply (,) at the constraint level, but we can talk about `(&) :: Constraint -> Constraint -> Constraint` and `(&) (Eq a) :: Constraint -> Constraint`. This doesn't seem to happen on simpler examples like the above, but once I modify the categories example from #11480 to move the domain and codomain of a functor into class associated types, so that they don't infect every single subclass of functor, we run into a problem. The following stripped down version of the code seems to send the compiler into an infinite loop: {{{#!hs {-# language KindSignatures #-} {-# language PolyKinds #-} {-# language DataKinds #-} {-# language TypeFamilies #-} {-# language RankNTypes #-} {-# language NoImplicitPrelude #-} {-# language FlexibleContexts #-} {-# language MultiParamTypeClasses #-} {-# language GADTs #-} {-# language ConstraintKinds #-} {-# language FlexibleInstances #-} {-# language TypeOperators #-} {-# language ScopedTypeVariables #-} {-# language DefaultSignatures #-} {-# language FunctionalDependencies #-} {-# language UndecidableSuperClasses #-} {-# language UndecidableInstances #-} {-# language TypeInType #-} import GHC.Types (Constraint, Type) import qualified Prelude type Cat i = i -> i -> Type newtype Y (p :: i -> j -> Type) (a :: j) (b :: i) = Y { getY :: p b a } class Vacuous (a :: i) instance Vacuous a class (Functor p, Dom p ~ Op p, Cod p ~ Nat p (->)) => Category (p :: Cat i) where type Op p :: Cat i type Op p = Y p type Ob p :: i -> Constraint type Ob p = Vacuous class (Category (Dom f), Category (Cod f)) => Functor (f :: i -> j) where type Dom f :: Cat i type Cod f :: Cat j class (Functor f, Dom f ~ p, Cod f ~ q) => Fun (p :: Cat i) (q :: Cat j) (f :: i -> j) | f -> p q instance (Functor f, Dom f ~ p, Cod f ~ q) => Fun (p :: Cat i) (q :: Cat j) (f :: i -> j) data Nat (p :: Cat i) (q :: Cat j) (f :: i -> j) (g :: i -> j) instance (Category p, Category q) => Category (Nat p q) where type Ob (Nat p q) = Fun p q instance (Category p, Category q) => Functor (Nat p q) where type Dom (Nat p q) = Y (Nat p q) type Cod (Nat p q) = Nat (Nat p q) (->) instance (Category p, Category q) => Functor (Nat p q f) where type Dom (Nat p q f) = Nat p q type Cod (Nat p q f) = (->) instance Category (->) instance Functor ((->) e) where type Dom ((->) e) = (->) type Cod ((->) e) = (->) instance Functor (->) where type Dom (->) = Y (->) type Cod (->) = Nat (->) (->) instance (Category p, Op p ~ Y p) => Category (Y p) where type Op (Y p) = p instance (Category p, Op p ~ Y p) => Functor (Y p a) where type Dom (Y p a) = Y p type Cod (Y p a) = (->) instance (Category p, Op p ~ Y p) => Functor (Y p) where type Dom (Y p) = p type Cod (Y p) = Nat (Y p) (->) }}} Here I need the circular definition of `Fun` to talk about the fact that the objects in the category of natural transformations from a category p to a category q are functors with domain p and codomain q, so to give the definition of the class-associated `type Ob (Nat p q)` I need such a cyclic definition. I can't leave the domain and codomain of `Functor` in fundeps, otherwise if I go to define a subclass of Functor I'd have to include the arguments, and I have a ''lot'' of those subclasses! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 18:53:03 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 18:53:03 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.15e63da70cf01ba70a32e916c9c5d9b7@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): (It apparently isn't infinite, the compiler eventually runs out of memory and crashes.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 19:47:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 19:47:53 -0000 Subject: [GHC] #11499: Loading temp shared object failed in GHCi In-Reply-To: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> References: <045.ae2a06a8cd91a2443aeaf738b9ee5413@haskell.org> Message-ID: <060.02df8c897ad4782eef1f43095ae90558@haskell.org> #11499: Loading temp shared object failed in GHCi -------------------------------------+------------------------------------- Reporter: alfa07 | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Resolution: | Keywords: dynamic | linking Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: 11238 | Blocking: Related Tickets: #10458 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by alfa07): Yeah, I suspected that the easy solution has some catches in the wider world (RTLD_GLOBAL). Thank you for looking at it Peter! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 20:39:03 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 20:39:03 -0000 Subject: [GHC] #11524: Something is amiss with quantification in pattern synonym type signatures Message-ID: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> #11524: Something is amiss with quantification in pattern synonym type signatures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 (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 GADTs #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE ExplicitForAll #-} {-# LANGUAGE PatternSynonyms #-} {-# LANGUAGE TypeInType #-} module Test where data AType (a :: k) where AMaybe :: AType Maybe AInt :: AType Int AApp :: forall k1 k2 (a :: k1 -> k2) (b :: k1). AType a -> AType b -> AType (a b) pattern PApp :: () => (fun ~ a b) => AType a -> AType b -> AType fun --pattern PApp :: forall k (fun :: k) k1 (a :: k1 -> k) (b :: k1). -- () => (fun ~ a b) => AType a -> AType b -> AType fun pattern PApp fun arg <- AApp fun arg }}} I would have thought that the two type signatures would be equivalent. However, when I use the quantified signature GHC complains with, {{{ hi.hs:14:34: error: ? Expected kind ?AType a?, but ?fun? has kind ?AType a1? ? In the declaration for pattern synonym ?PApp? ? Relevant bindings include arg :: AType b1 (bound at hi.hs:14:34) fun :: AType a1 (bound at hi.hs:14:30) }}} Moreover, if I use the un-quantified signature and ask GHCi for the full type signature, it gives me the precisely the quantified type that it rejected previously, {{{ ?> :info PApp pattern PApp :: forall k (fun :: k) k1 (a :: k1 -> k) (b :: k1). () => fun ~ a b => AType a -> AType b -> AType fun -- Defined at hi.hs:14:1 }}} Very odd. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 20:51:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 20:51:50 -0000 Subject: [GHC] #11524: Something is amiss with quantification in pattern synonym type signatures In-Reply-To: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> References: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> Message-ID: <061.aea8f12019110e33463ffff24f66951d@haskell.org> #11524: Something is amiss with quantification in pattern synonym type signatures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 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 goldfire): If I understand pattern signatures correctly, it's a bug in the pretty- printer. Here is the correct version with explicit quantification: {{{ pattern PApp :: forall k2 (fun :: k2). () => forall k1 (a :: k1 -> k2) (b :: k1). (fun ~ a b) => AType a -> AType b -> AType fun }}} Note that `k2` and `fun` are universal, while `k1`, `a`, and `b` are existential. And indeed this signature is accepted. Two problems remain: 1. That error message is unhelpful. I imagine we can do better. 2. The pretty-printer should put the existentials in the right spot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 21:11:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 21:11:26 -0000 Subject: [GHC] #11328: Auto complete in ghci shows $sel:function:Type for DuplicateRecordFields fields In-Reply-To: <047.e75a7fff6e231d461809a0fc09000e32@haskell.org> References: <047.e75a7fff6e231d461809a0fc09000e32@haskell.org> Message-ID: <062.58079fae5c7cb2647e86b346f858b6fb@haskell.org> #11328: Auto complete in ghci shows $sel:function:Type for DuplicateRecordFields fields -------------------------------------+------------------------------------- Reporter: kolmodin | Owner: adamgundry Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 8.0.1-rc1 Resolution: | Keywords: | DuplicateRecordFields, ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/should_run/T11328 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1870 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"dd0b7c78f64f2498594d3ef89d3bf884402f14d9/ghc" dd0b7c7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dd0b7c78f64f2498594d3ef89d3bf884402f14d9" Avoid mangled/derived names in GHCi autocomplete (fixes #11328) This changes `getRdrNamesInScope` to use field labels rather than selector names for fields from modules with `DuplicateRecordFields` enabled. Moreover, it filters out derived names (e.g. type representation bindings) that shouldn't show up in autocomplete. Test Plan: New test ghci/should_run/T11328 Reviewers: kolmodin, austin, bgamari, simonpj Reviewed By: bgamari, simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1870 GHC Trac Issues: #11328 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 21:26:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 21:26:17 -0000 Subject: [GHC] #11524: Something is amiss with quantification in pattern synonym type signatures In-Reply-To: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> References: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> Message-ID: <061.a438296861ddc8d87ca58df48a0eef89@haskell.org> #11524: Something is amiss with quantification in pattern synonym type signatures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 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 bgamari): * cc: niteria (added) Comment: > It's a bug in the pretty-printer. Actually, I'm not entirely sure that this is the whole story. After pulling I'm now seeing, {{{ $ inplace/bin/ghc-stage1 hi.hs [1 of 1] Compiling Main ( hi.hs, hi.o ) ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.1.20160124 for x86_64-unknown-linux): ASSERT failed! file compiler/types/TyCoRep.hs line 1919 in_scope InScope {k_aB4 k_aJd a_aJe b_aJf} tenv [auE :-> a_aJe[tau:5], auF :-> b_aJf[tau:5], aB3 :-> k_aJd[tau:5]] cenv [] tys [fun_auD[sk] ~ a_auE[sk] b_auF[sk]] cos [] needInScope [auD :-> fun_auD[sk], aB4 :-> k_aB4[tau:1]] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Presumably this is niteria's in-scope set checks in action. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 21:45:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 21:45:29 -0000 Subject: [GHC] #11525: Using a dummy typechecker plugin causes an ambiguity check error Message-ID: <042.ec775bcbbb96ef3ddf90f6d58883ad88@haskell.org> #11525: Using a dummy typechecker plugin causes an ambiguity check error -------------------------------------+------------------------------------- Reporter: jme | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 (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: -------------------------------------+------------------------------------- The following variation on [[GhcFile(testsuite/tests/typecheck/should_compile/T10009.hs)]] compiles cleanly: {{{#!hs {-# LANGUAGE TypeFamilies, ScopedTypeVariables #-} {-# OPTIONS_GHC -fno-warn-redundant-constraints #-} module T10009WithClass where type family F a type family UnF a class (UnF (F b) ~ b) => C b where f :: F b -> () g :: forall a. (C a) => a -> () g _ = f (undefined :: F a) }}} But compiling it with the dummy typechecker plugin [[GhcFile(testsuite/tests/typecheck/should_compile/T11462_Plugin.hs)]] yields {{{ $ ghc -dynamic -c T11462_Plugin.hs $ ghc -fplugin=T11462_Plugin -dynamic -c T10009WithClass.hs T10009WithClass.hs:10:5: error: - Could not deduce: F b0 ~ F b from the context: C b bound by the type signature for: f :: C b => F b -> () at T10009WithClass.hs:10:5-18 NB: 'F' is a type function, and may not be injective The type variable 'b0' is ambiguous Expected type: F b -> () Actual type: F b0 -> () - In the ambiguity check for 'f' To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the class method: f :: forall b. C b => F b -> () In the class declaration for 'C' }}} Superficially, the problem is that the presence of the plugin causes `runTcPluginsWanted` to zonk the pending superclass constraint, changing it to a `CNonCanonical`. This in turn prevents `solveWanteds` from making any further progress (which ultimately leads to the error): {{{ getUnsolvedInerts tv eqs = {[W] hole{aIO} :: s_aIL[fuv:2] GHC.Prim.~# fsk_aIC[fsk] (CTyEqCan)} fun eqs = {[W] hole{aIM} :: F b_aIu[tau:3] GHC.Prim.~# s_aIL[fuv:2] (CFunEqCan)} insols = {} others = {[W] $dC_aIv :: C b_aIu[tau:3] (CDictCan(psc))} <===== BEFORE plugin implics = {} Unflattening {Funeqs = [W] hole{aIM} :: F b_aIu[tau:3] GHC.Prim.~# s_aIL[fuv:2] (CFunEqCan) Tv eqs = [W] hole{aIO} :: s_aIL[fuv:2] GHC.Prim.~# fsk_aIC[fsk] (CTyEqCan)} Filling coercion hole aIM := _N unflattenFmv s_aIL[fuv:2] := F b_aIu[tau:3] writeMetaTyVar s_aIL[fuv:2] :: * := F b_aIu[tau:3] Unflattening 1 {} Unflattening 2 {[W] hole{aIO} :: s_aIL[fuv:2] GHC.Prim.~# fsk_aIC[fsk] (CTyEqCan)} Unflattening 3 {} Unflattening done {[W] hole{aIO} :: s_aIL[fuv:2] GHC.Prim.~# fsk_aIC[fsk] (CNonCanonical)} zonkSimples done: {[W] hole{aIO} :: F b_aIu[tau:3] GHC.Prim.~# F b_aIs[sk] (CNonCanonical)} zonkSimples done: {[W] $dC_aIv :: C b_aIu[tau:3] (CNonCanonical), <===== AFTER plugin [W] hole{aIO} :: F b_aIu[tau:3] GHC.Prim.~# F b_aIs[sk] (CNonCanonical)} solveSimples end } iterations = 1 residual = WC {wc_simple = [W] $dC_aIv :: C b_aIu[tau:3] (CNonCanonical) [W] hole{aIO} :: F b_aIu[tau:3] GHC.Prim.~# F b_aIs[sk] (CNonCanonical)} solveWanteds } }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 22:56:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 22:56:39 -0000 Subject: [GHC] #11524: Something is amiss with quantification in pattern synonym type signatures In-Reply-To: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> References: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> Message-ID: <061.3e40c5e961c39fab8b5191aa40542a9e@haskell.org> #11524: Something is amiss with quantification in pattern synonym type signatures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 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 niteria): Better trace with `ghc-stage2`: {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160128 for x86_64-unknown-linux): ASSERT failed! CallStack (from ImplicitParams): assertPprPanic, called at compiler/types/TyCoRep.hs:1932:51 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:1981:17 in ghc:TyCoRep substTys, called at compiler/types/TyCoRep.hs:2002:14 in ghc:TyCoRep substTheta, called at compiler/typecheck/TcPatSyn.hs:254:57 in ghc:TcPatSyn in_scope InScope {k_aB3 k_aB8 a_aB9 b_aBa} tenv [auD :-> a_aB9[tau:5], auE :-> b_aBa[tau:5], aB2 :-> k_aB8[tau:5]] cenv [] tys [fun_auC[sk] ~ a_auD[sk] b_auE[sk]] cos [] needInScope [auC :-> fun_auC[sk], aB3 :-> k_aB3[tau:1]] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 1 23:25:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 01 Feb 2016 23:25:41 -0000 Subject: [GHC] #11525: Using a dummy typechecker plugin causes an ambiguity check error In-Reply-To: <042.ec775bcbbb96ef3ddf90f6d58883ad88@haskell.org> References: <042.ec775bcbbb96ef3ddf90f6d58883ad88@haskell.org> Message-ID: <057.3a7597985a45e17bc2f721dfb3729872@haskell.org> #11525: Using a dummy typechecker plugin causes an ambiguity check error -------------------------------------+------------------------------------- Reporter: jme | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc1 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: | -------------------------------------+------------------------------------- Description changed by jme: @@ -61,1 +61,0 @@ - plugin @@ -83,1 +82,0 @@ - plugin New description: The following variation on [[GhcFile(testsuite/tests/typecheck/should_compile/T10009.hs)]] compiles cleanly: {{{#!hs {-# LANGUAGE TypeFamilies, ScopedTypeVariables #-} {-# OPTIONS_GHC -fno-warn-redundant-constraints #-} module T10009WithClass where type family F a type family UnF a class (UnF (F b) ~ b) => C b where f :: F b -> () g :: forall a. (C a) => a -> () g _ = f (undefined :: F a) }}} But compiling it with the dummy typechecker plugin [[GhcFile(testsuite/tests/typecheck/should_compile/T11462_Plugin.hs)]] yields {{{ $ ghc -dynamic -c T11462_Plugin.hs $ ghc -fplugin=T11462_Plugin -dynamic -c T10009WithClass.hs T10009WithClass.hs:10:5: error: - Could not deduce: F b0 ~ F b from the context: C b bound by the type signature for: f :: C b => F b -> () at T10009WithClass.hs:10:5-18 NB: 'F' is a type function, and may not be injective The type variable 'b0' is ambiguous Expected type: F b -> () Actual type: F b0 -> () - In the ambiguity check for 'f' To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the class method: f :: forall b. C b => F b -> () In the class declaration for 'C' }}} Superficially, the problem is that the presence of the plugin causes `runTcPluginsWanted` to zonk the pending superclass constraint, changing it to a `CNonCanonical`. This in turn prevents `solveWanteds` from making any further progress (which ultimately leads to the error): {{{ getUnsolvedInerts tv eqs = {[W] hole{aIO} :: s_aIL[fuv:2] GHC.Prim.~# fsk_aIC[fsk] (CTyEqCan)} fun eqs = {[W] hole{aIM} :: F b_aIu[tau:3] GHC.Prim.~# s_aIL[fuv:2] (CFunEqCan)} insols = {} others = {[W] $dC_aIv :: C b_aIu[tau:3] (CDictCan(psc))} <===== BEFORE implics = {} Unflattening {Funeqs = [W] hole{aIM} :: F b_aIu[tau:3] GHC.Prim.~# s_aIL[fuv:2] (CFunEqCan) Tv eqs = [W] hole{aIO} :: s_aIL[fuv:2] GHC.Prim.~# fsk_aIC[fsk] (CTyEqCan)} Filling coercion hole aIM := _N unflattenFmv s_aIL[fuv:2] := F b_aIu[tau:3] writeMetaTyVar s_aIL[fuv:2] :: * := F b_aIu[tau:3] Unflattening 1 {} Unflattening 2 {[W] hole{aIO} :: s_aIL[fuv:2] GHC.Prim.~# fsk_aIC[fsk] (CTyEqCan)} Unflattening 3 {} Unflattening done {[W] hole{aIO} :: s_aIL[fuv:2] GHC.Prim.~# fsk_aIC[fsk] (CNonCanonical)} zonkSimples done: {[W] hole{aIO} :: F b_aIu[tau:3] GHC.Prim.~# F b_aIs[sk] (CNonCanonical)} zonkSimples done: {[W] $dC_aIv :: C b_aIu[tau:3] (CNonCanonical), <===== AFTER [W] hole{aIO} :: F b_aIu[tau:3] GHC.Prim.~# F b_aIs[sk] (CNonCanonical)} solveSimples end } iterations = 1 residual = WC {wc_simple = [W] $dC_aIv :: C b_aIu[tau:3] (CNonCanonical) [W] hole{aIO} :: F b_aIu[tau:3] GHC.Prim.~# F b_aIs[sk] (CNonCanonical)} solveWanteds } }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 00:03:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 00:03:54 -0000 Subject: [GHC] #11524: Something is amiss with quantification in pattern synonym type signatures In-Reply-To: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> References: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> Message-ID: <061.fcb59872adbe38359b12ed583a7f897e@haskell.org> #11524: Something is amiss with quantification in pattern synonym type signatures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 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): Phab:D1879 Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * status: new => patch * differential: => Phab:D1879 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 02:50:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 02:50:54 -0000 Subject: [GHC] #11524: Something is amiss with quantification in pattern synonym type signatures In-Reply-To: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> References: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> Message-ID: <061.a02907a90c9725f540b66776d604d710@haskell.org> #11524: Something is amiss with quantification in pattern synonym type signatures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 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): Phab:D1879 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): NB: niteria's (quite necessary) patch does not fix the main issue reported up top. When that patch is merged, we still can't close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 07:51:12 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 07:51:12 -0000 Subject: [GHC] #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" In-Reply-To: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> References: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> Message-ID: <059.6b2a4a2f9538c75e12dd03d7ad12ba71@haskell.org> #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): After adding the required role annotation to `Serializable`, this works: {{{#!hs instance (Typeable a, SC (Serializable a)) => SC (Serializable (MyList a)) where dict = coerce (dict :: Static (Dict (Serializable [a]))) }}} but the standalone deriving clause still gives the same error as reported above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 07:51:51 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 07:51:51 -0000 Subject: [GHC] #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" In-Reply-To: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> References: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> Message-ID: <059.09100bda58fb0357c60712974cec203e@haskell.org> #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): Incidentally, when `Serializable` has a nominal role, that call to `coerce` is rejected by ghc 8.0 with {{{ Bug.hs:70:10: error: ? Couldn't match type ?[a]? with ?MyList a? arising from a use of ?coerce? ? In the expression: coerce (dict :: Static (Dict (Serializable [a]))) In an equation for ?dict?: dict = coerce (dict :: Static (Dict (Serializable [a]))) In the instance declaration for ?SC (Serializable (MyList a))? ? Relevant bindings include dict :: Static (Dict (Serializable (MyList a))) (bound at Bug.hs:70:3) }}} which I found somewhat confusing; "Couldn't match type `[a]` with `MyList a` arising from a use of `coerce`" isn't very obvious; ghc 7.10.3 here is much much clearer: {{{ Bug.hs:70:10: Couldn't match type ?MyList a? with ?[a]? arising from trying to show that the representations of ?Static (Dict (Serializable [a]))? and ?Static (Dict (Serializable (MyList a)))? are the same Relevant role signatures: type role [] representational type role MyList representational type role Dict representational type role Static representational type role Serializable nominal Relevant bindings include dict :: Static (Dict (Serializable (MyList a))) (bound at Bug.hs:70:3) In the expression: coerce (dict :: Static (Dict (Serializable [a]))) In an equation for ?dict?: dict = coerce (dict :: Static (Dict (Serializable [a]))) In the instance declaration for ?SC (Serializable (MyList a))? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 07:53:32 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 07:53:32 -0000 Subject: [GHC] #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" In-Reply-To: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> References: <044.9bb7684b16ac275a0fe9a3a2ff387003@haskell.org> Message-ID: <059.7a8e6fd6c24a2264816669cf558753cc@haskell.org> #11509: Incorrect error message in StandaloneDeriving: "The data constructors of are not all in scope" -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by edsko): * Attachment "Bug11509.hs" added. Test case with some CPP to make it work with 7.10 and 8.0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 07:59:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 07:59:25 -0000 Subject: [GHC] #11526: unsafeLookupStaticPtr should not live in IO Message-ID: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> #11526: unsafeLookupStaticPtr should not live in IO -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc1 Keywords: | 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.StaticPtr` provides {{{#!hs unsafeLookupStaticPtr :: StaticKey -> IO (Maybe (StaticPtr a)) }}} I don't think this function should live in IO. It is morally pure (the SPT that it needs to access is static for the duration of the program after all) and when this lives in IO this function cannot be used in `Binary` instances (without using `unsafePerformIO`, obviously). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 08:21:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 08:21:31 -0000 Subject: [GHC] #11100: Remote GHCi In-Reply-To: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> References: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> Message-ID: <062.a684628ac0708576b4a4db7d47809b40@haskell.org> #11100: Remote GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11047, #8736 | Differential Rev(s): Phab:D1562 Wiki Page: | Phab:D1747 Phab:D1748 Phab:D1836 -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"2fb6a8c30567e7d071ffcf88e22ea7f72f60b826/ghc" 2fb6a8c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2fb6a8c30567e7d071ffcf88e22ea7f72f60b826" Remote GHCi: Optimize the serialization/deserialization of byte code Summary: This cuts allocations by about a quarter. Test Plan: * validate * `ghci -fexternal-interpreter` in `nofib/real/anna` Reviewers: niteria, bgamari, ezyang, austin, hvr, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1875 GHC Trac Issues: #11100 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 08:21:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 08:21:31 -0000 Subject: [GHC] #11100: Remote GHCi In-Reply-To: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> References: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> Message-ID: <062.0798abb8396350056da548a721889e57@haskell.org> #11100: Remote GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11047, #8736 | Differential Rev(s): Phab:D1562 Wiki Page: | Phab:D1747 Phab:D1748 Phab:D1836 -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"7cb1fae2d6ec90b10708a2631cd1069561177bd4/ghc" 7cb1fae2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7cb1fae2d6ec90b10708a2631cd1069561177bd4" Remote GHCi: batch the creation of strings Summary: This makes a big performance difference especially when loading a large number of modules and using parallel compilation (ghci -jN). Test Plan: * validate * `ghci -fexternal-interpreter` in `nofib/real/anna` Reviewers: niteria, bgamari, ezyang, austin, hvr, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1876 GHC Trac Issues: #11100 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 08:21:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 08:21:31 -0000 Subject: [GHC] #11100: Remote GHCi In-Reply-To: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> References: <047.346d10a0114be8596e5485c83dbed9dd@haskell.org> Message-ID: <062.d0fc7e64ed6b3d8f5e8ae5a7128dea52@haskell.org> #11100: Remote GHCi -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11047, #8736 | Differential Rev(s): Phab:D1562 Wiki Page: | Phab:D1747 Phab:D1748 Phab:D1836 -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"c996db5b1802ebeb93420785127f7fd55b7ec0c0/ghc" c996db5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c996db5b1802ebeb93420785127f7fd55b7ec0c0" Remote GHCi: parallelise BCO serialization Summary: Serialization of BCOs is slow, but we can parallelise it when using ghci -j. It parallelises nicely, saving multiple seconds off the link time in a large example I have. Test Plan: * validate * `ghci -fexternal-interpreter` in `nofib/real/anna` Reviewers: niteria, bgamari, ezyang, austin, hvr, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1877 GHC Trac Issues: #11100 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 09:47:56 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 09:47:56 -0000 Subject: [GHC] #11354: Install script installs docs without -version suffix In-Reply-To: <043.018901061c911df7ad296ca4936d7024@haskell.org> References: <043.018901061c911df7ad296ca4936d7024@haskell.org> Message-ID: <058.a1fd890f5c98c228b88bf6235507bdb2@haskell.org> #11354: Install script installs docs without -version suffix -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.0.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:D1868 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: This sounds quite reasonable to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 09:48:56 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 09:48:56 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.1474417c45a8a5fe0c060951bcfe909a@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Up until now we seem to have been focused on getting the `Typeable` internals "right" rather than compatible. Fortunately, the vast majority of users of `Typeable` limit themselves to `deriving` and to `cast`, so whatever you do to the internals affects very few users. If you like the `TypeRep t` and `TypeRepX` convention, then I'd say go for it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 11:01:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 11:01:54 -0000 Subject: [GHC] #11527: Pattern match translation suboptimal Message-ID: <047.fde14f3a46e0c8f9e9764d2f5559e6f1@haskell.org> #11527: Pattern match translation suboptimal -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Compile the following code and look at the (sad) intermediate code: {{{ baz :: Integer -> Int -> Int baz 10 1 = 1 baz 20 1 = 2 baz 10 2 = 2 baz 20 2 = 3 baz 10 3 = 1 baz 20 3 = 2 baz 10 4 = 2 baz 20 4 = 3 baz _ _ = 0 }}} The pattern match compiler has not rearranged the clauses, and so it produces an 8 level deep nested test. Now change the type signature to {{{ baz :: Int -> Int -> Int }}} Now the pattern match compiler does its job and rearranges the clauses to make the tests 2 levels deep. The same phenomenon happens when matching string literals. For the predefined String type the right thing happens, but for some other string type (using OverloadedStrings) it doesn't. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 11:07:12 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 11:07:12 -0000 Subject: [GHC] #8746: Crosscompiling In-Reply-To: <049.1228fc07cede4b1619c6ff70ac264add@haskell.org> References: <049.1228fc07cede4b1619c6ff70ac264add@haskell.org> Message-ID: <064.26a934100b50d28323ee21e1c1978ca1@haskell.org> #8746: Crosscompiling -------------------------------------+------------------------------------- Reporter: Visionstar | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.8.1-rc1 Resolution: | Keywords: Crosscompile | cross compile failed ncurses | setupterm not found Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => new * resolution: invalid => Comment: I'd like to keep this one open. Users shouldn't have to comment out `terminfo` in the build system. That is something we can fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 11:16:38 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 11:16:38 -0000 Subject: [GHC] #11524: Something is amiss with quantification in pattern synonym type signatures In-Reply-To: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> References: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> Message-ID: <061.714b6d608d49e226e87533fcf225ccb1@haskell.org> #11524: Something is amiss with quantification in pattern synonym type signatures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | PatternSynonyms 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:D1879 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * keywords: => PatternSynonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 11:41:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 11:41:01 -0000 Subject: [GHC] #11526: unsafeLookupStaticPtr should not live in IO In-Reply-To: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> References: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> Message-ID: <059.99f4811a0aadc97ebb7454800be69335@haskell.org> #11526: unsafeLookupStaticPtr should not live in IO -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: 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: facundo.dominguez, mboes, ekmett (added) * component: Compiler => Core Libraries * milestone: => 8.0.1 Comment: If we want to make this change let's try to get it in to 8.0 before static pointers go into wide use. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 12:19:53 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 12:19:53 -0000 Subject: [GHC] #11526: unsafeLookupStaticPtr should not live in IO In-Reply-To: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> References: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> Message-ID: <059.64295c368269e7fe7faa993d0a32c593@haskell.org> #11526: unsafeLookupStaticPtr should not live in IO -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): {{{unsafeLookupStaticPtr}}} is not pure since the RTS can load code dynamically. Calling the function at different times of execution can yield different results. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 12:23:53 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 12:23:53 -0000 Subject: [GHC] #11526: unsafeLookupStaticPtr should not live in IO In-Reply-To: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> References: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> Message-ID: <059.42fc5c67c677f2ff30bc319769a85bb4@haskell.org> #11526: unsafeLookupStaticPtr should not live in IO -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): That kind of violates the whole idea of a _static_ reference to something surely? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 12:36:53 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 12:36:53 -0000 Subject: [GHC] #11526: unsafeLookupStaticPtr should not live in IO In-Reply-To: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> References: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> Message-ID: <059.3921e627c78e4a4e74b0b2dd11485b4e@haskell.org> #11526: unsafeLookupStaticPtr should not live in IO -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): {{{unsafeLookupStaticPtr}}} could be made pure if the program is forbidden from loading code dynamically. That probably will have all code depending indirectly on static pointers to work awkwardly in GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 12:52:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 12:52:39 -0000 Subject: [GHC] #10343: Make Typeable track kind information better In-Reply-To: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> References: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> Message-ID: <060.e8f80f23291fe1e06a045aef8c4f1f90@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: typeOf :: | Typeable (a::k) => Proxy a -> | TypeRep Blocked By: | Blocking: Related Tickets: #9858 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Typeable -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 12:53:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 12:53:03 -0000 Subject: [GHC] #10163: Export typeRepKinds in Data.Typeable In-Reply-To: <050.0f516dbc0c2490108f1b7d3eb58e3bb7@haskell.org> References: <050.0f516dbc0c2490108f1b7d3eb58e3bb7@haskell.org> Message-ID: <065.d5734799401488418d70020f9d1d1dc1@haskell.org> #10163: Export typeRepKinds in Data.Typeable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1-rc3 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => Typeable -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 12:54:27 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 12:54:27 -0000 Subject: [GHC] #11349: [TypeApplications] Create Proxy-free alternatives of functions in base In-Reply-To: <051.287da149b49626768faa704af8139943@haskell.org> References: <051.287da149b49626768faa704af8139943@haskell.org> Message-ID: <066.72eb2be650629f1491e15c4bf7488fc2@haskell.org> #11349: [TypeApplications] Create Proxy-free alternatives of functions in base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: | TypeApplications, TypeRep Operating System: Other | 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 => TypeApplications, TypeRep -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 12:55:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 12:55:43 -0000 Subject: [GHC] #11526: unsafeLookupStaticPtr should not live in IO In-Reply-To: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> References: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> Message-ID: <059.1773bb2c176ed3c49ca7c6d310de0f97@haskell.org> #11526: unsafeLookupStaticPtr should not live in IO -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Hmm. I'm deeply suspicious of `StaticKey`. It plays no role in our plan of record [wiki:StaticPointers]. If we don't have `StaticKey` the whole issue doesn't arise. I'd love to have a proper debate about [wiki:StaticPointers], based on successful execution of #11011. Would anyone like to lead on it? Meanwhile, I doubt we should mess with `unsafeLookupStaticPtr`, since other changes are in train. > If we want to make this change let's try to get it in to 8.0 before static pointers go into wide use. I think `StaticPtr` is in 7.10, isn't it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 12:59:13 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 12:59:13 -0000 Subject: [GHC] #11349: [TypeApplications] Create Proxy-free alternatives of functions in base In-Reply-To: <051.287da149b49626768faa704af8139943@haskell.org> References: <051.287da149b49626768faa704af8139943@haskell.org> Message-ID: <066.09986d790fb43b9a5447b674b306804f@haskell.org> #11349: [TypeApplications] Create Proxy-free alternatives of functions in base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: | TypeApplications, Typeable Operating System: Other | 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, TypeRep => TypeApplications, Typeable -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 13:03:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 13:03:19 -0000 Subject: [GHC] #11524: Something is amiss with quantification in pattern synonym type signatures In-Reply-To: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> References: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> Message-ID: <061.88bcc509347db1406164138b9ebd74cc@haskell.org> #11524: Something is amiss with quantification in pattern synonym type signatures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | PatternSynonyms 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:D1879 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Bartosz Nitka ): In [changeset:"07ed24132ebe62aab15f14a655506decdf252ff9/ghc" 07ed2413/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="07ed24132ebe62aab15f14a655506decdf252ff9" Use a correct substitution in tcCheckPatSynDecl The `substTheta` call didn't have the free variables of the `prov_theta` in the `in_scope` set. It should be enough to add `univ_tvs`, as all the `ex_tvs` are already in the domain of the substitution. Test Plan: added a testcase Reviewers: simonpj, bgamari, goldfire, austin Reviewed By: simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1879 GHC Trac Issues: #11524 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 13:04:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 13:04:25 -0000 Subject: [GHC] #11524: Something is amiss with quantification in pattern synonym type signatures In-Reply-To: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> References: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> Message-ID: <061.c69e979a7bf1fe3d89981c9c2b649c77@haskell.org> #11524: Something is amiss with quantification in pattern synonym type signatures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | PatternSynonyms 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:D1879 Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * status: patch => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 13:10:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 13:10:44 -0000 Subject: [GHC] #11527: Pattern match translation suboptimal In-Reply-To: <047.fde14f3a46e0c8f9e9764d2f5559e6f1@haskell.org> References: <047.fde14f3a46e0c8f9e9764d2f5559e6f1@haskell.org> Message-ID: <062.a02e42ceceaec3d93fe703a6d858ac3a@haskell.org> #11527: Pattern match translation suboptimal -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): For `Integer` I agree we could and should do better. But what about {{{ baz :: (Num a) => a -> Int -> Int }}} which is what you'll get if you don't have a type signature. The report specifies something like this: {{{ baz n x | n == fromInteger 10, x == 1 = 1 | n == fromInteger 20, x == 1 = 2 | n == fromInteger 10, x == 2 = 2 ...etc... }}} Now you might think that we can common up all those tests for `n == fromInteger 10` to get {{{ baz n x | n == fromInteger 10 = case x of 1 -> 1 2 -> 2 ... etc ... | n == fromInteger 20 = ...etc.. }}} But what if both `n == fromInteger 10` and `n == fromInteger 20` are ''both true''? Now it's not OK to group together all the matches against 10. How annoying! The best we can do is to do CSE on those `fromInteger` calls. It's all very irritating but I don't see how to do better. Except for `Integer` when we know that the `Num` instance has good properties. Is that particular case worth improving? Perhaps, and it would not be hard -- I can offer guidance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 13:13:46 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 13:13:46 -0000 Subject: [GHC] #11526: unsafeLookupStaticPtr should not live in IO In-Reply-To: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> References: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> Message-ID: <059.82c6e1d37ffedc594bea602c0501d3e4@haskell.org> #11526: unsafeLookupStaticPtr should not live in IO -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by edsko): > Hmm. I'm deeply suspicious of `StaticKey` . It plays no role in our plan of record StaticPointers. If we don't have `StaticKey` the whole issue doesn't arise. `StaticKey` is a low-level implementation detail. I have just added support for static pointers to the existing `distributed-static` package, based on the support for static pointers that exists in ghc today. The higher level API that `distributed-static` exposes is simply that `Static a` has a `Binary` instance (for `Typeable a`). But this is precisely where the problem is: if looking up a static pointer is not pure, then we cannot give a `Binary` instance. Facundo's objection is that in fact looking up a static pointer ''isn't'' pure. If that is true, then `unsafeLookupStaticPtr` should indeed live in IO, but then not having `StaticKey` is not going to solve the problem, it's just going to move it: whatever shape the decoder of `Static` takes (`Binary` instance, separate function, ...) will have to deal with it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 13:14:33 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 13:14:33 -0000 Subject: [GHC] #10163: Export typeRepKinds in Data.Typeable In-Reply-To: <050.0f516dbc0c2490108f1b7d3eb58e3bb7@haskell.org> References: <050.0f516dbc0c2490108f1b7d3eb58e3bb7@haskell.org> Message-ID: <065.6d245105608c7f089f2bc2108e9cc8dd@haskell.org> #10163: Export typeRepKinds in Data.Typeable -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1-rc3 Resolution: | Keywords: Typeable Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 13:30:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 13:30:03 -0000 Subject: [GHC] #11524: Something is amiss with quantification in pattern synonym type signatures In-Reply-To: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> References: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> Message-ID: <061.afb54119fa61a14eed7d30272e497d15@haskell.org> #11524: Something is amiss with quantification in pattern synonym type signatures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | PatternSynonyms 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:D1879 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Could someone fix the pretty-printer (comment:1)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 13:37:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 13:37:26 -0000 Subject: [GHC] #8118: : commitAndReleaseBuffer: invalid argument (invalid character) In-Reply-To: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> References: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> Message-ID: <059.2edda0fe04f708ef6ee1df90e2202315@haskell.org> #8118: : commitAndReleaseBuffer: invalid argument (invalid character) -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #5666 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by HairyDude): Ah... {{{ C:\Users\Peter\Documents\hacking>stack ghc -- test.hs -o test Run from outside a project, using implicit global project config Using resolver: lts-4.2 from implicit global project's config file: C:\Users\Peter\Documents\hacking\stack\global-project\stack.yaml [1 of 1] Compiling Main ( test.hs, test.o ) Linking test.exe ... C:\Users\Peter\Documents\hacking>test.exe ??? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 13:43:20 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 13:43:20 -0000 Subject: [GHC] #11526: unsafeLookupStaticPtr should not live in IO In-Reply-To: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> References: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> Message-ID: <059.2de141c291e4a92d47f38d44768ebfd6@haskell.org> #11526: unsafeLookupStaticPtr should not live in IO -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I agree that the problem would just move. I don't know what to do about the dynamic-linking thing. It looks as though ''whether'' you can deserialise a `ByteString` depends on ''when'' you try to deserialise it, and whether some blob of code has been dynamically linked. Ugh! Any suggestions? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 13:47:30 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 13:47:30 -0000 Subject: [GHC] #11527: Pattern match translation suboptimal In-Reply-To: <047.fde14f3a46e0c8f9e9764d2f5559e6f1@haskell.org> References: <047.fde14f3a46e0c8f9e9764d2f5559e6f1@haskell.org> Message-ID: <062.cbe12c0d8289a5adc52df34808f555d6@haskell.org> #11527: Pattern match translation suboptimal -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by augustss): I agree that in general we can't rearrange the tests. Unfortunately, this means that using your own string type instead of String can be quite costly if you do pattern matching (that's actually my use case). Since we can't assume that the compiler can deduce the necessary property, I suggest we add some way to convey the information. Some different ways: * Annotation on the Eq instance to say that it is sane. * Annotation on the case expression to say that we want more aggressive reordering. * A compiler flag that says we want more aggressive reordering. An annotation on the Eq instance seems like the nicest option. I'm quite keen to minimize the performance penalty for using a different string type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 13:49:47 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 13:49:47 -0000 Subject: [GHC] #11527: Pattern match translation suboptimal In-Reply-To: <047.fde14f3a46e0c8f9e9764d2f5559e6f1@haskell.org> References: <047.fde14f3a46e0c8f9e9764d2f5559e6f1@haskell.org> Message-ID: <062.c0e6fd80fe564560bc867e450c0ed25c@haskell.org> #11527: Pattern match translation suboptimal -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by augustss): Or maybe the annotation should be on the type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 14:02:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 14:02:05 -0000 Subject: [GHC] #10284: Create a dedicated `TypeError` exception type In-Reply-To: <047.839fde5ec581c7ee24adc8fc2d4d35b0@haskell.org> References: <047.839fde5ec581c7ee24adc8fc2d4d35b0@haskell.org> Message-ID: <062.dc8060b2f06273f6882768b0c2a0dbe9@haskell.org> #10284: Create a dedicated `TypeError` exception type -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: kanetw Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_run/T10284 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D866 -------------------------------------+------------------------------------- Comment (by RyanGlScott ): In [changeset:"a7ad0b91e7dace173ed95f31b221628d50c175e8/ghc" a7ad0b9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a7ad0b91e7dace173ed95f31b221628d50c175e8" Make TypeError a newtype, add changelog entry Summary: Phab:D866 added the `TypeError` datatype to `Control.Exception` to represent the error that is thrown when `-fdefer-type-errors` is on, but a changelog entry for it was never added. In addition, it should probably be a newtype. Reviewers: austin, hvr, KaneTW, bgamari Reviewed By: KaneTW, bgamari Subscribers: thomie, KaneTW Differential Revision: https://phabricator.haskell.org/D1873 GHC Trac Issues: #10284 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 14:08:33 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 14:08:33 -0000 Subject: [GHC] #8118: : commitAndReleaseBuffer: invalid argument (invalid character) In-Reply-To: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> References: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> Message-ID: <059.dd5f248dc1c4310c8f63ea5eefcf6e09@haskell.org> #8118: : commitAndReleaseBuffer: invalid argument (invalid character) -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #5666 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): OK, thank you for confirming. As I [https://ghc.haskell.org/trac/ghc/ticket/7593#comment:6 noted] in #7593, just changing the encoding to `utf8` is a sufficient fix for `mintty`, but it's not enough for `cmd.exe`. For the latter, the only solution I've found was to use native Windows console API functions such as `WriteConsoleW` and `ReadConsoleW`. This only works for `stdin`/`stdout`, though, and not general file IO. I imagine it would be a pretty significant time investment redesigning Haskell IO to use Windows API calls everywhere, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 14:14:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 14:14:22 -0000 Subject: [GHC] #8118: : commitAndReleaseBuffer: invalid argument (invalid character) In-Reply-To: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> References: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> Message-ID: <059.1dc127649d10cfd48272e8467f19e06b@haskell.org> #8118: : commitAndReleaseBuffer: invalid argument (invalid character) -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #5666 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by HairyDude): This gets correct output: {{{ import GHC.IO.Encoding import System.Win32.Console main = do ... setLocaleEncoding utf8 setCOnsoleOutputCP 65001 ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 15:05:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 15:05:49 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.15bc453bd8384cfcc3dde0e18d196183@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think we can have our cake and eat it too. Just use a new module name and then we can have `Data.Typeable.TypeRep` be different from `Data.Reflection.TypeRep`. (Of course, we can keep just one `Typeable`, happily.) I vastly prefer `TypeRep` and `TypeRepX` over `TTypeRep` and `TypeRep`. But I have no great reason for doing so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 15:20:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 15:20:05 -0000 Subject: [GHC] #11452: Typed Template Haskell sneakily allows impredicativity In-Reply-To: <047.95df7be3b6fa11a240e8f4b3bd1fc5a1@haskell.org> References: <047.95df7be3b6fa11a240e8f4b3bd1fc5a1@haskell.org> Message-ID: <062.a76bfbde33b34e16fc948e2efa8f184b@haskell.org> #11452: Typed Template Haskell sneakily allows impredicativity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T11452 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 15:48:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 15:48:14 -0000 Subject: [GHC] #11527: Pattern match translation suboptimal In-Reply-To: <047.fde14f3a46e0c8f9e9764d2f5559e6f1@haskell.org> References: <047.fde14f3a46e0c8f9e9764d2f5559e6f1@haskell.org> Message-ID: <062.9abeb3bd5bf2989ccfe47ae663d700fc@haskell.org> #11527: Pattern match translation suboptimal -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Sounds great to me. Yes, injectivity of `fromString` and `fromInteger` seem like the key points. Would you like to propose a design, describe it on a wiki page, agree it, and maybe implement it? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 16:00:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 16:00:25 -0000 Subject: [GHC] #11528: Representation of value set abstractions as trees causes performance issues Message-ID: <047.8140819c5c20cc2075d0d9649ecb74f6@haskell.org> #11528: Representation of value set abstractions as trees causes performance issues -------------------------------------+------------------------------------- Reporter: gkaracha | Owner: gkaracha Type: task | Status: new Priority: lowest | Milestone: Research needed Component: Compiler | Version: Keywords: | Operating System: Unknown/Multiple PatternMatchWarnings | Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The new exhaustiveness checker has been originally designed to use a prefix tree representation of value set abstractions. Unfortunately, this resulted in huge performance problems (see for example #11160, #11161, #11162, #11163, #11195, #11276, #11303, #11374, #11302) and we had to switch to a representation of value set abstractions as a list of value vector abstractions. It would be nice to switch back to the prefix tree representation but the performance problems with it are yet to be characterized so I have created a branch using this representation (`wip/gadtpm-prefix-tree`) to further investigate this approach. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 16:37:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 16:37:19 -0000 Subject: [GHC] #11247: Weird error from running runghc on an invalid input filename In-Reply-To: <047.d61a71ca0d3a8a8bd5c12bdb5d9bc198@haskell.org> References: <047.d61a71ca0d3a8a8bd5c12bdb5d9bc198@haskell.org> Message-ID: <062.03d75e252de4027c770f9b415fa2449f@haskell.org> #11247: Weird error from running runghc on an invalid input filename -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: runghc/T11247 Blocked By: | Blocking: Related Tickets: #7765 | Differential Rev(s): Phab:D1678 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Just putting down some notes here: * `runghc random.` calls `ghc -e :main random.` * The function function `partition_args` in `ghc/Main.hs` decides that `random.` doesn't look like a source file input. * So it becomes a linker input (`ldInputs`). * But then `classifyLdInput` in `compiler/main/Linker.hs` decides it isn't a suitable linker input either, and ignores it. From 948e7f388748078a8d9a324b284da7c4029f7060: In GHCi & Template Haskell, give a warning for things mentioned on the command line that we don't recognise, and then ignore them. In batch mode, these are still passed to the linker as before. Indeed, `ghc random.` shows an error produced by the linker: `gcc: error: random.: No such file or directory` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 16:37:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 16:37:43 -0000 Subject: [GHC] #10284: Create a dedicated `TypeError` exception type In-Reply-To: <047.839fde5ec581c7ee24adc8fc2d4d35b0@haskell.org> References: <047.839fde5ec581c7ee24adc8fc2d4d35b0@haskell.org> Message-ID: <062.c89f1b45261a4646b470c0e66917d905@haskell.org> #10284: Create a dedicated `TypeError` exception type -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: kanetw Type: feature request | Status: merge Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_run/T10284 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D866 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: ekmett (added) * status: closed => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 16:43:38 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 16:43:38 -0000 Subject: [GHC] #11452: Typed Template Haskell sneakily allows impredicativity In-Reply-To: <047.95df7be3b6fa11a240e8f4b3bd1fc5a1@haskell.org> References: <047.95df7be3b6fa11a240e8f4b3bd1fc5a1@haskell.org> Message-ID: <062.829997c94f646bfd0e4253fa300069d6@haskell.org> #11452: Typed Template Haskell sneakily allows impredicativity -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T11452 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-8.0` as 278e1fa2fd7b33254e323d394706e72f4664ad02 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 16:49:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 16:49:44 -0000 Subject: [GHC] #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case In-Reply-To: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> References: <047.5c89b253e58fe9ce2055aec88bd2394c@haskell.org> Message-ID: <062.b4fc1e0c3b94b0cb03922ed47aa9d5e9@haskell.org> #11487: stg_ap_pp_fast doesn't pass the argument in the arity=1 case -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: gmainland Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Runtime System | Version: 8.0.1-rc1 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:D1864 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Merged to `ghc-8.0` as c1f8f7da4bbff2f2093fa084811d790b78576d08, 3591a6fe7b2ad5b2ca013548e9267ad1783bc7a5, and 675b4467d21e39eb89d1537eb1e60cafcdc49c38. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 16:57:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 16:57:37 -0000 Subject: [GHC] #11414: Panic with -XStrict: StgCmmEnv: variable not found In-Reply-To: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> References: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> Message-ID: <060.d9837fbcfe4256989e35922ca40dface@haskell.org> #11414: Panic with -XStrict: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Strict Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T11414 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1791 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => new Comment: Taking out of patch status as we don't yet have a convincing fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 16:57:40 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 16:57:40 -0000 Subject: [GHC] #11247: Weird error from running runghc on an invalid input filename In-Reply-To: <047.d61a71ca0d3a8a8bd5c12bdb5d9bc198@haskell.org> References: <047.d61a71ca0d3a8a8bd5c12bdb5d9bc198@haskell.org> Message-ID: <062.19c3f162022536854c0916526beb1d4b@haskell.org> #11247: Weird error from running runghc on an invalid input filename -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: runghc/T11247 Blocked By: | Blocking: Related Tickets: #7765 | Differential Rev(s): Phab:D1678 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Some possible ways to solve this: * Throw an exception when `classifyLdInput` finds an unrecognised input. I wonder if this would break anything. * Or only throw an exception when the unrecognised input is a file that doesn't exist (passing an existing but invalid file would still be a warning). * Or check before putting files in `ldInputs` whether they exist. This affects normal `ghc` make and batch mode as well. Do not: * modify runghc, since `ghc -e :main foo.bar` has the same problem -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 17:24:58 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 17:24:58 -0000 Subject: [GHC] #11247: Weird error from running runghc on an invalid input filename In-Reply-To: <047.d61a71ca0d3a8a8bd5c12bdb5d9bc198@haskell.org> References: <047.d61a71ca0d3a8a8bd5c12bdb5d9bc198@haskell.org> Message-ID: <062.7909f7001be11c0422bbc6b190304367@haskell.org> #11247: Weird error from running runghc on an invalid input filename -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: runghc/T11247 Blocked By: | Blocking: Related Tickets: #7765 | Differential Rev(s): Phab:D1678 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"db97ed9f91119bffa68e9d23acf1a08a8cd4e23c/ghc" db97ed9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="db97ed9f91119bffa68e9d23acf1a08a8cd4e23c" Add (failing) test for #11247 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 17:36:11 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 17:36:11 -0000 Subject: [GHC] #11328: Auto complete in ghci shows $sel:function:Type for DuplicateRecordFields fields In-Reply-To: <047.e75a7fff6e231d461809a0fc09000e32@haskell.org> References: <047.e75a7fff6e231d461809a0fc09000e32@haskell.org> Message-ID: <062.445418f8dbd78c16c3e08a421dfd12ed@haskell.org> #11328: Auto complete in ghci shows $sel:function:Type for DuplicateRecordFields fields -------------------------------------+------------------------------------- Reporter: kolmodin | Owner: adamgundry Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 8.0.1-rc1 Resolution: | Keywords: | DuplicateRecordFields, ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/should_run/T11328 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1870 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 17:53:31 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 17:53:31 -0000 Subject: [GHC] #11428: ImpredicativeTypes causes GHC panic with 8.0.1-rc1 In-Reply-To: <050.76969e6fa5505d78e0d0dace54163d75@haskell.org> References: <050.76969e6fa5505d78e0d0dace54163d75@haskell.org> Message-ID: <065.8e947eaf107227601fea8ccdde95b168@haskell.org> #11428: ImpredicativeTypes causes GHC panic with 8.0.1-rc1 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: fixed | ImpredicativeTypes, | TypeApplications 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 bgamari): * status: new => closed * resolution: => fixed Comment: Indeed this now fails with the error {{{ T11428.hs:12:13: error: ? Couldn't match expected type ?forall a. a -> a? with actual type ?Pipe o2 r0 -> Pipe o2 r0? ? When checking that: Pipe o2 r0 -> Pipe o2 r0 is more polymorphic than: forall a. a -> a The lambda expression ?\ o' p' -> HaveOutput p' o'? has two arguments, but its type ?o2 -> forall a. a -> a? has only one In the second argument of ?maybe?, namely ?(\ o' p' -> HaveOutput p' o')? ? Relevant bindings include f :: o1 -> Maybe o2 (bound at T11428.hs:11:16) mapOutputMaybe :: (o1 -> Maybe o2) -> Pipe o1 r -> Pipe o2 r (bound at T11428.hs:11:1) }}} When compiled with `ImpredicativeTypes`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 18:41:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 18:41:35 -0000 Subject: [GHC] #11328: Auto complete in ghci shows $sel:function:Type for DuplicateRecordFields fields In-Reply-To: <047.e75a7fff6e231d461809a0fc09000e32@haskell.org> References: <047.e75a7fff6e231d461809a0fc09000e32@haskell.org> Message-ID: <062.1c15d7e297a9118d9dbd86693dba2936@haskell.org> #11328: Auto complete in ghci shows $sel:function:Type for DuplicateRecordFields fields -------------------------------------+------------------------------------- Reporter: kolmodin | Owner: adamgundry Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: GHCi | Version: 8.0.1-rc1 Resolution: fixed | Keywords: | DuplicateRecordFields, ORF Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | ghci/should_run/T11328 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1870 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 670466039ac63a94af9e136212da8d511f02b935. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 18:42:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 18:42:57 -0000 Subject: [GHC] #11397: Type mismatch in local definitions in Haskell 98 code In-Reply-To: <046.5b123e70d0bf35744220fa73d4352f47@haskell.org> References: <046.5b123e70d0bf35744220fa73d4352f47@haskell.org> Message-ID: <061.41c61f3c572ebb7f54d6f737f4755494@haskell.org> #11397: Type mismatch in local definitions in Haskell 98 code -------------------------------------+------------------------------------- Reporter: Lemming | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: fixed | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compiler/T11397 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: This was merged in 278e1fa2fd7b33254e323d394706e72f4664ad02. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 18:43:09 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 18:43:09 -0000 Subject: [GHC] #11458: Terrible failure of type inference in visible type application In-Reply-To: <046.9e988e804957302749d23e8054557bb0@haskell.org> References: <046.9e988e804957302749d23e8054557bb0@haskell.org> Message-ID: <061.846f89fb3bb5b1ef221d35411a439164@haskell.org> #11458: Terrible failure of type inference in visible type application -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: Resolution: fixed | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_compile/T11458 Blocked By: | Blocking: Related Tickets: #11397 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: This was merged in 278e1fa2fd7b33254e323d394706e72f4664ad02. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 19:06:09 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 19:06:09 -0000 Subject: [GHC] #11521: Test failures for the `profasm` way when BUILD_PROF_LIBS=YES In-Reply-To: <045.daf56e9bd8ee4ad19ba9daea05cb163a@haskell.org> References: <045.daf56e9bd8ee4ad19ba9daea05cb163a@haskell.org> Message-ID: <060.a79c46b12b13f71fbdc82fd77ba181cb@haskell.org> #11521: Test failures for the `profasm` way when BUILD_PROF_LIBS=YES -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: 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): One option would be to normalize out these profiling callstacks. You could take care of this pretty easily I believe. Unfortunately this is a very large hammer which makes it harder to test the profiling stack trace feature. It would be nice if the testsuite driver gave us a bit more control over what normalizations were run for which tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 19:31:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 19:31:41 -0000 Subject: [GHC] #11510: Missing Show instance for GHC.Stack.SrcLoc In-Reply-To: <050.e08b70941207067cd22a7124ead2f765@haskell.org> References: <050.e08b70941207067cd22a7124ead2f765@haskell.org> Message-ID: <065.cc39696cea44992479a5c077d180f06a@haskell.org> #11510: Missing Show instance for GHC.Stack.SrcLoc -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: 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 => high * cc: gridaphobe, ekmett (added) * component: Compiler => Core Libraries * milestone: => 8.0.1 Comment: We should really make sure something happens on this before 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 19:36:04 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 19:36:04 -0000 Subject: [GHC] #8228: GHC built under Windows does not generate dyn_hi files In-Reply-To: <045.75cbd05b617b871cecfcf573b0b5b3b2@haskell.org> References: <045.75cbd05b617b871cecfcf573b0b5b3b2@haskell.org> Message-ID: <060.2899af3347b4df933947b695db3f75d5@haskell.org> #8228: GHC built under Windows does not generate dyn_hi files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: cabal01 Blocked By: | Blocking: 6107 Related Tickets: #7134 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Austin, do you still intend on looking at this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 19:36:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 19:36:14 -0000 Subject: [GHC] #11508: QuickCheck application hangs with concurrent read/write of Chan In-Reply-To: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> References: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> Message-ID: <059.80832939b26b5afd464190af575a41dd@haskell.org> #11508: QuickCheck application hangs with concurrent read/write of Chan -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: https://github.com/centromere/ghc-bug-testcase => @@ -1,1 +1,2 @@ - If you configure the test case like so: + If you configure the test case in https://github.com/centromere/ghc-bug- + testcase like so: New description: If you configure the test case in https://github.com/centromere/ghc-bug- testcase like so: {{{ $ cabal configure --enable-tests -fbad }}} The QuickCheck application will hang when executed: {{{ $ ./dist/build/properties/properties --quickcheck-verbose --quickcheck- tests 10 10 9 8 7 6 5 4 3 2 1 10 testCase 1 a: }}} If you compile it without the 'bad' flag, it will execute successfully. The problem is reproducible on both FreeBSD 10 and Ubuntu 15.10. Attached is the output from truss when run against the bad version of the application. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 19:37:20 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 19:37:20 -0000 Subject: [GHC] #9630: compile-time performance regression (probably due to Generics) In-Reply-To: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> References: <042.a529e5f70870528e7f8796a28ce82a84@haskell.org> Message-ID: <057.9e614315e0d33d21bd99d151227584f6@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: Punting to 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 19:37:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 19:37:35 -0000 Subject: [GHC] #8228: GHC built under Windows does not generate dyn_hi files In-Reply-To: <045.75cbd05b617b871cecfcf573b0b5b3b2@haskell.org> References: <045.75cbd05b617b871cecfcf573b0b5b3b2@haskell.org> Message-ID: <060.e677df6f2660253c6c0c49bf56f13725@haskell.org> #8228: GHC built under Windows does not generate dyn_hi files -------------------------------------+------------------------------------- Reporter: ezyang | Owner: thoughtpolice Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC doesn't work | Unknown/Multiple at all | Test Case: cabal01 Blocked By: | Blocking: 6107 Related Tickets: #7134 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: Punting to 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 19:38:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 19:38:57 -0000 Subject: [GHC] #10074: Implement the 'Improved LLVM Backend' proposal In-Reply-To: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> References: <052.e0bd123a5931fad09824fa5aaa592583@haskell.org> Message-ID: <067.4919891010387f0ceb03a6618a1b19d7@haskell.org> #10074: Implement the 'Improved LLVM Backend' proposal -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: thoughtpolice Type: task | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (LLVM) | Version: Resolution: | Keywords: llvm, codegen Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D530 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: It seems that this likely won't happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 19:39:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 19:39:22 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.285dd117840e90f3a6e99b0803bc83bb@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Segmentation | fault, segfault, long input Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Runtime crash | Test Case: Blocked By: 4258 | Blocking: Related Tickets: | Differential Rev(s): Phab:D1180 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: Punting to 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 19:46:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 19:46:25 -0000 Subject: [GHC] #11510: Missing Show instance for GHC.Stack.SrcLoc In-Reply-To: <050.e08b70941207067cd22a7124ead2f765@haskell.org> References: <050.e08b70941207067cd22a7124ead2f765@haskell.org> Message-ID: <065.d6036e9ea3837bf6589bca852b5b4458@haskell.org> #11510: Missing Show instance for GHC.Stack.SrcLoc -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gridaphobe): I don't have a problem with adding the Show instance for SrcLoc back, I didn't think it would be very useful. There was also a Show instance for CallStack in 7.10.2, is there a reason to want that? I think not, because the user shouldn't care about the representation. If you want a machine-readable formatting of a CallStack you can use `getCallStack stk` to get a list of the call-sites, which is then Showable (assuming a Show SrcLoc instance). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 20:48:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 20:48:19 -0000 Subject: [GHC] #11508: QuickCheck application hangs with concurrent read/write of Chan In-Reply-To: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> References: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> Message-ID: <059.d64c63d575064969aa1b786b65a6c309@haskell.org> #11508: QuickCheck application hangs with concurrent read/write of Chan -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I haven't looked carefully at the ticket but if it helps to compile with `-fno-omit-yields` then you are being bitten by #367. See that ticket and the [http://downloads.haskell.org/~ghc/master/users-guide//bugs.html#bugs- in-ghc|Users Guide] for details. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 20:48:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 20:48:26 -0000 Subject: [GHC] #11508: QuickCheck application hangs with concurrent read/write of Chan In-Reply-To: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> References: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> Message-ID: <059.5b2a5902a620ead60f10b23a0929d19f@haskell.org> #11508: QuickCheck application hangs with concurrent read/write of Chan -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 21:03:18 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 21:03:18 -0000 Subject: [GHC] #11508: QuickCheck application hangs with concurrent read/write of Chan In-Reply-To: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> References: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> Message-ID: <059.8b21486be4e66aa4c6bb6329bdb1361e@haskell.org> #11508: QuickCheck application hangs with concurrent read/write of Chan -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I had a quick look at the testcase. Judging from the eventlog it appears that there are a few threads blocking: * one thread blocking on a `MVar` * another blocking on an STM retry Finally, we also have foreign calls involved due to the `ByteString` usage. Sadly `-fno-omit-yields` doesn't seem to help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 21:09:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 21:09:05 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.9464d43d9b0c436dd53d6afe75d64d4f@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by int-e): * cc: int-e (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 21:58:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 21:58:29 -0000 Subject: [GHC] #9936: Data.Fixed truncates 5.17 to 5.16 In-Reply-To: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> References: <049.6b8f69f5357b7d4ed3acd7f2538418ac@haskell.org> Message-ID: <064.506af3ae65d059e9d38d0db65aefe6c4@haskell.org> #9936: Data.Fixed truncates 5.17 to 5.16 -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9231, #9240 | Differential Rev(s): Phab:D1693 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bernalex): I tried this (see the differential), but it breaks things like read "38.009" :: Centi being the same as 38.009 :: Centi, which is not very nice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 2 23:53:04 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 02 Feb 2016 23:53:04 -0000 Subject: [GHC] #8746: Crosscompiling In-Reply-To: <049.1228fc07cede4b1619c6ff70ac264add@haskell.org> References: <049.1228fc07cede4b1619c6ff70ac264add@haskell.org> Message-ID: <064.96245105e8fd81fb33c86f2f28ca9623@haskell.org> #8746: Crosscompiling -------------------------------------+------------------------------------- Reporter: Visionstar | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.8.1-rc1 Resolution: invalid | Keywords: Crosscompile | cross compile failed ncurses | setupterm not found Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: I agree with thomie's sentiments, but: * `terminfo` already builds just fine when cross-compiling, so long as you have installed the terminfo C library properly for your cross-compiler. https://github.com/neurocyte/ghc-android does this for you for the case of cross-compiling to Android, and it sounds like the original reporter also got it to work eventually. * I'm guessing the "Unsupported GHC version" error was a result of an improperly checked-out GHC source tree, as described at https://mail.haskell.org/pipermail/ghc-devs/2014-March/004294.html. (My fuzzy understanding is that Haddock is built by the stage 2 compiler anyways, according to comments in `ghc.mk`, so perhaps it doesn't make sense to do anything with Haddock when cross-compiling. (But the error clearly shows something being built with `ghc-stage1`, so what's up with that?) In any case, one doesn't get this error if one sets `HADDOCK_DOCS = NO`.) So, going to close this again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 00:02:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 00:02:33 -0000 Subject: [GHC] #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page In-Reply-To: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> References: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> Message-ID: <067.5fa60cc4334ba430f76e954761be8bae@haskell.org> #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: > bgamari: what is the status here? hsyl20 and I were discussing it a few weeks ago; I fixed a few issues in Phab:D1470 but there is still a fair amount of debugging to do before it is mergeable. It certainly isn't 8.0 material at this point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 00:42:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 00:42:04 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.2a640bba8cdd5b113415e018bfafadb5@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf 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 HairyDude): * cc: HairyDude (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 00:43:30 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 00:43:30 -0000 Subject: [GHC] #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? In-Reply-To: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> References: <045.5b74d940dce176e76fe47859d9b698f8@haskell.org> Message-ID: <060.d75d679eaf651f45e9ec8727deefc0f7@haskell.org> #7450: Regression in optimisation time of functions with many patterns (6.12 to 7.4)? -------------------------------------+------------------------------------- Reporter: iustin | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.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): Phab:D1012 Wiki Page: | -------------------------------------+------------------------------------- Changes (by HairyDude): * cc: HairyDude (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 02:11:11 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 02:11:11 -0000 Subject: [GHC] #11529: Show instance of Char should print literals for non-ascii printable charcters Message-ID: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> #11529: Show instance of Char should print literals for non-ascii printable charcters -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Show instance for non-ascii characters prints their character codes. This is sad for Haskell users that speaks language other than English. {{{#!hs > 'A' 'A' > '?' '\196' > '?' '\28450' > print $ [(++"'s dad"), (++"'s mom")] <*> ["Simon", "John"] ["Simon's dad","John's dad","Simon's mom","John's mom"] > print $ [(++"??"), (++"??")] <*> ["??", "??"] ["\30000\20013\12398\29238","\23665\30000\12398\29238","\30000\20013\12398\27597","\23665\30000\12398\27597"] }}} The function that needs improvement is showLitChar in GHC.Show, which currently prints any character larger than ASCII code 127 by its character code: http://haddock.stackage.org/lts-5.1/base-4.8.2.0/src/GHC-Show.html {{{#!hs showLitChar :: Char -> ShowS showLitChar c s | c > '\DEL' = showChar '\\' (protectEsc isDec (shows (ord c)) s) }}} On the other hand, there is GHC.Unicode.isPrint, the predicate for printable Unicode characters, that is calling on a foreign function u_iswprint for the knowledge. https://hackage.haskell.org/package/base-4.8.2.0/docs/src/GHC.Unicode.html#isPrint I think one of the solution is to import and call u_iswprint from GHC.Show, too, but I don't know it's against any design choices. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 02:43:41 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 02:43:41 -0000 Subject: [GHC] #11529: Show instance of Char should print literals for non-ascii printable charcters In-Reply-To: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> References: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> Message-ID: <060.ab7f5868e7b096a5f14813ff54173a99@haskell.org> #11529: Show instance of Char should print literals for non-ascii printable charcters -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nushio): One of application that is broken by this change, is when a customized Show instance of a type is controlled by other variables in that type. For example, the following code simulates a press code that respects privacy for people of age under 20. {{{#!hs data Sex = Male | Female data Person = Person {name :: String, age :: Int, sex :: Sex} instance Show Person where show (Person _ a Male ) | a < 20 = "A boy (" ++ show a ++ ")" show (Person _ a Female) | a < 20 = "A girl (" ++ show a ++ ")" show (Person n a _ ) = n assert $ show (Person "????" 19 Male) == "A boy (19)" assert $ show (Person "????" 20 Male) == "\26449\20027\23815\34892" }}} I'm very looking forward to learn other drawbacks of this change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 03:58:55 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 03:58:55 -0000 Subject: [GHC] #11529: Show instance of Char should print literals for non-ascii printable charcters In-Reply-To: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> References: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> Message-ID: <060.963036d25b4408319071abe43e1d0992@haskell.org> #11529: Show instance of Char should print literals for non-ascii printable charcters -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): Absolutely any code in the entire world that relies on the current behavior will break. The current behavior is expressed in the reference implementation in the Haskell 2010 report. Frankly, changing it ''is not an option''. You can write your own function to unescape valid Unicode. You can also write your own `UShow` class if you like with a method for showing various things using Unicode generally. You can then try to convince other developers to depend on your package and write instances of your class. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 04:06:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 04:06:04 -0000 Subject: [GHC] #11530: Make fails on systems with GREP_OPTIONS Message-ID: <047.65eb2c1162c4e0a77b27714fb3375078@haskell.org> #11530: Make fails on systems with GREP_OPTIONS ----------------------------------------+--------------------------------- Reporter: alexlegg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Keywords: | Operating System: POSIX Architecture: Unknown/Multiple | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+--------------------------------- In rules/manual-package-config.mk the following use of grep will cause later errors if -n (prepending line numbers) is set in GREP_OPTIONS. {{{ grep -v '^#pragma GCC' $$@.raw | \ sed -e 's/""//g' -e 's/:[ ]*,/: /g' >$$@ }}} It causes parsing issues later, with errors like: {{{ : Warning: Unrecognized field 420 on line 420 : Warning: Unrecognized field 419 on line 419 ... : Warning: Unrecognized field 1 on line 1 : missing id field : invalid package identifier: : invalid package key: }}} It may be worth adding an `export GREP_OPTIONS=` somewhere in the make file as it's reasonably difficult to figure out the actual problem from the error message. I would do this and submit a patch but I'm not sure if it is desired since GREP_OPTIONS is now deprecated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 04:42:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 04:42:14 -0000 Subject: [GHC] #11529: Show instance of Char should print literals for non-ascii printable charcters In-Reply-To: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> References: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> Message-ID: <060.6a30b712e6625cdcf95c994c324dd88a@haskell.org> #11529: Show instance of Char should print literals for non-ascii printable charcters -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nushio): Dear dfeuer, thank you for pointing out that the `Show Char` is specified in Haskell 2010. I believe the corresponding section is the following: https://www.haskell.org/onlinereport/haskell2010/haskellch16.html#x24-21700016.6 {{{ 16.6 String representations showLitChar :: Char -> ShowS Convert a character to a string using only printable characters, using Haskell source-language escape conventions. For example: showLitChar '\n' s = "\\n" ++ s }}} where "Haskell source-language escape conventions" are defined, in turn, in Section 2.6 https://www.haskell.org/onlinereport/haskell2010/haskellch2.html#x7-200002.6 . Correct me if I'm wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 04:51:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 04:51:27 -0000 Subject: [GHC] #11531: ghci with ffi to inline assembly results in "the 'impossible'" Message-ID: <048.4371af626921c6fdca2773f5f4df3d61@haskell.org> #11531: ghci with ffi to inline assembly results in "the 'impossible'" --------------------------------------+--------------------------------- Reporter: isovector | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: ffi, asm, ghci | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- I'm attempting to run some assembly in Haskell; in order to do that I wrote a FFI to some inline C asm. Attempting to load it in ghci results in: $ g++ -c ffi.cpp -fPIC $ ghci ffi.o Main.hs GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static) ffi.o ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): Loading temp shared object failed: /tmp/ghc8684_0/ghc8684_1.so: undefined symbol: _ZNSt8ios_base4InitD1Ev Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug It said to report a bug, so here it is! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 04:51:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 04:51:47 -0000 Subject: [GHC] #11531: ghci with ffi to inline assembly results in "the 'impossible'" In-Reply-To: <048.4371af626921c6fdca2773f5f4df3d61@haskell.org> References: <048.4371af626921c6fdca2773f5f4df3d61@haskell.org> Message-ID: <063.29e6cd5201c2fbe144011c11be59250c@haskell.org> #11531: ghci with ffi to inline assembly results in "the 'impossible'" ---------------------------------+-------------------------------------- Reporter: isovector | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: ffi, asm, ghci 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 isovector): * Attachment "ffi.cpp" added. ffi implementation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 04:51:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 04:51:57 -0000 Subject: [GHC] #11531: ghci with ffi to inline assembly results in "the 'impossible'" In-Reply-To: <048.4371af626921c6fdca2773f5f4df3d61@haskell.org> References: <048.4371af626921c6fdca2773f5f4df3d61@haskell.org> Message-ID: <063.59b2c3ac8ff1dbc5dd7058947f09baa8@haskell.org> #11531: ghci with ffi to inline assembly results in "the 'impossible'" ---------------------------------+-------------------------------------- Reporter: isovector | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: ffi, asm, ghci 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 isovector): * Attachment "ffi.h" added. ffi header -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 04:52:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 04:52:06 -0000 Subject: [GHC] #11531: ghci with ffi to inline assembly results in "the 'impossible'" In-Reply-To: <048.4371af626921c6fdca2773f5f4df3d61@haskell.org> References: <048.4371af626921c6fdca2773f5f4df3d61@haskell.org> Message-ID: <063.1fe45f5a7daf376e159664bc42ed696c@haskell.org> #11531: ghci with ffi to inline assembly results in "the 'impossible'" ---------------------------------+-------------------------------------- Reporter: isovector | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: ffi, asm, ghci 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 isovector): * Attachment "Main.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 05:53:02 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 05:53:02 -0000 Subject: [GHC] #11531: ghci with ffi to inline assembly results in "the 'impossible'" In-Reply-To: <048.4371af626921c6fdca2773f5f4df3d61@haskell.org> References: <048.4371af626921c6fdca2773f5f4df3d61@haskell.org> Message-ID: <063.91db5cdb08a546304d10db43b2cfb914@haskell.org> #11531: ghci with ffi to inline assembly results in "the 'impossible'" ---------------------------------+-------------------------------------- Reporter: isovector | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: duplicate | Keywords: ffi, asm, ghci Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10458 | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate * related: => #10458 Comment: Thanks for the report. Actually, the issue here is that you wrote a C++ program. In order to link C++-compiled object files with the outside world, you need to link with the C++ standard library, `-lstdc++`. So, you could do this: {{{ $ ghci ffi.o Main.hs -lstdc++ }}} This won't actually work in 7.8 or 7.10, because of #10458. But I tested that it does work in current HEAD and 8.0. So, closing as a duplicate of that ticket. In the meantime, you can build your C++ object into a shared library yourself, and load that in ghci: {{{ $ g++ -shared -o libmyffi.so ffi.o $ ghci Main.hs -L. -lmyffi }}} Alternatively, just write your inline assembly in C. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 08:36:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 08:36:17 -0000 Subject: [GHC] #11532: ghc: panic! occured Message-ID: <045.2d3308752fa81c80b55c3625ddb38f5a@haskell.org> #11532: ghc: panic! occured -------------------------------------+------------------------------------- Reporter: cutsea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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'd like to try install by following: {{{ $ cabal sandbox init $ cabal install metadata Resolving dependencies... Notice: installing into a sandbox located at /home/cutsea110/devel/haskell/sandbox/.cabal-sandbox Configuring metadata-0.4.2.0... Building metadata-0.4.2.0... : : [1036 of 1286] Compiling Text.HTML5.MetaData.Schema.TelevisionStation[boot] ( Text/HTML5/MetaData/Schema/TelevisionStation.hs-boot, dist/dist-sandbox- 304cb20a/build/Text/HTML5/MetaData/Schema/TelevisionStation.o-boot ) [1037 of 1286] Compiling Text.HTML5.MetaData.Schema.TelevisionStation ( Text/HTML5/MetaData/Schema/TelevisionStation.hs, dist/dist-sandbox- 304cb20a/build/Text/HTML5/MetaData/Schema/TelevisionStation.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): LocalReg's live-in to graph cpd3t {_sp8MJ::P64} Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug cabal: Error: some packages failed to install: metadata-0.4.2.0 failed during the building phase. The exception was: ExitFailure 1 }}} -- regards. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 09:19:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 09:19:29 -0000 Subject: [GHC] #11527: Pattern match translation suboptimal In-Reply-To: <047.fde14f3a46e0c8f9e9764d2f5559e6f1@haskell.org> References: <047.fde14f3a46e0c8f9e9764d2f5559e6f1@haskell.org> Message-ID: <062.bf7d1efe76859ee4fd6e1371fe65383c@haskell.org> #11527: Pattern match translation suboptimal -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by augustss): OK, I'll start by making a wiki page. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 10:12:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 10:12:29 -0000 Subject: [GHC] #11532: ghc: panic! occured In-Reply-To: <045.2d3308752fa81c80b55c3625ddb38f5a@haskell.org> References: <045.2d3308752fa81c80b55c3625ddb38f5a@haskell.org> Message-ID: <060.af7b9840e615ec7145d58e396d633128@haskell.org> #11532: ghc: panic! occured -------------------------------------+------------------------------------- Reporter: cutsea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This looks bad. Does it happen with the 8.0 release candidate? Can anyone investigate? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 11:01:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 11:01:47 -0000 Subject: [GHC] #11529: Show instance of Char should print literals for non-ascii printable charcters In-Reply-To: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> References: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> Message-ID: <060.7a410e0872f35f74e75a06b358bc2ff6@haskell.org> #11529: Show instance of Char should print literals for non-ascii printable charcters -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): You can put something like this in your `.ghci` file: {{{ :seti -XScopedTypeVariables :{ let myShow :: Show a => a -> String myShow x = go (show x) where go :: String -> String go [] = [] go s@(x:xs) = case x of '\"' -> '\"' : str ++ "\"" ++ go rest '\'' -> '\'' : char : '\'' : go rest' _ -> x : go xs where (str :: String, rest):_ = reads s (char :: Char, rest'):_ = reads s :} :{ let myPrint :: Show a => a -> IO () myPrint = putStrLn . myShow :} :set -interactive-print=myPrint }}} Example: {{{ Prelude> [(++"??"), (++"??")] <*> ["??", "??"] ["????","????","????","????"] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 11:25:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 11:25:13 -0000 Subject: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled In-Reply-To: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> References: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> Message-ID: <061.559d0d075a7f3bffb469b5f67aaff93e@haskell.org> #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): What are the next steps here? I can make it a flag and use it to make the test pass. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 12:47:50 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 12:47:50 -0000 Subject: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled In-Reply-To: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> References: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> Message-ID: <061.73a0232cebccf0d21f5355a1f41f0b03@haskell.org> #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I don't know. I still don't understand WHY this assert is causing exponential behaviour in this example and I'm reluctant to suppress it until we know. In `typecheck/should_fail/TcCoercibleFail` I see {{{ newtype Fix f = Fix (f (Fix f)) foo6 = coerce :: Fix (Either Int) -> Fix (Either Age) foo7 = coerce :: Fix (Either Int) -> () }}} which is presumably the cause of the problem? But that looks nothing like the example in comment:8. Nor can I see where 100-level unwrappping would happen. So I'm lost. Fortunately it doesn't affect a normal stage-2 validate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 16:29:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 16:29:58 -0000 Subject: [GHC] #11533: Stack check not optimized out even if it could be Message-ID: <046.6d5f7866bf619f9b74b6c94e89479ca9@haskell.org> #11533: Stack check not optimized out even if it could be -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (CodeGen) | Keywords: cmm | 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: -------------------------------------+------------------------------------- CmmLayoutStack tries to remove a stack check if a function uses no stack space. It knows that Sp < SpLim is always false, but not that Sp >= SpLim is always true. However, the latter can arise when GHC flips the comparison (which it does sometimes). An example would be the worker function generated for {{{go}}}: {{{ countDown :: Int -> Int countDown = go 0 where go acc n | n > 0 = go (acc + 1) (n - 1) | otherwise = acc + n }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 16:30:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 16:30:47 -0000 Subject: [GHC] #11533: Stack check not optimized out even if it could be In-Reply-To: <046.6d5f7866bf619f9b74b6c94e89479ca9@haskell.org> References: <046.6d5f7866bf619f9b74b6c94e89479ca9@haskell.org> Message-ID: <061.b3c0ef6bda3919bd4c5f371dfffec0a6@haskell.org> #11533: Stack check not optimized out even if it could be -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (CodeGen) | Resolution: | Keywords: cmm Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1881 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jscholl): * status: new => patch * differential: => Phab:D1881 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 17:04:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 17:04:06 -0000 Subject: [GHC] #10345: Testsuite timeout_multiplier setting does not work as expected In-Reply-To: <048.e0092338ecde0e0050123f85c2695d0b@haskell.org> References: <048.e0092338ecde0e0050123f85c2695d0b@haskell.org> Message-ID: <063.b0cf19e536069c8445513f8b813a1f2d@haskell.org> #10345: Testsuite timeout_multiplier setting does not work as expected -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Test Suite | Version: 7.11 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:D982 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Replying to [comment:1 thomie]: > The issue only I seem to be having is that running `python testsuite/timeout/timeout.py 10 'echo ok' ` doesn't return immediately, but only after 10 seconds. I finally figured this one out. I had `stty tostop` set in `~/.bashrc`. When `stty tostop` is set, a background process that tries to write to the terminal receives a SIGTTOU signal, which suspends it. In timeout.py, the first thing the child process does is call `os.setpgrp()`. This creates a new process group, with the child process itself as process group leader. Because only one process group per session can be the foreground process group, it will be a background process group. I'm not sure yet //why// timeout.py turns the child process that it creates into a background process. One implication is that `CTRL-C` doesn't kill it. References: * https://www.win.tue.nl/~aeb/linux/lk/lk-10.html * http://www.linusakesson.net/programming/tty/index.php -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 17:42:03 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 17:42:03 -0000 Subject: [GHC] #11532: ghc: panic! occured In-Reply-To: <045.2d3308752fa81c80b55c3625ddb38f5a@haskell.org> References: <045.2d3308752fa81c80b55c3625ddb38f5a@haskell.org> Message-ID: <060.29e191f1dc7d10fba6ee81282dc8ab44@haskell.org> #11532: ghc: panic! occured -------------------------------------+------------------------------------- Reporter: cutsea | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => infoneeded Comment: I'm afraid I am unable to reproduce this with 7.10.3 and the metadata-0.4.2.0 on Linux/x86_64. Cutsea, have you been able to reproduce this after cleaning your source tree? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 17:42:24 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 17:42:24 -0000 Subject: [GHC] #11532: ghc: panic! occured In-Reply-To: <045.2d3308752fa81c80b55c3625ddb38f5a@haskell.org> References: <045.2d3308752fa81c80b55c3625ddb38f5a@haskell.org> Message-ID: <060.ee30960a687556c2fb7e60da57e54d9c@haskell.org> #11532: ghc: panic! occured -------------------------------------+------------------------------------- Reporter: cutsea | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * failure: None/Unknown => Compile-time crash * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 18:02:40 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 18:02:40 -0000 Subject: [GHC] #10284: Create a dedicated `TypeError` exception type In-Reply-To: <047.839fde5ec581c7ee24adc8fc2d4d35b0@haskell.org> References: <047.839fde5ec581c7ee24adc8fc2d4d35b0@haskell.org> Message-ID: <062.85af0754aec7a1ac1a2012f4a28486c6@haskell.org> #10284: Create a dedicated `TypeError` exception type -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: kanetw Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_run/T10284 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D866 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: This has been merged to `ghc-8.0` as fc5ed862ef52efa6e02e291ce441a1300ccc6e9c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 19:13:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 19:13:18 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies Message-ID: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (Type checker) | Keywords: TypeFamilies, | Operating System: Unknown/Multiple FunctionalDependencies | Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider: {{{#!hs class Foo i j | i -> j where type Bar i :: * type Bar i = j }}} This is rejected as `j` is not an argument to `Bar`, but when we realize any instance `j` will be a known type, determined by `i`, as told to us by the | i -> j functional dependency on the class. This would likely require some sort of extra pass over the instances with class associated types of this form to elaborate them, or a slight modification of the default signature implementation for class associated types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 21:04:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 21:04:34 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.556174619eface2798351f3e01a0f717@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm doubtful. Remember, * An associated type declaration is just convenient notation for a top- level declaration * Those default declarations are just an abbreviation for writing it out at every insttance With that in mind, what would we make of {{{ instance D a b => C [a] [b] where {} }}} From a fundep point of view this is fine, provided `D` has a fundep. Expanding the default decl gives {{{ instance D a b => C [a] [b] where type Bar [a] = [b] }}} which makes no sense. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 21:25:09 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 21:25:09 -0000 Subject: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled In-Reply-To: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> References: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> Message-ID: <061.a5822d88dca785d1e08cf341b4d8328e@haskell.org> #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): No, I don't think the example from comment:14 is related. We have {{{ newtype VoidBad a = VoidBad (VoidBad (a,a)) foo5' = coerce :: (VoidBad ()) -> () }}} For `coerce :: (VoidBad ()) -> ()` to typecheck we have to know if `VoidBad ()` and `()` have the same runtime representation. So we need to find out what `VoidBad ()` really is. So we start unwrapping the newtypes of off it. What do we get when we try to unwrap the newtype off of `VoidBad ()`? {{{ VoidBad () = VoidBad ((),()) = VoidBad (((),()),((),())) = VoidBad ((((),()),((),())),(((),()),((),()))) = ... }}} It's clear that the type we apply to `VoidBad` grows exponentially and that `VoidBad ()` diverges. Before adding the ASSERT this is detected by `checkRecTc`. The reason that `checkRecTc` manages to do that in the presence of an exponentially growing argument to `VoidBad` is that `checkRecTc` only counts how many times we've applied `VoidBad`. It never looks at the exponentially growing argument. The reason why we are able to build an exponentially growing arguments with small amount of space and time has to do with sharing. When we apply `VoidBad a = VoidBad (a, a)` it is the *same* `a` that goes to the left and right component of the pair. The `a` is shared between both components. The way we apply `VoidBad a = VoidBad (a, a)` is by using the `substTy` function. We replace every `a` from the right hand side with `a` from the left hand side. But in this case we use the *same* `a`, so the size of the type grows exponentially, but the representation doesn't. The problem arises when `substTy` examines the argument we passed as `a` to look for the free vars to do the ASSERT. Since the type grows exponentially, the time to compute the free vars also grows exponentially and we don't get to the 100th iteration of unwrapping in any reasonable amount of time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 21:44:53 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 21:44:53 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.72b8a94cbee9381cb6364f3ba79fadd5@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Let's expand your example and see. {{{#!hs class C a b | a -> b where type Bar a type Bar a = b class D a b | a -> b instance D Int Bool instance D a b => C [a] [b] }}} If we have a functional dependency on `D` from `a -> b`, that secretly builds some type family for us, we use behind the scenes, right? Let's say that `D_ab` is the "hidden" type family implied by the functional dependency from `a -> b` then the expansion of {{{#!hs instance D a b => C [a] [b] }}} would be {{{#!hs instance D a b => C [a] [b] where type Bar [a] = [D_ab a] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 21:47:48 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 21:47:48 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.9cc48f603a85c95f3c95be2ea293b8ff@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): One motivation for this is that it would finally provide us a way for users to "un-fundep" an argument without code repetition. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 22:03:32 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 22:03:32 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.421d4f5ff3f1c7ffacd22db476d6ec2e@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): In smaller steps: {{{ type Bar [a] = C_ab [a] = [D_ab a] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 22:05:25 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 22:05:25 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.8884a1225123bf56a01393c59d657a2f@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): No, there is no secret type function behind the scenes. Functional dependencies ONLY cause extra unification to take place. One could imagine something more ambitious but it is not designed or implemented. What repetition? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 22:37:30 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 22:37:30 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.029ed2edea7e80286b01b20a54f7a4df@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): If I define {{{#!hs class Functor (c :: i -> i -> *) (d :: j -> j -> *) (f :: i -> j) | f -> c d }}} as opposed to {{{#!hs class Functor (f :: i -> j) where type Dom f :: i -> i -> * type Cod f :: j -> j -> * }}} then I go to define a subclass of `Functor`, I need to repeat `c` and `d`. {{{#!hs class Functor c d f => Faithful c d f | f -> c d }}} In some real world code I have this eventually swells to something like 8-9 parameters, which is clearly unwieldy. I can "lower" things back down, by using {{{#!hs class (c ~ Dom f, d ~ Cod f) => Functor (c :: i -> i -> *) (d :: j -> j -> *) (f :: i -> j) | f -> c d where type Dom f :: i -> i -> * type Cod f :: j -> j -> * fmap :: c a b -> d (f a) (f b) }}} and using something like {{{#!hs type Fun f = Functor (Dom f) (Cod f) f }}} as the superclass of {{{#!hs class Fun f => Faithful f where unfmap :: Cod f (f a -> f b) -> Dom f a b }}} at the cost of repeating myself between the fundep determined argument and the class associated type in every instance. {{{#!hs instance Functor (->) (->) ((->) e) where type Dom ((->) e) = (->) type Cod ((->) e) = (->) fmap = (.) }}} In the example from #11523, I have {{{#!hs instance (Category p, Category q) => Category (Nat p q) where type Ob (Nat p q) = Functor p q }}} Note: I can't run the trick the other way and put a type synonym there, since I can't partially apply it. which requires me to use functional dependencies for the definition of Functor or to be able to use the existing class/instance synonym trick mentioned there, which #11523 notes currently sends the compiler into a spin with `UndecidableSuperClasses` turned on. With the machinery I was seeking here, we'd be able to write just {{{#!hs instance Functor (->) (->) ((->) e) where fmap = (.) }}} but as you note this would require upgrading functional dependencies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 22:47:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 22:47:45 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.7a4c5aaa53901b1001380c4f1a0ed205@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): You start by saying "If I define ... as opposed to ...". But why to that? Why not use the "as opposed to" definition: {{{#!hs class Functor (f :: i -> j) where type Dom f :: i -> i -> * type Cod f :: j -> j -> * }}} Fewer parameters, no fundep, easy! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 22:58:05 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 22:58:05 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.be91a613c53611eb3edd65f74ec25e10@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Then I get stuck when I get to the {{{#!hs instance (Category p, Category q) => Category (Nat p q) where type Ob (Nat p q) = Functor p q }}} line mentioned. I can't define {{{#!hs type Fun c d f = Functor (Dom f) (Cod f) f }}} and then put that in {{{#!hs instance (Category p, Category q) => Category (Nat p q) where type Ob (Nat p q) = Fun p q }}} because that involves partially applying a type family. For other reasons, I can't eta expand `Ob` to make it a type family with two parameters. Normally I'd do precisely what you suggest {{{#!hs class Functor (f :: i -> j) where type Dom f :: i -> i -> * type Cod f :: j -> j -> * }}} and then use the class/instance trick {{{#!hs class (Functor f, Dom f ~ c, Cod f ~ d) => FunctorOf c d f | f -> c d instance (Functor f, Dom f ~ c, Cod f ~ d) => FunctorOf c d f }}} to get a type family I can partially apply: {{{#!hs instance (Category p, Category q) => Category (Nat p q) where type Ob (Nat p q) = FunctorOf p q }}} but I get stuck due to #11523 causing the compiler to loop. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 3 23:01:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 03 Feb 2016 23:01:13 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.0ed34c320a81a229da4aec8da17f7e45@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): But there are other examples where this would be useful. e.g. `mtl` uses functional dependencies rather than type families, because the fundep versions of the type signatures are always less verbose, and users roundly rejected the `monads-tf` approach, but this results in a similar trap. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 03:17:51 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 03:17:51 -0000 Subject: [GHC] #11529: Show instance of Char should print literals for non-ascii printable charcters In-Reply-To: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> References: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> Message-ID: <060.2cadf845220ab95f3912514bf5e31236@haskell.org> #11529: Show instance of Char should print literals for non-ascii printable charcters -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 nushio): * status: new => closed * resolution: => invalid Comment: Dear thomie, thank you for your comment. Yes, `-interactive-print` is a great feature! I regret that I was not able to search out this has been done for years. There are also several customized `show` function proposed, like `myShow` here. However, when I used it in some detail, I found that printing in Unicode has many corner cases that are more difficult than it seems .... As far as I have searched, I cannot find a unicode-printing function that satisfies `read . unicode_show == id` for sufficiently many types. For example, https://gist.github.com/nushio3/4a10f3c0092295696daf Thus, I decided to start a small package `-interactive-print`ing. http://hackage.haskell.org/package/unicode-show I wish this helps many people enjoy Haskell! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 03:20:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 03:20:29 -0000 Subject: [GHC] #11529: Show instance of Char should print literals for non-ascii printable charcters In-Reply-To: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> References: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> Message-ID: <060.cf0d9f987c9f4d35a95b63ffb239ae79@haskell.org> #11529: Show instance of Char should print literals for non-ascii printable charcters -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: | -------------------------------------+------------------------------------- Comment (by nushio): By the way, now I know that this issue was a language feature, rather than lack of implementation, I think it is proper to close this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 03:46:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 03:46:20 -0000 Subject: [GHC] #11535: Derived instance of Read/Show causes runtime exception for infix Unicode value constructors Message-ID: <045.263be43d8d65688efb1e343588c8d0d5@haskell.org> #11535: Derived instance of Read/Show causes runtime exception for infix Unicode value constructors -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #1544, #11529 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When I run the following program `test-show.hs` on ghc 7.10.3: {{{#!hs data Y = ?? String String deriving (Eq, Ord, Show, Read) data X = String :? String deriving (Eq, Ord, Show, Read) main :: IO () main = do let y = ?? "" "" d = 0 print $ map fromEnum $ show y print $ (y, "") `elem` (readsPrec d (showsPrec d y "")) print $ (read $ show y :: Y) let x = "" :? "" d = 0 print $ map fromEnum $ show x print $ (x, "") `elem` (readsPrec d (showsPrec d x "")) print $ (read $ show x :: X) }}} I got the following results: {{{ $ stack ghc -- --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 $ stack runhaskell test-show.hs [1044,26143,32,34,34,32,34,34] True ?? "" "" [34,34,32,58,9734,32,34,34] False test-show.hs: Prelude.read: no parse }}} This behavior does not conform to Section 11.4 of Haskell 2010 Language Specification: https://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-18600011.4 : > It should be the case that > (x,"") is an element of (readsPrec d (showsPrec d x "")) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 03:47:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 03:47:54 -0000 Subject: [GHC] #11536: Multitude of different error messages when installed package is missing a module Message-ID: <045.de53bbc34e731050372202a5a7b857a8@haskell.org> #11536: Multitude of different error messages when installed package is missing a module -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #8060, #9009, | #11023 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (I might clean this up later) Key points: * missing module in 'exposed-modules' field of .cabal file * package name equals some (functioning) installed package * ghc-pkg happily registers the package * errors don't show up until one tries to use the module * error messages are all different and all quite terrible Makefile to reproduce: {{{ GHCPKG=ghc-pkg #GHC=ghc-8.0.0.20160127 GHC=ghc-7.10.3 PACKAGEDB=../.cabal-sandbox/x86_64-linux-$(GHC)-packages.conf.d/ all : $(MAKE) --no-print-directory clean $(MAKE) --no-print-directory setup $(MAKE) --no-print-directory setup1 $(MAKE) --no-print-directory run1 @echo @echo $(MAKE) --no-print-directory clean $(MAKE) --no-print-directory setup $(MAKE) --no-print-directory setup2 $(MAKE) --no-print-directory run2 clean : rm -rf .cabal-sandbox cabal.sandbox.config rm -rf temp dist System *.cabal setup : mkdir temp mkdir -p System/FilePath cabal -v0 sandbox init echo "name: filepath " >> filepath.cabal echo "version: 99999.1.0 " >> filepath.cabal echo "build-type: Simple " >> filepath.cabal echo "cabal-version: >=1.10 " >> filepath.cabal echo "library " >> filepath.cabal echo " exposed-modules: " >> filepath.cabal echo " System.FilePath " >> filepath.cabal echo " System.FilePath.Posix " >> filepath.cabal echo " build-depends: base >=4.8 " >> filepath.cabal echo " default-language: Haskell2010" >> filepath.cabal echo "module System.FilePath (module System.FilePath.Posix) where" >> System/FilePath.hs echo "import System.FilePath.Posix " >> System/FilePath.hs echo "module System.FilePath.Posix where" >> System/FilePath/Posix.hs echo "takeFileName = id " >> System/FilePath/Posix.hs setup1 : @echo @echo 111111111111111111111111111111111 @echo - Remove a module from 'exposed-modules' @echo - Install package @echo - Run some tests @echo sed -i '/System.FilePath.Posix/d' filepath.cabal cabal install -v0 --with-ghc="$(GHC)" run1 : @echo @echo FAILURE MODE 1A @echo -cd temp && "$(GHC)" -v0 -package-db="$(PACKAGEDB)" -e 'import System.FilePath.Posix' @echo @echo FAILURE MODE 1B @echo -cd temp && "$(GHC)" -v0 -package-db="$(PACKAGEDB)" -e 'import System.FilePath' -e 'takeFileName "foo/bar"' @echo @echo FAILURE MODE 1C @echo echo 'import System.FilePath' > temp/Foo.hs echo 'main = print $$ takeFileName "foo/bar"' >> temp/Foo.hs -cd temp && "$(GHC)" -v0 -package-db="$(PACKAGEDB)" Foo.hs -fforce-recomp setup2 : @echo @echo 222222222222222222222222222222222 @echo - Install package @echo - Remove a module from 'exposed-modules' @echo - Reinstall package @echo - Run some tests @echo cabal install -v0 --with-ghc="$(GHC)" sed -i '/System.FilePath.Posix/d' filepath.cabal cabal install -v0 --with-ghc="$(GHC)" run2 : @echo @echo FAILURE MODE 2A, same as 1A @echo -cd temp && "$(GHC)" -package-db="$(PACKAGEDB)" -e 'import System.FilePath.Posix' @echo @echo FAILURE MODE 2B @echo -cd temp && "$(GHC)" -package-db="$(PACKAGEDB)" -e 'import System.FilePath' -e 'takeFileName "foo/bar"' @echo @echo FAILURE MODE 2C @echo echo 'import System.FilePath' > temp/Foo.hs echo 'main = print $$ takeFileName "foo/bar"' >> temp/Foo.hs -cd temp && "$(GHC)" -package-db="$(PACKAGEDB)" Foo.hs -fforce- recomp }}} Output (run `make`): {{{ # FAILURE MODE 1A # # cd temp && "ghc-7.10.3" -v0 -package-db="../.cabal-sandbox/x86_64-linux- ghc-7.10.3-packages.conf.d/" -e 'import System.FilePath.Posix' # # : # Could not find module ?System.FilePath.Posix? # It is a member of the hidden package ?filepath-1.4.0.0 at filep_Ey7a1in9roBAE8bUFJ5R9m?. # make[1]: [run1] Error 1 (ignored) # # FAILURE MODE 1B # # cd temp && "ghc-7.10.3" -v0 -package-db="../.cabal-sandbox/x86_64-linux- ghc-7.10.3-packages.conf.d/" -e 'import System.FilePath' -e 'takeFileName "foo/bar"' # : Failed to load interface for ?System.FilePath.Posix? # Perhaps you haven't installed the "dyn" libraries for package ?filepath-99999.1.0?? # Use -v to see a list of the files searched for. # make[1]: [run1] Error 1 (ignored) # # FAILURE MODE 1C # # echo 'import System.FilePath' > temp/Foo.hs # echo 'main = print $ takeFileName "foo/bar"' >> temp/Foo.hs # cd temp && "ghc-7.10.3" -v0 -package-db="../.cabal-sandbox/x86_64-linux- ghc-7.10.3-packages.conf.d/" Foo.hs -fforce-recomp # Failed to load interface for ?System.FilePath.Posix? # There are files missing in the ?filepath-99999.1.0? package, # try running 'ghc-pkg check'. # Use -v to see a list of the files searched for. # make[1]: [run1] Error 1 (ignored) }}} More output: {{{ # FAILURE MODE 2A, same as 1A # # cd temp && "ghc-7.10.3" -package-db="../.cabal-sandbox/x86_64-linux- ghc-7.10.3-packages.conf.d/" -e 'import System.FilePath.Posix' # # : # Could not find module ?System.FilePath.Posix? # It is a member of the hidden package ?filepath-1.4.0.0 at filep_Ey7a1in9roBAE8bUFJ5R9m?. # make[1]: [run2] Error 1 (ignored) # # FAILURE MODE 2B # # cd temp && "ghc-7.10.3" -package-db="../.cabal-sandbox/x86_64-linux- ghc-7.10.3-packages.conf.d/" -e 'import System.FilePath' -e 'takeFileName "foo/bar"' # : # ByteCodeLink.lookupCE # During interactive linking, GHCi couldn't find the following symbol: # filepzuDQlytQXekB83614cuzzvF62_SystemziFilePathziPosix_takeFileName_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 # # make[1]: [run2] Error 1 (ignored) # # FAILURE MODE 2C # # echo 'import System.FilePath' > temp/Foo.hs # echo 'main = print $ takeFileName "foo/bar"' >> temp/Foo.hs # cd temp && "ghc-7.10.3" -package-db="../.cabal-sandbox/x86_64-linux- ghc-7.10.3-packages.conf.d/" Foo.hs -fforce-recomp # [1 of 1] Compiling Main ( Foo.hs, Foo.o ) # Linking Foo ... # Foo.o: In function `sKS_info': # (.text+0xae): undefined reference to `filepzuDQlytQXekB83614cuzzvF62_SystemziFilePathziPosix_takeFileName_closure' # Foo.o: In function `SLc_srt': # (.data+0x88): undefined reference to `filepzuDQlytQXekB83614cuzzvF62_SystemziFilePathziPosix_takeFileName_closure' # collect2: error: ld returned 1 exit status # make[1]: [run2] Error 1 (ignored) }}} == Analysis * 1A: why mention a hidden (global) package, when it is hidden by a *broken* package. * 1B: misleading suggestion about "dyn" libraries * 1C: why does GHC say I should run ghc-pkg, but 'ghc-pkg check' says everything is fine? * 2A: same as 1A * 2B: scary: ByteCodeLink.lookupCE * 2C: terrible: undefined reference == Bonus With ghc-8.0.1-rc1, failure modes 1B, 1C, 2B and 2C look like this: {{{ # [1 of 1] Compiling Main ( Foo.hs, Foo.o ) # # Foo.hs:1:1: error: # Bad interface file: /home/thomas/tmp/test/filepath/.cabal- sandbox/lib/x86_64-linux- ghc-8.0.0.20160127/filepath-1.4.1.0-87VdeZTuOMDJQ40Wd1kNnE/System/FilePath.hi # Something is amiss; requested module filepath-1.4.1.0 at filepath-1.4.1.0-435e90352be17e51f8e362eb5810bcd5:System.FilePath differs from name found in the interface file filep_87VdeZTuOMDJQ40Wd1kNnE:System.FilePath # make: [run2] Error 1 (ignored) }}} Related tickets: * https://github.com/haskell/cabal/issues/2982: Cabal will build and install broken library if other-modules is not complete * https://github.com/haskell/cabal/issues/3093: Missing files in package * #9009 Confusing error message when loading package with TH * #11023: ghci and ghc-pkg disagree about what's exposed * #8060: Undefined symbols when using Template Haskell linked from another object with unexposed modules #8060 was closed with: > GHC is not really in the business of checking the well-formedness of archive files installed in the package database, so there is not much GHC can do here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 03:49:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 03:49:20 -0000 Subject: [GHC] #11535: Derived instance of Read/Show causes runtime exception for infix Unicode value constructors In-Reply-To: <045.263be43d8d65688efb1e343588c8d0d5@haskell.org> References: <045.263be43d8d65688efb1e343588c8d0d5@haskell.org> Message-ID: <060.c60119e49db3b433b2ef51bf065f260c@haskell.org> #11535: Derived instance of Read/Show causes runtime exception for infix Unicode value constructors -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1544, #11529 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nushio): The condition for this bug is that the infix value constructor has at least one Unicode character. The prefix value constructors with Unicode characters, as well as infix value constructors without Unicode characters, works fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 04:02:49 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 04:02:49 -0000 Subject: [GHC] #11532: ghc: panic! occured In-Reply-To: <045.2d3308752fa81c80b55c3625ddb38f5a@haskell.org> References: <045.2d3308752fa81c80b55c3625ddb38f5a@haskell.org> Message-ID: <060.2484eb73d87ada5d7eb8a145399e645e@haskell.org> #11532: ghc: panic! occured -------------------------------------+------------------------------------- Reporter: cutsea | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by cutsea): Thanks for your replys. > Cutsea, have you been able to reproduce this after cleaning your source tree? I can reproduce this by following: {{{ $ mkdir sandbox $ cd sandbox $ cabal sandbox init $ cabal install metadata }}} By the way, my environment after occuring panic is: {{{ $ uname -a Linux kona 4.3.0-1-amd64 #1 SMP Debian 4.3.3-7 (2016-01-19) x86_64 GNU/Linux $ cabal sandbox hc-pkg list /usr/lib/ghc/package.conf.d Cabal-1.22.5.0 array-0.5.1.0 base-4.8.2.0 bin-package-db-0.0.0.0 binary-0.7.5.0 bytestring-0.10.6.0 containers-0.5.6.2 deepseq-1.4.1.1 directory-1.2.2.0 filepath-1.4.0.0 ghc-7.10.3 ghc-prim-0.4.0.0 haskeline-0.7.2.1 hoopl-3.10.0.2 hpc-0.6.0.2 integer-gmp-1.0.0.0 pretty-1.1.2.0 process-1.2.3.0 rts-1.0 template-haskell-2.10.0.0 terminfo-0.4.0.1 time-1.5.0.1 transformers-0.4.2.0 unix-2.7.1.0 xhtml-3000.2.1 /home/cutsea110/devel/haskell/sandbox/.cabal-sandbox/x86_64-linux- ghc-7.10.3-packages.conf.d text-1.2.2.0 }}} And my ghc is installed by using apt-get(debian package). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 04:03:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 04:03:47 -0000 Subject: [GHC] #11535: Derived instance of Read/Show causes runtime exception for infix Unicode value constructors In-Reply-To: <045.263be43d8d65688efb1e343588c8d0d5@haskell.org> References: <045.263be43d8d65688efb1e343588c8d0d5@haskell.org> Message-ID: <060.bf2c30f8921f656a15b0de6a964e3411@haskell.org> #11535: Derived instance of Read/Show causes runtime exception for infix Unicode value constructors -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: unicode Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1544, #11529 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => unicode Comment: nushio: maybe you could look into the cause and send a patch? See [wiki:Newcomers] and [wiki:WorkingConventions/FixingBugs]. Other unicode related tickets: [[TicketQuery(status=!closed,keywords=~unicode)]] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 04:19:33 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 04:19:33 -0000 Subject: [GHC] #11529: Show instance of Char should print literals for non-ascii printable charcters In-Reply-To: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> References: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> Message-ID: <060.0ebd66b1bc646d7d25d8d3d2bae12899@haskell.org> #11529: Show instance of Char should print literals for non-ascii printable charcters -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: | -------------------------------------+------------------------------------- Comment (by thomie): GHCi could be changed to show unicode characters nicely by default. The code is in the function `tcUserStmt` in `compiler/typecheck/TcRnDriver.hs`. Expressions: {{{ -- The plans are: -- A. [it <- e; print it] but not if it::() -- B. [it <- e] -- C. [let it = e; print it] }}} Statements: {{{ -- The plans are: -- [stmt; print v] if one binder and not v::() -- [stmt] otherwise }}} Replace `print` by `putStrLn . uShow`, with a suitable `uShow`. That shouldn't break anyone's code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 04:45:22 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 04:45:22 -0000 Subject: [GHC] #11529: Show instance of Char should print literals for non-ascii printable charcters In-Reply-To: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> References: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> Message-ID: <060.78db52b8a7572b6c2f4ee73f556fc45c@haskell.org> #11529: Show instance of Char should print literals for non-ascii printable charcters -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => new * resolution: invalid => Comment: Oh, silly me, `print` in `tcUserStmt` of course uses that interactive printer setting I mentioned in comment:4. So my suggestion is to change the default interactive printer to display unicode characters nicely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 04:46:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 04:46:04 -0000 Subject: [GHC] #11529: Show instance of Char should print literals for non-ascii printable charcters In-Reply-To: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> References: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> Message-ID: <060.e9ced83b03afbb45966f87b69633c5bb@haskell.org> #11529: Show instance of Char should print literals for non-ascii printable charcters -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): There is also a bug, `ghci -fprint-bind-result` doesn't use the interactive printer for statements: {{{ Prelude> :set -fprint-bind-result Prelude> let x = "??" "\12398\29238" Prelude> "??" "??" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 05:19:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 05:19:05 -0000 Subject: [GHC] #11535: Derived instance of Read/Show causes runtime exception for infix Unicode value constructors In-Reply-To: <045.263be43d8d65688efb1e343588c8d0d5@haskell.org> References: <045.263be43d8d65688efb1e343588c8d0d5@haskell.org> Message-ID: <060.f499b7679188dd3c987e8a2df0899efb@haskell.org> #11535: Derived instance of Read/Show causes runtime exception for infix Unicode value constructors -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: unicode Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1544, #11529 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nushio): Dear thomie: I'm excited to do so. I have `ghc` source downloaded and was able to compile it. Do you know where the deriving algorithm for `Read` is implemented? It will be helpful. Or, maybe should I ask in haskell-cafe ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 09:27:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 09:27:00 -0000 Subject: [GHC] #11162: T783 regresses severely in allocations with new pattern match checker In-Reply-To: <046.e9f04abec159fcbe6066b924b6d5e3f9@haskell.org> References: <046.e9f04abec159fcbe6066b924b6d5e3f9@haskell.org> Message-ID: <061.b84190f9337bf6bcbe8bce8ce1a0b1ac@haskell.org> #11162: T783 regresses severely in allocations with new pattern match checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T783 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"28f951edfe50ea5182065144340061ec326781f5/ghc" 28f951e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="28f951edfe50ea5182065144340061ec326781f5" Overhaul the Overhauled Pattern Match Checker Overhaul the Overhauled Pattern Match Checker * Changed the representation of Value Set Abstractions. Instead of using a prefix tree, we now use a list of Value Vector Abstractions. The set of constraints Delta for every Value Vector Abstraction is the oracle state so that we solve everything only once. * Instead of doing everything lazily, we prune at once (and in general everything is much stricter). Hence, an example written with pattern guards is checked in almost the same time as the equivalent with pattern matching. * Do not store the covered and the divergent sets at all. Since what we only need is a yes/no (does this clause cover anything? Does it force any thunk?) We just keep a boolean for each. * Removed flags `-Wtoo-many-guards` and `-ffull-guard-reasoning`. Replaced with `fmax-pmcheck-iterations=n`. Still debatable what should the default `n` be. * When a guard is for sure not going to contribute anything, we treat it as such: The oracle is not called and cases `CGuard`, `UGuard` and `DGuard` from the paper are not happening at all (the generation of a fresh variable, the unfolding of the pattern list etc.). his combined with the above seems to be enough to drop the memory increase for test T783 down to 18.7%. * Do not export function `dsPmWarn` (it is now called directly from within `checkSingle` and `checkMatches`). * Make `PmExprVar` hold a `Name` instead of an `Id`. The term oracle does not handle type information so using `Id` was a waste of time/space. * Added testcases T11195, T11303b (data families) and T11374 The patch addresses at least the following: Trac #11195, #11276, #11303, #11374, #11162 Test Plan: validate Reviewers: goldfire, bgamari, hvr, austin Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1795 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 09:27:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 09:27:00 -0000 Subject: [GHC] #11195: New pattern-match check can be non-performant In-Reply-To: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> References: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> Message-ID: <062.60065871da7eefbdbfe2211bdadb3564@haskell.org> #11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1676 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"28f951edfe50ea5182065144340061ec326781f5/ghc" 28f951e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="28f951edfe50ea5182065144340061ec326781f5" Overhaul the Overhauled Pattern Match Checker Overhaul the Overhauled Pattern Match Checker * Changed the representation of Value Set Abstractions. Instead of using a prefix tree, we now use a list of Value Vector Abstractions. The set of constraints Delta for every Value Vector Abstraction is the oracle state so that we solve everything only once. * Instead of doing everything lazily, we prune at once (and in general everything is much stricter). Hence, an example written with pattern guards is checked in almost the same time as the equivalent with pattern matching. * Do not store the covered and the divergent sets at all. Since what we only need is a yes/no (does this clause cover anything? Does it force any thunk?) We just keep a boolean for each. * Removed flags `-Wtoo-many-guards` and `-ffull-guard-reasoning`. Replaced with `fmax-pmcheck-iterations=n`. Still debatable what should the default `n` be. * When a guard is for sure not going to contribute anything, we treat it as such: The oracle is not called and cases `CGuard`, `UGuard` and `DGuard` from the paper are not happening at all (the generation of a fresh variable, the unfolding of the pattern list etc.). his combined with the above seems to be enough to drop the memory increase for test T783 down to 18.7%. * Do not export function `dsPmWarn` (it is now called directly from within `checkSingle` and `checkMatches`). * Make `PmExprVar` hold a `Name` instead of an `Id`. The term oracle does not handle type information so using `Id` was a waste of time/space. * Added testcases T11195, T11303b (data families) and T11374 The patch addresses at least the following: Trac #11195, #11276, #11303, #11374, #11162 Test Plan: validate Reviewers: goldfire, bgamari, hvr, austin Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1795 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 09:27:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 09:27:00 -0000 Subject: [GHC] #11374: `-Woverlapping-patterns` induced memory-blowup In-Reply-To: <042.6456ce80d8d3e5aa2bba8ee798efc810@haskell.org> References: <042.6456ce80d8d3e5aa2bba8ee798efc810@haskell.org> Message-ID: <057.401ea4b1ecf606c5b0eaa51c2d93e536@haskell.org> #11374: `-Woverlapping-patterns` induced memory-blowup -------------------------------------+------------------------------------- Reporter: hvr | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: pattern | checker, PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"28f951edfe50ea5182065144340061ec326781f5/ghc" 28f951e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="28f951edfe50ea5182065144340061ec326781f5" Overhaul the Overhauled Pattern Match Checker Overhaul the Overhauled Pattern Match Checker * Changed the representation of Value Set Abstractions. Instead of using a prefix tree, we now use a list of Value Vector Abstractions. The set of constraints Delta for every Value Vector Abstraction is the oracle state so that we solve everything only once. * Instead of doing everything lazily, we prune at once (and in general everything is much stricter). Hence, an example written with pattern guards is checked in almost the same time as the equivalent with pattern matching. * Do not store the covered and the divergent sets at all. Since what we only need is a yes/no (does this clause cover anything? Does it force any thunk?) We just keep a boolean for each. * Removed flags `-Wtoo-many-guards` and `-ffull-guard-reasoning`. Replaced with `fmax-pmcheck-iterations=n`. Still debatable what should the default `n` be. * When a guard is for sure not going to contribute anything, we treat it as such: The oracle is not called and cases `CGuard`, `UGuard` and `DGuard` from the paper are not happening at all (the generation of a fresh variable, the unfolding of the pattern list etc.). his combined with the above seems to be enough to drop the memory increase for test T783 down to 18.7%. * Do not export function `dsPmWarn` (it is now called directly from within `checkSingle` and `checkMatches`). * Make `PmExprVar` hold a `Name` instead of an `Id`. The term oracle does not handle type information so using `Id` was a waste of time/space. * Added testcases T11195, T11303b (data families) and T11374 The patch addresses at least the following: Trac #11195, #11276, #11303, #11374, #11162 Test Plan: validate Reviewers: goldfire, bgamari, hvr, austin Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1795 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 09:27:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 09:27:00 -0000 Subject: [GHC] #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker In-Reply-To: <046.076adf4676a7bff5c198511775a24988@haskell.org> References: <046.076adf4676a7bff5c198511775a24988@haskell.org> Message-ID: <061.71711cf6b86d235d0828724b26bb6b69@haskell.org> #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T11303 Blocked By: | Blocking: Related Tickets: #11276, #11302 | Differential Rev(s): Phab:D1716, Wiki Page: | Phab:D1719 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"28f951edfe50ea5182065144340061ec326781f5/ghc" 28f951e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="28f951edfe50ea5182065144340061ec326781f5" Overhaul the Overhauled Pattern Match Checker Overhaul the Overhauled Pattern Match Checker * Changed the representation of Value Set Abstractions. Instead of using a prefix tree, we now use a list of Value Vector Abstractions. The set of constraints Delta for every Value Vector Abstraction is the oracle state so that we solve everything only once. * Instead of doing everything lazily, we prune at once (and in general everything is much stricter). Hence, an example written with pattern guards is checked in almost the same time as the equivalent with pattern matching. * Do not store the covered and the divergent sets at all. Since what we only need is a yes/no (does this clause cover anything? Does it force any thunk?) We just keep a boolean for each. * Removed flags `-Wtoo-many-guards` and `-ffull-guard-reasoning`. Replaced with `fmax-pmcheck-iterations=n`. Still debatable what should the default `n` be. * When a guard is for sure not going to contribute anything, we treat it as such: The oracle is not called and cases `CGuard`, `UGuard` and `DGuard` from the paper are not happening at all (the generation of a fresh variable, the unfolding of the pattern list etc.). his combined with the above seems to be enough to drop the memory increase for test T783 down to 18.7%. * Do not export function `dsPmWarn` (it is now called directly from within `checkSingle` and `checkMatches`). * Make `PmExprVar` hold a `Name` instead of an `Id`. The term oracle does not handle type information so using `Id` was a waste of time/space. * Added testcases T11195, T11303b (data families) and T11374 The patch addresses at least the following: Trac #11195, #11276, #11303, #11374, #11162 Test Plan: validate Reviewers: goldfire, bgamari, hvr, austin Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1795 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 09:27:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 09:27:00 -0000 Subject: [GHC] #11276: GHC hangs/takes an exponential amount of time with simple program In-Reply-To: <049.2c7953798565542d8f2944995450a8e6@haskell.org> References: <049.2c7953798565542d8f2944995450a8e6@haskell.org> Message-ID: <064.02c527d28375e53a0136ccb858bfdf60@haskell.org> #11276: GHC hangs/takes an exponential amount of time with simple program -------------------------------------+------------------------------------- Reporter: mpickering | Owner: gkaracha Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: pattern | checker, PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1795 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"28f951edfe50ea5182065144340061ec326781f5/ghc" 28f951e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="28f951edfe50ea5182065144340061ec326781f5" Overhaul the Overhauled Pattern Match Checker Overhaul the Overhauled Pattern Match Checker * Changed the representation of Value Set Abstractions. Instead of using a prefix tree, we now use a list of Value Vector Abstractions. The set of constraints Delta for every Value Vector Abstraction is the oracle state so that we solve everything only once. * Instead of doing everything lazily, we prune at once (and in general everything is much stricter). Hence, an example written with pattern guards is checked in almost the same time as the equivalent with pattern matching. * Do not store the covered and the divergent sets at all. Since what we only need is a yes/no (does this clause cover anything? Does it force any thunk?) We just keep a boolean for each. * Removed flags `-Wtoo-many-guards` and `-ffull-guard-reasoning`. Replaced with `fmax-pmcheck-iterations=n`. Still debatable what should the default `n` be. * When a guard is for sure not going to contribute anything, we treat it as such: The oracle is not called and cases `CGuard`, `UGuard` and `DGuard` from the paper are not happening at all (the generation of a fresh variable, the unfolding of the pattern list etc.). his combined with the above seems to be enough to drop the memory increase for test T783 down to 18.7%. * Do not export function `dsPmWarn` (it is now called directly from within `checkSingle` and `checkMatches`). * Make `PmExprVar` hold a `Name` instead of an `Id`. The term oracle does not handle type information so using `Id` was a waste of time/space. * Added testcases T11195, T11303b (data families) and T11374 The patch addresses at least the following: Trac #11195, #11276, #11303, #11374, #11162 Test Plan: validate Reviewers: goldfire, bgamari, hvr, austin Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1795 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 11:10:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 11:10:24 -0000 Subject: [GHC] #11494: Add -Wcompat to -Wall In-Reply-To: <046.4883b5c7ccf037dba12555f655b97205@haskell.org> References: <046.4883b5c7ccf037dba12555f655b97205@haskell.org> Message-ID: <061.bbd6d4468910ea465abdc86744726107@haskell.org> #11494: Add -Wcompat to -Wall -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings| #To-Wcompat-Wallornot11494 | -------------------------------------+------------------------------------- Changes (by bgamari): * wikipage: => https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings#To-Wcompat- Wallornot11494 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 11:20:09 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 11:20:09 -0000 Subject: [GHC] #11494: Add -Wcompat to -Wall In-Reply-To: <046.4883b5c7ccf037dba12555f655b97205@haskell.org> References: <046.4883b5c7ccf037dba12555f655b97205@haskell.org> Message-ID: <061.be02d63b89416ca9bf6267dda1c40032@haskell.org> #11494: Add -Wcompat to -Wall -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | https://ghc.haskell.org/trac/ghc/wiki/Design/Warnings| #To-Wcompat-Wallornot11494 | -------------------------------------+------------------------------------- Comment (by bgamari): Edward has said that Relevant discussion, * November 2015: [[https://mail.haskell.org/pipermail/libraries/2015-November/026512.html|"3 release policy and -Wno-compat"]] on libraries@ * January 2016: [[https://mail.haskell.org/pipermail/ghc- devs/2016-January/010955.html|"Warnings, -Wall, and versioning policy"]] on ghc-devs@, ghc-users@ * #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" * The [[https://prime.haskell.org/wiki/Libraries/3-Release-Policy|Three- Release Policy]] on Haskell Prime wiki * October 2015: [[https://mail.haskell.org/pipermail/libraries/2015-October/026348.html|3 release policy]] on libraries@ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 11:58:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 11:58:04 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.87b7752fa2052be039e4ee84dd8dc5a3@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > I can't define {{{ type Fun c d f = Functor (Dom f) (Cod f) f }}} No indeed. So don't. Just have a single-parameter `Functor` class! {{{ class Functor (f :: i -> j) where type Dom f :: i -> i -> * type Cod f :: j -> j -> * }}} Now, I understand you are saying "a single-parameter `Functor` class is exactly what I would like but there is a problem". So rather than fix difficulties with the workaround, let's fix the actual problem. What exactly is it? What type family do you need to partially apply? So far we have `Dom` and `Cod`. Do you need to partially apply those? Can you just walk me through slowly the exact problem with the direct approach? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 11:58:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 11:58:56 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.5dbb5f28abd08db98408409cacb6de9d@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:9 ekmett]: > But there are other examples where this would be useful. e.g. `mtl` uses functional dependencies rather than type families, because the fundep versions of the type signatures are always less verbose Can you give concrete examples? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 12:33:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 12:33:18 -0000 Subject: [GHC] #11535: Derived instance of Read/Show causes runtime exception for infix Unicode value constructors In-Reply-To: <045.263be43d8d65688efb1e343588c8d0d5@haskell.org> References: <045.263be43d8d65688efb1e343588c8d0d5@haskell.org> Message-ID: <060.999199ffcc45f1caca039698a05c8ff0@haskell.org> #11535: Derived instance of Read/Show causes runtime exception for infix Unicode value constructors -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: unicode Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1544, #11529 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Search for `Read instances` in `compiler/typecheck/TcGenDeriv.hs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 12:59:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 12:59:52 -0000 Subject: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled In-Reply-To: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> References: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> Message-ID: <061.39f35614f897cf698292dbf411803757@haskell.org> #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Aha. I was looking in the wrong place. Good explanation. I've added a comment to the test to flag this up. Now I understand, and we've documented that understanding, I'm happy to close this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 13:03:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 13:03:50 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.6cbee55152014ee86e9a46c719f7e57b@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): > What type family do you need to partially apply? Given the single parameter `Functor` class, I would need to be able to supply something with kind `(i -> j) -> Constraint`, that says that its type argument is not just a Functor, but has a given `Dom` and a given `Cod`. {{{#!hs class (Functor f, Dom f ~ c, Cod f ~ d) => FunctorOf c d f | f -> c d instance (Functor f, Dom f ~ c, Cod f ~ d) => FunctorOf c d f }}} acts just like the type synonym {{{#!hs type FunctorOf c d f = (Functor f, Dom f ~ c, Cod f ~ d) }}} ''except'' it can be partially applied to the first two arguments to fix the Dom and Cod of its argument, whereas the type synonym version can't must be supplied all three arguments. Now I can answer > What type family do you need to partially apply? The answer is `FunctorOf c d`. This lets me write the line {{{#!hs instance (Category p, Category q) => Category (Nat p q) where type Ob (Nat p q) = FunctorOf p q }}} Because I can "partially apply" FunctorOf p q to get something of kind `(i -> j) -> Constraint`. Unfortunately, as noted with #11523 with `UndecidableSuperClasses` turned on, I spin forever trying to use the `FunctorOf` definition in this place. The "obvious" fix then is to go through and replace the class associated type `Ob f :: i -> Constraint` with `type Ob f a :: Constraint`, but take an extra argument fails because I ultimately wind up needing to claim that `Ob (Nat p q)` is a functor from `p` to the category of constraints and it can't be if it can't be partially applied in its own right. Similar issues arise forcing the class/instance trick to deal with constraints elsewhere: {{{#!hs class (p, q) => p & q instance (p, q) => p & q }}} let's me talk about `(&) :: Constraint -> Constraint -> Constraint` or `(&) (Eq a) :: Constraint -> Constraint)`, whereas only a fully applied pair at the type level can be spoken of due to the limitations of the syntactic / semantic hack that we have in place for products of constraints. > Can you give concrete examples? Every single definition in the `monads-tf` library has a significantly more verbose type signature than the ones in the `mtl`. {{{#!hs modify :: MonadState s m => (s -> s) -> m () tell :: MonadWriter e m => e -> m () ask :: MonadReader e m => m e local :: MonadReader e m => (e -> e) -> m a -> m a }}} vs. {{{#!hs modify :: MonadState m => (StateType m -> StateType m) -> m () tell :: MonadWriter m => WriterType m -> m () ask :: MonadReader m => m (EnvType m) local :: MonadReader m => (EnvType m -> EnvType m) -> m a -> m a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 13:09:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 13:09:42 -0000 Subject: [GHC] #7593: Unable to print exceptions of unicode identifiers In-Reply-To: <044.180348374c60284a01c4dfa59f341d42@haskell.org> References: <044.180348374c60284a01c4dfa59f341d42@haskell.org> Message-ID: <059.e3c244823a86c9b41523abcd3d27babd@haskell.org> #7593: Unable to print exceptions of unicode identifiers -------------------------------------+------------------------------------- Reporter: dagit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by HairyDude): Same as #8118? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 13:12:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 13:12:40 -0000 Subject: [GHC] #8118: : commitAndReleaseBuffer: invalid argument (invalid character) In-Reply-To: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> References: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> Message-ID: <059.06f245ffac7cda924c08a577262ea2f0@haskell.org> #8118: : commitAndReleaseBuffer: invalid argument (invalid character) -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #5666 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by HairyDude): * status: infoneeded => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 14:22:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 14:22:56 -0000 Subject: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled In-Reply-To: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> References: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> Message-ID: <061.5492d223041ea49205eba35cb2b0dc28@haskell.org> #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Before we close this, don't we still need to add the flag? Or maybe break out that part of `TcCoercibleFail` into a new test that is disabled in DEBUG mode? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 14:40:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 14:40:24 -0000 Subject: [GHC] #8118: : commitAndReleaseBuffer: invalid argument (invalid character) In-Reply-To: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> References: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> Message-ID: <059.2c4ce3bc49f159f0ac62fb750dc1cca5@haskell.org> #8118: : commitAndReleaseBuffer: invalid argument (invalid character) -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #5666 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:17 HairyDude]: > This gets correct output: > > {{{ > import GHC.IO.Encoding > import System.Win32.Console > > main = do > ... > setLocaleEncoding utf8 > setConsoleOutputCP 65001 > ... > }}} ''If you're only dealing with files''. If you attempt to read/write from the console, things still break: {{{#!hs import GHC.IO.Encoding import System.Win32.Console main :: IO () main = do setLocaleEncoding utf8 setConsoleOutputCP 65001 putStrLn "?" }}} {{{ *Main> main *** Exception: : hPutChar: invalid argument (invalid character) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 16:00:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 16:00:52 -0000 Subject: [GHC] #11276: GHC hangs/takes an exponential amount of time with simple program In-Reply-To: <049.2c7953798565542d8f2944995450a8e6@haskell.org> References: <049.2c7953798565542d8f2944995450a8e6@haskell.org> Message-ID: <064.69f8af699aefa46bfc5ccde4ba6fcdbb@haskell.org> #11276: GHC hangs/takes an exponential amount of time with simple program -------------------------------------+------------------------------------- Reporter: mpickering | Owner: gkaracha Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: pattern | checker, PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1795 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 6e23b68047a2c995562eba173fe9485cae18bff2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 16:01:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 16:01:31 -0000 Subject: [GHC] #11374: `-Woverlapping-patterns` induced memory-blowup In-Reply-To: <042.6456ce80d8d3e5aa2bba8ee798efc810@haskell.org> References: <042.6456ce80d8d3e5aa2bba8ee798efc810@haskell.org> Message-ID: <057.e80b5217ed5bbc33307f21517e99cac5@haskell.org> #11374: `-Woverlapping-patterns` induced memory-blowup -------------------------------------+------------------------------------- Reporter: hvr | Owner: gkaracha Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: pattern | checker, PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-8.0` as 6e23b68047a2c995562eba173fe9485cae18bff2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 16:01:37 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 16:01:37 -0000 Subject: [GHC] #11374: `-Woverlapping-patterns` induced memory-blowup In-Reply-To: <042.6456ce80d8d3e5aa2bba8ee798efc810@haskell.org> References: <042.6456ce80d8d3e5aa2bba8ee798efc810@haskell.org> Message-ID: <057.6af9b2c3262e5e238b5c071e184c2a88@haskell.org> #11374: `-Woverlapping-patterns` induced memory-blowup -------------------------------------+------------------------------------- Reporter: hvr | Owner: gkaracha Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: pattern | checker, PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 16:13:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 16:13:44 -0000 Subject: [GHC] #11474: incorrect redundant-constraints warning In-Reply-To: <042.2e15408ecc3253cf7591957da36697cd@haskell.org> References: <042.2e15408ecc3253cf7591957da36697cd@haskell.org> Message-ID: <057.5900d13d76c57fc31c451cb063415e67@haskell.org> #11474: incorrect redundant-constraints warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: highest => normal * milestone: 8.0.1 => 8.2.1 Comment: Given that this warning is now disabled by default I'm reducing priority and bumping off to 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 16:15:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 16:15:43 -0000 Subject: [GHC] #11401: No match in record selector ctev_dest In-Reply-To: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> References: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> Message-ID: <061.242d84eb869f371d512399426869fc4d@haskell.org> #11401: No match in record selector ctev_dest -------------------------------------+------------------------------------- Reporter: Lemming | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 Lemming): With ghc-8.0.0.20160202 I get the same error at a different place. Maybe this allows me to extract a simpler example code. Are you interested? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 16:31:19 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 16:31:19 -0000 Subject: [GHC] #11401: No match in record selector ctev_dest In-Reply-To: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> References: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> Message-ID: <061.cda638c0f05ff8eb8955aa8796a309c3@haskell.org> #11401: No match in record selector ctev_dest -------------------------------------+------------------------------------- Reporter: Lemming | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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): Not if it's much trouble. I think this one should be easy to track down. But I have to finish #11471 first, as that's a larger change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 17:28:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 17:28:52 -0000 Subject: [GHC] #8118: : commitAndReleaseBuffer: invalid argument (invalid character) In-Reply-To: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> References: <044.02f6a3ad6829765cf7e851ab9bdf063d@haskell.org> Message-ID: <059.68f0096e92e9db75c77edb6d6adaf38a@haskell.org> #8118: : commitAndReleaseBuffer: invalid argument (invalid character) -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: #5666 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by HairyDude): Odd. It works if you compile the program, but not from GHCi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 17:46:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 17:46:17 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.fc6e85c81c9e159004cad59abba61ec7@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I have a fix for this. Patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 17:47:02 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 17:47:02 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.1b78e2b29c96a2fc6dd29c517ddc2d71@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Very interesting. But the short term fix is to fix the original problem, with #11523, which I've now done (patch coming). SO that may unglue you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 19:32:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 19:32:05 -0000 Subject: [GHC] #11537: GHC fails to compile if source is in /ghc Message-ID: <050.7c1644d435e2a21ad9636a7eb5cb10e7@haskell.org> #11537: GHC fails to compile if source is in /ghc -------------------------------------+------------------------------------- Reporter: wereHamster | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was building GHC in a docker image and was ignorant what the $PWD is (it is / in case you were wondering). So I cloned GHC into /ghc, and attempted to build it from there. Eventually the build fails because there is a sed expression `'s|$(TOP)/|...'` which rewrites some include paths to nonesense: /usr/lib/ghc/include/... -> /usr/libinclude/... Anchoring the expression (`'s|^$(TOP)/|...'`) helped the build process to continue past that point, but I haven't completed it due to other issue, so there may be other places where $(TOP) == /ghc breaks the build. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 19:57:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 19:57:56 -0000 Subject: [GHC] #11537: GHC fails to compile if source is in /ghc In-Reply-To: <050.7c1644d435e2a21ad9636a7eb5cb10e7@haskell.org> References: <050.7c1644d435e2a21ad9636a7eb5cb10e7@haskell.org> Message-ID: <065.670685db3dd3dd1109eec30172fa5440@haskell.org> #11537: GHC fails to compile if source is in /ghc -------------------------------------+------------------------------------- Reporter: wereHamster | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Build System -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 21:16:34 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 21:16:34 -0000 Subject: [GHC] #11538: Wrong constants in LL code for big endian targets Message-ID: <050.18528b91e1735921204df2d5fcfc07a6@haskell.org> #11538: Wrong constants in LL code for big endian targets -------------------------------------+------------------------------------- Reporter: wereHamster | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (LLVM) | Keywords: | Operating System: Unknown/Multiple Architecture: mips | Type of failure: Building GHC | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm trying to compile GHC for a big endian MIPS target (MIPS 24Kc, Atheros AR9330). The generated code for the `negateFloat` function has the following line: `%ln3uf = fsub float 0x0000000000000080, %ln3ue` But the constant should be `0x8000000000000000` instead. See todays discussion in #ghc between wereHamster and rwbarton for more details and possible hints how/where to fix this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 21:17:39 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 21:17:39 -0000 Subject: [GHC] #11538: Wrong constants in LL code for big endian targets In-Reply-To: <050.18528b91e1735921204df2d5fcfc07a6@haskell.org> References: <050.18528b91e1735921204df2d5fcfc07a6@haskell.org> Message-ID: <065.dd73e04232940fcafe6ca93f4a2f4e61@haskell.org> #11538: Wrong constants in LL code for big endian targets ----------------------------------------+---------------------------- Reporter: wereHamster | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: mips Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+---------------------------- Comment (by wereHamster): Note that I'm building a cross-compiler, so host != target (in particular, they have different endianess, x32 LE vs mips BE) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 22:02:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 22:02:11 -0000 Subject: [GHC] #11539: Warn about missing forall when -XScopedTypeVariables is on Message-ID: <045.6c55e4ce55a104b4103356eb9a3637a1@haskell.org> #11539: Warn about missing forall when -XScopedTypeVariables is on -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.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've ran into a situation where I forgot to put an explicit forall to actually make type variables scoped, resulting in something like {{{ Could not deduce (PacketTypeId s0 t0 a0) arising from a use of ?fromPacketTypeId? from the context (PacketTypeId s t n) }}} with code like {{{ getPacketTypeId :: PacketTypeId s t n => KnxPacket d s t -> Integer getPacketTypeId _ = fromPacketTypeId (Proxy :: Proxy s) (Proxy :: Proxy t)) :: Integer }}} It'd be nice if GHC printed an extra suggestion "Did you forget to include an explicit forall?" when something like that arises? Maybe even suggest ScopedTypeVariables if they're not on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 22:03:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 22:03:00 -0000 Subject: [GHC] #11454: Do not suggest deprecated flags In-Reply-To: <045.65a0f03026a0fefacb4854cc40024538@haskell.org> References: <045.65a0f03026a0fefacb4854cc40024538@haskell.org> Message-ID: <060.e2cf077a957e0892b85649a64518fb23@haskell.org> #11454: Do not suggest deprecated flags -------------------------------------+------------------------------------- Reporter: thomie | Owner: nkartashov Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 nkartashov): * owner: => nkartashov -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 4 22:12:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 04 Feb 2016 22:12:57 -0000 Subject: [GHC] #11454: Do not suggest deprecated flags In-Reply-To: <045.65a0f03026a0fefacb4854cc40024538@haskell.org> References: <045.65a0f03026a0fefacb4854cc40024538@haskell.org> Message-ID: <060.2749f73191f440ca83e66e6e4df45f00@haskell.org> #11454: Do not suggest deprecated flags -------------------------------------+------------------------------------- Reporter: thomie | Owner: nkartashov Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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:D1883 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nkartashov): * differential: => Phab:D1883 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 00:00:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 00:00:05 -0000 Subject: [GHC] #11535: Derived instance of Read/Show causes runtime exception for infix Unicode value constructors In-Reply-To: <045.263be43d8d65688efb1e343588c8d0d5@haskell.org> References: <045.263be43d8d65688efb1e343588c8d0d5@haskell.org> Message-ID: <060.95262b3f22571a70ac0c7414afccc9ed@haskell.org> #11535: Derived instance of Read/Show causes runtime exception for infix Unicode value constructors -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: unicode Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1544, #11529 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nushio): Thank you very much, thomie! With that help now I have located the origin of this bug: {{{ > readPrec_to_S (expectP $ L.Symbol ":+") 0 ":+" [((),"")] > readPrec_to_S (expectP $ L.Symbol ":?") 0 ":?" [] > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 00:20:53 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 00:20:53 -0000 Subject: [GHC] #11535: Derived instance of Read/Show causes runtime exception for infix Unicode value constructors In-Reply-To: <045.263be43d8d65688efb1e343588c8d0d5@haskell.org> References: <045.263be43d8d65688efb1e343588c8d0d5@haskell.org> Message-ID: <060.b6f263452957d985bf2eebe1a2142283@haskell.org> #11535: Derived instance of Read/Show causes runtime exception for infix Unicode value constructors -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: unicode Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1544, #11529 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nushio): I actually found out that this issue #11535 have already been fixed as result of some other work between 7.10.3 and the latest head. What shall I do? I still can submit a patch with test cases for #11535, and I believe it is of some help to the ghc. {{{ ~/hub/ghc (fix-11535)$ cat tmp-lex-test.hs import GHC.Read import Text.ParserCombinators.ReadPrec import qualified Text.Read.Lex as L data X = String :?\& String deriving (Eq, Ord, Show, Read) main :: IO () main = do print $ readPrec_to_S (expectP $ L.Symbol ":+") 0 ":+" print $ readPrec_to_S (expectP $ L.Symbol ":?") 0 ":?" let x = "" :?\& "" d = 0 print $ map fromEnum $ show x print $ (x, "") `elem` (readsPrec d (showsPrec d x "")) print $ (read $ show x :: X) ~/hub/ghc (fix-11535)$ ./inplace/bin/runghc tmp-lex-test.hs [((),"")] [((),"")] [34,34,32,58,9734,92,38,32,34,34] True "" :?\& "" ~/hub/ghc (fix-11535)$ stack runhaskell tmp-lex-test.hs Run from outside a project, using implicit global project config Using resolver: lts-5.0 from implicit global project's config file: /home/nushio/.stack/global-project/stack.yaml [((),"")] [] [34,34,32,58,9734,92,38,32,34,34] False tmp-lex-test.hs: Prelude.read: no parse ~/hub/ghc (fix-11535)$ stack ghc -- --version Run from outside a project, using implicit global project config Using resolver: lts-5.0 from implicit global project's config file: /home/nushio/.stack/global-project/stack.yaml The Glorious Glasgow Haskell Compilation System, version 7.10.3 ~/hub/ghc (fix-11535)$ git log | head -n 1 commit db121b2ec4596b99fed9781ec2d055f29e0d5b20 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 00:30:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 00:30:06 -0000 Subject: [GHC] #11535: Derived instance of Read/Show causes runtime exception for infix Unicode value constructors In-Reply-To: <045.263be43d8d65688efb1e343588c8d0d5@haskell.org> References: <045.263be43d8d65688efb1e343588c8d0d5@haskell.org> Message-ID: <060.1c19bc12db6c1be535019e0a3eb7dfeb@haskell.org> #11535: Derived instance of Read/Show causes runtime exception for infix Unicode value constructors -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: unicode Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1544, #11529 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Oops, sorry for not checking with 8.0 earlier. I don't know which commit fixed it. So yes, a patch for the testsuite would be good. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 04:17:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 04:17:51 -0000 Subject: [GHC] #11535: Derived instance of Read/Show causes runtime exception for infix Unicode value constructors In-Reply-To: <045.263be43d8d65688efb1e343588c8d0d5@haskell.org> References: <045.263be43d8d65688efb1e343588c8d0d5@haskell.org> Message-ID: <060.f7835e98e365b1a7e8ee16a77d386f66@haskell.org> #11535: Derived instance of Read/Show causes runtime exception for infix Unicode value constructors -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: unicode Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1544, #11529 | Differential Rev(s): Phab:D1884 Wiki Page: | -------------------------------------+------------------------------------- Changes (by nushio): * differential: => Phab:D1884 Comment: I am sorry too, for not checking with the HEAD compiler (I did checked with stackage-nightly, but that was still 7.10.3 .) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 06:52:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 06:52:27 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.b94aff4b03990fdf82b58dc03df3ab1a@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Thanks! That will definitely get me unstuck for now, though I confess I'd still like a way to do something like this eventually. It'd go a long way towards ensuring that functional dependencies don't bit rot and cement them as more or less just a syntactic choice, rather than something radically different under the hood. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 09:30:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 09:30:09 -0000 Subject: [GHC] #11540: ghc accepts non-standard type without language extension Message-ID: <047.4af844a129b268095ee1a782d708bfe8@haskell.org> #11540: ghc accepts non-standard type without language extension -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Ghc accepts this {{{ f :: Eq a => Eq b => a -> b -> Bool f a b = a==a && b==b }}} The nested contexts should require some language extension. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 11:19:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 11:19:06 -0000 Subject: [GHC] #11538: Wrong constants in LL code for big endian targets In-Reply-To: <050.18528b91e1735921204df2d5fcfc07a6@haskell.org> References: <050.18528b91e1735921204df2d5fcfc07a6@haskell.org> Message-ID: <065.e1d17c865f0956a1189724f512a05783@haskell.org> #11538: Wrong constants in LL code for big endian targets ----------------------------------------+---------------------------- Reporter: wereHamster | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: mips Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------------+---------------------------- Changes (by bgamari): * Attachment "ghc.log" added. A log of the #ghc discussion -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 14:01:39 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 14:01:39 -0000 Subject: [GHC] #11541: Type errors sometimes has a lot of irrelevant information Message-ID: <047.b489a9355667fda5e49935258d0dd4af@haskell.org> #11541: Type errors sometimes has a lot of irrelevant information -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's an example. The essential part of the error message is {{{ Couldn't match type `DeclS IString TLoc' with `DeclHeadS IString l' }}} This is buried somewhere in the middle. Fixing this problem makes all the others go away. It seems ghc spits out constraints that it hasn't solved, but they are unsolved because there was a type error. Full message: {{{ Stem\Mu\Deriving.hs:214:93: No instance for (Integral b0) arising from a use of `constr' The type variable `b0' is ambiguous Note: there are several potential instances: instance Integral Int -- Defined in `GHC.Real' instance Integral Integer -- Defined in `GHC.Real' instance Integral GHC.Types.Word -- Defined in `GHC.Real' ...plus 8 others In the first argument of `zipWith', namely `constr' In the second argument of `($)', namely `zipWith constr qs [0 .. ]' In the expression: List () $ zipWith constr qs [0 .. ] Stem\Mu\Deriving.hs:214:103: No instance for (Enum b0) arising from the arithmetic sequence `0 .. ' The type variable `b0' is ambiguous Note: there are several potential instances: instance Enum GeneralCategory -- Defined in `Data.Char' instance Enum InlInfo -- Defined in `Cortex.Stem.Mu.Util' instance Enum Double -- Defined in `GHC.Float' ...plus 24 others In the third argument of `zipWith', namely `[0 .. ]' In the second argument of `($)', namely `zipWith constr qs [0 .. ]' In the expression: List () $ zipWith constr qs [0 .. ] Stem\Mu\Deriving.hs:214:104: No instance for (Num b0) arising from the literal `0' The type variable `b0' is ambiguous Note: there are several potential instances: instance Num Double -- Defined in `GHC.Float' instance Num Float -- Defined in `GHC.Float' instance Integral a => Num (GHC.Real.Ratio a) -- Defined in `GHC.Real' ...plus 12 others In the expression: 0 In the third argument of `zipWith', namely `[0 .. ]' In the second argument of `($)', namely `zipWith constr qs [0 .. ]' Stem\Mu\Deriving.hs:285:28: No instance for (Integral a0) arising from a use of `list' The type variable `a0' is ambiguous Note: there are several potential instances: instance Integral Int -- Defined in `GHC.Real' instance Integral Integer -- Defined in `GHC.Real' instance Integral GHC.Types.Word -- Defined in `GHC.Real' ...plus 8 others In the second argument of `($)', namely `list 10 (mkstr (nameString n) : map (ashow (mkInt () 11) . qvar) vs)' In the second argument of `($)', namely `shows $ list 10 (mkstr (nameString n) : map (ashow (mkInt () 11) . qvar) vs)' In the expression: method (PApp () (UnQual () $ dropAnn n) (map (PVar ()) vs)) $ shows $ list 10 (mkstr (nameString n) : map (ashow (mkInt () 11) . qvar) vs) Stem\Mu\Deriving.hs:285:33: No instance for (Num a0) arising from the literal `10' The type variable `a0' is ambiguous Note: there are several potential instances: instance Num Double -- Defined in `GHC.Float' instance Num Float -- Defined in `GHC.Float' instance Integral a => Num (GHC.Real.Ratio a) -- Defined in `GHC.Real' ...plus 12 others In the first argument of `list', namely `10' In the second argument of `($)', namely `list 10 (mkstr (nameString n) : map (ashow (mkInt () 11) . qvar) vs)' In the second argument of `($)', namely `shows $ list 10 (mkstr (nameString n) : map (ashow (mkInt () 11) . qvar) vs)' Stem\Mu\Deriving.hs:285:72: No instance for (Integral a1) arising from a use of `mkInt' The type variable `a1' is ambiguous Note: there are several potential instances: instance Integral Int -- Defined in `GHC.Real' instance Integral Integer -- Defined in `GHC.Real' instance Integral GHC.Types.Word -- Defined in `GHC.Real' ...plus 8 others In the first argument of `ashow', namely `(mkInt () 11)' In the first argument of `(.)', namely `ashow (mkInt () 11)' In the first argument of `map', namely `(ashow (mkInt () 11) . qvar)' Stem\Mu\Deriving.hs:285:81: No instance for (Num a1) arising from the literal `11' The type variable `a1' is ambiguous Note: there are several potential instances: instance Num Double -- Defined in `GHC.Float' instance Num Float -- Defined in `GHC.Float' instance Integral a => Num (GHC.Real.Ratio a) -- Defined in `GHC.Real' ...plus 12 others In the second argument of `mkInt', namely `11' In the first argument of `ashow', namely `(mkInt () 11)' In the first argument of `(.)', namely `ashow (mkInt () 11)' Stem\Mu\Deriving.hs:288:44: No instance for (Show a3) arising from a use of `var' The type variable `a3' is ambiguous Note: there are several potential instances: instance Show GeneralCategory -- Defined in `Data.Char' instance Show IString -- Defined in `Cortex.Utils.IString' instance Show a => Show (Cortex.Utils.List.Down a) -- Defined in `Cortex.Utils.List' ...plus 171 others In the second argument of `PVar', namely `(var 0)' In the second argument of `PInfixApp', namely `(PVar () (var 0))' In the first argument of `method', namely `(PInfixApp () (PVar () (var 0)) (UnQual () $ dropAnn n) (PVar () (var 1)))' Stem\Mu\Deriving.hs:288:48: No instance for (Num a3) arising from the literal `0' The type variable `a3' is ambiguous Note: there are several potential instances: instance Num Double -- Defined in `GHC.Float' instance Num Float -- Defined in `GHC.Float' instance Integral a => Num (GHC.Real.Ratio a) -- Defined in `GHC.Real' ...plus 12 others In the first argument of `var', namely `0' In the second argument of `PVar', namely `(var 0)' In the second argument of `PInfixApp', namely `(PVar () (var 0))' Stem\Mu\Deriving.hs:288:86: No instance for (Show a4) arising from a use of `var' The type variable `a4' is ambiguous Note: there are several potential instances: instance Show GeneralCategory -- Defined in `Data.Char' instance Show IString -- Defined in `Cortex.Utils.IString' instance Show a => Show (Cortex.Utils.List.Down a) -- Defined in `Cortex.Utils.List' ...plus 171 others In the second argument of `PVar', namely `(var 1)' In the fourth argument of `PInfixApp', namely `(PVar () (var 1))' In the first argument of `method', namely `(PInfixApp () (PVar () (var 0)) (UnQual () $ dropAnn n) (PVar () (var 1)))' Stem\Mu\Deriving.hs:288:90: No instance for (Num a4) arising from the literal `1' The type variable `a4' is ambiguous Note: there are several potential instances: instance Num Double -- Defined in `GHC.Float' instance Num Float -- Defined in `GHC.Float' instance Integral a => Num (GHC.Real.Ratio a) -- Defined in `GHC.Real' ...plus 12 others In the first argument of `var', namely `1' In the second argument of `PVar', namely `(var 1)' In the fourth argument of `PInfixApp', namely `(PVar () (var 1))' Stem\Mu\Deriving.hs:289:28: No instance for (Integral a5) arising from a use of `list' The type variable `a5' is ambiguous Note: there are several potential instances: instance Integral Int -- Defined in `GHC.Real' instance Integral Integer -- Defined in `GHC.Real' instance Integral GHC.Types.Word -- Defined in `GHC.Real' ...plus 8 others In the second argument of `($)', namely `list (precOf n) [ashow pp $ qvar $ var 0, mkstr (nameString n), ashow pp $ qvar $ var 1]' In the second argument of `($)', namely `shows $ list (precOf n) [ashow pp $ qvar $ var 0, mkstr (nameString n), ashow pp $ qvar $ var 1]' In the expression: method (PInfixApp () (PVar () (var 0)) (UnQual () $ dropAnn n) (PVar () (var 1))) $ shows $ list (precOf n) [ashow pp $ qvar $ var 0, mkstr (nameString n), ashow pp $ qvar $ var 1] Stem\Mu\Deriving.hs:289:34: No instance for (Num a5) arising from a use of `precOf' The type variable `a5' is ambiguous Note: there are several potential instances: instance Num Double -- Defined in `GHC.Float' instance Num Float -- Defined in `GHC.Float' instance Integral a => Num (GHC.Real.Ratio a) -- Defined in `GHC.Real' ...plus 12 others In the first argument of `list', namely `(precOf n)' In the second argument of `($)', namely `list (precOf n) [ashow pp $ qvar $ var 0, mkstr (nameString n), ashow pp $ qvar $ var 1]' In the second argument of `($)', namely `shows $ list (precOf n) [ashow pp $ qvar $ var 0, mkstr (nameString n), ashow pp $ qvar $ var 1]' Stem\Mu\Deriving.hs:289:63: No instance for (Show a6) arising from a use of `var' The type variable `a6' is ambiguous Note: there are several potential instances: instance Show GeneralCategory -- Defined in `Data.Char' instance Show IString -- Defined in `Cortex.Utils.IString' instance Show a => Show (Cortex.Utils.List.Down a) -- Defined in `Cortex.Utils.List' ...plus 171 others In the second argument of `($)', namely `var 0' In the second argument of `($)', namely `qvar $ var 0' In the expression: ashow pp $ qvar $ var 0 Stem\Mu\Deriving.hs:289:67: No instance for (Num a6) arising from the literal `0' The type variable `a6' is ambiguous Note: there are several potential instances: instance Num Double -- Defined in `GHC.Float' instance Num Float -- Defined in `GHC.Float' instance Integral a => Num (GHC.Real.Ratio a) -- Defined in `GHC.Real' ...plus 12 others In the first argument of `var', namely `0' In the second argument of `($)', namely `var 0' In the second argument of `($)', namely `qvar $ var 0' Stem\Mu\Deriving.hs:289:110: No instance for (Show a7) arising from a use of `var' The type variable `a7' is ambiguous Note: there are several potential instances: instance Show GeneralCategory -- Defined in `Data.Char' instance Show IString -- Defined in `Cortex.Utils.IString' instance Show a => Show (Cortex.Utils.List.Down a) -- Defined in `Cortex.Utils.List' ...plus 171 others In the second argument of `($)', namely `var 1' In the second argument of `($)', namely `qvar $ var 1' In the expression: ashow pp $ qvar $ var 1 Stem\Mu\Deriving.hs:289:114: No instance for (Num a7) arising from the literal `1' The type variable `a7' is ambiguous Note: there are several potential instances: instance Num Double -- Defined in `GHC.Float' instance Num Float -- Defined in `GHC.Float' instance Integral a => Num (GHC.Real.Ratio a) -- Defined in `GHC.Real' ...plus 12 others In the first argument of `var', namely `1' In the second argument of `($)', namely `var 1' In the second argument of `($)', namely `qvar $ var 1' Stem\Mu\Deriving.hs:290:37: No instance for (Integral a2) arising from a use of `mkInt' The type variable `a2' is ambiguous Note: there are several potential instances: instance Integral Int -- Defined in `GHC.Real' instance Integral Integer -- Defined in `GHC.Real' instance Integral GHC.Types.Word -- Defined in `GHC.Real' ...plus 8 others In the expression: mkInt () (precOf n + 1) In an equation for `pp': pp = mkInt () (precOf n + 1) In an equation for `sh': sh (QualConDecl _ _ _ (InfixConDecl _ t1 n t2)) = method (PInfixApp () (PVar () (var 0)) (UnQual () $ dropAnn n) (PVar () (var 1))) $ shows $ list (precOf n) [ashow pp $ qvar $ var 0, mkstr (nameString n), ashow pp $ qvar $ var 1] where pp = mkInt () (precOf n + 1) Stem\Mu\Deriving.hs:290:56: No instance for (Num a2) arising from a use of `+' The type variable `a2' is ambiguous Note: there are several potential instances: instance Num Double -- Defined in `GHC.Float' instance Num Float -- Defined in `GHC.Float' instance Integral a => Num (GHC.Real.Ratio a) -- Defined in `GHC.Real' ...plus 12 others In the second argument of `mkInt', namely `(precOf n + 1)' In the expression: mkInt () (precOf n + 1) In an equation for `pp': pp = mkInt () (precOf n + 1) Stem\Mu\Deriving.hs:297:47: No instance for (Integral a8) arising from a use of `mkInt' The type variable `a8' is ambiguous Note: there are several potential instances: instance Integral Int -- Defined in `GHC.Real' instance Integral Integer -- Defined in `GHC.Real' instance Integral GHC.Types.Word -- Defined in `GHC.Real' ...plus 8 others In the first argument of `ashow', namely `(mkInt () 0)' In the second argument of `aapp', namely `ashow (mkInt () 0) (qvar $ dropAnn n)' In the expression: mkstr (nameString n & " = ") `aapp` ashow (mkInt () 0) (qvar $ dropAnn n) Stem\Mu\Deriving.hs:297:56: No instance for (Num a8) arising from the literal `0' The type variable `a8' is ambiguous Note: there are several potential instances: instance Num Double -- Defined in `GHC.Float' instance Num Float -- Defined in `GHC.Float' instance Integral a => Num (GHC.Real.Ratio a) -- Defined in `GHC.Real' ...plus 12 others In the second argument of `mkInt', namely `0' In the first argument of `ashow', namely `(mkInt () 0)' In the second argument of `aapp', namely `ashow (mkInt () 0) (qvar $ dropAnn n)' Stem\Mu\Deriving.hs:337:44: No instance for (Show a10) arising from a use of `varx' The type variable `a10' is ambiguous Note: there are several potential instances: instance Show GeneralCategory -- Defined in `Data.Char' instance Show IString -- Defined in `Cortex.Utils.IString' instance Show a => Show (Cortex.Utils.List.Down a) -- Defined in `Cortex.Utils.List' ...plus 171 others In the first argument of `map', namely `varx' In the expression: map varx [0, 1] In a pattern binding: [x0, x1] = map varx [0, 1] Stem\Mu\Deriving.hs:337:50: No instance for (Num a10) arising from the literal `0' The type variable `a10' is ambiguous Note: there are several potential instances: instance Num Double -- Defined in `GHC.Float' instance Num Float -- Defined in `GHC.Float' instance Integral a => Num (GHC.Real.Ratio a) -- Defined in `GHC.Real' ...plus 12 others In the expression: 0 In the second argument of `map', namely `[0, 1]' In the expression: map varx [0, 1] Stem\Mu\Deriving.hs:338:44: No instance for (Show a9) arising from a use of `vary' The type variable `a9' is ambiguous Note: there are several potential instances: instance Show GeneralCategory -- Defined in `Data.Char' instance Show IString -- Defined in `Cortex.Utils.IString' instance Show a => Show (Cortex.Utils.List.Down a) -- Defined in `Cortex.Utils.List' ...plus 171 others In the first argument of `map', namely `vary' In the expression: map vary [0, 1] In a pattern binding: [y0, y1] = map vary [0, 1] Stem\Mu\Deriving.hs:338:50: No instance for (Num a9) arising from the literal `0' The type variable `a9' is ambiguous Note: there are several potential instances: instance Num Double -- Defined in `GHC.Float' instance Num Float -- Defined in `GHC.Float' instance Integral a => Num (GHC.Real.Ratio a) -- Defined in `GHC.Real' ...plus 12 others In the expression: 0 In the second argument of `map', namely `[0, 1]' In the expression: map vary [0, 1] Stem\Mu\Deriving.hs:366:33: Couldn't match type `DeclS IString TLoc' with `DeclHeadS IString l' Expected type: DeclHead l Actual type: Decl TLoc Relevant bindings include n :: Name l (bound at Stem\Mu\Deriving.hs:366:10) vs :: [TyVarBind l] (bound at Stem\Mu\Deriving.hs:366:13) In the first argument of `splitDeclHead', namely `dh' In the expression: splitDeclHead dh Stem\Mu\Deriving.hs:392:44: No instance for (Show a14) arising from a use of `varx' The type variable `a14' is ambiguous Note: there are several potential instances: instance Show GeneralCategory -- Defined in `Data.Char' instance Show IString -- Defined in `Cortex.Utils.IString' instance Show a => Show (Cortex.Utils.List.Down a) -- Defined in `Cortex.Utils.List' ...plus 171 others In the first argument of `map', namely `varx' In the expression: map varx [0, 1] In a pattern binding: [x0, x1] = map varx [0, 1] Stem\Mu\Deriving.hs:392:50: No instance for (Num a14) arising from the literal `0' The type variable `a14' is ambiguous Note: there are several potential instances: instance Num Double -- Defined in `GHC.Float' instance Num Float -- Defined in `GHC.Float' instance Integral a => Num (GHC.Real.Ratio a) -- Defined in `GHC.Real' ...plus 12 others In the expression: 0 In the second argument of `map', namely `[0, 1]' In the expression: map varx [0, 1] Stem\Mu\Deriving.hs:393:44: No instance for (Show a13) arising from a use of `vary' The type variable `a13' is ambiguous Note: there are several potential instances: instance Show GeneralCategory -- Defined in `Data.Char' instance Show IString -- Defined in `Cortex.Utils.IString' instance Show a => Show (Cortex.Utils.List.Down a) -- Defined in `Cortex.Utils.List' ...plus 171 others In the first argument of `map', namely `vary' In the expression: map vary [0, 1] In a pattern binding: [y0, y1] = map vary [0, 1] Stem\Mu\Deriving.hs:393:50: No instance for (Num a13) arising from the literal `0' The type variable `a13' is ambiguous Note: there are several potential instances: instance Num Double -- Defined in `GHC.Float' instance Num Float -- Defined in `GHC.Float' instance Integral a => Num (GHC.Real.Ratio a) -- Defined in `GHC.Real' ...plus 12 others In the expression: 0 In the second argument of `map', namely `[0, 1]' In the expression: map vary [0, 1] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 14:15:55 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 14:15:55 -0000 Subject: [GHC] #11542: Profiling call count frequently 0 when it shouldn't be Message-ID: <047.b0ecc7025940d726f91548515350f7d9@haskell.org> #11542: Profiling call count frequently 0 when it shouldn't be -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Here's an example (lines shortened): {{{ FUNCTION MODULE CALLS addinMTypeM Cortex.Stem.Exp.Addin 212462 56309 0.0 0.0 0.1 0.0 addinMTypeM'' Cortex.Stem.Exp.Addin 212463 0 0.0 0.0 0.1 0.0 memoize Cortex.Utils.Memo 212464 0 0.0 0.0 0.1 0.0 memoizeIO Cortex.Utils.Memo 212465 0 0.0 0.0 0.1 0.0 addinMTypeM' Cortex.Stem.Exp.Addin 212467 13799 0.0 0.0 0.1 0.0 }}} Maybe I don't understand the profile info, but here is my interpretation. addinMTypeM is called 56309 times, and then it calls addinMTypeM'' 0 times, which calls memoize 0 times, which calls memoizeIO 0 times, which calls addinMType' 13799. How can a function that was called 0 times call another function 13799 times? My profile are full of the 0 entries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 14:19:30 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 14:19:30 -0000 Subject: [GHC] #11543: Profiling information ambiguous Message-ID: <047.f56e01bd6ad8bd0c84dfa18f1d7c5710@haskell.org> #11543: Profiling information ambiguous -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- If a module M contains two instances of class C with method m and you ask for top level functions to be profiled then you get two profile entries for method m, and you cannot tell which is which. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 14:44:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 14:44:35 -0000 Subject: [GHC] #9638: Speed up Data.Char.isDigit In-Reply-To: <045.8305c40432408fead5554261d41a3400@haskell.org> References: <045.8305c40432408fead5554261d41a3400@haskell.org> Message-ID: <060.16d7567db663c54262cb25c10d2e12a8@haskell.org> #9638: Speed up Data.Char.isDigit -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11382 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * milestone: 8.0.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 15:19:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 15:19:27 -0000 Subject: [GHC] #10289: compiling huge HashSet hogs memory In-Reply-To: <044.7a75381e3cbd52797d1fc50b07f81ee0@haskell.org> References: <044.7a75381e3cbd52797d1fc50b07f81ee0@haskell.org> Message-ID: <059.6fc762e016a2cce191eef80796ca3bac@haskell.org> #10289: compiling huge HashSet hogs memory -------------------------------------+------------------------------------- Reporter: zudov | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 thomie): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 15:19:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 15:19:40 -0000 Subject: [GHC] #10289: compiling huge HashSet hogs memory In-Reply-To: <044.7a75381e3cbd52797d1fc50b07f81ee0@haskell.org> References: <044.7a75381e3cbd52797d1fc50b07f81ee0@haskell.org> Message-ID: <059.6f5120524be6f3a690fb9ba57a5ad553@haskell.org> #10289: compiling huge HashSet hogs memory -------------------------------------+------------------------------------- Reporter: zudov | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: worksforme | 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 thomie): * status: new => closed * resolution: => worksforme * milestone: 8.0.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 15:20:15 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 15:20:15 -0000 Subject: [GHC] #10289: compiling huge HashSet hogs memory In-Reply-To: <044.7a75381e3cbd52797d1fc50b07f81ee0@haskell.org> References: <044.7a75381e3cbd52797d1fc50b07f81ee0@haskell.org> Message-ID: <059.f53c0b28a057228f210cbc34d63d302d@haskell.org> #10289: compiling huge HashSet hogs memory -------------------------------------+------------------------------------- Reporter: zudov | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: worksforme | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * failure: Runtime performance bug => Compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 15:51:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 15:51:22 -0000 Subject: [GHC] #11543: Profiling information ambiguous In-Reply-To: <047.f56e01bd6ad8bd0c84dfa18f1d7c5710@haskell.org> References: <047.f56e01bd6ad8bd0c84dfa18f1d7c5710@haskell.org> Message-ID: <062.63429646a06320c7b1333543aa16f0dc@haskell.org> #11543: Profiling information ambiguous -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by j.waldmann): * cc: j.waldmann (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 15:52:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 15:52:06 -0000 Subject: [GHC] #11542: Profiling call count frequently 0 when it shouldn't be In-Reply-To: <047.b0ecc7025940d726f91548515350f7d9@haskell.org> References: <047.b0ecc7025940d726f91548515350f7d9@haskell.org> Message-ID: <062.4f987521278e5bbd7541f5ea93cecd01@haskell.org> #11542: Profiling call count frequently 0 when it shouldn't be -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by j.waldmann): * cc: j.waldmann (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 15:54:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 15:54:31 -0000 Subject: [GHC] #11541: Type errors sometimes has a lot of irrelevant information In-Reply-To: <047.b489a9355667fda5e49935258d0dd4af@haskell.org> References: <047.b489a9355667fda5e49935258d0dd4af@haskell.org> Message-ID: <062.40a6532c1803fec11301047bb544255e@haskell.org> #11541: Type errors sometimes has a lot of irrelevant information -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by j.waldmann): * cc: j.waldmann (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 16:17:21 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 16:17:21 -0000 Subject: [GHC] #11541: Type errors sometimes has a lot of irrelevant information In-Reply-To: <047.b489a9355667fda5e49935258d0dd4af@haskell.org> References: <047.b489a9355667fda5e49935258d0dd4af@haskell.org> Message-ID: <062.d827076ed48590bfe66e8cca98aaa538@haskell.org> #11541: Type errors sometimes has a lot of irrelevant information -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That is an unusually big cascade! We could suppress all type-class errors if there are any equality errors, I suppose. But that might suppress errors you'd like to see. Actually we *do* suppress class errors if there are any equality errors at the same level. So maybe the class errors are higher or lower in the tree. Would need an example to see. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 16:33:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 16:33:45 -0000 Subject: [GHC] #11544: SCC call-stack from `error` missing call-sites Message-ID: <049.10a404b43a93f3296c58a32955cdbf54@haskell.org> #11544: SCC call-stack from `error` missing call-sites -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.1-rc1 Keywords: | 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 reason the `-prof` stack that `error` attaches only includes the top-level CAF. This is with the default build settings (which I believe are the release settings?) {{{ $ cat Foo.hs main = print (foo [1]) foo xs = tail (tail xs) $ ./inplace/bin/ghc-stage2 --make -prof -fprof-auto-calls Foo.hs [1 of 1] Compiling Main ( Foo.hs, Foo.o ) [flags changed] Linking Foo ... $ ./Foo Foo: Prelude.tail: empty list CallStack (from -prof): GHC.List.CAF () }}} I would expect to at least see the call-site of `foo` (if not also `tail`) in the stack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 17:08:55 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 17:08:55 -0000 Subject: [GHC] #11544: SCC call-stack from `error` missing call-sites In-Reply-To: <049.10a404b43a93f3296c58a32955cdbf54@haskell.org> References: <049.10a404b43a93f3296c58a32955cdbf54@haskell.org> Message-ID: <064.02f7008008a12e296c4d08c04da23c53@haskell.org> #11544: SCC call-stack from `error` missing call-sites -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Profiling | Version: 8.0.1-rc1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => wontfix Comment: Yeah, this is a known problem, and it's kind of by design. The call to `error` in `GHC.List` is lifted out as a CAF, because it has no dependencies. Profiling doesn't add extra arguments to things (to avoid changing the cost model of the program), so this CAF can be evaluated only once. I'll close the ticket as wontfix for now, but I do have some experimental changes that might help with this in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 17:09:50 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 17:09:50 -0000 Subject: [GHC] #11545: Strictness signature blowup Message-ID: <046.cb411eddd2debdaa92305f408dd89d74@haskell.org> #11545: Strictness signature blowup -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- The following code takes a lot of memory (556MB) to compile: {{{#!hs data A = A A A A A A deriving (Eq) }}} More {{{A}}}s result in more memory consumption during compilation. Using {{{ghc -O A.hs -v -dverbose-core2core -c -ddump-simpl +RTS -s}}} it seems like the strictness signatures of (==) and (/=) blow up quite a bit. A less silly example could be the following: {{{#!hs data QuadTree a = QuadTree !Int [a] (QuadTree a) (QuadTree a) (QuadTree a) (QuadTree a) foldQuadTree :: (a -> b -> b) -> Int -> b -> QuadTree a -> b foldQuadTree f maxSize = go where go z (QuadTree size elems t1 t2 t3 t4) | size <= maxSize = foldr f z elems | otherwise = go (go (go (go z t4) t3) t2) t1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 17:10:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 17:10:27 -0000 Subject: [GHC] #11545: Strictness signature blowup In-Reply-To: <046.cb411eddd2debdaa92305f408dd89d74@haskell.org> References: <046.cb411eddd2debdaa92305f408dd89d74@haskell.org> Message-ID: <061.13e7c8c5a03feaf1cc0c86c3ab9b839e@haskell.org> #11545: Strictness signature blowup -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jscholl): * Attachment "A.log.gz" added. Output when compiling (22MB when uncompressed!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 17:15:34 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 17:15:34 -0000 Subject: [GHC] #11544: SCC call-stack from `error` missing call-sites In-Reply-To: <049.10a404b43a93f3296c58a32955cdbf54@haskell.org> References: <049.10a404b43a93f3296c58a32955cdbf54@haskell.org> Message-ID: <064.46552cecb2d90bb44d0eab6e575dd0f2@haskell.org> #11544: SCC call-stack from `error` missing call-sites -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Profiling | Version: 8.0.1-rc1 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 gridaphobe): I see, that makes some sense. Is this decision documented somewhere? It came up in a thread [1] on /r/haskell, and is likely to cause more confusion with the advertisement of stack-traces by default from `error`. [1]: https://www.reddit.com/r/haskell/comments/441e3s/how_to_use_the_implicit_error_locations_and_stack/czn4y9q?context=3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 17:20:44 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 17:20:44 -0000 Subject: [GHC] #11510: Missing Show instance for GHC.Stack.SrcLoc In-Reply-To: <050.e08b70941207067cd22a7124ead2f765@haskell.org> References: <050.e08b70941207067cd22a7124ead2f765@haskell.org> Message-ID: <065.dc3300aa545d171b96efea111e132165@haskell.org> #11510: Missing Show instance for GHC.Stack.SrcLoc -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc1 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:D1886 Wiki Page: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * status: new => patch * differential: => Phab:D1886 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 17:45:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 17:45:35 -0000 Subject: [GHC] #11545: Strictness signature blowup In-Reply-To: <046.cb411eddd2debdaa92305f408dd89d74@haskell.org> References: <046.cb411eddd2debdaa92305f408dd89d74@haskell.org> Message-ID: <061.77a2dd4e5ba47d8d85404a35af8cf686@haskell.org> #11545: Strictness signature blowup -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): So every `QuadTree` is infinite? As is every value of type `A`. But yes, it'd be much better not to blow up. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 20:37:29 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 20:37:29 -0000 Subject: [GHC] #11546: Compiler warning: cast from pointer to integer of different size Message-ID: <050.2c1fef46d020babab1aa4b0f7ab8074e@haskell.org> #11546: Compiler warning: cast from pointer to integer of different size -------------------------------------+------------------------------------- Reporter: wereHamster | Owner: 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: -------------------------------------+------------------------------------- While building the stage1 compiler: {{{ In file included from rts/Capability.h:25:0, from includes/dist-derivedconstants/header/tmp.c:15: rts/Task.h: In function 'serialiseTaskId': rts/Task.h:318:12: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] return (TaskId) taskID; ^ }}} I'm building a cross-compiler with build/host=x86_64-linux-gnu and target =mips-unknown-linux-musl -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 21:49:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 21:49:46 -0000 Subject: [GHC] #7666: excessive space and time usage for rendering (somewhat) deeply nested Docs In-Reply-To: <049.8cd4dd835967347997a66fc02360e8c1@haskell.org> References: <049.8cd4dd835967347997a66fc02360e8c1@haskell.org> Message-ID: <064.73aebca562e7b0d1b0f4993df13fb339@haskell.org> #7666: excessive space and time usage for rendering (somewhat) deeply nested Docs -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: dterei Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.6.2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by j.waldmann): * cc: ekmett (added) Comment: simplified test case entered into pretty's bug tracker: https://github.com/haskell/pretty -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 5 23:21:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 05 Feb 2016 23:21:45 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.bf2cce1213c01c843541ddca67b5554e@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1205 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): This is also a semantic bug because the Haskell Report specifies that `maximumBy` has the behavior of `foldl1`. We fixed this for `sum` and `maximum` and so on by making them instance methods of Foldable. We should just do the same for `maximumBy` and `minimumBy`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 00:09:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 00:09:47 -0000 Subject: [GHC] #11540: ghc accepts non-standard type without language extension In-Reply-To: <047.4af844a129b268095ee1a782d708bfe8@haskell.org> References: <047.4af844a129b268095ee1a782d708bfe8@haskell.org> Message-ID: <062.7a0734352f96df2e2473b5b407cef1b7@haskell.org> #11540: ghc accepts non-standard type without language extension -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * component: Compiler => Compiler (Parser) Comment: Hmmm, fair enough. Perhaps `-XNestedContexts`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 00:15:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 00:15:15 -0000 Subject: [GHC] #11540: ghc accepts non-standard type without language extension In-Reply-To: <047.4af844a129b268095ee1a782d708bfe8@haskell.org> References: <047.4af844a129b268095ee1a782d708bfe8@haskell.org> Message-ID: <062.2ced5c6eb78bfd66201aebf77bb39b2f@haskell.org> #11540: ghc accepts non-standard type without language extension -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): If we want to control this with a language extension, then `Rank2Types`/`RankNTypes` should be a good choice. After all we already have {{{ Prelude> let f :: a -> Eq a => a; f = undefined :4:10: Illegal polymorphic or qualified type: Eq a => a Perhaps you intended to use RankNTypes or Rank2Types In the type signature for ?f?: f :: a -> Eq a => a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 03:30:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 03:30:18 -0000 Subject: [GHC] #11547: Accessing shadowed definitions in GHCi Message-ID: <044.71011ab462b5fa37155c58f145f7265b@haskell.org> #11547: Accessing shadowed definitions in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Apparently GHCi creates a qualified namespace for each line it interprets, as can be observed with: {{{#!hs > data A = A > data A = B > :t A A :: Ghci3.A }}} Apparently accessing shadowed definitions in this way sometimes breaks GHCi: {{{#!hs > let a = a > let a = a > :t Ghci7.a :1:1: error: ? GHC internal error: ?Ghci7.a? is not in scope during type checking, but it passed the renamer tcl_env of environment: [] ? In the expression: Ghci7.a }}} More specifically, complete reproduction instructions: {{{#!hs GHCi, version 8.1.20160205: http://www.haskell.org/ghc/ :? for help > let foo = foo > :t Ghci1.foo Ghci1.foo :: t > let foo = foo > :t Ghci1.foo :1:1: error: ? GHC internal error: ?Ghci1.foo? is not in scope during type checking, but it passed the renamer tcl_env of environment: [] ? In the expression: Ghci1.foo }}} 7.10.2 (and 7.8.3 as verified over IRC by monochrom) appears to have a slightly different behavior. It seems it only creates namespaces for data/newtype/class declarations. Yet still, it fails with an error the first time but works completely fine thereafter: {{{#!hs > data A = A > data A = A > :t Ghci1.A Failed to load interface for ?Ghci1? no package key matching ?interactive? was found > :t Ghci1.A Ghci1.A :: Ghci1.A }}} 7.6.3 uses a different approach to displaying out of scope names so the behavior doesn't apply: {{{#!hs > data A = A > data A = B > :t A A :: main::Interactive.A }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 05:33:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 05:33:18 -0000 Subject: [GHC] #11548: Absolutely misleading error message on kind error Message-ID: <044.e6082235a325c0e8984f6f1f86653383@haskell.org> #11548: Absolutely misleading error message on kind error -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs module Bug where import Data.Proxy fun :: Proxy a -> () fun Proxy = () bug :: () bug = fun (Proxy :: Proxy Maybe) }}} {{{#!hs [1 of 1] Compiling Bug ( Bug.hs, Bug.o ) Bug.hs:9:12: error: ? Expected kind ?Proxy Maybe?, but ?Data.Proxy.Proxy :: Proxy Maybe? has kind ?Proxy Maybe? ? In the first argument of ?fun?, namely ?(Proxy :: Proxy Maybe)? In the expression: fun (Proxy :: Proxy Maybe) In an equation for ?bug?: bug = fun (Proxy :: Proxy Maybe) }}} 7.10 gives the appropriate `Couldn't match kind ?* -> *? with ?*?` message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 11:15:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 11:15:30 -0000 Subject: [GHC] #11548: Absolutely misleading error message on kind error In-Reply-To: <044.e6082235a325c0e8984f6f1f86653383@haskell.org> References: <044.e6082235a325c0e8984f6f1f86653383@haskell.org> Message-ID: <059.9f32537a624ba2f451e0facd6124d33b@haskell.org> #11548: Absolutely misleading error message on kind error -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * component: Compiler => Compiler (Type checker) Comment: Note that if you pass `-fprint-explicit-kinds` the error is a bit better (although arguably still not as clear as 7.10's error), {{{ Bug.hs:9:12: error: ? Expected kind ?Proxy * Maybe?, but ?Data.Proxy.Proxy :: Proxy Maybe? has kind ?Proxy (* -> *) Maybe? ? In the first argument of ?fun?, namely ?(Proxy :: Proxy Maybe)? In the expression: fun (Proxy :: Proxy Maybe) In an equation for ?bug?: bug = fun (Proxy :: Proxy Maybe) }}} Of course, this isn't a great situation; surely the compiler can see that the types as printed are indistinguishable and it should therefore providing kinds as well. I'm not certain of this, but I suspect Richard is already aware of this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 12:06:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 12:06:15 -0000 Subject: [GHC] #11548: Absolutely misleading error message on kind error In-Reply-To: <044.e6082235a325c0e8984f6f1f86653383@haskell.org> References: <044.e6082235a325c0e8984f6f1f86653383@haskell.org> Message-ID: <059.dc804a0eaf1a3251af3b586b131cc98c@haskell.org> #11548: Absolutely misleading error message on kind error -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mniip): Is `Proxy Maybe` even a kind? Unless I'm missing something, in this context it is a type, not a kind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 12:13:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 12:13:10 -0000 Subject: [GHC] #11548: Absolutely misleading error message on kind error In-Reply-To: <044.e6082235a325c0e8984f6f1f86653383@haskell.org> References: <044.e6082235a325c0e8984f6f1f86653383@haskell.org> Message-ID: <059.6b342814b7d763c8065564b1511a7090@haskell.org> #11548: Absolutely misleading error message on kind error -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): A fair point. Yes, "kind" does seem a bit misleading here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 13:13:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 13:13:05 -0000 Subject: [GHC] #11530: Make fails on systems with GREP_OPTIONS In-Reply-To: <047.65eb2c1162c4e0a77b27714fb3375078@haskell.org> References: <047.65eb2c1162c4e0a77b27714fb3375078@haskell.org> Message-ID: <062.4cd4bcfe10f98684d848011edc7368b4@haskell.org> #11530: Make fails on systems with GREP_OPTIONS ---------------------------------+---------------------------------------- Reporter: alexlegg | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Resolution: | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1886 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1886 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 13:17:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 13:17:39 -0000 Subject: [GHC] #11510: Missing Show instance for GHC.Stack.SrcLoc In-Reply-To: <050.e08b70941207067cd22a7124ead2f765@haskell.org> References: <050.e08b70941207067cd22a7124ead2f765@haskell.org> Message-ID: <065.886e7f500102c9ea14ab079c16d0ac54@haskell.org> #11510: Missing Show instance for GHC.Stack.SrcLoc -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc1 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:D1886 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > There was also a Show instance for CallStack in 7.10.2, is there a reason to want that? I think not, because the user shouldn't care about the representation. If you want a machine-readable formatting of a CallStack you can use getCallStack stk to get a list of the call-sites, which is then Showable (assuming a Show SrcLoc instance). I see the argument here but then again I think there is little harm in providing the instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 13:45:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 13:45:49 -0000 Subject: [GHC] #11510: Missing Show instance for GHC.Stack.SrcLoc In-Reply-To: <050.e08b70941207067cd22a7124ead2f765@haskell.org> References: <050.e08b70941207067cd22a7124ead2f765@haskell.org> Message-ID: <065.b9839c8f9cba43bf6b15fdd61bbe31cf@haskell.org> #11510: Missing Show instance for GHC.Stack.SrcLoc -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc1 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:D1886 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"38af3d1db2889423a12a2232b9d52181bba23d75/ghc" 38af3d1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="38af3d1db2889423a12a2232b9d52181bba23d75" Add a derived `Show SrcLoc` instance Test Plan: ``` ghci> import GHC.Stack ghci> SrcLoc "f" "b" "c" 1 2 3 4 SrcLoc {srcLocPackage = "f", srcLocModule = "b", srcLocFile = "c", srcLocStartLine = 1, srcLocStartCol = 2, srcLocEndLine = 3, srcLocEndCol = 4} ``` Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D1886 GHC Trac Issues: #11510 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 14:16:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 14:16:33 -0000 Subject: [GHC] #11516: Panic, "falls into a hole" In-Reply-To: <051.f6bcca55b0b02654ebc7a8da6d28be6c@haskell.org> References: <051.f6bcca55b0b02654ebc7a8da6d28be6c@haskell.org> Message-ID: <066.03dc0c7679b0506c343ce16234bd5a2b@haskell.org> #11516: Panic, "falls into a hole" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_compile/T11516 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * failure: None/Unknown => Compile-time crash * component: Compiler => Compiler (Type checker) * testcase: => typecheck/should_compile/T11516 * milestone: => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 14:31:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 14:31:56 -0000 Subject: [GHC] #11540: ghc accepts non-standard type without language extension In-Reply-To: <047.4af844a129b268095ee1a782d708bfe8@haskell.org> References: <047.4af844a129b268095ee1a782d708bfe8@haskell.org> Message-ID: <062.3366d639d3798e91dc5f69c194eb5643@haskell.org> #11540: ghc accepts non-standard type without language extension -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): That being said, it was decided at some point that we should also allow `foralls` independently from `RankNTypes` with `ExplicitForAlls`. My initial thought was that `RankNTypes` would imply `NestedContexts`, just as it does `ExplicitForAlls`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 14:46:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 14:46:22 -0000 Subject: [GHC] #11548: Absolutely misleading error message on kind error In-Reply-To: <044.e6082235a325c0e8984f6f1f86653383@haskell.org> References: <044.e6082235a325c0e8984f6f1f86653383@haskell.org> Message-ID: <059.91f233fefb5a4af6e7e911d18e9c7ac3@haskell.org> #11548: Absolutely misleading error message on kind error -------------------------------------+------------------------------------- Reporter: mniip | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire Comment: Yes, I'm already aware of this issue, but another test case is good. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 15:08:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 15:08:23 -0000 Subject: [GHC] #11549: Add -fshow-runtime-rep Message-ID: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> #11549: Add -fshow-runtime-rep -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- As discussed in several interwoven threads ([https://mail.haskell.org/pipermail/ghc-devs/2016-February/011268.html original], [https://mail.haskell.org/pipermail/haskell- cafe/2016-February/122914.html caf?]), it has been suggested to add a flag `-fshow-runtime-rep`. Without this flag enabled, the pretty printer will instantiate any `RuntimeRep` type parameters to `PtrRep Lifted`. This has the effect of changing {{{ ($) :: forall (r :: RuntimeRep) (a :: *) (b :: TYPE r). (a -> b) -> a -> b }}} to {{{ ($) :: (a -> b) -> a -> b }}} under the default GHCi settings. Note that `Levity` becomes `RuntimeRep` after #11471 is complete. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 15:33:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 15:33:41 -0000 Subject: [GHC] #7803: Superclass methods are left unspecialized In-Reply-To: <043.4332d4a466b84dd410c0fa8f45c15001@haskell.org> References: <043.4332d4a466b84dd410c0fa8f45c15001@haskell.org> Message-ID: <058.1f4c9c3e7977bf397c4a34a2c8b5513e@haskell.org> #7803: Superclass methods are left unspecialized -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): Can someone take another look at this ticket? It sounds like Simon's suggestion just needs to be merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 16:09:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 16:09:23 -0000 Subject: [GHC] #11516: Panic, "falls into a hole" In-Reply-To: <051.f6bcca55b0b02654ebc7a8da6d28be6c@haskell.org> References: <051.f6bcca55b0b02654ebc7a8da6d28be6c@haskell.org> Message-ID: <066.ba816353760718a0f16b1d0dfb9d99aa@haskell.org> #11516: Panic, "falls into a hole" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_compile/T11516 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"b49d509b336cb74f506555eada8830d754c4b7ba/ghc" b49d509b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b49d509b336cb74f506555eada8830d754c4b7ba" Add test for #11516 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 16:14:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 16:14:04 -0000 Subject: [GHC] #7803: Superclass methods are left unspecialized In-Reply-To: <043.4332d4a466b84dd410c0fa8f45c15001@haskell.org> References: <043.4332d4a466b84dd410c0fa8f45c15001@haskell.org> Message-ID: <058.88b1521af6f479116f61b081f9f91017@haskell.org> #7803: Superclass methods are left unspecialized -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've started a pair of builds; I'll put up nofib results once they have finished. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 17:34:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 17:34:38 -0000 Subject: [GHC] #11548: Absolutely misleading error message on kind error In-Reply-To: <044.e6082235a325c0e8984f6f1f86653383@haskell.org> References: <044.e6082235a325c0e8984f6f1f86653383@haskell.org> Message-ID: <059.91617e20e02f0e31e19463aee16dbb83@haskell.org> #11548: Absolutely misleading error message on kind error -------------------------------------+------------------------------------- Reporter: mniip | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Possibly a duplicate of #11485? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 17:57:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 17:57:34 -0000 Subject: [GHC] #797: nofib tests fail on Windows due to different EOL convention in output files In-Reply-To: <047.8d1466267df270460e4c08bc0ebdb93c@haskell.org> References: <047.8d1466267df270460e4c08bc0ebdb93c@haskell.org> Message-ID: <062.527feb1f6a8ecefe96bec94c7de3c889@haskell.org> #797: nofib tests fail on Windows due to different EOL convention in output files -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.6 Component: NoFib benchmark | Version: 6.4.1 suite | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => new * failure: => None/Unknown * resolution: fixed => * owner: igloo => @@ -1,1 +1,1 @@ - Now fixed in the 6.6 branch. + New description: -- Comment: NoFib on Windows fails for me using ghc-8.1 with `expected stdout not matched by reality`. Seems to be a line ending issue. This is the command I try to run, following instructions from [wiki:Building/RunningNoFib#Benchmarking]: {{{ cd nofib make boot make exeext=.exe }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 18:31:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 18:31:30 -0000 Subject: [GHC] #7803: Superclass methods are left unspecialized In-Reply-To: <043.4332d4a466b84dd410c0fa8f45c15001@haskell.org> References: <043.4332d4a466b84dd410c0fa8f45c15001@haskell.org> Message-ID: <058.99c13db762fa4c54d956c206cedf56e6@haskell.org> #7803: Superclass methods are left unspecialized -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Here is a nofib comparison based on 38af3d1db2889423a12a2232b9d52181bba23d75 with and without the following patch, {{{#!patch diff --git a/compiler/simplCore/SimplCore.hs b/compiler/simplCore/SimplCore.hs index 6badbf8..c573b45 100644 --- a/compiler/simplCore/SimplCore.hs +++ b/compiler/simplCore/SimplCore.hs @@ -182,7 +182,7 @@ getCoreToDo dflags (base_mode { sm_phase = InitialPhase , sm_names = ["Gentle"] , sm_rules = rules_on -- Note [RULEs enabled in SimplGently] - , sm_inline = False + , sm_inline = True , sm_case_case = False }) -- Don't do case-of-case transformations. -- This makes full laziness work better }}} Unfortunately things don't look terribly promising, {{{ Program Size Allocs Runtime Elapsed TotalMem -------------------------------------------------------------------------------- Min -0.3% -95.0% -0.6% -1.2% 0.0% Max +0.9% +10.6% +14.3% +14.3% +100.0% Geometric Mean +0.4% -2.8% +1.6% +1.5% +0.8% }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 18:32:14 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 18:32:14 -0000 Subject: [GHC] #7803: Superclass methods are left unspecialized In-Reply-To: <043.4332d4a466b84dd410c0fa8f45c15001@haskell.org> References: <043.4332d4a466b84dd410c0fa8f45c15001@haskell.org> Message-ID: <058.c9ca1e7605fda01f73500a6136cdd144@haskell.org> #7803: Superclass methods are left unspecialized -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * Attachment "analyze.log" added. nofib-analyze output -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 19:00:50 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 19:00:50 -0000 Subject: [GHC] #11473: Levity polymorphism checks are inadequate In-Reply-To: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> References: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> Message-ID: <061.e102022fd24353adc143c26e9500d29f@haskell.org> #11473: Levity polymorphism checks are inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): This slight variation of Ben's program does produce a garbage result. I just added an extra function call to `hello` (and turned on `ScopedTypeVariables`). {{{ {-# LANGUAGE PolyKinds, TypeFamilies, MagicHash, DataKinds, TypeInType, RankNTypes, ScopedTypeVariables #-} import GHC.Exts import GHC.Types type family Boxed (a :: k) :: * type instance Boxed Char# = Char type instance Boxed Char = Char class BoxIt (a :: TYPE lev) where boxed :: a -> Boxed a instance BoxIt Char# where boxed x = C# x instance BoxIt Char where boxed = id hello :: forall (lev :: Levity) (a :: TYPE lev). BoxIt a => a -> Boxed a hello x = boxed (myid x) where myid :: a -> a myid y = y {-# NOINLINE myid #-} {-# NOINLINE hello #-} main :: IO () main = do print $ boxed 'c'# print $ boxed 'c' print $ hello 'c' print $ hello 'c'# -- this one prints '\8589966336' }}} (Interesting note, `hello :: forall foo. forall bar. t` does ''not'' bring `bar` into scope in the definition of `hello`. I guess that makes sense.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 19:16:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 19:16:38 -0000 Subject: [GHC] #11473: Levity polymorphism checks are inadequate In-Reply-To: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> References: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> Message-ID: <061.bd6db1f27721a6239e827a2610a8e9ad@haskell.org> #11473: Levity polymorphism checks are inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): It seems to me the most logical place to put these levity polymorphism checks is in the typing rules for abstraction and application. After all `\(a :: t) -> ...` is really different beasts at runtime depending on whether `t :: * = TYPE L`, or `t :: TYPE UW32`, or `t :: TYPE UW64` etc. We should insist that the rep (the `r` such that `t :: TYPE r`) of `t` be known when type-checking the lambda, and resolve the overloading to `\_L`, or `\_UW32`, or `\_UW64`. In short, treat `\` as ad-hoc polymorphic. Similar comments apply to application. `f x` is really an overloaded `f $_r x`, where the typing rule for `$_r` is {{{ s :: RuntimeRep a :: TYPE r b :: TYPE s f :: a -> b x :: a ------------------------------------------------------------------ f $_r x :: b }}} And this makes sense because later to actually compile an application, we will absolutely need to know the rep of the type of `x`. Then I don't think we need any special rules about the kind of `->`, which can become rep-polymorphic in both arguments. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 19:58:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 19:58:13 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.a4863b89f7618647d344bded1031ac69@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): By the way, I know the name of the extension is `TypeInType`, but might it not make more sense to have a separate `Levity` constructor for kinds? Say `* :: TYPE T`. While the values of `Int` are things like `1 :: Int`, and they are lifted and boxed, the "values" of `*` are things like `Int :: *`, and... `Int` is not really represented by anything at runtime. But if it was, it wouldn't necessarily be a lifted, boxed pointer. Maybe you want lazy evaluation on the value level, but strict evaluation on the type level, along with a totally different runtime representation for types. I don't know of any reason why you would want to abstract over specifically (regular types of kind `*` + kinds). It seems to me that in such cases it would make just as much sense to allow unboxed types as well. On the other hand, I do realize that the name `*` is a lot more convenient than writing `forall (a :: RuntimeRep). ... (TYPE a)`, and maybe that is the real issue...? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 20:37:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 20:37:16 -0000 Subject: [GHC] #11550: ghc-HEAD -DDEBUG is broken (possiby by D1880) Message-ID: <045.510eebdecea6778a3cdc8536c2c13abb@haskell.org> #11550: ghc-HEAD -DDEBUG is broken (possiby by D1880) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Was found when tried to build with BuildFlavour = devel2 {{{ ghc-validate $ LANG=C make V=0 HC [stage 2] libraries/parallel/dist-install/build/Control/Seq.o WARNING: file compiler/stgSyn/CoreToStg.hs, line 250 using False True ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160206 for x86_64-unknown-linux): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/stgSyn/CoreToStg.hs:216:59 in ghc:CoreToStg using Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} https://travis-ci.org/ghc/ghc/builds suggests changeset:4f9967aa3d1f7cfd539d0c173cafac0fe290e26f might be at fault. Reverting it on top of master fixes devel2 build. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 20:58:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 20:58:49 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.28f2590f5dd3f378a1eaf2f700b9c39b@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: skvadrik Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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:D1888 Wiki Page: | -------------------------------------+------------------------------------- Changes (by skvadrik): * differential: => Phab:D1888 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 21:10:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 21:10:47 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.eceec4e584c5d156d944f8e5de280dc2@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: skvadrik Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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:D1888 Wiki Page: | -------------------------------------+------------------------------------- Comment (by skvadrik): So the breakage was **not** caused by the change of grammar (`(-.->)(..)` is parsed as neither `qcon` nor `oqtycon`, it is parsed as `qvar`). It was caused by removal of `setRdrNameSpace` call. D1888 breaks one test (`make test TEST=mod89`): we get error instead of warning and the message is different (perhaps less informative). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 21:41:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 21:41:36 -0000 Subject: [GHC] #11550: ghc-HEAD -DDEBUG is broken (possiby by D1880) In-Reply-To: <045.510eebdecea6778a3cdc8536c2c13abb@haskell.org> References: <045.510eebdecea6778a3cdc8536c2c13abb@haskell.org> Message-ID: <060.299c2579b3a76c20a83ff62c5dd093aa@haskell.org> #11550: ghc-HEAD -DDEBUG is broken (possiby by D1880) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): I have a fix, I'm waiting for Simon's review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 22:02:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 22:02:29 -0000 Subject: [GHC] #9685: GHC fails to build with mingw32-make on Windows In-Reply-To: <045.13b70a7884f3c365add55a5ab5f3ac02@haskell.org> References: <045.13b70a7884f3c365add55a5ab5f3ac02@haskell.org> Message-ID: <060.abdb57bc65e7ff89932a16300bbd8d59@haskell.org> #9685: GHC fails to build with mingw32-make on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Build System | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 8596 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gintas): * owner: gintas => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 22:02:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 22:02:41 -0000 Subject: [GHC] #9686: Link option detection does not work for incremental builds on Windows In-Reply-To: <045.5344aa82eaf7c34a0b72f08bd8458a01@haskell.org> References: <045.5344aa82eaf7c34a0b72f08bd8458a01@haskell.org> Message-ID: <060.e5711eb828c1e7dfcd8b94facd9e8c2c@haskell.org> #9686: Link option detection does not work for incremental builds on Windows ---------------------------------+---------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by gintas): * owner: gintas => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 22:03:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 22:03:58 -0000 Subject: [GHC] #7320: GHC crashes when building on 32-bit Linux in a Linode In-Reply-To: <043.0168db82b571fa620930b74d5d40cf16@haskell.org> References: <043.0168db82b571fa620930b74d5d40cf16@haskell.org> Message-ID: <058.807c0f52e524d51142294e8ceb69baa3@haskell.org> #7320: GHC crashes when building on 32-bit Linux in a Linode ---------------------------------------+-------------------------------- Reporter: benl | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------------+-------------------------------- Changes (by gintas): * cc: gintas (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 22:04:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 22:04:13 -0000 Subject: [GHC] #8842: Make sure msys2 builds non emulating binaries In-Reply-To: <046.86a6364bab91651953306fe81692398f@haskell.org> References: <046.86a6364bab91651953306fe81692398f@haskell.org> Message-ID: <061.2724d8e6e38f9d295b5bd4e2659ac47c@haskell.org> #8842: Make sure msys2 builds non emulating binaries ---------------------------------+---------------------------------------- Reporter: schyler | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.8.1-rc2 Resolution: fixed | Keywords: msys2 Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Changes (by gintas): * cc: gintas (removed) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 22:10:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 22:10:47 -0000 Subject: [GHC] #11529: Show instance of Char should print literals for non-ascii printable charcters In-Reply-To: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> References: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> Message-ID: <060.a19f33b9628dbde9cc342d10956ff57a@haskell.org> #11529: Show instance of Char should print literals for non-ascii printable charcters -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 22:28:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 22:28:35 -0000 Subject: [GHC] #11550: ghc-HEAD -DDEBUG is broken (possiby by D1880) In-Reply-To: <045.510eebdecea6778a3cdc8536c2c13abb@haskell.org> References: <045.510eebdecea6778a3cdc8536c2c13abb@haskell.org> Message-ID: <060.648b71750062ef91ceeaefca01246d81@haskell.org> #11550: ghc-HEAD -DDEBUG is broken (possiby by D1880) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): Yay! Do you happen to have it published anywhere so i could apply it locally? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 23:36:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 23:36:42 -0000 Subject: [GHC] #11550: ghc-HEAD -DDEBUG is broken (possiby by D1880) In-Reply-To: <045.510eebdecea6778a3cdc8536c2c13abb@haskell.org> References: <045.510eebdecea6778a3cdc8536c2c13abb@haskell.org> Message-ID: <060.9474a428b1aa982f9d10cd4ae488be8b@haskell.org> #11550: ghc-HEAD -DDEBUG is broken (possiby by D1880) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1889 Wiki Page: | -------------------------------------+------------------------------------- Changes (by osa1): * status: new => patch * differential: => Phab:D1889 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 23:36:47 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 23:36:47 -0000 Subject: [GHC] #11551: Get doctests into testsuite Message-ID: <042.af40c85fc8748e84b1cb8db08ab4aad3@haskell.org> #11551: Get doctests into testsuite -------------------------------------+------------------------------------- Reporter: lwm | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.3 Libraries | Keywords: | Operating System: Unknown/Multiple documentation, doctest | Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems like a bit of a shame not to have Mr.Orlitzky's lovely doctests not running with the testsuite. Or perhaps to at least have some sort of `make doctest`. If there is some interest to get this working, I'd like to take a look at submitting a patch. Here are the previous documentation patches I can find: https://phabricator.haskell.org/p/mjo/ I can see the following files that have doctests: {{{ ruby-2.2.1 ~/work/contributing/ghc (master) [12:35:44] lwm$ grep -R "=== __Examples__" libraries/base/ | uniq grep: libraries/base/Data/Maybe.hs:-- ==== __Examples__ libraries/base/Data/Either.hs:-- ==== __Examples__ libraries/base/Data/List.hs:-- ==== __Examples__ libraries/base/Data/Functor.hs:-- ==== __Examples__ libraries/base/Data/Bool.hs:-- ==== __Examples__ libraries/base/Data/Char.hs:-- ==== __Examples__ libraries/base/GHC/Unicode.hs:-- ==== __Examples__ libraries/base/Text/Printf.hs:-- ==== __Examples__ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 6 23:37:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 06 Feb 2016 23:37:16 -0000 Subject: [GHC] #11549: Add -fshow-runtime-rep In-Reply-To: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> References: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> Message-ID: <062.8c8fdd9d0e586e87adb9169735f28d0d@haskell.org> #11549: Add -fshow-runtime-rep -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): One thing isn't clear to me about how `-fshow-runtime-rep` works. I'm assuming that without `-fshow-runtime-rep` on, you won't see any mention of `RuntimeRep` in error messages. If so, what kind of error would this produce? {{{#!hs import GHC.Exts bad :: forall (w :: RuntimeRep) (a :: TYPE w). a -> Int bad _ = 42 }}} The error would probably mention the type signature of `bad`, but would it be truncated to `a -> Int` instead of the full shebang? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 01:10:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 01:10:36 -0000 Subject: [GHC] #11550: ghc-HEAD -DDEBUG is broken (possiby by D1880) In-Reply-To: <045.510eebdecea6778a3cdc8536c2c13abb@haskell.org> References: <045.510eebdecea6778a3cdc8536c2c13abb@haskell.org> Message-ID: <060.0024de19d101bf723f325f51abb32481@haskell.org> #11550: ghc-HEAD -DDEBUG is broken (possiby by D1880) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1889 Wiki Page: | -------------------------------------+------------------------------------- Comment (by osa1): FYI I reverted the patch in the meantime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 02:38:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 02:38:17 -0000 Subject: [GHC] #11551: Get doctests into testsuite In-Reply-To: <042.af40c85fc8748e84b1cb8db08ab4aad3@haskell.org> References: <042.af40c85fc8748e84b1cb8db08ab4aad3@haskell.org> Message-ID: <057.6b379f46e14e12e43f7bc2b7741f650e@haskell.org> #11551: Get doctests into testsuite -------------------------------------+------------------------------------- Reporter: lwm | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: | documentation, doctest 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 thomie): Go for it. Either create a separate `doctest` target in the testsuite (see `testsuite/Makefile`, `testsuite/mk/test.mk` and `testsuite/tests/Makefile`), and have `validate` call that. Or add it simply as a `run_command` test. Think about what should happen when the user doesn't have `doctest` installed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 05:18:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 05:18:29 -0000 Subject: [GHC] #11552: ScopedTypeVariables / InstanceSigs do not work in GHC 8.0 Message-ID: <048.ed8df3269063d4724395b509ea472611@haskell.org> #11552: ScopedTypeVariables / InstanceSigs do not work in GHC 8.0 -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 InstanceSigs #-} {-# LANGUAGE ScopedTypeVariables #-} module MyMaybeT where newtype MaybeT m a = MaybeT { runMaybeT :: m (Maybe a) } instance (Functor m) => Functor (MaybeT m) where fmap f (MaybeT ma) = MaybeT $ (fmap . fmap) f ma instance forall f . (Applicative f) => Applicative (MaybeT f) where pure :: a -> MaybeT f a pure x = MaybeT (pure (pure x)) (<*>) :: forall a b . Applicative f => MaybeT f (a -> b) -> MaybeT f a -> MaybeT f b (MaybeT fab) <*> (MaybeT mma) = let fab' :: f (Maybe (a -> b)) fab' = fab in MaybeT $ undefined }}} Works fine in 7.10.3, breaks in GHC 8.0: {{{ Prelude> :l code/myMaybeT1.hs [1 of 1] Compiling MyMaybeT ( code/myMaybeT1.hs, interpreted ) code/myMaybeT1.hs:13:10: error: Malformed instance: forall f. (Applicative f) => Applicative (MaybeT f) code/myMaybeT1.hs:14:3: error: The class method signature for ?pure? lacks an accompanying binding (The class method signature must be given where ?pure? is declared) code/myMaybeT1.hs:17:3: error: The class method signature for ?<*>? lacks an accompanying binding (The class method signature must be given where ?<*>? is declared) code/myMaybeT1.hs:17:37: error: Not in scope: type variable ?f? code/myMaybeT1.hs:17:49: error: Not in scope: type variable ?f? code/myMaybeT1.hs:17:70: error: Not in scope: type variable ?f? code/myMaybeT1.hs:17:84: error: Not in scope: type variable ?f? Failed, modules loaded: none. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 05:19:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 05:19:00 -0000 Subject: [GHC] #11552: ScopedTypeVariables / InstanceSigs do not work in GHC 8.0 In-Reply-To: <048.ed8df3269063d4724395b509ea472611@haskell.org> References: <048.ed8df3269063d4724395b509ea472611@haskell.org> Message-ID: <063.7f430e90c3babf057eeaf13851dd2981@haskell.org> #11552: ScopedTypeVariables / InstanceSigs do not work in GHC 8.0 -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 bitemyapp: @@ -53,0 +53,5 @@ + + {{{ + $ ghci --version + The Glorious Glasgow Haskell Compilation System, version 8.0.0.20160122 + }}} New description: {{{ {-# LANGUAGE InstanceSigs #-} {-# LANGUAGE ScopedTypeVariables #-} module MyMaybeT where newtype MaybeT m a = MaybeT { runMaybeT :: m (Maybe a) } instance (Functor m) => Functor (MaybeT m) where fmap f (MaybeT ma) = MaybeT $ (fmap . fmap) f ma instance forall f . (Applicative f) => Applicative (MaybeT f) where pure :: a -> MaybeT f a pure x = MaybeT (pure (pure x)) (<*>) :: forall a b . Applicative f => MaybeT f (a -> b) -> MaybeT f a -> MaybeT f b (MaybeT fab) <*> (MaybeT mma) = let fab' :: f (Maybe (a -> b)) fab' = fab in MaybeT $ undefined }}} Works fine in 7.10.3, breaks in GHC 8.0: {{{ Prelude> :l code/myMaybeT1.hs [1 of 1] Compiling MyMaybeT ( code/myMaybeT1.hs, interpreted ) code/myMaybeT1.hs:13:10: error: Malformed instance: forall f. (Applicative f) => Applicative (MaybeT f) code/myMaybeT1.hs:14:3: error: The class method signature for ?pure? lacks an accompanying binding (The class method signature must be given where ?pure? is declared) code/myMaybeT1.hs:17:3: error: The class method signature for ?<*>? lacks an accompanying binding (The class method signature must be given where ?<*>? is declared) code/myMaybeT1.hs:17:37: error: Not in scope: type variable ?f? code/myMaybeT1.hs:17:49: error: Not in scope: type variable ?f? code/myMaybeT1.hs:17:70: error: Not in scope: type variable ?f? code/myMaybeT1.hs:17:84: error: Not in scope: type variable ?f? Failed, modules loaded: none. }}} {{{ $ ghci --version The Glorious Glasgow Haskell Compilation System, version 8.0.0.20160122 }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 05:32:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 05:32:27 -0000 Subject: [GHC] #11552: ScopedTypeVariables / InstanceSigs do not work in GHC 8.0 In-Reply-To: <048.ed8df3269063d4724395b509ea472611@haskell.org> References: <048.ed8df3269063d4724395b509ea472611@haskell.org> Message-ID: <063.7e9604a5ac5fd9bd950d1d4d23204166@haskell.org> #11552: ScopedTypeVariables / InstanceSigs do not work in GHC 8.0 -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 rwbarton): Not sure whether this change was intentional, but you don't need the `forall f .`, and the code compiles fine without it. See http://ghc.readthedocs.org/en/latest/glasgow_exts.html#class-and-instance- declarations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 05:40:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 05:40:18 -0000 Subject: [GHC] #11552: ScopedTypeVariables / InstanceSigs do not work in GHC 8.0 In-Reply-To: <048.ed8df3269063d4724395b509ea472611@haskell.org> References: <048.ed8df3269063d4724395b509ea472611@haskell.org> Message-ID: <063.2162f8ed6ab7e2895e2d29a9124d46f3@haskell.org> #11552: ScopedTypeVariables / InstanceSigs do not work in GHC 8.0 -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 bitemyapp): That has fixed it for GHC 8.0 and 7.10.3, thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 08:58:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 08:58:03 -0000 Subject: =?utf-8?b?W0dIQ10gIzExNTUzOiBgcm91bmQgKMKxIOKIniA6OiBEb3VibGUp?= =?utf-8?q?=60_not_infinite?= Message-ID: <042.93f88cdeba35ad1f9966dc1928b5debf@haskell.org> #11553: `round (? ? :: Double)` not infinite -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: libraries/base | 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: -------------------------------------+------------------------------------- Rounding 1/0 or 0/0 results in an arbitrary chosen `Integer` value, e.g. {{{ ?:2> (round (1/0 :: Double) :: Integer) == 2^1024 True ?:3> (round (-1/0 :: Double) :: Integer) == -(2^1024) True }}} I'm not sure if this is more desirable than returning a bottom value (e.g. by throwing some `ArithException`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 09:01:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 09:01:01 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMTU1MzogYHJvdW5kICjCsSDiiJ4gOjogRG91?= =?utf-8?q?ble=29=60_not_infinite?= In-Reply-To: <042.93f88cdeba35ad1f9966dc1928b5debf@haskell.org> References: <042.93f88cdeba35ad1f9966dc1928b5debf@haskell.org> Message-ID: <057.2aaf289fbd5db585f72ae5ce79dad629@haskell.org> #11553: `round (? ? :: Double)` not infinite -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by hvr: @@ -1,1 +1,1 @@ - Rounding 1/0 or 0/0 results in an arbitrary chosen `Integer` value, e.g. + Rounding 1/0 or -1/0 results in an arbitrary chosen `Integer` value, e.g. @@ -9,0 +9,3 @@ + + ?:4> (round (0/0 :: Double) :: Integer) == -(2^1024 + 2^1023) + True New description: Rounding 1/0 or -1/0 results in an arbitrary chosen `Integer` value, e.g. {{{ ?:2> (round (1/0 :: Double) :: Integer) == 2^1024 True ?:3> (round (-1/0 :: Double) :: Integer) == -(2^1024) True ?:4> (round (0/0 :: Double) :: Integer) == -(2^1024 + 2^1023) True }}} I'm not sure if this is more desirable than returning a bottom value (e.g. by throwing some `ArithException`) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 10:11:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 10:11:28 -0000 Subject: [GHC] #11529: Show instance of Char should print literals for non-ascii printable charcters In-Reply-To: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> References: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> Message-ID: <060.e2032d282e55e646d930142fb1bf3f3c@haskell.org> #11529: Show instance of Char should print literals for non-ascii printable charcters -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nushio): (+1) to suggestion that to change the default interactive printer to display unicode characters nicely. The algorithm in `unicode-show` might be suitable for the purpose, although there should be various opinions on what is the "nice way to print unicode." By the way, if we update the default interactive printer, will we be breaking the `doctests` that `show`s values with unicodes, forcing them to update the expected results from the interpreter? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 10:39:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 10:39:12 -0000 Subject: [GHC] #11550: ghc-HEAD -DDEBUG is broken (possiby by D1880) In-Reply-To: <045.510eebdecea6778a3cdc8536c2c13abb@haskell.org> References: <045.510eebdecea6778a3cdc8536c2c13abb@haskell.org> Message-ID: <060.5e154bef1b4c2f5325aa7c13d5143174@haskell.org> #11550: ghc-HEAD -DDEBUG is broken (possiby by D1880) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1889 Wiki Page: | -------------------------------------+------------------------------------- Changes (by slyfox): * status: patch => closed * resolution: => fixed Comment: Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 10:43:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 10:43:26 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.a4fdabe6047322fd551cd555d833ca14@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1205 Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Tried to revive the discussion at https://mail.haskell.org/pipermail/libraries/2016-February/026663.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 11:50:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 11:50:27 -0000 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax In-Reply-To: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> References: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> Message-ID: <057.9cbf391150acab9fc5c4709284356e39@haskell.org> #2530: deriving Show adds extra parens for constructor with record syntax -------------------------------------+------------------------------------- Reporter: spl | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 8.0.1 Component: Compiler | 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: | Differential Rev(s): Phab:D669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Fyi, this broke a few testsuites of mine based on golden-tests based on the `Show`-serialisation. Not sure yet how I can fix this other than using a duplicated set of golden files with the old and new `Show` instance serialisation... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 14:33:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 14:33:13 -0000 Subject: [GHC] #11552: ScopedTypeVariables / InstanceSigs do not work in GHC 8.0 In-Reply-To: <048.ed8df3269063d4724395b509ea472611@haskell.org> References: <048.ed8df3269063d4724395b509ea472611@haskell.org> Message-ID: <063.e0a6a8f33fe0e8432b5e030828ce26fc@haskell.org> #11552: ScopedTypeVariables / InstanceSigs do not work in GHC 8.0 -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 goldfire): * owner: => goldfire Comment: I think I know what caused this regression, and there's no good reason for it. It is simple, so I'll add this to my queue. (I'm 98% sure that this is caused by my changes to the parser in order to account for the kind `*`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 14:39:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 14:39:31 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.8247b7cbc6f0e50f7587d06a2c8d61b8@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: SafeHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8226, #8745 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I don't have time to remind myself of this whole conversation now, but I wanted to share a point that came up in a related conversation, by @nomeata, about the horrible recursive find-all-constructors-out-to-the- leaves check: "But, wouldn?t we, at such a check, only have to look at things that are already imported? If anything is not imported, the check would fail and we could stop. (This now assumes that imported things are loaded, no extra loading would happen.)" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 14:46:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 14:46:57 -0000 Subject: [GHC] #11162: T783 regresses severely in allocations with new pattern match checker In-Reply-To: <046.e9f04abec159fcbe6066b924b6d5e3f9@haskell.org> References: <046.e9f04abec159fcbe6066b924b6d5e3f9@haskell.org> Message-ID: <061.cfff5aaa51cbd92f883ac60afa7b2f6b@haskell.org> #11162: T783 regresses severely in allocations with new pattern match checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T783 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * milestone: => 8.0.1 Comment: From `testsuite/tests/perf/compiler/all.T` for `T783`: {{{ 2015-08-28: 526230456 (amd64/Linux) 2016-02-03: 488592288 (amd64/Linux) }}} So bytes allocated is now 7% lower than it was before the whole pattern match checker overhaul. Nice. The patch has been merged to 8.0 already in 6e23b68047a2c995562eba173fe9485cae18bff2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 14:47:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 14:47:05 -0000 Subject: [GHC] #11162: T783 regresses severely in allocations with new pattern match checker In-Reply-To: <046.e9f04abec159fcbe6066b924b6d5e3f9@haskell.org> References: <046.e9f04abec159fcbe6066b924b6d5e3f9@haskell.org> Message-ID: <061.7078fc6d6df73ab4f5fab7b5a3f3254e@haskell.org> #11162: T783 regresses severely in allocations with new pattern match checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T783 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 14:54:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 14:54:29 -0000 Subject: [GHC] #11510: Missing Show instance for GHC.Stack.SrcLoc In-Reply-To: <050.e08b70941207067cd22a7124ead2f765@haskell.org> References: <050.e08b70941207067cd22a7124ead2f765@haskell.org> Message-ID: <065.34ac39e436d6fea773eee36f8ba68462@haskell.org> #11510: Missing Show instance for GHC.Stack.SrcLoc -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc1 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:D1886 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 15:00:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 15:00:42 -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.bd1fe19ccf25b726bb56291c6443b8a0@haskell.org> #11498: GHC requires kind-polymorphic signatures on class head -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.2-rc2 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 thomie): * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 15:17:50 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 15:17:50 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.238d4c9fcc6e8cab8af0dcc4b9938902@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Thanks for reporting. Maybe you want to help fix it? Once `fibon` is at least building again, we can make it part of validate. See #9572. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 15:23:54 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 15:23:54 -0000 Subject: [GHC] #11504: Can't install haskell-platform in OpenBSD In-Reply-To: <048.527cd8144ea27e8efd2ea022a74e8a79@haskell.org> References: <048.527cd8144ea27e8efd2ea022a74e8a79@haskell.org> Message-ID: <063.e1e115ebc9b54243bceee714a5983a2a@haskell.org> #11504: Can't install haskell-platform in OpenBSD ------------------------------------------+------------------------------ Reporter: Achifaifa | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Package system | Version: 7.10.3 Resolution: invalid | Keywords: Operating System: OpenBSD | Architecture: x86 Type of failure: Installing GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------------+------------------------------ Changes (by thomie): * status: new => closed * resolution: => invalid Comment: Ok, thanks for reporting. Unfortunately 7.4.2 is no longer supported (maybe we should put expected end-of-life in those error messages). Please try with a more recent ghc release, such as 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 15:25:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 15:25:53 -0000 Subject: [GHC] #10898: GHCI crash In-Reply-To: <045.6b0350008e1009dd255fc812f56da5c5@haskell.org> References: <045.6b0350008e1009dd255fc812f56da5c5@haskell.org> Message-ID: <060.81c4e44f80843ecc60013cf4c0b1a0b0@haskell.org> #10898: GHCI crash -------------------------------+------------------------------ Reporter: trebor | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: worksforme | Keywords: Operating System: Linux | Architecture: x86 Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+------------------------------ Changes (by thomie): * status: infoneeded => closed * resolution: => worksforme Comment: I think this `interactiveUI:setBuffering2` bug has been fixed a long time ago, so I'm closing this ticket (reported against 7.6.3). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 15:34:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 15:34:20 -0000 Subject: [GHC] #10862: No way to exclude current directory from search path In-Reply-To: <046.896446a44757716ea085cdf95c0a86ea@haskell.org> References: <046.896446a44757716ea085cdf95c0a86ea@haskell.org> Message-ID: <061.0749197940ec168cba5517c3fa5ca489@haskell.org> #10862: No way to exclude current directory from search path -------------------------------------+------------------------------------- Reporter: literon | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Driver | Version: 7.8.3 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => worksforme Comment: No response from submitter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 15:36:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 15:36:59 -0000 Subject: [GHC] #11465: Eliminate check_lifted check in TcValidity In-Reply-To: <046.8d383cd5b7ced0427539a51976b34ef3@haskell.org> References: <046.8d383cd5b7ced0427539a51976b34ef3@haskell.org> Message-ID: <061.4f9f06fee6b084122479df4f22034e00@haskell.org> #11465: Eliminate check_lifted check in TcValidity -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1807 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): The test case for this was as follows {{{ class BoxIt (a :: TYPE 'Unlifted) where type Boxed a :: * boxed :: a -> Boxed a instance BoxIt Char# where type Boxed Char# = Char boxed x = C# x main :: IO () main = print $ boxed 'c'# }}} After refactoring the levity stuff as per #11471, this test failed (of course). But as I look at it, it's amazing that it ever worked. The width to the argument of `boxed` is entirely unknowable. Anyway, it's all much better now. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 15:40:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 15:40:09 -0000 Subject: [GHC] #10919: ghc: panic! (the 'impossible' happened) ... Dynamic linker not initialised In-Reply-To: <054.0b98f2d3ec398afce2ee51103df99d47@haskell.org> References: <054.0b98f2d3ec398afce2ee51103df99d47@haskell.org> Message-ID: <069.5cc47cedbfc9dff9551901d62a68a1c5@haskell.org> #10919: ghc: panic! (the 'impossible' happened) ... Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: recursion-ninja | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: worksforme | Keywords: panic | impossible linker initialized Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => worksforme Comment: `accelate-cuda` is building successfuly on Travis with ghc-7.8.4 and ghc-7.10.3, so I think the problem is fixed: https://travis- ci.org/AccelerateHS/accelerate-cuda -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 15:40:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 15:40:20 -0000 Subject: [GHC] #11419: Binary distributions seem to lack haddock docs In-Reply-To: <046.301e54ff3450cc81bb3b03acb25df199@haskell.org> References: <046.301e54ff3450cc81bb3b03acb25df199@haskell.org> Message-ID: <061.3b48217d958251454a44329b16c67306@haskell.org> #11419: Binary distributions seem to lack haddock docs -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: 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 binary distributions do not in fact lack documentation. However, `mkDocs` still fails. This is a knock-on effect of c5f4f95c64006a9f018301dc1311d65195d9dec4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 16:05:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 16:05:59 -0000 Subject: [GHC] #11522: maxStkSize can overflow In-Reply-To: <047.c682131ad79ad28d6b34355aabbd4286@haskell.org> References: <047.c682131ad79ad28d6b34355aabbd4286@haskell.org> Message-ID: <062.26192ea648f12f0054ee7808d55814fc@haskell.org> #11522: maxStkSize can overflow -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: MarcelineVQ (added) Comment: MarcelineVQ: maybe you can have a look at this one as well, while you're working on #11502. Don't forget a test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 16:24:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 16:24:13 -0000 Subject: [GHC] #11530: Make fails on systems with GREP_OPTIONS In-Reply-To: <047.65eb2c1162c4e0a77b27714fb3375078@haskell.org> References: <047.65eb2c1162c4e0a77b27714fb3375078@haskell.org> Message-ID: <062.caac353727fc025347d712bb12c34c44@haskell.org> #11530: Make fails on systems with GREP_OPTIONS ---------------------------------+---------------------------------------- Reporter: alexlegg | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Resolution: | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1887 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by thomie): * differential: Phab:D1886 => Phab:D1887 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 16:30:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 16:30:41 -0000 Subject: [GHC] #11532: ghc: panic! occured In-Reply-To: <045.2d3308752fa81c80b55c3625ddb38f5a@haskell.org> References: <045.2d3308752fa81c80b55c3625ddb38f5a@haskell.org> Message-ID: <060.f6e9daae4a8a291b2bdeef6ac584283a@haskell.org> #11532: ghc: panic! occured -------------------------------------+------------------------------------- Reporter: cutsea | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): cutsea: that's great that you can reproduce the problem consistently. The next step would be to reduce the problem to a tiny testcase, without any cabal dependencies. Maybe you could give it a try? If not, one of us can probably do it at some point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 16:38:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 16:38:09 -0000 Subject: [GHC] #11539: Warn about missing forall when -XScopedTypeVariables is on In-Reply-To: <045.6c55e4ce55a104b4103356eb9a3637a1@haskell.org> References: <045.6c55e4ce55a104b4103356eb9a3637a1@haskell.org> Message-ID: <060.8cec28f06b951cb655738085270ce624@haskell.org> #11539: Warn about missing forall when -XScopedTypeVariables is on -------------------------------------+------------------------------------- Reporter: kanetw | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9244 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #9244 Comment: This is covered by #9244. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 16:39:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 16:39:10 -0000 Subject: [GHC] #9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables In-Reply-To: <047.4ca6fb75e0604e66c9de7145ac89f916@haskell.org> References: <047.4ca6fb75e0604e66c9de7145ac89f916@haskell.org> Message-ID: <062.de565f0e6597182355a591d4a1a2ea44@haskell.org> #9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables -------------------------------------+------------------------------------- Reporter: stusmith | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #1316, #3691, | Differential Rev(s): #11438, #10581, #11539 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: #1316, #3691, #11438,10581 => #1316, #3691, #11438, #10581, #11539 Comment: #11539 requests to warn about missing forall when `-XScopedTypeVariables` is on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 16:41:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 16:41:31 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.075e1d119c1d528782782e386f3bc792@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rem): Can try. I heard of plans to port the benchmarks to Shake, is that happening? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 16:43:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 16:43:49 -0000 Subject: [GHC] #11542: Profiling call count frequently 0 when it shouldn't be In-Reply-To: <047.b0ecc7025940d726f91548515350f7d9@haskell.org> References: <047.b0ecc7025940d726f91548515350f7d9@haskell.org> Message-ID: <062.3bca3e3e497e27156431942bc1279441@haskell.org> #11542: Profiling call count frequently 0 when it shouldn't be -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * component: Compiler => Profiling -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 16:47:54 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 16:47:54 -0000 Subject: [GHC] #7105: Better names for derived SCCs of instances In-Reply-To: <042.2fbb06d1a4b326bebe4b64cda6396110@haskell.org> References: <042.2fbb06d1a4b326bebe4b64cda6396110@haskell.org> Message-ID: <057.c4b5c6a3bac3492ea8496193beb13754@haskell.org> #7105: Better names for derived SCCs of instances -------------------------------------+------------------------------------- Reporter: ksf | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Profiling | 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: #11543 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #11543 Comment: Also reported as #11543. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 16:48:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 16:48:04 -0000 Subject: [GHC] #11543: Profiling information ambiguous In-Reply-To: <047.f56e01bd6ad8bd0c84dfa18f1d7c5710@haskell.org> References: <047.f56e01bd6ad8bd0c84dfa18f1d7c5710@haskell.org> Message-ID: <062.f8cc8c225c7a46f0c0c4609f2ecf26ed@haskell.org> #11543: Profiling information ambiguous -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Profiling | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7105 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * component: Compiler => Profiling * related: => #7105 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 16:59:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 16:59:30 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.8419764854a8b242e088fc7a3deb52c1@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): A rewrite of the build system is happening here: https://github.com/snowleopard/shaking-up-ghc. I don't know what the plans for nofib are. Some code was written 4 years ago, see #5793. If you want, you can also pick this project up. The bug in this ticket is probably unrelated to `make` vs `shake`, but I might be wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 17:07:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 17:07:55 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.fe6b051eb1a9f077e9a281ee57aead59@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rem): I thought something went wrong here in the Makefiles, but there are other possibilities. It seems more practical to stick with the current build system and get it to work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 17:09:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 17:09:01 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.787179ab8c813601c7353f578e43a6df@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rem): How does one take on a ticket, or has to be assigned? Haven't done this before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 17:35:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 17:35:55 -0000 Subject: [GHC] #11510: Missing Show instance for GHC.Stack.SrcLoc In-Reply-To: <050.e08b70941207067cd22a7124ead2f765@haskell.org> References: <050.e08b70941207067cd22a7124ead2f765@haskell.org> Message-ID: <065.cc208f6fec6b1e15b7cf38495c855773@haskell.org> #11510: Missing Show instance for GHC.Stack.SrcLoc -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1886 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: This was merged to `ghc-8.0` as bffb7afbde197763b5897b16efb02f5ec4833828. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 17:38:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 17:38:56 -0000 Subject: [GHC] #11419: Binary distributions seem to lack haddock docs In-Reply-To: <046.301e54ff3450cc81bb3b03acb25df199@haskell.org> References: <046.301e54ff3450cc81bb3b03acb25df199@haskell.org> Message-ID: <061.70e3c6af4760ab92a7a9543b5f7e45b5@haskell.org> #11419: Binary distributions seem to lack haddock docs -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: 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 were a few issues with `mkDocs`, * the `ghc` directory now has a version number suffix, as mentioned in comment:2. * it was looking for a gzip archive, not a xz archive. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 17:41:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 17:41:38 -0000 Subject: [GHC] #11419: Binary distributions seem to lack haddock docs In-Reply-To: <046.301e54ff3450cc81bb3b03acb25df199@haskell.org> References: <046.301e54ff3450cc81bb3b03acb25df199@haskell.org> Message-ID: <061.1071f445f48683b6bcbd3a989daaa5f8@haskell.org> #11419: Binary distributions seem to lack haddock docs -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 18:12:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 18:12:32 -0000 Subject: [GHC] #11419: Binary distributions seem to lack haddock docs In-Reply-To: <046.301e54ff3450cc81bb3b03acb25df199@haskell.org> References: <046.301e54ff3450cc81bb3b03acb25df199@haskell.org> Message-ID: <061.525b46081adfd4777befc2f7bc417962@haskell.org> #11419: Binary distributions seem to lack haddock docs -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"10603015d9b03531a688d77e25dffce4738f4818/ghc" 10603015/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="10603015d9b03531a688d77e25dffce4738f4818" mkDocs: Update for xz Fixes #11419. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 18:12:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 18:12:32 -0000 Subject: [GHC] #11419: Binary distributions seem to lack haddock docs In-Reply-To: <046.301e54ff3450cc81bb3b03acb25df199@haskell.org> References: <046.301e54ff3450cc81bb3b03acb25df199@haskell.org> Message-ID: <061.903b8e30ffd2e90569d89b690c726a4b@haskell.org> #11419: Binary distributions seem to lack haddock docs -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c96acf366119eeb683dc413e84610bfc168e1106/ghc" c96acf36/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c96acf366119eeb683dc413e84610bfc168e1106" mkDocs: Fix fallout from c5f4f95c64006a9f Fixes #11419 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 18:13:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 18:13:51 -0000 Subject: [GHC] #11419: Binary distributions seem to lack haddock docs In-Reply-To: <046.301e54ff3450cc81bb3b03acb25df199@haskell.org> References: <046.301e54ff3450cc81bb3b03acb25df199@haskell.org> Message-ID: <061.cd3bda8b6fc057bca4a06768af3bc00b@haskell.org> #11419: Binary distributions seem to lack haddock docs -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `ghc-8.0` as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 18:17:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 18:17:23 -0000 Subject: [GHC] #11419: Binary distributions seem to lack haddock docs In-Reply-To: <046.301e54ff3450cc81bb3b03acb25df199@haskell.org> References: <046.301e54ff3450cc81bb3b03acb25df199@haskell.org> Message-ID: <061.7ccfc04a6acb7e4fdd0d42ad03ba4dc5@haskell.org> #11419: Binary distributions seem to lack haddock docs -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): TIL about `mkDocs`. Sorry for breaking it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 18:28:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 18:28:16 -0000 Subject: [GHC] #4029: ghci leaks memory when loading a file In-Reply-To: <046.7e3cd0db8a339c9dc956ab26c7e5c0ec@haskell.org> References: <046.7e3cd0db8a339c9dc956ab26c7e5c0ec@haskell.org> Message-ID: <061.33203ed420ab4db8e364f6413b52204e@haskell.org> #4029: ghci leaks memory when loading a file -------------------------------------------------+------------------------- Reporter: blarsen | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: GHCi | Version: Resolution: | Keywords: memory | leak Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time performance bug | Test Case: Blocked By: | Blocking: -------------------------------------------------+------------------------- Changes (by jme): * Attachment "Leak.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 18:28:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 18:28:28 -0000 Subject: [GHC] #4029: ghci leaks memory when loading a file In-Reply-To: <046.7e3cd0db8a339c9dc956ab26c7e5c0ec@haskell.org> References: <046.7e3cd0db8a339c9dc956ab26c7e5c0ec@haskell.org> Message-ID: <061.0de9be7eecefd060aa2c56f6b1c73425@haskell.org> #4029: ghci leaks memory when loading a file -------------------------------------------------+------------------------- Reporter: blarsen | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: GHCi | Version: Resolution: | Keywords: memory | leak Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time performance bug | Test Case: Blocked By: | Blocking: -------------------------------------------------+------------------------- Changes (by jme): * Attachment "leak.script" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 18:28:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 18:28:39 -0000 Subject: [GHC] #4029: ghci leaks memory when loading a file In-Reply-To: <046.7e3cd0db8a339c9dc956ab26c7e5c0ec@haskell.org> References: <046.7e3cd0db8a339c9dc956ab26c7e5c0ec@haskell.org> Message-ID: <061.50fb41e0b3dfdc1317451839775c18c4@haskell.org> #4029: ghci leaks memory when loading a file -------------------------------------------------+------------------------- Reporter: blarsen | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: GHCi | Version: Resolution: | Keywords: memory | leak Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time performance bug | Test Case: Blocked By: | Blocking: -------------------------------------------------+------------------------- Changes (by jme): * Attachment "workaround.script" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 18:33:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 18:33:00 -0000 Subject: [GHC] #11554: Self quantification in GADT data declarations Message-ID: <046.bec85a0842a04f6c9921baff0e29a2a1@haskell.org> #11554: Self quantification in GADT data declarations -------------------------------------+------------------------------------- Reporter: Rafbill | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | 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 hangs on this (it was panicking on the same code before : [https://github.com/goldfirere/ghc/issues/56](https://github.com/goldfirere/ghc/issues/56) : {{{#!hs {-# LANGUAGE GADTs, TypeInType #-} import Data.Kind data A :: Type where B :: forall (a :: A). A }}} I guess the typechecker tries to infer the kind of A from the type of the constructors and hangs. Maybe recursive occurrences of a type as a kind in its constructors should only be allowed when its kind signature is specified and can be used to typecheck the constructors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 18:33:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 18:33:28 -0000 Subject: [GHC] #4029: ghci leaks memory when loading a file In-Reply-To: <046.7e3cd0db8a339c9dc956ab26c7e5c0ec@haskell.org> References: <046.7e3cd0db8a339c9dc956ab26c7e5c0ec@haskell.org> Message-ID: <061.af265cc29a05f9f11ce7e58802393f98@haskell.org> #4029: ghci leaks memory when loading a file -------------------------------------+------------------------------------- Reporter: blarsen | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: GHCi | Version: Resolution: | Keywords: memory leak 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 jme): There is a new leak on the 8.0 branch. For example, running attachment:leak.script, which simply loads attachment:Leak.hs 20 times, results in a max residency of 115 MB: {{{ $ inplace/bin/ghc-stage2 --version The Glorious Glasgow Haskell Compilation System, version 8.0.0.20160206 $ inplace/bin/ghc-stage2 --interactive +RTS -t < leak.script > /dev/null <> }}} This is an obvious regression from 7.10.3, for which the max residency is 18.3 MB: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 $ ghc --interactive +RTS -t < leak.script > /dev/null <> }}} There is a quick fix for the bulk of the leak (just make the `hsc_IC` field in `HscTypes.HscEnv` strict), but I'd like to track down what caused the regression before I submit a patch. In the meantime, anyone who needs a workaround (without recompiling) should periodically run a command which references the contents of the loaded module. For example, by querying the type of a constructor after each load, attachment:workaround.script is able to reduce the max residency to 29.1 MB: {{{ $ inplace/bin/ghc-stage2 --interactive +RTS -t < workaround.script > /dev/null <> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 18:42:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 18:42:08 -0000 Subject: [GHC] #4029: ghci leaks memory when loading a file In-Reply-To: <046.7e3cd0db8a339c9dc956ab26c7e5c0ec@haskell.org> References: <046.7e3cd0db8a339c9dc956ab26c7e5c0ec@haskell.org> Message-ID: <061.3d32fe805e0a850565ba5280c93b53ef@haskell.org> #4029: ghci leaks memory when loading a file -------------------------------------+------------------------------------- Reporter: blarsen | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: Resolution: | Keywords: memory leak Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * priority: normal => high * milestone: ? => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 18:43:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 18:43:09 -0000 Subject: [GHC] #11554: Self quantification in GADT data declarations In-Reply-To: <046.bec85a0842a04f6c9921baff0e29a2a1@haskell.org> References: <046.bec85a0842a04f6c9921baff0e29a2a1@haskell.org> Message-ID: <061.5edc4da6778dc9ae99c381d291183a06@haskell.org> #11554: Self quantification in GADT data declarations -------------------------------------+------------------------------------- Reporter: Rafbill | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => TypeInType * failure: None/Unknown => Compile-time crash * priority: normal => high * component: Compiler => Compiler (Type checker) * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 18:44:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 18:44:51 -0000 Subject: [GHC] #8265: getTokenStream fails for source using cpp In-Reply-To: <044.c2e14a732cb70550e894f0c0106fd8dd@haskell.org> References: <044.c2e14a732cb70550e894f0c0106fd8dd@haskell.org> Message-ID: <059.04a4b23255933cee8f814d0f4ed6eb9f@haskell.org> #8265: getTokenStream fails for source using cpp -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * Attachment "tokenbug.2.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 18:44:50 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 18:44:50 -0000 Subject: [GHC] #8265: getTokenStream fails for source using cpp In-Reply-To: <044.c2e14a732cb70550e894f0c0106fd8dd@haskell.org> References: <044.c2e14a732cb70550e894f0c0106fd8dd@haskell.org> Message-ID: <059.7cf3f9b978e7b8a9c8c12239bcf6a7c2@haskell.org> #8265: getTokenStream fails for source using cpp -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by thomie): * Attachment "tokenbug.2.hs" removed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 18:46:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 18:46:12 -0000 Subject: [GHC] #8265: getTokenStream fails for source using cpp In-Reply-To: <044.c2e14a732cb70550e894f0c0106fd8dd@haskell.org> References: <044.c2e14a732cb70550e894f0c0106fd8dd@haskell.org> Message-ID: <059.4dfabd318b14b39e3c19bea5348581e2@haskell.org> #8265: getTokenStream fails for source using cpp -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): @alanz: can you confirm this is fixed? I can't find the commit that did it though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 18:49:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 18:49:05 -0000 Subject: [GHC] #8265: getTokenStream fails for source using cpp In-Reply-To: <044.c2e14a732cb70550e894f0c0106fd8dd@haskell.org> References: <044.c2e14a732cb70550e894f0c0106fd8dd@haskell.org> Message-ID: <059.cbced771be0fcb22cec0b22b35aa1185@haskell.org> #8265: getTokenStream fails for source using cpp -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by alanz): * owner: => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 19:02:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 19:02:20 -0000 Subject: [GHC] #8207: Pretty Printer for textual version of Language (name) in DynFlags In-Reply-To: <047.ff066453d0b5bb8959d2c8e8b4d65d05@haskell.org> References: <047.ff066453d0b5bb8959d2c8e8b4d65d05@haskell.org> Message-ID: <062.bb3fbfad78d84a46c2a56bdadbc9f35c@haskell.org> #8207: Pretty Printer for textual version of Language (name) in DynFlags -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: GHC API | Version: 7.7 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 thomie): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 19:07:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 19:07:31 -0000 Subject: [GHC] #11419: Binary distributions seem to lack haddock docs In-Reply-To: <046.301e54ff3450cc81bb3b03acb25df199@haskell.org> References: <046.301e54ff3450cc81bb3b03acb25df199@haskell.org> Message-ID: <061.d25531431696b8f8bfcb704140c95327@haskell.org> #11419: Binary distributions seem to lack haddock docs -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Build System | Version: 8.0.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): TIL about `mkDocs` as well. No worries! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 19:08:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 19:08:56 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.1ef75a6f4d20cf99850536d705b39f55@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: rem Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | 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 bgamari): * owner: => rem Comment: There you are! If you open the "Modify Ticket" button you'll see an "Assign to" option which you can use in the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 19:15:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 19:15:20 -0000 Subject: [GHC] #8136: Some tests segfault randomly with ghci way In-Reply-To: <048.1bdfc638111b21a21e4300b2120d40a1@haskell.org> References: <048.1bdfc638111b21a21e4300b2120d40a1@haskell.org> Message-ID: <063.6ff752136ac465d7e2958ea6a3355bac@haskell.org> #8136: Some tests segfault randomly with ghci way ----------------------------------+------------------------------ Reporter: jstolarek | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.7 Resolution: worksforme | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Changes (by thomie): * status: new => closed * resolution: => worksforme Comment: Assuming this was either hardware failure, or since fixed. I can not reproduce. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 19:31:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 19:31:31 -0000 Subject: [GHC] #4029: ghci leaks memory when loading a file In-Reply-To: <046.7e3cd0db8a339c9dc956ab26c7e5c0ec@haskell.org> References: <046.7e3cd0db8a339c9dc956ab26c7e5c0ec@haskell.org> Message-ID: <061.15ea4497154e9cd93518e9ba3ff0d4aa@haskell.org> #4029: ghci leaks memory when loading a file -------------------------------------+------------------------------------- Reporter: blarsen | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: Resolution: | Keywords: memory leak 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 jme): * cc: jme (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 19:51:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 19:51:17 -0000 Subject: [GHC] #11491: GHC 10.7.3 panic while executing 'stack upgrade' on Mac OSX El Capitan In-Reply-To: <050.f1d2d2fd741ac35dc7874d58b9d5c990@haskell.org> References: <050.f1d2d2fd741ac35dc7874d58b9d5c990@haskell.org> Message-ID: <065.7aa878ff133371025509e9620672eb80@haskell.org> #11491: GHC 10.7.3 panic while executing 'stack upgrade' on Mac OSX El Capitan ---------------------------------+---------------------------------------- Reporter: hienqnguyen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by hienqnguyen): I did the following and it worked fine: {{{ ln -s /usr/local/Cellar/ghc/7.10.3b /usr/local/opt/ghc }}} So it definitely related to my local installation. I used `brew` so I think this is an issue with `brew` and not `ghc` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 19:53:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 19:53:12 -0000 Subject: [GHC] #11491: GHC 10.7.3 panic while executing 'stack upgrade' on Mac OSX El Capitan In-Reply-To: <050.f1d2d2fd741ac35dc7874d58b9d5c990@haskell.org> References: <050.f1d2d2fd741ac35dc7874d58b9d5c990@haskell.org> Message-ID: <065.90aa2513ea36c7d7119d6d2e4917156d@haskell.org> #11491: GHC 10.7.3 panic while executing 'stack upgrade' on Mac OSX El Capitan --------------------------------+---------------------------------------- Reporter: hienqnguyen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: wontfix | Keywords: 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 hienqnguyen): * status: new => closed * failure: None/Unknown => Other * resolution: => wontfix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 19:58:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 19:58:21 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.de52d9988149ad4d34f3dd29bd30af55@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Just another data point about when people use functional dependencies over class associated types: I'm at the Compose conference in New York talking to Brian Hurt who is refactoring the `monad-control` package to switch ''to'' functional dependencies from a class associated type so that he can support `GeneralizedNewtypeDeriving`. This also arises as a common idiom with the `mtl`, because you can use GND to derive `MonadState MyState`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 20:14:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 20:14:01 -0000 Subject: [GHC] #7860: Add more bit fiddling functions to 'integer-gmp' In-Reply-To: <046.cf50459cade182946253e5602ab21f1f@haskell.org> References: <046.cf50459cade182946253e5602ab21f1f@haskell.org> Message-ID: <061.c329d96f77b12e1062a8f44cfa9d02bd@haskell.org> #7860: Add more bit fiddling functions to 'integer-gmp' -------------------------------------+------------------------------------- Reporter: lebedev | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: gmp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3489, #9835 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: ekmett (added) * owner: => hvr * related: #3489, 9835 => #3489, #9835 Comment: Assigning to hvr as per comment:15. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 20:14:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 20:14:42 -0000 Subject: [GHC] #7860: Add more bit fiddling functions to 'integer-gmp' In-Reply-To: <046.cf50459cade182946253e5602ab21f1f@haskell.org> References: <046.cf50459cade182946253e5602ab21f1f@haskell.org> Message-ID: <061.0672313134b26599384e173a44a68b10@haskell.org> #7860: Add more bit fiddling functions to 'integer-gmp' -------------------------------------+------------------------------------- Reporter: lebedev | Owner: hvr Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: | Keywords: integer-gmp Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3489, #9835 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: gmp => integer-gmp -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 20:14:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 20:14:46 -0000 Subject: [GHC] #9210: "overlapping instances" through FunctionalDependencies In-Reply-To: <047.6a800cfcf265ed257e947bc6c7dfc0fb@haskell.org> References: <047.6a800cfcf265ed257e947bc6c7dfc0fb@haskell.org> Message-ID: <062.f72beae859e45de0a9fcbf0452069e61@haskell.org> #9210: "overlapping instances" through FunctionalDependencies -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Somehow, this program no longer compiles in GHC 8.0 or HEAD. Yay! I'd rather not just close this without knowing why it was fixed, and we should add a regression test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 20:24:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 20:24:59 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.7692e66f733c57cf487168ca1da898f1@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Another point is that GHC isn't very good at actually enforcing functional dependencies. For one thing, you can certainly fool it by putting orphan instances in different modules. But historically there have been several bugs where GHC failed to check the necessary conditions for the dependency to be functional under some cases. Notably, see #8634 and related tickets. For better or worse, after 7.8 fixed an often-abused bug, many users clamored for the old behavior. But that never quite happened, and the requests seem to have died out. In the past we've been fairly lackadaisical about such bugs since they don't seem to threaten type safety. From `class C a b | a -> b` and `C a b` and `C a b'` you cannot deduce `b ~ b'`. (In fact I think functional dependencies are much older than System FC.) But if we give access to the "functionally determined type" through a type family, then type safety is at stake so we have to treat such bugs seriously. Most likely, the implementation will force us to check the functional dependency correctly, and I would guess we will find a lot more programs that are currently abusing functional dependencies, to no real harm, and have to break them. Something to consider. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 20:35:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 20:35:21 -0000 Subject: [GHC] #10830: maximumBy has a space leak In-Reply-To: <051.80712d357123f27d6467f28abef6100b@haskell.org> References: <051.80712d357123f27d6467f28abef6100b@haskell.org> Message-ID: <066.0d0d37088249654ee8e7dbec048a6cf7@haskell.org> #10830: maximumBy has a space leak -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1205 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: ekmett (added) * component: libraries/base => Core Libraries -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 20:42:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 20:42:17 -0000 Subject: [GHC] #7862: Could not deduce (A) from the context (A, ...) In-Reply-To: <045.77e996083183797ec6c495029488c3f8@haskell.org> References: <045.77e996083183797ec6c495029488c3f8@haskell.org> Message-ID: <060.f3198d663a52b66e303138a5d46eadeb@haskell.org> #7862: Could not deduce (A) from the context (A, ...) -------------------------------------+------------------------------------- Reporter: alang9 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.8.3 checker) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T7862 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 Comment: This was fixed in commit a6f0f5ab45b2643b561e0a0a54a4f14745ab2152: {{{ Author: Simon Peyton Jones Date: Tue Dec 23 15:39:50 2014 +0000 Eliminate so-called "silent superclass parameters" The purpose of silent superclass parameters was to solve the awkward problem of superclass dictinaries being bound to bottom. See THE PROBLEM in Note [Recursive superclasses] in TcInstDcls Although the silent-superclass idea worked, * It had non-local consequences, and had effects even in Haddock, where we had to discard silent parameters before displaying instance declarations * It had unexpected peformance costs, shown up by Trac #3064 and its test case. In monad-transformer code, when constructing a Monad dictionary you had to pass an Applicative dictionary; and to construct that you neede a Functor dictionary. Yet these extra dictionaries were often never used. (All this got much worse when we added Applicative as a superclass of Monad.) Test T3064 compiled *far* faster after silent superclasses were eliminated. * It introduced new bugs. For example SilentParametersOverlapping, T5051, and T7862, all failed to compile because of instance overlap directly because of the silent-superclass trick. So this patch takes a new approach, which I worked out with Dimitrios in the closing hours before Christmas. It is described in detail in THE PROBLEM in Note [Recursive superclasses] in TcInstDcls. Seems to work great! Quite a bit of knock-on effect * The main implementation work is in tcSuperClasses in TcInstDcls Everything else is fall-out * IdInfo.DFunId no longer needs its n-silent argument * Ditto IDFunId in IfaceSyn * Hence interface file format changes * Now that DFunIds do not have silent superclass parameters, printing out instance declarations is simpler. There is tiny knock-on effect in Haddock, so that submodule is updated * I realised that when computing the "size of a dictionary type" in TcValidity.sizePred, we should be rather conservative about type functions, which can arbitrarily increase the size of a type. Hence the new datatype TypeSize, which has a TSBig constructor for "arbitrarily big". * instDFunType moves from TcSMonad to Inst * Interestingly, CmmNode and CmmExpr both now need a non-silent (Ord r) in a couple of instance declarations. These were previously silent but must now be explicit. * Quite a bit of wibbling in error messages }}} The test output is now: {{{ T7862.hs:23:10: Warning: No explicit implementation for ?+?, ?*?, ?abs?, ?signum?, ?fromInteger?, and (either ?negate? or ?-?) In the instance declaration for ?Num (Tower s a)? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 20:43:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 20:43:18 -0000 Subject: [GHC] #7985: Allow openFile on unknown file type In-Reply-To: <049.5d3eb1afc9286373e53a0f1299c75b88@haskell.org> References: <049.5d3eb1afc9286373e53a0f1299c75b88@haskell.org> Message-ID: <064.364e368c56e793cc10657977bc74b9e9@haskell.org> #7985: Allow openFile on unknown file type -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: ekmett (added) * status: infoneeded => closed * resolution: => invalid Comment: No response from submitter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 20:43:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 20:43:58 -0000 Subject: [GHC] #7862: Could not deduce (A) from the context (A, ...) In-Reply-To: <045.77e996083183797ec6c495029488c3f8@haskell.org> References: <045.77e996083183797ec6c495029488c3f8@haskell.org> Message-ID: <060.66fcaa619951ce5e253e77ee222b5b1a@haskell.org> #7862: Could not deduce (A) from the context (A, ...) -------------------------------------+------------------------------------- Reporter: alang9 | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T7862 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * milestone: 8.0.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 20:55:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 20:55:53 -0000 Subject: [GHC] #5476: Cap memory usage for one thread without disrupting other threads In-Reply-To: <048.f4782c6615e970e4c0ac7ccff4280564@haskell.org> References: <048.f4782c6615e970e4c0ac7ccff4280564@haskell.org> Message-ID: <063.378617106aae06d764da876758d662f0@haskell.org> #5476: Cap memory usage for one thread without disrupting other threads -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: feature request | Status: closed Priority: normal | Milestone: ? Component: Runtime System | Version: 7.2.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #7763 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #7763 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 21:01:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 21:01:59 -0000 Subject: [GHC] #10648: Some 64-vector SIMD primitives are absolutely useless In-Reply-To: <044.c060f468a7f7b3021db9c517bef50f1b@haskell.org> References: <044.c060f468a7f7b3021db9c517bef50f1b@haskell.org> Message-ID: <059.a97211ef8be09a1ed8247884bff24504@haskell.org> #10648: Some 64-vector SIMD primitives are absolutely useless -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: gmainland (added) * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 21:02:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 21:02:41 -0000 Subject: [GHC] #10647: Notice about lack of SIMD support. In-Reply-To: <044.41ea1589882067bc6ce5e3c65bf3dab1@haskell.org> References: <044.41ea1589882067bc6ce5e3c65bf3dab1@haskell.org> Message-ID: <059.759dc0147741d1136f344825e2a4e344@haskell.org> #10647: Notice about lack of SIMD support. -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: gmainland (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 21:04:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 21:04:04 -0000 Subject: [GHC] #7741: Add SIMD support to x86/x86_64 NCG In-Reply-To: <047.ec0118457b1e4a3b6ea3c008b0b9e4f2@haskell.org> References: <047.ec0118457b1e4a3b6ea3c008b0b9e4f2@haskell.org> Message-ID: <062.a2167a0591ea7027cfedd1d08a2d089d@haskell.org> #7741: Add SIMD support to x86/x86_64 NCG -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #3557 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: gmainland (added) * failure: None/Unknown => Runtime performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 21:21:37 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 21:21:37 -0000 Subject: [GHC] #7625: Semicolon is not handled between imports at the ghci command prompt In-Reply-To: <050.3f3c09b0fe695c3fef7cb862e1a16be1@haskell.org> References: <050.3f3c09b0fe695c3fef7cb862e1a16be1@haskell.org> Message-ID: <065.8255b69eb7ffc3b56e8f24026301c624@haskell.org> #7625: Semicolon is not handled between imports at the ghci command prompt -------------------------------------+------------------------------------- Reporter: JohnWiegley | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.4.2 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #11392 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #11392 Comment: This is now tracked in #11392. The error message in 8.0 is a little bit nicer at least, after #10663: {{{ Prelude> import Data.List ; import Data.Map error: expecting a single import declaration }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 21:23:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 21:23:58 -0000 Subject: [GHC] #11392: Decide and document how semicolons are supposed to work in GHCi In-Reply-To: <046.d75fcf3d7505bd227ba71ab98306e831@haskell.org> References: <046.d75fcf3d7505bd227ba71ab98306e831@haskell.org> Message-ID: <061.54783ea4094c88352cc3625509e12941@haskell.org> #11392: Decide and document how semicolons are supposed to work in GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: GHCi | 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: #10663, #7625 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: #10663 => #10663, #7625 Comment: See also #7625, which has a preliminary patch for multiple import statements separated by semicolons. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 21:24:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 21:24:48 -0000 Subject: [GHC] #11392: Decide and document how semicolons are supposed to work in GHCi In-Reply-To: <046.d75fcf3d7505bd227ba71ab98306e831@haskell.org> References: <046.d75fcf3d7505bd227ba71ab98306e831@haskell.org> Message-ID: <061.38235f4e8108ec747d4b60134f124f87@haskell.org> #11392: Decide and document how semicolons are supposed to work in GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10663, #7625 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 21:50:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 21:50:58 -0000 Subject: [GHC] #9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables In-Reply-To: <047.4ca6fb75e0604e66c9de7145ac89f916@haskell.org> References: <047.4ca6fb75e0604e66c9de7145ac89f916@haskell.org> Message-ID: <062.323ec29f40f60e1c9dfe3725e78e3ca6@haskell.org> #9244: Compiler could warn about type variable shadowing, and hint about ScopedTypeVariables -------------------------------------+------------------------------------- Reporter: stusmith | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #1316, #3691, | Differential Rev(s): #11438, #10581, #11539 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by kanetw): * cc: kanetw (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 22:13:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 22:13:42 -0000 Subject: [GHC] #11532: ghc: panic! occured In-Reply-To: <045.2d3308752fa81c80b55c3625ddb38f5a@haskell.org> References: <045.2d3308752fa81c80b55c3625ddb38f5a@haskell.org> Message-ID: <060.8b7afb2ffa91203636f142ab8cfceb7f@haskell.org> #11532: ghc: panic! occured -------------------------------------+------------------------------------- Reporter: cutsea | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by cutsea): I'll leave it to someone having skills. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 22:16:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 22:16:12 -0000 Subject: [GHC] #7482: GHC.Event overwrites main IO managers hooks to RTS In-Reply-To: <053.8265638cb53ac37cc1aae74a0afb4d97@haskell.org> References: <053.8265638cb53ac37cc1aae74a0afb4d97@haskell.org> Message-ID: <068.385b46fd5659de609f630cca767cab0f@haskell.org> #7482: GHC.Event overwrites main IO managers hooks to RTS -------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.4.1 Resolution: fixed | Keywords: IO Manager, | RTS Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: Re-reading comment:6, I think it's safe to close this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 23:25:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 23:25:32 -0000 Subject: [GHC] #11246: Regression typechecking type synonym which includes `Any`. In-Reply-To: <049.3c8cb14b3612458c05777138a511d1ef@haskell.org> References: <049.3c8cb14b3612458c05777138a511d1ef@haskell.org> Message-ID: <064.96a76d3274f48620246096069c98a755@haskell.org> #11246: Regression typechecking type synonym which includes `Any`. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 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 asr): * version: 7.11 => 8.0.1-rc2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 23:41:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 23:41:56 -0000 Subject: [GHC] #10965: GHC Panic on import with 'OPTIONS_GHC -fobject-code -O' In-Reply-To: <044.d2359d5edaaed9fe3a9870eb9b625099@haskell.org> References: <044.d2359d5edaaed9fe3a9870eb9b625099@haskell.org> Message-ID: <059.56e9ff4c0828468b7e374ee98150b40f@haskell.org> #10965: GHC Panic on import with 'OPTIONS_GHC -fobject-code -O' ---------------------------------+-------------------------------------- Reporter: Orome | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10549 | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by slyfox): * status: closed => new * version: 7.10.2 => 8.0.1-rc2 * resolution: duplicate => Comment: Seems to be distinct from #10549. Still happens in today's -HEAD: {{{ $ inplace/bin/ghc-stage2 --interactive /tmp/z/G.hs GHCi, version 8.1.20160207: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/slyfox/.ghci [1 of 1] Compiling Main ( /tmp/z/G.hs, interpreted ) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160207 for x86_64-unknown-linux): floatExpr tick break<0>() 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 Feb 7 23:42:36 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 23:42:36 -0000 Subject: [GHC] #10965: GHC Panic on import with 'OPTIONS_GHC -fobject-code -O' In-Reply-To: <044.d2359d5edaaed9fe3a9870eb9b625099@haskell.org> References: <044.d2359d5edaaed9fe3a9870eb9b625099@haskell.org> Message-ID: <059.a32cdc72eee6777c763d3f4e8ee60ac7@haskell.org> #10965: GHC Panic on import with 'OPTIONS_GHC -fobject-code -O' ---------------------------------+-------------------------------------- Reporter: Orome | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10549 | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Changes (by slyfox): * cc: slyfox, scpmw (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 7 23:46:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 07 Feb 2016 23:46:53 -0000 Subject: [GHC] #11555: catch under unsafePerformIO breaks on -O1 Message-ID: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> #11555: catch under unsafePerformIO breaks on -O1 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Discovered on xmonad-0.12 test failure. Happens on today's -HEAD and ghc-8.0.1-rc1,-rc2 Short example is (needs only base): {{{#!hs -- cat F.hs module F where import qualified Control.Exception as C import System.IO.Unsafe import qualified Data.List as L abort :: String -> a abort x = error $ "xmonad: StackSet: " ++ x prop_abort x = unsafePerformIO $ C.catch (abort "fail") (\(C.SomeException e) -> return $ "xmonad: StackSet: fail" `L.isPrefixOf` show e ) where _ = x :: Int }}} Session 1 [ok]: {{{ $ ghci F.hs GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling F ( F.hs, interpreted ) Ok, modules loaded: F. *F> prop_abort 1 True }}} Session 2 [fails]: {{{ $ ghci -O1 -fobject-code F.hs GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling F ( F.hs, F.o ) Ok, modules loaded: F. Prelude F> prop_abort 1 *** Exception: xmonad: StackSet: fail CallStack (from HasCallStack): error, called at F.hs:9:11 in main:F }}} I would expect exception to be caught on both cases. Is it unreasonable expectation in light of unsafePerformIO? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 02:39:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 02:39:47 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.6f4185b84fc42477f6c15a5cee2fc0bf@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: SafeHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8226, #8745 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dterei: @@ -0,0 +1,3 @@ + See a detailed write up here [wiki:SafeRoles/RolesOverview Safe Haskell, + GND and Roles] + New description: See a detailed write up here [wiki:SafeRoles/RolesOverview Safe Haskell, GND and Roles] Consider the following modules: {{{ module A (List, ints) where data List a = Nil | Cons a (List a) infixr 4 `Cons` ints :: List Int ints = 1 `Cons` 2 `Cons` 3 `Cons` Nil }}} {{{ {-# LANGUAGE GeneralizedNewtypeDeriving #-} module B where import A newtype Age = MkAge Int deriving C class C a where cList :: List a instance C Int where cList = ints }}} {{{ {-# LANGUAGE Safe #-} module C (ages) where import A import B ages :: List Age ages = cList }}} Module C compiles without a hiccup. But, it shouldn't: the coercion between `ages` and `ints` (performed by !GeneralizedNewtypeDeriving in module B) isn't Safe, as it breaks through `List`'s abstraction. (Note that the constructors of `List` are ''not'' exported from module A!) If module B includes `{-# LANGUAGE Safe #-}`, it duly doesn't compile, because of the stringent "constructors-must-be-in-scope" check done by the `Coercible` mechanism. The problem is that safety can be ''inferred'' without this check taking place. You may also want to read the commentary on #8745 for related discussion. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 02:44:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 02:44:41 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.d31772e13e56d7a634213d869106a8c3@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: SafeHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8226, #8745 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dterei): I wrote up a detailed summary of all of this 6 months back here: [wiki:SafeRoles/RolesOverview Roles Overview]. I believe the recursive check can be done, and in such a way were we track that it's possible to import the right modules to satisfy the requirement that all constructors are in-scope, rather than actually require these imports (which is the main complaint against this check). The complications to this recursive check are internal vs. external modules and Safe Haskell import restrictions. They seem resolvable though, just annoying engineering most likely. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 02:48:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 02:48:58 -0000 Subject: [GHC] #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong In-Reply-To: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> References: <047.8813fe37039a68aef13a3424b2e5592a@haskell.org> Message-ID: <062.d7db66c45cdb3e20e1d477ace31a7120@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: SafeHaskell Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8226, #8745 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by dterei: @@ -1,2 +1,1 @@ - See a detailed write up here [wiki:SafeRoles/RolesOverview Safe Haskell, - GND and Roles] + See a detailed write up here [wiki:SafeRoles Safe Haskell, GND and Roles] New description: See a detailed write up here [wiki:SafeRoles Safe Haskell, GND and Roles] Consider the following modules: {{{ module A (List, ints) where data List a = Nil | Cons a (List a) infixr 4 `Cons` ints :: List Int ints = 1 `Cons` 2 `Cons` 3 `Cons` Nil }}} {{{ {-# LANGUAGE GeneralizedNewtypeDeriving #-} module B where import A newtype Age = MkAge Int deriving C class C a where cList :: List a instance C Int where cList = ints }}} {{{ {-# LANGUAGE Safe #-} module C (ages) where import A import B ages :: List Age ages = cList }}} Module C compiles without a hiccup. But, it shouldn't: the coercion between `ages` and `ints` (performed by !GeneralizedNewtypeDeriving in module B) isn't Safe, as it breaks through `List`'s abstraction. (Note that the constructors of `List` are ''not'' exported from module A!) If module B includes `{-# LANGUAGE Safe #-}`, it duly doesn't compile, because of the stringent "constructors-must-be-in-scope" check done by the `Coercible` mechanism. The problem is that safety can be ''inferred'' without this check taking place. You may also want to read the commentary on #8745 for related discussion. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 03:07:24 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 03:07:24 -0000 Subject: [GHC] #4029: ghci leaks memory when loading a file In-Reply-To: <046.7e3cd0db8a339c9dc956ab26c7e5c0ec@haskell.org> References: <046.7e3cd0db8a339c9dc956ab26c7e5c0ec@haskell.org> Message-ID: <061.01110b614a472f4736686ec55169547d@haskell.org> #4029: ghci leaks memory when loading a file -------------------------------------+------------------------------------- Reporter: blarsen | Owner: jme Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: Resolution: | Keywords: memory leak 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 jme): * owner: => jme -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 03:19:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 03:19:49 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.2d88da9de00397ea465a6d64aa2ed1c6@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I actually quite like this idea. I do think it's too late for 8.0. And the long-term plan is to make `Type` (that is, `*`) and `TypeRep` to be the same thing. So `* :: *` really will make sense! But perhaps if this idea came along earlier, we would have adopted it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 03:34:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 03:34:44 -0000 Subject: [GHC] #11556: GHC recompiles unchanged hs-boot files Message-ID: <045.fe8cb73688703861b98c9c8756078f48@haskell.org> #11556: GHC recompiles unchanged hs-boot files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11013, #10333 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A.hs: {{{#!hs module A where import B f = someError }}} A.hs-boot: {{{#!hs module A where }}} B.hs: {{{#!hs module B where import {-# SOURCE #-} A }}} {{{ $ ghc-7.10.3 --make A.hs [1 of 3] Compiling A[boot] ( A.hs-boot, A.o-boot ) [2 of 3] Compiling B ( B.hs, B.o ) [3 of 3] Compiling A ( A.hs, A.o ) A.hs:5:5: Not in scope: ?someError? $ ghc-7.10.3 --make A.hs [1 of 3] Compiling A[boot] ( A.hs-boot, A.o-boot ) [3 of 3] Compiling A ( A.hs, A.o ) A.hs:5:5: Not in scope: ?someError? }}} Why does `ghc --make` recompile `B.hs-boot`? Note that recompilation avoidance does work when using `ghc -c`: {{{ $ ghc -c A.hs-boot compilation IS NOT required }}} (found while trying to reduce the testcase for #11532, which contains 644 .hs and 642 .hs-boot files) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 03:44:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 03:44:06 -0000 Subject: [GHC] #11556: GHC recompiles unchanged hs-boot files In-Reply-To: <045.fe8cb73688703861b98c9c8756078f48@haskell.org> References: <045.fe8cb73688703861b98c9c8756078f48@haskell.org> Message-ID: <060.d4149f29fd23b2f62a53ed59db5b5cf5@haskell.org> #11556: GHC recompiles unchanged hs-boot files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | driver/recomp002/recomp002 Blocked By: | Blocking: Related Tickets: #11013, #10333 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => driver/recomp002/recomp002 Comment: Please tell me this is indeed a bug. For a testsuite testcase, append the following two lines to `testsuite/tests/driver/recomp002/Makefile`. {{{ touch W.hs '$(TEST_HC)' $(TEST_HC_OPTS_NO_RECOMP) --make Q.hs }}} Only `W.hs` should get recompiled, not `W.hs-boot`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 04:23:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 04:23:26 -0000 Subject: [GHC] #11556: GHC recompiles unchanged hs-boot files In-Reply-To: <045.fe8cb73688703861b98c9c8756078f48@haskell.org> References: <045.fe8cb73688703861b98c9c8756078f48@haskell.org> Message-ID: <060.df6dfd3c57e8707abe1c769e7a4e0240@haskell.org> #11556: GHC recompiles unchanged hs-boot files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Driver | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | driver/recomp002/recomp002 Blocked By: | Blocking: Related Tickets: #11013, #10333 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): The underlying cause of this issue is, I believe, the same as #10333 (https://ghc.haskell.org/trac/ghc/ticket/10333#comment:2). Since `A.hi` is not successfully compiled, we will always consider `A.hi-boot` as unstable (and we'll report that it is modified). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 04:26:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 04:26:47 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.4f9775b59c2d4eb821a8d2816358ed23@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ekmett): * version: 7.10.3 => 8.0.1-rc1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 08:40:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 08:40:34 -0000 Subject: [GHC] #11557: Unbundle Cabal from GHC Message-ID: <045.7d711249cd9c8cedc606277ad69f7e88@haskell.org> #11557: Unbundle Cabal from GHC -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: libraries | Version: 8.1 (other) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Recently, Duncan made it so that GHC proper does not depend on Cabal (so it is just ghc-pkg that is the user-facing executable which links against Cabal). We should now seriously consider unbundling Cabal from GHC, so that the default global database we provide does NOT include Cabal. Pros: * Distributions will be more likely to take point version releases to Cabal, as they no longer have to finesse updating Cabal without updating GHC as they have now * Stack is (improperly) coupling the version of Cabal they build with the release of GHC; while they should fix this, unbundling Cabal would also give them more flexibility with picking LTS packages. Cons: * Bootstrapping Cabal/cabal-install becomes modestly harder. Fortunately, cabal-install is already pretty obnoxious to bootstrap, so SOP is to just distribute binaries for this, in which case things are as easy as before. * We wouldn't be strictly adhering to the Cabal spec, which requires that the compiler always be able to build the Setup executable. * ghc-pkg would have to be statically linked -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 09:05:55 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 09:05:55 -0000 Subject: [GHC] #11519: Inferring non-tau kinds In-Reply-To: <047.4d7c879b01fe33a75f5e9304ccb4f8c9@haskell.org> References: <047.4d7c879b01fe33a75f5e9304ccb4f8c9@haskell.org> Message-ID: <062.4ff36544536e27e2151e012f00864805@haskell.org> #11519: Inferring non-tau kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"2cf3cac6a05879c27fa82b12dd34cce39a262402/ghc" 2cf3cac6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2cf3cac6a05879c27fa82b12dd34cce39a262402" Allow foralls in instance decls This patch finally makes it possible to have explicit foralls in an instance decl instance forall (a :: *). Eq a => Eq [a] where ... This is useful to allow kind signatures or indeed explicicit kind for-alls; see Trac #11519 I thought it would be really easy, because an instance declaration already contains an actual HsSigType, so all the syntactic baggage is there. But in fact it turned out that instance declarations were kind-checked a little differently, because the body kind of the forall is 'Constraint' rather than '*'. So I fixed that. There a slight kludge (see Note [Body kind of a HsQualTy], but it's still a significant improvement. I also did the usual other round of refactoring, improved a few error messages, tidied up comments etc. The only significant aspect of all that was * Kill mkNakedSpecSigmaTy, mkNakedPhiTy, mkNakedFunTy These function names suggest that they do something complicated, but acutally they do nothing. So I killed them. * Swap the arg order of mkNamedBinder, just so that it is convenient to say 'map (mkNamedBinder Invisible) tvs' * I had to improve isPredTy, to deal with (illegal) types like (Eq a => Eq [a]) => blah See Note [isPeredTy complications] in Type.hs Still to come: user manual documentation for the instance-decl change. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 10:06:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 10:06:50 -0000 Subject: [GHC] #11548: Absolutely misleading error message on kind error In-Reply-To: <044.e6082235a325c0e8984f6f1f86653383@haskell.org> References: <044.e6082235a325c0e8984f6f1f86653383@haskell.org> Message-ID: <059.7303ece219611a6cff3c3f022d78dc1a@haskell.org> #11548: Absolutely misleading error message on kind error -------------------------------------+------------------------------------- Reporter: mniip | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 10:49:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 10:49:51 -0000 Subject: [GHC] #11558: Using Cabal 1.22 against GHC 8.0 results in terrible errors Message-ID: <046.d2616ea949ac4d1153655c6314ef5133@haskell.org> #11558: Using Cabal 1.22 against GHC 8.0 results in terrible errors -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Package | Version: 8.0.1-rc1 system | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- GHC 8.0 will require Cabal >1.22 due to a variety of interface changes (see #10714, Phab:D1780, https://mail.haskell.org/pipermail/ghc- devs/2016-January/010978.html). Unfortunately things currently blow up late in compilation with a seemingly unrelated error when this requirement isn't met. Namely, we complain about missing interface files for dependencies. For instance, {{{ Text/Parsec/Prim.hs:85:1: error: Bad interface file: /root/.cabal/lib/x86_64-linux- ghc-8.0.0.20160204/mtl-2.2.1-9wMhzcfsAXi7cNtl9n7svO/Control/Monad/Cont/Class.hi Something is amiss; requested module mtl-2.2.1 at mtl-2.2.1-1af5dabd2d7abb688f2145aec87badc4:Control.Monad.Cont.Class differs from name found in the interface file mtl_9wMhzcfsAXi7cNtl9n7svO:Control.Monad.Cont.Class }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 10:51:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 10:51:30 -0000 Subject: [GHC] #11558: Using Cabal 1.22 against GHC 8.0 results in terrible errors In-Reply-To: <046.d2616ea949ac4d1153655c6314ef5133@haskell.org> References: <046.d2616ea949ac4d1153655c6314ef5133@haskell.org> Message-ID: <061.8b6d25022cf460c19668af0e51adee75@haskell.org> #11558: Using Cabal 1.22 against GHC 8.0 results in terrible errors -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Package system | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -17,0 +17,6 @@ + + = For users afflicted by this = + + The solution here is to install `Cabal` 1.23 or later and a `cabal- + install` linking against it. Currently this requires installing `Cabal` + and `cabal-install` from git. This is most easily done using GHC 7.10. New description: GHC 8.0 will require Cabal >1.22 due to a variety of interface changes (see #10714, Phab:D1780, https://mail.haskell.org/pipermail/ghc- devs/2016-January/010978.html). Unfortunately things currently blow up late in compilation with a seemingly unrelated error when this requirement isn't met. Namely, we complain about missing interface files for dependencies. For instance, {{{ Text/Parsec/Prim.hs:85:1: error: Bad interface file: /root/.cabal/lib/x86_64-linux- ghc-8.0.0.20160204/mtl-2.2.1-9wMhzcfsAXi7cNtl9n7svO/Control/Monad/Cont/Class.hi Something is amiss; requested module mtl-2.2.1 at mtl-2.2.1-1af5dabd2d7abb688f2145aec87badc4:Control.Monad.Cont.Class differs from name found in the interface file mtl_9wMhzcfsAXi7cNtl9n7svO:Control.Monad.Cont.Class }}} = For users afflicted by this = The solution here is to install `Cabal` 1.23 or later and a `cabal- install` linking against it. Currently this requires installing `Cabal` and `cabal-install` from git. This is most easily done using GHC 7.10. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 10:52:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 10:52:18 -0000 Subject: [GHC] #11558: Using Cabal 1.22 against GHC 8.0 results in terrible errors In-Reply-To: <046.d2616ea949ac4d1153655c6314ef5133@haskell.org> References: <046.d2616ea949ac4d1153655c6314ef5133@haskell.org> Message-ID: <061.74cee8a41cbed351561644556ee9b123@haskell.org> #11558: Using Cabal 1.22 against GHC 8.0 results in terrible errors -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Package system | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -18,1 +18,1 @@ - = For users afflicted by this = + = For users seeing this error = New description: GHC 8.0 will require Cabal >1.22 due to a variety of interface changes (see #10714, Phab:D1780, https://mail.haskell.org/pipermail/ghc- devs/2016-January/010978.html). Unfortunately things currently blow up late in compilation with a seemingly unrelated error when this requirement isn't met. Namely, we complain about missing interface files for dependencies. For instance, {{{ Text/Parsec/Prim.hs:85:1: error: Bad interface file: /root/.cabal/lib/x86_64-linux- ghc-8.0.0.20160204/mtl-2.2.1-9wMhzcfsAXi7cNtl9n7svO/Control/Monad/Cont/Class.hi Something is amiss; requested module mtl-2.2.1 at mtl-2.2.1-1af5dabd2d7abb688f2145aec87badc4:Control.Monad.Cont.Class differs from name found in the interface file mtl_9wMhzcfsAXi7cNtl9n7svO:Control.Monad.Cont.Class }}} = For users seeing this error = The solution here is to install `Cabal` 1.23 or later and a `cabal- install` linking against it. Currently this requires installing `Cabal` and `cabal-install` from git. This is most easily done using GHC 7.10. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 10:53:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 10:53:01 -0000 Subject: [GHC] #11558: Using Cabal 1.22 against GHC 8.0 results in unhelpful errors (was: Using Cabal 1.22 against GHC 8.0 results in terrible errors) In-Reply-To: <046.d2616ea949ac4d1153655c6314ef5133@haskell.org> References: <046.d2616ea949ac4d1153655c6314ef5133@haskell.org> Message-ID: <061.df31c404b1bdecbc87d5de9cc1bf6b16@haskell.org> #11558: Using Cabal 1.22 against GHC 8.0 results in unhelpful errors -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Package system | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 11:09:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 11:09:39 -0000 Subject: [GHC] #11558: Using Cabal 1.22 against GHC 8.0 results in unhelpful errors In-Reply-To: <046.d2616ea949ac4d1153655c6314ef5133@haskell.org> References: <046.d2616ea949ac4d1153655c6314ef5133@haskell.org> Message-ID: <061.87f365390af992b23ef7854f2a65b73b@haskell.org> #11558: Using Cabal 1.22 against GHC 8.0 results in unhelpful errors -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Package system | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -23,0 +23,10 @@ + Finally, you need to clear your package database. + + This can be done with, + {{{ + $ git clone git://github.com/haskell/cabal + $ cd cabal + $ cabal update + $ cabal install Cabal/ cabal-install/ + $ rm -R $HOME/.ghc/*-8.0.0* + }}} New description: GHC 8.0 will require Cabal >1.22 due to a variety of interface changes (see #10714, Phab:D1780, https://mail.haskell.org/pipermail/ghc- devs/2016-January/010978.html). Unfortunately things currently blow up late in compilation with a seemingly unrelated error when this requirement isn't met. Namely, we complain about missing interface files for dependencies. For instance, {{{ Text/Parsec/Prim.hs:85:1: error: Bad interface file: /root/.cabal/lib/x86_64-linux- ghc-8.0.0.20160204/mtl-2.2.1-9wMhzcfsAXi7cNtl9n7svO/Control/Monad/Cont/Class.hi Something is amiss; requested module mtl-2.2.1 at mtl-2.2.1-1af5dabd2d7abb688f2145aec87badc4:Control.Monad.Cont.Class differs from name found in the interface file mtl_9wMhzcfsAXi7cNtl9n7svO:Control.Monad.Cont.Class }}} = For users seeing this error = The solution here is to install `Cabal` 1.23 or later and a `cabal- install` linking against it. Currently this requires installing `Cabal` and `cabal-install` from git. This is most easily done using GHC 7.10. Finally, you need to clear your package database. This can be done with, {{{ $ git clone git://github.com/haskell/cabal $ cd cabal $ cabal update $ cabal install Cabal/ cabal-install/ $ rm -R $HOME/.ghc/*-8.0.0* }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 11:11:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 11:11:43 -0000 Subject: [GHC] #11558: Using Cabal 1.22 against GHC 8.0 results in unhelpful errors In-Reply-To: <046.d2616ea949ac4d1153655c6314ef5133@haskell.org> References: <046.d2616ea949ac4d1153655c6314ef5133@haskell.org> Message-ID: <061.0e523f955c3420104c8c365bdfa477d4@haskell.org> #11558: Using Cabal 1.22 against GHC 8.0 results in unhelpful errors -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Package system | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1892 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => Phab:D1892 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 11:15:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 11:15:53 -0000 Subject: [GHC] #11558: Using Cabal 1.22 against GHC 8.0 results in unhelpful errors In-Reply-To: <046.d2616ea949ac4d1153655c6314ef5133@haskell.org> References: <046.d2616ea949ac4d1153655c6314ef5133@haskell.org> Message-ID: <061.acef632782c469806e7046f19445b614@haskell.org> #11558: Using Cabal 1.22 against GHC 8.0 results in unhelpful errors -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Package system | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1892 Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -5,2 +5,2 @@ - isn't met. Namely, we complain about missing interface files for - dependencies. For instance, + isn't met. Namely, we complain about bad interface files for dependencies. + For instance, New description: GHC 8.0 will require Cabal >1.22 due to a variety of interface changes (see #10714, Phab:D1780, https://mail.haskell.org/pipermail/ghc- devs/2016-January/010978.html). Unfortunately things currently blow up late in compilation with a seemingly unrelated error when this requirement isn't met. Namely, we complain about bad interface files for dependencies. For instance, {{{ Text/Parsec/Prim.hs:85:1: error: Bad interface file: /root/.cabal/lib/x86_64-linux- ghc-8.0.0.20160204/mtl-2.2.1-9wMhzcfsAXi7cNtl9n7svO/Control/Monad/Cont/Class.hi Something is amiss; requested module mtl-2.2.1 at mtl-2.2.1-1af5dabd2d7abb688f2145aec87badc4:Control.Monad.Cont.Class differs from name found in the interface file mtl_9wMhzcfsAXi7cNtl9n7svO:Control.Monad.Cont.Class }}} = For users seeing this error = The solution here is to install `Cabal` 1.23 or later and a `cabal- install` linking against it. Currently this requires installing `Cabal` and `cabal-install` from git. This is most easily done using GHC 7.10. Finally, you need to clear your package database. This can be done with, {{{ $ git clone git://github.com/haskell/cabal $ cd cabal $ cabal update $ cabal install Cabal/ cabal-install/ $ rm -R $HOME/.ghc/*-8.0.0* }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 11:53:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 11:53:46 -0000 Subject: [GHC] #11557: Unbundle Cabal from GHC In-Reply-To: <045.7d711249cd9c8cedc606277ad69f7e88@haskell.org> References: <045.7d711249cd9c8cedc606277ad69f7e88@haskell.org> Message-ID: <060.10e70bf1070b584f5fa130ca8becdaf7@haskell.org> #11557: Unbundle Cabal from GHC -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: libraries | Version: 8.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): For reference, a previous discussion which also suggested not installing `Cabal` into the package db: - https://mail.haskell.org/pipermail/ghc-devs/2014-December/007825.html as well as the original CABAL specifcation from 2004 or so: - https://www.haskell.org/cabal/proposal/pkg-spec.pdf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 11:59:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 11:59:22 -0000 Subject: [GHC] #11557: Unbundle Cabal from GHC In-Reply-To: <045.7d711249cd9c8cedc606277ad69f7e88@haskell.org> References: <045.7d711249cd9c8cedc606277ad69f7e88@haskell.org> Message-ID: <060.fd519467dbb8eeb0200dacace2555d7c@haskell.org> #11557: Unbundle Cabal from GHC -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: libraries | Version: 8.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): As the Debian maintainer: Yay! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 12:47:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 12:47:50 -0000 Subject: [GHC] #11558: Using Cabal 1.22 against GHC 8.0 results in unhelpful errors In-Reply-To: <046.d2616ea949ac4d1153655c6314ef5133@haskell.org> References: <046.d2616ea949ac4d1153655c6314ef5133@haskell.org> Message-ID: <061.bda57c7826d8d60a75fecc03074c88bc@haskell.org> #11558: Using Cabal 1.22 against GHC 8.0 results in unhelpful errors -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Package system | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1892 Wiki Page: | -------------------------------------+------------------------------------- Changes (by asr): * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 12:58:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 12:58:57 -0000 Subject: [GHC] #11246: Regression typechecking type synonym which includes `Any`. In-Reply-To: <049.3c8cb14b3612458c05777138a511d1ef@haskell.org> References: <049.3c8cb14b3612458c05777138a511d1ef@haskell.org> Message-ID: <064.7f7580af054a098fefd8e9eaddd16db0@haskell.org> #11246: Regression typechecking type synonym which includes `Any`. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 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 asr): * priority: high => highest Comment: This issue will block hashtables for supporting GHC 8.0.1 (and hashtables will block Agda). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 13:00:03 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 13:00:03 -0000 Subject: [GHC] #11555: catch under unsafePerformIO breaks on -O1 In-Reply-To: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> References: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> Message-ID: <060.8e66233d76886275cf50381c9b66e174@haskell.org> #11555: catch under unsafePerformIO breaks on -O1 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by NeilMitchell): * cc: ndmitchell (added) Comment: I ran into this today in the Shake test suite. My reduced case doesn't rely on {{{unsafePerformIO}}}. {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} module Main(main) where import Control.Exception main :: IO () main = (undefined :: IO ()) `catch` \(e :: SomeException) -> putStrLn "Success" }}} At {{{-O0}}} this program is equivalent to {{{putStrLn "Success"}}}. At {{{-O1}}} and above this program is equivalent to {{{undefined}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 13:07:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 13:07:22 -0000 Subject: [GHC] #11559: Building a cross-compiler for MIPS target on Mac OS X host fails Message-ID: <050.6c95ef109504726bb3b81a6b68c92e68@haskell.org> #11559: Building a cross-compiler for MIPS target on Mac OS X host fails -------------------------------------+------------------------------------- Reporter: wereHamster | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I was able to build a cross-compiling GHC on a Ubuntu 16.04 host with just a few changes to the source code (see this article I wrote about it, the necessary source code changes are in the GHC/Haskell section: https://medium.com/@wereHamster/cross-compiling-for-the-onion-omega- 1cf8ee80df02) Replicating the necessary steps on my Mac OS X laptop didn't work. The build system doesn't clearly distinguish between CPP/C/LD flags required by the host and target compilers (which in my case are quite different, clang for the host and gcc for the target). The C/LD flags determined by `--with-curses-includes/libraries` are passed to both the host and target compiler. The host has ncurses installed in a standard search path (/usr), I used this option to let the build system know where a version of ncurses for the target is installed (required for the stage2 compiler I believe). The problem here is that the host compiler fails to build stage1 libraries/terminfo because it first finds the cross- compiled ncurses library in its search path and stops because it is incompatible. Maybe it's a peculiarity of clang that it doesn't keep on searching when it comes across the first library it can find, even though later in the search path there is one which is compatible. I was able to get past that by changing some makefile rules and pass the necessary options only when building the stage2 terminfo. Similar issue is when wrong CPP options are passed to the pre-processor during building of stage2. The configure script adds `-m64` to CPP options (because the build host is x86_64 darwin). However, these options are then passed to the target compiler which doesn't understand `-m64`. I tried to track down where exactly that happens but I was not able to find where (`rules/build-dependencies.mk` -> `addCFileDeps` is who calls `$(CPP)` with the wrong flags). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 14:24:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 14:24:30 -0000 Subject: [GHC] #11555: catch under unsafePerformIO breaks on -O1 In-Reply-To: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> References: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> Message-ID: <060.402296891bd2531d65ff863b6bbfc63d@haskell.org> #11555: catch under unsafePerformIO breaks on -O1 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 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): * priority: normal => highest * failure: None/Unknown => Incorrect result at runtime * milestone: => 8.0.1 Comment: It sounds like this may be fallout from #11222. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 14:45:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 14:45:38 -0000 Subject: [GHC] #11555: catch _|_ breaks at -O1 (was: catch under unsafePerformIO breaks on -O1) In-Reply-To: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> References: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> Message-ID: <060.0733b438f71b3d0fee15e17230445e17@haskell.org> #11555: catch _|_ breaks at -O1 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 14:46:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 14:46:16 -0000 Subject: [GHC] #11555: catch under unsafePerformIO breaks on -O1 (was: catch _|_ breaks at -O1) In-Reply-To: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> References: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> Message-ID: <060.654a411b284b27be7fbf17a6e90176c0@haskell.org> #11555: catch under unsafePerformIO breaks on -O1 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 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 rwbarton): It is fallout from #11222, but it's not a bug. There's no guarantee that the ''pure value'' passed to `catch` will be evaluated at any particular time. `catch` catches exceptions that arise from the ''execution'' of its IO argument action. Correct versions of this program would include changing `abort` to `abort :: Stack -> IO a; abort x = throwIO $ ...` or changing `C.catch (abort "fail")` to `C.catch (evaluate (abort "fail"))`. But I'm not sure that there is any way currently to, given an (unevaluated) IO action, evaulate it and execute it, catching exceptions raised by either step. A possible attempt would be `catch (do { a <- evaluate action; a })`, but would GHC see through this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 14:46:45 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 14:46:45 -0000 Subject: [GHC] #11555: catch under unsafePerformIO breaks on -O1 to catch _|_ breaks at -O1 (was: catch under unsafePerformIO breaks on -O1) In-Reply-To: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> References: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> Message-ID: <060.ec983dd68e308cc553dc774f724578d8@haskell.org> #11555: catch under unsafePerformIO breaks on -O1 to catch _|_ breaks at -O1 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 15:07:25 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 15:07:25 -0000 Subject: [GHC] #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled In-Reply-To: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> References: <046.7a90834ded840a9f72a583b5d9ced71d@haskell.org> Message-ID: <061.2e22b7f882983383ba1c1208d1e3ee84@haskell.org> #11518: Test TcCoercibleFail hangs with substitution sanity checks enabled -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a96c4e7ca391ff3003d5debf187e7d177131f2fe/ghc" a96c4e7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a96c4e7ca391ff3003d5debf187e7d177131f2fe" Add comments to TcCoercibleFail Flag up the problem highlighted in Trac #11518 comment:15 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 15:07:25 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 15:07:25 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.a155ead18eac900d119a3be274733886@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"8871737db588b1cb8f7d33d60c5af80b85b2422d/ghc" 8871737/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8871737db588b1cb8f7d33d60c5af80b85b2422d" Document and improve superclass expansion When investigating Trac #11523 I found that superclass expansion was a little over-aggressive; we were sort of unrolling each loop twice. This patch corrects that, and adds explanatory comments. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 15:07:25 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 15:07:25 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.591b4ca3583e1fcb80604820292a5e15@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"43e02d1270701a1043be67f078cf2b1a85047feb/ghc" 43e02d12/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="43e02d1270701a1043be67f078cf2b1a85047feb" Fix a nasty superclass expansion bug This patch fixes Trac #11523. * The basic problem was that TcRnTypes.superClassesMightHelp was returning True of a Derived constraint, and that led to us expanding Given superclasses, which produced the same Derived constraint again, and so on infinitely. We really want to do this only if there are unsolve /Wanted/ contraints! * On the way I made TcSMonad.getUnsolvedInerts a bit more discriminating about which Derived equalities it returns; see Note [Unsolved Derived equalities] in TcSMonad * Lots of new comments in TcSMonad. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 15:14:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 15:14:18 -0000 Subject: [GHC] #11555: catch under unsafePerformIO breaks on -O1 to catch _|_ breaks at -O1 In-Reply-To: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> References: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> Message-ID: <060.4c8bbb6a5b1af33be2a56ea55626f020@haskell.org> #11555: catch under unsafePerformIO breaks on -O1 to catch _|_ breaks at -O1 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 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 NeilMitchell): The current title is inaccurate - this ticket is all about {{{catch _|_}}}, and has nothing to do with {{{unsafePerformIO}}}. The question is whether {{{catch _|_}}} should evaluate to {{{_|_}}} or {{{Left}}}. I observe that in all previous releases of GHC, and at {{{-O0}}}, it's been {{{Left}}}. In two applications that have excellent test suites and have upgraded to GHC 8.0RC2 this issue has been flagged as a breaking change, so I suspect that it might be relatively widespread. As to what it should do, it seems unfortunate to argue that {{{catch undefined}}} is itself undefined. What's the semantics of {{{catch (return () >> undefined)}}}? If it's not equivalent to {{{catch undefined}}} then it's problematic for the Monad laws. I think it's reasonable in a lazy language that a function only evaluates its arguments when it has to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 15:23:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 15:23:14 -0000 Subject: [GHC] #11549: Add -fshow-runtime-rep In-Reply-To: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> References: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> Message-ID: <062.3273785355cc2a758dc11e778b9b8db2@haskell.org> #11549: Add -fshow-runtime-rep -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.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 simonpj): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 15:30:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 15:30:21 -0000 Subject: [GHC] #11555: catch _|_ breaks at -O1 (was: catch under unsafePerformIO breaks on -O1 to catch _|_ breaks at -O1) In-Reply-To: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> References: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> Message-ID: <060.a23e9937bdef7c76361ad11eb8423bf4@haskell.org> #11555: catch _|_ breaks at -O1 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 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 rwbarton): Aah, sorry, I'm just incompetent at Trac this morning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 15:48:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 15:48:33 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.ad1cda835e0dececd9519e2dcf2c4094@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm afraid I don't understand the idea of comment:9. I'm happy that Richard says he likes it, but what precisely is the suggestion? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 16:04:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 16:04:29 -0000 Subject: [GHC] #11550: ghc-HEAD -DDEBUG is broken (possiby by D1880) In-Reply-To: <045.510eebdecea6778a3cdc8536c2c13abb@haskell.org> References: <045.510eebdecea6778a3cdc8536c2c13abb@haskell.org> Message-ID: <060.0082e4a3a9c08904a8529108f5dcc27c@haskell.org> #11550: ghc-HEAD -DDEBUG is broken (possiby by D1880) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1889 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I responded to the Phab: There's an easier way. Use the old code for `stgArgHasCafRefs` use {{{ stgIdHasCafRefs :: Id -> Bool stgIdHasCafRefs id = isGlobalId id && mayHaveCafRefs (idCafInfo id) }}} After `TidyPgm`, all top-level and imported Ids are `GlobalIds`. Needs a comment of course! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 16:14:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 16:14:09 -0000 Subject: [GHC] #11552: ScopedTypeVariables / InstanceSigs do not work in GHC 8.0 In-Reply-To: <048.ed8df3269063d4724395b509ea472611@haskell.org> References: <048.ed8df3269063d4724395b509ea472611@haskell.org> Message-ID: <063.154cbb04ae3027e343702e58fceb3843@haskell.org> #11552: ScopedTypeVariables / InstanceSigs do not work in GHC 8.0 -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11552 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_compile/T11552 * resolution: => fixed Comment: I'm not sure what you had in mind, Richard, but I fixed this as part of #11519. I'll add another regression test though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 16:14:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 16:14:27 -0000 Subject: [GHC] #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker In-Reply-To: <046.076adf4676a7bff5c198511775a24988@haskell.org> References: <046.076adf4676a7bff5c198511775a24988@haskell.org> Message-ID: <061.e8262706af59f19ce54b03ce862489e9@haskell.org> #11303: Pattern matching against sets of strings sharing a prefix blows up pattern checker -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: T11303, performance bug | T11303b Blocked By: | Blocking: Related Tickets: #11276, #11302 | Differential Rev(s): Phab:D1716, Wiki Page: | Phab:D1719, Phab:1795 -------------------------------------+------------------------------------- Changes (by gkaracha): * status: new => closed * testcase: T11303 => T11303, T11303b * differential: Phab:D1716, Phab:D1719 => Phab:D1716, Phab:D1719, Phab:1795 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 16:15:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 16:15:57 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.b6d4fc730025588d4f42bcae7ed8879b@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, the current plan (implemented in Phab:D1891) looks like this, {{{#!hs data RuntimeRep = PtrRep Levity -- ^ represented by a pointer ? | VecRep VecCount VecElem -- ^ a SIMD vector type ? | VoidRep -- ^ erased entirely ? | IntRep -- ^ signed, word-sized value ? | WordRep -- ^ unsigned, word-sized value ? | Int64Rep -- ^ signed, 64-bit value (on 32-bit only) ? | Word64Rep -- ^ unsigned, 64-bit value (on 32-bit only) ? | AddrRep -- ^ A pointer, but /not/ to a Haskell value ? | FloatRep -- ^ a 32-bit floating point number ? | DoubleRep -- ^ a 64-bit floating point number ? | UnboxedTupleRep -- ^ An unboxed tuple; this doesn't specify a concrete rep data VecCount = Vec2 | Vec4 | Vec8 | Vec16 | Vec32 | Vec64 data VecElem = Int8ElemRep | Int16ElemRep | Int32ElemRep | Int64ElemRep | Word8ElemRep | Word16ElemRep | Word32ElemRep | Word64ElemRep | FloatElemRep | DoubleElemRep data Levity = Lifted | Unlifted data TYPE (rep :: RuntimeRep) :: TYPE 'Lifted }}} Simon says, > I'm afraid I don't understand the idea of comment:9. I'm happy that Richard says he likes it, but what precisely is the suggestion? I think Reid was suggesting that `TYPE 'Lifted :: TYPE 'TypeRep` or something along those lines (where `TypeRep` would look very similar to `VoidRep`). This reflects the fact types (e.g. `Int`) have no runtime representation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 16:16:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 16:16:35 -0000 Subject: [GHC] #11160: New exhaustiveness checker breaks ghcirun004 In-Reply-To: <046.c89324db7a7d18158fff821e17f3a109@haskell.org> References: <046.c89324db7a7d18158fff821e17f3a109@haskell.org> Message-ID: <061.e46ef60130547ac4479f6e96ee573f42@haskell.org> #11160: New exhaustiveness checker breaks ghcirun004 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: | PatternMatchWarnings 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 gkaracha): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 16:17:19 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 16:17:19 -0000 Subject: [GHC] #11161: New exhaustiveness checker breaks concurrent/prog001 In-Reply-To: <046.378e54f436fe43981c9731a70e8aac82@haskell.org> References: <046.378e54f436fe43981c9731a70e8aac82@haskell.org> Message-ID: <061.9c6294f8ace26c2bad2efa60b1b988e6@haskell.org> #11161: New exhaustiveness checker breaks concurrent/prog001 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | concurrent/prog001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gkaracha): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 16:20:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 16:20:02 -0000 Subject: [GHC] #10640: Document prim-ops In-Reply-To: <046.4e817e7df8d2c783e102d23f1eac2c40@haskell.org> References: <046.4e817e7df8d2c783e102d23f1eac2c40@haskell.org> Message-ID: <061.f51f14219bc27704cdeb8270bae383f2@haskell.org> #10640: Document prim-ops -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: task | Status: new Priority: normal | Milestone: 8.2.1 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): Phab:D1082 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * type: bug => task * milestone: 8.0.1 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 16:23:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 16:23:08 -0000 Subject: [GHC] #11138: Kill the terrible LLVM Mangler In-Reply-To: <046.1671c4fce95e0eb48491b5a743b485ce@haskell.org> References: <046.1671c4fce95e0eb48491b5a743b485ce@haskell.org> Message-ID: <061.50e38f76550917e74def9faebb7e33fd@haskell.org> #11138: Kill the terrible LLVM Mangler -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * type: bug => task -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 16:26:03 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 16:26:03 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.50b84024bee02928934ed8b396dd4884@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): = > I'm at the Compose conference in New York talking to Brian Hurt who is refactoring the `monad-control` package to switch ''to'' functional dependencies from a class associated type so that he can support `GeneralizedNewtypeDeriving`. > > This also arises as a common idiom with the `mtl`, because you can use GND to derive `MonadState MyState`. Would you (or he) care to give a small self-contained example of why GND works for fundeps but not for associated types? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 16:36:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 16:36:38 -0000 Subject: [GHC] #11519: Inferring non-tau kinds In-Reply-To: <047.4d7c879b01fe33a75f5e9304ccb4f8c9@haskell.org> References: <047.4d7c879b01fe33a75f5e9304ccb4f8c9@haskell.org> Message-ID: <062.1606fcd750b6d6743faab49c5c50dd12@haskell.org> #11519: Inferring non-tau kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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): This doesn't close the ticket, but the above commit does now allow explicit quantification in instance decls, like comment:5. c.f. # 11552 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 16:44:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 16:44:38 -0000 Subject: [GHC] #11560: panic: isInjectiveTyCon sees a TcTyCon Message-ID: <047.844547fa9c9539b9ad0e369581a719b2@haskell.org> #11560: panic: isInjectiveTyCon sees a TcTyCon -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I typed this into ghci and it panicked. Not sure whether the declaration is really valid anyways, but ghci shouldn't panic on it. {{{ rwbarton at morphism:~/ghc-newest$ ./inplace/bin/ghc-stage2 --interactive GHCi, version 8.1.20160201: http://www.haskell.org/ghc/ :? for help Prelude> :set -XTypeFamilies -XTypeInType Prelude> :m +Data.Kind Prelude Data.Kind> type family T (l :: *) (k :: l) :: * where { T * Int = * } ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160201 for x86_64-unknown-linux): isInjectiveTyCon sees a TcTyCon T Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 16:56:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 16:56:50 -0000 Subject: [GHC] #11163: New exhaustiveness checker breaks T5642 In-Reply-To: <046.9409b0868436ac4488ffd0b9a2c0e5a5@haskell.org> References: <046.9409b0868436ac4488ffd0b9a2c0e5a5@haskell.org> Message-ID: <061.e087c12049153f4f0518d082fbe6f34d@haskell.org> #11163: New exhaustiveness checker breaks T5642 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: pattern | checker, PatternMatchWarnings 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 gkaracha): After merging Phab:D1795, I checked again the situation with T5642: With the old pattern match checker the deviation (for bytes allocated) for #5642 was 196.8%. With the current HEAD it is 222.3%, yet this increase is not only due to the new checker. Disabling coverage checking for the test gives deviation 212.0%, which means that only 10.3% is due to the new checker. Concerning this 10.3%, the module uses the generics library and function `to :: Rep a x -> a` has 100 clauses, all with nested patterns. Most importantly, `Rep` is a type family, which means that the new checker goes the extra mile to ensure they are all well-typed. Hence, this 10.3% is quite reasonable (the old pattern match checker was --in most cases-- faster because it did not take into account types). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 16:57:19 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 16:57:19 -0000 Subject: [GHC] #11163: New exhaustiveness checker breaks T5642 In-Reply-To: <046.9409b0868436ac4488ffd0b9a2c0e5a5@haskell.org> References: <046.9409b0868436ac4488ffd0b9a2c0e5a5@haskell.org> Message-ID: <061.68ed04702eaf909b37ff56693f53c3a5@haskell.org> #11163: New exhaustiveness checker breaks T5642 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gkaracha Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: pattern | checker, PatternMatchWarnings 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 gkaracha): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 17:01:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 17:01:17 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.df28c2a516a070a7a2c6282bce71736b@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): So under comment:7 as I understand it `*` is a synonym for `TYPE L`. We can make a table {{{ 1 :: Int and Int :: * = TYPE L 2# :: Int# and Int# :: TYPE UW64 3.0# :: Double# and Double# :: TYPE UF64 Int :: * and * :: * = TYPE L }}} The last line is given to us by TypeInType. But to me the thing `Int` seems at least as different from the thing `1` as the things `1`, `2#` and `3.0#` are from each other. So, the suggestion is to add another constructor `T` to `RuntimeRep` and replace the last line with {{{ Int :: * and * :: TYPE T }}} We could define a synonym `type Kind = TYPE T` and then `* :: Kind`. The motivation is basically: By merging the type and kind levels, TypeInType means that we no longer ''need'' to distinguish types and kinds. That is great for implementing, say, kind coercions because we don't need to duplicate the language of coercions to the kind level any more. (Feel free to substitute your own, better examples.) However, now that this RuntimeRep story has emerged, it seems we could get the best of both worlds, by defining `* = TYPE L`, and `Kind = TYPE T`. Now we can abstract over the difference between types and kinds when we want to, by working with `TYPE t`. Or we can distinguish between types and kinds when that makes sense, by using `*` and `Kind`. I don't have any great examples for the latter. Maybe if you define a type family whose result is intended to be a kind (since you use it to classify a type elsewhere) you would want to be able to enforce that on clients who may define their own instances. Or maybe the typing rule for a coercion should be that the type `s ~ t` of coercions is well-formed only if `s :: TYPE r` and `t :: TYPE r` for the same `r`, and you don't want to allow coercing between values and types. (But see the end of this comment.) ---- Note that one could perhaps retain even more of the type/kind/sort/etc. hierarchy by adding a parameter to `T`. The parameter `r` would contain information about the representation of the "values" (types) classified by types of kind `TYPE (T r)`. Or in symbols, {{{ if C :: K = TYPE r, (i.e., the type C has representation r) then K :: TYPE (T r), }}} or in short `TYPE r :: TYPE (T r)`. I'm not sure how this would interact with type constructors though (with kinds built from `(->)`). This probably has something to do with the indexed TypeRep story also, which I haven't been paying any attention to. ---- These suggestions apply to an unspecified extension of Haskell that might want to treat the type level in an arbitrary way. If there's a specific plan for "GHC Haskell" to identify types with their TypeReps as mentioned in comment:10 (I guess this means there is some way to refer to a type at the value level, so now it really makes sense to write functions of type `* -> *`, etc.) then there is probably not much reason to take this route, indeed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 17:03:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 17:03:43 -0000 Subject: [GHC] #11555: catch _|_ breaks at -O1 In-Reply-To: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> References: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> Message-ID: <060.7f9754a30da89f4e4b70ebe60b33ce21@haskell.org> #11555: catch _|_ breaks at -O1 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 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): So consider {{{ f x = catch (g x) }}} where `g` is strict in `x`; perhaps {{{ g x = if x>0 then else }}} Now, are we allowed to use call-by-value on `f`? If 'no' then we are forced to use lazy evaluation and thunk creation in inner loops of the I/O system (for example). This can have a very material performance impact. Being able do to this sort of code motion is what "The semantics of imprecise exceptions" was all about and, combined with `unsafePerformIO`, you can indeed get unpredictable behaviour. There certainly ought to be a way of saying "evaluate this free variable right at this point",and there is: `evaluate` is just what you need. Indeed if you replace `abort "fail"` with `evaluate (abort "fail")` then the program behaves the same no matter how you compile it. But, I grant you, this makes my head hurt, and needs a careful writeup. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 17:04:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 17:04:08 -0000 Subject: [GHC] #11560: panic: isInjectiveTyCon sees a TcTyCon In-Reply-To: <047.844547fa9c9539b9ad0e369581a719b2@haskell.org> References: <047.844547fa9c9539b9ad0e369581a719b2@haskell.org> Message-ID: <062.0b9a3f3bc6fa18c1b2b32a74df9677e1@haskell.org> #11560: panic: isInjectiveTyCon sees a TcTyCon -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): The panic is also present in version 8.0.0.20160123. (Note both these versions are slightly out of date so it's possible this is fixed already.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 17:05:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 17:05:21 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.b3b2a1511a6579b9eb95f34d6e9e66ff@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11523 Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => polykinds/T11523 Comment: I believe I've fixed this. I'm sorry I missed the RC2 bus. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 17:41:11 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 17:41:11 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.b36b05cdcf7b27d01d80760a4e0fd7e4@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11523 Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Thanks! I'll give it a shot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 17:47:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 17:47:16 -0000 Subject: [GHC] #11552: ScopedTypeVariables / InstanceSigs do not work in GHC 8.0 In-Reply-To: <048.ed8df3269063d4724395b509ea472611@haskell.org> References: <048.ed8df3269063d4724395b509ea472611@haskell.org> Message-ID: <063.e6ec469c7955ee3a432fdbe0e9ff54e4@haskell.org> #11552: ScopedTypeVariables / InstanceSigs do not work in GHC 8.0 -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11552 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c9ac9de78254fb6bf463fd6370be7a7214b3e649/ghc" c9ac9de7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c9ac9de78254fb6bf463fd6370be7a7214b3e649" Test Trac #11552 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 18:10:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 18:10:37 -0000 Subject: [GHC] #11555: catch _|_ breaks at -O1 In-Reply-To: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> References: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> Message-ID: <060.a881e6b359af428a9c123c690c1dc820@haskell.org> #11555: catch _|_ breaks at -O1 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 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 NeilMitchell): Note that the second example involves no {{{unsafePerformIO}}}, so it's surprisingly semantics just with imprecise exceptions alone. My personal expectation is that yes, you would have to create a thunk for {{{g}}} - but my expectations rarely match the lazy exception semantics. If alternatively you argue that one valid interpretation is {{{catch _|_ x = _|_}}}, then why not define: {{{#!hs catch !a b = ... }}} I suspect having a lazy first argument never improves performance, and now it's always picking the same semantics at all optimisation levels. Note that in the above examples {{{evaluate}}} is a sufficient trick, but for Shake only because I reduced the example. In the real code it takes an argument of type {{{IO a}}}. I think a correct general workaround is: {{{#!hs safeCatch a b = catch (join $ evaluate a) b }}} But it would be good to get someone who fully understands the semantics to declare this a "safe" trick. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 18:17:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 18:17:58 -0000 Subject: [GHC] #11560: panic: isInjectiveTyCon sees a TcTyCon In-Reply-To: <047.844547fa9c9539b9ad0e369581a719b2@haskell.org> References: <047.844547fa9c9539b9ad0e369581a719b2@haskell.org> Message-ID: <062.c6cdebe8fb459d1c69780e3c5e230ced@haskell.org> #11560: panic: isInjectiveTyCon sees a TcTyCon -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * keywords: => TypeInType Comment: I'll mark this as a TypeInType ticket since I don't know how to cause the panic without TypeInType, though of course it may really be an issue with injective type families. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 18:32:28 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 18:32:28 -0000 Subject: [GHC] #9693: Reloading GHCi with Template Haskell names can panic GHC In-Reply-To: <043.739fde51b47ea4696baf564b0f9ae27e@haskell.org> References: <043.739fde51b47ea4696baf564b0f9ae27e@haskell.org> Message-ID: <058.769857ab02204e791fc10bc5989fde33@haskell.org> #9693: Reloading GHCi with Template Haskell names can panic GHC -------------------------------------+------------------------------------- Reporter: maxs | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bollmann): upon a quick look at the code the initial error message is thrown in module `rename/RnEnv.hs` by function `lookupExactOcc_either`. But I'm unsure why this leaves `ghci` in an inconsistent state afterwards. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 19:21:24 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 19:21:24 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.34c68f3dbbb2bb728f3d7076c02386bc@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Consider the rather similar definitions of A and B below: {{{#!hs {-# language FunctionalDependencies, TypeFamilies, MultiParamTypeClasses, GeneralizedNewtypeDeriving #-} class A s m | m -> s instance A () Int class B m where type S m :: * instance B Int where type S Int = () }}} Now, {{{#!hs newtype X = X Int deriving (A ()) }}} works, but {{{#!hs newtype X = X Int deriving (B) }}} complains {{{ ? Can't make a derived instance of ?B X? (even with cunning GeneralizedNewtypeDeriving): the class has associated types ? In the newtype declaration for ?X? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 19:31:45 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 19:31:45 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.a0243c2c97279a03aef857c67cb2d16d@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): A related common idiom you can spot in the wild using the `mtl` is to do something like {{{#!hs newtype M a = M (ReaderT MyEnv (StateT MyState (WriterT MyLog IO)) a) deriving (Functor, Applicative, Monad, MonadIO, MonadReader MyEnv, MonadState MyState, MonadWriter MyLog, MonadIO) }}} resulting in a custom monad where you can filter out as many of the instances as you don't like in 2 lines rather than in hand-rolling one in 60. E.g. `haskeline`'s `InputT` is more or less an example of this, although Judah explicitly hides the `MonadReader` instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 21:16:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 21:16:44 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.65a619b2343332d9a6a79122c5336f59@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Interesting. I suppose you could say {{{ type family S m :: * class B m where {} type instance S Int = () instance B Int }}} Now you can say {{{ type instance S X = () newtype X = X Int deriving( B ) }}} This supplies the extra information nominally, whereas the fundep notation supplies it positionally. It might be advantageous to be able to give an associated type instance outside of a class instance decl. Thanks for the example. The problem is notational rather than fundamental; but still I can see it's annoying. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 21:26:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 21:26:54 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.17cc7e2d9a9de01a3df6db1a0b118bdd@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by mfox): I did a perf build from today's master, and I'm seeing a ton of test failures. Like hundreds. Most are "bad stderr" or "stderr mismatch". I notice a lot of tests complaining about "unable to decommit memory: Function not implemented". This may be the cause of all the failures. Any idea what it's about? Building from e2b66a0ef0a0d8ff5cdb681edd8309954ef0a08a I made sure to update all of my submodules with git submodule update --init as recommended in https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources to avoid the old iserv problem mentioned above. Any ideas? Should I open a new bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 21:29:19 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 21:29:19 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.b902a291469794738c45fb6ee258bb58@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): See #8165. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 21:31:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 21:31:13 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.a40f8f8e5ca77c3b8cc07d7e36a6bda7@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by mfox): {{{ OVERALL SUMMARY for test run started at Mon Feb 8 20:39:23 2016 UTC 0:18:00 spent to go through 5012 total tests, which gave rise to 18811 test cases, of which 13830 were skipped 70 had missing libraries 4119 expected passes 81 expected failures 0 caused framework failures 1 unexpected passes 707 unexpected failures 3 unexpected stat failures }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 21:40:29 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 21:40:29 -0000 Subject: [GHC] #11465: Eliminate check_lifted check in TcValidity In-Reply-To: <046.8d383cd5b7ced0427539a51976b34ef3@haskell.org> References: <046.8d383cd5b7ced0427539a51976b34ef3@haskell.org> Message-ID: <061.f2a8de4a3cd7ddf7cd6135dc8cb6fa1a@haskell.org> #11465: Eliminate check_lifted check in TcValidity -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1807 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => LevityPolymorphism Comment: Adding a keyword so we can find it when we write a paper about levity polymorphism! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 21:45:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 21:45:38 -0000 Subject: [GHC] #11534: Allow class associated types to reference functional dependencies In-Reply-To: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> References: <045.1a6bcd80210fca99b610721a6253548f@haskell.org> Message-ID: <060.26a5f913a140627bd72cbb440609c833@haskell.org> #11534: Allow class associated types to reference functional dependencies -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeFamilies, Resolution: | FunctionalDependencies Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah yes, #8165 indeed; provided that the rule in comment:7 there is indeed what is wanted in the cases that Edward describes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 21:50:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 21:50:49 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.e20795e31a67c00cff7ec68a1ae344a9@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by mfox): This message stands out: {{{ You are using an unsupported version of LLVM! Currently only 3.7 is supported. }}} I swear something told me only 3.5 is supported. Maybe it's the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 21:58:40 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 21:58:40 -0000 Subject: [GHC] #11550: ghc-HEAD -DDEBUG is broken (possiby by D1880) In-Reply-To: <045.510eebdecea6778a3cdc8536c2c13abb@haskell.org> References: <045.510eebdecea6778a3cdc8536c2c13abb@haskell.org> Message-ID: <060.26e08be67723d186ff0666b1d710d40d@haskell.org> #11550: ghc-HEAD -DDEBUG is broken (possiby by D1880) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1889 Wiki Page: | -------------------------------------+------------------------------------- Comment (by ?mer Sinan A?acan ): In [changeset:"023fc92f6f98a8bd003ce20083d3682aec865cb5/ghc" 023fc92f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="023fc92f6f98a8bd003ce20083d3682aec865cb5" Remove unused LiveVars and SRT fields of StgCase We also need to update `stgBindHasCafRefs` assertion with this change, as we no longer have the pre-computed SRT, LiveVars etc. We rename it to `topStgBindHasCafRefs` and implement it like this: A non-updatable top-level binding may refer to a CAF by referring to a top-level definition with CAFs. A top-level definition may have CAFs if it's updatable. At this point (because this is done after TidyPgm) top-level Ids (whether imported or defined in this module) are GlobalIds, so the top-levelness test is easy. (see also comments in the code) Reviewers: bgamari, simonpj, austin Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1889 GHC Trac Issues: #11550 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 22:01:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 22:01:10 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.6fa11536c01c042743d54fef4685e421@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): GHC 7.10.* requires LLVM 3.5.2. HEAD requires 3.7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 22:10:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 22:10:05 -0000 Subject: [GHC] #7985: Allow openFile on unknown file type In-Reply-To: <049.5d3eb1afc9286373e53a0f1299c75b88@haskell.org> References: <049.5d3eb1afc9286373e53a0f1299c75b88@haskell.org> Message-ID: <064.b753973612b052ba3af1a5d60d120069@haskell.org> #7985: Allow openFile on unknown file type -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 singpolyma): * status: closed => new * resolution: invalid => Comment: I mean a filetype that is not one of the currently supported filetypes. The example in question when I opened this was some special kind of QNX file (like a device, but different) -- when patched to allow the handle to be created, operations on it work fine, but by default the program just crashes because it doesn't know how to categorise the file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 22:38:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 22:38:35 -0000 Subject: [GHC] #7985: Allow openFile on unknown file type In-Reply-To: <049.5d3eb1afc9286373e53a0f1299c75b88@haskell.org> References: <049.5d3eb1afc9286373e53a0f1299c75b88@haskell.org> Message-ID: <064.5c23e41b6632f83d42e1f5c623c0e727@haskell.org> #7985: Allow openFile on unknown file type -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 rwbarton): What are "the currently supported filetypes"? Can you please point to some code? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 8 22:55:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 08 Feb 2016 22:55:22 -0000 Subject: [GHC] #7985: Allow openFile on unknown file type In-Reply-To: <049.5d3eb1afc9286373e53a0f1299c75b88@haskell.org> References: <049.5d3eb1afc9286373e53a0f1299c75b88@haskell.org> Message-ID: <064.6e5283596d954d3891102283d6909915@haskell.org> #7985: Allow openFile on unknown file type -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 singpolyma): IODeviceType as defined in https://github.com/ghc/ghc/blob/master/libraries/base/GHC/IO/Device.hs -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 00:34:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 00:34:41 -0000 Subject: [GHC] #11561: Have static ghci link against its own copy of its libraries Message-ID: <047.005f1a7fca7542e98131ea7a465aec68@haskell.org> #11561: Have static ghci link against its own copy of its libraries -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Runtime | Version: 8.1 System (Linker) | 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 ghci is built dynamically, there is just one copy of each of the libraries that make up ghci (the ghc library, and base and ghc-prim and all the other dependencies of ghc or ghci) loaded, which is used both by ghc(i) itself directly, and also by the code run inside ghci. Could we do the same for statically-built ghci? Here is a possibility. * Ensure through suitable linker flags that ''all'' objects in the archives for the libraries that make up ghci are linked into the ghci executable. (Or link the .o files that we also produce (except for ghc itself), instead.) * Through more linker flags, add ''dynamic symbol table'' entries for all the symbols in the ghci executable that might be referenced from code run inside ghci; say all the symbols that the runtime linker would add to its internal symbol table. This is a bit weird, because the ghci executable is not relocatable. But I can't see any specific reason why it is wrong to do. * In the runtime linker, don't load any library that was linked into ghci. Instead, trust that `dlsym()` (or the OS-specific equivalent) will find symbols from those libraries. Pros: * ghci startup time (and time to load other libraries linked into ghc) should be reduced since the runtime linker doesn't need to process a bunch of relocations. ghci startup time is particularly noticeable on, say, ARM. (On my tablet it takes about a second.) Not sure whether the dynamic loader has to process the executable's dynamic symbol table at startup time, but I assume that even if it does, that process is much faster. * We can eliminate the .o file for each library linked into ghci from the binary distribution, at the cost of having to link that entire .o file into ghci. The net savings would be whatever part of that object file would have been linked into ghci anyways. (Note that we do not currently distribute a .o file for the ghc library anyways. My estimate for the total savings is on the order of 20MB.) Unknown * The total process size of ghci might go up or down. For each library that is eventually loaded into ghci anyways, we save space equal to the amount of code that would have been linked into ghci from that library. For each library that is not eventually loaded into ghci, we use additional space equal to the amount of code in that library that would not have been linked into ghci. We could exclude some libraries from this treatment if they make for particularly bad tradeoffs here and are not depended on by other libraries that we want to include. We might exclude the ghc package just because it is rarely loaded into ghci, even though most or all of it will be linked into ghci anyways, to leave more flexibility for its dependencies. Cons: * ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 00:38:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 00:38:55 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.c1b5c6a00e68f33db4d7e9dc0c1b7a36@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11523 Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ekmett): * Attachment "Categories.hs" added. a test case that is still failing after february 8th patches -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 00:41:48 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 00:41:48 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.85f74bef5cd40d88ed064942ab21afee@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11523 Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Attempting to compile the attachment I just submitted now crashes `ghc` HEAD with the following rather uninformative error message: {{{ *** Exception: No match in record selector ctev_dest }}} I haven't cut down the example, yet, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 00:46:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 00:46:54 -0000 Subject: [GHC] #7985: Allow openFile on unknown file type In-Reply-To: <049.5d3eb1afc9286373e53a0f1299c75b88@haskell.org> References: <049.5d3eb1afc9286373e53a0f1299c75b88@haskell.org> Message-ID: <064.2ea095352ef2ecb05b916d5785b78942@haskell.org> #7985: Allow openFile on unknown file type -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 rwbarton): I believe these cryptic communications refer to the following function. {{{ statGetType :: Ptr CStat -> IO IODeviceType statGetType p_stat = do c_mode <- st_mode p_stat :: IO CMode case () of _ | s_isdir c_mode -> return Directory | s_isfifo c_mode || s_issock c_mode || s_ischr c_mode -> return Stream | s_isreg c_mode -> return RegularFile -- Q: map char devices to RawDevice too? | s_isblk c_mode -> return RawDevice | otherwise -> ioError ioe_unknownfiletype }}} These are all the types of file defined by POSIX, but I suppose a system could add others. But it's unclear what to do here. What should we return for, say, `hIsSeekable` if you opened such a file? Just guessing once and for all that files of unknown type are seekable (or not seekable) doesn't seem right. Haven't looked into what else the file type is used for. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 01:06:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 01:06:26 -0000 Subject: [GHC] #11561: Have static ghci link against its own copy of its libraries In-Reply-To: <047.005f1a7fca7542e98131ea7a465aec68@haskell.org> References: <047.005f1a7fca7542e98131ea7a465aec68@haskell.org> Message-ID: <062.084da2e492b3e4cbb6485ce4783c8957@haskell.org> #11561: Have static ghci link against its own copy of its libraries -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Runtime System | Version: 8.1 (Linker) | 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 rwbarton): I don't know how this would interact with remote ghci. Badly, I guess. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 01:11:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 01:11:54 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.51fad522a6438ccd5824f8113378590c@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: 5321 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): What's the status of discarding coercions during normal compilations? Is it worth separating that idea out into its own ticket? Seems like it would be good for compilation time more generally, not just when computing with type families. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 02:22:04 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 02:22:04 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.5dbfc1fab995a0687a07fd61d800eccc@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: 5321 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): It somehow didn't make it onto the ticket, but there was a concern about this idea: once you omit coercions from one module, then all downstream modules are also missing (some) coercions. This means that `-dcore-lint` doesn't do nearly as much as it normally does. That makes me a bit uncomfortable, but perhaps it's OK. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 02:59:34 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 02:59:34 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.da634f5bb29d59dc931876858d1d93c5@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): And also, I thought of this: what type would `Bool` have? It surely must have type `*`. But then would it not work as a kind anymore? So perhaps this isn't really such a good idea. In any case, I don't believe there is any serious consideration of implementing Reid's plan... just musing about alternatives. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 04:08:33 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 04:08:33 -0000 Subject: [GHC] #11522: maxStkSize can overflow In-Reply-To: <047.c682131ad79ad28d6b34355aabbd4286@haskell.org> References: <047.c682131ad79ad28d6b34355aabbd4286@haskell.org> Message-ID: <062.f4ef45b36ba8a3bd0212f69dbfc09b9c@haskell.org> #11522: maxStkSize can overflow -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: MarcelineVQ Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.4 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:D1895 Wiki Page: | -------------------------------------+------------------------------------- Changes (by MarcelineVQ): * owner: => MarcelineVQ * differential: => Phab:D1895 Comment: The suggested overflow test of -K32.0001G can overflow enough to be above the minimally required stack size to run a small program. Decided to use -K4294967297W to overflow it to exactly 1 for testing. According to the invariants in TSO.h:[[BR]] tso->stack_size <= tso->max_stack_size[[BR]] Which means I'll need to change StgStack.stack_size too but its implications reach farther than the other two, offsets and such, so please double-check if that's a good idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 07:33:52 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 07:33:52 -0000 Subject: [GHC] #11561: Have static ghci link against its own copy of its libraries In-Reply-To: <047.005f1a7fca7542e98131ea7a465aec68@haskell.org> References: <047.005f1a7fca7542e98131ea7a465aec68@haskell.org> Message-ID: <062.a9cefc59da0b246db430b3e2edd8a80b@haskell.org> #11561: Have static ghci link against its own copy of its libraries -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Runtime System | Version: 8.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11238 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * cc: trommler (added) * related: => #11238 Comment: I proposed something similar as part of the dynamic linker redesign (#11238). My idea in that ticket was to use the system runtime linker on architectures where we do not have RTS linker support (e.g. powerpc64[le]) even in a statically linked GHCi. The ticket mentioned above has more information and a link to a Wiki page with the design proposal (in progress). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 07:35:50 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 07:35:50 -0000 Subject: [GHC] #11561: Have static ghci link against its own copy of its libraries In-Reply-To: <047.005f1a7fca7542e98131ea7a465aec68@haskell.org> References: <047.005f1a7fca7542e98131ea7a465aec68@haskell.org> Message-ID: <062.64d719fc919d68bae7da89322d2aa508@haskell.org> #11561: Have static ghci link against its own copy of its libraries -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Runtime System | Version: 8.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11238 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): Replying to [comment:1 rwbarton]: > I don't know how this would interact with remote ghci. Badly, I guess. Why? Remote GHCi lives in its own process, so the way the parent process is linked does not matter at all. Am I missing something fundamental here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 08:38:56 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 08:38:56 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.b13a3f16481e5909c0608933bc99526f@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11523 Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Ah, that's #11401, which Richard hasn't got to yet. So, progress of a sort. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 08:42:58 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 08:42:58 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.f7675b730b5c50faeaad047f0fdc0b63@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: 5321 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think the design in comment:15 gets us a decent way forward. But someone will have to implement it, and I'm totally swamped. So the status is "stalled" I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 09:19:47 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 09:19:47 -0000 Subject: [GHC] #10022: Clean up GHC.RTS.Flags In-Reply-To: <052.5f42b7b89367d2d1404df9b2172515f5@haskell.org> References: <052.5f42b7b89367d2d1404df9b2172515f5@haskell.org> Message-ID: <067.864a56cec0496edce248a75ce565b667@haskell.org> #10022: Clean up GHC.RTS.Flags -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9970 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): For the record, the original proposal was, > btw, I noticed that the API exposed by GHC.RTS.Flags varies depending on `unsigned int`: > > {{{#!hs > -- | @'nat'@ defined in @rts/Types.h@ > type Nat = #{type unsigned int} > > data GCFlags = GCFlags > { statsFile :: Maybe FilePath > , giveStats :: GiveGCStats > , maxStkSize :: Nat > , initialStkSize :: Nat > , stkChunkSize :: Nat > ... > }}} > > Is this really a good idea rather simply using `Word` which I assume should always be large enough to contain the range of `CULong`? > > Moreover, shouldn't most of those small-fields be `!`-ed to avoid thunks and unecessary pointer chasing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 09:33:00 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 09:33:00 -0000 Subject: [GHC] #11213: Incorrect reported pattern synonym signature In-Reply-To: <049.0060591a08c7b469b18d12224f42f93b@haskell.org> References: <049.0060591a08c7b469b18d12224f42f93b@haskell.org> Message-ID: <064.2d151a6da610b4bae22501f08e929c5f@haskell.org> #11213: Incorrect reported pattern synonym signature -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1896 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rdragon): * differential: => Phab:D1896 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 10:01:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 10:01:07 -0000 Subject: [GHC] #5642: Deriving Generic of a big type takes a long time and lots of space In-Reply-To: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> References: <049.904645e363a227f735eb4cfb7fbae513@haskell.org> Message-ID: <064.72c0120b35a10c16bbb385bbca180ba3@haskell.org> #5642: Deriving Generic of a big type takes a long time and lots of space -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.3 Resolution: | Keywords: deriving- | perf, Generics Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: T5642 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"16cf460ca6c4aa1ccb05703743f61242ee90c53f/ghc" 16cf460/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="16cf460ca6c4aa1ccb05703743f61242ee90c53f" testsuite: Un-break T5642 This was largely fixed by the re-rework of the pattern match checker. Resolves #5642. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 10:39:50 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 10:39:50 -0000 Subject: [GHC] #11246: Regression typechecking type synonym which includes `Any`. In-Reply-To: <049.3c8cb14b3612458c05777138a511d1ef@haskell.org> References: <049.3c8cb14b3612458c05777138a511d1ef@haskell.org> Message-ID: <064.3416a7cebf53efe3f5532452386282b9@haskell.org> #11246: Regression typechecking type synonym which includes `Any`. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => GHC rejects valid program * component: Compiler => Compiler (Type checker) @@ -1,1 +1,1 @@ - {{{ + {{{#!hs New description: {{{#!hs module Foo where import GHC.Exts type Key a = Any }}} produces the error message on HEAD but compiles on 7.8.3 and 7.10.1 (thanks to Reid for testing). {{{ unsafeany.hs:5:1: error: ? The type family ?Any? should have no arguments, but has been given none ? In the type synonym declaration for ?Key? Failed, modules loaded: none. }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 11:06:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 11:06:44 -0000 Subject: [GHC] #11540: ghc accepts non-standard type without language extension In-Reply-To: <047.4af844a129b268095ee1a782d708bfe8@haskell.org> References: <047.4af844a129b268095ee1a782d708bfe8@haskell.org> Message-ID: <062.c42e25c18b3910e5c9fe89df4e9bde19@haskell.org> #11540: ghc accepts non-standard type without language extension -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'd be happy to see this checked, if someone wants to have a go, but I doubt that it's a very high priority. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 11:13:36 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 11:13:36 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.83af2eda195f758a59b84b4472f6d3d8@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: skvadrik Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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:D1888 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Simon M and I are really doubtful about whether fixing this is a good idea at all. With the proposed fix we have {{{ module M( (%%)( A, B ) ) where -- OK data (%%) x y = A x | B y module M( (%%)( .. ) ) where -- OK data (%%) x y = A x | B y module M( (%%) ) where -- NOT OK data (%%) x y = A x | B y }}} This seems horribly non-uniform. Better just to require the `type` keyword in all three cases, I suggest. Very sorry not to have paid more attention before. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 11:15:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 11:15:02 -0000 Subject: [GHC] #11488: -dynamic-too is entirely undocumented In-Reply-To: <046.8614faf1a62ae888f21a12626cf19543@haskell.org> References: <046.8614faf1a62ae888f21a12626cf19543@haskell.org> Message-ID: <061.98c4759bbb0cd8456b432654f369e641@haskell.org> #11488: -dynamic-too is entirely undocumented -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => simonmar -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 11:17:13 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 11:17:13 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.6af84ee12b088b21d70068f1b23846eb@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Could you give a concrete example demonstrating the "massive asymptotic win". That would be highly motivating. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 11:18:30 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 11:18:30 -0000 Subject: [GHC] #11414: Panic with -XStrict: StgCmmEnv: variable not found In-Reply-To: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> References: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> Message-ID: <060.6b3711cc947fed03180ac7338faaeac6@haskell.org> #11414: Panic with -XStrict: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Strict Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T11414 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1791 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I need to look at this; sorry. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 11:31:20 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 11:31:20 -0000 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax In-Reply-To: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> References: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> Message-ID: <057.30975388121ce8450a4dfd4b6ebf426a@haskell.org> #2530: deriving Show adds extra parens for constructor with record syntax -------------------------------------+------------------------------------- Reporter: spl | Owner: Type: bug | Status: new Priority: lowest | Milestone: 8.0.1 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: | Differential Rev(s): Phab:D669 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * status: closed => new * resolution: fixed => Comment: Btw, this also affects how GHCi displays results: {{{ GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help Loaded GHCi configuration from /home/hvr/.ghci ?:1> data T = C { f1, f2 :: () } deriving Show data T = C {f1 :: (), f2 :: ()} f1 :: T -> () f2 :: T -> () ?:2> Just (C () ()) Just C {f1 = (), f2 = ()} it :: Maybe T ?:3> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 11:32:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 11:32:25 -0000 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax In-Reply-To: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> References: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> Message-ID: <057.5082ba9a5ba132c233b6e86f966606e3@haskell.org> #2530: deriving Show adds extra parens for constructor with record syntax -------------------------------------+------------------------------------- Reporter: spl | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 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: | Differential Rev(s): Phab:D669 Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * priority: lowest => highest * owner: => bgamari Comment: Temporarily setting this to high prio and assigning to Ben for judgement call -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 11:55:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 11:55:44 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.33bbb1b188bc1a235ca4f3e581958439@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: skvadrik Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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:D1888 Wiki Page: | -------------------------------------+------------------------------------- Comment (by skvadrik): I agree that basing compilation decisions on subtle syntax changes is bad, but error message {{{ error: Not in scope: ?%%? }}} which appears suddenly after GHC upgrade is obscure. I think it should at least suggest the cause of error and the way to fix it. Perhaps something like this (don't hesitate to suggest a better wording): {{{ error: Not in scope: ?%%? Note: if '%%' is a type constructor, add 'type' keyword: 'type (%%)' (requires extension TypeOperators) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 12:21:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 12:21:55 -0000 Subject: [GHC] #11562: WARNING: file compiler/stgSyn/CoreToStg.hs, line 250: $fCategoryConstraint:- True False Message-ID: <045.f6b21c47cfe1e3756485cde13f1c62ac@haskell.org> #11562: WARNING: file compiler/stgSyn/CoreToStg.hs, line 250: $fCategoryConstraint:- True False -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Tried to debug unrelated build failure of constraints-0.4.1.3 and found this in today's ghc-HEAD: {{{ $ inplace/bin/ghc-stage2 -fforce-recomp -c C.hs -O0 WARNING: file compiler/stgSyn/CoreToStg.hs, line 250 $fCategoryConstraint:- True False }}} {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE Rank2Types #-} {-# LANGUAGE GADTs #-} module C () where import Control.Category import GHC.Types (Constraint) data Dict :: Constraint -> * where Dict :: a => Dict a infixr 9 :- newtype a :- b = Sub (a => Dict b) instance Category (:-) where id = refl (.) = trans infixl 1 \\ (\\) :: a => (b => r) -> (a :- b) -> r r \\ Sub Dict = r trans :: (b :- c) -> (a :- b) -> a :- c trans f g = Sub (Dict \\ f \\ g) refl :: a :- a refl = Sub Dict {- $ inplace/bin/ghc-stage2 -fforce-recomp -c C.hs -O0 WARNING: file compiler/stgSyn/CoreToStg.hs, line 250 $fCategoryConstraint:- True False -} }}} Original file it was factored out is: https://github.com/ekmett/constraints/blob/c550b7653e88d58882873d11f05538d783313a05/src/Data/Constraint.hs Might be a result of Phab:D1889 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 13:11:51 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 13:11:51 -0000 Subject: [GHC] #11562: WARNING: file compiler/stgSyn/CoreToStg.hs, line 250: $fCategoryConstraint:- True False In-Reply-To: <045.f6b21c47cfe1e3756485cde13f1c62ac@haskell.org> References: <045.f6b21c47cfe1e3756485cde13f1c62ac@haskell.org> Message-ID: <060.b81b35fbeaee3eee33e4d0e761aef803@haskell.org> #11562: WARNING: file compiler/stgSyn/CoreToStg.hs, line 250: $fCategoryConstraint:- True False -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): > Might be a result of ?Phab:D1889 Same warning exists in current ghc-8.0 as well thus something else is happening here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 13:12:53 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 13:12:53 -0000 Subject: [GHC] #11413: GHC 8.1.20160111 fails to bootstrap itself. In-Reply-To: <046.15e95fc56f5612748d97a6c11de5e498@haskell.org> References: <046.15e95fc56f5612748d97a6c11de5e498@haskell.org> Message-ID: <061.3cbaa96719af7c0b3e3982c4f95235c4@haskell.org> #11413: GHC 8.1.20160111 fails to bootstrap itself. ----------------------------------------+---------------------------------- Reporter: kgardas | Owner: thomie Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1869 Wiki Page: | ----------------------------------------+---------------------------------- Comment (by hvr): Replying to [comment:5 thomie]: > Instead of reverting that commit, I plan to fix bootstrapping with HEAD by enabling `MIN_VERSION` support without `-hide-all-packages` (see ticket:10970#comment:7). I just submitted as phab:D1897, and now I realised that we had a similiar idea... except you wanted this to work w/o `-hide-all-packages` (which tbh at this point I wonder why `-hide-all-packages` isn't acceptable). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 13:14:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 13:14:10 -0000 Subject: [GHC] #11413: GHC 8.1.20160111 fails to bootstrap itself. In-Reply-To: <046.15e95fc56f5612748d97a6c11de5e498@haskell.org> References: <046.15e95fc56f5612748d97a6c11de5e498@haskell.org> Message-ID: <061.060207b64a8a4b01ee5e430e51941dbd@haskell.org> #11413: GHC 8.1.20160111 fails to bootstrap itself. -------------------------------------+------------------------------------- Reporter: kgardas | Owner: thomie Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1869 Wiki Page: | Phab:D1897 -------------------------------------+------------------------------------- Changes (by hvr): * differential: Phab:D1869 => Phab:D1869 Phab:D1897 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 13:30:28 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 13:30:28 -0000 Subject: [GHC] #10970: Built in MIN_VERSION macro support In-Reply-To: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> References: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> Message-ID: <060.91f778104df0b6821048470b7b1ba5ed@haskell.org> #10970: Built in MIN_VERSION macro support -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Phab:D1349, Wiki Page: | Phab:D1869 -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:3 rwbarton]: > [...] I don't understand any more why it should be the case that we only create these macros for packages explicitly specified with `-package` or equivalent. Well, if you `-hide-all-packages` and unmask a few packages via `-package`, then exposing macros for all other packages in the package database would be very unsound, as it would destroy modularity. You don't expect package versions outside the set of explicitly requested ones to have any effect on your code, just like you wouldn't expect modules not explicitly imported to bring entities into scope (sadly, instances violate this already, but we shouldn't add to this any more). Also, always defining macros even though the packages are not activated (i.e. enabled via `-package`) would also break code which uses `#ifdef MIN_VERSION_...` to query whether a package has been activated for a given compilation, and thus its modules are allowed to be `import`ed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 14:14:07 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 14:14:07 -0000 Subject: [GHC] #11541: Type errors sometimes has a lot of irrelevant information In-Reply-To: <047.b489a9355667fda5e49935258d0dd4af@haskell.org> References: <047.b489a9355667fda5e49935258d0dd4af@haskell.org> Message-ID: <062.cb6bbb83dda33873fdbe25ad9416e74e@haskell.org> #11541: Type errors sometimes has a lot of irrelevant information -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by augustss): So it seems that there is an error for each type variable that defaulting would have resolved in the normal case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 14:27:54 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 14:27:54 -0000 Subject: [GHC] #11547: Accessing shadowed definitions in GHCi In-Reply-To: <044.71011ab462b5fa37155c58f145f7265b@haskell.org> References: <044.71011ab462b5fa37155c58f145f7265b@haskell.org> Message-ID: <059.243a7b902e134ab2e31f769718ade11f@haskell.org> #11547: Accessing shadowed definitions in GHCi -------------------------------------+------------------------------------- Reporter: mniip | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Is it desirable: * To provide full access, using qualified names, to shadowed data types (and maybe values), or * To consistently ''not'' provide it? I rather assume the former. After all if you say {{{ > data A = A > let f A = Int > data A = XX > :type f }}} then we have to print some sensible type for `f`, but it clearly can't mention the new data type `A`; it must somehow mention the old data type `A`. And then you might want to know more about that data type. So it would be good to document this behaviour, and to make it work consistently. I know how some, but not all, of the moving parts work, so I can advise. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 14:41:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 14:41:05 -0000 Subject: [GHC] #11533: Stack check not optimized out even if it could be In-Reply-To: <046.6d5f7866bf619f9b74b6c94e89479ca9@haskell.org> References: <046.6d5f7866bf619f9b74b6c94e89479ca9@haskell.org> Message-ID: <061.ab614a68760aaf6e2b30cbee93078c53@haskell.org> #11533: Stack check not optimized out even if it could be -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 (CodeGen) | Resolution: | Keywords: cmm Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1881 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"4ec61411930495fc109be27993c176fd7aaf486d/ghc" 4ec61411/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4ec61411930495fc109be27993c176fd7aaf486d" Fix the removal of unnecessary stack checks The module CmmLayoutStack removes stack checks if a function does not use stack space. However, it can only recognize checks of the form Sp < SpLim. However, these checks get sometimes rewritten to Sp >= SpLim (with both branches swapped), so we better recognize these checks too. Test Plan: ./validate Reviewers: austin, bgamari, simonpj Reviewed By: simonpj Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1881 GHC Trac Issues: #11533 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 14:41:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 14:41:05 -0000 Subject: [GHC] #11530: Make fails on systems with GREP_OPTIONS In-Reply-To: <047.65eb2c1162c4e0a77b27714fb3375078@haskell.org> References: <047.65eb2c1162c4e0a77b27714fb3375078@haskell.org> Message-ID: <062.9b7f0650ebbf4c16314936072bbd629b@haskell.org> #11530: Make fails on systems with GREP_OPTIONS ---------------------------------+---------------------------------------- Reporter: alexlegg | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Resolution: | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1887 Wiki Page: | ---------------------------------+---------------------------------------- Comment (by Ben Gamari ): In [changeset:"bfec4a6aade005b6dbd170645d4f2d062cee1d92/ghc" bfec4a6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bfec4a6aade005b6dbd170645d4f2d062cee1d92" Unset GREP_OPTIONS in build system Test Plan: GREP_OPTIONS=--blah ./validate Reviewers: austin, thomie Reviewed By: thomie Differential Revision: https://phabricator.haskell.org/D1887 GHC Trac Issues: #11530 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 14:51:50 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 14:51:50 -0000 Subject: [GHC] #11563: fvProv falls into a hole (instead of detecting missing type argument) (regression from -rc1 to -rc2) Message-ID: <049.16d0cb1a68df6b8b24667b8e4900f6c5@haskell.org> #11563: fvProv falls into a hole (instead of detecting missing type argument) (regression from -rc1 to -rc2) -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This program has an error (T is missing an argument) {{{ data T a ; class C t ; instance C s => C T }}} which makes 8-rc2 fall into a hole: {{{ /opt/ghc/ghc-8.0.0.20160204/bin/ghc -c Bug.hs ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160204 for x86_64-unknown-linux): fvProv falls into a hole {ap6} }}} It is detected by 8-rc1: {{{ /opt/ghc/ghc-8.0.0.20160111/bin/ghc -c Bug.hs Bug.hs:1:40: error: ? Illegal instance declaration for ?C T? (All instance types must be of the form (T a1 ... an) where a1 ... an are *distinct type variables*, and each type variable appears at most once in the instance head. Use FlexibleInstances if you want to disable this.) ? In the instance declaration for ?C T? Bug.hs:1:42: error: ? Expecting one more argument to ?T? Expected a type, but ?T? has kind ?* -> *? ? In the first argument of ?C?, namely ?T? In the instance declaration for ?C T? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 15:03:00 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 15:03:00 -0000 Subject: [GHC] #10970: Built in MIN_VERSION macro support In-Reply-To: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> References: <045.d023da2e9c148d41ec284eb11be9b9b1@haskell.org> Message-ID: <060.55aebc84ee37585f810700df4374450d@haskell.org> #10970: Built in MIN_VERSION macro support -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Phab:D1349, Wiki Page: | Phab:D1869 -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:12 hvr]: > Replying to [comment:3 rwbarton]: > > [...] I don't understand any more why it should be the case that we only create these macros for packages explicitly specified with `-package` or equivalent. > > Well, if you `-hide-all-packages` and unmask a few packages via `-package`, then exposing macros for all other packages in the package database would be very unsound, as it would destroy modularity. I was unclear in comment:3. I thought I was pretty clear in comment:7, but let me try again. For a given compilation, after processing all package-related flags and environment variables, and reading in all package databases, GHC selects some set of installed packages, called the exposed packages. These are the packages that GHC will use to satisfy import statements. My proposal is simply: define `MIN_VERSION_x` macros for exactly the exposed packages. If you can import it, then you can check its version too. So, if you `-hide-all-packages` and unmask a few packages via `-package`, you'd only get `MIN_VERSION_x` macros for those packages you exposed with `-package`. The modularity concerns that Cabal addresses for imports then extend directly to `MIN_VERSION_x` macros. In Cabal, you need to state your dependency on a module to import it. So, you need to state your dependency on a module to check its version with `MIN_VERSION_x`, too. No need to reason explicitly about `-hide-all-packages` and `-package` flags to arrive at this result. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 15:24:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 15:24:49 -0000 Subject: [GHC] #9022: TH pretty printer and GHC parser semicolon placement mismatch In-Reply-To: <047.5de523bade6a019122fff089f11b671b@haskell.org> References: <047.5de523bade6a019122fff089f11b671b@haskell.org> Message-ID: <062.db11cf011501181aed63b048a031c6f8@haskell.org> #9022: TH pretty printer and GHC parser semicolon placement mismatch -------------------------------------+------------------------------------- Reporter: roldugin | Owner: bollmann Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): D1898 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bollmann): * status: new => patch * differential: => D1898 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 15:28:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 15:28:43 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.73005c1ecd087d8d71f2f453b6ff8c47@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: skvadrik Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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:D1888 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm fine with a better error message. It would be Much Better if the "note" part only came out if there ''actually was'' a type constructor `(%%)` in scope. And that should be easy to check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 15:31:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 15:31:22 -0000 Subject: [GHC] #9022: TH pretty printer and GHC parser semicolon placement mismatch In-Reply-To: <047.5de523bade6a019122fff089f11b671b@haskell.org> References: <047.5de523bade6a019122fff089f11b671b@haskell.org> Message-ID: <062.d1f633b10029c0107450b8a5d1065dc0@haskell.org> #9022: TH pretty printer and GHC parser semicolon placement mismatch -------------------------------------+------------------------------------- Reporter: roldugin | Owner: bollmann Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.1 Resolution: | Keywords: newcomer 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:D1898 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bollmann): * differential: D1898 => Phab:D1898 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 15:33:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 15:33:08 -0000 Subject: [GHC] #11541: Type errors sometimes has a lot of irrelevant information In-Reply-To: <047.b489a9355667fda5e49935258d0dd4af@haskell.org> References: <047.b489a9355667fda5e49935258d0dd4af@haskell.org> Message-ID: <062.dacc989463273e9bb603fa96563655ec@haskell.org> #11541: Type errors sometimes has a lot of irrelevant information -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I truly have no idea without an example. But I agree it's bad. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 16:03:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 16:03:03 -0000 Subject: [GHC] #11561: Have static ghci link against its own copy of its libraries In-Reply-To: <047.005f1a7fca7542e98131ea7a465aec68@haskell.org> References: <047.005f1a7fca7542e98131ea7a465aec68@haskell.org> Message-ID: <062.b6f2dbe18a09e6f435b20e97c4c14112@haskell.org> #11561: Have static ghci link against its own copy of its libraries -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Runtime System | Version: 8.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11238 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:3 trommler]: > Replying to [comment:1 rwbarton]: > > I don't know how this would interact with remote ghci. Badly, I guess. > Why? Remote GHCi lives in its own process, so the way the parent process is linked does not matter at all. Am I missing something fundamental here? I just thought that the pros would not apply since the Haskell libraries linked into the main ghc(i) process cannot be shared with the ones used by code loaded into the remote ghci process. But I didn't think about the fact that the remote ghci process also has its own set of Haskell libraries (assuming again that it is statically linked). So in fact the same benefits apply there; maybe reduced if ghc-iserv links against fewer Haskell libraries than ghc does. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 16:03:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 16:03:57 -0000 Subject: [GHC] #11561: Have static ghci link against its own copy of its libraries In-Reply-To: <047.005f1a7fca7542e98131ea7a465aec68@haskell.org> References: <047.005f1a7fca7542e98131ea7a465aec68@haskell.org> Message-ID: <062.b6fe4a66442950f75f647720138c0600@haskell.org> #11561: Have static ghci link against its own copy of its libraries -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Runtime System | Version: 8.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11238 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:2 trommler]: > I proposed something similar as part of the dynamic linker redesign (#11238). > > My idea in that ticket was to use the system runtime linker on architectures where we do not have RTS linker support (e.g. powerpc64[le]) even in a statically linked GHCi. > > The ticket mentioned above has more information and a link to a Wiki page with the design proposal (in progress). Thanks for the link, I'll take a look at the wiki page referenced there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 16:09:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 16:09:57 -0000 Subject: [GHC] #11401: No match in record selector ctev_dest In-Reply-To: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> References: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> Message-ID: <061.3d56822533ea1094ee2ae8b64ae19178@haskell.org> #11401: No match in record selector ctev_dest -------------------------------------+------------------------------------- Reporter: Lemming | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11523 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ekmett): * related: => #11523 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 16:47:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 16:47:03 -0000 Subject: [GHC] #11562: WARNING: file compiler/stgSyn/CoreToStg.hs, line 250: $fCategoryConstraint:- True False In-Reply-To: <045.f6b21c47cfe1e3756485cde13f1c62ac@haskell.org> References: <045.f6b21c47cfe1e3756485cde13f1c62ac@haskell.org> Message-ID: <060.0c00268199957cd866dd1b91f4578d85@haskell.org> #11562: WARNING: file compiler/stgSyn/CoreToStg.hs, line 250: $fCategoryConstraint:- True False -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by slyfox): Even less extensions, less external haskell module dependencies: {{{#!hs {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE Rank2Types #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE NoImplicitPrelude #-} module C () where import qualified GHC.Types as C (Constraint) class Category (cat :: k -> k -> *) where id :: cat a a (.) :: cat b c -> cat a b -> cat a c data Dict :: C.Constraint -> * where Dict :: a => Dict a newtype C2D a b = Sub (a => Dict b) instance Category C2D where id = Sub Dict f . g = Sub (sub (sub Dict f) g) sub :: a => (b => r) -> (C2D a b) -> r sub r (Sub Dict) = r {- $ inplace/bin/ghc-stage2 -fforce-recomp -c C.hs -O0 WARNING: file compiler/stgSyn/CoreToStg.hs, line 250 $fCategoryConstraint:- True False -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 18:05:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 18:05:49 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.dc2ff0961ea6f911037b23315b3b3183@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by mfox): Is there a way to apply these patches on 7.10 so I can make a current release without having to wait for 8.0? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 19:07:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 19:07:08 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.79962208d6320838c57acea469cae369@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Is there a way to apply these patches on 7.10 so I can make a current release without having to wait for 8.0? I'm afraid not. For the record, I have nightly ARM builds available [[http://home.smart- cactus.org/~ben/ghc/nightlies/arm/20160209/|here]]. They are built on an ARMv7 board running Debian 8. You will need to provide a working LLVM 3.7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 19:08:51 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 19:08:51 -0000 Subject: [GHC] #11530: Make fails on systems with GREP_OPTIONS In-Reply-To: <047.65eb2c1162c4e0a77b27714fb3375078@haskell.org> References: <047.65eb2c1162c4e0a77b27714fb3375078@haskell.org> Message-ID: <062.c3a86b1ed523de1a72ebe2d48bdd299b@haskell.org> #11530: Make fails on systems with GREP_OPTIONS ---------------------------------+---------------------------------------- Reporter: alexlegg | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Resolution: | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1887 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 19:08:57 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 19:08:57 -0000 Subject: [GHC] #11530: Make fails on systems with GREP_OPTIONS In-Reply-To: <047.65eb2c1162c4e0a77b27714fb3375078@haskell.org> References: <047.65eb2c1162c4e0a77b27714fb3375078@haskell.org> Message-ID: <062.667f383d22654832e35233874c8a11e9@haskell.org> #11530: Make fails on systems with GREP_OPTIONS ---------------------------------+---------------------------------------- Reporter: alexlegg | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.10.3 Resolution: | Keywords: Operating System: POSIX | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1887 Wiki Page: | ---------------------------------+---------------------------------------- Changes (by bgamari): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 19:09:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 19:09:10 -0000 Subject: [GHC] #11530: Make fails on systems with GREP_OPTIONS In-Reply-To: <047.65eb2c1162c4e0a77b27714fb3375078@haskell.org> References: <047.65eb2c1162c4e0a77b27714fb3375078@haskell.org> Message-ID: <062.fdef016c0867a35334b7b0f8cd1fbb92@haskell.org> #11530: Make fails on systems with GREP_OPTIONS -------------------------------------+------------------------------------- Reporter: alexlegg | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.10.3 Resolution: | Keywords: Operating System: POSIX | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1887 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Building GHC failed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 19:09:43 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 19:09:43 -0000 Subject: [GHC] #11533: Stack check not optimized out even if it could be In-Reply-To: <046.6d5f7866bf619f9b74b6c94e89479ca9@haskell.org> References: <046.6d5f7866bf619f9b74b6c94e89479ca9@haskell.org> Message-ID: <061.f7aec248724ace070acda05b238c1bd5@haskell.org> #11533: Stack check not optimized out even if it could be -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 (CodeGen) | Resolution: | Keywords: cmm Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1881 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 19:21:32 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 19:21:32 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.82214f4313d241a2bf0abc25e14f22fb@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Consider `Data.Sequence`. There `(<$>)` is `O(n)`, but `(<$)` is `O(log n)`. For any `Functor` that is representable, which is to say there exists `x` such that that `f a` is isomorphic to `x -> a`, you build a 'zipping' applicative that is isomorphic to reader. For that you can show that `(m *> _ = m)` and `(_ <* m = m)`. So `(<*)` and `(*>)` are `O(1)` while the `(<*>)` pays for every point used. In the case of something like {{{#!hs data Stream a = a :- Stream a }}} which is isomorphic to `Natural -> a`, if we look at the zipping applicative (which behaves like `ZipList`)` such an (*>) operation is O(1), but `(<*>)` incurs an ongoing cost O(n) in the length of the prefix of the result stream you inspect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 20:18:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 20:18:59 -0000 Subject: [GHC] #11563: fvProv falls into a hole (instead of detecting missing type argument) (regression from -rc1 to -rc2) In-Reply-To: <049.16d0cb1a68df6b8b24667b8e4900f6c5@haskell.org> References: <049.16d0cb1a68df6b8b24667b8e4900f6c5@haskell.org> Message-ID: <064.7a121d2733afefe33074737dd71396be@haskell.org> #11563: fvProv falls into a hole (instead of detecting missing type argument) (regression from -rc1 to -rc2) -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: 11520, 11516, | Differential Rev(s): 11399 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by j.waldmann): * related: => 11520, 11516, 11399 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 20:20:40 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 20:20:40 -0000 Subject: [GHC] #11563: fvProv falls into a hole (instead of detecting missing type argument) (regression from -rc1 to -rc2) In-Reply-To: <049.16d0cb1a68df6b8b24667b8e4900f6c5@haskell.org> References: <049.16d0cb1a68df6b8b24667b8e4900f6c5@haskell.org> Message-ID: <064.2005d6a139258fa03993d906cf6dae5e@haskell.org> #11563: fvProv falls into a hole (instead of detecting missing type argument) (regression from -rc1 to -rc2) -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11520, #11516, | Differential Rev(s): #11399 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by j.waldmann): * related: 11520, 11516, 11399 => #11520, #11516, #11399 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 20:23:15 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 20:23:15 -0000 Subject: [GHC] #11563: fvProv falls into a hole (instead of detecting missing type argument) (regression from -rc1 to -rc2) In-Reply-To: <049.16d0cb1a68df6b8b24667b8e4900f6c5@haskell.org> References: <049.16d0cb1a68df6b8b24667b8e4900f6c5@haskell.org> Message-ID: <064.42ae903c20891ad6e03247705796ff1c@haskell.org> #11563: fvProv falls into a hole (instead of detecting missing type argument) (regression from -rc1 to -rc2) -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11520, #11516, | Differential Rev(s): #11399 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): compared to the related tickets that I found when searching for "falls into a hole", this one here * uses no language extensions, has short source code * is a regression (of rc2 w.r.t. rc1) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 21:25:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 21:25:05 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.0add5546afc8662aa5b72f3a5e31de67@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Interesting. For sequences why would you say {{{ do { ... ; x <- e ; ... } }}} if you were just going to discard `x`? Can you give a particular example of a (plausible) program whose complexity becomes asymptotically better? I bet you have some in mind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 21:42:50 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 21:42:50 -0000 Subject: [GHC] #11564: Possible overzealous unfolding Message-ID: <047.2c6c2b843f6daaa097ae723c3d64a380@haskell.org> #11564: Possible overzealous unfolding -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 8.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 investigating why (>>=) in the Haxl monad is being inlined more than I would expect, and I ran into something I don't fully understand, and looks dubious. Start from this standalone example: {{{ {-# LANGUAGE ScopedTypeVariables, ExistentialQuantification #-} module Haxl where import Data.IORef import Control.Exception newtype GenHaxl u a = GenHaxl { unHaxl :: Int -> IORef () -> IO (Result u a) } data Result u a = Done a | Throw SomeException | Blocked (Cont u a) data Cont u a = forall b. Cont u b :>>= (b -> GenHaxl u a) | forall b. (b -> a) :<$> (Cont u b) instance Monad (GenHaxl u) where return a = GenHaxl $ \_env _ref -> return (Done a) GenHaxl m >>= k = GenHaxl $ \env ref -> do e <- m env ref case e of Done a -> unHaxl (k a) env ref Throw e -> return (Throw e) Blocked cont -> return (Blocked (cont :>>= k)) instance Functor (GenHaxl u) instance Applicative (GenHaxl u) }}} (it could be simplified further, but I've intentionally used the exact definition of `>>=` that is used in Haxl to be sure I'm not investigating the wrong thing) Compile like this: {{{ ghc -O -c Haxl.hs }}} and look at the .hi file: {{{ ghc --show-iface Haxl.hi }}} see this: {{{ ea159c3b107c307a4e76cd310efcc8bc $fMonadGenHaxl2 :: GenHaxl u a -> (a -> GenHaxl u b) -> Int -> IORef () -> State# RealWorld -> (# State# RealWorld, Result u b #) {- Arity: 5, HasNoCafRefs, Strictness: , Unfolding: InlineRule (5, True, False) (\ @ u @ a @ b (ds :: GenHaxl u a) (k :: a -> GenHaxl u b) (env :: Int) (ref :: IORef ()) (s :: State# RealWorld)[OneShot] -> case (ds `cast` (N:GenHaxl[0] _P _R) env ref) `cast` (N:IO[0] _R) s of ds1 { (#,#) ipv ipv1 -> case ipv1 of wild { Done a1 -> ((k a1) `cast` (N:GenHaxl[0] _P _R) env ref) `cast` (N:IO[0] _R) ipv Throw e -> (# ipv, Throw @ u @ b e #) Blocked cont -> (# ipv, Blocked @ u @ b (:>>= @ u @ b @ a cont k) #) } }) -} }}} That right there is the definition of `>>=`. Note that it has an `InlineRule`, which means that it will be unconditionally unfolded pretty much everywhere. I don't think this is right - there's no benefit to be had in inlining it unconditionally. I delved in a bit more, and it seems this unfolding arises during worker- wrapper. Before WW we have {{{ a_sVM [LclId, Arity=5, Str=DmdType , Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0 60 0 0 0] 94 60}] a_sVM = \ @ u_XQR @ a_aPN @ b_aPO ds_dQP [Dmd=] k_aEC env_aED ref_aEE s_aVC [Dmd=, OS=OneShot] -> case (((ds_dQP `cast` ...) env_aED ref_aEE) `cast` ...) s_aVC of _ [Occ=Dead, Dmd=] { (# ipv_aVF [Dmd=], ipv1_aVG [Dmd=] #) -> case ipv1_aVG of _ [Occ=Dead, Dmd=] { Done a_aEG -> ((((k_aEC a_aEG) `cast` ...) env_aED ref_aEE) `cast` ...) ipv_aVF; Throw e_aEH -> (# ipv_aVF, Haxl.Throw e_aEH #); Blocked cont_aEI -> (# ipv_aVF, Haxl.Blocked (Haxl.:>>= cont_aEI k_aEC) #) } } }}} and after WW we have {{{ a_sVM [LclId, Arity=5, Str=DmdType , Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=5,unsat_ok=True,boring_ok=False) Tmpl= \ @ u_XQR @ a_aPN @ b_aPO ds_dQP [Occ=Once] k_aEC [Occ=Once*] env_aED ref_aEE s_aVC [Occ=Once, OS=OneShot] -> case (((ds_dQP `cast` ...) env_aED ref_aEE) `cast` ...) s_aVC of _ [Occ=Dead] { (# ipv_aVF [Occ=Once*], ipv1_aVG [Occ=Once!] #) -> case ipv1_aVG of _ [Occ=Dead] { Done a_aEG [Occ=Once] -> ((((k_aEC a_aEG) `cast` ...) env_aED ref_aEE) `cast` ...) ipv_aVF; Throw e_aEH [Occ=Once] -> (# ipv_aVF, Haxl.Throw e_aEH #); Blocked cont_aEI [Occ=Once] -> (# ipv_aVF, Haxl.Blocked (Haxl.:>>= cont_aEI k_aEC) #) } }}] a_sVM = \ @ u_XQR @ a_aPN @ b_aPO ds_dQP [Dmd=] k_aEC env_aED ref_aEE s_aVC [Dmd=, OS=OneShot] -> case (((ds_dQP `cast` ...) env_aED ref_aEE) `cast` ...) s_aVC of _ [Occ=Dead, Dmd=] { (# ipv_aVF [Dmd=], ipv1_aVG [Dmd=] #) -> case ipv1_aVG of _ [Occ=Dead, Dmd=] { Done a_aEG -> ((((k_aEC a_aEG) `cast` ...) env_aED ref_aEE) `cast` ...) ipv_aVF; Throw e_aEH -> (# ipv_aVF, Haxl.Throw e_aEH #); Blocked cont_aEI -> (# ipv_aVF, Haxl.Blocked (Haxl.:>>= cont_aEI k_aEC) #) } } }}} For some unknown reason, this binding has acquired an always-on unfolding. There's no wrapper, we're just unfolding the whole thing. Simon, can you shed any light here? I would like to tune unfolding sizes to reduce code bloat in our codebase, but with this unfolding being unconditional it doesn't work to use `-funfolding-use-threshold`, I can only use `NOINLINE` but that's too blunt. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 21:44:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 21:44:39 -0000 Subject: [GHC] #11565: Restore code to handle '-fmax-worker-args' flag Message-ID: <045.9d241621de87bb494a516e9874327ca7@haskell.org> #11565: Restore code to handle '-fmax-worker-args' flag -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 i had a pass through DynFlags I've noticed dead code: https://phabricator.haskell.org/D1727 It was accidentally lost 3 years ago in major update changeset:0831a12ea2fc73c33652eeec1adc79fa19700578 The consensus is to try to put option handling back. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 21:48:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 21:48:25 -0000 Subject: [GHC] #11565: Restore code to handle '-fmax-worker-args' flag In-Reply-To: <045.9d241621de87bb494a516e9874327ca7@haskell.org> References: <045.9d241621de87bb494a516e9874327ca7@haskell.org> Message-ID: <060.a2e8c2c110a44180b992ed0cf0196dc7@haskell.org> #11565: Restore code to handle '-fmax-worker-args' flag -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 slyfox): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 21:57:58 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 21:57:58 -0000 Subject: [GHC] #11565: Restore code to handle '-fmax-worker-args' flag In-Reply-To: <045.9d241621de87bb494a516e9874327ca7@haskell.org> References: <045.9d241621de87bb494a516e9874327ca7@haskell.org> Message-ID: <060.4664eada25e0260512f0cfb0f7a4b5f9@haskell.org> #11565: Restore code to handle '-fmax-worker-args' flag -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: | -------------------------------------+------------------------------------- Description changed by slyfox: @@ -4,1 +4,1 @@ - It was accidentally lost 3 years ago in major update + maxWorkerArgs handling was accidentally lost 3 years ago in major update New description: When i had a pass through DynFlags I've noticed dead code: https://phabricator.haskell.org/D1727 maxWorkerArgs handling was accidentally lost 3 years ago in major update changeset:0831a12ea2fc73c33652eeec1adc79fa19700578 The consensus is to try to put option handling back. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 22:27:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 22:27:22 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.bcb732c8d49dd722b15db1cc0ceebb8c@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): You often do have to use {{{#!hs _ <- char ')' }}} just to avoid unused result warnings in things like parsers given a parser like {{{#!hs char :: Char -> Parser Char }}} Also, even if you just have do x; y in the ApplicativeDo encoding, nothing currently says that that will invoke (*>) over a manual expansion involving (<*>). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 22:33:40 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 22:33:40 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.4a46003a1859badd22e7a7ecb1b63e17@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): You understand this so much better than me. By "particular" example, I was hoping for an executable program that would run asymptotically faster under one desugaring vs the other. Or more simply, a program using `<*>` that would run asymptotically faster if we replaced that `<*>` with `*>`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 23:03:46 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 23:03:46 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.a1e9d43c719f3319ce9775f805ac9539@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Changes (by owst): * differential: => Phab:D1899 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 23:13:23 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 23:13:23 -0000 Subject: [GHC] #11564: Possible overzealous unfolding In-Reply-To: <047.2c6c2b843f6daaa097ae723c3d64a380@haskell.org> References: <047.2c6c2b843f6daaa097ae723c3d64a380@haskell.org> Message-ID: <062.bf9dcf5681a4a7defc033afe9b556651@haskell.org> #11564: Possible overzealous unfolding -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: high | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Here's the code in `WorkWrap.tryWW` {{{ | not loop_breaker , Just stable_unf <- certainlyWillInline dflags fn_unf = return [ (fn_id `setIdUnfolding` stable_unf, rhs) ] -- Note [Don't w/w inline small non-loop-breaker, or INLINE, things] -- NB: use idUnfolding because we don't want to apply -- this criterion to a loop breaker! }}} The note says {{{ Note [Don't w/w inline small non-loop-breaker things] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In general, we refrain from w/w-ing *small* functions, which are not loop breakers, because they'll inline anyway. But we must take care: it may look small now, but get to be big later after other inlining has happened. So we take the precaution of adding an INLINE pragma to any such functions. I made this change when I observed a big function at the end of compilation with a useful strictness signature but no w-w. (It was small during demand analysis, we refrained from w/w, and then got big when something was inlined in its rhs.) When I measured it on nofib, it didn't make much difference; just a few percent improved allocation on one benchmark (bspt/Euclid.space). But nothing got worse. }}} Also look at `certainlyWillInline`. Now, maybe the size calculation is bad, and is treating as small something that isn't small. The calculation in `certainlyWillInline` is saying, I think, that the size of the RHS is no bigger than the size of the call (i.e. `(arity+1)*10`). Does that help? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 23:20:47 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 23:20:47 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.85d9f22de10b25c1fb02e51bf86f6741@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by mfox): Thank you, but it doesn't work for me. I think there's an ABI difference between armv7 and armv8. All executables give: cannot execute binary file: Exec format error One approach I'm pursuing, there's an Ubuntu PPA that builds GHC nightlies. https://launchpad.net/~hvr If they were to enable arm64 builds then it would just happen. Supposedly, launchpad will do this if you just ask them so I'm trying to figure out how to ask them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 9 23:29:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 09 Feb 2016 23:29:06 -0000 Subject: [GHC] #11563: fvProv falls into a hole (instead of detecting missing type argument) (regression from -rc1 to -rc2) In-Reply-To: <049.16d0cb1a68df6b8b24667b8e4900f6c5@haskell.org> References: <049.16d0cb1a68df6b8b24667b8e4900f6c5@haskell.org> Message-ID: <064.9bd56ab08594d3242a5555c8f82517ec@haskell.org> #11563: fvProv falls into a hole (instead of detecting missing type argument) (regression from -rc1 to -rc2) -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11520, #11516, | Differential Rev(s): #11399 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): True; but #11520 has a complete diagnosis. I'll try the solution I propose there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 10 01:06:32 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Feb 2016 01:06:32 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.85e6a8522a482204033c17939810e226@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Armv7 and Armv8 are not just different ABIs, they are completely different architectures (different instructions set even). IN addition, however many problems there are with Armv7, the ones with Armv7 are significantly worse. Debian shipped a working ghc-7.8.4, but the current ghc-7.10.3 is completely busted due to a bug in LLVM that was never fixed. I've been using Debian's old ghc-7.8.4 to build the GHC 8.0 branch, but I currently cannot build Git HEAD because git head requires ghc-7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 10 01:17:56 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Feb 2016 01:17:56 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.4553767d8107c851137b4fdc7078680d@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by mfox): I don't know. I have built 7.10 on armv8 and it doesn't pass all tests but it's good enough to build 95% of stackage and I've just finished building HEAD and am about to test it. We're discussing it here: https://github.com/commercialhaskell/stack/issues/1755 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 10 02:29:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Feb 2016 02:29:16 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.1c26311e77d48583a972869df62e8cb3@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): @mfox Do you have a working ghc 7.10 on Arm64? The one from Debian fails for me with: {{{ 0 libLLVM-3.5.so.1 0x0000007f8703e458 llvm::sys::PrintStackTrace(_IO_FILE*) + 48 Stack dump: 0. Program arguments: llc-3.5 -O1 -relocation-model=static /tmp/ghcb9c5_0/ghc_64.bc -o /tmp/ghcb9c5_0/ghc_65.lm_s --enable- tbaa=true 1. Running pass 'Function Pass Manager' on module '/tmp/ghcb9c5_0/ghc_64.bc'. 2. Running pass 'Greedy Register Allocator' on function '@"cxOZ_entry$def"' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 10 08:35:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Feb 2016 08:35:58 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.bc107ec4ffc36d1cc498235cd8328b21@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11523 Blocked By: | Blocking: Related Tickets: #11480 | 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 Wed Feb 10 09:12:30 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Feb 2016 09:12:30 -0000 Subject: [GHC] #11564: Possible overzealous unfolding In-Reply-To: <047.2c6c2b843f6daaa097ae723c3d64a380@haskell.org> References: <047.2c6c2b843f6daaa097ae723c3d64a380@haskell.org> Message-ID: <062.6f84d5bba132668b0e91765915189645@haskell.org> #11564: Possible overzealous unfolding -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: high | 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Ok, I understand the reason, we're saying "this function is strict, but it's small enough to be inlined anyway so there's no point in worker/wrappering it, we'll just inline it instead." In my case here the size is 94 and the arity is 5, so it falls under the threshold. The calculation is a bit generous (I found a bug, diff coming soon), but even still there's something a bit wrong here. The problem is that we're deciding based on the value of `-funfolding-use-threshold` at the //definition// site, which means we can't use that flag to decide at the call site. Presumably we need the INLINE pragma because otherwise we might lose the opportunity to take advantage of the strictness. But what goes wrong if we make it an INLINABLE pragma instead? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 10 10:19:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Feb 2016 10:19:29 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDczNDogcHByaW50IG9mIOKAmGxldOKAmSBp?= =?utf-8?q?nside_=E2=80=98do=E2=80=99_prints_invalid_Haskell?= In-Reply-To: <047.198f0614ed38423766e17028c03c3aa7@haskell.org> References: <047.198f0614ed38423766e17028c03c3aa7@haskell.org> Message-ID: <062.a9fcc30e5e10415a5e833039b5133b72@haskell.org> #10734: pprint of ?let? inside ?do? prints invalid Haskell -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: johnleo Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: th/T10734.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2f9931e3536caa65e40f63f76be5f0d966180411/ghc" 2f9931e3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2f9931e3536caa65e40f63f76be5f0d966180411" add Template Haskell regression test for #9022. The bug itself has already been fixed in #10734, so this only adds another regression test (as given in the ticket). Test Plan: ./validate Reviewers: goldfire, austin, thomie, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1898 GHC Trac Issues: #9022 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 10 10:19:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Feb 2016 10:19:29 -0000 Subject: [GHC] #9022: TH pretty printer and GHC parser semicolon placement mismatch In-Reply-To: <047.5de523bade6a019122fff089f11b671b@haskell.org> References: <047.5de523bade6a019122fff089f11b671b@haskell.org> Message-ID: <062.2128cd1f4286a559f74127ab95be5a70@haskell.org> #9022: TH pretty printer and GHC parser semicolon placement mismatch -------------------------------------+------------------------------------- Reporter: roldugin | Owner: bollmann Type: bug | Status: patch Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.1 Resolution: | Keywords: newcomer 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:D1898 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2f9931e3536caa65e40f63f76be5f0d966180411/ghc" 2f9931e3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2f9931e3536caa65e40f63f76be5f0d966180411" add Template Haskell regression test for #9022. The bug itself has already been fixed in #10734, so this only adds another regression test (as given in the ticket). Test Plan: ./validate Reviewers: goldfire, austin, thomie, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1898 GHC Trac Issues: #9022 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 10 10:19:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Feb 2016 10:19:29 -0000 Subject: [GHC] #11558: Using Cabal 1.22 against GHC 8.0 results in unhelpful errors In-Reply-To: <046.d2616ea949ac4d1153655c6314ef5133@haskell.org> References: <046.d2616ea949ac4d1153655c6314ef5133@haskell.org> Message-ID: <061.cbcfbe1e2079d5faa7ede5b91be150bc@haskell.org> #11558: Using Cabal 1.22 against GHC 8.0 results in unhelpful errors -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Package system | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1892 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"d80caca10d7c2fa1c9ee8ef6bcafac365d02ff3d/ghc" d80caca/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d80caca10d7c2fa1c9ee8ef6bcafac365d02ff3d" Error early when you register with too old a version of Cabal. On the GHC 8.0 RCs, multiple users reported a very strange error whereby GHC would complain that the symbols names recorded in interface files did not match the expected name. The reason for this is that they were using an old version of Cabal which chose symbol names differently from the installed package ID ('id' field) which the package was to be installed with; GHC 8.0 now mandates that these coincides. This change adds a test to ghc-pkg to make sure that 'id' and 'key' (which is how Cabal previously reported what the symbol name was supposed to be) match; if they don't match or key is missing, we assume that the Cabal was too old. Bikeshed points: - Should we offer more information about how to upgrade Cabal correctly (i.e. specify a version?) - Should we allow for a missing 'key'? If we allow for 'key' to be missing, we lose the ability to detect Cabal from GHC 7.8 or earlier being used. If we require it to be specified, then it will not be possible for Cabal to deprecate the (unused) field and remove it without having BC for 8.0. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: austin, bgamari, hvr Reviewed By: hvr Subscribers: bergmark, thomie Differential Revision: https://phabricator.haskell.org/D1892 GHC Trac Issues: #11558 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 10 10:19:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Feb 2016 10:19:29 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.8fb404528d170659c888e9a8839a96bc@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"93e2c8fff902c12fd22d907f7648d847ebfd2146/ghc" 93e2c8ff/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="93e2c8fff902c12fd22d907f7648d847ebfd2146" Expand users' guide TH declaration groups section (#9813) Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1899 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 10 10:30:00 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Feb 2016 10:30:00 -0000 Subject: [GHC] #11558: Using Cabal 1.22 against GHC 8.0 results in unhelpful errors In-Reply-To: <046.d2616ea949ac4d1153655c6314ef5133@haskell.org> References: <046.d2616ea949ac4d1153655c6314ef5133@haskell.org> Message-ID: <061.9ae0a05759dc569a9c5d2320e674df40@haskell.org> #11558: Using Cabal 1.22 against GHC 8.0 results in unhelpful errors -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Package system | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1892 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): GHC should now produce an error resembling, {{{ PROG: installed package info from too old version of Cabal (key field does not match id field) }}} when invoked by an older Cabal. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 10 11:07:05 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Feb 2016 11:07:05 -0000 Subject: [GHC] #11564: Possible overzealous unfolding In-Reply-To: <047.2c6c2b843f6daaa097ae723c3d64a380@haskell.org> References: <047.2c6c2b843f6daaa097ae723c3d64a380@haskell.org> Message-ID: <062.b6c297999479a1e74794011fb8372257@haskell.org> #11564: Possible overzealous unfolding -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: high | 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:D1900 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * differential: => Phab:D1900 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 10 11:26:16 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Feb 2016 11:26:16 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.9d20ac65b7cd5be68531696e1cd0c662@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by owst): Apologies that it took me so long from saying I'll make the user guide changes to actually making them; thanks for the nudge thomie! Having made the doc changes, I'm still not satisfied about the {{{$(return [])}}} solution and I'd definitely like to try to attempt to make the "reasonable" use case work. To be clear, consider: {{{ data A = A f :: Int -> Int f x = x + 1 data B = B C g1 :: Int -> Int g1 x = 1 + g2 x exprContainingSplice1 = $(...) data C = C g2 :: Int -> Int g2 x = x + 2 exprContainingSplice2 = $(...) }}} Naively, I'd expect the splice in {{{ exprContainingSplice1 }}} to be able to refer to {{{A}}} and {{{f}}}, but ''not'' {{{B}}} or {{{g1}}}, since they are in some sense "not fully defined" at the point the splice is encountered (assuming a top-to-bottom processing, rather than some topological-sorted graph-traversal). I'd also expect the splice in {{{ exprContainingSplice2 }}} to be able to able to refer to all functions and and data types except probably(?) {{{exprContainingSplice1}}} and {{{exprContainingSplice2}}}. Can this be made to work, or is it nonsense? Simon's earlier comment > Moreover, types declarations are (reliably) typechecked before values decls. Worth looking into. intrigues me - I think he suggests that it might be possible for a splice in {{{ exprContainingSplice1 }}} to refer to {{{A}}}, but not {{{f}}}? If it is likely to be at all possible, does anyone have any pointers of likely starting points/functions I should definitely explore etc. I'd like to get my hands dirty! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 10 14:32:30 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Feb 2016 14:32:30 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.3ff99f567a089180a8b33c903cf5b15f@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by mfox): Somehow mine works. I put it here: https://s3-us-west-1.amazonaws.com /stack-aarch64/ghc-7.10.3-aarch64-unknown-linux.tar.bz2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 10 14:32:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Feb 2016 14:32:42 -0000 Subject: [GHC] #11520: GHC falls into a hole if given incorrect kind signature In-Reply-To: <046.a2116e67b07177218d33d38f3453d162@haskell.org> References: <046.a2116e67b07177218d33d38f3453d162@haskell.org> Message-ID: <061.733a07767c42bc73bc95122bc1081107@haskell.org> #11520: GHC falls into a hole if given incorrect kind signature -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b565830dda0994d5d67617039db3310f81e831c8/ghc" b565830d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b565830dda0994d5d67617039db3310f81e831c8" Wrap solveEqualities in checkNoErrs This simple change fixes Trac #11563, #11520, #11516, #11399. See esp the comments in #11520. See Note [Fail fast on kind errors] in TcSimplify Merge to 8.0 branch }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 10 14:32:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Feb 2016 14:32:42 -0000 Subject: [GHC] #11399: Ill-kinded instance head involving -XTypeInType can invoke GHC panic In-Reply-To: <050.fa5529f380365cfe4744b03407d72fc7@haskell.org> References: <050.fa5529f380365cfe4744b03407d72fc7@haskell.org> Message-ID: <065.2827e36ff6f8f59ec972301092b5c7d5@haskell.org> #11399: Ill-kinded instance head involving -XTypeInType can invoke GHC panic -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b565830dda0994d5d67617039db3310f81e831c8/ghc" b565830d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b565830dda0994d5d67617039db3310f81e831c8" Wrap solveEqualities in checkNoErrs This simple change fixes Trac #11563, #11520, #11516, #11399. See esp the comments in #11520. See Note [Fail fast on kind errors] in TcSimplify Merge to 8.0 branch }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 10 14:32:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Feb 2016 14:32:42 -0000 Subject: [GHC] #11563: fvProv falls into a hole (instead of detecting missing type argument) (regression from -rc1 to -rc2) In-Reply-To: <049.16d0cb1a68df6b8b24667b8e4900f6c5@haskell.org> References: <049.16d0cb1a68df6b8b24667b8e4900f6c5@haskell.org> Message-ID: <064.876d80bcf365b395fd5cd41a63c33817@haskell.org> #11563: fvProv falls into a hole (instead of detecting missing type argument) (regression from -rc1 to -rc2) -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11520, #11516, | Differential Rev(s): #11399 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b565830dda0994d5d67617039db3310f81e831c8/ghc" b565830d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b565830dda0994d5d67617039db3310f81e831c8" Wrap solveEqualities in checkNoErrs This simple change fixes Trac #11563, #11520, #11516, #11399. See esp the comments in #11520. See Note [Fail fast on kind errors] in TcSimplify Merge to 8.0 branch }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 10 14:32:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Feb 2016 14:32:42 -0000 Subject: [GHC] #11516: Panic, "falls into a hole" In-Reply-To: <051.f6bcca55b0b02654ebc7a8da6d28be6c@haskell.org> References: <051.f6bcca55b0b02654ebc7a8da6d28be6c@haskell.org> Message-ID: <066.f592a5422940abeb918baed3153a19ee@haskell.org> #11516: Panic, "falls into a hole" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | typecheck/should_compile/T11516 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b565830dda0994d5d67617039db3310f81e831c8/ghc" b565830d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b565830dda0994d5d67617039db3310f81e831c8" Wrap solveEqualities in checkNoErrs This simple change fixes Trac #11563, #11520, #11516, #11399. See esp the comments in #11520. See Note [Fail fast on kind errors] in TcSimplify Merge to 8.0 branch }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 10 15:21:28 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Feb 2016 15:21:28 -0000 Subject: [GHC] #11526: unsafeLookupStaticPtr should not live in IO In-Reply-To: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> References: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> Message-ID: <059.9d72ea7fc9450a9f2f37b116993a141e@haskell.org> #11526: unsafeLookupStaticPtr should not live in IO -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mboes): Replicating here for the record my earlier email, which from my mobile phone originally went to ghc-dev@ instead: > IMHO this dynamic linking thing is a red herring. In principle any function call becomes potentially impure given eg the ability to shadow symbols. In practice that's not something we do to programs. We could consider having two tables though: an initial tackle generated at compile time that will never change, and an aux table populated as new objects get linked in. Then programs can "opt in" to taking into account new objects loaded dynamically by reading (in IO) the aux table. A followup - I think a reasonable compromise here is simply to have: {{{ -- | Lookup in a static table constructed at compile time. unsafeLookupStaticPtr :: StaticKey -> Maybe (StaticPtr a) -- | Lookup in the static table + an aux table that's initially empty but may grow if objects are dynamically loaded. unsafeLookupStaticPtrDL :: StaticKey -> IO (Maybe (StaticPtr a)) }}} The idea is: bake in a static table at compile time that is immutable for all time; any new static pointers that get loaded at runtime (i.e. are not reachable from `main` at the start of the program) go into a separate table, which can only be accessed via `unsafeLookupStaticPtrDL`. Most programs will never use `unsafeLookupStaticPtrDL`. That way it becomes possible to define a `Binary` instance, but also address Facundo's concerns about dynamically loaded objects. I don't anticipate anyone will have time to implement the `*DL` stuff ahead of GHC 8.0, but that doesn't prevent us from moving `unsafeLookupStaticPtr` out of IO now. For the the DL table to be useful we'd have to populate it upon object load somehow, likely via so-called "constructor functions". Maybe someone with that use case wants to give it a crack (in a separate ticket). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 10 15:30:50 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Feb 2016 15:30:50 -0000 Subject: [GHC] #11563: fvProv falls into a hole (instead of detecting missing type argument) (regression from -rc1 to -rc2) In-Reply-To: <049.16d0cb1a68df6b8b24667b8e4900f6c5@haskell.org> References: <049.16d0cb1a68df6b8b24667b8e4900f6c5@haskell.org> Message-ID: <064.ec04d5a6a43fff9e67e8e40b14a45758@haskell.org> #11563: fvProv falls into a hole (instead of detecting missing type argument) (regression from -rc1 to -rc2) -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T11563 Blocked By: | Blocking: Related Tickets: #11520, #11516, | Differential Rev(s): #11399 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => typecheck/should_fail/T11563 Comment: Ha! One fix closes four tickets. Merge to 8.0 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 10 15:31:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Feb 2016 15:31:21 -0000 Subject: [GHC] #11399: Ill-kinded instance head involving -XTypeInType can invoke GHC panic In-Reply-To: <050.fa5529f380365cfe4744b03407d72fc7@haskell.org> References: <050.fa5529f380365cfe4744b03407d72fc7@haskell.org> Message-ID: <065.f42e28d69328dabd14287bd275186bdc@haskell.org> #11399: Ill-kinded instance head involving -XTypeInType can invoke GHC panic -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | polykinds/T11399 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => polykinds/T11399 * status: new => merge Comment: Ha! One fix closes four tickets. Merge to 8.0 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 10 15:32:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Feb 2016 15:32:27 -0000 Subject: [GHC] #11516: Panic, "falls into a hole" In-Reply-To: <051.f6bcca55b0b02654ebc7a8da6d28be6c@haskell.org> References: <051.f6bcca55b0b02654ebc7a8da6d28be6c@haskell.org> Message-ID: <066.e5152069a82c62e3e11d62789321d3b2@haskell.org> #11516: Panic, "falls into a hole" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | polykinds/T11516 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: typecheck/should_compile/T11516 => polykinds/T11516 * status: new => merge Comment: Ha! One fix closes four tickets. Merge to 8.0 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 10 15:33:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Feb 2016 15:33:01 -0000 Subject: [GHC] #11520: GHC falls into a hole if given incorrect kind signature In-Reply-To: <046.a2116e67b07177218d33d38f3453d162@haskell.org> References: <046.a2116e67b07177218d33d38f3453d162@haskell.org> Message-ID: <061.89efe5454a5d4051a4dfd3914293ce1d@haskell.org> #11520: GHC falls into a hole if given incorrect kind signature -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | polykinds/T11520 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => polykinds/T11520 Comment: Ha! That worked. One fix closes four tickets. Merge to 8.0 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 10 16:52:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Feb 2016 16:52:45 -0000 Subject: [GHC] #11526: unsafeLookupStaticPtr should not live in IO In-Reply-To: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> References: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> Message-ID: <059.552b022579e93f4efa90b4da74159264@haskell.org> #11526: unsafeLookupStaticPtr should not live in IO -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): Currently all static names in a statically linked module are inserted in the SPT before the program starts executing main. When the module is loaded dynamically, the static names are inserted at load time. Making {{{unsafeLookupStaticPtr}}} pure will require changing the implementation so linking modules dynamically do not modify the SPT. It will also require doing something so the table is available when the function is used in (code loaded in) GHCi, unless nobody cares of breaking that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 10 17:49:31 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Feb 2016 17:49:31 -0000 Subject: [GHC] #11526: unsafeLookupStaticPtr should not live in IO In-Reply-To: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> References: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> Message-ID: <059.d5fc80fd17338480215708ead00e3d6f@haskell.org> #11526: unsafeLookupStaticPtr should not live in IO -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Replying to [comment:8 mboes]: > I think a reasonable compromise here is simply to have: > > {{{ > -- | Lookup in a static table constructed at compile time. > unsafeLookupStaticPtr :: StaticKey -> Maybe (StaticPtr a) > > -- | Lookup in the static table + an aux table that's initially empty but may grow if objects are dynamically loaded. > unsafeLookupStaticPtrDL :: StaticKey -> IO (Maybe (StaticPtr a)) > }}} This is the approach we take in the `OpenGLRaw` package for detecting extensions. Yes, technically you ''might'' switch OpenGL contexts and change which ones are available over the life of a program, it isn't the common case, while branching on them is very common and is made nigh unusable, and needlessly slow, since they can't memoize this information if they are stuck in IO. One of hundreds of such examples: http://hackage.haskell.org/package/OpenGLRaw-3.1.0.0/docs/Graphics-GL-ARB- CullDistance.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 10 18:43:28 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 10 Feb 2016 18:43:28 -0000 Subject: [GHC] #11526: unsafeLookupStaticPtr should not live in IO In-Reply-To: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> References: <044.f93a21b1835068cb7ee01f72ff1b48c6@haskell.org> Message-ID: <059.ff798a6da1414aded47bfffd64730c00@haskell.org> #11526: unsafeLookupStaticPtr should not live in IO -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mboes): Replying to [comment:5 simonpj]: > Hmm. I'm deeply suspicious of `StaticKey`. It plays no role in our plan of record [wiki:StaticPointers]. FTR the reason we have StaticKey (i.e. just Fingerprint, nothing new) is to avoid hardcoding encoding/decoding of static pointers in the compiler. Encoding/decoding is `binary`'s business, or any other package. Patrick Mayer in particular was keen to minimize message size in his use cases to the bare minimum, say by maintaining himself a perfect hash for fingerprints and hence sending only a small integer across the wire. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 11 10:38:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Feb 2016 10:38:42 -0000 Subject: [GHC] #11562: WARNING: file compiler/stgSyn/CoreToStg.hs, line 250: $fCategoryConstraint:- True False In-Reply-To: <045.f6b21c47cfe1e3756485cde13f1c62ac@haskell.org> References: <045.f6b21c47cfe1e3756485cde13f1c62ac@haskell.org> Message-ID: <060.591dbd770b1a48e9d1df84d6097fdbe8@haskell.org> #11562: WARNING: file compiler/stgSyn/CoreToStg.hs, line 250: $fCategoryConstraint:- True False -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"850085555a1103810d57f0d9835f4d525fd8ec00/ghc" 85008555/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="850085555a1103810d57f0d9835f4d525fd8ec00" Always do eta-reduction See Note [Eta-reduction in -O0] in DynFlags. Bottom line: doing eta reduction unconditionally is benign, and removes an ASSERT failure (Trac #11562). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 11 10:43:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Feb 2016 10:43:27 -0000 Subject: [GHC] #11562: WARNING: file compiler/stgSyn/CoreToStg.hs, line 250: $fCategoryConstraint:- True False In-Reply-To: <045.f6b21c47cfe1e3756485cde13f1c62ac@haskell.org> References: <045.f6b21c47cfe1e3756485cde13f1c62ac@haskell.org> Message-ID: <060.778423c53d96697a74819c965a227644@haskell.org> #11562: WARNING: file compiler/stgSyn/CoreToStg.hs, line 250: $fCategoryConstraint:- True False -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | simplCore/should_compile/T11562 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => simplCore/should_compile/T11562 * resolution: => fixed Comment: Thanks for a nice small example. The failure was benign (so barely worth merging to 8.0) but the fix is easy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 11 11:43:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Feb 2016 11:43:56 -0000 Subject: [GHC] #11566: I don't need madvise DONT_NEED Message-ID: <043.ae7447db31f335ef6697823ae5dfc604@haskell.org> #11566: I don't need madvise DONT_NEED -------------------------------------+------------------------------------- Reporter: mfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Linux Architecture: aarch64 | Type of failure: Incorrect | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Many tests fail because of a warning in rts/posix/OSMem.c unable to decommit memory: function not implemented The reason it says "function not implemented" is that the function madvise(..., DONT_NEED) is not implemented. This is on a stock Ubuntu LTS 14.04 machine. The only interesting thing about it is that it's running on a pre-production armv8 processor with a beta 4.2 guest kernel. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 11 11:57:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Feb 2016 11:57:18 -0000 Subject: [GHC] #11519: Inferring non-tau kinds In-Reply-To: <047.4d7c879b01fe33a75f5e9304ccb4f8c9@haskell.org> References: <047.4d7c879b01fe33a75f5e9304ccb4f8c9@haskell.org> Message-ID: <062.608f86fd23b67a77ccc271d436269557@haskell.org> #11519: Inferring non-tau kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 bgamari): Just to confirm: explicit instance foralls will be a an 8.2 feature and should not be merged to 8.0.1, correct? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 11 12:30:54 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Feb 2016 12:30:54 -0000 Subject: [GHC] #11567: Haddock renders wired-in types with kind signature Message-ID: <046.9da84f84610001ab70d0d61e4b2e51a9@haskell.org> #11567: Haddock renders wired-in types with kind signature -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Documentation | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Lifted wired-in types seem to be rendered with an unnecessary `TYPE 'Lifted` kind signature. See, for instance, [https://downloads.haskell.org/~ghc/8.0.1-rc2/docs/html/libraries/base-4.9.0.0/Prelude.html#t:Bool|`Bool`]. I'm not yet sure whether this is a ghc or haddock issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 11 14:33:17 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Feb 2016 14:33:17 -0000 Subject: [GHC] #11519: Inferring non-tau kinds In-Reply-To: <047.4d7c879b01fe33a75f5e9304ccb4f8c9@haskell.org> References: <047.4d7c879b01fe33a75f5e9304ccb4f8c9@haskell.org> Message-ID: <062.8a16ab94beee333da9351c0aa0eaeb48@haskell.org> #11519: Inferring non-tau kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 do not feel strongly -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 11 14:55:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Feb 2016 14:55:38 -0000 Subject: [GHC] #11564: Possible overzealous unfolding In-Reply-To: <047.2c6c2b843f6daaa097ae723c3d64a380@haskell.org> References: <047.2c6c2b843f6daaa097ae723c3d64a380@haskell.org> Message-ID: <062.a4ff17f4fda0df3c7ea17b00e2ccd982@haskell.org> #11564: Possible overzealous unfolding -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: new Priority: high | 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:D1900 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"51a33924fc118d9b6c1db556c75c0d010ef95e18/ghc" 51a3392/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="51a33924fc118d9b6c1db556c75c0d010ef95e18" sizeExpr: fix a bug in the size calculation There were two bugs here: * We weren't ignoring Cast in size_up_app * An application of a non-variable wasn't being charged correct The result was that some things looked too cheap. In my case I had things like ((f x) `cast` ...) y which was given size 21 instead of 30, and this had knock-on effects elsewhere that caused some large code bloat. Test Plan: * nofib runs (todo) * validate Reviewers: simonpj, austin, bgamari, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1900 GHC Trac Issues: #11564 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 11 14:59:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Feb 2016 14:59:58 -0000 Subject: [GHC] #11454: Do not suggest deprecated flags In-Reply-To: <045.65a0f03026a0fefacb4854cc40024538@haskell.org> References: <045.65a0f03026a0fefacb4854cc40024538@haskell.org> Message-ID: <060.b2f4343b540fdc35fb51ec8eb3639637@haskell.org> #11454: Do not suggest deprecated flags -------------------------------------+------------------------------------- Reporter: thomie | Owner: nkartashov Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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:D1883 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"46af6835ac68d104ee56c29afdfa523c165db2fb/ghc" 46af6835/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="46af6835ac68d104ee56c29afdfa523c165db2fb" compiler: Do not suggest nor complete deprecated flags fix trac issue #11454 Previously, all flags were present in user suggest and completion. This commit removes the deprecated ones from there. It is done by saving deprecation info at the moment of flag definition. Reviewers: rwbarton, austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D1883 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 11 15:04:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Feb 2016 15:04:50 -0000 Subject: [GHC] #11568: Regression in nofib/shootout/k-nucleotide Message-ID: <047.d9404b64e39ef5028df3b630d601b854@haskell.org> #11568: Regression in nofib/shootout/k-nucleotide -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Fixing the `sizeExpr` bug in #11564 caused a regression in `nofib/shootout/k-nucleotide`. We don't know yet exactly which function was affected. See Phab:D1900 for details and some `-ddump-simpl` and `-ticky` dumps. We should investigate this before merging Phab:D1900 into a release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 11 15:05:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Feb 2016 15:05:58 -0000 Subject: [GHC] #11564: Possible overzealous unfolding In-Reply-To: <047.2c6c2b843f6daaa097ae723c3d64a380@haskell.org> References: <047.2c6c2b843f6daaa097ae723c3d64a380@haskell.org> Message-ID: <062.69f0cde66ada38db7784bc4234180208@haskell.org> #11564: Possible overzealous unfolding -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: merge Priority: high | 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:D1900 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => merge Comment: I pushed the fix and opened #11568 for the regression. We may want to merge, but we should understand the regression before doing so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 11 15:42:02 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Feb 2016 15:42:02 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.98a627483bf993a79f228deb89bbc212@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): There's two separate questions at work here: 1. Is there a rule that humans can understand and apply easily telling these humans what is available for reification at a certain splice? 2. Is the rule proposed in (1) implementable? I'm worried about tackling (2) before nailing (1). It sounds like you're suggesting a rule such as this: A. All declarations appearing above a splice such that all dependencies of the declaration are also above the splice are available. I don't love this rule, because it takes declaration order into account in a non-trivial way. Haskellers tend not to worry about top-to-bottom ordering. (Of course, we already violate this convention with top-level splices.) But maybe others like this rule and think it's easy enough. But then what about B. All declarations that do not depend on any splice are in scope for all splices. This is a different rule than the first. Is it easier to understand? According to Simon's suggestion, we might consider C. All types (as broken up by top-level splices) are available for all splices, but functions are available only according to the top-to-bottom rule around top-level splices. I think any of these rules might be implementable. But what's best? Let's settle on a design that can be simply stated and understood before worrying about implementation. Another way of saying this: let's get our brains dirty before we get our hands dirty. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 11 16:51:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Feb 2016 16:51:28 -0000 Subject: [GHC] #11454: Do not suggest deprecated flags In-Reply-To: <045.65a0f03026a0fefacb4854cc40024538@haskell.org> References: <045.65a0f03026a0fefacb4854cc40024538@haskell.org> Message-ID: <060.f80653bf2c1499a236e0842c463ec07b@haskell.org> #11454: Do not suggest deprecated flags -------------------------------------+------------------------------------- Reporter: thomie | Owner: nkartashov Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 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: | Differential Rev(s): Phab:D1883 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * failure: None/Unknown => Incorrect warning at compile-time * resolution: => fixed * milestone: => 8.0.1 Comment: This was also merged to `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 11 17:00:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Feb 2016 17:00:28 -0000 Subject: [GHC] #11567: Haddock renders wired-in types with kind signature In-Reply-To: <046.9da84f84610001ab70d0d61e4b2e51a9@haskell.org> References: <046.9da84f84610001ab70d0d61e4b2e51a9@haskell.org> Message-ID: <061.98fae5be25d3f5b7549b240fea64975c@haskell.org> #11567: Haddock renders wired-in types with kind signature -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Documentation | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: goldfire (added) Comment: The [https://downloads.haskell.org/~ghc/8.0.1-rc2/docs/html/libraries/base-4.9.0.0 /Data-Proxy.html|instance list] of `Proxy` has similar issues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 11 17:04:59 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Feb 2016 17:04:59 -0000 Subject: [GHC] #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. In-Reply-To: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> References: <045.d4380bf1adf1df9e0c96b4a3ede582ad@haskell.org> Message-ID: <060.49d891da6a0396916219d96cb0631933@haskell.org> #11523: Infinite Loop when mixing UndecidableSuperClasses and the class/instance constraint synonym trick. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: fixed | UndecidableSuperClasses Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | polykinds/T11523 Blocked By: | Blocking: Related Tickets: #11480 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: This was merged in aa830b1e709bb65353045e27f163ace4752da265. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 11 17:09:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Feb 2016 17:09:57 -0000 Subject: [GHC] #11533: Stack check not optimized out even if it could be In-Reply-To: <046.6d5f7866bf619f9b74b6c94e89479ca9@haskell.org> References: <046.6d5f7866bf619f9b74b6c94e89479ca9@haskell.org> Message-ID: <061.a74137cecc1ef422388c2fbdd91c303a@haskell.org> #11533: Stack check not optimized out even if it could be -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 (CodeGen) | Resolution: fixed | Keywords: cmm Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1881 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged in d0b4eade3410a09459c4c101546f58e06f9aebcc -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 11 17:10:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Feb 2016 17:10:27 -0000 Subject: [GHC] #11530: Make fails on systems with GREP_OPTIONS In-Reply-To: <047.65eb2c1162c4e0a77b27714fb3375078@haskell.org> References: <047.65eb2c1162c4e0a77b27714fb3375078@haskell.org> Message-ID: <062.4b7a1c03dbce13c63f62b0f0c6ed1a7e@haskell.org> #11530: Make fails on systems with GREP_OPTIONS -------------------------------------+------------------------------------- Reporter: alexlegg | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: POSIX | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1887 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged in ac0732ff36280b99f53a30ee6ecf0ce2e5eee60a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 11 17:10:45 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Feb 2016 17:10:45 -0000 Subject: [GHC] #11399: Ill-kinded instance head involving -XTypeInType can invoke GHC panic In-Reply-To: <050.fa5529f380365cfe4744b03407d72fc7@haskell.org> References: <050.fa5529f380365cfe4744b03407d72fc7@haskell.org> Message-ID: <065.ce400ad9acadc38b3e4f681b3f38b727@haskell.org> #11399: Ill-kinded instance head involving -XTypeInType can invoke GHC panic -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | polykinds/T11399 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 11 17:37:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Feb 2016 17:37:50 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.f6f301fc9b75d1b6ecbbbbeb28171a58@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: skvadrik Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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:D1902 Wiki Page: | -------------------------------------+------------------------------------- Changes (by skvadrik): * differential: Phab:D1888 => Phab:D1902 Comment: Replying to [comment:27 simonpj]: > I'm fine with a better error message. > > It would be Much Better if the "note" part only came out if there ''actually was'' a type constructor `(%%)` in scope. And that should be easy to check. Done, please have a look at D1902. Message example: {{{ Not in scope: ?-.->? Note: use ?type? keyword to export type constructor ?-.->? defined at T11432.hs:9:1 (requires TypeOperators extension) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 11 17:42:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Feb 2016 17:42:23 -0000 Subject: [GHC] #11520: GHC falls into a hole if given incorrect kind signature In-Reply-To: <046.a2116e67b07177218d33d38f3453d162@haskell.org> References: <046.a2116e67b07177218d33d38f3453d162@haskell.org> Message-ID: <061.f17c407ecea72905b4b0c8b589d4e55d@haskell.org> #11520: GHC falls into a hole if given incorrect kind signature -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | polykinds/T11520 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as d0010d749f80b405f991e88e0e953a21d54a744d -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 11 17:44:09 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Feb 2016 17:44:09 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.bb5d2c54c3dbc79cc7b80aea3811f79f@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by Bartosz Nitka ): In [changeset:"dbf72dbc6e49b3db7f2337a7a41e95c1d0169163/ghc" dbf72dbc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="dbf72dbc6e49b3db7f2337a7a41e95c1d0169163" Build the substitution correctly in piResultTy This fixes a bug where piResultTy created substitutions that would violate both of the invariants in Note [The substitution invariant]. Test Plan: ./validate --slow Reviewers: goldfire, simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: simonmar, thomie Differential Revision: https://phabricator.haskell.org/D1855 GHC Trac Issues: #11371 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 11 20:04:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Feb 2016 20:04:58 -0000 Subject: [GHC] #11473: Levity polymorphism checks are inadequate In-Reply-To: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> References: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> Message-ID: <061.866b7b0c826a75115b86566fc168f1d8@haskell.org> #11473: Levity polymorphism checks are inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): What happens with let-bound variables of polymorphic representation? Surely we can't allow this: {{{ {-# LANGUAGE TypeInType, ScopedTypeVariables #-} import GHC.Types app :: forall (l :: Levity) (a :: *) (b :: TYPE l). (a -> b) -> a -> b app f x = let y :: b y = undefined in f x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 11 22:59:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Feb 2016 22:59:13 -0000 Subject: [GHC] #9386: GHCi cannot load .so in ./ In-Reply-To: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> References: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> Message-ID: <062.bc61f30542719e77c9463a55059d7607@haskell.org> #9386: GHCi cannot load .so in ./ -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D593 Wiki Page: | -------------------------------------+------------------------------------- Comment (by crockeea): Did the patch ever get merged? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 11 23:30:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Feb 2016 23:30:57 -0000 Subject: [GHC] #11557: Unbundle Cabal from GHC In-Reply-To: <045.7d711249cd9c8cedc606277ad69f7e88@haskell.org> References: <045.7d711249cd9c8cedc606277ad69f7e88@haskell.org> Message-ID: <060.4f482f1cd5c850676c9a239c36b9a6c7@haskell.org> #11557: Unbundle Cabal from GHC -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: libraries | Version: 8.1 (other) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): > ghc-pkg would have to be statically linked That should be a matter of setting `utils/ghc-pkg_dist-install_PROGRAM_WAY = v` in `utils/ghc-pkg/ghc.mk`, and probably removing the `utils/ghc- pkg_dist-install_SHELL_WRAPPER` and `utils/ghc-pkg_dist- install_INSTALL_SHELL_WRAPPER_NAME` settings. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 11 23:34:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Feb 2016 23:34:26 -0000 Subject: [GHC] #11559: Building a cross-compiler for MIPS target on Mac OS X host fails In-Reply-To: <050.6c95ef109504726bb3b81a6b68c92e68@haskell.org> References: <050.6c95ef109504726bb3b81a6b68c92e68@haskell.org> Message-ID: <065.f32d36cb545529558fff08b07cc59679@haskell.org> #11559: Building a cross-compiler for MIPS target on Mac OS X host fails -------------------------------------+------------------------------------- Reporter: wereHamster | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #10456 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #10456 Comment: The second issue sounds like #10456, which has an in-progress patch in Phab:D998. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 11 23:52:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 11 Feb 2016 23:52:46 -0000 Subject: [GHC] #11568: Regression in nofib/shootout/k-nucleotide In-Reply-To: <047.d9404b64e39ef5028df3b630d601b854@haskell.org> References: <047.d9404b64e39ef5028df3b630d601b854@haskell.org> Message-ID: <062.db681b85030542d4c7636c62bb6c8cc0@haskell.org> #11568: Regression in nofib/shootout/k-nucleotide -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): [https://perf.haskell.org/ghc/#revision/51a33924fc118d9b6c1db556c75c0d010ef95e18 perf.haskell.org] reports the following numbers as well: {{{ Benchmark name previous change now tests/alloc/T3064 297834384 + 3.18% 307311896 bytes tests/alloc/T5631 1164415992 + 108.27% 2425081664 bytes tests/alloc/T7257 1654893352 - 14.50% 1414893352 bytes tests/alloc/T783 489042024 + 3.47% 505987776 bytes tests/alloc/T9020 703211744 + 16.45% 818924416 bytes tests/alloc/T9872d 535824528 + 3.09% 552399688 bytes tests/alloc/T9961 731573736 + 5.10% 768861280 bytes tests/alloc/haddock.Cabal 10472403176 + 4.52% 10945830216 bytes tests/alloc/haddock.compiler 59679619080 + 4.56% 62402376816 bytes }}} Links to: #3064, #5631, #783, #9020, #9872, #9961. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 00:10:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 00:10:26 -0000 Subject: [GHC] #11533: Stack check not optimized out even if it could be In-Reply-To: <046.6d5f7866bf619f9b74b6c94e89479ca9@haskell.org> References: <046.6d5f7866bf619f9b74b6c94e89479ca9@haskell.org> Message-ID: <061.2a05be1bee32959e3b665e62143c2ef5@haskell.org> #11533: Stack check not optimized out even if it could be -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 (CodeGen) | Resolution: fixed | Keywords: cmm Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1881 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): For the record, [https://perf.haskell.org/ghc/#revision/4ec61411930495fc109be27993c176fd7aaf486d perf.haskell.org] reports: {{{ nofib/time/fannkuch-redux 2.727 + 4.66% 2.854 seconds }}} On Phab, Jonas said: "I think nofib contained maybe between 20 and 40 cases where the the stack check was incorrectly not dropped. I could not measure a performance difference, but binary size decreased by a few bytes (as one would expect)" `fannkuch-redux` has been investigated for performance regressions before: #7367, #10457, #10677, #10844, https://phabricator.haskell.org/rGHCb949c96b4960. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 00:14:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 00:14:28 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.79a6ec80c1b69b5ebedc2b2c95cc8550@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by thomie): [https://perf.haskell.org/ghc/#revision/dbf72dbc6e49b3db7f2337a7a41e95c1d0169163 perf.haskell.org] reports for that last commit: {{{ testsuite/unexpected stats 3 + 3 6 tests Testsuite allocations Benchmark name previous change now tests/alloc/T5030 691938256 + 17.33% 811867344 bytes tests/alloc/T9872a 3477263608 + 4.63% 3638155736 bytes tests/alloc/T9872b 4984017672 + 5.75% 5270795992 bytes tests/alloc/T9872c 4507661800 + 6.50% 4800521096 bytes }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 01:45:38 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 01:45:38 -0000 Subject: [GHC] #10965: GHC Panic on import with 'OPTIONS_GHC -fobject-code -O' In-Reply-To: <044.d2359d5edaaed9fe3a9870eb9b625099@haskell.org> References: <044.d2359d5edaaed9fe3a9870eb9b625099@haskell.org> Message-ID: <059.a107f9666e8818213a589e709bf6289e@haskell.org> #10965: GHC Panic on import with 'OPTIONS_GHC -fobject-code -O' ---------------------------------+-------------------------------------- Reporter: Orome | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10549 | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by rwbarton): The contents of the module aren't relevant, this module exhibits the same panic. {{{ {-# OPTIONS_GHC -fobject-code -O #-} f :: String -> String f = id }}} The difference is that this module has `-fobject-code`. `checkOptLevel` disallows `-O`, if the target is `HscInterpreted`. That was the fix for #10549. But here the target is `HscAsm`. But somewhere later the target must get set to `HscInterpreted`, as evidenced by the output {{{ [1 of 1] Compiling Main ( G.hs, interpreted ) }}} and the fact that the module contains breakpoints. (So as another issue, `{-# OPTIONS_GHC -fobject-code #-}` doesn't actually work. Seems it hasn't worked since at least 7.8.) Aha, found it! {{{ upsweep_mod hsc_env old_hpt (stable_obj, stable_bco) summary mod_index nmods = ... -- We're using the dflags for this module now, obtained by -- applying any options in its LANGUAGE & OPTIONS_GHC pragmas. dflags = ms_hspp_opts summary prevailing_target = hscTarget (hsc_dflags hsc_env) local_target = hscTarget dflags -- If OPTIONS_GHC contains -fasm or -fllvm, be careful that -- we don't do anything dodgy: these should only work to change -- from -fllvm to -fasm and vice-versa, otherwise we could -- end up trying to link object code to byte code. target = if prevailing_target /= local_target && (not (isObjectTarget prevailing_target) || not (isObjectTarget local_target)) then prevailing_target else local_target -- store the corrected hscTarget into the summary summary' = summary{ ms_hspp_opts = dflags { hscTarget = target } } ... }}} Assuming this stuff about linking object code and byte code is still relevant, I guess we should call `checkNewDynFlags` on `dflags { hscTarget = target }`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 01:56:34 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 01:56:34 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.260931f4bcee1267821d4d9f7e21ac16@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1774 Wiki Page: | -------------------------------------+------------------------------------- Comment (by luite): Unfortunately the fix breaks cross compilation due to a hardcoded `WORD_SIZE_IN_BITS` dependency in `TysWiredIn`. If the cross compilation target has a different word size than the build machine, the types become inconsistent. (This makes GHCJS unusable with a 64 bit GHC 8.0.1rc2; it fails to compile `ghc-prim`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 02:01:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 02:01:33 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.7f6a689e33ee7b1a11ccf4404ba1e124@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Phab:D1774 Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 02:04:49 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 02:04:49 -0000 Subject: [GHC] #11319: ImpredicativeTypes even more broken than usual In-Reply-To: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> References: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> Message-ID: <066.356aa2b7e71ee339a80158ace519339d@haskell.org> #11319: ImpredicativeTypes even more broken than usual -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | ImpredicativeTypes Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Reid Barton ): In [changeset:"b7dfbb45b6ac7849dbb7cf414d507fd65d1e7ed4/ghc" b7dfbb4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b7dfbb45b6ac7849dbb7cf414d507fd65d1e7ed4" Add test for #11319 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 02:05:19 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 02:05:19 -0000 Subject: [GHC] #11319: ImpredicativeTypes even more broken than usual In-Reply-To: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> References: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> Message-ID: <066.07beee0ec756bc149ce828ab1dbfb852@haskell.org> #11319: ImpredicativeTypes even more broken than usual -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | ImpredicativeTypes Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11319 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * testcase: => typecheck/should_compile/T11319 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 02:23:43 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 02:23:43 -0000 Subject: [GHC] #10965: GHC Panic on import with 'OPTIONS_GHC -fobject-code -O' In-Reply-To: <044.d2359d5edaaed9fe3a9870eb9b625099@haskell.org> References: <044.d2359d5edaaed9fe3a9870eb9b625099@haskell.org> Message-ID: <059.a7e931c077f007d4f29e1ebef53f58bf@haskell.org> #10965: GHC Panic on import with 'OPTIONS_GHC -fobject-code -O' ---------------------------------+-------------------------------------- Reporter: Orome | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10549 | Differential Rev(s): Wiki Page: | ---------------------------------+-------------------------------------- Comment (by rwbarton): I guess the issue is: we can't have an object code module import a byte code module, since how would we link the object file? And if we allowed `{-# OPTIONS_GHC -fobject-code #-}`, that could end up happening. The workaround is of course not to write `{-# OPTIONS_GHC -fobject-code #-}` since it doesn't work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 07:29:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 07:29:58 -0000 Subject: [GHC] #9022: TH pretty printer and GHC parser semicolon placement mismatch In-Reply-To: <047.5de523bade6a019122fff089f11b671b@haskell.org> References: <047.5de523bade6a019122fff089f11b671b@haskell.org> Message-ID: <062.d7b37b868a3eb7f2408f13ca8c175416@haskell.org> #9022: TH pretty printer and GHC parser semicolon placement mismatch -------------------------------------+------------------------------------- Reporter: roldugin | Owner: bollmann Type: bug | Status: closed Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.1 Resolution: fixed | Keywords: newcomer 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:D1898 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bollmann): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 09:11:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 09:11:12 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.ca81db574890e67153ad63cbda68b2cd@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1774 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: luite, I'm afraid I'll need a bit more detail. On looking at this it appears that `WORD_SIZE_IN_BITS` should be the word size of the target, so I don't see what could be going on here. Can you open another ticket describing the issue that you are observing in detail? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 09:54:12 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 09:54:12 -0000 Subject: [GHC] #11564: Possible overzealous unfolding In-Reply-To: <047.2c6c2b843f6daaa097ae723c3d64a380@haskell.org> References: <047.2c6c2b843f6daaa097ae723c3d64a380@haskell.org> Message-ID: <062.4eaddd5acbacaeef05a00f04d0c009df@haskell.org> #11564: Possible overzealous unfolding -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | 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:D1900 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * owner: simonpj => * status: merge => new Comment: I reverted the change, because it caused perf test regressions (that were apparently not reported by Travis): https://perf.haskell.org/ghc/#revision/51a33924fc118d9b6c1db556c75c0d010ef95e18 {{{ tests/alloc/T3064 297834384 + 3.18% 307311896 bytes tests/alloc/T5631 1164415992 + 108.27% 2425081664 bytes tests/alloc/T7257 1654893352 - 14.50% 1414893352 bytes tests/alloc/T783 489042024 + 3.47% 505987776 bytes tests/alloc/T9020 703211744 + 16.45% 818924416 bytes tests/alloc/T9872d 535824528 + 3.09% 552399688 bytes tests/alloc/T9961 731573736 + 5.10% 768861280 bytes tests/alloc/haddock.Cabal 10472403176 + 4.52% 10945830216 bytes tests/alloc/haddock.compiler 59679619080 + 4.56% 62402376816 bytes }}} Need to investigate these before pushing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 09:58:54 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 09:58:54 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.413ea74f983d0fa21fe2220b615555ca@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1774 Wiki Page: | -------------------------------------+------------------------------------- Comment (by luite): Oh I'm sorry, I expected the problem to be known due to the `TODO: This should be for the target, no?` remark in the code. GHCJS configures the GHC API through `DynFlags` to produce 32 bit code. The GHC code was reworked to support changing the target dynamically. For example in `PrelRules` the `WORD_SIZE_IN_BITS` constant was replaced by `wordSizeInBits dflags`(which in turn uses `targetPlatform` from `dflags`) in various places. Unfortunately the use of the `WORD_SIZE_IN_BITS` macro in `TysWiredIn` means that `TyCon` gets `Word#` fields with a 64 bit GHC library, even if `wordSizeInBits dflags == 32`. It should get `Word64#` fields. GHC should really use the `DynFlags` word size value in `trTyConDataCon` (similar to for example `PrelRules.shiftRightLogical`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 10:12:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 10:12:13 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.116abb158d310a3121206a0109aa7819@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1774 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The code is {{{ trTyConDataCon :: DataCon trTyConDataCon = pcDataCon trTyConDataConName [] [fprint, fprint, trModuleTy, trNameTy] trTyConTyCon where -- TODO: This should be for the target, no? #if WORD_SIZE_IN_BITS < 64 fprint = word64PrimTy #else fprint = wordPrimTy #endif }}} Question: why is `trTyConTyCon` wired in at all? Its only use is in `TcTypeable` which could perfectly well look it up in the envt (it would need to be a known-key name). We should never wire-in type constructors without a pressing reason. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 10:23:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 10:23:16 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.c480a5b862f9e69e839c6e8f134dca14@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1774 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I suspect that simonpj is right and we can get away without wiring in `TyCon`. I'll quickly give this a shot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 10:44:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 10:44:16 -0000 Subject: [GHC] #11564: Possible overzealous unfolding In-Reply-To: <047.2c6c2b843f6daaa097ae723c3d64a380@haskell.org> References: <047.2c6c2b843f6daaa097ae723c3d64a380@haskell.org> Message-ID: <062.3a7c82643c457522d2f3570cf072595e@haskell.org> #11564: Possible overzealous unfolding -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | 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:D1900 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): I looked at the `-dverboseI looked at the `-dverbose-core2core` for `T5631` and it's identical between the before and after compilers, so this is a difference in the performance of GHC itself after this change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 11:11:24 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 11:11:24 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.20b4acae1bbd32a059d68bb53aba2544@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by owst): Excellent points goldfire. My thoughts on your three suggestions: * A) As you say, declaration order isn't something we normally have to consider in Haskell, which is a drawback I hadn't thought about, * C) Sounds simple, but seems a little arbitrary that types would be available to all splices, but functions only according to the top-to- bottom ordering, why should types be more important than terms? :-) * B) Certainly sounds simple and using it in my example above, {{{exprContainingSplice1}}} and {{{exprContainingSplice1}}} would have access to all of {{{A}}},{{{B}}},{{{f}}},{{{g1}}} and {{{g2}}} but ''not'' each other, which seems very reasonable. A question/thought: should {{{reify}}} be able to determine information about datatypes/expressions, but have them still be unavailable for compile-time evaluation? E.g. consider the following: {{{#!hs import Language.Haskell.TH double :: (Num a) => a -> a double x = x * 2 data D = D Int deriving Show doReify = do print $(reify 'double >>= litE . stringL . show) print $(reify 'D >>= litE . stringL . show) doEval = do print $(litE . integerL $ double 10) print $(litE . stringL . show $ D 10) main = doReify >> doEval }}} under the B) suggestion, the following will fail to compile (with a stage restriction error) unless the definition and usage of {{{doEval}}} are commented out. Is that surprising? Is there a technical reason to rule out {{{doEval}}}? The user guide currently has this to say > You can only run a function at compile time if it is imported from another module. That is, you can't define a function in a module, and call it from within a splice in the same module. (It would make sense to do so, but it's hard to implement.) is this related to why {{{reify myFunction}}} doesn't contain the source of {{{myFunction}}} - as per #1831? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 12:02:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 12:02:13 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.06f31356fd543b0bca422bbff58038dc@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1774 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The principle difficulty here is the following: * The first thing that we do during type checking is construct a `GHC.Types.Module` binding to represent the module being compiled. This is necessary since we must refer to this binding when generating implicits for the data types which we later typecheck * When we compile `GHC.Types` `Module` is not yet in scope, since it is defined in the module we are currently compiling Similar issues occur with the `TyCon` and `TrName` types. I thought it would be possible to finagle the order of typechecking such that we could ensure that everything was in scope when needed. After playing around with a few ideas I suspect that, while this might be possible, the result will be too fragile to offset the benefit of unwiring these types. Sadly wiring-in really does seem like the simplest option here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 12:03:44 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 12:03:44 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.bee4e695b2c1a39e40b888c67b38310a@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1774 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've put up the quick, easy, but dirty approach to fixing this as Phab:D1904. It's really quite foul, but I'm not sure I see a better way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 12:06:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 12:06:35 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.5626fc9eab475d10503c4a6a038c4850@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1774 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > * When we compile `GHC.Types` `Module` is not yet in scope, since it is defined in the module we are currently compiling Yes it is! We typecheck the module before generating those extra bindings. So the definitions will be in the type environment, won't they. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 12:09:53 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 12:09:53 -0000 Subject: [GHC] #11564: Possible overzealous unfolding In-Reply-To: <047.2c6c2b843f6daaa097ae723c3d64a380@haskell.org> References: <047.2c6c2b843f6daaa097ae723c3d64a380@haskell.org> Message-ID: <062.0df2547762b0130b6492772b4b047b8a@haskell.org> #11564: Possible overzealous unfolding -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | 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:D1900 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Well yes, I guess that's maybe what tests/alloc/T5631 measures? I don't even know where that test is. But why would the compiler allocate twice as much? If `-dverbose- core2core` is identical, it can't be that the program being compiled is getting bigger. Very mysterious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 12:26:01 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 12:26:01 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.9fe8e9283c75e806adfa846f5c23d53e@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1774 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Yes it is! We typecheck the module before generating those extra bindings. Hmm, in that case I'm a bit stumped as to why my `wip/typeable-unwired` branch fails while building `GHC.Types` with, {{{ libraries/ghc-prim/GHC/Types.hs:1:1: error: GHC internal error: ?TyCon? is not in scope during type checking, but it passed the renamer }}} This appears to occur at some point between the `Tc3` and `Tc4` trace points. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 12:38:49 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 12:38:49 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.b1384073cbe77bf14377eed324eba4ed@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1774 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > Yes it is! We typecheck the module before generating those extra bindings. So the definitions will be in the type environment, won't they? Ahh, I think we were talking about different things. The `TyCon` bindings are indeed generated after type checking the module's type declarations. However, this is not the case for the `Module` binding: Generating it is literally the first thing done by `tcRnSrcDecls`, {{{#!hs tcRnSrcDecls explicit_mod_hdr decls = do { -- Create a binding for $trModule -- Do this before processing any data type declarations, -- which need tcg_tr_module to be initialised ; tcg_env <- mkModIdBindings ; tcg_env <- setGblEnv tcg_env mkPrimTypeableBinds -- Do all the declarations ; ((tcg_env, tcl_env), lie) <- setGblEnv tcg_env $ captureConstraints $ do { (tcg_env, tcl_env) <- tc_rn_src_decls decls ; ; tcg_env <- setEnvs (tcg_env, tcl_env) $ checkMain explicit_mod_hdr ; return (tcg_env, tcl_env) } ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 12:45:50 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 12:45:50 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.a2367b6d2238eb1108de200f415c02ba@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1774 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): That's only because we do `mkTypeableBinds` on a group by group basis. Instead we could * Typecheck all the type/class decls * Do `mkModIdBindings` * Do `mkTypeableBindings` That might also mean that we could generate type representations for all types in `GHC.Types` instead of the weird stuff that happens now, with them being manually defined elsewhere -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 12:50:43 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 12:50:43 -0000 Subject: [GHC] #11569: make -j24 test Message-ID: <043.ebd4ab4cf2b889476fd8b09d162a3605@haskell.org> #11569: make -j24 test ----------------------------------+-------------------------- Reporter: mfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.1 Keywords: | Operating System: Linux Architecture: aarch64 | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------+-------------------------- My computer is slow but has many cores. I find several hundred tests fail "bad stderr" when I set the environment variable: {{{ export MAKEFLAGS=-j24 make test }}} I'll update with the list of failing tests in a few hours when I'm done running the testsuite serially. But one is T3307. It even fails when run by itself like: {{{ export MAKEFLAGS=-j24 make test TESTS="T3307" }}} But otherwise passes if {{{ unset MAKEFLAGS make test TESTS="T3307" }}} Building version 99cb627a45afacde5f86799671c53baf81daee41 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 12:53:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 12:53:58 -0000 Subject: [GHC] #11566: I don't need madvise DONT_NEED In-Reply-To: <043.ae7447db31f335ef6697823ae5dfc604@haskell.org> References: <043.ae7447db31f335ef6697823ae5dfc604@haskell.org> Message-ID: <058.e1d00079a811a60ee8a3383e430fc048@haskell.org> #11566: I don't need madvise DONT_NEED -------------------------------------+------------------------------------- Reporter: mfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mfox): I can make a patch easily deleting the call seems fine. I just wonder if it affects another platform. Should I ifdef it out for Linux? For aarch64? For Linux && aarch64? Who uses this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 12:57:01 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 12:57:01 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.d08a899fe3ccccaed4b1226cb123748b@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1774 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > That's only because we do mkTypeableBinds on a group by group basis. That is a fair point. I can give this a try. > That might also mean that we could generate type representations for all types in `GHC.Types` instead of the weird stuff that happens now, with them being manually defined elsewhere Actually since my refactoring there is no oddness in the handling of `GHC.Types`; since `TyCon`, et al. are wired-in we allow the usual codepath to generate the representations for types defined in this module. The only oddness at this point is the handling of `GHC.Prim`, which needs to have its representations injected into `GHC.Types`. Performing the refactoring you mention above would allow us to retain the consistent handling of `GHC.Types` while un-wiring `TyCon` and friends. Currently type constructor representations are produced by `tcAddImplicits`. Should we move the entire `tcAddImplicits` step until after all groups have been typechecked or only extract the typeable handling? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 12:58:18 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 12:58:18 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.107b70c3dfc5e33d6a4d7ff36f65269d@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by mfox): #11566 I don't need madvise DONT_NEED Compiler 8.1 bug normal Feb 11, 2016 #11569 make -j24 test Test Suite 8.1 bug normal Feb 12, 2016 These are the source of many testsuite failures. I'll update with the new (hopefully empty) list of failures in however many hours it takes to run serially. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 13:01:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 13:01:45 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.2e4931f51bf87a02078d7f35e95c92f6@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1774 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > Currently type constructor representations are produced by tcAddImplicits. Should we move the entire tcAddImplicits step until after all groups have been typechecked or only extract the typeable handling? Yes I think we could do that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 13:03:21 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 13:03:21 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.150938a1e0ba97ae743ec95445896dd0@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by mfox): @erikd Did you get a chance to try my build? I would like to know if it works or not on which hardware and Linux version. I built under Ubuntu 14.04 with a mildly patched 4.2 kernel using llvm-3.5 from ubuntu so expect it to work maybe on more recent distros only. My hardware is thunderX on armcloud but I expect every armv8 chip is compatible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 13:03:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 13:03:46 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.585d0d189f0ccbd52d218521f4413c66@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by simonpj): Blimey! That's a big change n allocation for a very small diff. Esp since one part (`piResultTys` not using one-at-a-time substitutio) ought to be a material improvement in efficiency! Bartosz maybe you can investigate? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 13:12:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 13:12:40 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.ad87afbf24b57efaf36578860031c3d1@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by mfox): @erikd Another thing is I installed a new binutils and ld.gold that comes with it. Maybe you need it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 13:24:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 13:24:22 -0000 Subject: [GHC] #11569: make -j24 test In-Reply-To: <043.ebd4ab4cf2b889476fd8b09d162a3605@haskell.org> References: <043.ebd4ab4cf2b889476fd8b09d162a3605@haskell.org> Message-ID: <058.d2dc59ae29e9be70553bbe75c93c2df4@haskell.org> #11569: make -j24 test -------------------------------+------------------------------- Reporter: mfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+------------------------------- Comment (by thomie): Use `make THREADS=24` instead. See [wiki:Building/RunningTests]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 13:26:59 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 13:26:59 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.16fdf0006688f9aa702d0409a4b36f66@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1774 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have a stab at this that seems to be compiling in Phab:D1906. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 13:51:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 13:51:37 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.6d19843f1919af7ede5f5480d472dc40@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): If we are willing to expose GHC's internal toposort of declarations (that is, its process of finding mutually recursive groups, without regard to top-to-bottom ordering, and then processing these groups in dependency order), then we might be able to do away with the stage restriction. Indeed, I was surprised to see that the Haskell 2010 report even contains a description of the toposort: see [https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-880004.5 Section 4.5.1]. The context there is different than here, but it all still relies on finding chunks of perhaps-mutually-recursive definitions. So perhaps the process is this: 1. Split up the module into regions separated by top-level declaration splices. 2. Within each region, chunk the declarations into mutually recursive groups. Any declaration with a splice in it is considered to depend on all other declarations in the region. 3. Process the chunks in dependency order, making already-processed chunks available both for a. reification b. calling in a splice (i.e. loosening the stage restriction) I actually that's not quite so bad. It's not really too hard to understand. It might be some work to implement; it will depend on the details. But it surely seems ''possible'' to implement. And, as far as I can see, this is a loosening of existing restrictions. No code that is accepted today would be rejected by these rules. What do you think? And, in answer to your question, I don't think this is much related to #1831. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 13:59:03 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 13:59:03 -0000 Subject: [GHC] #11319: ImpredicativeTypes even more broken than usual In-Reply-To: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> References: <051.bdfa9dd4904b1999b29695de7c490ac6@haskell.org> Message-ID: <066.bc2d2258718e37f37c3b56104de4386c@haskell.org> #11319: ImpredicativeTypes even more broken than usual -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | ImpredicativeTypes Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11319 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Just to note that most of wiki:Typechecking is indeed in HEAD and 8.0 now. The bit that I believe would fix this ticket is `ExpFun`, which is not implemented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 14:01:53 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 14:01:53 -0000 Subject: [GHC] #11473: Levity polymorphism checks are inadequate In-Reply-To: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> References: <046.2d23c9704ae9d4ad296bcce421432abd@haskell.org> Message-ID: <061.97f276a1c8b42ab037f77247910ad063@haskell.org> #11473: Levity polymorphism checks are inadequate -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: | LevityPolymorphism, TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Thanks for another example. Will get to this soon (next week?). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 14:13:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 14:13:42 -0000 Subject: [GHC] #11541: Type errors sometimes has a lot of irrelevant information In-Reply-To: <047.b489a9355667fda5e49935258d0dd4af@haskell.org> References: <047.b489a9355667fda5e49935258d0dd4af@haskell.org> Message-ID: <062.d1d5541ecc3a679a8ed5dfa428789a36@haskell.org> #11541: Type errors sometimes has a lot of irrelevant information -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): I have seen this behvaiour a few times. Here is a simple self-contained test case: {{{ g :: Ord k => k -> v -> () g k v = () f x y = let m = min x y in g m foo }}} 8-rc2 outputs this: {{{ ghci C.hs GHCi, version 8.0.0.20160204: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( C.hs, interpreted ) C.hs:5:11: error: ? No instance for (Ord t) arising from a use of ?min? Possible fix: add (Ord t) to the context of the inferred type of f :: t -> t -> () ? In the expression: min x y In an equation for ?m?: m = min x y In the expression: let m = min x y in g m foo C.hs:6:11: error: Variable not in scope: foo }}} The relevant error message (not in scope) comes last, the message before is bogus. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 14:22:01 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 14:22:01 -0000 Subject: [GHC] #11570: C build fails on RPi 2 Message-ID: <048.1f2e7206edbdb8d73ca72e4996ab02a5@haskell.org> #11570: C build fails on RPi 2 ---------------------------------+------------------------------------- Reporter: neuwirthe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------+------------------------------------- I am trying to build ghc 7.8.4 on a RaspberryPi 2 B This fails in the last step. I installed ghc 7.6.3 from the Raspbian archive pi at raspberrypi32:~/devel/ghc-7.8.4$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.3 And I downloaded the sources for 7.8.4 from here. https://www.haskell.org/ghc/dist/7.8.4/ghc-7.8.4-src.tar.bz2 The I unarchived the tar file and did ./boot ./configure make Then, tha machine happily chruned alog for more than 12 hours and then I got ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all inplace/bin/dll-split compiler/stage2/build/.depend-v-p-dyn.haskell "DynFlags" "Annotations Avail Bag BasicTypes BinIface Binary BooleanFormula BreakArray BufWrite BuildTyCl Class CmdLineParser CmmType CoAxiom ConLike Coercion Config Constants CoreArity CoreFVs CoreLint CoreSubst CoreSyn CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph DriverPhases DsMonad DynFlags Encoding ErrUtils Exception ExtsCompat46 FamInstEnv FastFunctions FastMutInt FastString FastTypes Finder Fingerprint FiniteMap ForeignCall Hooks HsBinds HsDecls HsDoc HsExpr HsImpExp HsLit HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id IdInfo IfaceEnv IfaceSyn IfaceType InstEnv Kind ListSetOps Literal LoadIface Maybes MkCore MkId Module MonadUtils Name NameEnv NameSet OccName OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair Panic PatSyn PipelineMonad Platform PlatformConstants PprCore PrelInfo PrelNames PrelRules Pretty PrimOp RdrName Rules Serialized SrcLoc StaticFlags StringBuffer TcEvidence TcIface TcRnMonad TcRnTypes TcType TcTypeNats TrieMap TyCon Type TypeRep TysPrim TysWiredIn Unify UniqFM UniqSet UniqSupply Unique Util Var VarEnv VarSet Bitmap BlockId ByteCodeAsm ByteCodeInstr ByteCodeItbls CLabel Cmm CmmCallConv CmmExpr CmmInfo CmmMachOp CmmNode CmmUtils CodeGen.Platform CodeGen.Platform.ARM CodeGen.Platform.NoRegs CodeGen.Platform.PPC CodeGen.Platform.PPC_Darwin CodeGen.Platform.SPARC CodeGen.Platform.X86 CodeGen.Platform.X86_64 FastBool Hoopl Hoopl.Dataflow InteractiveEvalTypes MkGraph PprCmm PprCmmDecl PprCmmExpr Reg RegClass SMRep StgCmmArgRep StgCmmClosure StgCmmEnv StgCmmLayout StgCmmMonad StgCmmProf StgCmmTicky StgCmmUtils StgSyn Stream" dll-split: internal error: evacuate(static): strange closure type 0 (GHC version 7.8.4 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug compiler/ghc.mk:646: recipe for target 'compiler/stage2/dll-split.stamp' failed make[1]: *** [compiler/stage2/dll-split.stamp] Aborted Makefile:71: recipe for target 'all' failed make: *** [all] Error 2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 14:34:43 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 14:34:43 -0000 Subject: [GHC] #11567: Haddock renders wired-in types with kind signature In-Reply-To: <046.9da84f84610001ab70d0d61e4b2e51a9@haskell.org> References: <046.9da84f84610001ab70d0d61e4b2e51a9@haskell.org> Message-ID: <061.0f1c1f025744777da7d5def277d983e4@haskell.org> #11567: Haddock renders wired-in types with kind signature -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Documentation | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * Attachment "fixed-data-proxy.png" added. What the docs for Data.Proxy looks like now -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 14:35:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 14:35:46 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.fe029e8b20b937f1f08c5c875d0ed328@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by niteria): I will investigate. I think it will be easier if I revert it and then push it again when it's fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 14:36:49 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 14:36:49 -0000 Subject: [GHC] #11567: Haddock renders wired-in types with kind signature In-Reply-To: <046.9da84f84610001ab70d0d61e4b2e51a9@haskell.org> References: <046.9da84f84610001ab70d0d61e4b2e51a9@haskell.org> Message-ID: <061.ebcad5f83fb380e627068f679ca9c65c@haskell.org> #11567: Haddock renders wired-in types with kind signature -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Documentation | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): This was fixed by a [https://github.com/haskell/haddock/pull/476 recent Haddock commit], but GHC 8.0.1-rc2 did not use a sufficiently new version of Haddock. I've attached an image of what `Data.Proxy`'s docs should look like, for reference. (The abnormally long lines for `type Rep` and `type Rep1` should be fixed once [https://github.com/haskell/haddock/pull/482 this] is merged.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 14:59:34 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 14:59:34 -0000 Subject: [GHC] #11566: I don't need madvise MADV_DONTNEED (was: I don't need madvise DONT_NEED) In-Reply-To: <043.ae7447db31f335ef6697823ae5dfc604@haskell.org> References: <043.ae7447db31f335ef6697823ae5dfc604@haskell.org> Message-ID: <058.169e36900a084ca3da91942303bae329@haskell.org> #11566: I don't need madvise MADV_DONTNEED -------------------------------------+------------------------------------- Reporter: mfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- @@ -6,1 +6,1 @@ - madvise(..., DONT_NEED) is not implemented. + madvise(..., MADV_DONTNEED) is not implemented. New description: Many tests fail because of a warning in rts/posix/OSMem.c unable to decommit memory: function not implemented The reason it says "function not implemented" is that the function madvise(..., MADV_DONTNEED) is not implemented. This is on a stock Ubuntu LTS 14.04 machine. The only interesting thing about it is that it's running on a pre-production armv8 processor with a beta 4.2 guest kernel. -- Comment (by rwbarton): If the two-stage allocator isn't working on your system, you can disable it with `configure --disable-large-address-space`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 15:24:39 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 15:24:39 -0000 Subject: [GHC] #11570: C build fails on RPi 2 In-Reply-To: <048.1f2e7206edbdb8d73ca72e4996ab02a5@haskell.org> References: <048.1f2e7206edbdb8d73ca72e4996ab02a5@haskell.org> Message-ID: <063.dffdf0fa1097118d7ee83e5054810faf@haskell.org> #11570: C build fails on RPi 2 -------------------------------------+--------------------------------- Reporter: neuwirthe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4-rc1 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 neuwirthe): I forgot to mention: I also get warnings of the following type: [ 1 of 89] Compiling Distribution.PackageDescription.Utils ( libraries/Cabal/Cabal/Distribution/PackageDescription/Utils.hs, bootstrapping/Distribution/PackageDescription/Utils.o ) You are using a new version of LLVM that hasn't been tested yet! We will try though... And this is the information abut the version of LLVM I am using: pi at raspberrypi32:~/devel/ghc-7.8.4$ /usr/lib/llvm-3.4/bin/opt --version LLVM (http://llvm.org/): LLVM version 3.4.2 Optimized build. Built Nov 5 2014 (21:06:13). Default target: arm-unknown-linux-gnueabihf Host CPU: (unknown) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 15:58:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 15:58:42 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.546174f32c7d3b31fdb479b08cf5af83@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by mfox): Here's what really doesn't work on arm64: {{{ Unexpected results from: TEST="T2552 T5654b-O1 T5654b-O0 T2552 T11374 linker_unload divbyzero T5435_dyn_asm T5435_v_gcc T5435_v_asm T3424 ghci004 ghci006 T9329 T5313 T10052 recomp015 ghcilink004 TH_spliceE5_prof_ext recomp011 T3586 prog001 T8628 T8639_api T10508_api dynCompileExpr T9203 haddock.Cabal haddock.compiler haddock.base T5321FD T5631 T9872a T3064 T1969 T783" OVERALL SUMMARY for test run started at Fri Feb 12 12:38:16 2016 UTC 2:59:55 spent to go through 5015 total tests, which gave rise to 18823 test cases, of which 13838 were skipped 67 had missing libraries 4801 expected passes 81 expected failures 0 caused framework failures 1 unexpected passes 25 unexpected failures 10 unexpected stat failures Unexpected passes: profiling/should_run T2552 (profasm) Unexpected failures: codeGen/should_compile T9329 [exit code non-0] (normal) driver T5313 [bad exit code] (normal) driver/recomp011 recomp011 [bad stdout] (normal) driver/recomp015 recomp015 [bad exit code] (normal) ghc-api T10508_api [bad exit code] (normal) ghc-api T8628 [bad exit code] (normal) ghc-api T8639_api [bad exit code] (normal) ghc-api/T10052 T10052 [bad exit code] (normal) ghc-api/dynCompileExpr dynCompileExpr [bad exit code] (normal) ghci/linking ghcilink004 [bad exit code] (normal) ghci/prog001 prog001 [bad exit code] (ghci-ext) ghci/scripts ghci004 [bad exit code] (ghci-ext) ghci/scripts ghci006 [bad exit code] (ghci-ext) perf/should_run T3586 [exit code non-0] (normal) pmcheck/should_compile T11374 [exit code non-0] (normal) profiling/should_run T2552 [bad profile] (prof) profiling/should_run T5654b-O0 [exit code non-0] (prof) profiling/should_run T5654b-O1 [exit code non-0] (profasm) rts T3424 [exit code non-0] (normal) rts T5435_dyn_asm [bad stdout] (normal) rts T5435_v_asm [bad exit code] (normal) rts T5435_v_gcc [bad exit code] (normal) rts divbyzero [bad exit code] (normal) rts linker_unload [bad exit code] (normal) th TH_spliceE5_prof_ext [bad exit code] (normal) Unexpected stat failures: perf/compiler T1969 [stat too good] (normal) perf/compiler T3064 [stat too good] (normal) perf/compiler T5321FD [stat too good] (normal) perf/compiler T5631 [stat too good] (normal) perf/compiler T783 [stat too good] (normal) perf/compiler T9872a [stat too good] (normal) perf/haddock haddock.Cabal [stat too good] (normal) perf/haddock haddock.base [stat too good] (normal) perf/haddock haddock.compiler [stat too good] (normal) perf/should_run T9203 [stat too good] (normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 16:13:30 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 16:13:30 -0000 Subject: [GHC] #11566: I don't need madvise MADV_DONTNEED In-Reply-To: <043.ae7447db31f335ef6697823ae5dfc604@haskell.org> References: <043.ae7447db31f335ef6697823ae5dfc604@haskell.org> Message-ID: <058.c942ed1d5a49cfbd91bde820713c6064@haskell.org> #11566: I don't need madvise MADV_DONTNEED -------------------------------------+------------------------------------- Reporter: mfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mfox): Thanks. Should this be default for arm64? Is it something hardware can't support, needs kernel improvement or something that will eventually work? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 16:29:02 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 16:29:02 -0000 Subject: [GHC] #11566: I don't need madvise MADV_DONTNEED In-Reply-To: <043.ae7447db31f335ef6697823ae5dfc604@haskell.org> References: <043.ae7447db31f335ef6697823ae5dfc604@haskell.org> Message-ID: <058.70ae845c7dac1ba786fe336b0ecb8777@haskell.org> #11566: I don't need madvise MADV_DONTNEED -------------------------------------+------------------------------------- Reporter: mfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: erikd (added) Comment: Good question. I don't know. erikd? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 16:36:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 16:36:26 -0000 Subject: [GHC] #11570: C build fails on RPi 2 In-Reply-To: <048.1f2e7206edbdb8d73ca72e4996ab02a5@haskell.org> References: <048.1f2e7206edbdb8d73ca72e4996ab02a5@haskell.org> Message-ID: <063.94f2a7aadd3187fbba00b82e6fe7cabc@haskell.org> #11570: C build fails on RPi 2 -------------------------------------+--------------------------------- Reporter: neuwirthe | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4-rc1 Resolution: wontfix | 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 rwbarton): * status: new => closed * resolution: => wontfix Comment: This looks like it might be #8976. Are you using the gold linker? But even if you get past that, you'd run into #9439. Unfortunately the whole 7.8 line has a serious bug in the LLVM backend making it unusable. You can try applying commit 5895f2b8ffba72a8393e9f712461e6e5ed7ceced. It should be easy, it was just overlooked. If you don't mind building 7.10 instead of 7.8, I imagine you'd probably have an easier time with that (both these bugs are fixed in 7.10). Closing since 7.8 is no longer supported. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 17:35:34 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 17:35:34 -0000 Subject: [GHC] #11414: Panic with -XStrict: StgCmmEnv: variable not found In-Reply-To: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> References: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> Message-ID: <060.7c39054d870cb6f9736fbfbdd9f1647c@haskell.org> #11414: Panic with -XStrict: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Strict Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T11414 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1791 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c6485d5e6daec20c8ff66d6e721d3e0a5f3156ac/ghc" c6485d5e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c6485d5e6daec20c8ff66d6e721d3e0a5f3156ac" Simplify AbsBinds wrapping In poking Trac #11414 I found myself sinking into the abe_inst_wrap swamp. What is this strange thing? (It turned out that #11414 was breaking because of it.) Thrillingly, I found a way to sweep it away again, putting the deep instantation into tcMonoBinds instead of mkExport; and it turned out that the fun_co_fn field of FunBind was already there ready to receive exactly this wrapper. Hooray. Result * Death to abe_inst_wrap * Death to mbi_orig * Death to the plumbing in tcPolyInfer that did the deep instantiation I did find that I had to re-engineer the treatment of instance type signatures (again), but the result looks more modular and robust to me. And #11414 is fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 17:36:18 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 17:36:18 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.edfa059cac3038d270784d4f534d0733@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by owst): I think it's reasonable to expose the toposort of declarations - users are presumably used to declarations not being processed top-to-bottom already; it seems more consistent to expose toposorted-ness here too, rather than use a different rule. Some thoughts about your proposal (which I like the gist of!): * W.r.t. step 1. I'd quite like the splice in {{{f}}}: {{{#!hs f x = x ++ $(reify 'g ...) $(return []) g x = x + 1 }}} to be able to refer to {{{g}}}. It is in a different declaration group, but I think that it should be visible. However, I can't see an easy way around the need for declaration groups, so maybe it's not possible. * In step 2. I think it would be necessary that a splice within a declaration cannot refer to the declaration itself (though I'm not ''sure'' this is a problem?) > No code that is accepted today would be rejected by these rules. This seems particularly desirable to me! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 18:05:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 18:05:26 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.a700207dd06dc6ebc561403c0d53fd25@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:16 owst]: > * In step 2. I think it would be necessary that a splice within a declaration cannot refer to the declaration itself (though I'm not ''sure'' this is a problem?) Right. We at least can't allow an expression splice to refer to the type of the containing declaration: {{{ x = $(if the type of x is Char then [| False |] else [| 'a' |]) }}} So the topological sorting in goldfire's steps 2-3 is a bit overkill, and what is really going on is: 2-3. Within each region, process all the declarations that do not contain splices first. Then process all the declarations that do contain splices, making the declarations in the former group available for reification and calling. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 18:28:16 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 18:28:16 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.43f6eed72aed95049269b699b273ef0a@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by owst): Replying to [comment:17 rwbarton]: > Right. We at least can't allow an expression splice to refer to the type of the containing declaration: > {{{ > x = $(if the type of x is Char then [| False |] else [| 'a' |]) > }}} Nice example! > 2-3. Within each region, process all the declarations that do not contain splices first. Then process all the declarations that do contain splices, making the declarations in the former group available for reification and calling. Hmm, I think the topological sorting ''is'' required within regions, what about: {{{#!hs module Foo where f = $(...) g = $(reify 'f ...) h = 1 }}} I think we want to, in order: 1. Process {{{h}}} 2. Process {{{f}}}, which can refer to {{{h}}} but not {{{f}}} or {{{g}}} 3. Process {{{g}}}, which can ref to {{{h}}} and {{{f}}}, but ''not'' {{{g}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 18:31:22 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 18:31:22 -0000 Subject: [GHC] #11571: Need more intelligent conditionalization of libgcc rts symbols for x32 Message-ID: <047.5f427ce2a17580df7f32c78c02d7671e@haskell.org> #11571: Need more intelligent conditionalization of libgcc rts symbols for x32 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.1 System (Linker) | Keywords: | Operating System: Unknown/Multiple Architecture: Other | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In `rts/RtsSymbols.c` we have {{{ // 64-bit support functions in libgcc.a #if defined(__GNUC__) && SIZEOF_VOID_P <= 4 && !defined(_ABIN32) #define RTS_LIBGCC_SYMBOLS \ SymI_NeedsProto(__divdi3) \ SymI_NeedsProto(__udivdi3) \ ... }}} The purpose is to provide these symbols to `.o` files that use these symbols, expecting to be linked against libgcc. These symbols are for things like 64-bit integer division that aren't available as machine instructions on some platforms. But the `#if` is wrong on x32, which, despite having `sizeof(void *) == 4`, naturally has a full complement of 64-bit arithmetic instructions, since its registers are 64 bits wide. So libgcc does not provide these symbols, and as a result we eventually encounter missing symbol errors when linking the rts. Some possible solutions include * Figure out if there is a CPP variable set for x32 and don't include these symbols if that variable is set. I'm not sure whether `__ILP32__` is such a variable (after all x86 is also an architecture on which int, long and pointers are 32-bits). * Use autoconf to detect the presence of these symbols in libgcc. (Probably just pick one, like `__divdi3`, and hope they are all present or all missing.) * Use weak symbols somehow to add these symbols to the RTS's internal symbol table if and only if the RTS was linked against a libgcc that provides these symbols. My Android ghci also needs lots more of these, including `__modsi3`, `__umodsi3`, `__ctzdi2`, a bunch of `__aeabi_*` and `__sync_*`, and `__sF` (no idea what that is). So I'm inclined towards the last option. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 18:33:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 18:33:51 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.42d36a1ec7063cfef257f239c62aa225@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I think this is too optimistic. In general we can't analyze the argument of `reify` in `g` to know that it refers only to `f`. Plus the `...` could contain arbitrary code that could use functions in other packages that reify arbitrary names. I would say that both `f` and `g` can only refer to `h`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 19:00:21 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 19:00:21 -0000 Subject: [GHC] #11555: catch _|_ breaks at -O1 In-Reply-To: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> References: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> Message-ID: <060.89f60d32b65ab507004eabfa0e41b487@haskell.org> #11555: catch _|_ breaks at -O1 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 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 rwbarton): We could provide both `catch`-made-strict and `safeCatch`, and maybe discuss which should be the "default" in the sense of using the existing name `catch`. Though it's not just `catch`, there's `try` and other related functions as well. Maybe better to add a new `execute a = join (evaluate a)`. Simon, you wrote elsewhere (ticket:10712#comment:22): > `catch` is ''not'' strict in its argument. Its argument is a function; `catch` just guarantees to call that function. But I don't understand. Really `catch` has two arguments `catch act handler` and we're talking about strictness in `act`. Isn't `catch` strict in `act` (once applied to `handler`)? If `act` itself is _|_ then we are saying (in #10712) then `catch act handler` is allowed to be _|_. The funny property of `catch` comes in the fact that even though `catch` is going to ''apply'' `act`, it is not strict in that application because of its magical turning-bottom-into-non-bottom property. So, doesn't `catch` just have the same strictness in `act` as does, say, `seq` at a function type? Similarly I don't understand this excerpt from Note [Exceptions and strictness]: > This also applies uniformly to free variables. Consider > {{{ > let r = \st -> raiseIO# blah st > in catch# (\s -> ...(r s')..) handler st > }}} > If we give the first argument of catch a strict signature, we'll get a demand 'C(S)' for 'r'; that is, 'r' is definitely called with one argument, which indeed it is. Why can't we give `catch#` a signature that says it is strict in its argument, without necessarily ''calling'' that argument? Just like `seq`. I see that 9915b6564403a6d17651e9969e9ea5d7d7e78e7f is quite a large commit, so likely I'm missing the whole picture. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 19:58:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 19:58:28 -0000 Subject: [GHC] #7320: GHC crashes when building on 32-bit Linux in a Linode In-Reply-To: <043.0168db82b571fa620930b74d5d40cf16@haskell.org> References: <043.0168db82b571fa620930b74d5d40cf16@haskell.org> Message-ID: <058.c1baab7d94f3e53b3f290414d194ec88@haskell.org> #7320: GHC crashes when building on 32-bit Linux in a Linode ---------------------------------------+-------------------------------- Reporter: benl | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------------+-------------------------------- Comment (by rwbarton): This was a long time ago; is it still an issue? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 20:07:36 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 20:07:36 -0000 Subject: [GHC] #11414: Panic with -XStrict: StgCmmEnv: variable not found In-Reply-To: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> References: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> Message-ID: <060.01b4b46a740c7ecf61a48d812aacf4e5@haskell.org> #11414: Panic with -XStrict: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Strict Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T11414 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1791 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge Comment: Worth merging this. I'm very happy with it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 21:39:37 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 21:39:37 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.2a2bf657ed76fc0b83a866e96e2fb203@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Replying to [comment:29 mfox]: > @erikd Another thing is I installed a new binutils and ld.gold that comes with it. Maybe you need it. What versions are you using? I'm on Debian Testing and have {{{ ii binutils 2.26-3 arm64 GNU assembler, linker and binary utilities }}} {{{ $ ld.gold --version GNU gold (GNU Binutils for Debian 2.26) 1.11 }}} In addition, the llvm version I'm using with ghc (also from Debian): {{{ ii libllvm3.5v5:arm64 1:3.5.2-3 arm64 ii llvm-3.5 1:3.5.2-3 arm64 ii llvm-3.5-dev 1:3.5.2-3 arm64 ii llvm-3.5-runtime 1:3.5.2-3 arm64 }}} Also I think discussion about Arm64 does not really belong in this ticket which started out being about 32 bit Arm. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 21:53:17 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 21:53:17 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.e43ccbd093b129099650cb7745e0f83c@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Replying to [comment:26 mfox]: > Somehow mine works. I put it here: https://s3-us-west-1.amazonaws.com /stack-aarch64/ghc-7.10.3-aarch64-unknown-linux.tar.bz2 Tried that and get the same crash I get with the ghc-7.10.3 from Debian. This is not an GHC issue. Its almost certainly and issue in LLVM. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 12 23:32:36 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 12 Feb 2016 23:32:36 -0000 Subject: [GHC] #7985: Allow openFile on unknown file type In-Reply-To: <049.5d3eb1afc9286373e53a0f1299c75b88@haskell.org> References: <049.5d3eb1afc9286373e53a0f1299c75b88@haskell.org> Message-ID: <064.288de5887d40e172805e6c1976a7f033@haskell.org> #7985: Allow openFile on unknown file type -------------------------------------+------------------------------------- Reporter: singpolyma | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 ekmett): > Just guessing once and for all that files of unknown type are seekable (or not seekable) doesn't seem right. We ''could'' default to merely claiming a `Stream` as a reasonably safe default. This makes the fewest assumptions about supported operations, and would give back `False` for unknown seekability. This is conservative, but would allow users to at least open and stream content to/from such devices. If users later can point to specific exotic non-posix device types that support seeking then we could toggle on support for them on a case by case basis. This would likely let us simplify the `statGetType` logic a great deal to something like: {{{#!hs statGetType :: Ptr CStat -> IO IODeviceType statGetType p_stat = do c_mode <- st_mode p_stat :: IO CMode case () of _ | s_isdir c_mode -> return Directory | s_isreg c_mode -> return RegularFile | s_isblk c_mode -> return RawDevice | otherwise -> return Stream }}} Another, far less desirable, alternative would be to add a new `IODeviceType` and call `ioe_unsupportedOperation` when you attempt to call `hIsSeekable` on such a device, but it only delays the unexpected bottom, and seems like it would rely on `seek` being implemented in a rather uniform manner across devices across platforms, which doesn't fit with my understanding of the world. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 13 00:26:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Feb 2016 00:26:51 -0000 Subject: [GHC] #11572: BangPatterns-related behavior regressions on GHC 8.0 Message-ID: <050.d7de474953179e2bffe8b1b2c4c525d3@haskell.org> #11572: BangPatterns-related behavior regressions on GHC 8.0 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Keywords: | 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 you compile this code: {{{#!hs {-# LANGUAGE BangPatterns #-} main :: IO () main = let !_ = (undefined :: ()) in print 2 }}} with GHC 8.0.1-rc2 with any level of optimizations, it will print `2` instead of throwing `undefined` like GHC 7.10.3 does. Note that changing `undefined :: ()` to something like `undefined :: Int#` is enough to invoke `undefined` when compiled, but if you run this code in GHCi: {{{ ?> :set -XMagicHash -XBangPatterns ?> import GHC.Prim ?> let !_ = (undefined :: Int#) in print 2 }}} You get something even stranger: {{{ ghc: panic! (the 'impossible' happened) (GHC version 8.0.0.20160204 for x86_64-unknown-linux): dsLet: unlifted !_ = (undefined :: Int#) print @ Integer $dShow_a2ky 2 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 Feb 13 00:35:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Feb 2016 00:35:41 -0000 Subject: [GHC] #11572: BangPatterns-related behavior regressions on GHC 8.0 In-Reply-To: <050.d7de474953179e2bffe8b1b2c4c525d3@haskell.org> References: <050.d7de474953179e2bffe8b1b2c4c525d3@haskell.org> Message-ID: <065.98ca540795cf8c6bc74b121bc976b610@haskell.org> #11572: BangPatterns-related behavior regressions on GHC 8.0 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Another strange facet of the GHCi portion of the bug: the behavior is different depending on whether a wildcard or a named type variable is used. Here's another bizarre error you can get in GHCi (but not compiled code): {{{ ?> :set -XMagicHash -XBangPatterns ?> import GHC.Prim ?> let !a = (undefined :: Int#) in print 2 :3:5: error: ? You can't mix polymorphic and unlifted bindings !a = (undefined :: Int#) Probable fix: add a type signature ? In the expression: let !a = (undefined :: Int#) in print 2 In an equation for ?it?: it = let !a = (undefined :: Int#) in print 2 }}} This works without issue in GHCi 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 13 05:26:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Feb 2016 05:26:58 -0000 Subject: [GHC] #11174: Traversable can't be derived for datatypes with unboxed arguments In-Reply-To: <050.8afc974fb1620698fac2f086504cf230@haskell.org> References: <050.8afc974fb1620698fac2f086504cf230@haskell.org> Message-ID: <065.d2bd2e9c58b1606fff21d5cfaf97b2d3@haskell.org> #11174: Traversable can't be derived for datatypes with unboxed arguments -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Generics 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:D1908 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: new => patch * differential: => Phab:D1908 Comment: I've uploaded a Phab:D1908, based on the design philosophy outlined in [https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DeriveFunctor#Proposal:alternativestrategyforderivingFoldableandTraversable this wiki page]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 13 07:57:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Feb 2016 07:57:11 -0000 Subject: [GHC] #11555: catch _|_ breaks at -O1 In-Reply-To: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> References: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> Message-ID: <060.92347b62d01fafe1e7032975bd2008d2@haskell.org> #11555: catch _|_ breaks at -O1 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 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 NeilMitchell): I talked to Simon offline a few days ago, after that I believe his opinion was: * {{{catch#}}} should remain strict in it's first argument. * {{{catch a b = catch# (lazy a) b}}} is the correct way to express the laziness, the {{{evaluate}}} trick certainly avoids the problem for now, but it may not be robust in the future. * There are places in the IO subsystem which get a significant benefit from a strict catch, they should use a more primitive version ({{{strictCatch}}} or something). * The default exposed {{{catch}}} (and also {{{try}}}, {{{handle}}} etc) should use {{{lazy}}}. All these functions seem to share the same underlying entry point, so that shouldn't be hard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 13 09:05:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Feb 2016 09:05:56 -0000 Subject: [GHC] #11555: catch _|_ breaks at -O1 In-Reply-To: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> References: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> Message-ID: <060.483ee9aa8d31f52512ee0b4fd376967a@haskell.org> #11555: catch _|_ breaks at -O1 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 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 NeilMitchell): I have tried the two suggestions for "lazy catch", namely: {{{#!hs safeCatch1 a b = join (evaluate a) `catch` b safeCatch2 a b = lazy a `catch` b }}} Both work in isolation on the tiny example. Only {{{safeCatch1}}} works in the Shake test suite, with {{{safeCatch2}}} I get the same error as before. That suggests that {{{lazy}}} is somehow insufficient to obtain the original behaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 13 09:20:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Feb 2016 09:20:59 -0000 Subject: [GHC] #11573: CallStacks show up unexpectedly in type of local binding in GHCi Message-ID: <046.50bedf0c81dd2bc801447c1bb4cd0177@haskell.org> #11573: CallStacks show up unexpectedly in type of local binding in GHCi -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (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: -------------------------------------+------------------------------------- It was noticed (in a thread on ghc-devs) that introducing a CallStack- carrying term into the RHS of a let binding in GHCi produces a type which itself carries a callstack. I could be wrong but as far as I know this is a bug: the solver should never introduce a constraint that the user didn't write; it should merely provide an empty callstack in the event that a callstack constraint can't be solved. {{{ Prelude> let myList = [1, 2, 3 :: Integer] Prelude> let myList' = myList ++ undefined Prelude> :t myList myList :: [Integer] Prelude> :t myList' myList' :: (?callStack::GHC.Stack.Types.CallStack) => [Integer] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 13 10:32:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Feb 2016 10:32:57 -0000 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax In-Reply-To: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> References: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> Message-ID: <057.3536c7d50d17060e888cbb7486b97e41@haskell.org> #2530: deriving Show adds extra parens for constructor with record syntax -------------------------------------+------------------------------------- Reporter: spl | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 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: | Differential Rev(s): Phab:D669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Fwiw, Changing GHCi's output after so many years is possibly disrupting to literature, as GHCi's output would look different from examples printed in books and tutorials. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 13 12:32:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Feb 2016 12:32:28 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.deffeb564ac34ee89632e1adfbfa0f50@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by owst): Replying to [comment:19 rwbarton]: > I think this is too optimistic. In general we can't analyze the argument of `reify` in `g` to know that it refers only to `f`. Plus the `...` could contain arbitrary code that could use functions in other packages that reify arbitrary names. Oh of course, yes. I was only thinking about `reify 'name`, rather than passing an arbitrary `Name` to `reify`. > I would say that both `f` and `g` can only refer to `h`. I agree. I think we must rule out dependencies on expressions that contain splices. e.g. in the following: {{{#!hs f x = $(...) g y = f ... }}} `g` does not contain a splice, but depends on `f`, which does. Therefore, if this is to be allowed, we must process `f` before `g`. I think it could be done, but that way probably lies madness. Taking goldfire and rwbarton's suggestions into account, I think the procedure would be: 1. Split the module into declaration groups and process top-to-bottom, 2. For each declaration group, partition the declarations within to those that contain splices (S), and those that do not (NS), 3. Process NS first, then S. Splices within S can refer (either in `reify` or via evaluation) to all names declared in NS, but no names within S. This allows: {{{#!hs f = () data C = C g = $(reify 'f >> reify 'C >> reify ''C >> ...) $(return []) h = $(reify 'f >> reify 'C >> reify ''C >> reify 'g >> ...) }}} but not: {{{#!hs f = () g = $(reify 'f ...) -- ok h = $(reify 'g ...) -- f not in type environment in reify i = ... g ... h ... -- Not in scope g or h j = k $(reify 'k ...) -- Not in scope k (and k not in type environment in reify) $(return []) k x = ... }}} Does that seem reasonable, and likely to be implementable? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 13 16:46:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Feb 2016 16:46:19 -0000 Subject: [GHC] #11567: Haddock renders wired-in types with kind signature In-Reply-To: <046.9da84f84610001ab70d0d61e4b2e51a9@haskell.org> References: <046.9da84f84610001ab70d0d61e4b2e51a9@haskell.org> Message-ID: <061.cb17ea5b30f80d88fa900d0d25ceeecb@haskell.org> #11567: Haddock renders wired-in types with kind signature -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Documentation | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): The issue I inteded to point out here isn't the use of `TYPE 'Lifted` (which is indeed fixed by your patch) but the fact that kind signatures are rendered at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 13 16:53:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Feb 2016 16:53:59 -0000 Subject: [GHC] #11573: Inferred CallStacks expose implicit parameter (was: CallStacks show up unexpectedly in type of local binding in GHCi) In-Reply-To: <046.50bedf0c81dd2bc801447c1bb4cd0177@haskell.org> References: <046.50bedf0c81dd2bc801447c1bb4cd0177@haskell.org> Message-ID: <061.0c165df76bb476ae54e4ddfd6349c13f@haskell.org> #11573: Inferred CallStacks expose implicit parameter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gridaphobe Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * owner: => gridaphobe * priority: high => normal Comment: Just copying my response from ghc-devs :) ---- The inferred CallStack is not a bug, it was added to fix #10845. The problem is that in a function like foo :: HasCallStack => ... foo x = let bar y = undefined in bar x we need to infer a CallStack for bar (due to the structure of the constraint solver) in order to link foo's CallStack to undefined. What '''is''' a bug is that GHC shows the implicit parameter in the inferred signature. We don't expose those anymore in the CallStack API, instead we use a type synonym HasCallStack. GHC should infer HasCallStack constraints instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 13 18:19:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Feb 2016 18:19:53 -0000 Subject: [GHC] #9920: Segfault in arm binary with llvm 3.5 In-Reply-To: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> References: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> Message-ID: <059.11ee2257a11ea03e29cc6cb328353dac@haskell.org> #9920: Segfault in arm binary with llvm 3.5 -------------------------------------+------------------------------ Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Comment (by andrewufrank): i installed ghc 7.10.3 from jessie-backports (together with the corresponding LLVM 1:3.5.2.3~bpo8+2) and get for the minimal main = putStrLn "hello" program the error message {{{testthree: schedule: re-entered unsafely. Perhaps a 'foreign import unsafe' should be 'safe'? }} i am not certain if this is related: cabal install for the same minimal program (with a minimal cabal file) hangs. cabal install -v gives {{{ /home/frank/.cabal/setup-exe-cache/setup-Simple-Cabal-1.22.5.0-arm-linux- ghc-7.10.3 configure --verbose=2 --ghc --prefix=/home/frank/.cabal --bindir=/home/frank/.cabal/bin --libdir=/home/frank/.cabal/lib --libsubdir=arm-linux-ghc-7.10.3/testthree-0.0.6-3AgAf9bDkWJGZdbGLvO875 --libexecdir=/home/frank/.cabal/libexec --datadir=/home/frank/.cabal/share --datasubdir=arm-linux-ghc-7.10.3/testthree-0.0.6 --docdir=/home/frank/.cabal/share/doc/arm-linux-ghc-7.10.3/testthree-0.0.6 --htmldir=/home/frank/.cabal/share/doc/arm-linux- ghc-7.10.3/testthree-0.0.6/html --haddockdir=/home/frank/.cabal/share/doc/arm-linux- ghc-7.10.3/testthree-0.0.6/html --sysconfdir=/home/frank/.cabal/etc --user --extra-prog-path=/home/frank/.cabal/bin --dependency=base=base-4.8.2.0-2f1f71a7fcf013cd47fd21f489064f9a --disable-tests --exact-configuration --disable-benchmarks Redirecting build log to {handle: /home/frank/.cabal/logs/testthree-0.0.6.log} }}} any comment how this can be fixed? thank you - a running 7.10.3 for armhf is a great achievement! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 13 18:25:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Feb 2016 18:25:17 -0000 Subject: [GHC] #11574: schedule: re-entered unsafely on minimal hello world program on arm Message-ID: <051.5f65ae7b7de5c2aba500f9eaf01974c1@haskell.org> #11574: schedule: re-entered unsafely on minimal hello world program on arm -------------------------------------+------------------------------------- Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 installed ghc 7.10.3 from jessie-backports (together with the corresponding LLVM 1:3.5.2.3~bpo8+2) and get for the minimal main = putStrLn "hello" program the error message {{{testthree: schedule: re-entered unsafely. Perhaps a 'foreign import unsafe' should be 'safe'? }} i am not certain if this is related: cabal install for the same minimal program (with a minimal cabal file) hangs. cabal install -v gives {{{ /home/frank/.cabal/setup-exe-cache/setup-Simple-Cabal-1.22.5.0-arm-linux- ghc-7.10.3 configure --verbose=2 --ghc --prefix=/home/frank/.cabal --bindir=/home/frank/.cabal/bin --libdir=/home/frank/.cabal/lib --libsubdir=arm-linux-ghc-7.10.3/testthree-0.0.6-3AgAf9bDkWJGZdbGLvO875 --libexecdir=/home/frank/.cabal/libexec --datadir=/home/frank/.cabal/share --datasubdir=arm-linux-ghc-7.10.3/testthree-0.0.6 --docdir=/home/frank/.cabal/share/doc/arm-linux-ghc-7.10.3/testthree-0.0.6 --htmldir=/home/frank/.cabal/share/doc/arm-linux- ghc-7.10.3/testthree-0.0.6/html --haddockdir=/home/frank/.cabal/share/doc/arm-linux- ghc-7.10.3/testthree-0.0.6/html --sysconfdir=/home/frank/.cabal/etc --user --extra-prog-path=/home/frank/.cabal/bin --dependency=base=base-4.8.2.0-2f1f71a7fcf013cd47fd21f489064f9a --disable-tests --exact-configuration --disable-benchmarks Redirecting build log to {handle: /home/frank/.cabal/logs/testthree-0.0.6.log} }}} any comment how this can be fixed? thank you - a running 7.10.3 for armhf is a great achievement! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 13 18:27:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Feb 2016 18:27:09 -0000 Subject: [GHC] #11574: schedule: re-entered unsafely on minimal hello world program on arm In-Reply-To: <051.5f65ae7b7de5c2aba500f9eaf01974c1@haskell.org> References: <051.5f65ae7b7de5c2aba500f9eaf01974c1@haskell.org> Message-ID: <066.155f589ee07b408b0a2cf91517ca872b@haskell.org> #11574: schedule: re-entered unsafely on minimal hello world program on arm ----------------------------------+------------------------------ Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Changes (by andrewufrank): * failure: None/Unknown => Runtime crash * os: Unknown/Multiple => Linux * architecture: Unknown/Multiple => arm -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 13 18:27:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Feb 2016 18:27:30 -0000 Subject: [GHC] #9920: Segfault in arm binary with llvm 3.5 In-Reply-To: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> References: <044.555edb7e560a8d41cf35aba7c1c44446@haskell.org> Message-ID: <059.b26e31fcf282a7665a99169f67d7a430@haskell.org> #9920: Segfault in arm binary with llvm 3.5 -------------------------------------+------------------------------ Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------ Comment (by rwbarton): Maybe look at #11190, rather than here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 13 18:37:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Feb 2016 18:37:28 -0000 Subject: [GHC] #11574: schedule: re-entered unsafely on minimal hello world program on arm In-Reply-To: <051.5f65ae7b7de5c2aba500f9eaf01974c1@haskell.org> References: <051.5f65ae7b7de5c2aba500f9eaf01974c1@haskell.org> Message-ID: <066.671a915e4b891285aca99cf83941d40b@haskell.org> #11574: schedule: re-entered unsafely on minimal hello world program on arm ----------------------------------+------------------------------ Reporter: andrewufrank | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+------------------------------ Comment (by rwbarton): Well, #11190 looks identical. You say you are using LLVM 3.5.2, but in that ticket the reporter also thought they were using 3.5.2, but they weren't really. So, are you sure you are using 3.5.2? :) You could also try the ARM binary distribution from https://www.haskell.org/ghc/download_ghc_7_10_3#linux_armv7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 13 18:38:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Feb 2016 18:38:15 -0000 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax In-Reply-To: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> References: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> Message-ID: <057.f157df2dc74bfa5a5c3a452d6f4f540c@haskell.org> #2530: deriving Show adds extra parens for constructor with record syntax -------------------------------------+------------------------------------- Reporter: spl | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 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: | Differential Rev(s): Phab:D669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Well, if people find this objectionable, I suppose we also need to review #10104, since that also resulted in a change in `Show` output. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 13 18:42:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Feb 2016 18:42:00 -0000 Subject: [GHC] #2530: deriving Show adds extra parens for constructor with record syntax In-Reply-To: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> References: <042.b19622be9d3706ab4b282d1c64e9acb0@haskell.org> Message-ID: <057.a25151e0a7ae241ba8c71429215bddb1@haskell.org> #2530: deriving Show adds extra parens for constructor with record syntax -------------------------------------+------------------------------------- Reporter: spl | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 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: | Differential Rev(s): Phab:D669 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I assume hvr is joking, but you can never be sure... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 13 22:12:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Feb 2016 22:12:58 -0000 Subject: [GHC] #11573: Inferred CallStacks expose implicit parameter In-Reply-To: <046.50bedf0c81dd2bc801447c1bb4cd0177@haskell.org> References: <046.50bedf0c81dd2bc801447c1bb4cd0177@haskell.org> Message-ID: <061.9c06cd01a0260a2939cfdf74ab66f4e9@haskell.org> #11573: Inferred CallStacks expose implicit parameter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gridaphobe Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 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): Phab:D1911 Wiki Page: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * status: new => patch * differential: => Phab:D1911 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 13 22:19:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Feb 2016 22:19:16 -0000 Subject: [GHC] #8710: Overlapping patterns warning misplaced In-Reply-To: <047.1f227e0dac37dd7309646386f280164b@haskell.org> References: <047.1f227e0dac37dd7309646386f280164b@haskell.org> Message-ID: <062.77e3d72eddd9c148eee2850cc57d873d@haskell.org> #8710: Overlapping patterns warning misplaced -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gkaracha): Replying to [comment:3 thomie]: > I would maybe prefer separate warnings, such that even for a single redundant clause, the warning message doesn't have to mention two different line numbers (one for the location of the whole match, and one for the location of the redundant clause). > > I don't know if there is precedent for multiple line numbers in a warning message. > > Either way is fine though. I created a small patch for this (Phab:D1910). If we print a separate warning for every redundant clause it may become overwhelming so I thought that it would be best to keep them all in the same warning. The patch has the following behavior: {{{ Bug.hs:22:3: warning: Pattern match(es) are overlapped In an equation for ?show?: len _ = ... (at Bug.hs:24:3) len _ = ... (at Bug.hs:25:3) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 13 22:20:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 13 Feb 2016 22:20:56 -0000 Subject: [GHC] #8710: Overlapping patterns warning misplaced In-Reply-To: <047.1f227e0dac37dd7309646386f280164b@haskell.org> References: <047.1f227e0dac37dd7309646386f280164b@haskell.org> Message-ID: <062.f3e29e3d737481012d7dd8ed8e191298@haskell.org> #8710: Overlapping patterns warning misplaced -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1910 Wiki Page: | -------------------------------------+------------------------------------- Changes (by gkaracha): * differential: => Phab:D1910 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 03:08:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 03:08:04 -0000 Subject: [GHC] #8710: Overlapping patterns warning misplaced In-Reply-To: <047.1f227e0dac37dd7309646386f280164b@haskell.org> References: <047.1f227e0dac37dd7309646386f280164b@haskell.org> Message-ID: <062.0e5dacf7d2027a393c8f08627bafdf56@haskell.org> #8710: Overlapping patterns warning misplaced -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1910 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Looks great to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 03:47:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 03:47:12 -0000 Subject: [GHC] #11575: Program crashes only when compiled via LLVM Message-ID: <049.d1272a840a63edf1ed87ef1d7e8f2f1e@haskell.org> #11575: Program crashes only when compiled via LLVM --------------------------------------+---------------------------------- Reporter: Guest00000 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 7.10.3 Keywords: llvm | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+---------------------------------- `llvm-test.hs`: {{{#!hs import System.IO import Foreign.Storable import Foreign.Marshal.Alloc import Data.Word main = do hSetBuffering stdout NoBuffering test 1000 test 5000 where test n = do allocaBytes (n * 4) $ \p -> do sequence_ [ pokeByteOff p (i * 4) (0x12345678 :: Word32) | i <- [ 0 .. n - 1 ] ] putStrLn $ show n ++ " fine" }}} ---- Cygwin shell: {{{ user at pc ~ $ ghc llvm-test.hs && ./llvm-test.exe [1 of 1] Compiling Main ( llvm-test.hs, llvm-test.o ) Linking llvm-test.exe ... 1000 fine 5000 fine user at pc ~ $ touch llvm-test.hs user at pc ~ $ ghc llvm-test.hs -fllvm && ./llvm-test.exe [1 of 1] Compiling Main ( llvm-test.hs, llvm-test.o ) Linking llvm-test.exe ... 1000 fine Segmentation fault }}} ---- {{{ `Guest00000: try adding -O2 to the compiler command line. <`Guest00000> erikd: it now segfaults even before printing "1000 fine" <`Guest00000> wait, one time it printed one character "1" before crashing }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 05:38:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 05:38:12 -0000 Subject: [GHC] #11575: Program crashes only when compiled via LLVM In-Reply-To: <049.d1272a840a63edf1ed87ef1d7e8f2f1e@haskell.org> References: <049.d1272a840a63edf1ed87ef1d7e8f2f1e@haskell.org> Message-ID: <064.c529d1add3710bdbfa3991a85b92c516@haskell.org> #11575: Program crashes only when compiled via LLVM ----------------------------------+-------------------------------------- Reporter: Guest00000 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 7.10.3 Resolution: | Keywords: llvm Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+-------------------------------------- Comment (by erikd): This code compiles and runs correctly on Linux/x86_64, both with and with `-fllvm`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 13:24:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 13:24:08 -0000 Subject: [GHC] #11567: Haddock renders wired-in types with kind signature In-Reply-To: <046.9da84f84610001ab70d0d61e4b2e51a9@haskell.org> References: <046.9da84f84610001ab70d0d61e4b2e51a9@haskell.org> Message-ID: <061.13bfd015d6588e86fbf26859734e91ce@haskell.org> #11567: Haddock renders wired-in types with kind signature -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Documentation | Version: 7.10.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid Comment: Ryan pointed out that these signatures are shown because the modules which export these types have `KindSignatures` enabled. Given that this behavior was exhibited by earlier releases as well, this doesn't seem like a bug. Now that `*` is now rendered as `*` thanks to Ryan's Haddock fix, I'm going to close this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 13:35:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 13:35:49 -0000 Subject: [GHC] #11574: schedule: re-entered unsafely on minimal hello world program on arm In-Reply-To: <051.5f65ae7b7de5c2aba500f9eaf01974c1@haskell.org> References: <051.5f65ae7b7de5c2aba500f9eaf01974c1@haskell.org> Message-ID: <066.f129a77968f3323d0965b2a7b065222f@haskell.org> #11574: schedule: re-entered unsafely on minimal hello world program on arm ----------------------------------+---------------------------------- Reporter: andrewufrank | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------- Changes (by bgamari): * status: new => infoneeded @@ -4,1 +4,2 @@ - {{{testthree: schedule: re-entered unsafely. + {{{ + testthree: schedule: re-entered unsafely. New description: i installed ghc 7.10.3 from jessie-backports (together with the corresponding LLVM 1:3.5.2.3~bpo8+2) and get for the minimal main = putStrLn "hello" program the error message {{{ testthree: schedule: re-entered unsafely. Perhaps a 'foreign import unsafe' should be 'safe'? }} i am not certain if this is related: cabal install for the same minimal program (with a minimal cabal file) hangs. cabal install -v gives {{{ /home/frank/.cabal/setup-exe-cache/setup-Simple-Cabal-1.22.5.0-arm-linux- ghc-7.10.3 configure --verbose=2 --ghc --prefix=/home/frank/.cabal --bindir=/home/frank/.cabal/bin --libdir=/home/frank/.cabal/lib --libsubdir=arm-linux-ghc-7.10.3/testthree-0.0.6-3AgAf9bDkWJGZdbGLvO875 --libexecdir=/home/frank/.cabal/libexec --datadir=/home/frank/.cabal/share --datasubdir=arm-linux-ghc-7.10.3/testthree-0.0.6 --docdir=/home/frank/.cabal/share/doc/arm-linux-ghc-7.10.3/testthree-0.0.6 --htmldir=/home/frank/.cabal/share/doc/arm-linux- ghc-7.10.3/testthree-0.0.6/html --haddockdir=/home/frank/.cabal/share/doc/arm-linux- ghc-7.10.3/testthree-0.0.6/html --sysconfdir=/home/frank/.cabal/etc --user --extra-prog-path=/home/frank/.cabal/bin --dependency=base=base-4.8.2.0-2f1f71a7fcf013cd47fd21f489064f9a --disable-tests --exact-configuration --disable-benchmarks Redirecting build log to {handle: /home/frank/.cabal/logs/testthree-0.0.6.log} }}} any comment how this can be fixed? thank you - a running 7.10.3 for armhf is a great achievement! -- Comment: I agree with rwbarton; this is characteristic of a buggy LLVM release. Can you try LLVM 3.5.2? A binary distribution is available [http://llvm.org/releases/3.5.2/clang+llvm-3.5.2-armv7a-linux- gnueabihf.tar.xz|here]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 13:39:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 13:39:19 -0000 Subject: [GHC] #11549: Add -fshow-runtime-rep In-Reply-To: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> References: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> Message-ID: <062.9b41d21a108dad4337b1efe19b944171@haskell.org> #11549: Add -fshow-runtime-rep -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.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 bgamari): * cc: bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 13:53:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 13:53:52 -0000 Subject: [GHC] #11576: renamer discards name location for HsRecField Message-ID: <044.1064c2f83d32fde867ff7dc0ad2e6598@haskell.org> #11576: renamer discards name location for HsRecField -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When renaming a `HsVar` it can be converted to a `HsRecField`. In the process the location of the enclosed name is converted to a `noLoc` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 14:07:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 14:07:28 -0000 Subject: [GHC] #11574: schedule: re-entered unsafely on minimal hello world program on arm In-Reply-To: <051.5f65ae7b7de5c2aba500f9eaf01974c1@haskell.org> References: <051.5f65ae7b7de5c2aba500f9eaf01974c1@haskell.org> Message-ID: <066.ab2ff011cd6a8bfed715440a136318fc@haskell.org> #11574: schedule: re-entered unsafely on minimal hello world program on arm ----------------------------------+---------------------------------- Reporter: andrewufrank | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------- Comment (by andrewufrank): i indicated in the report what i see in synaptic for llvm, namely LLVM 1:3.5.2.3~bpo8+2. i downloaded and unpacked the indicated files, but they do not include instructions how to install. it seems not to be ./configure + make. where do i have to copy the unpacked files? can you point me to some instructions? thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 15:29:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 15:29:39 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages In-Reply-To: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> References: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> Message-ID: <067.86e429f7b5342dcfbc31542c29a744e1@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): here are two more instances where compile time does increase substantially. {{{ 7.6 7.8 7.10 tpdb 4 6 13 (minutes of travis build time) obdd 2 2 5 }}} https://travis-ci.org/jwaldmann/haskell-tpdb https://travis-ci.org/jwaldmann/haskell-obdd -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 16:01:03 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 16:01:03 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages In-Reply-To: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> References: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> Message-ID: <067.a5f589252def392517b05626b3e35ee6@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Hmm, I wouldn't take those Travis times very seriously... I ran approximately the same sequence of commands locally, and `cabal build` took 3 seconds, not the 2.5 ''minutes'' reported by Travis. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 16:01:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 16:01:32 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages In-Reply-To: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> References: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> Message-ID: <067.488e083c9c8b697ba1566de9eb25df14@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Can you try with 7.10.3 instead of 7.10.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 16:17:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 16:17:32 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages In-Reply-To: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> References: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> Message-ID: <067.999abc49dc3c46ed8e1c6ae28968b449@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): Yes it's not clear (to me) what the travis timing data actually measures. I was hoping it's CPU time allocated to the build process. Of course if it's wall clock then all bets are off. Or, if time includes waiting for the cabal downloads ... > 3 sec for obdd Really. On my local machine, more like 30 seconds (single-threaded build) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 16:26:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 16:26:15 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages In-Reply-To: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> References: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> Message-ID: <067.a8f1ed60bd484f5f2b01b5bda9ffef83@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): {{{ rwbarton at morphism:/tmp/haskell-obdd$ cabal-super2 clean cleaning... rwbarton at morphism:/tmp/haskell-obdd$ cabal-super2 configure -w ghc-7.10.1 --with-hc-pkg ghc-pkg-7.10.1 --enable-tests --enable-benchmarks --disable- shared Resolving dependencies... Configuring obdd-0.3.3... rwbarton at morphism:/tmp/haskell-obdd$ time cabal-super2 build Building obdd-0.3.3... Preprocessing library obdd-0.3.3... [1 of 7] Compiling OBDD.IntIntMap ( src/OBDD/IntIntMap.hs, dist/build/OBDD/IntIntMap.o ) [2 of 7] Compiling OBDD.VarIntIntMap ( src/OBDD/VarIntIntMap.hs, dist/build/OBDD/VarIntIntMap.o ) [3 of 7] Compiling OBDD.Data ( src/OBDD/Data.hs, dist/build/OBDD/Data.o ) [4 of 7] Compiling OBDD.Make ( src/OBDD/Make.hs, dist/build/OBDD/Make.o ) [5 of 7] Compiling OBDD.Operation ( src/OBDD/Operation.hs, dist/build/OBDD/Operation.o ) [6 of 7] Compiling OBDD.Property ( src/OBDD/Property.hs, dist/build/OBDD/Property.o ) [7 of 7] Compiling OBDD ( src/OBDD.hs, dist/build/OBDD.o ) Preprocessing test suite 'obdd-placement' for obdd-0.3.3... [1 of 1] Compiling Main ( examples/Placement.hs, dist/build /obdd-placement/obdd-placement-tmp/Main.o ) Linking dist/build/obdd-placement/obdd-placement ... Preprocessing test suite 'obdd-queens' for obdd-0.3.3... [1 of 1] Compiling Main ( examples/Queens.hs, dist/build/obdd- queens/obdd-queens-tmp/Main.o ) Linking dist/build/obdd-queens/obdd-queens ... real 0m3.187s user 0m2.916s sys 0m0.212s }}} (I have a lot of cabal versions installed.) This is without a sandbox, if that matters somehow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 16:35:22 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 16:35:22 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages In-Reply-To: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> References: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> Message-ID: <067.f17ff3188fe3aee133b23fe97e5857ce@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): Oh, I was timing "cabal install" (not just "cabal build") because I assume that is what is being timed on travis. Meanwhile, I did repeat the builds with 7.10.3 instead of 7.10.2, see https://travis-ci.org/jwaldmann/haskell-tpdb/builds/109177528 https://travis-ci.org/jwaldmann/haskell-obdd/builds/109179019 and results look similar to before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 16:41:24 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 16:41:24 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages In-Reply-To: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> References: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> Message-ID: <067.4c7bf343f0a2bab122100ab3b9b9647a@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Travis shows the time executed for each command at the right. So https ://travis-ci.org/jwaldmann/haskell-obdd/jobs/108860083#L233 shows `cabal build` taking ~150 seconds for example. Though I don't know how to reconcile that with the whole job taking "5 min 16 sec", since the other times reported add up to less than a minute. I'm assuming Travis build machines are under huge load and memory pressure, and it's probably unreasonable to expect anything out of the build times beyond "if you make the build more efficient, the numbers will go down, probably". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 16:53:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 16:53:43 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages In-Reply-To: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> References: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> Message-ID: <067.1fe9c4c8cd81943d41342ae569197c47@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I have to say I don't really understand `cabal install` taking 30 seconds either; unless it includes either building your dependencies (random, mtl) or the slowest operation known to man, "Updating documentation index" in the global package database. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 17:00:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 17:00:30 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages In-Reply-To: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> References: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> Message-ID: <067.9fa59dafe5f965508ac7d3cd97eccd16@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): ... both! (well, update doc index in the sandbox only) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 18:04:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 18:04:04 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.edbcd55f4cd5e9b72715e61c0dc9105a@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by mfox): @erikd {{{ binutils-2.26 ld.gold --version GNU gold (GNU Binutils 2.26.20160125) 1.11 ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 cabal get hello Downloading hello-1.0.0.2... Unpacking to hello-1.0.0.2/ admin at vectorious2:~/src$ cd hello-1.0.0.2/ admin at vectorious2:~/src/hello-1.0.0.2$ cabal build Package has never been configured. Configuring with default flags. If this fails, please run configure manually. Resolving dependencies... Configuring hello-1.0.0.2... Building hello-1.0.0.2... Preprocessing executable 'hello' for hello-1.0.0.2... ghc: setNumCapabilities: not supported on this platform [1 of 1] Compiling Main ( src/hello.hs, dist/build/hello /hello-tmp/Main.o ) Linking dist/build/hello/hello ... admin at vectorious2:~/src/hello-1.0.0.2$ ls dist hello.cabal LICENSE Setup.hs src admin at vectorious2:~/src/hello-1.0.0.2$ ./dist/ build/ package.conf.inplace/ admin at vectorious2:~/src/hello-1.0.0.2$ ./dist/build/ autogen/ hello/ admin at vectorious2:~/src/hello-1.0.0.2$ ./dist/build/hello/hello Hello, World! llc --version LLVM (http://llvm.org/): LLVM version 3.7.1 DEBUG build with assertions. Built Feb 8 2016 (22:06:00). Default target: aarch64-unknown-linux-gnu Host CPU: (unknown) aptitude search llvm | egrep "^i" i A libllvm3.4 - Modular compiler and toolchain technologie id llvm-3.4-runtime - Modular compiler and toolchain technologie cat /proc/cpuinfo processor : 0 [nid: 0] Features : fp asimd aes pmull sha1 sha2 crc32 CPU implementer : 0x43 CPU architecture: 8 CPU variant : 0x0 CPU part : 0x0a1 CPU revision : 0 }}} How else can I help? Do you want to try screen sharing? May be more productive in getting you on track. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 18:06:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 18:06:46 -0000 Subject: [GHC] #11577: GHCi accepts invalid programs when recompiling Message-ID: <047.2a12c44ccefc548e437422f83a607aa3@haskell.org> #11577: GHCi accepts invalid programs when recompiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.2-rc2 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: -------------------------------------+------------------------------------- This ticket may or may not be a duplicate of #9729, but I ran into it again in a different context, so I'm reporting it. My GHC version is 7.10.2.20151030. The example is as minimal as I could make it. File Bar.hs {{{ {-# LANGUAGE FlexibleInstances, MultiParamTypeClasses #-} module Bar where class Bar a b where (*^) :: a -> b -> b }}} File Foo.hs {{{ {-# LANGUAGE MultiParamTypeClasses #-} module Foo where import Bar import GHC.Prim newtype Foo fp = Foo [fp] instance {-# OVERLAPS #-} Bar (Foo fp) [fp] }}} File Main.hs {{{ {-# LANGUAGE MultiParamTypeClasses #-} import Foo import Bar newtype LW a = LW [a] instance Bar (Foo fp) (LW fp) where r *^ (LW xs) = LW $ r *^ xs }}} If I start GHCi with `ghci Main`, everything compiles as it should. Then I remove the `{-# OVERLAPS #-}` pragma in Foo.hs, which should break Main.hs. But GHCi happily recompiles with `:r`. A couple of notes: *with* the pragma, `:i Bar` gives the instances {{{ instance Bar (Foo fp) (LW fp) -- Defined at Main.hs:8:10 instance Bar a b => Bar a [b] -- Defined at Bar.hs:8:10 instance [overlap ok] Bar (Foo fp) [fp] -- Defined at Foo.hs:22:3 }}} while after (successfully, but incorrectly) recompiling without the pragma, I get the instances {{{ instance Bar (Foo fp) (LW fp) -- Defined at Main.hs:8:10 instance Bar a b => Bar a [b] -- Defined at Bar.hs:8:10 instance Bar (Foo fp) [fp] -- Defined at Foo.hs:22:3 }}} (i.e., without the `[overlap ok]`). Another strange thing is that the bug is only triggered if I import specific (superfluous) modules in Foo.hs. For example, if I replace GHC.Prim with Control.Monad or Data.Maybe, the bug is not triggered (i.e., GHCi correctly detects when I remove the pragma). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 18:35:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 18:35:41 -0000 Subject: [GHC] #2159: Use a more efficient representation than [DynFlag] In-Reply-To: <044.7464fd042e6f0696195045db2d1740fe@haskell.org> References: <044.7464fd042e6f0696195045db2d1740fe@haskell.org> Message-ID: <059.2a69907a12cc89f522a131cefcd1a50b@haskell.org> #2159: Use a more efficient representation than [DynFlag] -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Unless I am mistaken this has already been implemented. `DynFlags` now represents dump flags, extension flags, and general flags as `IntSet`s, using the `Enum` instances of the respective types to map each flag to a bit. I'm not entirely sure when this change was made but it was quite a while ago. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 18:41:50 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 18:41:50 -0000 Subject: [GHC] #2159: Use a more efficient representation than [DynFlag] In-Reply-To: <044.7464fd042e6f0696195045db2d1740fe@haskell.org> References: <044.7464fd042e6f0696195045db2d1740fe@haskell.org> Message-ID: <059.1aaef4f7403d4cb25981c7cd441b4e8e@haskell.org> #2159: Use a more efficient representation than [DynFlag] -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: fixed | 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 rwbarton): Heh, I was just looking at this too. I imagine a bit array representation as in "bitmap.dpatch" would be a lot faster though. Especially if you added RULES to inline the case of checking for a known flag. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 19:51:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 19:51:28 -0000 Subject: [GHC] #11576: renamer discards name location for HsRecField In-Reply-To: <044.1064c2f83d32fde867ff7dc0ad2e6598@haskell.org> References: <044.1064c2f83d32fde867ff7dc0ad2e6598@haskell.org> Message-ID: <059.982aa329354456582af1132061febd13@haskell.org> #11576: renamer discards name location for HsRecField -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Alan Zimmerman ): In [changeset:"cd4a7d07890fa53c455c14f22c2d30c22b64a396/ghc" cd4a7d07/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="cd4a7d07890fa53c455c14f22c2d30c22b64a396" renamer discards name location for HsRecField When renaming a HsVar it can be converted to a HsRecField. In the process the location of the enclosed name is converted to a noLoc Closes #11576 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 19:56:24 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 19:56:24 -0000 Subject: [GHC] #2159: Use a more efficient representation than [DynFlag] In-Reply-To: <044.7464fd042e6f0696195045db2d1740fe@haskell.org> References: <044.7464fd042e6f0696195045db2d1740fe@haskell.org> Message-ID: <059.9c8d54dee3d790bbbbb81bc18e32eefe@haskell.org> #2159: Use a more efficient representation than [DynFlag] -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: fixed | 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 rwbarton): Well the bit array was 4x faster than IntSet in my unscientific test. And it would probably be a bit faster still when the option to test is known and can be inlined. But there could be little left to gain after the switch to IntSet. A pretty easy experiment to do, if we had an easy way to benchmark compiler performance... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 20:03:15 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 20:03:15 -0000 Subject: [GHC] #11569: make -j24 test In-Reply-To: <043.ebd4ab4cf2b889476fd8b09d162a3605@haskell.org> References: <043.ebd4ab4cf2b889476fd8b09d162a3605@haskell.org> Message-ID: <058.fda967f7e5494d3105fb18574ff68238@haskell.org> #11569: make -j24 test -------------------------------+------------------------------- Reporter: mfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 8.1 Resolution: invalid | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+------------------------------- Changes (by thomie): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 20:14:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 20:14:21 -0000 Subject: [GHC] #11574: schedule: re-entered unsafely on minimal hello world program on arm In-Reply-To: <051.5f65ae7b7de5c2aba500f9eaf01974c1@haskell.org> References: <051.5f65ae7b7de5c2aba500f9eaf01974c1@haskell.org> Message-ID: <066.edef070119c078a99b7e9e9a7c633284@haskell.org> #11574: schedule: re-entered unsafely on minimal hello world program on arm ----------------------------------+---------------------------------- Reporter: andrewufrank | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------- Description changed by thomie: @@ -7,1 +7,1 @@ - }} + }}} New description: i installed ghc 7.10.3 from jessie-backports (together with the corresponding LLVM 1:3.5.2.3~bpo8+2) and get for the minimal main = putStrLn "hello" program the error message {{{ testthree: schedule: re-entered unsafely. Perhaps a 'foreign import unsafe' should be 'safe'? }}} i am not certain if this is related: cabal install for the same minimal program (with a minimal cabal file) hangs. cabal install -v gives {{{ /home/frank/.cabal/setup-exe-cache/setup-Simple-Cabal-1.22.5.0-arm-linux- ghc-7.10.3 configure --verbose=2 --ghc --prefix=/home/frank/.cabal --bindir=/home/frank/.cabal/bin --libdir=/home/frank/.cabal/lib --libsubdir=arm-linux-ghc-7.10.3/testthree-0.0.6-3AgAf9bDkWJGZdbGLvO875 --libexecdir=/home/frank/.cabal/libexec --datadir=/home/frank/.cabal/share --datasubdir=arm-linux-ghc-7.10.3/testthree-0.0.6 --docdir=/home/frank/.cabal/share/doc/arm-linux-ghc-7.10.3/testthree-0.0.6 --htmldir=/home/frank/.cabal/share/doc/arm-linux- ghc-7.10.3/testthree-0.0.6/html --haddockdir=/home/frank/.cabal/share/doc/arm-linux- ghc-7.10.3/testthree-0.0.6/html --sysconfdir=/home/frank/.cabal/etc --user --extra-prog-path=/home/frank/.cabal/bin --dependency=base=base-4.8.2.0-2f1f71a7fcf013cd47fd21f489064f9a --disable-tests --exact-configuration --disable-benchmarks Redirecting build log to {handle: /home/frank/.cabal/logs/testthree-0.0.6.log} }}} any comment how this can be fixed? thank you - a running 7.10.3 for armhf is a great achievement! -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 20:19:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 20:19:58 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.ac11f9126ed908343ee83bb968d0cb92@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Do you now have llvm 3.5 installed? The GHC 7.10 release *requires* LLVM version 3.5. What does `ghc --info` say? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 20:31:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 20:31:33 -0000 Subject: [GHC] #8278: Improve error message when the same type is imported from two different library versions In-Reply-To: <044.b4ff53b1f7bce9508c7f6f66eb6f72da@haskell.org> References: <044.b4ff53b1f7bce9508c7f6f66eb6f72da@haskell.org> Message-ID: <059.7411dc6f69ba94a311730da28884c382@haskell.org> #8278: Improve error message when the same type is imported from two different library versions -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/tcfail182 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dmwit): Just wanted to pipe up and say I've just been hit by the problem in Comment 2. It seems it doesn't happen very often; but when it does happen it's quite confusing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 20:36:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 20:36:28 -0000 Subject: [GHC] #11470: Support changing cross compiler target at runtime In-Reply-To: <045.fac441a3726b1539e9f173129f6fb28c@haskell.org> References: <045.fac441a3726b1539e9f173129f6fb28c@haskell.org> Message-ID: <060.2d0448ad96600d12a1502456b196d828@haskell.org> #11470: Support changing cross compiler target at runtime -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11378 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by luite): I'd be happy to help with this. Fortunately there is not all that much information about the target platform hardcoded in GHC anymore. I think a new cross compilation target could be added by pointing GHC to some target-specific `settings` file. This file should also specify how to run TH and GHCi (for example via the external interpreter for general TH and by loading code from another package DB for host-only TH) We would create an `initialize-target` tool that: * queries the toolchain and generates an appropriate `settings` file * (possibly) builds an initial set of packages for the target, similar to what ships with GHC I think this is still reasonably straightforward, and I think it would be a good first step, and would mainly involve separating part of the build system and making sure that all relevant configuration options can indeed be specified by `settings`. This should allow cross compilers to load native code for plugins (the code generator for the target could even be a plugin). For the next step, my main concern would be how to match up the host and target architecture package databases for things like host-only TH. Say a cross compiler needs to run some host-only TH, which means it probably needs to load some code from a host-arch package DB: * Who is responsible for the code to be there? Will `cabal-install` make sure that a host version of a package is built and registered before a target version? * ABI hashes will likely be different between architectures: do we just require transitive version numbers to be the same? Or should there be a way to link hashes between architectures? (if we match on version numbers, i suspect we may lose things like cabal flag settings) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 20:41:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 20:41:48 -0000 Subject: [GHC] #10576: REPL returns list of all imported names when operator completion requested In-Reply-To: <047.d28f43369ab4f4eebeb74c70f6d59630@haskell.org> References: <047.d28f43369ab4f4eebeb74c70f6d59630@haskell.org> Message-ID: <062.9943fd4bbe9b025bab82acaa4a6813b2@haskell.org> #10576: REPL returns list of all imported names when operator completion requested -------------------------------------+------------------------------------- Reporter: Geraldus | Owner: Geraldus Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: | Keywords: completions | complete command operator Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: ghci/prog017 at runtime | ghci/scripts/T10576a T10576b Blocked By: | Blocking: Related Tickets: #9996 | Differential Rev(s): Phab:D1058 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => ghci/prog017 ghci/scripts/T10576a T10576b Comment: Update. This works: {{{ Prelude> (??) _ _ = () Prelude> x1 ? }}} This doesn't work: {{{ Prelude> (??) _ _ = () Prelude> x1? }}} A space is needed between the variable and the operator for completion to work. To solve this nicely requires adding a function to haskeline, similar to `completeWord`, but which takes a predicate function instead of a list of escape characters. The tests `T10576a` and `T10576b` are marked `expect_broken` for this issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 20:55:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 20:55:13 -0000 Subject: [GHC] #3693: Show stack traces In-Reply-To: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> References: <043.7c288f8e774d3806292d73b1513892ec@haskell.org> Message-ID: <058.414e5b42b1aef3184b92374602d5446a@haskell.org> #3693: Show stack traces -------------------------------------+------------------------------------- Reporter: jpet | Owner: Tarrasch Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 6.10.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10656 | Differential Rev(s): -------------------------------------+------------------------------------- Changes (by Slavon8): * Attachment "93098974.png" removed. [http://smartmiltoys.com/kidkraft-train-table/ http://smartmiltoys.com /kidkraft-train-table/] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 21:08:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 21:08:08 -0000 Subject: [GHC] #9611: Suggest the cause of "No instance" errors involving multiple versions of a package In-Reply-To: <047.46300571edbd036da850eb10c4f281a5@haskell.org> References: <047.46300571edbd036da850eb10c4f281a5@haskell.org> Message-ID: <062.989803c2538acb4e768af3ae74e6d328@haskell.org> #9611: Suggest the cause of "No instance" errors involving multiple versions of a package -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dmwit): * cc: me@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 21:40:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 21:40:04 -0000 Subject: [GHC] #11576: renamer discards name location for HsRecField In-Reply-To: <044.1064c2f83d32fde867ff7dc0ad2e6598@haskell.org> References: <044.1064c2f83d32fde867ff7dc0ad2e6598@haskell.org> Message-ID: <059.32652538d9a0a3b72ab7e6608803ad74@haskell.org> #11576: renamer discards name location for HsRecField -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 21:44:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 21:44:55 -0000 Subject: [GHC] #11558: Using Cabal 1.22 against GHC 8.0 results in unhelpful errors In-Reply-To: <046.d2616ea949ac4d1153655c6314ef5133@haskell.org> References: <046.d2616ea949ac4d1153655c6314ef5133@haskell.org> Message-ID: <061.1446ffd7330f6c04e516a594063573ce@haskell.org> #11558: Using Cabal 1.22 against GHC 8.0 results in unhelpful errors -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Package system | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1892 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 21:45:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 21:45:26 -0000 Subject: [GHC] #8278: Improve error message when the same type is imported from two different library versions In-Reply-To: <044.b4ff53b1f7bce9508c7f6f66eb6f72da@haskell.org> References: <044.b4ff53b1f7bce9508c7f6f66eb6f72da@haskell.org> Message-ID: <059.6d3539a0c078b31e97299b9cd9e5b992@haskell.org> #8278: Improve error message when the same type is imported from two different library versions -------------------------------------+------------------------------------- Reporter: Yuras | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/tcfail182 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): #9611 is the ticket for comment:2, I believe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 21:47:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 21:47:19 -0000 Subject: [GHC] #11454: Do not suggest deprecated flags In-Reply-To: <045.65a0f03026a0fefacb4854cc40024538@haskell.org> References: <045.65a0f03026a0fefacb4854cc40024538@haskell.org> Message-ID: <060.64cec276f8e7aca19fe8691d578cbe13@haskell.org> #11454: Do not suggest deprecated flags -------------------------------------+------------------------------------- Reporter: thomie | Owner: nkartashov Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 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: | Differential Rev(s): Phab:D1883 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Thanks @nkartashov and @bgamari! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 21:53:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 21:53:35 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.838763cbd24c04a2db1a1c29357fcee2@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1891 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * differential: => Phab:D1891 Comment: As the differential states, there are still some performance issues to be worked out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 22:02:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 22:02:53 -0000 Subject: [GHC] #11316: Too many guards warning causes issues In-Reply-To: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> References: <051.c76bd2f743d3c95a645475e298a847e3@haskell.org> Message-ID: <066.8f48f52cdc727f200e14f1ec5d0a3576@haskell.org> #11316: Too many guards warning causes issues -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11163, #11276 | Differential Rev(s): Phab:D1737 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: 8.2.1 => 8.0.1 Comment: Commit 28f951edfe50ea5182065144340061ec326781f5 deleted the "too many guards" warning completely, so I think this particular ticket can be closed now. {{{ Author: George Karachalias Date: Wed Feb 3 19:06:45 2016 +0100 Overhaul the Overhauled Pattern Match Checker }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 14 23:41:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 14 Feb 2016 23:41:57 -0000 Subject: [GHC] #10800: vector-0.11 compile time increased substantially with 7.10.1 In-Reply-To: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> References: <046.b08e48c7e3091b06d4d1122f9be87efe@haskell.org> Message-ID: <061.764b144fe6434f690e708823fd931a3a@haskell.org> #10800: vector-0.11 compile time increased substantially with 7.10.1 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I have noticed that there is a qualitative difference in the verbose- core2core output between 7.8.4 and 7.10.3: namely 7.8 lacks an initial gentle simplifier pass. In the case of 7.10.3 the compiler inlines `Data.Vector.Generic.zip` in the `SimplMode {Phase = 2 [main], inline, rules, eta-expand, case-of-case}` pass, producing a significant amount of unresolved `stream`/`unstream` pairs relatively early in simplification. The last appearance of `unstream` doesn't disappear until `SimplMode {Phase = 0 [main], inline, rules, eta-expand, case-of-case}`. By contrast, 7.8.4 doesn't perform this inlining until much later (right before the second FloatOut; it's a bit hard to tell precisely since `verbose-core2core` doesn't output simplifier passes). As far as I can tell, it manages to collapse all of the stream fusion apparatus in a single simplifier pass. I believe this may be the reason for the difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 01:09:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 01:09:15 -0000 Subject: [GHC] #11362: T6137 doesn't pass with reversed uniques In-Reply-To: <046.176cbdce58fe0c2949bc42c9d1fa1775@haskell.org> References: <046.176cbdce58fe0c2949bc42c9d1fa1775@haskell.org> Message-ID: <061.fd3443c8554ee48513a1672211376bce@haskell.org> #11362: T6137 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: 4012 Related Tickets: #11371 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): After clearing the `substTy` sanity check I'm back here with the original issue and I need some input on the underlying assumptions. The test fails with a lint failure: {{{ *** Core Lint errors : in result of Tidy Core *** : warning: [in body of lambda with binder dt_a18nZe :: In g_a18o6Y (Sum1 r_a18o6X (In ('F g_a18o6Y) r_a18o6X)) v_a18o6W] Kind application error in coercion ?Sym (D:R:InjuFrv0[0] _N _N _N) _N _N? Function kind = Code (Sum j_a18nZC u_a18nZB) u_a18nZB -> * Arg kinds = [(v_a18o6W, u_a18nZB)] : warning: [in body of lambda with binder dt_a18nZe :: In g_a18o6Y (Sum1 r_a18o6X (In ('F g_a18o6Y) r_a18o6X)) v_a18o6W] Kind application error in coercion ?Sym (D:R:InjuFrv0[0] _N _N _N) _N _N? Function kind = Code (Sum j_a18nZC u_a18nZB) u_a18nZB -> * Arg kinds = [(v_a18o6W, u_a18nZB)] *** Offending Program *** $WMkIn [InlPrag=INLINE] :: forall u_a18nZB j_a18nZC (g_a18o6Y :: Code (Sum j_a18nZC u_a18nZB) u_a18nZB) (r_a18o6X :: j_a18nZC -> *) (v_a18o6W :: u_a18nZB). In g_a18o6Y (Sum1 r_a18o6X (In ('F g_a18o6Y) r_a18o6X)) v_a18o6W -> In ('F g_a18o6Y) r_a18o6X v_a18o6W [GblId[DataConWrapper], Arity=1, Caf=NoCafRefs, Str=DmdType m, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=False,boring_ok=True) Tmpl= \ (@ u_a18nZB) (@ j_a18nZC) (@ (g_a18o6Y :: Code (Sum j_a18nZC u_a18nZB) u_a18nZB)) (@ (r_a18o6X :: j_a18nZC -> *)) (@ (v_a18o6W :: u_a18nZB)) (dt_a18nZe [Occ=Once] :: In g_a18o6Y (Sum1 r_a18o6X (In ('F g_a18o6Y) r_a18o6X)) v_a18o6W) -> (MkIn @ u_a18nZB @ j_a18nZC @ g_a18o6Y @ r_a18o6X @ v_a18o6W dt_a18nZe) `cast` (Sym (D:R:InjuFrv0[0] _N _N _N) _N _N }}} This didn't tell me much, so I kept digging. It seems that the case for `AxiomInstCo` in `lintCoercion`: {{{ lintCoercion co@(AxiomInstCo con ind cos) = do { unless (0 <= ind && ind < numBranches (coAxiomBranches con)) (bad_ax (text "index out of range")) ; let CoAxBranch { cab_tvs = ktvs , cab_cvs = cvs , cab_roles = roles , cab_lhs = lhs , cab_rhs = rhs } = coAxiomNthBranch con ind ; unless (length ktvs + length cvs == length cos) $ bad_ax (text "lengths") ; subst <- getTCvSubst ; let empty_subst = zapTCvSubst subst ; (subst_l, subst_r) <- foldlM check_ki (empty_subst, empty_subst) (zip3 (ktvs ++ cvs) roles cos) ; let lhs' = substTys subst_l lhs rhs' = substTy subst_r rhs ; case checkAxInstCo co of Just bad_branch -> bad_ax $ text "inconsistent with" <+> pprCoAxBranch con bad_branch Nothing -> return () ; let s2 = mkTyConApp (coAxiomTyCon con) lhs' ; return (typeKind s2, typeKind rhs', s2, rhs', coAxiomRole con) } }}} assumes that `cab_lhs` and `cab_rhs` are in the same "order". When I printed out `cab_lhs` and `cab_rhs` I got `[j_a18o0a, u_a18o09, 'F g_a18o71]` and `R:InjuFrv u_a18o09 j_a18o0a g_a18o71` respectively (they do match up if I don't reverse the order of uniques). Later when we try to kind check `rhs'` and `s2 = mkTyConApp (coAxiomTyCon con) lhs'` we get a kind error. I don't know if the order is assumed to match up, there's no comment about that on the `CoAxBranch` constructor. If the assumption is that it should match up then the call to `mkSingleCoAxiom` in `tcDataFamInstDecl` breaks that. It reads: {{{ mkSingleCoAxiom Representational axiom_name eta_tvs [] fam_tc eta_pats (mkTyConApp rep_tc (mkTyVarTys eta_tvs)) }}} Where the last two parameters are `cab_lhs` and `cab_rhs` respectively. Notice that the "order" for `cab_rhs` is the same as the order of `eta_tvs`. This in turn is the order that `tcFamTyPats` returns them in. If we look at the code for `tcFamTyPats` the reordering happens when we call `qtkvs <- quantifyTyVars emptyVarSet $ splitDepVarsOfTypes typat`. `quantifyTyVars` takes a `VarSet` and then converts it into a list, effectively sorting by the value of the associated `Unique`. It's possible that I'm interpreting it wrong, any advice would be appreciated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 02:41:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 02:41:54 -0000 Subject: [GHC] #11566: I don't need madvise MADV_DONTNEED In-Reply-To: <043.ae7447db31f335ef6697823ae5dfc604@haskell.org> References: <043.ae7447db31f335ef6697823ae5dfc604@haskell.org> Message-ID: <058.bbe524111ab63bad66dc12e6943de233@haskell.org> #11566: I don't need madvise MADV_DONTNEED -------------------------------------+------------------------------------- Reporter: mfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Large address space should work on Arm64. At least it does on the server grade machine that I', testing on. Interestingly I had reduce the mmap size from 1TB to 1/4 TB (see commit 38c98e4f6). I'm currently doing my testing on base machine with Ubuntu 15.04 but doing all my testing in a Debian Chroot. The base kernel is `3.19.0-31-generic #36-Ubuntu SMP`. Can you tell tell which tests fail with the above error message? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 02:51:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 02:51:18 -0000 Subject: [GHC] #11566: I don't need madvise MADV_DONTNEED In-Reply-To: <043.ae7447db31f335ef6697823ae5dfc604@haskell.org> References: <043.ae7447db31f335ef6697823ae5dfc604@haskell.org> Message-ID: <058.664ab5db1867986e2ef13d98789d65eb@haskell.org> #11566: I don't need madvise MADV_DONTNEED -------------------------------------+------------------------------------- Reporter: mfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mfox): @erikd I will tell you which ones fail but it will take a while. The reason is I can't run with -j24 or I get spurious failures. So I have to run `make test` for a few hours with and without the patch. We are both interested in servers with large amounts of memory. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 03:05:00 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 03:05:00 -0000 Subject: [GHC] #11569: make -j24 test In-Reply-To: <043.ebd4ab4cf2b889476fd8b09d162a3605@haskell.org> References: <043.ebd4ab4cf2b889476fd8b09d162a3605@haskell.org> Message-ID: <058.adc4c8d87f77273021ae43e303a2d71b@haskell.org> #11569: make -j24 test -------------------------------+------------------------------- Reporter: mfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Test Suite | Version: 8.1 Resolution: invalid | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+------------------------------- Comment (by mfox): Hey, whoever closed my ticket. This isn't just about making tests. This is an environment variable I keep set for efficiency on slow but massively parallel build machine. Why should the tests fail with this flag? They should be cool. And so should you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 03:07:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 03:07:08 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.b19d6ee277458c25a983ff5f6c00ba57@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by mfox): {{{ ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags"," -fuse-ld=gold -Wl,-z,noexecstack") ,("Haskell CPP command","/usr/bin/gcc") ,("Haskell CPP flags","-E -undef -traditional ") ,("ld command","/usr/local/bin/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","/usr/local/bin/ar") ,("ar flags","q") ,("ar supports at file","NO") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("readelf command","/usr/local/bin/readelf") ,("perl command","/usr/bin/perl") ,("cross compiling","NO") ,("target os","OSLinux") ,("target arch","ArchARM64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("Unregisterised","YES") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("Project version","7.10.3") ,("Project Git commit id","97e7c293abbde5223d2bf0516f8969bdd1a9a7a2") ,("Booter version","7.6.3") ,("Stage","2") ,("Build platform","aarch64-unknown-linux") ,("Host platform","aarch64-unknown-linux") ,("Target platform","aarch64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","NO") ,("Have native code generator","NO") ,("Support SMP","NO") ,("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") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Uses package keys","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/local/lib/ghc-7.10.3") ,("Global Package DB","/usr/local/lib/ghc-7.10.3/package.conf.d") ]}} Maybe I'm very lucky. I haven't been careful but things work pretty well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 03:08:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 03:08:08 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.3f821009185fe311a231ea875bf83f05@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by mfox): I had llvm 3.5 at some point but then I uninstalled and built llvm 3.7 because that's what HEAD requires and nothing went wrong yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 03:57:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 03:57:08 -0000 Subject: [GHC] #11578: Fix GHC on AArch64/Arm64 Message-ID: <044.82eed99cc066ccb994128f1f7245b038@haskell.org> #11578: Fix GHC on AArch64/Arm64 --------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: aarch64 | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------+------------------------------------- Raising this to track discussion about GHC on Arm64. There is already some discussion in ticket #11206 (ARM is generally a disaster), but that ticket is about 32 bit Arm which is vastly different and is now mostly fixed. Information worth saving from #11206: * GHC 7.8.4 from Debian can build the ghc-8.0 branch, but cannot build HEAD because HEAD requires ghc-7.10 to build. * GHC 7.10 from Debian is broken because of an unfixed bug in llvm-3.5.2. * User @mfox reports that ghc-7.10 does build against llvm-3.7 and results in a compiler that can build HEAD. * That GHC 7.10 can be build against llvm-3.7 is a happy accident. Versions of GHC are usually locked to a specific version of LLVM. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 03:57:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 03:57:43 -0000 Subject: [GHC] #11206: ARM is generally a disaster In-Reply-To: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> References: <046.71a922fa04ac6af2f036d787368fbb06@haskell.org> Message-ID: <061.a578e89cbae9558983b3204818b6c71e@haskell.org> #11206: ARM is generally a disaster -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Linux | Architecture: arm Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11205, #11289, | Differential Rev(s): #11294, #11295, #11296, #11297, | #11340 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): We really should get off this ticket because this ticket is about Arm and what we are discussing is about Arm64 which is vastly different. Please use ticket #11578 for further Arm64 related discussion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 04:04:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 04:04:43 -0000 Subject: [GHC] #11578: Fix GHC on AArch64/Arm64 In-Reply-To: <044.82eed99cc066ccb994128f1f7245b038@haskell.org> References: <044.82eed99cc066ccb994128f1f7245b038@haskell.org> Message-ID: <059.dd355be65eab6af0a16a0f84b773c292@haskell.org> #11578: Fix GHC on AArch64/Arm64 -------------------------------------+------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------- Comment (by erikd): GHC 7.10 does *not* work here with llvm-3.7. What I get is: {{{ You are using a new version of LLVM that hasn't been tested yet! We will try though... /usr/bin/opt-3.7: /tmp/ghc16717_0/ghc_26.ll:7:6: error: unexpected type in metadata definition !0 = metadata !{metadata !"top", i8* null} }}} which in hindsight is what I expected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 04:05:24 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 04:05:24 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.79c75885a75fd7e9862bbd4f86f82bb4@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Recent arguments have not shifted me from my proposal in comment:15. What about {{{ f = g 5 g = $(...) }}} The suggestion to process declarations that do not contain a splice before declarations that do fails here. Instead, we recognize that `f` and `g` are in a mutually recursive group and process them together. `g` cannot reify `f`. Note that comment:15 says that only already-processed declarations (that is, not in the same mutually recursive group) are available. It does strike me (inspired by comment:16) that with all this toposorting going on, we may be able to avoid having top-level splices break the file up into declaration groups. The current behavior seems something like a feeble attempt at a toposort, anyway. I suppose changing this would break {{{ f = $(...) $( ... reify 'f ... ) }}} though. (That code would work now.) So, upon further thought, this particular aspect of the change seems dead in the water. Note that my pessimism here is only about comment:16, not comment:15. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 04:17:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 04:17:38 -0000 Subject: [GHC] #11578: Fix GHC on AArch64/Arm64 In-Reply-To: <044.82eed99cc066ccb994128f1f7245b038@haskell.org> References: <044.82eed99cc066ccb994128f1f7245b038@haskell.org> Message-ID: <059.81d3a5f5492d4c51f0a11080f21f412c@haskell.org> #11578: Fix GHC on AArch64/Arm64 -------------------------------------+------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------- Comment (by erikd): Building HEAD with Debian's ghc-7.10.3 and llvm-3.5.2 results in: {{{ 0 libLLVM-3.5.so.1 0x0000007fb6de1458 llvm::sys::PrintStackTrace(_IO_FILE*) + 48 Stack dump: 0. Program arguments: llc-3.5 -O1 -relocation-model=static /tmp/ghcb9c5_0/ghc_244.bc -o /tmp/ghcb9c5_0/ghc_245.lm_s --enable- tbaa=true 1. Running pass 'Function Pass Manager' on module '/tmp/ghcb9c5_0/ghc_244.bc'. 2. Running pass 'Greedy Register Allocator' on function '@"c5K0b_entry$def"' utils/ghc-cabal/ghc.mk:34: recipe for target 'utils/ghc-cabal/dist/build/tmp/ghc-cabal' failed make[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Segmentation fault (core dumped) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 07:53:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 07:53:27 -0000 Subject: [GHC] #11579: Bug in parser for named Haddock chunks since GHC 8.0.1-rc1 Message-ID: <050.4d0ef6c9d54d8fe326a15d5b3729d82a@haskell.org> #11579: Bug in parser for named Haddock chunks since GHC 8.0.1-rc1 -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Steps to reproduce: {{{ -- Foo.hs module Foo where -- $bar some -- named chunk }}} {{{ -- Extract.hs module Extract where import Prelude hiding (mod) import Data.Generics import DynFlags import FastString import GHC import GHC.Paths extractDocStrings :: IO [String] extractDocStrings = do extract . pm_parsed_source <$> do runGhc (Just libdir) $ do _ <- getSessionDynFlags >>= setSessionDynFlags . setHaddockMode guessTarget "Foo.hs" Nothing >>= setTargets . return [mod] <- depanal [] False parseModule mod where setHaddockMode :: DynFlags -> DynFlags setHaddockMode dynflags = (gopt_set dynflags Opt_Haddock) extract :: ParsedSource -> [String] extract m = [unpackFS s | HsDocString s <- everything (++) ([] `mkQ` return) m] }}} Expected result: {{{extractDocStrings}}} returns {{{" some\n named chunk"}}} Actual result: it returns {{{" some"}}} instead -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 08:03:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 08:03:49 -0000 Subject: [GHC] #11579: Bug in parser for named Haddock chunks since GHC 8.0.1-rc1 In-Reply-To: <050.4d0ef6c9d54d8fe326a15d5b3729d82a@haskell.org> References: <050.4d0ef6c9d54d8fe326a15d5b3729d82a@haskell.org> Message-ID: <065.eae584678e69fdd64a3fa27cf1e574a5@haskell.org> #11579: Bug in parser for named Haddock chunks since GHC 8.0.1-rc1 -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by SimonHengel): * version: 7.10.3 => 8.0.1-rc2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 08:45:45 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 08:45:45 -0000 Subject: [GHC] #11541: Type errors sometimes has a lot of irrelevant information In-Reply-To: <047.b489a9355667fda5e49935258d0dd4af@haskell.org> References: <047.b489a9355667fda5e49935258d0dd4af@haskell.org> Message-ID: <062.fd6d15181e0884bdb87509e8f9bcb192@haskell.org> #11541: Type errors sometimes has a lot of irrelevant information -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"18cd712427182e76d38047860ee3e26799bc3fe2/ghc" 18cd712/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="18cd712427182e76d38047860ee3e26799bc3fe2" Improve error message suppression TcErrors has a system for suppressing some type errors if a more serious one occurs. But there was a crucial missing case, which sometimes resulted in a cascade of irrelevant errors overwhelming the actual cause. This was Trac #11541. The fix is simple. Worth merging to 8.0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 08:48:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 08:48:31 -0000 Subject: [GHC] #11541: Type errors sometimes has a lot of irrelevant information In-Reply-To: <047.b489a9355667fda5e49935258d0dd4af@haskell.org> References: <047.b489a9355667fda5e49935258d0dd4af@haskell.org> Message-ID: <062.142224c11d7146fd5c1b366d3b21da2c@haskell.org> #11541: Type errors sometimes has a lot of irrelevant information -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge Comment: Thanks Johannes, that test case was extremely helpful; it led me straight to the bug. The error-message suppression mechanism was all there (comment:2), but it wasn't being used properly. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 08:48:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 08:48:49 -0000 Subject: [GHC] #11541: Type errors sometimes has a lot of irrelevant information In-Reply-To: <047.b489a9355667fda5e49935258d0dd4af@haskell.org> References: <047.b489a9355667fda5e49935258d0dd4af@haskell.org> Message-ID: <062.f5240a1284c7b2f7f4b947234e66f28b@haskell.org> #11541: Type errors sometimes has a lot of irrelevant information -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T11541 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_fail/T11541 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 08:50:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 08:50:32 -0000 Subject: [GHC] #11273: PowerPC NCG: Assign all STG float and double regs to PowerPC registers In-Reply-To: <047.9904a1c11b816b72007affef2eb0aa68@haskell.org> References: <047.9904a1c11b816b72007affef2eb0aa68@haskell.org> Message-ID: <062.1dcb3f431f5255e3c7faa5509c83db0d@haskell.org> #11273: PowerPC NCG: Assign all STG float and double regs to PowerPC registers -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:1914 Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * status: new => patch * differential: => Phab:1914 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 08:51:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 08:51:16 -0000 Subject: [GHC] #11273: PowerPC NCG: Assign all STG float and double regs to PowerPC registers In-Reply-To: <047.9904a1c11b816b72007affef2eb0aa68@haskell.org> References: <047.9904a1c11b816b72007affef2eb0aa68@haskell.org> Message-ID: <062.bb35b39df0c53f43a044d4a6b9d176ff@haskell.org> #11273: PowerPC NCG: Assign all STG float and double regs to PowerPC registers -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1914 Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * differential: Phab:1914 => Phab:D1914 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 09:24:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 09:24:32 -0000 Subject: [GHC] #11573: Inferred CallStacks expose implicit parameter In-Reply-To: <046.50bedf0c81dd2bc801447c1bb4cd0177@haskell.org> References: <046.50bedf0c81dd2bc801447c1bb4cd0177@haskell.org> Message-ID: <061.65cb7b7934ef53b4018208d825698bab@haskell.org> #11573: Inferred CallStacks expose implicit parameter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gridaphobe Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 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): Phab:D1911 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think that the inferred call stack is also a bug! I believe that for top-level bindings that lack a signature, we are not inferring a `HasCallStack` constraint: {{{ foo (x:xs) = x foo [] = error "foo" }}} Here we infer `foo :: [a] -> a`, without a `HasCallStack` constraint. Correct? Alas the [http://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#hascallstack user manual section] does not say this. It should. Also, I believe that [wiki:ExplicitCallStack/ImplicitLocations this is the relevant wiki page] (correct?). Yet it is full of "proposals", and this particular point is an "open choice" under "Discussion". It would be great it * The user manual was updated to be a more complete and accurate spec * It referred to the wiki page * The wiki page was updated to reflect reality Finally, back to GHCi. I think that a `let` binding in GHCi should have the same status as a top-level binding in a module; and hence should not get an automatically-inferred `HasCallStack` constraint. So there are four things to fix: * Using the `HasCallStack` synonym * Treating GHCi `let` bindings as top level * Update the user manual * Update the wiki page Eric, if you are willing it would be great if you could look into this. It's such a valuable feature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 09:31:05 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 09:31:05 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.ab826f8c63fd38a66a954c908e7a489b@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by owst): Replying to [comment:21 goldfire]: > {{{ > f = g 5 > g = $(...) > }}} > > The suggestion to process declarations that do not contain a splice before declarations that do fails here. Yes, indeed, it is very similar to my example at the top of comment:20, but I felt it wouldn't be easy to handle. Perhaps it is... > Instead, we recognize that `f` and `g` are in a mutually recursive group and process them together. `g` cannot reify `f`. Note that comment:15 says that only already-processed declarations (that is, not in the same mutually recursive group) are available. Are `f` and `g` mutually recursive? Since you explicitly say `g` ''cannot'' reify `f` - does `f` therefore just depend on `g`? What about in: {{{ f = e $(...) c = $(...) e = c ... d = $(...) a = ... b ... b = ... a ... }}} I think an processing order: `(a b) < (c d) < e < f` could work: 1. `a, b` are in scope to reify/call for `c`, 1. `c` is ''not'' in scope to reify/call for `d` (we cannot in general determine what `d` `reify`s so cannot order the splices - as per comment:19) 1. `a, b, c, d` are in scope to reify/call in `e`, there is a data dependency between `e` and `c` (and thus implicitly `d`): `e` is ordered ''after'' `c` 1. `a, b, c, d, e` are in scope to reify/call in `f` since there is a data dependency between `f` and `e`: `f` is ordered ''after'' `e`. > It does strike me (inspired by comment:16) that with all this toposorting going on, we may be able to avoid having top-level splices break the file up into declaration groups. The current behavior seems something like a feeble attempt at a toposort, anyway. Indeed, I think that would be nice for a consistent story. However, how do you order top-level declarations in the toposort? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 10:00:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 10:00:16 -0000 Subject: [GHC] #8710: Overlapping patterns warning misplaced In-Reply-To: <047.1f227e0dac37dd7309646386f280164b@haskell.org> References: <047.1f227e0dac37dd7309646386f280164b@haskell.org> Message-ID: <062.6f326b9c079051fba542eee5b3a9fe60@haskell.org> #8710: Overlapping patterns warning misplaced -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1910 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > If we print a separate warning for every redundant clause it may become overwhelming Really? There are a few artificial examples in the testsuite, but I'd have thought that one error per redundant equation would be ok. But still, I'd really like the common case of one redundant equation to look like {{{ Bug.hs:24:3: warning: -- Note correct line number Pattern match(es) are redundant In an equation for ?show?: len _ = ... (at Bug.hs:24:3) }}} Or maybe even {{{ Bug.hs:24:3: warning: Pattern match(es) are redundant In an equation for ?show?: len _ = ... -- No need to duplicate here }}} If there are more than one, then adding the individual locations is good {{{ Bug.hs:24:3: warning: Pattern match(es) are redundant In an equation for ?show?: len _ = ... (at Bug.hs:24:3) len _ = ... (at Bug.hs:25:3) }}} but the herald should mention the first. Can't be hard, I guess. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 10:14:23 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 10:14:23 -0000 Subject: [GHC] #11577: GHCi accepts invalid programs when recompiling In-Reply-To: <047.2a12c44ccefc548e437422f83a607aa3@haskell.org> References: <047.2a12c44ccefc548e437422f83a607aa3@haskell.org> Message-ID: <062.3fea0da7fe436c94b7515628a09cd104@haskell.org> #11577: GHCi accepts invalid programs when recompiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: ezyang (added) Comment: Edward do you have any idea what is happening here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 10:16:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 10:16:07 -0000 Subject: [GHC] #2159: Use a more efficient representation than [DynFlag] In-Reply-To: <044.7464fd042e6f0696195045db2d1740fe@haskell.org> References: <044.7464fd042e6f0696195045db2d1740fe@haskell.org> Message-ID: <059.3ee75f800c0b6daf19f36c6d561afc35@haskell.org> #2159: Use a more efficient representation than [DynFlag] -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: fixed | 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): Great! Bring it on! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 10:18:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 10:18:56 -0000 Subject: [GHC] #11383: CAFs lose sharing due to implicit call stacks In-Reply-To: <047.7956a69fc4ebcb0a87f22be719b572d1@haskell.org> References: <047.7956a69fc4ebcb0a87f22be719b572d1@haskell.org> Message-ID: <062.a31df7615e90b4298fe0671e679115b6@haskell.org> #11383: CAFs lose sharing due to implicit call stacks -------------------------------------+------------------------------------- Reporter: simonmar | Owner: gridaphobe Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11298 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by chak): * cc: chak (added) Comment: Haskell performance is tricky to reason about as it is. Adding more complexity seems worrying. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 10:37:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 10:37:37 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.185bced95d3d3dc483165120a9208b95@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): #10100, #10183 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by mboes): * cc: mboes (added) Comment: I disagree. Here's a data point for you to take into consideration. At Tweag I/O we've had at least one instance of a serious bug that shipped into production and several days worth of wasted effort, because a constraint maintaining a key invariant was mistakenly unused. -fwarn-redundant-constraints would of caught this bug very early and saved us all the trouble (a test would have worked too, but as it happens a test did exist but had a bug too). If this warning is not turned on with -Wall, then we'd have to discover somehow that there is this extra flag that we should pass in ''even though we already said -Wall'', to really get all warnings, including one that could be life saving. I think -Wall should do what it says on the tin: include all warnings. That many such warnings may be cause for false positives is why we have -Wall not turned on by default in the first place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 10:48:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 10:48:26 -0000 Subject: [GHC] #11573: Inferred CallStacks expose implicit parameter In-Reply-To: <046.50bedf0c81dd2bc801447c1bb4cd0177@haskell.org> References: <046.50bedf0c81dd2bc801447c1bb4cd0177@haskell.org> Message-ID: <061.1f0946b1e9b3452f521b039e34f90db1@haskell.org> #11573: Inferred CallStacks expose implicit parameter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gridaphobe Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 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): Phab:D1911 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Aha: see Phab:1912: Don't infer `CallStacks` at top level -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 11:07:21 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 11:07:21 -0000 Subject: [GHC] #11195: New pattern-match check can be non-performant In-Reply-To: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> References: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> Message-ID: <062.4eccffaa1a8c8f25318654a96eb2e208@haskell.org> #11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1676 Wiki Page: | -------------------------------------+------------------------------------- Comment (by gkaracha): I think that commit 28f951edfe50ea5182065144340061ec326781f5 addresses this completely: {{{ Author: George Karachalias Date: Wed Feb 3 19:06:45 2016 +0100 Overhaul the Overhauled Pattern Match Checker }}} Hence, I am closing this. Feel free to reopen in case performance issues arise again due to pattern match checking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 11:08:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 11:08:14 -0000 Subject: [GHC] #11195: New pattern-match check can be non-performant In-Reply-To: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> References: <047.3d302be30292bcd5d6fb3a65b1c2a01c@haskell.org> Message-ID: <062.e303f9f638442e181978ca5ed79b1867@haskell.org> #11195: New pattern-match check can be non-performant -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1676, Wiki Page: | Phab:D1795 -------------------------------------+------------------------------------- Changes (by gkaracha): * status: new => closed * differential: Phab:D1676 => Phab:D1676, Phab:D1795 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 11:28:12 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 11:28:12 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.1883750ac9e503a121ea4e15b8dd3a4b@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): #10100, #10183 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): I understand -Wall as the option that allows reasonably designed code to pass without warnings. There are good reasons to have redundant constraints as I sketched in the ticket description. It's crucial to be able to make code -Wall warning-free otherwise relevant warnings are easily overlooked in a flood of irrelevant warnings. According to my programming style I often add e.g. -fwarn-incomplete-uni-patterns -fwarn- tabs -fwarn-missing-import-lists. They match my style of programming but seem to interfere with other's style, thus they are not part of -Wall. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 11:47:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 11:47:27 -0000 Subject: [GHC] #11488: -dynamic-too is entirely undocumented In-Reply-To: <046.8614faf1a62ae888f21a12626cf19543@haskell.org> References: <046.8614faf1a62ae888f21a12626cf19543@haskell.org> Message-ID: <061.250d5a7979a8cf0df72a6ae11378b57c@haskell.org> #11488: -dynamic-too is entirely undocumented -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"160765f8331cf92e9a34e9062846a949e7b11b1e/ghc" 160765f8/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="160765f8331cf92e9a34e9062846a949e7b11b1e" Document -dynamic-too (#11488) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 11:47:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 11:47:51 -0000 Subject: [GHC] #11488: -dynamic-too is entirely undocumented In-Reply-To: <046.8614faf1a62ae888f21a12626cf19543@haskell.org> References: <046.8614faf1a62ae888f21a12626cf19543@haskell.org> Message-ID: <061.05d49b83edb54fb383b2e64861f44f41@haskell.org> #11488: -dynamic-too is entirely undocumented -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: merge Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 12:39:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 12:39:56 -0000 Subject: [GHC] #11578: Fix GHC on AArch64/Arm64 In-Reply-To: <044.82eed99cc066ccb994128f1f7245b038@haskell.org> References: <044.82eed99cc066ccb994128f1f7245b038@haskell.org> Message-ID: <059.db7171588982a591c608037adff07883@haskell.org> #11578: Fix GHC on AArch64/Arm64 -------------------------------------+------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------- Comment (by mfox): It is crazy that mine works with almost no problems and doesn't even seem to care about llvm versions. You can try my build of HEAD: https://s3-us- west-1.amazonaws.com/stack-aarch64/ghc-8.1.20160209-aarch64-unknown- linux.tar.bz2 I built llvm 3.7 and clang using default options and installed to /usr/local from: http://llvm.org/releases/download.html I am still curious whether there is some hardware difference, if it comes down to an ubuntu vs debian thing or whether I just got lucky somehow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 12:44:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 12:44:33 -0000 Subject: [GHC] #11569: make -j24 test In-Reply-To: <043.ebd4ab4cf2b889476fd8b09d162a3605@haskell.org> References: <043.ebd4ab4cf2b889476fd8b09d162a3605@haskell.org> Message-ID: <058.a71b1bf6a66431b98bee85d82c48ccab@haskell.org> #11569: make -j24 test -------------------------------+------------------------------- Reporter: mfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+------------------------------- Changes (by thomie): * status: closed => new * resolution: invalid => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 12:59:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 12:59:16 -0000 Subject: [GHC] #11519: Inferring non-tau kinds In-Reply-To: <047.4d7c879b01fe33a75f5e9304ccb4f8c9@haskell.org> References: <047.4d7c879b01fe33a75f5e9304ccb4f8c9@haskell.org> Message-ID: <062.762da381d514edbd610bec45ef26b78d@haskell.org> #11519: Inferring non-tau kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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): This documents the instance-forall extension {{{ commit 6cf9b06fd193867bf4964eff4317479b9e25fca5 Author: Simon Peyton Jones Date: Fri Feb 12 14:38:22 2016 +0000 User manual improvments - Document that you can use 'forall' in instance decls - Change the sections a bit, so that big sections (like lexically scoped type variables, pattern synonyms, implicit parameters) become more visible }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 13:35:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 13:35:14 -0000 Subject: [GHC] #10478: Shorter import syntax In-Reply-To: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> References: <046.5e60b02b9fe497cdf59ecd5b37a450a2@haskell.org> Message-ID: <061.cdb41edc9a918e6c1ebccd65e9ac6209@haskell.org> #10478: Shorter import syntax -------------------------------------+------------------------------------- Reporter: acowley | Owner: 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:D1238 Wiki Page: | -------------------------------------+------------------------------------- Changes (by waern): * cc: david.waern@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 13:38:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 13:38:08 -0000 Subject: [GHC] #11362: T6137 doesn't pass with reversed uniques In-Reply-To: <046.176cbdce58fe0c2949bc42c9d1fa1775@haskell.org> References: <046.176cbdce58fe0c2949bc42c9d1fa1775@haskell.org> Message-ID: <061.a3dfde6409e3f57eb822da1b8dc75921@haskell.org> #11362: T6137 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: 4012 Related Tickets: #11371 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I have not been following this ticket, but I'm very lost at the last comment. * `cab_lhs` is a list of types that are the type patterns on the LHS of an axiom. * `cab_rhs` is the type on the RHS of an axiom. What do you mean by an order of the RHS? There's just one thing. The line of code you include is for data family axioms, where the RHS has a certain prescribed form. I can see how "order" might apply here. But the Core Lint code should work over all axioms, including type family axioms, for which the RHS has no notion of ordering at all. What makes you say that Core Lint is assuming this? It is possible something somewhere is assuming an ordering property about data family axioms, in particular, but it's not Core Lint. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 13:51:03 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 13:51:03 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.6b16c7b7ff9e23585697c836f644a434@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:22 owst]: > Are `f` and `g` mutually recursive? Since you explicitly say `g` ''cannot'' reify `f` - does `f` therefore just depend on `g`? We declare that they are. That's what's meant by "anything with a splice depends on anything else". It's true that the splice can't do much reify `f`, but it can certainly produce code which calls `f`. > > What about in: > {{{ > f = e $(...) > c = $(...) > e = c ... > d = $(...) > a = ... b ... > b = ... a ... > }}} > > I think an processing order: `(a b) < (c d) < e < f` could work: I don't think this would quite work. What if `c` calls `f`? That is, `c = $(varE (mkName (['a'..] !! 5 : [])))`. We don't know without running the splice, so we say that anything with a splice depends on anything else in the region. > > > > It does strike me (inspired by comment:16) that with all this toposorting going on, we may be able to avoid having top-level splices break the file up into declaration groups. The current behavior seems something like a feeble attempt at a toposort, anyway. > > Indeed, I think that would be nice for a consistent story. However, how do you order top-level declarations in the toposort? Perhaps I was confusing. Sorry. I changed my mind as I wrote my response -- in the end, I don't think this would work, because it would assume that expression splices above the top-level splice could depend on declarations below the top-level splice, which might break existing code (and with no workaround). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 13:56:55 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 13:56:55 -0000 Subject: [GHC] #11580: panic on incompatible options Message-ID: <044.f81a5f3f4d659979b389f8dba4789246@haskell.org> #11580: panic on incompatible options -------------------------------------+------------------------------------- Reporter: dougm | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This torture test causes ghc to panic for incompatible options Unsafe and Trustworthy {{{ ghc `ghc --supported-languages | sed 's/^/-X/'` }}} The two options alone lead to a correct diagnostic. So does deletion of either from the full list. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 14:12:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 14:12:14 -0000 Subject: [GHC] #11578: Fix GHC on AArch64/Arm64 In-Reply-To: <044.82eed99cc066ccb994128f1f7245b038@haskell.org> References: <044.82eed99cc066ccb994128f1f7245b038@haskell.org> Message-ID: <059.f446a8a3c2520f940c7c0c839a2312bc@haskell.org> #11578: Fix GHC on AArch64/Arm64 -------------------------------------+------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------- Comment (by mfox): Something I've heard about but don't fully understand the implications (if any) for ghc: * Some programs assume that a page size is 4k. Arm64 can have larger and smaller pages. * Some programs assume 47-bit virtual address space with bit 48 signaling kernel space; the feel free to use bits [63:49] of a pointer as a tag. Arm64 Doesn't like it. Can still use bits [63:56] as a tag Again, I don't know the implications for ghc. Just mentioning it in case someone knows more. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 14:16:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 14:16:56 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.ba3e6a90d20e46bca05fb7355bef8d7b@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): In comment:19 I neglected the case of comment:20, in which a function without a splice refers to a function with a splice. I still think the main point, that there are only two kinds of declaration per declaration group is correct. In each declaration group we have * the declarations which do not use a splice, either directly or via reference to another declaration in the same group which uses a splice; * the declarations which do use a splice, either directly or via reference.... We process the first group, then process the second group, making the first group (but none of the second group) available to reify. This is just supposed to be a restatement of goldfire's comment:15, taking into account that "any declaration with a splice in it is considered to depend on all other declarations in the region" means that there are effectively at most two of goldfire's "chunks" per declaration group. (In fact, there might be several mutually recursive groups of declarations that do not (even indirectly) contain splices. But then it doesn't matter whether we process them as a single group or as several groups, because the declarations in the group contain no splices anyways.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 14:28:23 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 14:28:23 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.0dd5ff683cea8c08dd819a927aaf0647@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Ah. Understood re comment:24. I was thinking more in terms of GHC's implementation, which does all the chunking already. But you're right that we can explain this to users in terms of just two chunks, the non-splicy one and then the splicy one, with the caveat that spliciness is infectious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 14:42:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 14:42:33 -0000 Subject: [GHC] #3919: Or-patterns as GHC extension In-Reply-To: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> References: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> Message-ID: <066.37cf5759f0951d205d479c6d1d3db151@haskell.org> #3919: Or-patterns as GHC extension -------------------------------------+------------------------------------- Reporter: BjornEdstrom | Owner: 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gkaracha): * cc: gkaracha (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 15:18:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 15:18:48 -0000 Subject: [GHC] #11416: GHC mistakenly believes datatype with type synonym in its type can't be eta-reduced In-Reply-To: <050.aaa6fc55eaa14775eef54eee92a05a1a@haskell.org> References: <050.aaa6fc55eaa14775eef54eee92a05a1a@haskell.org> Message-ID: <065.e18fdb486e38979cda0070e68160d5f2@haskell.org> #11416: GHC mistakenly believes datatype with type synonym in its type can't be eta-reduced -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1772 Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Hm, there's another tricky case that I hadn't previously considered: {{{#!hs type ConstT a b = a data family Fam a b data instance Fam (ConstT a b) b = Fam b deriving Functor }}} Currently, the eta-reduction check rejects this. Should it? On on hand, the `b` in `ConstT a b` will go away if you expand the `ConstT` type synonym, so one could argue this is no different from `data instance Fam a b = Fam b deriving Functor` (which is accepted). On the other hand, if you consider what the derived instance would look like: {{{#!hs instance Functor (Fam (ConstT a b)) where ... }}} This feels a bit off, because now the instance head is mentioning an eta- reduced type variable! But it does typecheck if you type it in manually... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 15:40:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 15:40:20 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.7ff0fffcbc986b3f7d2a243c7f06c56d@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * owner: bgamari => * status: closed => new * resolution: fixed => Comment: `-Wredundant-constraints` was removed from the standard warning set, but we should put it in `-Wall`. We explicitly allow warnings in `-Wall` (and to a lesser extent the standard warning set) to change between releases, and this warning should really be in `-Wall`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 16:11:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 16:11:31 -0000 Subject: [GHC] #11383: CAFs lose sharing due to implicit call stacks In-Reply-To: <047.7956a69fc4ebcb0a87f22be719b572d1@haskell.org> References: <047.7956a69fc4ebcb0a87f22be719b572d1@haskell.org> Message-ID: <062.dead8f4ec4b29cc1edab35df610a5c24@haskell.org> #11383: CAFs lose sharing due to implicit call stacks -------------------------------------+------------------------------------- Reporter: simonmar | Owner: gridaphobe Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11298 | Differential Rev(s): Phab:D1912 Wiki Page: | -------------------------------------+------------------------------------- Changes (by gridaphobe): * status: new => patch * differential: => Phab:D1912 Comment: This will be (partially) fixed by D1912, which prevents GHC from inferring CallStack constraints for top-level definitions. You could still create the issue by making `x` a local binder inside `main`, but then again, the monomorphism restriction will usually be turned on and will prevent the inference. On a related note, do we have a warning (or less severely, a note) for when we infer a polymorphic type that the monomorphism restriction would have prevented? That might be useful to pair with NoMonomorphismRestriction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 16:20:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 16:20:09 -0000 Subject: [GHC] #11148: T9563 doesn't pass with reversed uniques In-Reply-To: <046.b847015ce18a169600f5428c8d6709c6@haskell.org> References: <046.b847015ce18a169600f5428c8d6709c6@haskell.org> Message-ID: <061.2cfe0b88fcd3eb9ee3993267f87b5ea4@haskell.org> #11148: T9563 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T11148 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"e2f7d777bb7e4c176e01e1c4f8184f115253dee0/ghc" e2f7d777/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e2f7d777bb7e4c176e01e1c4f8184f115253dee0" A tiny, outright bug in tcDataFamInstDecl This bug was revealed by Trac #11362. It turns out that in my patch for Trac #11148 (namely 1160dc5), I failed to turn one occurrence of tvs' into full_tvs. Sigh. This is tricky stuff and it cost me several hours to page it back in and figure out what was happening. The result was a CoAxiom whose lhs had rhs had different kinds. Eeek! Anyway it's fixed. I also added an ASSERT, in FamInst.newFamInst, that trips on such bogus CoAxioms. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 16:20:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 16:20:09 -0000 Subject: [GHC] #11362: T6137 doesn't pass with reversed uniques In-Reply-To: <046.176cbdce58fe0c2949bc42c9d1fa1775@haskell.org> References: <046.176cbdce58fe0c2949bc42c9d1fa1775@haskell.org> Message-ID: <061.270beedf5303561b2cf13c89239342db@haskell.org> #11362: T6137 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: 4012 Related Tickets: #11371 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"e2f7d777bb7e4c176e01e1c4f8184f115253dee0/ghc" e2f7d777/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e2f7d777bb7e4c176e01e1c4f8184f115253dee0" A tiny, outright bug in tcDataFamInstDecl This bug was revealed by Trac #11362. It turns out that in my patch for Trac #11148 (namely 1160dc5), I failed to turn one occurrence of tvs' into full_tvs. Sigh. This is tricky stuff and it cost me several hours to page it back in and figure out what was happening. The result was a CoAxiom whose lhs had rhs had different kinds. Eeek! Anyway it's fixed. I also added an ASSERT, in FamInst.newFamInst, that trips on such bogus CoAxioms. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 16:21:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 16:21:54 -0000 Subject: [GHC] #11362: T6137 doesn't pass with reversed uniques In-Reply-To: <046.176cbdce58fe0c2949bc42c9d1fa1775@haskell.org> References: <046.176cbdce58fe0c2949bc42c9d1fa1775@haskell.org> Message-ID: <061.e5b2250492449d63af1c93234f50fdd7@haskell.org> #11362: T6137 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: 4012 Related Tickets: #11371 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge Comment: OK fixed. Merge to stable branch please. Would someone (Bartosz) like to add a regression test? Perhaps just compiling this test with reversed uniques. Thanks! I'll put it in merge state, but let's not forget that test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 16:27:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 16:27:30 -0000 Subject: [GHC] #11383: CAFs lose sharing due to implicit call stacks In-Reply-To: <047.7956a69fc4ebcb0a87f22be719b572d1@haskell.org> References: <047.7956a69fc4ebcb0a87f22be719b572d1@haskell.org> Message-ID: <062.7a9c43eb0155f8b10867debb448c2f4f@haskell.org> #11383: CAFs lose sharing due to implicit call stacks -------------------------------------+------------------------------------- Reporter: simonmar | Owner: gridaphobe Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11298 | Differential Rev(s): Phab:D1912 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:7 gridaphobe]: > On a related note, do we have a warning (or less severely, a note) for when we infer a polymorphic type that the monomorphism restriction would have prevented? That might be useful to pair with NoMonomorphismRestriction. I agree this would be nice; I've always wished the monomorphism restriction was instead a warning like this. There is `-fwarn-monomorphism-restriction`, but it does the reverse: when the monomorphism restriction is on, it warns about bindings that it applies to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 16:31:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 16:31:15 -0000 Subject: [GHC] #11573: Inferred CallStacks expose implicit parameter In-Reply-To: <046.50bedf0c81dd2bc801447c1bb4cd0177@haskell.org> References: <046.50bedf0c81dd2bc801447c1bb4cd0177@haskell.org> Message-ID: <061.3b8f90e2fb876ee907a80b7984ef5fe4@haskell.org> #11573: Inferred CallStacks expose implicit parameter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gridaphobe Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11383 | Differential Rev(s): Phab:D1911, Wiki Page: | Phab:D1912 -------------------------------------+------------------------------------- Changes (by gridaphobe): * differential: Phab:D1911 => Phab:D1911, Phab:D1912 * related: => #11383 Comment: > Here we infer foo :: [a] -> a, without a HasCallStack constraint. Correct? That's incorrect as of the reworked solver, but as you've seen D1912 is going to put the original "don't infer top-level call-stacks" behavior back in place. > - The user manual was updated to be a more complete and accurate spec > - It referred to the wiki page Sure, I didn't realize we linked to the wiki from the manual. > - The wiki page was updated to reflect reality I've been treating the wiki page as append-only, so I'll add a section that explains the final design. > I think that a let binding in GHCi should have the same status as a top- level binding in a module I agree, and D1912 does treat them as top-level. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 16:37:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 16:37:01 -0000 Subject: [GHC] #11362: T6137 doesn't pass with reversed uniques In-Reply-To: <046.176cbdce58fe0c2949bc42c9d1fa1775@haskell.org> References: <046.176cbdce58fe0c2949bc42c9d1fa1775@haskell.org> Message-ID: <061.0c3767e130a166d1d3bf64a890803b15@haskell.org> #11362: T6137 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: 4012 Related Tickets: #11371 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): I will add a test. Thank you! This should unblock D1905 from #4012. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 16:55:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 16:55:43 -0000 Subject: [GHC] #11416: GHC mistakenly believes datatype with type synonym in its type can't be eta-reduced In-Reply-To: <050.aaa6fc55eaa14775eef54eee92a05a1a@haskell.org> References: <050.aaa6fc55eaa14775eef54eee92a05a1a@haskell.org> Message-ID: <065.09a67db8bd63ff902a8f679a102a8c18@haskell.org> #11416: GHC mistakenly believes datatype with type synonym in its type can't be eta-reduced -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1772 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Maybe. If you type it in manually you'll get a spuriously polymorphic instance, which will result in some uses of `Any`. I think the same will happen if you allow this data instance. Perhaps it's no more than using `exactTyCoVarsofType` in `eta_reduce` in `tcDataFamInstDecl`. You'd need to make sure you quantify over the tyvar anyway; but I think that will happen. I don't feel strongly. It would be good to document it. Crumbs if I had a pound for every hour I've spent on `GeneralisedNewtypeDeriving` I'd be a rich man. Thanks for digging into this -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 16:58:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 16:58:38 -0000 Subject: [GHC] #11573: Inferred CallStacks expose implicit parameter In-Reply-To: <046.50bedf0c81dd2bc801447c1bb4cd0177@haskell.org> References: <046.50bedf0c81dd2bc801447c1bb4cd0177@haskell.org> Message-ID: <061.50b44a8d2222bee3038c1857d05c9976@haskell.org> #11573: Inferred CallStacks expose implicit parameter -------------------------------------+------------------------------------- Reporter: bgamari | Owner: gridaphobe Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11383 | Differential Rev(s): Phab:D1911, Wiki Page: | Phab:D1912 -------------------------------------+------------------------------------- Comment (by simonpj): > Sure, I didn't realize we linked to the wiki from the manual. We don't in this case (yet) but we sometimes do. A little odd, I agree, but the shortest path to a decent outcome. > > - The wiki page was updated to reflect reality > > I've been treating the wiki page as append-only, so I'll add a section that explains the final design. Let's _not_ treat it as append-only! Put the final state of affairs at the top; if there is some illuminating history then dump it at the end clearly labelled. If not illuminating, discard it. We have too many out of date and misleading wiki pages! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 17:57:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 17:57:38 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.127c51fef438d946e849f839e6702de3@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by owst): Thank you both for clarifying things. So, to be explicit, the proposal is (at a conceptual level) now: 1. Split the module into declaration groups (DG) and process top-to- bottom, 2. For each DG: a. partition the declarations within it to two sets: those that contain splices (directly or via reference), which we refer to as S, and those that do not, which we refer to as NS, b. Process NS first, then S. Splices within S can refer (either with `reify` or via evaluation) to all names declared in NS or previous DGs), but no names within S. This allows: {{{ f = $(mapM reify ['C, ''C, 'i] >>= ...) -- all names are in NS g = h f h x = $(LitE . StringL . i . show <$> reify 'i) -- both call and reify i i x = x data C = C $(return []) -- In a later DG, all earlier names are available, as are those in NS j = $(mapM reify ['C, ''C, 'f, 'g, 'h, 'i, 'k] >>= ...) k = () }}} Here, we have two declaration groups: 1. NS = `{i, C}`, S = `{f, g, h}` 2. NS = `{k}`, S = `{j}` (with `i, C, f, g, h` all available for `reify`/evaluation) but not: {{{ f = () g = $(reify 'f ...) -- ok h = ... g ... i = $(reify 'g ...) -- Error: f is in S in this declaration group j = $(reify 'h ...) -- Error: h is in S in this declaration group k = $(reify 'l ...) -- Error: l is declared in the next declaration group $(return []) l x = ... }}} Here we also have two declaration groups, and in particular, `h` is contained in ''S'' in the first declaration group. So vs today: 1. We loosen the stage restriction (allowing e.g. `h` to call `i`) 2. Allow "no-splice" expressions to be referred to from a splice within the same declaration group (allowing e.g. `f` to `reify` both `C` and `i`). Both whilst not breaking existing programs. This seems good! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 18:06:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 18:06:32 -0000 Subject: [GHC] #11577: GHCi accepts invalid programs when recompiling In-Reply-To: <047.2a12c44ccefc548e437422f83a607aa3@haskell.org> References: <047.2a12c44ccefc548e437422f83a607aa3@haskell.org> Message-ID: <062.429965b2ec88ec788c1691869bc99654@haskell.org> #11577: GHCi accepts invalid programs when recompiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by crockeea): * version: 7.10.2-rc2 => 8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 18:06:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 18:06:54 -0000 Subject: [GHC] #11577: GHCi accepts invalid programs when recompiling In-Reply-To: <047.2a12c44ccefc548e437422f83a607aa3@haskell.org> References: <047.2a12c44ccefc548e437422f83a607aa3@haskell.org> Message-ID: <062.7af7881b7153edad0e4b994458fe64f4@haskell.org> #11577: GHCi accepts invalid programs when recompiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.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 crockeea): Reproduced in HEAD (8.1.20160215). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 18:11:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 18:11:06 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.a1e04a882cb8465f9859f8fcc73b0ed2@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): This all sounds great except for one thing. Do we have a plan for actually loosening the stage restriction? The stage restriction exists for technical reasons, not conceptual reasons. The stage restriction currently applies to the module as a whole. It says you cannot use an identifier that was defined in a module within a splice in the same module. Clearly if the use is in a later declaration group than the definition, there is no problem in principle with lifting the restriction. But in order to do so, we would have to run the declaration group containing the definition through the entire compiler pipeline, right up to linking, so that we can load it to run the splice in the latter declaration group to begin type checking it. GHC just isn't organized to work that way currently. The user's guide has this to say on the subject: > You can only run a function at compile time if it is imported from another module. That is, you can't define a function in a module, and call it from within a splice in the same module. (It would make sense to do so, but it's hard to implement.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 18:36:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 18:36:15 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.e388b9b538cdbad9750edb26f977b726@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by owst): Replying to [comment:27 rwbarton]: > This all sounds great except for one thing. Do we have a plan for actually loosening the stage restriction? The stage restriction exists for technical reasons, not conceptual reasons. > > The stage restriction currently applies to the module as a whole. It says you cannot use an identifier that was defined in a module within a splice in the same module. Clearly if the use is in a later declaration group than the definition, there is no problem in principle with lifting the restriction. But in order to do so, we would have to run the declaration group containing the definition through the entire compiler pipeline, right up to linking, so that we can load it to run the splice in the latter declaration group to begin type checking it. GHC just isn't organized to work that way currently. An incredibly good point. To answer the first question simply: I don't, no. I haven't hacked on GHC before, so was attempting to flesh out my original bug report to find a change that I might get my teeth into. I have to admit I hadn't thought about the technical barriers and thus rather haphazardly threw about the "let's loosen the stage restriction" part! > The user's guide has this to say on the subject: ... Indeed - I pasted that very snippet in comment:14, but I hadn't appreciated what the technical barriers were. What do you think is a sensible step forward? Change 2.b. in my previous comment to "Process NS first, then S. Splices within S can refer (via reify but ''not'' evaluation) to all names declared in NS or previous DGs), but no names within S"? That way, my original program in this ticket would work, but I wouldn't need any of the complexity of changing the stage restriction too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 18:38:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 18:38:13 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.6ff0308920b3fca536772b51a234752c@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Yes, I think that is practical in the short term. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 18:49:56 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 18:49:56 -0000 Subject: [GHC] #11362: T6137 doesn't pass with reversed uniques In-Reply-To: <046.176cbdce58fe0c2949bc42c9d1fa1775@haskell.org> References: <046.176cbdce58fe0c2949bc42c9d1fa1775@haskell.org> Message-ID: <061.0d42b3c093e2621396fa1340bd1fd379@haskell.org> #11362: T6137 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: 4012 Related Tickets: #11371 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Bartosz Nitka ): In [changeset:"023742e444a415001d86d50a6ec331fe71d50426/ghc" 023742e4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="023742e444a415001d86d50a6ec331fe71d50426" Add a testcase for #11362 This reproduces the issue that I encountered in #11362. Test Plan: this testcase Reviewers: simonpj, bgamari, austin Reviewed By: simonpj Subscribers: thomie, simonmar Differential Revision: https://phabricator.haskell.org/D1917 GHC Trac Issues: #11362 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 18:54:55 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 18:54:55 -0000 Subject: [GHC] #11569: make -j24 test In-Reply-To: <043.ebd4ab4cf2b889476fd8b09d162a3605@haskell.org> References: <043.ebd4ab4cf2b889476fd8b09d162a3605@haskell.org> Message-ID: <058.38c05277f9ae9b1e19641dcd4e6db762@haskell.org> #11569: make -j24 test -------------------------------+------------------------------- Reporter: mfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+------------------------------- Comment (by rwbarton): The failure for T3307 is due to this warning printed by the `make` run by the test: {{{ make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. }}} I suggest just unsetting `MAKEFLAGS` in `mk/test.mk`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 19:02:12 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 19:02:12 -0000 Subject: [GHC] #11361: Test tc253 doesn't pass with reversed uniques In-Reply-To: <046.5df15c1dcbce47b96e0a22d92e3160a0@haskell.org> References: <046.5df15c1dcbce47b96e0a22d92e3160a0@haskell.org> Message-ID: <061.bab6749b17eda0fb30c6c68ee1833664@haskell.org> #11361: Test tc253 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T11361, | T11361a Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Bartosz Nitka ): In [changeset:"426a25c719f74054758eaaf15daf5760f8d068fb/ghc" 426a25c7/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="426a25c719f74054758eaaf15daf5760f8d068fb" Make T11361 actually run with reversed uniques `-dunique-increment` doesn't work inside the file. Test Plan: I've discovered it doesn't work in D1917. Reviewers: simonpj, bgamari, austin Subscribers: thomie, simonmar Differential Revision: https://phabricator.haskell.org/D1918 GHC Trac Issues: #11361 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 19:36:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 19:36:06 -0000 Subject: [GHC] #9611: Suggest the cause of "No instance" errors involving multiple versions of a package In-Reply-To: <047.46300571edbd036da850eb10c4f281a5@haskell.org> References: <047.46300571edbd036da850eb10c4f281a5@haskell.org> Message-ID: <062.58deeb6675cd0ba0b69b85db4854453b@haskell.org> #9611: Suggest the cause of "No instance" errors involving multiple versions of a package -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Yuras Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Yuras): * owner: => Yuras Comment: I'll try to implement it unless someone already is on it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 20:24:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 20:24:39 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.b1190ebe75d25bd849f696e8f6a5fcaf@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Very well. I'll admit I'm sad to see this go into `-Wall`, as this is the first warning in `-Wall` that sometimes just absolutely can not be worked around without explicitly turning it off, but I see your reasoning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 20:35:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 20:35:35 -0000 Subject: [GHC] #11581: TypeError requires UndecidableInstances unnecessarily Message-ID: <047.4c36e92acb669f967ff5258393f77106@haskell.org> #11581: TypeError requires UndecidableInstances unnecessarily -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Priority: low | Milestone: Component: Compiler | Version: 8.0.1-rc2 (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: -------------------------------------+------------------------------------- The example from the `TypeError` documentation {{{ type family ByteSize x where ByteSize Word16 = 2 ByteSize Word8 = 1 ByteSize a = TypeError (Text "The type " :<>: ShowType a :<>: Text " is not exportable.") }}} requires `UndecidableInstances`: {{{ BS.hs:11:5: error: ? The type family application ?(TypeError ...)? is no smaller than the instance head (Use UndecidableInstances to permit this) ? In the equations for closed type family ?ByteSize? In the type family declaration for ?ByteSize? }}} Obviously there's no real danger of undecidability here. I tried changing the declaration of `TypeError` to {{{ type family TypeError :: ErrorMessage -> b where }}} but it didn't help. Same error. Is that a bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 20:38:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 20:38:47 -0000 Subject: [GHC] #9611: Suggest the cause of "No instance" errors involving multiple versions of a package In-Reply-To: <047.46300571edbd036da850eb10c4f281a5@haskell.org> References: <047.46300571edbd036da850eb10c4f281a5@haskell.org> Message-ID: <062.0f74710392ae5afe671813767931b62e@haskell.org> #9611: Suggest the cause of "No instance" errors involving multiple versions of a package -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Yuras Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1919 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Yuras): * status: new => patch * differential: => Phab:D1919 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 21:11:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 21:11:13 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.268a88b484907aa33bb808df5ad215ed@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): #10100, #10183 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Lemming, Perhaps it would help have introduce a mechanism for telling the compiler "I intentionally do not use this constraint" on either a per- context or per-class basis? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 21:24:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 21:24:50 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.cfe627d69f9f50118c34fe7d52e5ab80@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): #10100, #10183 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): Replying to [comment:4 bgamari]: > Lemming, Perhaps it would help have introduce a mechanism for telling the compiler "I intentionally do not use this constraint" on either a per- context or per-class basis? On the one hand, I would say, Yes, because we have ways to flag intentionally unused imports and unused identifiers and that works nicely. On the other hand, I wonder whether we can treat constraints and imports and identifiers the same way. What does it mean at all to have a redundant constraint? E.g. {{{ asTypeOf :: a -> a -> a asTypeOf x _ = x }}} has not the most general type. Is this a redundant constraint? I can write it more explicitly: {{{ asTypeOf1 :: (a ~ b) => a -> b -> a asTypeOf1 x _ = x }}} GHC-8.0 does not warn about any of these two. Should it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 21:44:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 21:44:44 -0000 Subject: [GHC] #11580: panic on incompatible options In-Reply-To: <044.f81a5f3f4d659979b389f8dba4789246@haskell.org> References: <044.f81a5f3f4d659979b389f8dba4789246@haskell.org> Message-ID: <059.e969467deb51dca7fedef4ff19bcf596@haskell.org> #11580: panic on incompatible options -------------------------------------+------------------------------------- Reporter: dougm | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: => newcomer Comment: Nice test :) Would you like to submit a patch? See [wiki:Newcomers] and [wiki:WorkingConventions/FixingBugs]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 21:58:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 21:58:22 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.09de0386aab378960303c2bead896124@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > this is the first warning in -Wall that sometimes just absolutely can not be worked around without explicitly turning it off Does this sentence have an implicit ?without losing 3-release compatibility?? Or is there really code that triggers this warning and cannot be worked around for a single set of GHC and library versions? We should stay explicit about these things. I conjecture that most users of GHC do not attempt to write 3-release-compatible code and are just interested in the most tidy code for their current target. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 22:44:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 22:44:16 -0000 Subject: [GHC] #8710: Overlapping patterns warning misplaced In-Reply-To: <047.1f227e0dac37dd7309646386f280164b@haskell.org> References: <047.1f227e0dac37dd7309646386f280164b@haskell.org> Message-ID: <062.1ed0c8d0129d95485eb60ca3af31a56a@haskell.org> #8710: Overlapping patterns warning misplaced -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1910 Wiki Page: | -------------------------------------+------------------------------------- Comment (by gkaracha): Replying to [comment:8 simonpj]: > > If we print a separate warning for every redundant clause it may become overwhelming > > Really? There are a few artificial examples in the testsuite, but I'd have thought that one error per redundant equation would be ok. Hmmm, true. The number of redundant clauses (and of those with inaccessible RHS) is bound by the number of clauses a match has (it's not the case with the uncovered though). In practice I have not seen matches with many redundant cases. Hence, I created Phab:D1920 too, which implements this approach (one warning per redundant clause, each with its own location). > > But still, I'd really like the common case of one redundant equation to look like > {{{ > Bug.hs:24:3: warning: -- Note correct line number > Pattern match(es) are redundant > In an equation for ?show?: > len _ = ... (at Bug.hs:24:3) > }}} > Or maybe even > {{{ > Bug.hs:24:3: warning: > Pattern match(es) are redundant > In an equation for ?show?: > len _ = ... -- No need to duplicate here > }}} > If there are more than one, then adding the individual locations is good > {{{ > Bug.hs:24:3: warning: > Pattern match(es) are redundant > In an equation for ?show?: > len _ = ... (at Bug.hs:24:3) > len _ = ... (at Bug.hs:25:3) > }}} > but the herald should mention the first. > > Can't be hard, I guess. Agreed on this one too, I have updated Phab:D1910 to behave like this. Merge at will the revision you prefer. :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 15 22:44:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 15 Feb 2016 22:44:49 -0000 Subject: [GHC] #8710: Overlapping patterns warning misplaced In-Reply-To: <047.1f227e0dac37dd7309646386f280164b@haskell.org> References: <047.1f227e0dac37dd7309646386f280164b@haskell.org> Message-ID: <062.30575b095f7de791a5a3576cb2c2c1e9@haskell.org> #8710: Overlapping patterns warning misplaced -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1910, Wiki Page: | Phab:D1920 -------------------------------------+------------------------------------- Changes (by gkaracha): * differential: Phab:D1910 => Phab:D1910, Phab:D1920 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 04:00:58 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 04:00:58 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.de94e1b8b3b4257715ea8c7d345c2219@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): > Does this sentence have an implicit ?without losing 3-release compatibility?? No. I mean explicitly that there is code that I have in the wild that can only work around this by turning off the warning. If you write any class that only supplies a law then it will always appear to be a "redundant constraint". GHC doesn't know about the laws. Examples from real math: Upgrading a braided monoidal category to a symmetric monoidal category, or needing to know that the Cayley-Dickson construction that yields the complex numbers from the reals needs a the ring structure it builds over to be trivially involutive for the lifted ring structure to be commutative. These will simply always trigger this warning. In some cases not just for my library but for users of my library. Now, I've already patched most of that code to include an explicit, messy {{{#!hs #if __GLASGOW_HASKELL__ >= 800 {-# OPTIONS_GHC -fno-warn-redundant-constraints #-} #endif }}} But it is telling to me that this is the first situation where I've had to hack in explicit `{-# OPTIONS_GHC #-}` to work around a warning going haywire. At present the only other code I can think of where I turn on explicit `{-# OPTIONS_GHC #-}` is to hack around changes in sharing behavior across GHC versions that breaks particularly tricky uses of `{-# NOINLINE #-}`. To get `reflection` to work across a wide enough array of GHC versions I wind up with a cocktail that looks like: {{{#!hs {-# OPTIONS_GHC -fno-cse -fno-full-laziness -fno-float-in #-} }}} but that isn't hacking around warnings, but rather buggy code motion that changes in behavior across GHC versions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 04:04:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 04:04:55 -0000 Subject: [GHC] #11401: No match in record selector ctev_dest In-Reply-To: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> References: <046.fed72033f13421ee9cc8c1dd97426231@haskell.org> Message-ID: <061.a74ab8144b91e5fdbfd417da6a44f76d@haskell.org> #11401: No match in record selector ctev_dest -------------------------------------+------------------------------------- Reporter: Lemming | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11523 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ekmett): * cc: ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 04:05:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 04:05:49 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.16e1de3bbe9aa3da1523651ae033b9a8@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1891 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ekmett): * cc: ekmett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 04:13:30 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 04:13:30 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.7857ac08e7801bad488b9dfe065795fb@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gershomb): Note that there's another silliness here. If we have both -Wcompat and -Wredundant-constraints in the -Wall set, then there will be cases where the "correct" fix to a compat warning is precisely to introduce something that will trigger a redundant-constraints warning! I don't think we want to have actively contradictory warnings in the same -Wall set -- even if there is a way to fix this (i.e. explicitly turn off one or the other set of warnings) it will send users into a flurry of confusion. Also, I may have missed something, but where is the discussion that overturned the prior resolution of this ticket? I thought we had a good plan of action, arrived at after a fair amount of discussion. Now I see that there's been a 180-degree-turn, but I don't see any discussion surrounding it outside of "this warning really should be in -Wall." In particular, if this is moved into the -Wall set a few releases down the line, then at a minimum users won't need a version-specific-flag to disable it, which was the motivation for the prior plan to begin with. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 05:45:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 05:45:49 -0000 Subject: [GHC] #11578: Fix GHC on AArch64/Arm64 In-Reply-To: <044.82eed99cc066ccb994128f1f7245b038@haskell.org> References: <044.82eed99cc066ccb994128f1f7245b038@haskell.org> Message-ID: <059.3bcaac84b581963621dd59f39c33147e@haskell.org> #11578: Fix GHC on AArch64/Arm64 -------------------------------------+------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------- @@ -10,4 +10,4 @@ - * User @mfox reports that ghc-7.10 does build against llvm-3.7 and results - in a compiler that can build HEAD. - * That GHC 7.10 can be build against llvm-3.7 is a happy accident. - Versions of GHC are usually locked to a specific version of LLVM. + * ~~User @mfox reports that ghc-7.10 does build against llvm-3.7 and + results in a compiler that can build HEAD.~~ + * ~~That GHC 7.10 can be build against llvm-3.7 is a happy accident. + Versions of GHC are usually locked to a specific version of LLVM.~~ New description: Raising this to track discussion about GHC on Arm64. There is already some discussion in ticket #11206 (ARM is generally a disaster), but that ticket is about 32 bit Arm which is vastly different and is now mostly fixed. Information worth saving from #11206: * GHC 7.8.4 from Debian can build the ghc-8.0 branch, but cannot build HEAD because HEAD requires ghc-7.10 to build. * GHC 7.10 from Debian is broken because of an unfixed bug in llvm-3.5.2. * ~~User @mfox reports that ghc-7.10 does build against llvm-3.7 and results in a compiler that can build HEAD.~~ * ~~That GHC 7.10 can be build against llvm-3.7 is a happy accident. Versions of GHC are usually locked to a specific version of LLVM.~~ -- Comment (by erikd): @mfox The LLVM IR code generated by GHC-7.10.3 does not compile with LLVM-3.7. There is a fundamental imcompatibility. GHC-7.10.3 generated LLVM metata data instructions that LLVM-3.7 rejects. End of story. I have tried Debian's GHC where I manually edited the settings file to replace `/usr/bin/(opt|llc)-3.5` with `/usr/bin/(opt|llc)-3.7`. I also did the same for the 7.10.3 bindist you provided in ticket #11206. Both fail with the same error message: {{{ You are using a new version of LLVM that hasn't been tested yet! We will try though... /usr/bin/opt-3.7: /tmp/ghc16717_0/ghc_26.ll:7:6: error: unexpected type in metadata definition !0 = metadata !{metadata !"top", i8* null} }}} It would help if you could actually figure out what is made you think that the GHC-7.10.3 with LLVM-3.7 setup worked. Even if it just for documentation purposes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 08:03:17 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 08:03:17 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.70dd70ac0a4e20022714c85b6dc38bd0@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler (Type | Version: 7.7 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1241, #2247, | Differential Rev(s): Phab:D69 #8356, #9103, #9227 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by dfeuer): I think Simon's suggestion in [comment:30 comment 30] of a different notation for not-really-functional suggestions is much better than the per-instance pragma. Thus {{{#!hs class Foo a b c | a b -> c, a c ~> b }}} would clearly indicate that `a` and `b` must solidly determine `c`, but that the type checker is free to guess `b` based on `a` and `c` when it thinks it needs to. One thing to note is that, as shown in [http://stackoverflow.com/a/35413064/1477667 this answer] to a related question I asked recently, functional dependencies are ''already'' dysfunctional. In particular, module import diamonds can lead to undetected fundep violations. I'd personally like to see the following: 1. Add a "soft dependency" `~>` as described. 2. Plug the module diamond loophole. 3. Translate fundeps into type families in core, so that `class Bar a b | a -> b` will let me write `funBar :: (Bar a b, Bar a b') => b :~: b'`. The translation could even be ''exposed'' by an extension, I imagine, so that `__Bar_1_DETERMINES_2` (or whatever) would be a usable type family. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 08:10:05 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 08:10:05 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.2d9d4b7b09f9d655f40e88721a87d9c8@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): @gershomb - re the missing discussion, this came up during the GHC Skype meeting yesterday, I was concerned that we had stopped adding new warnings to `-Wall` which is exactly what I wanted to avoid (see [https://mail.haskell.org/pipermail/ghc-devs/2016-January/010955.html]). I've also argued that we should put `-Wcompat` into `-Wall` for the same reason. However, I wasn't aware that there would be a conflict between the compat warnings and `-Wredundant-constraints`, nor was I aware that we planned to have compat warnings that were very difficult to act upon. So in the light of that, I suggest that we don't add warnings to `-Wall` that are not actionable or that conflict with other warnings in `-Wall`. Sadly that means that a lot of people won't see some of the compat warnings, but maybe that's ok. My apologies for diving into the discussion with partial information. But I do feel strongly about one thing: that `-Wall` should always be the set of all warnings that we believe it is both possible and sensible for programmers to act upon. We shouldn't try to freeze `-Wall` under a misguided desire for stability. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 08:14:13 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 08:14:13 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.aa3382594eb6dbdb76c5b6645ff4b4d3@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): > If you write any class that only supplies a law then it will always appear to be a "redundant constraint". One (not necessarily me) could argue that in a language where laws are just convention, one should not use superclasses to document such a convention. It is a bit similar to annotating functions with an unused argument of some type `Deprecated` instead of documenting that with a pragma or in the documentation. But OTOH, that would work by matching it with `_`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 08:24:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 08:24:44 -0000 Subject: [GHC] #11579: Bug in parser for named Haddock chunks since GHC 8.0.1-rc1 In-Reply-To: <050.4d0ef6c9d54d8fe326a15d5b3729d82a@haskell.org> References: <050.4d0ef6c9d54d8fe326a15d5b3729d82a@haskell.org> Message-ID: <065.a98365a206c2f7ebfe0aeabe21eb77ef@haskell.org> #11579: Bug in parser for named Haddock chunks since GHC 8.0.1-rc1 -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by darchon): As I reported on the doctest github issue tracker, https://github.com/sol/doctest/issues/117, named sections using multi-line comments still work, where: {{{ {- $bar some named chunk -} }}} results in: {{{ *Extract> extractDocStrings [" some\n named chunk\n"] }}} So it's only named sections using single-line comments that seem broken. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 10:22:29 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 10:22:29 -0000 Subject: [GHC] #11578: Fix GHC on AArch64/Arm64 In-Reply-To: <044.82eed99cc066ccb994128f1f7245b038@haskell.org> References: <044.82eed99cc066ccb994128f1f7245b038@haskell.org> Message-ID: <059.cd50783161321c1692f8dc5c84f39b47@haskell.org> #11578: Fix GHC on AArch64/Arm64 -------------------------------------+------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------- Comment (by mfox): @erikd I think you asked the right question and that the answer will surprise you; It doesn't work work with LLVM-3.7. It works without it: {{{ $ ghc-7.10.3 hello.hs -v Glasgow Haskell Compiler, Version 7.10.3, stage 2 booted by GHC version 7.6.3 Using binary package database: /usr/local/lib/ghc-7.10.3/package.conf.d/package.cache wired-in package ghc-prim mapped to ghc- prim-0.4.0.0-6cdc86811872333585fa98756aa7c51e wired-in package integer-gmp mapped to integer- gmp-1.0.0.0-3c8c40657a9870f5c33be17496806d8d wired-in package base mapped to base-4.8.2.0-5d0e263086c09cf3ebc7a9920d2d76e9 wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.10.0.0-62d3bceb439078a9e90ea2eeb7044dd9 wired-in package ghc mapped to ghc-7.10.3-2084d337d2d83783183750b0af41d317 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: wired-in package ghc-prim mapped to ghc- prim-0.4.0.0-6cdc86811872333585fa98756aa7c51e wired-in package integer-gmp mapped to integer- gmp-1.0.0.0-3c8c40657a9870f5c33be17496806d8d wired-in package base mapped to base-4.8.2.0-5d0e263086c09cf3ebc7a9920d2d76e9 wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.10.0.0-62d3bceb439078a9e90ea2eeb7044dd9 wired-in package ghc mapped to ghc-7.10.3-2084d337d2d83783183750b0af41d317 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *hello.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2016-02-14 17:59:53.924557751 UTC ms_mod = Main, ms_textual_imps = [import (implicit) Prelude] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file hello.hs Created temporary directory: /tmp/ghc22305_0 *** Checking old interface for Main: [1 of 1] Compiling Main ( hello.hs, hello.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (after optimization) = {terms: 7, types: 5, coercions: 0} *** Simplifier: Result size of Simplifier = {terms: 7, types: 5, coercions: 0} *** Tidy Core: Result size of Tidy Core = {terms: 7, types: 5, coercions: 0} writeBinIface: 1 Names writeBinIface: 14 dict entries *** CorePrep: Result size of CorePrep = {terms: 9, types: 6, coercions: 0} *** Stg2Stg: *** CodeGen: *** C Compiler: /usr/bin/gcc -fno-stack-protector -DNO_REGS -DUSE_MINIINTERPRETER -x c /tmp/ghc22305_0/ghc_2.hc -o /tmp/ghc22305_0/ghc_4.s -Wimplicit -fwrapv -fno-strict-aliasing -S '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc-7.10.3/include/ghcversion.h -I. -I/usr/local/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/include -I/usr/local/lib/ghc-7.10.3/integ_2aU3IZNMF9a7mQ0OzsZ0dS/include -I/usr/local/lib/ghc-7.10.3/include *** Assembler: /usr/bin/gcc -fno-stack-protector -DNO_REGS -DUSE_MINIINTERPRETER -I. -x assembler -c /tmp/ghc22305_0/ghc_4.s -o hello.o Upsweep completely successful. *** Deleting temp files: Deleting: /tmp/ghc22305_0/ghc_5.rsp /tmp/ghc22305_0/ghc_4.s /tmp/ghc22305_0/ghc_3.c /tmp/ghc22305_0/ghc_2.hc /tmp/ghc22305_0/ghc_1.hc Warning: deleting non-existent /tmp/ghc22305_0/ghc_3.c Warning: deleting non-existent /tmp/ghc22305_0/ghc_1.hc link: linkables are ... LinkableM (2016-02-16 10:21:57.144557751 UTC) Main [DotO hello.o] Linking hello ... *** C Compiler: /usr/bin/gcc -fno-stack-protector -DNO_REGS -DUSE_MINIINTERPRETER -c /tmp/ghc22305_0/ghc_6.c -o /tmp/ghc22305_0/ghc_7.o -I/usr/local/lib/ghc-7.10.3/include *** C Compiler: /usr/bin/gcc -fno-stack-protector -DNO_REGS -DUSE_MINIINTERPRETER -c /tmp/ghc22305_0/ghc_9.s -o /tmp/ghc22305_0/ghc_10.o -I/usr/local/lib/ghc-7.10.3/include *** Linker: /usr/bin/gcc -fno-stack-protector -DNO_REGS -DUSE_MINIINTERPRETER '-fuse- ld=gold' -Wl,-z,noexecstack -Wl,--no-as-needed -o hello hello.o -L/usr/local/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM -L/usr/local/lib/ghc-7.10.3/integ_2aU3IZNMF9a7mQ0OzsZ0dS -L/usr/local/lib/ghc-7.10.3/ghcpr_8TmvWUcS1U1IKHT0levwg3 -L/usr/local/lib/ghc-7.10.3/rts /tmp/ghc22305_0/ghc_7.o /tmp/ghc22305_0/ghc_10.o -Wl,-u,ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,base_GHCziPtr_Ptr_static_info -Wl,-u,ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,base_GHCziInt_I8zh_static_info -Wl,-u,base_GHCziInt_I16zh_static_info -Wl,-u,base_GHCziInt_I32zh_static_info -Wl,-u,base_GHCziInt_I64zh_static_info -Wl,-u,base_GHCziWord_W8zh_static_info -Wl,-u,base_GHCziWord_W16zh_static_info -Wl,-u,base_GHCziWord_W32zh_static_info -Wl,-u,base_GHCziWord_W64zh_static_info -Wl,-u,base_GHCziStable_StablePtr_static_info -Wl,-u,ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,base_GHCziPtr_Ptr_con_info -Wl,-u,base_GHCziPtr_FunPtr_con_info -Wl,-u,base_GHCziStable_StablePtr_con_info -Wl,-u,ghczmprim_GHCziTypes_False_closure -Wl,-u,ghczmprim_GHCziTypes_True_closure -Wl,-u,base_GHCziPack_unpackCString_closure -Wl,-u,base_GHCziIOziException_stackOverflow_closure -Wl,-u,base_GHCziIOziException_heapOverflow_closure -Wl,-u,base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,base_GHCziTopHandler_runIO_closure -Wl,-u,base_GHCziTopHandler_runNonIO_closure -Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,base_GHCziConcziSync_runSparks_closure -Wl,-u,base_GHCziConcziSignal_runHandlersPtr_closure -lHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM -lHSinteger- gmp-1.0.0.0-2aU3IZNMF9a7mQ0OzsZ0dS -lHSghc- prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3 -lHSrts -lCffi -lgmp -lm -lrt -ldl link: done *** Deleting temp files: Deleting: /tmp/ghc22305_0/ghc_12.rsp /tmp/ghc22305_0/ghc_11.rsp /tmp/ghc22305_0/ghc_10.o /tmp/ghc22305_0/ghc_9.s /tmp/ghc22305_0/ghc_8.rsp /tmp/ghc22305_0/ghc_7.o /tmp/ghc22305_0/ghc_6.c *** Deleting temp dirs: Deleting: /tmp/ghc22305_0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 10:29:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 10:29:08 -0000 Subject: [GHC] #8761: Make pattern synonyms work with Template Haskell In-Reply-To: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> References: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> Message-ID: <062.01a30f39c809ba72e95e28b4042d2c26@haskell.org> #8761: Make pattern synonyms work with Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: cocreature Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 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 bollmann): Replying to [comment:14 cocreature]: Have you been working on this cocreature? Otherwise, I'd love to take ownership of this ticket. :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 10:36:20 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 10:36:20 -0000 Subject: [GHC] #11578: Fix GHC on AArch64/Arm64 In-Reply-To: <044.82eed99cc066ccb994128f1f7245b038@haskell.org> References: <044.82eed99cc066ccb994128f1f7245b038@haskell.org> Message-ID: <059.76d4e7361479f9d7ebb619bc1d304e8a@haskell.org> #11578: Fix GHC on AArch64/Arm64 -------------------------------------+------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------- Comment (by mfox): Anywho, moving on. These are the tests that fail in HEAD: {{{ TEST="T2552 joao-circular T5654b-O1 T5654b-O0 T2552 T11195 T11303b T11276 T11374 linker_unload divbyzero T5435_dyn_asm T5435_v_gcc outofmem T5435_v_asm T3424 barton-mangler-bug T10052 T9329 T5313 T3586 recomp015 ghcilink004 integerConstantFolding TH_spliceE5_prof_ext recomp011 ghci004 ghci006 prog001 T8628 T8639_api T10508_api ffi014 dynCompileExpr T9203 haddock.Cabal haddock.compiler haddock.base T5321FD T5030 T4801 T5631 T5837 T9872a T5642 T9872b T3064 parsing001 T9872d T9872c T1969 T5321Fun T783 T9233 T9961" OVERALL SUMMARY for test run started at Mon Feb 15 16:05:12 2016 UTC 7:24:18 spent to go through 5015 total tests, which gave rise to 18823 test cases, of which 13838 were skipped 67 had missing libraries 4782 expected passes 81 expected failures 0 caused framework failures 1 unexpected passes 33 unexpected failures 21 unexpected stat failures }}} To get this good of a result you must build with: ./configure --disable-large-address-space -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 10:42:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 10:42:03 -0000 Subject: [GHC] #11578: Fix GHC on AArch64/Arm64 In-Reply-To: <044.82eed99cc066ccb994128f1f7245b038@haskell.org> References: <044.82eed99cc066ccb994128f1f7245b038@haskell.org> Message-ID: <059.cef3260aec5cb19da1c5f962a24f3030@haskell.org> #11578: Fix GHC on AArch64/Arm64 -------------------------------------+------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------- Comment (by mfox): LLVM does work in HEAD though: {{{ ghc -v -fllvm hello.hs Glasgow Haskell Compiler, Version 8.1.20160209, stage 2 booted by GHC version 7.10.3 Using binary package database: /usr/local/lib/ghc-8.1.20160209/package.conf.d/package.cache Using binary package database: /home/admin/.ghc/aarch64-linux-8.1.20160209/package.conf.d/package.cache loading package database /usr/local/lib/ghc-8.1.20160209/package.conf.d loading package database /home/admin/.ghc/aarch64-linux-8.1.20160209/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.0.0 wired-in package rts mapped to rts wired-in package template-haskell mapped to template-haskell-2.11.0.0 wired-in package ghc mapped to ghc-8.1 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: loading package database /usr/local/lib/ghc-8.1.20160209/package.conf.d loading package database /home/admin/.ghc/aarch64-linux-8.1.20160209/package.conf.d wired-in package ghc-prim mapped to ghc-prim-0.5.0.0 wired-in package integer-gmp mapped to integer-gmp-1.0.0.1 wired-in package base mapped to base-4.9.0.0 wired-in package rts mapped to rts-1.0 wired-in package template-haskell mapped to template-haskell-2.11.0.0 wired-in package ghc mapped to ghc-8.1 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *hello.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2016-02-14 17:59:53.924557751 UTC ms_mod = Main, ms_textual_imps = [(Nothing, Prelude)] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file hello.hs *** Checking old interface for Main: [1 of 1] Compiling Main ( hello.hs, hello.o ) *** Parser: *** Renamer/typechecker: *** Desugar: Result size of Desugar (before optimization) = {terms: 15, types: 8, coercions: 0} Result size of Desugar (after optimization) = {terms: 13, types: 6, coercions: 0} *** Simplifier: Result size of Simplifier iteration=1 = {terms: 17, types: 8, coercions: 0} Result size of Simplifier = {terms: 17, types: 8, coercions: 0} *** Tidy Core: Result size of Tidy Core = {terms: 17, types: 8, coercions: 0} writeBinIface: 1 Names writeBinIface: 18 dict entries Created temporary directory: /tmp/ghc22455_0 *** CorePrep: Result size of CorePrep = {terms: 19, types: 9, coercions: 0} *** Stg2Stg: *** CodeGen: *** LLVM CodeGen: Using LLVM version: (3,7) *** LLVM Optimiser: /usr/local/bin/opt /tmp/ghc22455_0/ghc_2.ll -o /tmp/ghc22455_0/ghc_4.bc -mem2reg -globalopt '--enable-tbaa=true' *** LLVM Compiler: /usr/local/bin/llc -O1 '-relocation-model=static' /tmp/ghc22455_0/ghc_4.bc -o /tmp/ghc22455_0/ghc_5.lm_s '--enable-tbaa=true' *** LLVM Mangler: *** Assembler: /usr/bin/gcc -fno-stack-protector -DNO_REGS -DUSE_MINIINTERPRETER -I. -x assembler -c /tmp/ghc22455_0/ghc_6.s -o hello.o Upsweep completely successful. *** Deleting temp files: Deleting: /tmp/ghc22455_0/ghc_6.s /tmp/ghc22455_0/ghc_5.lm_s /tmp/ghc22455_0/ghc_4.bc /tmp/ghc22455_0/ghc_3.c /tmp/ghc22455_0/ghc_2.ll /tmp/ghc22455_0/ghc_1.ll Warning: deleting non-existent /tmp/ghc22455_0/ghc_3.c Warning: deleting non-existent /tmp/ghc22455_0/ghc_1.ll link: linkables are ... LinkableM (2016-02-16 10:42:45.064557751 UTC) Main [DotO hello.o] Linking hello ... *** C Compiler: /usr/bin/gcc -fno-stack-protector -DNO_REGS -DUSE_MINIINTERPRETER -c /tmp/ghc22455_0/ghc_7.c -o /tmp/ghc22455_0/ghc_8.o -I/usr/local/lib/ghc-8.1.20160209/include *** C Compiler: /usr/bin/gcc -fno-stack-protector -DNO_REGS -DUSE_MINIINTERPRETER -c /tmp/ghc22455_0/ghc_10.s -o /tmp/ghc22455_0/ghc_11.o -I/usr/local/lib/ghc-8.1.20160209/include *** Linker: /usr/bin/gcc -fno-stack-protector -DNO_REGS -DUSE_MINIINTERPRETER '-fuse- ld=gold' -Wl,-z,noexecstack -Wl,--no-as-needed -o hello -Wl,--gc-sections hello.o -L/usr/local/lib/ghc-8.1.20160209/base-4.9.0.0 -L/usr/local/lib/ghc-8.1.20160209/integer-gmp-1.0.0.1 -L/usr/local/lib/ghc-8.1.20160209/ghc-prim-0.5.0.0 -L/usr/local/lib/ghc-8.1.20160209/rts /tmp/ghc22455_0/ghc_8.o /tmp/ghc22455_0/ghc_11.o -Wl,-u,ghczmprim_GHCziTypes_Izh_static_info -Wl,-u,ghczmprim_GHCziTypes_Czh_static_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_static_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_static_info -Wl,-u,base_GHCziPtr_Ptr_static_info -Wl,-u,ghczmprim_GHCziTypes_Wzh_static_info -Wl,-u,base_GHCziInt_I8zh_static_info -Wl,-u,base_GHCziInt_I16zh_static_info -Wl,-u,base_GHCziInt_I32zh_static_info -Wl,-u,base_GHCziInt_I64zh_static_info -Wl,-u,base_GHCziWord_W8zh_static_info -Wl,-u,base_GHCziWord_W16zh_static_info -Wl,-u,base_GHCziWord_W32zh_static_info -Wl,-u,base_GHCziWord_W64zh_static_info -Wl,-u,base_GHCziStable_StablePtr_static_info -Wl,-u,ghczmprim_GHCziTypes_Izh_con_info -Wl,-u,ghczmprim_GHCziTypes_Czh_con_info -Wl,-u,ghczmprim_GHCziTypes_Fzh_con_info -Wl,-u,ghczmprim_GHCziTypes_Dzh_con_info -Wl,-u,base_GHCziPtr_Ptr_con_info -Wl,-u,base_GHCziPtr_FunPtr_con_info -Wl,-u,base_GHCziStable_StablePtr_con_info -Wl,-u,ghczmprim_GHCziTypes_False_closure -Wl,-u,ghczmprim_GHCziTypes_True_closure -Wl,-u,base_GHCziPack_unpackCString_closure -Wl,-u,base_GHCziIOziException_stackOverflow_closure -Wl,-u,base_GHCziIOziException_heapOverflow_closure -Wl,-u,base_ControlziExceptionziBase_nonTermination_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -Wl,-u,base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -Wl,-u,base_GHCziIOziException_allocationLimitExceeded_closure -Wl,-u,base_ControlziExceptionziBase_nestedAtomically_closure -Wl,-u,base_GHCziEventziThread_blockedOnBadFD_closure -Wl,-u,base_GHCziWeak_runFinalizzerBatch_closure -Wl,-u,base_GHCziTopHandler_flushStdHandles_closure -Wl,-u,base_GHCziTopHandler_runIO_closure -Wl,-u,base_GHCziTopHandler_runNonIO_closure -Wl,-u,base_GHCziConcziIO_ensureIOManagerIsRunning_closure -Wl,-u,base_GHCziConcziIO_ioManagerCapabilitiesChanged_closure -Wl,-u,base_GHCziConcziSync_runSparks_closure -Wl,-u,base_GHCziConcziSignal_runHandlersPtr_closure -lHSbase-4.9.0.0 -lHSinteger-gmp-1.0.0.1 -lHSghc-prim-0.5.0.0 -lHSrts -lCffi -lgmp -lm -lrt -ldl link: done *** Deleting temp files: Deleting: /tmp/ghc22455_0/ghc_13.rsp /tmp/ghc22455_0/ghc_12.rsp /tmp/ghc22455_0/ghc_11.o /tmp/ghc22455_0/ghc_10.s /tmp/ghc22455_0/ghc_9.rsp /tmp/ghc22455_0/ghc_8.o /tmp/ghc22455_0/ghc_7.c *** Deleting temp dirs: Deleting: /tmp/ghc22455_0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 10:47:20 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 10:47:20 -0000 Subject: [GHC] #11558: Using Cabal 1.22 against GHC 8.0 results in unhelpful errors In-Reply-To: <046.d2616ea949ac4d1153655c6314ef5133@haskell.org> References: <046.d2616ea949ac4d1153655c6314ef5133@haskell.org> Message-ID: <061.62d616e11a9aa7f077095ce1aa34eeea@haskell.org> #11558: Using Cabal 1.22 against GHC 8.0 results in unhelpful errors -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Package system | Version: 8.0.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1892 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Thanks thomie! This was merged to `ghc-8.0` as 7fc4300200a9e287d693e2df936e0fc9549de0a3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 11:30:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 11:30:55 -0000 Subject: [GHC] #11582: Redundant constraints warning complains that (a ~ b) is redundant Message-ID: <046.2363e0c9c1e65dfb1e8483d570038aef@haskell.org> #11582: Redundant constraints warning complains that (a ~ b) is redundant -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Lemming came up with an interesting example where the redundant constraints warning is arguable a bit too trigger-happy in #10635. Consider, {{{#!hs asTypeOf :: a -> a -> a asTypeOf x _ = x }}} We could equivalently rewrite this with an equality constraint, {{{#!hs asTypeOf1 :: (a ~ b) => a -> b -> a asTypeOf1 x _ = x }}} If compiled with GHC 8.0 with `-Wredundant-constraints` we see a warning, {{{ hi.hs:4:1: warning: ? Redundant constraint: a ~ b ? In the type signature for: asTypeOf1 :: (a ~ b) => a -> b -> a }}} But is this really unused? We may not have referenced the constraint in the RHS, but surely the typechecker has gleaned something from it. Perhaps we should simply ignore equality constraints when generating redundant constraint warnings? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 11:34:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 11:34:06 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.a425129ba3df70fecafa9d06032c45d9@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): #10100, #10183 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > GHC-8.0 does not warn about any of these two. Should it? Indeed GHC 8.0 warns that the `a ~ b` constraint is redundant. This is arguably wrong and I've opened #11582 for this case. This is almost certainly not the last example of this sort that we will find. However, I suspect that `-Wredundant-constraints` will help more users in the situation that mboes describes than it would hurt users with the cases you describe if enabled in `-Wall`. It doesn't seem unreasonable to me to require users writing code like `asTypeOf1` to explicitly disable this warning. At the moment this can only be done on with module-level granularity but hopefully in the future we will have [[Design/LocalWarningPragmas|mechanisms]] for silencing warnings with greater precision. Regardless, your points have demonstrated that there are some tricky issues here. It would be helpful if you could collect these thoughts on [[Design/Warnings/RedundantConstraints]]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 11:40:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 11:40:59 -0000 Subject: [GHC] #11583: Make warning names more consistent Message-ID: <046.2c5f65cdcdffbe526873fdbd4a154741@haskell.org> #11583: Make warning names more consistent -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Sven Panne points out that current warning naming conventions used in GHC are rather inconsistent. Since we are moving away from `-fwarn-` to `-W` it would be nice if we could also try to fix up the names themselves. We do, however, want to make sure that transition isn't more painful for users than necessary. For instance, the user should be able to get useful feedback from the compiler on what warning flags have changed with `s/-fwarn-/-W/` To this end I recommend the following, * We write down a consistent vocabulary for warning flag names * We keep `-fwarn-` flags as they are currently * We keep the inconsistently named -W flags corresponding to these `-fwarn-` flags * We add consistently named `-W` flags alongside these * We set a timeline for deprecating the inconsistent forms (perhaps in three or four releases) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 11:42:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 11:42:03 -0000 Subject: [GHC] #11583: Make warning names more consistent In-Reply-To: <046.2c5f65cdcdffbe526873fdbd4a154741@haskell.org> References: <046.2c5f65cdcdffbe526873fdbd4a154741@haskell.org> Message-ID: <061.5adf4e1cf0086ce6b79c6186d96f92fd@haskell.org> #11583: Make warning names more consistent -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -1,3 +1,5 @@ - Sven Panne points out that current warning naming conventions used in GHC - are rather inconsistent. Since we are moving away from `-fwarn-` to `-W` - it would be nice if we could also try to fix up the names themselves. + Sven Panne [[https://mail.haskell.org/pipermail/ghc- + devs/2016-February/011393.html|points out]] that current warning naming + conventions used in GHC are rather inconsistent. Since we are moving away + from `-fwarn-` to `-W` it would be nice if we could also try to fix up the + names themselves. New description: Sven Panne [[https://mail.haskell.org/pipermail/ghc- devs/2016-February/011393.html|points out]] that current warning naming conventions used in GHC are rather inconsistent. Since we are moving away from `-fwarn-` to `-W` it would be nice if we could also try to fix up the names themselves. We do, however, want to make sure that transition isn't more painful for users than necessary. For instance, the user should be able to get useful feedback from the compiler on what warning flags have changed with `s/-fwarn-/-W/` To this end I recommend the following, * We write down a consistent vocabulary for warning flag names * We keep `-fwarn-` flags as they are currently * We keep the inconsistently named -W flags corresponding to these `-fwarn-` flags * We add consistently named `-W` flags alongside these * We set a timeline for deprecating the inconsistent forms (perhaps in three or four releases) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 12:03:53 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 12:03:53 -0000 Subject: [GHC] #11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment Message-ID: <047.9b656b30dd7751cce1c00e17927ecd51@haskell.org> #11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment -------------------------------------+------------------------------------- Reporter: bollmann | Owner: bollmann Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.3 Haskell | Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In `Language.Haskell.TH.Syntax` it reads on the generation of fresh names: {{{ Although names generated by @newName@ cannot /be captured/, they can /capture/ other names. For example, this: >g = $(do > nm1 <- newName "x" > let nm2 = mkName "x" > return (LamE [VarP nm2] (LamE [VarP nm1] (VarE nm2))) > ) will produce the splice >g = \x -> \x0 -> x0 since the occurrence @VarE nm2@ is captured by the innermost binding of @x@, namely @VarP nm1 at . }}} I find this note quite misleading, especially since the above splice normally generates something like {{{ \ x -> \ x_a3vv -> x }}} where no inadvertent capture occurs. I belive this note should rather be something as follows: {{{ Although names generated by @newName@ cannot /be captured/, they can /capture/ other names. For example, suppose that the next invocation of newName would generate the name nm1 = x0, and we have the following splice, where mkName uses the very same name x0 for nm2: >g = $(do > nm1 <- newName "x" > let nm2 = mkName "x0" > return (LamE [VarP nm2] (LamE [VarP nm1] (VarE nm2))) > ) This will produce the following splice, where nm1 generated by newName captures nm2 assigned by mkName: >g = \x0 -> \x0 -> x0 In particular, now the occurrence @VarE nm2@ is captured by @VarP nm1@ and not by @VarP nm2" anymore (as was intended by the TH AST). }}} I'm happy to change this, if people agree :-). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 12:10:44 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 12:10:44 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.a70db8f973b91b151ce337b7047e3379@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): It's perfectly fine for `-Wall` to contain warnings that sometimes need to be disabled, for reasons of personal taste or necessity. A lot of our code has `-Wall -fno-warn-unused-do-binds -fno-warn-name-shadowing`, and it's quite often necessary to throw in a `-fno-warn-orphans` when there's no reasonable way to avoid an orphan. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 12:11:27 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 12:11:27 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.3deebcdc7d8d4562b07b438c5c9b5a74@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): #10100, #10183 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): Replying to [comment:6 bgamari]: > > GHC-8.0 does not warn about any of these two. Should it? > > Indeed GHC 8.0 warns that the `a ~ b` constraint is redundant. This is arguably wrong and I've opened #11582 for this case. This is almost certainly not the last example of this sort that we will find. I just re-checked: ghci-8.0.0.20160214 warns with -fwarn-redundant- constraints but not with -Wall. That is, -fwarn-redundant-constraints is no longer part of -Wall? But this is the subject of this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 12:15:47 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 12:15:47 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.63d65fc7518dccf0375a5b412d1c1841@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): #10100, #10183 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): Replying to [comment:6 bgamari]: > It doesn't seem unreasonable to me to require users writing code like `asTypeOf1` to explicitly disable this warning. At the moment this can only be done on with module-level granularity but hopefully in the future we will have [[Design/LocalWarningPragmas|mechanisms]] for silencing warnings with greater precision. If would prefer to disable the warning per constraint. E.g. I could wrap a not strictly needed constraint in a magic {{{Used :: Constraint -> Constraint}}}. However, this would not be possible in Haskell 98. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 12:36:38 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 12:36:38 -0000 Subject: [GHC] #11585: Overload the static form to reduce verbosity Message-ID: <056.41ddf713d7e0fe1de83ff400ce602f67@haskell.org> #11585: Overload the static form to reduce verbosity -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature | Status: new request | Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Static pointers are rarely used naked: most often they are defined at the base of a {{{Closure}}}, as defined in e.g. the {{{distributed-closure}}} and {{{distributed-static}}} packages. So a typical usage pattern is: {{{ distributeMap (closure (static (\x -> x * 2))) }}} which is more verbose than it needs to be. Ideally we'd just have to write {{{ distributeMap (static (\x -> x * 2)) }}} and let the static pointer be lifted to a {{{Closure}}} implicitly. i.e. what we want is to overload static literals, just like we already overload list literals and string literals. This is achieved by introducing the {{{IsStatic}}} type class and changing the typing rule for static forms slightly: {{{ static (e :: t) :: IsStatic p => p t }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 12:37:16 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 12:37:16 -0000 Subject: [GHC] #11585: Overload the static form to reduce verbosity In-Reply-To: <056.41ddf713d7e0fe1de83ff400ce602f67@haskell.org> References: <056.41ddf713d7e0fe1de83ff400ce602f67@haskell.org> Message-ID: <071.cf986f96c2e2a0b3176e83c568d49484@haskell.org> #11585: Overload the static form to reduce verbosity -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by facundo.dominguez: @@ -16,2 +16,2 @@ - This is achieved by introducing the {{{IsStatic}}} type class and changing - the typing rule for static forms slightly: + This could be achieved by introducing the {{{IsStatic}}} type class and + changing the typing rule for static forms slightly: New description: Static pointers are rarely used naked: most often they are defined at the base of a {{{Closure}}}, as defined in e.g. the {{{distributed-closure}}} and {{{distributed-static}}} packages. So a typical usage pattern is: {{{ distributeMap (closure (static (\x -> x * 2))) }}} which is more verbose than it needs to be. Ideally we'd just have to write {{{ distributeMap (static (\x -> x * 2)) }}} and let the static pointer be lifted to a {{{Closure}}} implicitly. i.e. what we want is to overload static literals, just like we already overload list literals and string literals. This could be achieved by introducing the {{{IsStatic}}} type class and changing the typing rule for static forms slightly: {{{ static (e :: t) :: IsStatic p => p t }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 12:50:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 12:50:41 -0000 Subject: [GHC] #11585: Overload the static form to reduce verbosity In-Reply-To: <056.41ddf713d7e0fe1de83ff400ce602f67@haskell.org> References: <056.41ddf713d7e0fe1de83ff400ce602f67@haskell.org> Message-ID: <071.623c5b2a10f05c290e96c91303819cc9@haskell.org> #11585: Overload the static form to reduce verbosity -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1923 Wiki Page: | -------------------------------------+------------------------------------- Changes (by facundo.dominguez): * differential: => Phab:D1923 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 14:23:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 14:23:55 -0000 Subject: [GHC] #11586: GHC 8.0 can't be bootstrapped with GHC 8.0 Message-ID: <046.7e2029da3c938692bfa3f263a2004860@haskell.org> #11586: GHC 8.0 can't be bootstrapped with GHC 8.0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Build System | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems that GHC 8.0 can't bootstrap itself. With a clean `ghc-8.0` tree and `ghc` from the 8.0.1-rc2 release in `PATH` on x86-64 Debian things fall apart quite quickly, {{{ $ ghc -V The Glorious Glasgow Haskell Compilation System, version 8.0.0.20160204 $ ./boot $ ./configure $ make -j2 + test -f mk/config.mk.old + cmp -s mk/config.mk mk/config.mk.old + cp -p mk/config.mk mk/config.mk.old touch -r mk/config.mk.old mk/config.mk + test -f mk/project.mk.old + cmp -s mk/project.mk mk/project.mk.old touch -r mk/project.mk.old mk/project.mk + test -f compiler/ghc.cabal.old + cmp -s compiler/ghc.cabal compiler/ghc.cabal.old touch -r compiler/ghc.cabal.old compiler/ghc.cabal ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds "rm" -f compiler/stage1/build/Config.hs "inplace/bin/ghc-cabal" configure libraries/ghc-boot dist-boot "" --with- ghc="/opt/exp/ghc/roots/8.0.1-rc2/bin/ghc" --with-ghc- pkg="/opt/exp/ghc/roots/8.0.1-rc2/bin/ghc-pkg" --package- db=/opt/exp/ghc/ghc-8.0/libraries/bootstrapping.conf --disable-library- for-ghci --enable-library-vanilla --disable-library-profiling --disable- shared --with-hscolour="/home/ben/.cabal/bin/HsColour" --configure- option=CFLAGS="-Wall -fno-stack-protector -Werror=unused-but-set- variable -Wno-error=inline" --configure-option=LDFLAGS=" " --configure- option=CPPFLAGS=" " --gcc-options="-Wall -fno-stack-protector -Werror =unused-but-set-variable -Wno-error=inline " --constraint "binary == 0.8.2.0" --constraint "Cabal == 1.23.1.0" --constraint "hpc == 0.6.0.3" --constraint "ghc-boot == 8.0.0.20160211" --constraint "hoopl == 3.10.2.1" --constraint "transformers == 0.5.1.0" --constraint "template-haskell == 2.11.0.0" --constraint "terminfo == 0.4.0.2" --with-gcc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with- alex="/home/ben/.cabal/bin/alex" --with-happy="/home/ben/.cabal/bin/happy" Creating compiler/stage1/build/Config.hs ... Configuring ghc-boot-8.0.0.20160211... done. ghc-cabal: ghc-pkg dump failed libraries/ghc-boot/ghc.mk:3: recipe for target 'libraries/ghc-boot/dist- boot/package-data.mk' failed make[1]: *** [libraries/ghc-boot/dist-boot/package-data.mk] Error 1 Makefile:129: recipe for target 'all' failed make: *** [all] Error 2 }}} In particular the failing command is {{{ $ /opt/exp/ghc/roots/8.0.1-rc2/bin/ghc-pkg dump --package- db=/opt/exp/ghc/ghc-8.0/libraries/bootstrapping.conf -v2 GHC package manager version 8.0.0.20160204 Timestamp 2016-02-12 09:21:06.076187903 UTC for /opt/exp/ghc/ghc-8.0/libraries/bootstrapping.conf/package.cache Timestamp 2016-02-12 09:21:06.076187903 UTC for /opt/exp/ghc/ghc-8.0/libraries/bootstrapping.conf (same as cache) using cache: /opt/exp/ghc/ghc-8.0/libraries/bootstrapping.conf/package.cache ghc-pkg: /opt/exp/ghc/ghc-8.0/libraries/bootstrapping.conf/package.cache: GHC.PackageDb.readPackageDb: inappropriate type (Not a valid Unicode code point!) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 14:59:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 14:59:01 -0000 Subject: [GHC] #11524: Something is amiss with quantification in pattern synonym type signatures In-Reply-To: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> References: <046.fa129b9f41d6d2f998f000d4b548aad1@haskell.org> Message-ID: <061.b4a141f1df39bcea6035a140ce6c1c51@haskell.org> #11524: Something is amiss with quantification in pattern synonym type signatures -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: Resolution: | PatternSynonyms 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:D1879, Wiki Page: | Phab:D1896 -------------------------------------+------------------------------------- Changes (by rdragon): * differential: Phab:D1879 => Phab:D1879, Phab:D1896 Comment: See Phab:D1896 for a fix of the pretty-printer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 15:20:37 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 15:20:37 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.664f6ed21f1e63d32065bf422997a470@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm fully agreed with the last volley of posts and have nothing new to contribute. @owst, it sounds like you want a go at implementing this ("this" being without the stage-restriction stuff). Go right ahead! :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 15:28:13 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 15:28:13 -0000 Subject: [GHC] #11583: Make warning names more consistent In-Reply-To: <046.2c5f65cdcdffbe526873fdbd4a154741@haskell.org> References: <046.2c5f65cdcdffbe526873fdbd4a154741@haskell.org> Message-ID: <061.c938a74864b4240a1c77329a2813b30e@haskell.org> #11583: Make warning names more consistent -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by heisenbug): * cc: heisenbug (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 15:29:26 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 15:29:26 -0000 Subject: [GHC] #11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment In-Reply-To: <047.9b656b30dd7751cce1c00e17927ecd51@haskell.org> References: <047.9b656b30dd7751cce1c00e17927ecd51@haskell.org> Message-ID: <062.bd96478087ea2636f92071615a8c8284@haskell.org> #11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment -------------------------------------+------------------------------------- Reporter: bollmann | Owner: bollmann Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): That comment seems utterly wrong to me. Can you observe the weird capturing behavior described? What's your example? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 15:56:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 15:56:02 -0000 Subject: [GHC] #11383: CAFs lose sharing due to implicit call stacks In-Reply-To: <047.7956a69fc4ebcb0a87f22be719b572d1@haskell.org> References: <047.7956a69fc4ebcb0a87f22be719b572d1@haskell.org> Message-ID: <062.672d80011d4f0370cf8a62563ba0ec08@haskell.org> #11383: CAFs lose sharing due to implicit call stacks -------------------------------------+------------------------------------- Reporter: simonmar | Owner: gridaphobe Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #11298 | Differential Rev(s): Phab:D1912 Wiki Page: | -------------------------------------+------------------------------------- Changes (by j.waldmann): * cc: j.waldmann (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 16:56:12 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 16:56:12 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.c0cfa921e199b3edd8b341fb63202407@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by syd): For the record, I created the wiki page: https://ghc.haskell.org/trac/ghc/wiki/Proposal/HelpfulImportError I'm sending it to glasgow-haskell-users@ now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 17:20:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 17:20:41 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.8fbd371d2cfe4da077cef6426636e55f@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:24 syd]: > For the record, I created the wiki page: https://ghc.haskell.org/trac/ghc/wiki/Proposal/HelpfulImportError Just to clarify, this feature is only relevant to `ghc --make` (and therefore may not benefit future cabal versions, as there's a chance that cabal will move away from using `ghc --make` altogether)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 17:29:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 17:29:14 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.f083870a575932180e08b9455afcfa91@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by syd): Replying to [comment:25 hvr]: > Replying to [comment:24 syd]: > > For the record, I created the wiki page: https://ghc.haskell.org/trac/ghc/wiki/Proposal/HelpfulImportError > > Just to clarify, this feature is only relevant to `ghc --make` (and therefore may not benefit future cabal versions, as there's a chance that cabal will move away from using `ghc --make` altogether)? The mapping suggestion is only relevant to `ghc --make`, yes. If cabal moves away from using `ghc --make`, then that becomes cabal's responsibility. The import typo warning will stay relevant either way, but it may be implemented by using cabal's `exposed-modules` or `other- modules` instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 18:31:11 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 18:31:11 -0000 Subject: [GHC] #8761: Make pattern synonyms work with Template Haskell In-Reply-To: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> References: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> Message-ID: <062.3858079d82f9f907bcfc273f92a5c984@haskell.org> #8761: Make pattern synonyms work with Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by cocreature): * owner: cocreature => Comment: Replying to [comment:16 bollmann]: > Replying to [comment:14 cocreature]: > > Have you been working on this cocreature? Otherwise, I'd love to take ownership of this ticket. :-) I started working on it, but I ran out of time to finish it. I just pushed the [https://github.com/cocreature/ghc/tree/th-patsyns current status]. Feel free to pick it up or start from scratch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 18:41:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 18:41:19 -0000 Subject: [GHC] #9887: No message when GHCi reusing compiled code (was: No message when GCHI reusing compiled code) In-Reply-To: <045.cf91be422b5fc2a64d8ab73a523f6c8e@haskell.org> References: <045.cf91be422b5fc2a64d8ab73a523f6c8e@haskell.org> Message-ID: <060.513fbcd98b14aab080606fa3370a424b@haskell.org> #9887: No message when GHCi reusing compiled code -------------------------------------+------------------------------------- Reporter: jsrice | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 19:07:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 19:07:01 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages In-Reply-To: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> References: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> Message-ID: <067.cc9e281213cfc250456a2ff44589f8b7@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by j.waldmann): * cc: j.waldmann (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 19:14:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 19:14:06 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.662234373967d62be6d2d1a2393aca24@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by niteria): I've done some profiling today and I've optimized `piResultTys` a bit. Here are the results (this is built with prof): {{{ Benchmark name baseline with-inscope without-inscope tests/alloc/T5030 1084862416 1198020320 1084861344 tests/alloc/T9872a 5426538936 5576679896 5426504344 tests/alloc/T9872b 7807323280 8022344352 7728326496 tests/alloc/T9872c 7113767856 7405191768 7113729216 }}} `baseline` is the current incorrect implementation that doesn't compute the in-scope sets. `with-inscope` is https://phabricator.haskell.org/P97 - an implementation where the `coreView` that was hidden in `splitPiTy_maybe` and in `getTyVar_maybe` is done only once and both are inlined. This is the hint that I got from profiling, there was a significant difference in bytes allocated by `splitPiTy_maybe`. `without-inscope` is https://phabricator.haskell.org/P95 - a version of `with-inscope` that's doesn't compute the in-scope sets. So `without-inscope` is a strict, but small improvement over `baseline` performance wise, but the cost of computing the `in-scope` sets is non- trivial, so the correct version has a performance penalty. Are we willing to accept it in the name of correctness? The correct version has to do more work. The hot path is `cmpTypeX -> typeKind -> piResultTys`, I believe `cmpTypeX` already has the relevant free vars in the `env`, so passing them down is what I'll try to do next. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 19:38:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 19:38:55 -0000 Subject: [GHC] #10818: GHC 7.10.2 takes much longer to compile some packages In-Reply-To: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> References: <052.bbf8ed2f6a4e18f5bbbbe47aede56c86@haskell.org> Message-ID: <067.66df2bd19b3a9d73421ec8c015d14399@haskell.org> #10818: GHC 7.10.2 takes much longer to compile some packages -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by j.waldmann): Here is some more timing info for travis: I added "time" measurements around the cabal commands https://travis-ci.org/jwaldmann/haskell-tpdb/builds/109678365 So the timing they are showing is indeed wallclock. Still, sometimes "user time" was larger than "real time". I suspect this is because cabal uses `-j $ncpus` by default. I think for `cabal install --dependencies` this means to compile them in parallel, which is OK, but for `cabal build` this means to pass `-j $ncpus` to ghc, which decreases performance, and sometimes drastically so. So, I put explicit `-j 1` for these commands, https://travis-ci.org/jwaldmann/haskell-tpdb/builds/109683703 and now the timings look at least somewhat reasonable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 20:09:51 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 20:09:51 -0000 Subject: [GHC] #11587: Place shared objects in LIBDIR Message-ID: <046.ae680f55d8340157abb914750c3f9267@haskell.org> #11587: Place shared objects in LIBDIR -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Package | Version: 7.10.3 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: -------------------------------------+------------------------------------- If one compiles a program with `-dynamic`, the resulting executable includes in its `rpath` the library directory of every Haskell package that the program links against. This causes a significant number of excess system calls at program start-up. For instance, in the case of a dynamically linked `ghc` executable on Debian 8, compiling a trivial "hello world" application produces over 800 `open` calls, the majority of which originate from the dynamic linker. e.g., {{{ $ strace -f -e open ghc-7.10.3 -c -fforce-recomp Test.hs 2>&1 | grep open ... open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/tls/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/tls/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/tls/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/tls/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/tls/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/tls/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) ... }}} The dynamic linker must look in nearly 25 Haskell library directories to locate every system library! This is madness. Instead of placing each shared library in its own directory, `$LIBDIR/$PKG_KEY/lib$PKG_KEY.so` as we do currently, why not just place them in `$LIBDIR`, e.g. `$LIBDIR/libPKG_KEY.so`. This would mean that we need to include only one directory, `$LIBDIR`, in `rpath`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 20:10:45 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 20:10:45 -0000 Subject: [GHC] #11587: Place shared objects in LIBDIR In-Reply-To: <046.ae680f55d8340157abb914750c3f9267@haskell.org> References: <046.ae680f55d8340157abb914750c3f9267@haskell.org> Message-ID: <061.675547540509ce42d9a6963f62d9278c@haskell.org> #11587: Place shared objects in LIBDIR -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Package system | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -42,1 +42,1 @@ - them in `$LIBDIR`, e.g. `$LIBDIR/libPKG_KEY.so`. This would mean that we + them in `$LIBDIR`, e.g. `$LIBDIR/lib$PKG_KEY.so`. This would mean that we New description: If one compiles a program with `-dynamic`, the resulting executable includes in its `rpath` the library directory of every Haskell package that the program links against. This causes a significant number of excess system calls at program start-up. For instance, in the case of a dynamically linked `ghc` executable on Debian 8, compiling a trivial "hello world" application produces over 800 `open` calls, the majority of which originate from the dynamic linker. e.g., {{{ $ strace -f -e open ghc-7.10.3 -c -fforce-recomp Test.hs 2>&1 | grep open ... open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/tls/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/tls/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../haske_GGvi737nHHfG6zm2y7Rimi/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/tls/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/tls/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../termi_6iVf4EBnOgfIaaOCLRs8jl/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/tls/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/tls/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/ghc/bin/../ghc_0AG9TOjDEtx4Ji3wSwHOBe/x86_64/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) ... }}} The dynamic linker must look in nearly 25 Haskell library directories to locate every system library! This is madness. Instead of placing each shared library in its own directory, `$LIBDIR/$PKG_KEY/lib$PKG_KEY.so` as we do currently, why not just place them in `$LIBDIR`, e.g. `$LIBDIR/lib$PKG_KEY.so`. This would mean that we need to include only one directory, `$LIBDIR`, in `rpath`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 20:13:27 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 20:13:27 -0000 Subject: [GHC] #11579: Bug in parser for named Haddock chunks since GHC 8.0.1-rc1 In-Reply-To: <050.4d0ef6c9d54d8fe326a15d5b3729d82a@haskell.org> References: <050.4d0ef6c9d54d8fe326a15d5b3729d82a@haskell.org> Message-ID: <065.3dcf096c60d2734545c034c8c208a1de@haskell.org> #11579: Bug in parser for named Haddock chunks since GHC 8.0.1-rc1 -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * priority: normal => high * component: Compiler => Compiler (Parser) * milestone: => 8.0.1 @@ -3,1 +3,1 @@ - {{{ + {{{#!hs @@ -11,1 +11,1 @@ - {{{ + {{{#!hs New description: Steps to reproduce: {{{#!hs -- Foo.hs module Foo where -- $bar some -- named chunk }}} {{{#!hs -- Extract.hs module Extract where import Prelude hiding (mod) import Data.Generics import DynFlags import FastString import GHC import GHC.Paths extractDocStrings :: IO [String] extractDocStrings = do extract . pm_parsed_source <$> do runGhc (Just libdir) $ do _ <- getSessionDynFlags >>= setSessionDynFlags . setHaddockMode guessTarget "Foo.hs" Nothing >>= setTargets . return [mod] <- depanal [] False parseModule mod where setHaddockMode :: DynFlags -> DynFlags setHaddockMode dynflags = (gopt_set dynflags Opt_Haddock) extract :: ParsedSource -> [String] extract m = [unpackFS s | HsDocString s <- everything (++) ([] `mkQ` return) m] }}} Expected result: {{{extractDocStrings}}} returns {{{" some\n named chunk"}}} Actual result: it returns {{{" some"}}} instead -- Comment: Oh dear, this should get fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 20:19:45 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 20:19:45 -0000 Subject: [GHC] #11580: panic on incompatible options In-Reply-To: <044.f81a5f3f4d659979b389f8dba4789246@haskell.org> References: <044.f81a5f3f4d659979b389f8dba4789246@haskell.org> Message-ID: <059.87120b82a044c58160500c6e605082b3@haskell.org> #11580: panic on incompatible options -------------------------------------+------------------------------------- Reporter: dougm | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1925 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1925 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 20:35:32 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 20:35:32 -0000 Subject: [GHC] #11587: Place shared objects in LIBDIR In-Reply-To: <046.ae680f55d8340157abb914750c3f9267@haskell.org> References: <046.ae680f55d8340157abb914750c3f9267@haskell.org> Message-ID: <061.79dcf44aba124c8ede07dd28b7a5c81a@haskell.org> #11587: Place shared objects in LIBDIR -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Package system | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 20:41:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 20:41:06 -0000 Subject: [GHC] #11587: Place shared objects in LIBDIR In-Reply-To: <046.ae680f55d8340157abb914750c3f9267@haskell.org> References: <046.ae680f55d8340157abb914750c3f9267@haskell.org> Message-ID: <061.92fda7cbbc3dcf49fef6149cac1c8bae@haskell.org> #11587: Place shared objects in LIBDIR -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Package system | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): > The dynamic linker must look in nearly 25 Haskell library directories to locate every system library! This is madness. Not only that, but just to spell it all out explicitly, * The dynamic linker has to look in those nearly 25 Haskell library directories for each Haskell library, too, making the behavior quadratic in the number of Haskell packages. * This applies not just to `ghc` itself, but to any executable that uses dynamic Haskell libraries. Some people have programs that use hundreds of different Haskell packages. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 20:42:22 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 20:42:22 -0000 Subject: [GHC] #7414: plugins always trigger recompilation In-Reply-To: <045.791037be90cd943b6dd26df93dd060d8@haskell.org> References: <045.791037be90cd943b6dd26df93dd060d8@haskell.org> Message-ID: <060.db1502577bae8e123642417a4c00dfd0@haskell.org> #7414: plugins always trigger recompilation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: plugin, | recompilation 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 conal): * cc: conal@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 21:11:47 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 21:11:47 -0000 Subject: [GHC] #10858: Smaller generated Ord instances In-Reply-To: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> References: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> Message-ID: <061.a867256bf954534c3b0697bcdc6a1582@haskell.org> #10858: Smaller generated Ord instances -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9557 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nkartashov): nomeata: so you have managed to get a little reduction of generated code size for compare but failed for the rest of operations? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 21:34:00 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 21:34:00 -0000 Subject: [GHC] #11586: GHC 8.0 can't be bootstrapped with GHC 8.0 In-Reply-To: <046.7e2029da3c938692bfa3f263a2004860@haskell.org> References: <046.7e2029da3c938692bfa3f263a2004860@haskell.org> Message-ID: <061.89938c27c8dfa5a3b51e49a2e116c5f1@haskell.org> #11586: GHC 8.0 can't be bootstrapped with GHC 8.0 -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Build System | Version: 7.10.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => invalid Comment: Never mind; my tree was merely not clean enough. Things seem to be find after a `distclean`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 22:13:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 22:13:06 -0000 Subject: [GHC] #11413: GHC 8.1.20160111 fails to bootstrap itself. In-Reply-To: <046.15e95fc56f5612748d97a6c11de5e498@haskell.org> References: <046.15e95fc56f5612748d97a6c11de5e498@haskell.org> Message-ID: <061.d861693353cd46037ec0701f29a3bcfa@haskell.org> #11413: GHC 8.1.20160111 fails to bootstrap itself. -------------------------------------+------------------------------------- Reporter: kgardas | Owner: thomie Type: bug | Status: new Priority: highest | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1869 Wiki Page: | Phab:D1897 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"525a304f8c010ce73f1456e507aca668eb4917ac/ghc" 525a304f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="525a304f8c010ce73f1456e507aca668eb4917ac" Make bootstrapping more robust Starting with GHC 8.0 we rely on GHC's native cabal macro generation. As a side-effect, this limits the packages in scope when compiling `ghc-cabal` for all bootstrapping GHCs. Reviewers: ezyang, austin, thomie, bgamari Reviewed By: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1897 GHC Trac Issues: #11413 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 22:13:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 22:13:06 -0000 Subject: [GHC] #8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning In-Reply-To: <042.758ba24a75f02bbb7ec81f3778780b4e@haskell.org> References: <042.758ba24a75f02bbb7ec81f3778780b4e@haskell.org> Message-ID: <057.54176bd4f312551fd9337568d1c044ae@haskell.org> #8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning -------------------------------------+--------------------------------- Reporter: asr | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Documentation | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+--------------------------------- Comment (by Ben Gamari ): In [changeset:"ad30c760f55205174b3b3472bbcd85fc51fb65d0/ghc" ad30c760/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ad30c760f55205174b3b3472bbcd85fc51fb65d0" Remove documentation for -Wlazy-unlifted-bindings This flag was supposed to be removed in 7.10. This finally resolves Trac #8022. Test Plan: Read it Reviewers: austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1922 GHC Trac Issues: #8022 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 22:13:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 22:13:06 -0000 Subject: [GHC] #9611: Suggest the cause of "No instance" errors involving multiple versions of a package In-Reply-To: <047.46300571edbd036da850eb10c4f281a5@haskell.org> References: <047.46300571edbd036da850eb10c4f281a5@haskell.org> Message-ID: <062.fb8177aa294377af72effcdfaf28c66c@haskell.org> #9611: Suggest the cause of "No instance" errors involving multiple versions of a package -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Yuras Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1919 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"5fc06b97b320e98febaa925085dac03e5b01fc5a/ghc" 5fc06b9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="5fc06b97b320e98febaa925085dac03e5b01fc5a" Suggest candidate instances in error message See Trac #9611. In "No instance..." error message we suggest instances for other types with the same occ name. It is usefull e.g. when we have two different versions of the same package installed. Test Plan: typecheck/should_fail/tcfail224 Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1919 GHC Trac Issues: #9611 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 22:13:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 22:13:06 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.a94ae833a618781756c63d026cab08d2@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: skvadrik Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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:D1902 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"693a54ea7ac6bdd229e0a297fc023d25263077b9/ghc" 693a54e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="693a54ea7ac6bdd229e0a297fc023d25263077b9" Improved error message about exported type operators. There is ambiguty between (1) type constructors and (2) data constructors in export lists, e.g. '%%' can stand for both of them. This ambiguity is resolved in favor of (2). If the exported data constructor is not in scope, but type constructor with the same name is in scope, GHC should suggest adding 'type' keyword to resolve ambiguity in favor of (1) and enabling 'TypeOperators' extension. The patch only extends the error message. See Trac #11432. Test Plan: `make test` Reviewers: simonpj, bgamari, austin Reviewed By: simonpj Subscribers: mpickering, thomie, goldfire, kosmikus Differential Revision: https://phabricator.haskell.org/D1902 GHC Trac Issues: #11432 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 22:13:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 22:13:06 -0000 Subject: [GHC] #11273: PowerPC NCG: Assign all STG float and double regs to PowerPC registers In-Reply-To: <047.9904a1c11b816b72007affef2eb0aa68@haskell.org> References: <047.9904a1c11b816b72007affef2eb0aa68@haskell.org> Message-ID: <062.1e7953c63db8694663f3bb334ab45df9@haskell.org> #11273: PowerPC NCG: Assign all STG float and double regs to PowerPC registers -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1914 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"31160036c71f6f913623ea5c889ec3963d49768c/ghc" 3116003/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="31160036c71f6f913623ea5c889ec3963d49768c" PowerPC: Improve float register assignment. On Linux assign F5 and F6 and D3 through D6 to caller-saved registers. Fixes #11273 Test Plan: validate on powerpc (I validated on powerpc64) Reviewers: bgamari, erikd, austin Reviewed By: erikd, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1914 GHC Trac Issues: #11273 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 22:13:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 22:13:06 -0000 Subject: [GHC] #11580: panic on incompatible options In-Reply-To: <044.f81a5f3f4d659979b389f8dba4789246@haskell.org> References: <044.f81a5f3f4d659979b389f8dba4789246@haskell.org> Message-ID: <059.a8ce5ebb6eb3be57a8c3eae29022ef78@haskell.org> #11580: panic on incompatible options -------------------------------------+------------------------------------- Reporter: dougm | Owner: Type: bug | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1925 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2b906af0dab01c30c28792d39161e01449b85cb0/ghc" 2b906af0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2b906af0dab01c30c28792d39161e01449b85cb0" DynFlags: Don't panic on incompatible Safe Haskell flags We just return an arbitrary value since we are destined to fail due to the error anyways. Fixes #11580. Test Plan: Needs to be tested Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1925 GHC Trac Issues: #11580 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 22:15:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 22:15:39 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.695225134338ea1372caea5badb7277a@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: skvadrik Type: bug | Status: closed Priority: highest | Milestone: 8.2.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1902 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed * milestone: 8.0.1 => 8.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 22:15:58 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 22:15:58 -0000 Subject: [GHC] #11273: PowerPC NCG: Assign all STG float and double regs to PowerPC registers In-Reply-To: <047.9904a1c11b816b72007affef2eb0aa68@haskell.org> References: <047.9904a1c11b816b72007affef2eb0aa68@haskell.org> Message-ID: <062.c079135ca82227a21203e660d9c5fd7e@haskell.org> #11273: PowerPC NCG: Assign all STG float and double regs to PowerPC registers -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: powerpc Type of failure: Runtime | Test Case: performance bug | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1914 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 22:16:41 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 22:16:41 -0000 Subject: [GHC] #9611: Suggest the cause of "No instance" errors involving multiple versions of a package In-Reply-To: <047.46300571edbd036da850eb10c4f281a5@haskell.org> References: <047.46300571edbd036da850eb10c4f281a5@haskell.org> Message-ID: <062.5d6d10f680e014cbed45d67826d4c932@haskell.org> #9611: Suggest the cause of "No instance" errors involving multiple versions of a package -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Yuras Type: feature request | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1919 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * failure: None/Unknown => Incorrect warning at compile-time * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 22:17:15 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 22:17:15 -0000 Subject: [GHC] #11580: panic on incompatible options In-Reply-To: <044.f81a5f3f4d659979b389f8dba4789246@haskell.org> References: <044.f81a5f3f4d659979b389f8dba4789246@haskell.org> Message-ID: <059.6536e2c11c2a0269128e7d0be9e95eed@haskell.org> #11580: panic on incompatible options -------------------------------------+------------------------------------- Reporter: dougm | Owner: Type: bug | Status: merge Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1925 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 22:22:09 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 22:22:09 -0000 Subject: [GHC] #10858: Smaller generated Ord instances In-Reply-To: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> References: <046.699ef2ff00fb815c84fa41ceb8d156c0@haskell.org> Message-ID: <061.1a69be0eddb7cf17e48ab84e3bb5d95e@haskell.org> #10858: Smaller generated Ord instances -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9557 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): It?s been a while, so I?m not sure. From a quick reading, I think the rationale is: For large product types, the chain of `compare` calls can be implemented with less code using `thenCmp`. Also for large product types, the default implementations of `(<)` etc. should be good enough. One question is what ?large? means here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 22:33:00 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 22:33:00 -0000 Subject: [GHC] #8927: Multiple case match at once In-Reply-To: <046.b6a1dc69b4ff427961f031ca91cfb46c@haskell.org> References: <046.b6a1dc69b4ff427961f031ca91cfb46c@haskell.org> Message-ID: <061.91a8972ef2c27640ee06053e2e3640f8@haskell.org> #8927: Multiple case match at once -------------------------------------+------------------------------------- Reporter: vxanica | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 (Parser) | Keywords: case, Resolution: | multiple Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3919 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gkaracha): * cc: gkaracha (added) * related: => #3919 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 22:53:34 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 22:53:34 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.5c6ee20e236c5faee3c5906b465a0128@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): From Sven Panne: Just a few quick remarks: * Whatever you do, never walk the file system tree up or down in an uncontrolled way, this will kill basically all benefits and is a show- stopper. File systems like NFS, NTFS, stuff on USB sticks etc. are so **horribly** slow when used that way that the walks will probably dominate your compilation time. And even under Linux it's not uncommon to have a few dozen directory levels and hundreds of thousands of files below our cwd: Just check out a few repositories, have some leftovers from compilations, tons of documentations in small HTML files etc., and this sums up quickly. Git walks up the tree, but only looking for a specific directory and will e.g. not cross mount points under normal circumstances. This is probably the limit of what you can do. * Caching between runs will be tricky: How will you invalidate the cache? People can (and will :-) do all kinds of evil things between runs, so how can you (in-)validate the cache quicker than re-scanning the file system again? * As a general rule to keep in mind during the design: Successful compiler runs should not pay a price. It's OK if things are a little bit slower when an error occurs, but the main use case is successful compilation. This is a bit like exceptions in most programming language implementations: They are more or less for free when you don't use them (yes, they have a cost even then because they complicate/invalidate some compiler optimizations, but let's forget that for now), and are often costly when you actually raise them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 22:54:11 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 22:54:11 -0000 Subject: [GHC] #10756: Allow users to indicate inaccessible patterns In-Reply-To: <044.44fc866587983798150a57353bc7bdbd@haskell.org> References: <044.44fc866587983798150a57353bc7bdbd@haskell.org> Message-ID: <059.32edaf384eea29f4b23a541be2545d12@haskell.org> #10756: Allow users to indicate inaccessible patterns -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gkaracha): * cc: george.karachalias@? (removed) * cc: gkaracha (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 22:57:49 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 22:57:49 -0000 Subject: [GHC] #11580: panic on incompatible options In-Reply-To: <044.f81a5f3f4d659979b389f8dba4789246@haskell.org> References: <044.f81a5f3f4d659979b389f8dba4789246@haskell.org> Message-ID: <059.f0218dc82b39374e55537032f5df7dd4@haskell.org> #11580: panic on incompatible options -------------------------------------+------------------------------------- Reporter: dougm | Owner: Type: bug | Status: merge Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1925 Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): For anyone else who was confused at first like me, the panic actually arises from specifying all ''three'' of `-XSafe`, `-XUnsafe` and `-XTrustworthy` because then the result of combining the first two flags is demanded when adding the third flag. We should still add * a test for `-XSafe -XUnsafe -XTrustworthy` (under `safeHaskell/flags`; I'm not going to do it right now just because I would have to build ghc to find out what the right error message is) * the original test in this ticket * possibly other versions of that test for the `-d`, `-f` and `-W` flags. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 16 23:00:23 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 16 Feb 2016 23:00:23 -0000 Subject: [GHC] #8927: Multiple case match at once In-Reply-To: <046.b6a1dc69b4ff427961f031ca91cfb46c@haskell.org> References: <046.b6a1dc69b4ff427961f031ca91cfb46c@haskell.org> Message-ID: <061.b55ebe3877ca4e44e91d38926c91833f@haskell.org> #8927: Multiple case match at once -------------------------------------+------------------------------------- Reporter: vxanica | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 (Parser) | Keywords: case, Resolution: | multiple Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3919 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I like the idea of disambiguating or-patterns and guards with parentheses, since I expect to be able to use or-patterns compositionally (nested within a larger pattern) anyways. So for hvr's last example {{{#!hs case x of (False | True) -> "123" }}} Don't know if this would cause major problems in the parser. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 02:27:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 02:27:58 -0000 Subject: [GHC] #11588: haddock documents misleading type signature for TypeError in GHC.TypeLits Message-ID: <045.930ffa474ea9a35c110a1f7afc57c5d3@haskell.org> #11588: haddock documents misleading type signature for TypeError in GHC.TypeLits -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ type family TypeError a :: b }}} is what is shown in the haddocks, which is misleading, at least to those accustomed to reading vanilla type families. 1) its impossible from the haddock info to know that the actual type signature is `type family TypeError (a :: ErrorMessage) :: b` , that requires reading the source of the module (a generally useful thing always, but still, disappointing that its needed to understand this) 2) i also need read the source to notice that the definition of the type family is a closed with no cases! It seems odd (at least to me) that haddock doesn't disclose the closedness. (this might be an artifact of it being an empty closed type family, which wasn't possible prior to ghc 8.0 anyways) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 02:28:44 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 02:28:44 -0000 Subject: [GHC] #11588: haddock documents misleading type signature for TypeError in GHC.TypeLits In-Reply-To: <045.930ffa474ea9a35c110a1f7afc57c5d3@haskell.org> References: <045.930ffa474ea9a35c110a1f7afc57c5d3@haskell.org> Message-ID: <060.67b526c62d9ec0edaf6e7449c1291892@haskell.org> #11588: haddock documents misleading type signature for TypeError in GHC.TypeLits -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- @@ -18,0 +18,4 @@ + + the relevant haddocks can be seen in the RC2 docs currently hosted at + http://downloads.haskell.org/~ghc/8.0.1-rc2/docs/html/libraries/base-4.9.0.0 + /GHC-TypeLits.html New description: {{{ type family TypeError a :: b }}} is what is shown in the haddocks, which is misleading, at least to those accustomed to reading vanilla type families. 1) its impossible from the haddock info to know that the actual type signature is `type family TypeError (a :: ErrorMessage) :: b` , that requires reading the source of the module (a generally useful thing always, but still, disappointing that its needed to understand this) 2) i also need read the source to notice that the definition of the type family is a closed with no cases! It seems odd (at least to me) that haddock doesn't disclose the closedness. (this might be an artifact of it being an empty closed type family, which wasn't possible prior to ghc 8.0 anyways) the relevant haddocks can be seen in the RC2 docs currently hosted at http://downloads.haskell.org/~ghc/8.0.1-rc2/docs/html/libraries/base-4.9.0.0 /GHC-TypeLits.html -- Comment (by carter): http://downloads.haskell.org/~ghc/8.0.1-rc2/docs/html/libraries/base-4.9.0.0 /GHC-TypeLits.html is a link -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 08:16:50 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 08:16:50 -0000 Subject: [GHC] #11582: Redundant constraints warning complains that (a ~ b) is redundant In-Reply-To: <046.2363e0c9c1e65dfb1e8483d570038aef@haskell.org> References: <046.2363e0c9c1e65dfb1e8483d570038aef@haskell.org> Message-ID: <061.ab089be538237acfce0ba85146e0c691@haskell.org> #11582: Redundant constraints warning complains that (a ~ b) is redundant -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: I don't agree. "Redundant" means that if you leave it off the function will still compile. And indeed {{{ asTypeOf1 :: a -> b -> a asTypeOf1 x _ = x }}} is just fine. So I don't know what you mean by saying "the type checker has gleaned something from it". I say it's behaving precisely as advertised, so I'll close as invalid. Re- open if I have misunderstood. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 08:28:26 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 08:28:26 -0000 Subject: [GHC] #11582: Redundant constraints warning complains that (a ~ b) is redundant In-Reply-To: <046.2363e0c9c1e65dfb1e8483d570038aef@haskell.org> References: <046.2363e0c9c1e65dfb1e8483d570038aef@haskell.org> Message-ID: <061.1155b03edfb6a06ef45a4a8193fbc1d2@haskell.org> #11582: Redundant constraints warning complains that (a ~ b) is redundant -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): I thought a bit about it and found that equality constraints and type class constraints actually differ in the following aspect: If you remove a redundant type class constraint from a function type signature then any code depending on that function will continue to be type correct and continue to work as before. In contrast to that, if you remove an equality constraint (or generalize a function like asTypeOf to a more general type), then code might no longer pass the type checker because of ambiguous types. That is, if you eagerly remove all redundant constraints then removed type class constraints will not do any harm but removed equality constraints might do so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 08:39:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 08:39:19 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.19958dbf2934d5a7c739577c7c794cb6@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): #10100, #10183 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): Replying to [comment:8 Lemming]: > If would prefer to disable the warning per constraint. E.g. I could wrap a not strictly needed constraint in a magic {{{Used :: Constraint -> Constraint}}}. However, this would not be possible in Haskell 98. A Haskell 98 compliant pragma might look like this: {{{#!hs {-# MINIMAL_CONSTRAINTS singleton () #-} singleton :: Ord a => a -> Set a }}} The pragma means: Type check "singleton" two times, once with the constraints `()` and once with the constraint `Ord a`. Warn about redundant constraints in the pragma but not in the signature of `singleton`. If you also want to warn about not maximally general types, then the pragma should even mention the whole type signature, e.g. {{{#!hs {-# MOST_GENERAL singleton :: a -> Set a #-} singleton :: Ord a => a -> Set a {-# MOST_GENERAL asTypeOf :: a -> b -> a #-} asTypeOf :: a -> a -> a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 08:39:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 08:39:38 -0000 Subject: [GHC] #11582: Redundant constraints warning complains that (a ~ b) is redundant In-Reply-To: <046.2363e0c9c1e65dfb1e8483d570038aef@haskell.org> References: <046.2363e0c9c1e65dfb1e8483d570038aef@haskell.org> Message-ID: <061.dbc45a2d2c5c1a87cdb5d5fe9157d4e9@haskell.org> #11582: Redundant constraints warning complains that (a ~ b) is redundant -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I see. Yes that is true. Sort of. Removing a type class with functional dependencies might have the same effect. Or a type class with a superclass that had functional depencies. Or a type class with a superclass equality like {{{ class (a~b) => C a b where ... }}} And with higher-kinded stuff I don't think we can predict with precision. I suppose you could have `-fwarn-redundant-constraints-for-definition` and `-fwarn-redundant-constraints-for-call-sites`, to say what level of redundancy you wanted to report or at least make best-efforts to report (see above). But I do see what you mean, and it might be good to have such an example in the user manual. Also if you felt like implementing per-signature control that would be cool. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 08:42:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 08:42:18 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.28df13dbe5825e0b717f57b80086aef1@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): #10100, #10183 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think it might be simpler just to say {{{ {-# NO_WARN_REDUNDANT_CONSTRAINTS singleton #-} }}} or something of that ilk. Or put it in the signature itself {{{ singleton :: {-# NO_WARN_REDUNDANT_CONSTRAINTS #-} Ord a => a -> Set a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 08:44:46 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 08:44:46 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.2de7ca318b4faf07f2067e8a8c3b4419@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by syd): Replying to [comment:27 simonpj]: > From Sven Panne: Just a few quick remarks: > > * Whatever you do, never walk the file system tree up or down in an uncontrolled way, this will kill basically all benefits and is a show- stopper. File systems like NFS, NTFS, stuff on USB sticks etc. are so **horribly** slow when used that way that the walks will probably dominate your compilation time. And even under Linux it's not uncommon to have a few dozen directory levels and hundreds of thousands of files below our cwd: Just check out a few repositories, have some leftovers from compilations, tons of documentations in small HTML files etc., and this sums up quickly. Git walks up the tree, but only looking for a specific directory and will e.g. not cross mount points under normal circumstances. This is probably the limit of what you can do. For the record: I never meant to walk the entire cwd, only source directories. While I get the general idea of 'never walk directory trees', in the end that is what you're doing anyway. In directories that only contain the source files, this approach would only reduce the amount of files opened. That said, I'm starting to think the cabal approach would be both easier and a smaller change. > * Caching between runs will be tricky: How will you invalidate the cache? People can (and will :-) do all kinds of evil things between runs, so how can you (in-)validate the cache quicker than re-scanning the file system again? Good point. Caching is probably not feasible here. > * As a general rule to keep in mind during the design: Successful compiler runs should not pay a price. It's OK if things are a little bit slower when an error occurs, but the main use case is successful compilation. This is a bit like exceptions in most programming language implementations: They are more or less for free when you don't use them (yes, they have a cost even then because they complicate/invalidate some compiler optimizations, but let's forget that for now), and are often costly when you actually raise them. Good feedback, thank you very much. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 08:48:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 08:48:13 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.0a734812985faeabcb26837e4ea019cb@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): #10100, #10183 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): Replying to [comment:10 simonpj]: > I think it might be simpler just to say > {{{ > {-# NO_WARN_REDUNDANT_CONSTRAINTS singleton #-} > }}} My goal was to somehow mark the redundant constraints, as we do with unused identifiers. I would not like to let the type checker ignore all redundant constraints at once in a signature. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 09:03:20 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 09:03:20 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.1f8daeabac007ef2b2475b2b0f64e821@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by simonpj): There is something odd happening here. '''I do not expect the in-scope set to be evaluated at all (that is, it should remain as a thunk) when substituting into for-all-free types'''. That was why I thought it worth writing `piResultTys` (plural). Consider `piResultTys (forall a b. blah) [t1, t2]`. If we substitute one `[a->t1]`, and then `[b->t2]` the first will substitute into `forall b. blah` and that will force the in-scope set. But if we do both at once, we won't, provided `blah` has no foralls, which is the wildly common case. So how can it possibly cost 10% of all of compile time in this single tiny function???? That is utterly bizarre. Are you sure ASSERTs are off? They do a lot of forcing! Maybe you can just `pprTrace` what is going on, to see if the in-scope sets are being unexpectedly forced. If so, fixing that might fix a LOT of things. Yes, it might be good to give the in-scope set to `piResultTy(s)` when it's available, but please, before you do that, can you get more insight into what is happening? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 09:06:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 09:06:33 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.20fb39eab30c50fa8e9625dda582db90@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): #10100, #10183 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > My goal was to somehow mark the redundant constraints, as we do with unused identifiers. I would not like to let the type checker ignore all redundant constraints at once in a signature. I hear you. But as compiler writers we have a limited complexity budget and number of implementation cycles, and we need to think how best to spend them in the service of our users. Both in the initial cost of design and implementation and in the ongoing cost of maintenance. I think what you want is hard, so there's a risk of making the best be the enemy of the good. (By all means try; I'm just saying.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 09:17:58 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 09:17:58 -0000 Subject: [GHC] #10635: -fwarn-redundant-constraints should not be part of -Wall In-Reply-To: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> References: <046.37bc7c73c7a26deffb461f9d58ce3c42@haskell.org> Message-ID: <061.0c1c9bbd5594192020764b088304fdf8@haskell.org> #10635: -fwarn-redundant-constraints should not be part of -Wall -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #9939, #9973, | Differential Rev(s): #10100, #10183 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): Replying to [comment:12 simonpj]: > I hear you. But as compiler writers we have a limited complexity budget and number of implementation cycles, and we need to think how best to spend them in the service of our users. Both in the initial cost of design and implementation and in the ongoing cost of maintenance. I think what you want is hard, so there's a risk of making the best be the enemy of the good. Bgamari suggested a general mechanism like [[Design/LocalWarningPragmas]] that would certainly make `NO_WARN_REDUNDANT_CONSTRAINTS` unnecessary. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 09:22:20 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 09:22:20 -0000 Subject: [GHC] #11581: TypeError requires UndecidableInstances unnecessarily In-Reply-To: <047.4c36e92acb669f967ff5258393f77106@haskell.org> References: <047.4c36e92acb669f967ff5258393f77106@haskell.org> Message-ID: <062.6ef0484ea1b421f2efc8b9220f8ef67b@haskell.org> #11581: TypeError requires UndecidableInstances unnecessarily -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 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 bgamari): * cc: diatchki (added) * failure: None/Unknown => GHC rejects valid program @@ -2,1 +2,1 @@ - {{{ + {{{#!hs @@ -21,1 +21,1 @@ - {{{ + {{{#!hs New description: The example from the `TypeError` documentation {{{#!hs type family ByteSize x where ByteSize Word16 = 2 ByteSize Word8 = 1 ByteSize a = TypeError (Text "The type " :<>: ShowType a :<>: Text " is not exportable.") }}} requires `UndecidableInstances`: {{{ BS.hs:11:5: error: ? The type family application ?(TypeError ...)? is no smaller than the instance head (Use UndecidableInstances to permit this) ? In the equations for closed type family ?ByteSize? In the type family declaration for ?ByteSize? }}} Obviously there's no real danger of undecidability here. I tried changing the declaration of `TypeError` to {{{#!hs type family TypeError :: ErrorMessage -> b where }}} but it didn't help. Same error. Is that a bug? -- Comment: Iavor, perhaps you can comment here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 09:37:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 09:37:51 -0000 Subject: [GHC] #9637: Type level programming needs an error function In-Reply-To: <047.3309ef9af8755e67dc24602c9e6ec77f@haskell.org> References: <047.3309ef9af8755e67dc24602c9e6ec77f@haskell.org> Message-ID: <062.7fb252cf5336b8a8216d5afe1386b49c@haskell.org> #9637: Type level programming needs an error function -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9180, #9636 | Differential Rev(s): Phab:D1236 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Lemming): I just want to add: The Helium people also thought about customizing error messages: See Heeren, Hage, Swierstra on [http://www.staff.science.uu.nl/~hage0101/scriptingthetypeinferencer.pdf Scripting the Type Inference Process]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 09:38:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 09:38:36 -0000 Subject: [GHC] #11581: TypeError requires UndecidableInstances unnecessarily In-Reply-To: <047.4c36e92acb669f967ff5258393f77106@haskell.org> References: <047.4c36e92acb669f967ff5258393f77106@haskell.org> Message-ID: <062.d650dd1861898696814efc235a83b7ea@haskell.org> #11581: TypeError requires UndecidableInstances unnecessarily -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 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): In the (necessarily conservative) story about the "size" of the RHS, we could certainly ignore all definitely-non-recursive type functions. `TypeError` is a case in point. By "recursive" I mean: given {{{ F t1 ... tn = ...(G s1 .. sm)... }}} can `G s1 .. sm` ever rewrite to call of `F` that is no smaller than the LHS? For open families `G` we can't know for sure, because `G` might get new RHSs. For closed `G` we could make a stab, perhaps. For `TypeError` we know for sure since it is built in. For now we could make it a special case: easy to do and useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 09:46:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 09:46:12 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.e0f7ea1f8e72f2ae2d2157baca51bc80@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > But in order to do so, we would have to run the declaration group containing the definition through the entire compiler pipeline, right up to linking, so that we can load it to run the splice in the latter declaration group to begin type checking it. GHC just isn't organized to work that way currently. Yes, this is the main reason for the fairly draconian staging restriction at present. But that's only when you want to RUN a splice. If you merely want to reify a type declared "earlier" (as in the Description of this ticket), that's much less stressful. But it exists already {{{ data F = MkF $(makeLenses 'F) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 10:08:33 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 10:08:33 -0000 Subject: [GHC] #11589: Reexports of wired-in packages don't work. Message-ID: <045.ef6d9437d9e0e94059219935e0ffea8d@haskell.org> #11589: Reexports of wired-in packages don't work. -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): Phab:D1926 | Wiki Page: -------------------------------------+------------------------------------- My fault. Have a patch. This bug is to make sure it goes into 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 10:09:22 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 10:09:22 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.0acb15effe72cfbef45be5d562f18b95@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by svenpanne): Replying to [comment:28 syd]: > For the record: I never meant to walk the entire cwd, only source directories. Hmm, what is a "source directory" then? And what is the exact use case for the feature? I'm a bit lost in this long ticket by now... For anything non-trivial, most people will probably use cabal or stack, anyway (and even for trivial stuff it's often quicker to do a "cabal init" or "stack new" than to fiddle around with epic GHC command lines). > While I get the general idea of 'never walk directory trees', in the end that is what you're doing anyway. Hmmm, unless things have changed, I don't think GHC walks the directory tree somehow. Trying to open a file in a few(!) directories is a fundamentally different operation than walking a directory hierarchy. If you try to open another file a tiny bit later, the OS will probably still have the relevant parts of the file system in its cache, so somehow your proposal is moving the caching strategy from the OS to user land, something which is rarely worthwhile and is tricky to get right and perform well. > In directories that only contain the source files, this approach would only reduce the amount of files opened. [...] Your proposal actually trades off trying to open several files from probably OS-cached directories against a single retrieval of a potentially large directory hierarchy. You probably save a few context switches, but lose in most other aspects. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 10:21:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 10:21:52 -0000 Subject: [GHC] #11483: Ghci integration with readline In-Reply-To: <043.d9012877ec55d7b6ecae2a655fc173ce@haskell.org> References: <043.d9012877ec55d7b6ecae2a655fc173ce@haskell.org> Message-ID: <058.d1546872ee56750366a7e0ab48e8b085@haskell.org> #11483: Ghci integration with readline -------------------------------------+------------------------------------- Reporter: Ivan | Owner: Geraldus Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Resolution: | Keywords: readline | complete Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10576 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * type: bug => feature request Comment: I agree that this is a feature request (although a very reasonable one!) Geraldus, you've done work in this area in the past, perhaps you'd be interested in looking at this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 10:25:14 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 10:25:14 -0000 Subject: [GHC] #11483: Ghci integration with readline In-Reply-To: <043.d9012877ec55d7b6ecae2a655fc173ce@haskell.org> References: <043.d9012877ec55d7b6ecae2a655fc173ce@haskell.org> Message-ID: <058.793990cffc4c664eb9fd5fa5d552bde3@haskell.org> #11483: Ghci integration with readline -------------------------------------+------------------------------------- Reporter: Ivan | Owner: Geraldus Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Resolution: | Keywords: readline | complete Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10576 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Geraldus): Surely, Thomie have assigned me to this ticket already. This will be very helpful for all kind of editors which provide autocompletions! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 10:27:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 10:27:34 -0000 Subject: [GHC] #11418: Suggest correct spelling when module is not found because of typo In-Reply-To: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> References: <042.13ab385d106ea3fbcb66ee6df2ee3a8d@haskell.org> Message-ID: <057.42722862c84fce49aa19fb8e905f4e09@haskell.org> #11418: Suggest correct spelling when module is not found because of typo -------------------------------------+------------------------------------- Reporter: syd | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by syd): Replying to [comment:29 svenpanne]: > For anything non-trivial, most people will probably use cabal or stack, anyway (and even for trivial stuff it's often quicker to do a "cabal init" or "stack new" than to fiddle around with epic GHC command lines). You're right. I modified the page (heavily) to reflect the result of this discussion. That should make it easier to follow along. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 10:30:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 10:30:59 -0000 Subject: [GHC] #11483: Ghci should TAB-complete keywords, not only identifiers (was: Ghci integration with readline) In-Reply-To: <043.d9012877ec55d7b6ecae2a655fc173ce@haskell.org> References: <043.d9012877ec55d7b6ecae2a655fc173ce@haskell.org> Message-ID: <058.6e54f2991e514e14ff1ed673c584d580@haskell.org> #11483: Ghci should TAB-complete keywords, not only identifiers -------------------------------------+------------------------------------- Reporter: Ivan | Owner: Geraldus Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Resolution: | Keywords: readline | complete Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10576 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 10:45:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 10:45:34 -0000 Subject: [GHC] #11589: Reexports of wired-in packages don't work. In-Reply-To: <045.ef6d9437d9e0e94059219935e0ffea8d@haskell.org> References: <045.ef6d9437d9e0e94059219935e0ffea8d@haskell.org> Message-ID: <060.dbc4538647e6fb24cbd106eebc1eb78b@haskell.org> #11589: Reexports of wired-in packages don't work. -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: cabal/cabal09 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1926 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => cabal/cabal09 Comment: The problem appears to be when you have something like the following in a cabal file, {{{ ? library reexported-modules: Data.List.NonEmpty }}} which results in {{{ $ runghc Setup.hs build Building reexport-0.1.0.0... Preprocessing library reexport-0.1.0.0... Preprocessing executable 'foo' for reexport-0.1.0.0... [1 of 1] Compiling Main ( Main.hs, dist/build/foo/foo- tmp/Main.o ) Main.hs:1:1: error:ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160122 for x86_64-unknown-linux): expectJust mkModuleToPkgConf CallStack (from ImplicitParams): error, called at compiler/utils/Maybes.hs:45:27 in ghc:Maybes 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 Feb 17 11:01:10 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 11:01:10 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.4dfb11ba30ec812ba1f0b03990966513@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by owst): Replying to [comment:31 simonpj]: > Yes, this is the main reason for the fairly draconian staging restriction at present. But that's only when you want to RUN a splice. If you merely want to reify a type declared "earlier" (as in the Description of this ticket), that's much less stressful. But it exists already > {{{ > data F = MkF > $(makeLenses 'F) > }}} Absolutely, since `F` is defined in the ''previous'' declaration group to `makeLenses 'F`. My proposal is to allow: {{{ data F = MkF f x = x g = $(mapM reify [''F, 'MkF, 'f] ...) }}} to work too (i.e. allow access via `reify` to (certain) declarations in the ''same'' declaration group). Implementation-wise, I can imagine that the changes will be something along the lines of: 1. Partition the expressions in a declaration group into those that contain splices, and those that do not, 1. Make each expression that contains a splice implicitly depend on all expressions that do not contain splices, 1. Traverse the the toposorted dependency graph and mark all nodes below or containing a splice as "splicy", 1. Process all nodes that are not marked splicy, 1. Make available the information about the non-splicy nodes in the environment, 1. Process all splicy nodes. Presumably, much of this can be taken from the code used to implement the features pointed out by Simon. I will likely start taking a serious look at this tonight. Any pointers/suggestions gratefully received! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 11:57:46 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 11:57:46 -0000 Subject: [GHC] #11590: Typo in documentation Message-ID: <055.6da9e84ca8b8331762d57514e277c626@haskell.org> #11590: Typo in documentation -------------------------------------+------------------------------------- Reporter: | Owner: mark_christiaens | Type: bug | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 8.0.1-rc2 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: -------------------------------------+------------------------------------- In "6.9. Packages" under "-trust" it says: "This command functions in the in a very similar way to ...". Should become "This command functions in a very similar way to ..." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 12:21:54 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 12:21:54 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.12c3e1dabb7784832d2dac610bb3634b@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): > My proposal is to allow: .... That does look feasible, since the code you are running in the splice all comes from other modules. Do you have a compelling use-case? Most of the debate here is about mechanism. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 13:04:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 13:04:18 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.7a8f92ff659a6ca2153a4a817c062536@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by owst): Replying to [comment:33 simonpj]: > That does look feasible, since the code you are running in the splice all comes from other modules. > > Do you have a compelling use-case? Most of the debate here is about mechanism. My original report was modified from a program (https://github.com/owst/Penrose/blob/master/Main.hs#L139) where I do some rudimentary commandline option parsing using a deriving Read instance. To generate the usage of the program, I map over my Option type's constructors and show each one. Something along the lines of: {{{#!hs {-# LANGUAGE TemplateHaskell #-} import System.Environment ( getArgs, getProgName ) import Data.List ( intercalate ) import Data.Either ( partitionEithers ) import Language.Haskell.TH data Option = Foo | Bar | Baz deriving (Read, Show) -- If the next non-comment line is commented this will not compile: -- opts.hs:13:17: -- ?Option? is not in the type environment at a reify -- In the splice: -- $(do { ty <- reify ''Option; -- let showCon (NormalC n _) = ... -- showCon _ = ... -- ....; -- return . LitE . StringL $ intercalate ", " strs }) $(return []) allowedArgs :: String allowedArgs = $(do ty <- reify ''Option let showCon (NormalC n _) = nameBase n showCon _ = error "Can't handle non-normal constructors" strs = case ty of (TyConI (DataD _ _ _ cons _)) -> map showCon cons _ -> error "Can't handle non-tycon type" return . LitE . StringL $ intercalate ", " strs) main :: IO () main = do parsedArgs <- map parseArg `fmap` getArgs case partitionEithers parsedArgs of ([], okArgs) -> putStrLn $ "Computing with: " ++ show okArgs (badArgs, _) -> do progName <- getProgName putStrLn $ "Bad args: " ++ intercalate ", " badArgs putStrLn $ "Usage: " ++ progName ++ " " ++ allowedArgs where parseArg :: String -> Either String Option parseArg x = case reads x of [(o, "")] -> Right o _ -> Left $ show x }}} When I first wrote the program, I didn't need the `$(return [])` trick (using 7.6.3) and I was surprised that it broke upon upgrading to 7.8.3. In fact, I solved the problem by moving the declaration of `Option` to another module, but I still think it would be reasonable to allow it within the same declaration group, hence the proposed change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 13:08:35 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 13:08:35 -0000 Subject: [GHC] #8761: Make pattern synonyms work with Template Haskell In-Reply-To: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> References: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> Message-ID: <062.56dc6e6a1a48b849e9aa9fa9a438bc03@haskell.org> #8761: Make pattern synonyms work with Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bollmann Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: Resolution: | Keywords: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bollmann): * owner: => bollmann -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 13:31:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 13:31:52 -0000 Subject: [GHC] #11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment In-Reply-To: <047.9b656b30dd7751cce1c00e17927ecd51@haskell.org> References: <047.9b656b30dd7751cce1c00e17927ecd51@haskell.org> Message-ID: <062.5b5685260f0a61ef1729f7f8e6f4aac7@haskell.org> #11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment -------------------------------------+------------------------------------- Reporter: bollmann | Owner: bollmann Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bollmann): Yea, I thought the comment to be wrong at first glance as well, in particular since I couldn't observe this capturing behavior at all: The mentioned splice generates something like {{{ \ x -> \ x_a3vv -> x }}} Which is exactly as specified in the TH AST and thus as expected. But at 2nd reading I was thinking that the original intent of this comment might have been to explain that a newly generated Name via `newName` might clash with the name chosen by `mkName`. That is, suppose `newName` would generate the name `x_1234` next, and by bad luck we generate the same name `x_1234` by means of `mkName`. Then these two names might interfere and capturing results (see my revised message in the ticket description at the very end for more details). Or is this case not possible and we should just remove this comment entirely instead of modifying it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 13:34:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 13:34:04 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.2676ae118438b652d75dec05c8b17d25@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Really? With the `$(return [])` the above code works in 7.8, 7.10 and HEAD. I think. I'm a bit surprised it doesn't work without the `$(return [])`, because data types are typechecked before value declarations. But it doesn't. If that worked, would you be happy? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 13:36:03 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 13:36:03 -0000 Subject: [GHC] #9041: NCG generates slow loop code In-Reply-To: <042.98aca4c930785f21daf56def917ee27d@haskell.org> References: <042.98aca4c930785f21daf56def917ee27d@haskell.org> Message-ID: <057.7ce0c02b79f1e06ed88d89a3772a6170@haskell.org> #9041: NCG generates slow loop code -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 13:57:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 13:57:42 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.9ebba2249fcb2825c0b1a273bcd442e7@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by niteria): Btw this is a subset of tests from #11196 which got 30-60% worse after TypeInType. > I do not expect the in-scope set to be evaluated at all (that is, it should remain as a thunk) when substituting into for-all-free types. I've experimented a bit and you're right. The in-scope set is never forced for T5030. Why do we see a difference then? I've compared: {{{ empty_subst = mkEmptyTCvSubst (pprTrace "forced" (ppr (ty,args)) $ mkInScopeSet $ tyCoVarsOfTypes (ty:args)) }}} with {{{ empty_subst = mkEmptyTCvSubst (pprTrace "forced" (ppr (ty,args)) $ mkInScopeSet $ tyCoVarsOfTypes []) }}} and they performed exactly the same! They were different without `pprTrace`. So I've tried: {{{ empty_subst = mkEmptyTCvSubst (pprTrace "forced" (ppr ()) $ mkInScopeSet $ tyCoVarsOfTypes []) }}} and it was better, back to the same amount of allocations as `baseline`. It appears that the difference in allocations comes from the thunks that get created or `empty_subst` being constant changes the generated code significantly. I will take a look at the core. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 14:04:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 14:04:06 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.071a73f9ec5a206414b9aca19b372d59@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by simonpj): Yes look at the core. I'm struggling to believe that this one thunk takes 10% of compile time! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 14:06:32 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 14:06:32 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.1147bfe945cd5c615c4747f511ecada9@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by owst): I can confirm that with `$(return [])` the code compiles on 7.8.3 and 7.10.3. My issue is that the `$(return [])` trick seems to be just that, a trick, required to make GHC accept a program that naively appears reasonable. I was hoping to be able to make a (small, I thought) change to GHC to allow this program to work without the trick. I know this isn't the most-important issue, but I was hoping to find a small ticket to work on as a first go at hacking on GHC that a) I understand the need for (albeit perhaps minor!), and b) is reasonably small, so I don't bite off more than I can chew. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 14:36:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 14:36:51 -0000 Subject: [GHC] #9611: Suggest the cause of "No instance" errors involving multiple versions of a package In-Reply-To: <047.46300571edbd036da850eb10c4f281a5@haskell.org> References: <047.46300571edbd036da850eb10c4f281a5@haskell.org> Message-ID: <062.80b22b51d448055113080d6b3596901e@haskell.org> #9611: Suggest the cause of "No instance" errors involving multiple versions of a package -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Yuras Type: feature request | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1919 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"4c6e95e4f92516a925fd2a1bce0c0f8b5b9cbd17/ghc" 4c6e95e4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4c6e95e4f92516a925fd2a1bce0c0f8b5b9cbd17" Small refactor and comments Related to the fix to Trac #9611 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 14:42:17 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 14:42:17 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.34c88d7bc3670769cc1cbc61ebaa2b0f@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by niteria): With the in-scope set: https://phabricator.haskell.org/P99 Without the in-scope set: https://phabricator.haskell.org/P98 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 15:03:59 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 15:03:59 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.821aee2c1038c544b2ff7ecf433aa0fa@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by niteria): Looking at {{{ let { a_sihF :: VarEnv Var [LclId, Str=DmdType] a_sihF = case TyCoRep.$wtyCoVarsOfTypesAcc (ghc-prim-0.5.0.0:GHC.Types.: @ Type ty_a6bU args_a6bV) FV.runFV2 ((containers-0.5.7.1:Data.IntMap.Base.Nil @ Var) `cast` (Sym UniqFM.N:UniqFM[0] _N :: containers-0.5.7.1:Data.IntMap.Base.IntMap Var ~R# UniqFM.UniqFM Var)) (ghc-prim-0.5.0.0:GHC.Types.[] @ Var) ((containers-0.5.7.1:Data.IntMap.Base.Nil @ Var) `cast` (Sym UniqFM.N:UniqFM[0] _N :: containers-0.5.7.1:Data.IntMap.Base.IntMap Var ~R# UniqFM.UniqFM Var)) of _ [Occ=Dead] { (# ww4_aeZD, ww5_aeZE #) -> ww5_aeZE } } in let { a1_sihE :: InScopeSet [LclId, Str=DmdType m] a1_sihE = VarEnv.InScope a_sihF 1# } in let { empty_subst_seCG :: TCvSubst [LclId, Str=DmdType m] empty_subst_seCG = TyCoRep.TCvSubst a1_sihE ((containers-0.5.7.1:Data.IntMap.Base.Nil @ Type) `cast` (Sym UniqFM.N:UniqFM[0] _N :: containers-0.5.7.1:Data.IntMap.Base.IntMap Type ~R# UniqFM.UniqFM Type)) ((containers-0.5.7.1:Data.IntMap.Base.Nil @ Coercion) `cast` (Sym UniqFM.N:UniqFM[0] _N :: containers-0.5.7.1:Data.IntMap.Base.IntMap Coercion ~R# UniqFM.UniqFM Coercion)) } in }}} it produces not 1, but 3 thunks. I will try to see if reducing that to 1 helps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 15:13:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 15:13:19 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.b3cedc14e3fde22a597d22f77c42225f@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by simonpj): I only see one superfluous one: `a_sihF` could be pushed inside the RHS of `a_s1hE`. And still -- at risk of repetition -- how can this one extra allocation account for 10% of the entire compiler allocation? Are there very many calls to this function some how? And if so why? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 15:40:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 15:40:29 -0000 Subject: [GHC] #11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment In-Reply-To: <047.9b656b30dd7751cce1c00e17927ecd51@haskell.org> References: <047.9b656b30dd7751cce1c00e17927ecd51@haskell.org> Message-ID: <062.069da3bbeb41871291cd2c26328e5cbb@haskell.org> #11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment -------------------------------------+------------------------------------- Reporter: bollmann | Owner: bollmann Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Without going into that code deeply, I think this comment is just wrong. My best advice is to try to reproduce the behavior it suggests. If that fails, delete the comment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 15:42:10 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 15:42:10 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.936cfd0766e637742f01e5fff2376a77@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by niteria): Changing it to: {{{ empty_subst = mkEmptyTCvSubst $! mkInScopeSet $! tyCoVarsOfTypes (ty:args) }}} gives me: {{{ $ ("/data/users/bnitka/ghc-perf/ghc-after/inplace/test spaces/ghc- stage2" -c T5030.hs -fforce-recomp -no-user-package-db -rtsopts -fno-warn- tabs -fno-warn-missed-specialisations -fno-ghci-history -freduction- depth=300 +RTS -V0 -tT5030.comp.stats --machine-readable -P -RTS) ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160216 for x86_64-unknown-linux): exprToType CallStack (from -prof): GHC.withCleanupSession (compiler/main/GHC.hs:(464,1)-(473,27)) GHC.runGhc (compiler/main/GHC.hs:(437,1)-(442,26)) GHC.defaultErrorHandler (compiler/main/GHC.hs:(377,1)-(409,7)) CoreSyn.CAF () Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Is it worth looking at? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 15:45:09 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 15:45:09 -0000 Subject: [GHC] #9813: Error when reifying type constructor In-Reply-To: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> References: <043.87c694a3ff71e05ab7fcde26c09627fe@haskell.org> Message-ID: <058.2ec4acc55dcdb2dc1f3cc6ac91637607@haskell.org> #9813: Error when reifying type constructor -------------------------------------+------------------------------------- Reporter: owst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1899 Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I also quite dislike `$(return [])` and support fixing this ticket. But I think your approach in comment:32 is quite a bit simpler than it may seem, because everything you say there is (I believe) already implemented except for point (5). In particular, GHC already does dependency analysis and chunking, and it would be terribly wrong not to have splicy things depend on everything else in the declaration group. The only problem, I believe, is that type-checking is held off until the whole group is renamed. (Splice action happens in the renamer.) It may or may not be hard to change that routing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 15:52:22 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 15:52:22 -0000 Subject: [GHC] #10266: Split base for Backpack In-Reply-To: <045.81e58b6e2b97dd039d014c76c016ea80@haskell.org> References: <045.81e58b6e2b97dd039d014c76c016ea80@haskell.org> Message-ID: <060.8d4380cc7a27932785b97b2b431edba9@haskell.org> #10266: Split base for Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: low | Milestone: Component: libraries/base | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Ericson2314): * cc: Ericson2314 (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 15:53:44 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 15:53:44 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.1a7fde8d7a9452552a3bdaf63ea29766@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by simonpj): Well by making it strict you'll certainly force the `tyCoVarsOfTypes` to happen, which isn't really a good idea. But there is something weird here: why is `exprToType` being called on an expression other than `(Type ty)`. Let's find out. You can make the panic print the expr. And it could come from {{{ applyTypeToArg fun_ty arg = piResultTy fun_ty (exprToType arg) }}} perhpas? Which call to `exprToType` (there aren't many) is at fault? More and more mysterious -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 16:05:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 16:05:39 -0000 Subject: [GHC] #11581: TypeError requires UndecidableInstances unnecessarily In-Reply-To: <047.4c36e92acb669f967ff5258393f77106@haskell.org> References: <047.4c36e92acb669f967ff5258393f77106@haskell.org> Message-ID: <062.d947e2f5cf49ae8e4631e2e97714e927@haskell.org> #11581: TypeError requires UndecidableInstances unnecessarily -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 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 rwbarton): Replying to [comment:2 simonpj]: > For `TypeError` we know for sure since it is built in. For now we could make it a special case: easy to do and useful. Yes, that's one option. I was in a bit of a rush when writing the ticket so let me try to explain what I meant by the last paragraph. I think the undecidability checker is computing the size of the type family application wrong. Compare these type family declarations: {{{#!hs type family T1 (a :: *) (b :: *) :: * type family T2 (a :: *) :: * -> * }}} and suppose I use one of these in the right-hand side of another type family: {{{#!hs type instance F Int a b = T1 String (a,b) -- or: T2 String (a,b) }}} If I used `T1`, the compiler definitely needs to take into account the size of both arguments because `T1` can match on both arguments. But if I used `T2`, then `T2` can only match on its first argument, and so `T2 String` is a saturated type family application, which has been further applied to `(a,b)`. This latter application is generative (if `f x ~ T2 String (a,b)` then `f ~ T2 String` and `x ~ (a,b)`) and so it is just as "inert" from the standpoint of type family reduction as if I had written {{{#!hs data Ap (f :: * -> *) a type instance F Int a b = Ap (T2 String) (a,b) }}} which the undecidability checker happily accepts. In short, I think the undecidability checker should only include the indexed arguments to a type family when calculating the size of a type family application, and not any additional parametric arguments. But it doesn't work that way currently. That's why I tried writing `type family TypeError :: ErrorMessage -> b where` rather than the current definition `type family TypeError (a :: ErrorMessage) :: b where`. In the case of `TypeError`, there is an additional twist: `TypeError` has an implicit kind argument. I couldn't figure out how to tell GHC that `TypeError` is parametric in the kind argument too, at least judging from the `:i TypeError` output. Shouldn't that be possible? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 16:10:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 16:10:23 -0000 Subject: [GHC] #11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment In-Reply-To: <047.9b656b30dd7751cce1c00e17927ecd51@haskell.org> References: <047.9b656b30dd7751cce1c00e17927ecd51@haskell.org> Message-ID: <062.844b27c75b869f740a9bfaa74f848c9c@haskell.org> #11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment -------------------------------------+------------------------------------- Reporter: bollmann | Owner: bollmann Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I don't understand what you are all talking about :) Try this complete program: {{{#!hs {-# LANGUAGE TemplateHaskell #-} import Language.Haskell.TH g = $(do nm1 <- newName "x" let nm2 = mkName "x" return (LamE [VarP nm2] (LamE [VarP nm1] (VarE nm2))) ) main = putStrLn $ g "1" "2" }}} It outputs `2`, as advertised by the comment in question. I happened to be looking at this the other day for unrelated reasons. `mkName "x"` means "whatever variable of name `x` is in scope", and `newName "x"` returns a new variable whose name is `x`. It is a different variable than is returned by other calls to `newName "x"`, but all of them capture the name `x` as far as `mkName` is concerned. As far as I can tell it's all exactly as explained in that comment. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 16:16:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 16:16:21 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.64f0049632324e125967c939c96754c4@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by niteria): I got 2 traces {{{ CallStack (from HasCallStack): pprSTrace, called at compiler/coreSyn/CoreSyn.hs:1595:33 in ghc:CoreSyn exprToType2, called at compiler/coreSyn/CoreSyn.hs:1585:53 in ghc:CoreSyn applyTypeToArg2, called at compiler/simplCore/SimplUtils.hs:251:37 in ghc:SimplUtils addValArgTo, called at compiler/simplCore/Simplify.hs:1114:57 in ghc:Simplify rebuild, called at compiler/simplCore/Simplify.hs:1477:5 in ghc:Simplify rebuildCall, called at compiler/simplCore/Simplify.hs:1406:11 in ghc:Simplify bad $fMonadIO CallStack (from HasCallStack): pprSTrace, called at compiler/coreSyn/CoreSyn.hs:1595:33 in ghc:CoreSyn exprToType2, called at compiler/coreSyn/CoreSyn.hs:1585:53 in ghc:CoreSyn applyTypeToArg2, called at compiler/simplCore/SimplUtils.hs:251:37 in ghc:SimplUtils addValArgTo, called at compiler/simplCore/Simplify.hs:1468:28 in ghc:Simplify rebuildCall, called at compiler/simplCore/Simplify.hs:1446:5 in ghc:Simplify rebuildCall, called at compiler/simplCore/Simplify.hs:1406:11 in ghc:Simplify bad Permute @ Flag }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 16:19:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 16:19:29 -0000 Subject: [GHC] #11591: thread blocked indefinitely in an MVar operation Message-ID: <048.f80b00024c78ab63fc5ff7af29581599@haskell.org> #11591: thread blocked indefinitely in an MVar operation --------------------------------------+------------------------------- Reporter: PaulNibin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Windows Architecture: x86_64 (amd64) | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+------------------------------- *Main> take 24 [13,26..] [13,26,39,52,65,78,91,104,117,130,143,156,169,182,195,208,221,234,247,260,273,286,299,312] *Main> cycle [1,2,3] [1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2, *Main> *Main> *Main> *Main> take 10 (cycle [1,2,3]) [1,2,3,1,2,3,1,2,3,1] *Main> take 10 (cycle "Hel) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-mingw32): thread blocked indefinitely in an MVar operation 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 Feb 17 16:28:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 16:28:06 -0000 Subject: [GHC] #2159: Use a more efficient representation than [DynFlag] In-Reply-To: <044.7464fd042e6f0696195045db2d1740fe@haskell.org> References: <044.7464fd042e6f0696195045db2d1740fe@haskell.org> Message-ID: <059.ff1c0daffb456fa7b5853220389f1fd3@haskell.org> #2159: Use a more efficient representation than [DynFlag] -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: fixed | 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 rwbarton): According to a statistical profiling run that I did some time ago GHC spends about 0.3% of its total time in the module `libraries/containers/Data/IntSet/Base.hs`. I don't know how much of that 0.3% is from `DynFlag`-checking versus other users of `IntSet` (another one is `UnVarSet`, whatever that is). Unfortunately, reliably measuring a speedup that is expected to be at most ~0.25% is itself a somewhat nontrivial project. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 16:51:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 16:51:13 -0000 Subject: [GHC] #11529: Show instance of Char should print literals for non-ascii printable charcters In-Reply-To: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> References: <045.b2e132b07816c9ef2342eb20bb4deb49@haskell.org> Message-ID: <060.513ace24d30e6be1f06b3761a73ee709@haskell.org> #11529: Show instance of Char should print literals for non-ascii printable charcters -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): I would love for something like comment:4 to become the default in ghci. It could even be simpler/stupider and just replace any sequence like `\12345` with the corresponding Unicode character wherever it appears. I mean when would you ever have such a string in the output of `show`, short of a weird custom Show instance? And it would be more robust to other weird custom Show instances, that used quotes in an unbalanced fashion. I don't think we should replace `\n` or `\ESC` or especially `\\` though. Just printable Unicode characters outside the ASCII range, probably. And we could decline to do the replacement if the replacement character can't be encoded in the user's locale. One drawback is that the user's font might not contain the Unicode characters in question, like mine does not contain `\12345`. So there should probably be an option to disable these replacements. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 17:09:24 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 17:09:24 -0000 Subject: [GHC] #11592: Self-kinded type varialbe accepted Message-ID: <046.963b9cb668cb74eedc86863125d8516d@haskell.org> #11592: Self-kinded type varialbe accepted -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Found when chasing #11407 {{{ data T (a::a) = Blah -- Accepted data S (b :: a) a = ... -- Rejected with: variable ?a? used as a kind variable before being bound -- as a type variable. Perhaps reorder your variables? }}} But `T` should be rejected too, for the same reason as `S` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 17:10:49 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 17:10:49 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.b6e6d39770a8cdf31c63e96fd119ab80@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by niteria): More than half the difference from allocations comes from `liftCoMatch` in `Unify`. In the same file there are calls to `eqType` and `typeKind`. Both of them call `piResultTys`. There are also comments like: `-- TODO (RAE): Remove this exponential behavior.`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 17:12:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 17:12:12 -0000 Subject: [GHC] #11592: Self-kinded type variable accepted (was: Self-kinded type varialbe accepted) In-Reply-To: <046.963b9cb668cb74eedc86863125d8516d@haskell.org> References: <046.963b9cb668cb74eedc86863125d8516d@haskell.org> Message-ID: <061.2995fc84b68d3dfbf441248f90947213@haskell.org> #11592: Self-kinded type variable accepted -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 17:48:08 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 17:48:08 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.d6d86de17a6b8b92370d510c4d676ba4@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by simonpj): There's a lot going on here. Concerning comment:39, here is what is happening: * `CoreSyn.applyTypeToArg` deliberately calls `piResultTy` with a possibly-bottom second argument. It'll be bottom when the type is `t1 -> t2` and the arg is some non-`Type` expression. * `piResultTy` calls `piResultTys` * When `piResultTys` finishes it calls `substTy` * Which looks at the substitution * Which is bottom because you built it strictly from its in-scope set * Which was bottom because the second arg to `piResultTy` was bottom Sigh. We could improve matters, but that is at least why you are getting the panic. So go back to being lazy. The exponential `typeKind` stuff seems more likely. Can you just count how many calls to `piResultTy` and/or `typeKind` are being made? And if large, then on what shaped types? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 17:53:26 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 17:53:26 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.809d9b530ba49cc8940b7ce43e68783b@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by niteria): `promoteCoercion` [https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/Unify.hs;4c6e95e4f92516a925fd2a1bce0c0f8b5b9cbd17$1073 here] contributes half of the increase in allocations. `promoteCoercion` is called 86576 times in total for T5030. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 17:59:40 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 17:59:40 -0000 Subject: [GHC] #11593: Template Haskell: Add a way to get names that are neither capturable nor capturing. Message-ID: <047.507e61696acbd5d73fd43e115fb3392c@haskell.org> #11593: Template Haskell: Add a way to get names that are neither capturable nor capturing. -------------------------------------+------------------------------------- Reporter: cgibbard | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Template | Version: 7.10.3 Haskell | Keywords: | Operating System: Unknown/Multiple yhjulwwiefzojcbxybbruweejw | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- From the documentation on newName: "Although names generated by newName cannot ''be captured'', they can ''capture'' other names." We recently ran into a case where we'd really have liked a way to create a name which can't interact at all with other names in the code, apart from where it is used in the construction of the TH expression. In this code: https://github.com/reflex-frp/reflex/blob/develop/src/Reflex/Dynamic/TH.hs The `newName "dynamicQuotedExpressionVariable"` used to be simply `newName "dyn"`, and we ended up having occurrences of `dyn` in the quasiquoted expressions (which would be constructed by NameG) get captured by that newName rather than referring to reflex-dom's definition of `dyn`. There ought to be some Q Name action which can be executed to give fresh names which can be used internally by a TH macro without fear that they can be referred to in any way other than using the Name value obtained from the action. The documentation for `Name` seems to suggest that newName is presently the closest thing, so perhaps we need a new primitive for creating totally-non-interacting Names. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 18:46:43 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 18:46:43 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.df65977dcbaa0725aaa6d3db53ff3b89@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by niteria): For completeness, there are `831805` calls to `piResultTys` with this distribution: {{{ 346492 piResultTys Levity -> * 308771 piResultTys * -> * -> * 147177 piResultTys * -> * 18410 piResultTys * -> * -> * -> * 10407 piResultTys * 142 piResultTys * -> # 70 piResultTys Levity 66 piResultTys * -> Constraint 24 piResultTys (* -> *) -> Constraint }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 18:52:57 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 18:52:57 -0000 Subject: [GHC] #11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied Message-ID: <045.7c07d2218cc40ac347ede40d7f240131@haskell.org> #11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 (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: -------------------------------------+------------------------------------- in an effort to simulate the TypeError close type family in userland, I was doing a bit of experimentation with type families in ghc 7.10 and 8.0 RC2, and i was surprised to find that i can't get fully applied closed type families to reduce "strictly" when they are fully applied to concrete arguments within a Constraint Tuple. Roughly, I want to be able to write "Assert x" style predicates in a type signature, and have those be checked/ reduced at the definition site rather than the use site. It seems like what I would have to do is do a slight indirection the form {{{ publicFunName :: SimpleType c1 c2 --- c1 c2 are two concrete types publicFunName ... = guardedFun where guardedFun :: (MyClosedTypeFamAssert c1 c2)=> SimpleType c1 c2 guardedFun ... = ... -- myClosedTypeFamAssert (x :: *) (y :: *) :: Constraint }}} I guess this SORTOF makes sense that it doesn't get reduced strictly at the definition site (though its a sort of normalization i feel like). I think the sibling computation where i have `myClosedTypeFamAssert (x :: *) (y :: *) :: Bool` and have the guard be ('True ~ myClosedTypeFamAssert c1 c2 ), but I was hoping i could have things look a teeny bit more "Assertion" style for aesthetical reasons enclosed below is a self contained module that exhibits a more worked out example {{{ {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeFamilies, TypeOperators #-} {-# LANGUAGE DataKinds, GADTs #-} {-# LANGUAGE TypeInType, ConstraintKinds #-} module Main where import GHC.Types (Constraint,TYPE,Levity(..)) main = print (7 :: Int)-- this works -- main = print (sevenBad :: Int ) -- this does error, but its at the use site rather than definition site! -- using this one ""works"", but results in a VERY confusing type error involving -- type family WorstClosedStuckError (x :: a) :: Constraint where WorstClosedStuckError a = (False ~ True) --- empty closed type families are ONLY allowed as of ghc 8.0 type family ClosedStuckSilly (x :: a) :: b where type family ClosedStuckSillyConstr (x :: a) :: Constraint where --- this is analogous to a version of the TypeError family in GHC.TypeLits in 8.0 onwards --- but kind polymorphic closed empty type families dont seem to trigger a type error in the definition site --- but rather in the USE site type family ClosedStuckTypeConstr (x :: TYPE Lifted) :: Constraint where type family ClosedStuckType (x :: TYPE Lifted) :: b where --- these two seem to work OK -- these two only only report an error once I resolve the constraint on a to something like Int etc sevenBad :: (ClosedStuckSilly 'True , Num a) => a sevenBad = 7 sevenOtherBad :: (ClosedStuckSillyConstr 'False, Num a) => a sevenOtherBad = 7 -- this one fails to type check at the definition site, but has a SUPER confusing -- error about allow ambiguous types sevenBadWorst :: (WorstClosedStuckError 'False, Num a) => a sevenBadWorst = 7 sevenOKButNotUseful :: (ClosedStuckType Bool, Num a) => a sevenOKButNotUseful = 7 -- i have to do an indirection to force an "assertion" / "reduction", the following triggers the error as expected sevenIndirect :: Num a => a sevenIndirect = sevenBad }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 19:47:55 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 19:47:55 -0000 Subject: [GHC] #11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied In-Reply-To: <045.7c07d2218cc40ac347ede40d7f240131@haskell.org> References: <045.7c07d2218cc40ac347ede40d7f240131@haskell.org> Message-ID: <060.353dbf6d8b5a449ced0a3b4f054af1d2@haskell.org> #11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I'm a bit lost here. Can you give a small example that exhibits some behavior you disagree with and say what it is that's disagreeable? The range of examples above is helpful, but I'm not sure what's the signal and what's the noise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 19:51:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 19:51:04 -0000 Subject: [GHC] #11513: Work out when GADT parameters should be specified In-Reply-To: <047.8e435f63c64a501e9ed45a384456290b@haskell.org> References: <047.8e435f63c64a501e9ed45a384456290b@haskell.org> Message-ID: <062.311ca98d7cee66c2c5d6d29ed65edc79@haskell.org> #11513: Work out when GADT parameters should be specified -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Richard Eisenberg ): In [changeset:"90f35612f16ff9cb2466cc936f12e748402abb85/ghc" 90f35612/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="90f35612f16ff9cb2466cc936f12e748402abb85" Existentials should be specified. This addresses point (2) from #11513. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 19:51:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 19:51:04 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2311313=3A_Awkward_error_message_=22E?= =?utf-8?b?eHBlY3Rpbmcgb25lIGZld2VyIGFyZ3VtZW50IHRvIOKAmCrigJki?= In-Reply-To: <047.dc3f19603dc752c518577df5ddd3f1c7@haskell.org> References: <047.dc3f19603dc752c518577df5ddd3f1c7@haskell.org> Message-ID: <062.a6068f109915084264a019470d95b94e@haskell.org> #11313: Awkward error message "Expecting one fewer argument to ?*?" -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.11 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 Richard Eisenberg ): In [changeset:"a6152159c9f14fc9cf0e86caff532906abd49b73/ghc" a6152159/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a6152159c9f14fc9cf0e86caff532906abd49b73" Fix #11313. Previously, we looked through synonyms when counting arguments, but that's a bit silly. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 19:51:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 19:51:04 -0000 Subject: [GHC] #11241: Kind-level PartialTypeSignatures causes internal error In-Reply-To: <049.0ee542afb8efab3eb7c877cf28ed244b@haskell.org> References: <049.0ee542afb8efab3eb7c877cf28ed244b@haskell.org> Message-ID: <064.7069df99e1eda5500140a213b2185517@haskell.org> #11241: Kind-level PartialTypeSignatures causes internal error -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"43468fe386571564a4bdfc35cbaeab4199259318/ghc" 43468fe3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="43468fe386571564a4bdfc35cbaeab4199259318" Fix #11241. When renaming a type, now looks for wildcards in bound variables' kinds. testcase: dependent/should_compile/T11241 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 19:51:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 19:51:04 -0000 Subject: [GHC] #11246: Regression typechecking type synonym which includes `Any`. In-Reply-To: <049.3c8cb14b3612458c05777138a511d1ef@haskell.org> References: <049.3c8cb14b3612458c05777138a511d1ef@haskell.org> Message-ID: <064.5f2e5c98784fb20867fe50d072f31be3@haskell.org> #11246: Regression typechecking type synonym which includes `Any`. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"489e6ab5990f0f37624f14d6bf3f0025476513a1/ghc" 489e6ab5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="489e6ab5990f0f37624f14d6bf3f0025476513a1" Fix #11246. We have to instantiate any invisible arguments to type families right away. This is now done in tcTyCon in TcHsType. testcase: typecheck/should_compile/T11246 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 19:52:56 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 19:52:56 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2311313=3A_Awkward_error_message_=22E?= =?utf-8?b?eHBlY3Rpbmcgb25lIGZld2VyIGFyZ3VtZW50IHRvIOKAmCrigJki?= In-Reply-To: <047.dc3f19603dc752c518577df5ddd3f1c7@haskell.org> References: <047.dc3f19603dc752c518577df5ddd3f1c7@haskell.org> Message-ID: <062.07560a637a52bfef0e43f0f49601537b@haskell.org> #11313: Awkward error message "Expecting one fewer argument to ?*?" -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: merge Priority: low | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T11313 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => typecheck/should_fail/T11313 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 19:53:44 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 19:53:44 -0000 Subject: [GHC] #11246: Regression typechecking type synonym which includes `Any`. In-Reply-To: <049.3c8cb14b3612458c05777138a511d1ef@haskell.org> References: <049.3c8cb14b3612458c05777138a511d1ef@haskell.org> Message-ID: <064.23f69eb85f98f7b725290fcc4ee999e8@haskell.org> #11246: Regression typechecking type synonym which includes `Any`. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 8.0.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 | typecheck/should_compile/T11246 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => typecheck/should_compile/T11246 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 19:59:00 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 19:59:00 -0000 Subject: [GHC] #11241: Kind-level PartialTypeSignatures causes internal error In-Reply-To: <049.0ee542afb8efab3eb7c877cf28ed244b@haskell.org> References: <049.0ee542afb8efab3eb7c877cf28ed244b@haskell.org> Message-ID: <064.6b27bbdb98f73443f7d2f517726c09e2@haskell.org> #11241: Kind-level PartialTypeSignatures causes internal error -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | dependent/should_compile/T11241 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * testcase: => dependent/should_compile/T11241 * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 20:01:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 20:01:07 -0000 Subject: [GHC] #11595: Merge some TypeInType fixes Message-ID: <047.0b5fec0bd3fc52dea06510ee7b852368@haskell.org> #11595: Merge some TypeInType fixes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- There were several commits I just pushed that should be merged, but there is no associated ticket. b962bcc609cf3239d61ba281ca0eccc3cd89d99d 90f35612f16ff9cb2466cc936f12e748402abb85 aff5bb47b70450bb1e3e4ac3c18ea35d13f9ac7c 7d8031ba3d36a9378a40834aa3e3817d8f7f310f 6f952f58bc4d592265134e4e13af46da9c56560f -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 20:01:12 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 20:01:12 -0000 Subject: [GHC] #11595: Merge some TypeInType fixes In-Reply-To: <047.0b5fec0bd3fc52dea06510ee7b852368@haskell.org> References: <047.0b5fec0bd3fc52dea06510ee7b852368@haskell.org> Message-ID: <062.9aefefda55448d3f47665457267e291f@haskell.org> #11595: Merge some TypeInType fixes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: merge Priority: normal | Milestone: 8.0.1 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 20:01:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 20:01:45 -0000 Subject: [GHC] #11174: Traversable can't be derived for datatypes with unboxed arguments In-Reply-To: <050.8afc974fb1620698fac2f086504cf230@haskell.org> References: <050.8afc974fb1620698fac2f086504cf230@haskell.org> Message-ID: <065.e4ff7ebd23511b345bd1a2b35d1cfbd3@haskell.org> #11174: Traversable can't be derived for datatypes with unboxed arguments -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Generics 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:D1908 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Thanks RyanGlScott! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 20:02:15 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 20:02:15 -0000 Subject: [GHC] #11590: Typo in documentation In-Reply-To: <055.6da9e84ca8b8331762d57514e277c626@haskell.org> References: <055.6da9e84ca8b8331762d57514e277c626@haskell.org> Message-ID: <070.08638d2f215700ae8ab962f51bad33aa@haskell.org> #11590: Typo in documentation -------------------------------------+------------------------------------- Reporter: mark_christiaens | Owner: Type: bug | Status: merge Priority: lowest | Milestone: 8.0.1 Component: Documentation | Version: 8.0.1-rc2 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 bgamari): * status: new => merge * milestone: => 8.0.1 Comment: Thanks Mark! I'll merge this to the GHC 8.0 branch as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 20:02:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 20:02:45 -0000 Subject: [GHC] #11174: Traversable can't be derived for datatypes with unboxed arguments In-Reply-To: <050.8afc974fb1620698fac2f086504cf230@haskell.org> References: <050.8afc974fb1620698fac2f086504cf230@haskell.org> Message-ID: <065.63e5786aa06d1e1775a583990d44db5a@haskell.org> #11174: Traversable can't be derived for datatypes with unboxed arguments -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Generics 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:D1908 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"a82956df5b34175410e0feb9e2febe7d39b60b49/ghc" a82956d/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a82956df5b34175410e0feb9e2febe7d39b60b49" Remove superfluous code when deriving Foldable/Traversable Currently, `-XDeriveFoldable` and `-XDeriveTraversable` generate unnecessary `mempty` and `pure` expressions when it traverses of an argument of a constructor whose type does not mention the last type parameter. Not only is this inefficient, but it prevents `Traversable` from being derivable for datatypes with unlifted arguments (see Trac #11174). The solution to this problem is to adopt a slight change to the algorithms for `-XDeriveFoldable` and `-XDeriveTraversable`, which is described in [this wiki page](https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DeriveFu nctor#Proposal:alternativestrategyforderivingFoldableandTraversable). The wiki page also describes why we don't apply the same changes to the algorithm for `-XDeriveFunctor`. This is techincally a breaking change for users of `-XDeriveFoldable` and `-XDeriveTraversable`, since if someone was using a law-breaking `Monoid` instance with a derived `Foldable` instance (i.e., one where `x <> mempty` does not equal `x`) or a law-breaking `Applicative` instance with a derived `Traversable` instance, then the new generated code could result in different behavior. I suspect the number of scenarios like this is very small, and the onus really should be on those users to fix up their `Monoid`/`Applicative` instances. Fixes #11174. Test Plan: ./validate Reviewers: hvr, simonpj, austin, bgamari Reviewed By: simonpj, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1908 GHC Trac Issues: #11174 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 20:02:45 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 20:02:45 -0000 Subject: [GHC] #11590: Typo in documentation In-Reply-To: <055.6da9e84ca8b8331762d57514e277c626@haskell.org> References: <055.6da9e84ca8b8331762d57514e277c626@haskell.org> Message-ID: <070.2412432392c2556d86c85138e4a43a48@haskell.org> #11590: Typo in documentation -------------------------------------+------------------------------------- Reporter: mark_christiaens | Owner: Type: bug | Status: merge Priority: lowest | Milestone: 8.0.1 Component: Documentation | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"525b54c469941c636fd45591e5f382cb3b44756c/ghc" 525b54c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="525b54c469941c636fd45591e5f382cb3b44756c" users-guide: Fix typos Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1927 GHC Trac Issues: #11590 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 20:26:48 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 20:26:48 -0000 Subject: [GHC] #11591: thread blocked indefinitely in an MVar operation In-Reply-To: <048.f80b00024c78ab63fc5ff7af29581599@haskell.org> References: <048.f80b00024c78ab63fc5ff7af29581599@haskell.org> Message-ID: <063.e4390c73885a91fb7bdcbca39fcf59de@haskell.org> #11591: thread blocked indefinitely in an MVar operation -------------------------------+-------------------------------------- Reporter: PaulNibin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+-------------------------------------- Description changed by bgamari: @@ -0,0 +1,1 @@ + {{{ @@ -10,1 +11,1 @@ - *Main> take 10 (cycle "Hel) + *Main> take 10 (cycle "Hel") @@ -16,0 +17,1 @@ + }}} New description: {{{ *Main> take 24 [13,26..] [13,26,39,52,65,78,91,104,117,130,143,156,169,182,195,208,221,234,247,260,273,286,299,312] *Main> cycle [1,2,3] [1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2,3,1,2, *Main> *Main> *Main> *Main> take 10 (cycle [1,2,3]) [1,2,3,1,2,3,1,2,3,1] *Main> take 10 (cycle "Hel") ghc.exe: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-mingw32): thread blocked indefinitely in an MVar operation 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 Feb 17 20:53:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 20:53:36 -0000 Subject: [GHC] #11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied In-Reply-To: <045.7c07d2218cc40ac347ede40d7f240131@haskell.org> References: <045.7c07d2218cc40ac347ede40d7f240131@haskell.org> Message-ID: <060.ac024415149d803940d954434bd48ca1@haskell.org> #11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): the meat of it is i want the folllowing to not type check {{{ {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeFamilies, TypeOperators #-} {-# LANGUAGE DataKinds, GADTs #-} {-# LANGUAGE TypeInType, ConstraintKinds #-} module MyLIbrary(sevenBad) where import GHC.Types (Constraint,TYPE,Levity(..)) -- these two only only report an error once I ---resolve the constraint on a to something like Int etc sevenBad :: (ClosedStuckSilly 'True , Num a) => a sevenBad = 7 type family ClosedStuckSilly (x :: a) :: b where }}} if i instead write something like {{{ {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeFamilies, TypeOperators #-} {-# LANGUAGE DataKinds, GADTs #-} {-# LANGUAGE TypeInType, ConstraintKinds #-} module MyLIbrary(sevenBadWrapped) where import GHC.Types (Constraint,TYPE,Levity(..)) -- these two only only report an error once I resolve ---the constraint on a to something like Int etc sevenBad :: (ClosedStuckSilly 'True , Num a) => a sevenBad = 7 sevenBadWrapped :: Num a => a sevenBadWrapped = sevenBad type family ClosedStuckSilly (x :: a) :: b where }}} i'll get the type error i want, but that, I fear, wont scale very well in terms of usability for more complex codes -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 21:04:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 21:04:38 -0000 Subject: [GHC] #11596: ghci gets confused if a file is deleted Message-ID: <051.d9ce7de3f29efd32f3cc7f9d9dcf6a05@haskell.org> #11596: ghci gets confused if a file is deleted -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- With GHC 8.0 RC2 if a currently loaded .hs file is deleted then {{{:reload}}} works, but actual execution of anything is broken. In previous versions this situation resulted in an error at {{{:reload}}} time. Below is a session that demonstrate the bug: {{{ $ ghci A.hs GHCi, version 8.0.0.20160205: http://www.haskell.org/ghc/ :? for help [1 of 2] Compiling B ( B.hs, interpreted ) [2 of 2] Compiling A ( A.hs, interpreted ) Ok, modules loaded: A, B. *A> :!cat A.hs module A where import B a = b + 1 *A> :!cat B.hs module B where b = 41 *A> :!mv B.hs B.txt *A> :r Ok, modules loaded: A. *A> :show modules A ( A.hs, interpreted ) *A> a : fatal: cannot find object file for module `B' while linking an interpreted expression *A> :r Ok, modules loaded: A. }}} Specifically, I load A.hs, which depends on B.hs. I move B.hs away (or delete it). I reload and it says everything is fine. I try to run and it fails. Putting the B.hs file back solves it. This sequence worked fine in all previous versions of GHC, and is caught by the [https://github.com/ndmitchell/ghcid ghcid] test suite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 21:07:56 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 21:07:56 -0000 Subject: [GHC] #11513: Work out when GADT parameters should be specified In-Reply-To: <047.8e435f63c64a501e9ed45a384456290b@haskell.org> References: <047.8e435f63c64a501e9ed45a384456290b@haskell.org> Message-ID: <062.b4d7f3596bbb00b4149571c2e6e22a56@haskell.org> #11513: Work out when GADT parameters should be specified -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 simonpj): This is a very quiet change {{{ - rep_ty = mkSpecForAllTys univ_tvs $ mkInvForAllTys ex_tvs $ + rep_ty = mkSpecForAllTys univ_tvs $ mkSpecForAllTys ex_tvs $ }}} Is it worth a comment and an example? After all, it can't have been obvious to you the first time. Test case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 21:18:52 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 21:18:52 -0000 Subject: [GHC] #11513: Work out when GADT parameters should be specified In-Reply-To: <047.8e435f63c64a501e9ed45a384456290b@haskell.org> References: <047.8e435f63c64a501e9ed45a384456290b@haskell.org> Message-ID: <062.1c08afc12a370a4d3a0c7e5760b17deb@haskell.org> #11513: Work out when GADT parameters should be specified -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 goldfire): I'll add a comment, but it was just plain wrong the first time around. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 21:21:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 21:21:27 -0000 Subject: [GHC] #11513: Work out when GADT parameters should be specified In-Reply-To: <047.8e435f63c64a501e9ed45a384456290b@haskell.org> References: <047.8e435f63c64a501e9ed45a384456290b@haskell.org> Message-ID: <062.e43f6dc30d6dbd0707ba0429ab77a86a@haskell.org> #11513: Work out when GADT parameters should be specified -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Richard Eisenberg ): In [changeset:"0c420cb6fdf25a6779785e18d88c9ca9d3695af1/ghc" 0c420cb6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0c420cb6fdf25a6779785e18d88c9ca9d3695af1" Comments only (#11513) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 21:29:48 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 21:29:48 -0000 Subject: [GHC] #11596: ghci gets confused if a file is deleted In-Reply-To: <051.d9ce7de3f29efd32f3cc7f9d9dcf6a05@haskell.org> References: <051.d9ce7de3f29efd32f3cc7f9d9dcf6a05@haskell.org> Message-ID: <066.83694f551b12159c702d61f5da8f0951@haskell.org> #11596: ghci gets confused if a file is deleted -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): > Putting the B.hs file back solves it. This seems like an an improvement over #9648, not a regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 21:57:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 21:57:39 -0000 Subject: [GHC] #11596: ghci gets confused if a file is deleted In-Reply-To: <051.d9ce7de3f29efd32f3cc7f9d9dcf6a05@haskell.org> References: <051.d9ce7de3f29efd32f3cc7f9d9dcf6a05@haskell.org> Message-ID: <066.b220b60238c03a094196b9b993c7b63f@haskell.org> #11596: ghci gets confused if a file is deleted -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by NeilMitchell): > I reload and it says everything is fine. I try to run and it fails. Sorry, I should have been clearer - the above bit is the problem. It should complain that the module is missing when you {{{:reload}}}, rather than claiming everything is loaded correctly and failing at runtime. The fact you can recover from that state is indeed desirable, and an improvement over #9648. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 22:03:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 22:03:13 -0000 Subject: [GHC] #9648: ghci fails to reload after deleting/creating an imported module In-Reply-To: <051.6a800ad064a7e9508a8fdca22e1c117b@haskell.org> References: <051.6a800ad064a7e9508a8fdca22e1c117b@haskell.org> Message-ID: <066.661e4c3c45bb5a173325e953793fc42a@haskell.org> #9648: ghci fails to reload after deleting/creating an imported module -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11596 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #11596 Comment: Let's continue this in #11596. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 23:06:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 23:06:39 -0000 Subject: [GHC] #11588: haddock documents misleading type signature for TypeError in GHC.TypeLits In-Reply-To: <045.930ffa474ea9a35c110a1f7afc57c5d3@haskell.org> References: <045.930ffa474ea9a35c110a1f7afc57c5d3@haskell.org> Message-ID: <060.17c0d31df2c6da1f338a9a006a4c92f4@haskell.org> #11588: haddock documents misleading type signature for TypeError in GHC.TypeLits -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This should be fixed by [[https://github.com/haskell/haddock/pull/483|Haddock #483]]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 23:08:27 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 23:08:27 -0000 Subject: [GHC] #11588: haddock documents misleading type signature for TypeError in GHC.TypeLits In-Reply-To: <045.930ffa474ea9a35c110a1f7afc57c5d3@haskell.org> References: <045.930ffa474ea9a35c110a1f7afc57c5d3@haskell.org> Message-ID: <060.fa1e7b26bb7880a362022e1d73c2cf73@haskell.org> #11588: haddock documents misleading type signature for TypeError in GHC.TypeLits -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 17 23:57:11 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 17 Feb 2016 23:57:11 -0000 Subject: [GHC] #11587: Place shared objects in LIBDIR In-Reply-To: <046.ae680f55d8340157abb914750c3f9267@haskell.org> References: <046.ae680f55d8340157abb914750c3f9267@haskell.org> Message-ID: <061.d569d63a0ce77e66b3e757c885b8c40f@haskell.org> #11587: Place shared objects in LIBDIR -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Package system | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by chak): * cc: trommler (removed) * cc: Trommler, chak (added) Comment: I have wondered about this set up in the past. More precisely, I think having the dynamic libraries for different packages in separate directories with the interface files etc of the package makes a lot of sense. I keeps the `$LIBDIR` tidy. However, the dynamic linking set up does appear to be rather inefficient and, at least on OS X, it makes relocating GHC distributions very hard. In the Haskell for Mac build, I hence, post-process all executables and dynamic libraries to optimise the linking process. As my ELF is a bit rusty let me explain it in MACH-O terms. I am setting the `RPATH` in all executables such that it points to `$LIBDIR` and I set the library name of each dynamic library to include the package directory. For example, for `base`, we might have `base_GDytRqRVSUX7zckgKqJjgw/libHSbase-4.8.1.0 -GDytRqRVSUX7zckgKqJjgw-ghc7.10.2.dylib`. I also set `RPATH` to be relative to `@loader_PATH`, which gives me a relocatable set of dynamic libraries and GHC executables. So, for example, here is what `base` looks like {{{ LC 03: LC_ID_DYLIB @rpath/base_GDytRqRVSUX7zckgKqJjgw/libHSbase-4.8.1.0 -GDytRqRVSUX7zckgKqJjgw-ghc7.10.2.dylib ... LC 12: LC_LOAD_DYLIB @rpath/integ_2aU3IZNMF9a7mQ0OzsZ0dS /libHSinteger-gmp-1.0.0.0-2aU3IZNMF9a7mQ0OzsZ0dS-ghc7.10.2.dylib LC 13: LC_LOAD_DYLIB @rpath/ghcpr_8TmvWUcS1U1IKHT0levwg3 /libHSghc-prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3-ghc7.10.2.dylib ... LC 19: LC_RPATH @loader_path/.. }}} This avoids the quadratic explosion of the search space, but still keeps the dynamic libraries in the package directories (and `$LIBDIR` tidier). This is definitely the better set up on OS X. Can't we do something equivalent on Linux? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 01:35:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 01:35:43 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.be1dd9b8f4051d2de031c0802f6c18f1@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by niteria): I have a version that performs as well as the old code on T5030: {{{ piResultTys :: Type -> [Type] -> Type piResultTys ty args = go_fast ty args where go_fast ty [] = ty go_fast (ForAllTy (Anon _) res) (_:args') = go_fast res args' go_fast ty args = go (mkEmptyTCvSubst $ mkInScopeSet $ tyCoVarsOfTypes (ty:args)) ty args -- The free vars of 'ty' and 'args' need to be in scope to satisfy the -- invariant in Note [The substitution invariant] in TyCoRep. go subst ty [] = substTy subst ty go subst ty args | Just ty' <- coreView ty = go subst ty' args go subst (ForAllTy bndr res) (arg:args') = case bndr of Anon _ -> go subst res args' Named tv _ -> go (extendTCvSubst subst tv arg) res args' go subst (TyVarTy tv) args -- Deals with piResultTys (forall a. a) [forall b.b, Int] = go subst (substTyVar subst tv) args -- The previous version used empty_subst here, -- I'm not sure if it matters for correctness go _subst _ty _args = panic "piResultTys" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 02:26:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 02:26:00 -0000 Subject: [GHC] #11577: GHCi accepts invalid programs when recompiling In-Reply-To: <047.2a12c44ccefc548e437422f83a607aa3@haskell.org> References: <047.2a12c44ccefc548e437422f83a607aa3@haskell.org> Message-ID: <062.1bbcf4f2284f53628c2b2bb6eb00193f@haskell.org> #11577: GHCi accepts invalid programs when recompiling -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.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 thomie): Probably a long shot, but #11596 might be related. I that ticket, ghci also reports everything is fine after a `:reload`, even though the source code had been modified to a broken state in the meantime. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 03:25:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 03:25:30 -0000 Subject: [GHC] #11579: Bug in parser for named Haddock chunks since GHC 8.0.1-rc1 In-Reply-To: <050.4d0ef6c9d54d8fe326a15d5b3729d82a@haskell.org> References: <050.4d0ef6c9d54d8fe326a15d5b3729d82a@haskell.org> Message-ID: <065.40dc1a4c85fd0673058b75640cdda576@haskell.org> #11579: Bug in parser for named Haddock chunks since GHC 8.0.1-rc1 -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10398 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #10398 Comment: The fix for #10398 (d784bdeb62a6b11831c5235a97449ff2a86dcc52) caused this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 04:09:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 04:09:42 -0000 Subject: [GHC] #11597: Optimize cmpTypeX Message-ID: <047.c45212e57d1b61470e39791921d06b96@haskell.org> #11597: Optimize cmpTypeX -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Simon and I observed that we could skip the kind-check in `cmpTypeX` if the type has no casts, which is the vastly common case. I will collect this information while checking the type and omit the kind check if possible. Putting on "highest" priority basically because this is so easy to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 04:12:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 04:12:31 -0000 Subject: [GHC] #11598: Cache coercion kinds and roles Message-ID: <047.56bbfff0d86db02c37b25ddc698d48a1@haskell.org> #11598: Cache coercion kinds and roles -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Because we never inspect the structure of a coercion, it is easy to cache coercions' kinds and role at the top level, using something like this: {{{ data Coercion = MkCoercion { coercionKind :: Pair Type , coercionRole :: Role , coercionRep :: CoercionRep } data CoercionRep = -- the long, recursive datatype we have now }}} In the process, various role and type information currently stored in the recursive structure could be dropped. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 08:20:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 08:20:23 -0000 Subject: [GHC] #11597: Optimize cmpTypeX In-Reply-To: <047.c45212e57d1b61470e39791921d06b96@haskell.org> References: <047.c45212e57d1b61470e39791921d06b96@haskell.org> Message-ID: <062.8b6629a0700d330b22c9ef42ff0e73f4@haskell.org> #11597: Optimize cmpTypeX -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Also see Bartosz's data in #11371, comment 43. Data here: {{{ 346492 piResultTys Levity -> * 308771 piResultTys * -> * -> * 147177 piResultTys * -> * 18410 piResultTys * -> * -> * -> * 10407 piResultTys * 142 piResultTys * -> # 70 piResultTys Levity 66 piResultTys * -> Constraint 24 piResultTys (* -> *) -> Constraint }}} (Relevance: `piResultTys` is called by `typeKind`, which is called by `cmpTypeX`.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 09:42:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 09:42:26 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.39a3735d596d9af860a37823af5d12dc@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by simonpj): Yes I found that too. I have something similar running now. Your `TyVarTy` case isn't quite right. Meanwhile I'm going to open another ticket about the "exponential behavior" part. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 09:46:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 09:46:30 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.41c1dba4a248820cfcc2af7f10124241@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by niteria): > Your TyVarTy case isn't quite right. Can you elaborate? With a counter example maybe? FWIW it passes ./validate with no perf regressions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 09:56:21 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 09:56:21 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.b90e8a541c69469f74a9d7654767a966@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by simonpj): comment:43 is fantastic. Are you in a position to go one level up and determine which are the hot calls to `piResultTys`? (Maybe the one in `typeKind`?) And then which are the hot calls to `typeKind`? comment:30 suggests that it's mostly from `cmpTypeX`; is that still right? If so it should improve a lot when Richard does #11597. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 10:09:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 10:09:08 -0000 Subject: [GHC] #11599: Why is UndecidableInstances required for an obviously terminating type family? Message-ID: <048.46a585e0a031be7dac9c705cbeea9625@haskell.org> #11599: Why is UndecidableInstances required for an obviously terminating type family? -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 (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: -------------------------------------+------------------------------------- In below (working) snippet {{{#!hs {-# LANGUAGE DataKinds, KindSignatures, TypeFamilies, UndecidableInstances #-} type family Rev (acc :: [*]) (ts :: [*]) :: [*] where Rev acc '[] = acc Rev acc (t ': ts) = Rev (t ': acc) ts type Reverse ts = Rev '[] ts }}} the `Rev` does an exhaustive pattern match on its second argument and recurses on strictly smaller data. {{{#!hs *Main> :kind! Reverse [Char, Bool, Float] Reverse [Char, Bool, Float] :: [*] = '[Float, Bool, Char] }}} So when I remove `UndecidableInstances` it is not clear to me why this would be rejected :-( {{{ error: The type family application Rev (a : acc) as is no smaller than the instance head (Use UndecidableInstances to permit this) In the equations for closed type family Rev In the type family declaration for Rev Failed, modules loaded: none. }}} I tried this on GHC v8.1.today, but older GHCs behave the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 10:38:37 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 10:38:37 -0000 Subject: [GHC] #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 Message-ID: <042.261e60284e26a798be48364a9348d62e@haskell.org> #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This happens when trying to update the `transformers` submodule to 0.5.2.0 (see `wip/transformers-0.5.2`-branch), then during `validate` the following panic occurs: {{{ "inplace/bin/ghc-stage1" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -hide-all-packages -i -ighc/. -ighc/stage2/build -ighc/stage2/build/autogen -Ighc/stage2/build -Ighc/stage2/build/autogen -optP-DGHCI -optP-include -optPghc/stage2/build/autogen/cabal_macros.h -package-id array-0.5.1.0 -package-id base-4.9.0.0 -package-id bytestring-0.10.7.0 -package-id containers-0.5.7.1 -package-id deepseq-1.4.2.0 -package-id directory-1.2.5.1 -package-id filepath-1.4.1.0 -package-id ghc-8.1 -package-id ghc-boot-8.1 -package-id ghci-8.1 -package-id haskeline-0.7.2.2 -package-id process-1.4.2.0 -package-id time-1.6 -package-id transformers-0.5.2.0 -package-id unix-2.7.2.0 -Wall -fno-warn-name-shadowing -XHaskell2010 -O -dcore-lint -no-hs-main -threaded -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir ghc/stage2/build -hidir ghc/stage2/build -stubdir ghc/stage2/build -c ghc/./GHCi/UI.hs -o ghc/stage2/build/GHCi/UI.dyn_o WARNING: file compiler/specialise/Specialise.hs, line 1173 Missed specialisation opportunity for $fMonadIOExceptT_$cliftIO [] 2 [] 1 [ALWAYS] WARNING: file compiler/specialise/Specialise.hs, line 1173 Missed specialisation opportunity for $w$c<*> [] 2 [] 1 [0] ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.1.20160218 for x86_64-unknown-linux): ASSERT failed! file compiler/types/TyCoRep.hs line 1939 in_scope InScope {fromTarget_aiKD pprTT_aj4s pp_resume_aj4J opts_ajdx flagList_ajdy $dMonad_anX0 $dOrd_areH $dEq_as40 $dRead_as5N $dEq_aswW $dMonadIO_at39 $dApplicative_atce $dShow_atnW $dMonad_ats4 $dFunctor_atsk $dNFData_awOZ $dEq_azf8 $dFunctor_azfb $dHasGhciState_azfd $dNFData_aAFw $trModule availableCommands shortHelpText fullHelpText defPrompt defPrompt2 defaultGhciSettings ghciWelcomeMsg ghciCommands word_break_chars specials spaces flagWordBreakChars keepGoing keepGoing' keepGoingPaths defShortHelpText defFullHelpText findEditor default_progname default_prompt default_prompt2 interactiveUI resetLastErrorLocations withGhcAppData runGHCiInput checkFileAndDirPerms checkPerms incrementLineNo fileLoop mkPrompt queryQueue installInteractivePrint runCommands runCommands' runOneCommand checkInputForLayout enqueueCommands runStmt afterRunStmt runSuccess runAllocs printTypeOfNames compareNames printTypeOfName lookupCommand' getCurrentBreakSpan getCurrentBreakModule noArgs withSandboxOnly help info filterOutChildren pprInfo doWithArgs changeDirectory trySuccess chooseEditFile defineMacro getGhciStepIO deferredLoad loadModule loadModule_ reloadModule doLoadAndCollectInfo afterLoad setContextAfterLoad setContextKeepingPackageModules keepPackageImports runExceptGhcMonad exceptT parseSpanArg showSrcSpan showRealSrcSpan kindOfType isSafeModule browseCmd guessCurrentModule browseModule addModulesToContext addModulesToContext_ remModulesFromContext setContext addII restoreContextOnFailure checkAdd setGHCContextFromGHCiState mkIIDecl iiModules iiModuleName preludeModuleName implicitPreludeImport isPreludeImport iiSubsumes showOptions showDynFlags setArgs setProg setEditor setStop setPrompt setPrompt2 setPrompt_ packageFlagsChanged newDynFlags isMinus isPlus setOpt unsetOpt strToGHCiOpt showImports showModules getLoadedModules showBindings showBkptTable showContext pprStopped showPackages showPaths showLanguages showiLanguages showLanguages' ghciCompleteWord completeGhciCommand completeIdentifier completeModule listHomeModules completeSetOptions completeHomeModuleOrFile wrapCompleter wrapIdentCompleter completeExpression pprintCommand stepCmd leftmostLargestRealSrcSpan doContinue bold breakSwitch breakByModuleLine breakSyntax findBreakAndSet findBreakByCoord do_bold start_bold end_bold listModuleLine listAround getTickArray discardTickArrays discardActiveBreakPoints turnOffBreak getModBreak handler showException ghciHandle tryBool lookupModule lookupModuleName expandPath expandPathIO wantInterpretedModule wantInterpretedModuleName wantNameFromInterpretedModule $tc'GhciSettings $tcGhciSettings $tc'GotCommand $tc'BadCommand $tc'NoLastCommand $tcMaybeCommand a_sKa7 a_sKa8 a_sKa9 a_sKaa a_sKag a_sKah a_sKai a_sKaj a_sKdg a_sKrw a_sKvG a_sKvH a_sKvI a_sKwn a_sKwo a_sKws a_sKwt a_sKxU a_sKxV a_sKy8 a_sKy9 a_sKyg a_sKyh a_sKyk a_sKyl a_sKyV a_sKAe a_sKAk a_sKAl a_sKAm a_sKAn a_sKAo a_sKAp a_sKAq a_sKAr a_sKAs a_sKAt a_sKAu a_sKD4 a_sKEx a_sKEy a_sKEz a_sKEA a_sKEB a_sKEC a_sKF1 a_sKF2 a_sKFj a_sKFk a_sKFm a_sKFn a_sKMd a_sKMe a_sKMf a_sKMg a_sKMh a_sKOX a_sKQx a_sKQy a_sKTg a_sKWr a_sKWs a_sKWt a_sLrp a_sLrs a_sLrB a_sLs3 a_sLs5 a_sLsd a_sLsV a_sLtg a_sLtY a_sLv2 a_sLv7 a_sLvB a_sLvF a_sLvP a_sLvT a_sLwI} tenv [alhH :-> InputT GHCi, alhI :-> e_alhI] tenvFVs [alhI :-> e_alhI] cenv [] cenvFVs [] tys [] cos [forall (a17_aDzt :: <*>_N). _R -> Sym (N:ExceptT[0] _N _R _N)] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ghc/ghc.mk:112: recipe for target 'ghc/stage2/build/GHCi/UI.dyn_o' failed }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 10:51:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 10:51:53 -0000 Subject: [GHC] #11519: Inferring non-tau kinds In-Reply-To: <047.4d7c879b01fe33a75f5e9304ccb4f8c9@haskell.org> References: <047.4d7c879b01fe33a75f5e9304ccb4f8c9@haskell.org> Message-ID: <062.abb6b53db5c6310965d14b5ddd1e628d@haskell.org> #11519: Inferring non-tau kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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 bgamari): * status: new => merge * version: 8.1 => 8.0.1-rc1 * milestone: => 8.0.1 Comment: Alright, it can go in, if for no other reason than to keep `ghc-8.0` from diverging from `master` even more than it (already!) has. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 10:58:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 10:58:24 -0000 Subject: [GHC] #11601: Strict Haskell is not as strict as it probably should be Message-ID: <046.29f8763fff117f73c640765f0dcb62b0@haskell.org> #11601: Strict Haskell is not as strict as it probably should be -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this with `-XStrict` {{{ f y = let Just x = blah[y] in body[y,x] }}} Suppose that in a call to `f`, * `blah` returns `Nothing` * but `body` does not use `x` Should `f` succeed? For sure, `blah` will be evaluated to HNF before `body` is started, but is the match against `Just` done strictly too? According to [http://downloads.haskell.org/~ghc/master/users- guide/glasgow_exts.html#recursive-and-polymorphic-let-bindings our current semantics], in the match against `Just` is ''not'' done strictly, so the call should succeed. I think that?s unexpected and probably wrong. The translation goes like this: {{{ !(Just x) = blah ==> (FORCE) v = blah; Just x = v (and add a seq on v) ==> (SPLIT) v = blah; x = case v of Just x -> x }}} So we finish up with {{{ f y = let v = blah[y] in let x = case v of Just x -> x in v `seq` body[y,x] }}} I don?t think that?s what we intended, because there's a thunk for `x`. If the pattern can fail, I think we want the FORCE rule to say this: {{{ Replace any binding !p = e with v = case e of p -> (v1,..,vn); (v1,..,vn) = v and replace e0 with v seq e0, where v is fresh and v1..vn are the variable(s) bound by p }}} (Compare with the text at the above link.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 11:25:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 11:25:52 -0000 Subject: [GHC] #11602: Exponential behaviour in typeKind, unifyTys etc Message-ID: <046.e53628d582e407f397aed54b95187558@haskell.org> #11602: Exponential behaviour in typeKind, unifyTys etc -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- In Trac #11371 Bartosz found some very suspicious performance behaviour. Specifically: * See comment 42 of #11371, which says that `liftCoMatch` and `promoteCoercion` is responsible for a significant fraction of all compiler allocation. Why so expensive? Especially since only used from `OptCoercion`. * There are two comments in `Unify` saying {{{ ty_co_match_app menv subst ty1a ty1b co2a co2b = do { -- TODO (RAE): Remove this exponential behavior. subst1 <- ty_co_match menv subst ki1a ki2a ki_ki_co ki_ki_co }}} and {{{ unify_ty_app ty1a ty1b ty2a ty2b = do { -- TODO (RAE): Remove this exponential behavior. let ki1a = typeKind ty1a ki2a = typeKind ty2a ; unify_ty ki1a ki2a (mkNomReflCo liftedTypeKind) }}} NB: `ty_co_match_app` is also called from `liftCoMatch`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 11:35:34 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 11:35:34 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.d84d7ffd2dfa20b518b491704aeafffa@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by simonpj): Re the tyvar case, what if tv is not in the substitution? `substTyVar` will return the same tyvar and we'll get an infinite loop. I'll push shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 11:37:07 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 11:37:07 -0000 Subject: [GHC] #11599: Why is UndecidableInstances required for an obviously terminating type family? In-Reply-To: <048.46a585e0a031be7dac9c705cbeea9625@haskell.org> References: <048.46a585e0a031be7dac9c705cbeea9625@haskell.org> Message-ID: <063.fbda90fbfb2ddf5be14c6d289a5cc8c7@haskell.org> #11599: Why is UndecidableInstances required for an obviously terminating type family? -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): The test is conservative. It could certainly be improved. The trick is how. A good project for someone. Lots of prior art! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 11:38:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 11:38:05 -0000 Subject: [GHC] #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 In-Reply-To: <042.261e60284e26a798be48364a9348d62e@haskell.org> References: <042.261e60284e26a798be48364a9348d62e@haskell.org> Message-ID: <057.95cd9e6b097026f2c0aaf90ba8ec91d4@haskell.org> #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: niteria (added) Comment: How precisely does one reproduce, starting from HEAD? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:04:19 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:04:19 -0000 Subject: [GHC] #11414: Panic with -XStrict: StgCmmEnv: variable not found In-Reply-To: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> References: <045.a777435cbfef922d7ec8785075e8ada5@haskell.org> Message-ID: <060.10195ac9ca5f0689e0f05dccbf143665@haskell.org> #11414: Panic with -XStrict: StgCmmEnv: variable not found -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Strict Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T11414 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1791 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 9cc99477f2314203ab5abf2dab62c44cb2b0951f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:05:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:05:43 -0000 Subject: [GHC] #11519: Inferring non-tau kinds In-Reply-To: <047.4d7c879b01fe33a75f5e9304ccb4f8c9@haskell.org> References: <047.4d7c879b01fe33a75f5e9304ccb4f8c9@haskell.org> Message-ID: <062.4682fa514955e56b49db18f47a92787e@haskell.org> #11519: Inferring non-tau kinds -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` in 28c26d9da990e4889f77b562fb76fb79e71f9ef2 and c0e380f2a0c5f476d2aabc55a98f237c3b5c3021. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:06:07 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:06:07 -0000 Subject: [GHC] #11541: Type errors sometimes has a lot of irrelevant information In-Reply-To: <047.b489a9355667fda5e49935258d0dd4af@haskell.org> References: <047.b489a9355667fda5e49935258d0dd4af@haskell.org> Message-ID: <062.fd44f32658afb1097c5ce4ca577d06fb@haskell.org> #11541: Type errors sometimes has a lot of irrelevant information -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.8.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | typecheck/should_fail/T11541 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * failure: None/Unknown => Incorrect warning at compile-time * component: Compiler => Compiler (Type checker) * resolution: => fixed * milestone: => 8.0.1 Comment: Merged as 0e2b99affd07d8b46eb2f9f5b130a3a4c450358c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:06:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:06:28 -0000 Subject: [GHC] #11488: -dynamic-too is entirely undocumented In-Reply-To: <046.8614faf1a62ae888f21a12626cf19543@haskell.org> References: <046.8614faf1a62ae888f21a12626cf19543@haskell.org> Message-ID: <061.3595cd2b1817dbada180d16b2b5d2b66@haskell.org> #11488: -dynamic-too is entirely undocumented -------------------------------------+------------------------------------- Reporter: bgamari | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.1 Comment: Merged as acefdeb33d059a0e64e627f5f681e4160e72fb47. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:06:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:06:56 -0000 Subject: [GHC] #11432: Cannot export operator newtype In-Reply-To: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> References: <045.9a7fdda2cb353078e033f239a1207022@haskell.org> Message-ID: <060.7dcca52e67dde11bcf9fbacfa3cccc4b@haskell.org> #11432: Cannot export operator newtype -------------------------------------+------------------------------------- Reporter: phadej | Owner: skvadrik Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1902 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.0.1 Comment: Merged to `ghc-8.0` as d2744a3eb6457aa4043986c20685b9ecf8953612. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:07:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:07:15 -0000 Subject: [GHC] #11148: T9563 doesn't pass with reversed uniques In-Reply-To: <046.b847015ce18a169600f5428c8d6709c6@haskell.org> References: <046.b847015ce18a169600f5428c8d6709c6@haskell.org> Message-ID: <061.d7ffa0e759028ee9aaf88969ae13dccd@haskell.org> #11148: T9563 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T11148 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => merge Comment: Merged tiny, outright bug fix to `ghc-8.0` as a885f485d3a017658a29b7436f875e7d457b0c81. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:07:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:07:44 -0000 Subject: [GHC] #9611: Suggest the cause of "No instance" errors involving multiple versions of a package In-Reply-To: <047.46300571edbd036da850eb10c4f281a5@haskell.org> References: <047.46300571edbd036da850eb10c4f281a5@haskell.org> Message-ID: <062.393d63ffe0334be7e85b22664311a69e@haskell.org> #9611: Suggest the cause of "No instance" errors involving multiple versions of a package -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Yuras Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1919 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` a938c7ad62ccdd6ff4ea15df5ae2ddb8050a04df. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:08:35 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:08:35 -0000 Subject: [GHC] #11413: GHC 8.1.20160111 fails to bootstrap itself. In-Reply-To: <046.15e95fc56f5612748d97a6c11de5e498@haskell.org> References: <046.15e95fc56f5612748d97a6c11de5e498@haskell.org> Message-ID: <061.c42efca0025b840bb48e4a8427739c1c@haskell.org> #11413: GHC 8.1.20160111 fails to bootstrap itself. -------------------------------------+------------------------------------- Reporter: kgardas | Owner: thomie Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Building GHC | Test Case: failed | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1869 Wiki Page: | Phab:D1897 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * version: 8.1 => 8.0.1-rc1 * resolution: => fixed * milestone: => 8.0.1 Comment: Merged to `ghc-8.0` as 287d08343cc757b88f0abf6d42e8cea264dad706. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:09:49 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:09:49 -0000 Subject: [GHC] #8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning In-Reply-To: <042.758ba24a75f02bbb7ec81f3778780b4e@haskell.org> References: <042.758ba24a75f02bbb7ec81f3778780b4e@haskell.org> Message-ID: <057.403e6d39e8de7884e0be62bbd73cb08e@haskell.org> #8022: Outdated documentation for the -fwarn-lazy-unlifted-bindings warning -------------------------------------+------------------------------------- Reporter: asr | Owner: thoughtpolice Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Documentation | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 7.10.1 => 8.0.1 Comment: Merged to `ghc-8.0` as 2a9fce0eba4f0ef06de79a458bffbccc87aacac5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:10:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:10:05 -0000 Subject: [GHC] #11580: panic on incompatible options In-Reply-To: <044.f81a5f3f4d659979b389f8dba4789246@haskell.org> References: <044.f81a5f3f4d659979b389f8dba4789246@haskell.org> Message-ID: <059.932d6c9f98cf3713907e8c46da7b6e93@haskell.org> #11580: panic on incompatible options -------------------------------------+------------------------------------- Reporter: dougm | Owner: Type: bug | Status: new Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1925 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => new Comment: Merged to `ghc-7.10` as ad6a7a3c65e6083417230521e28cb3ed831bf184. Still needs tests as pointed out by rwbarton. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:10:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:10:26 -0000 Subject: [GHC] #11241: Kind-level PartialTypeSignatures causes internal error In-Reply-To: <049.0ee542afb8efab3eb7c877cf28ed244b@haskell.org> References: <049.0ee542afb8efab3eb7c877cf28ed244b@haskell.org> Message-ID: <064.69f79a35273de6561cf1d110b2c6c2e9@haskell.org> #11241: Kind-level PartialTypeSignatures causes internal error -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.11 checker) | Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | dependent/should_compile/T11241 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.1 Comment: Merged to `ghc-8.0` as 314e1489022e3022b4b348c43a8fa6688807c0c7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:10:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:10:40 -0000 Subject: [GHC] #11246: Regression typechecking type synonym which includes `Any`. In-Reply-To: <049.3c8cb14b3612458c05777138a511d1ef@haskell.org> References: <049.3c8cb14b3612458c05777138a511d1ef@haskell.org> Message-ID: <064.ed4b125bb69c6bc2e3946743d861d416@haskell.org> #11246: Regression typechecking type synonym which includes `Any`. -------------------------------------+------------------------------------- Reporter: mpickering | Owner: goldfire Type: bug | Status: closed Priority: highest | Milestone: 8.0.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 | typecheck/should_compile/T11246 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 6133d58121ce80d3b481eaee2a008c6086aa2f0d. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:10:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:10:58 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2311313=3A_Awkward_error_message_=22E?= =?utf-8?b?eHBlY3Rpbmcgb25lIGZld2VyIGFyZ3VtZW50IHRvIOKAmCrigJki?= In-Reply-To: <047.dc3f19603dc752c518577df5ddd3f1c7@haskell.org> References: <047.dc3f19603dc752c518577df5ddd3f1c7@haskell.org> Message-ID: <062.8efe97063e08b308f729207fe4f66dc8@haskell.org> #11313: Awkward error message "Expecting one fewer argument to ?*?" -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.11 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T11313 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.1 Comment: Merged to `ghc-8.0` as b2db13a7e7b693419170216ea6f74dc92723a8a9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:11:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:11:42 -0000 Subject: [GHC] #11148: T9563 doesn't pass with reversed uniques In-Reply-To: <046.b847015ce18a169600f5428c8d6709c6@haskell.org> References: <046.b847015ce18a169600f5428c8d6709c6@haskell.org> Message-ID: <061.e3ffb7001011a8c0f5b5bd9905021de8@haskell.org> #11148: T9563 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deriving/should_compile/T11148 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:12:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:12:13 -0000 Subject: [GHC] #11576: renamer discards name location for HsRecField In-Reply-To: <044.1064c2f83d32fde867ff7dc0ad2e6598@haskell.org> References: <044.1064c2f83d32fde867ff7dc0ad2e6598@haskell.org> Message-ID: <059.50fb9946135320ee982a8c7523ddf0c2@haskell.org> #11576: renamer discards name location for HsRecField -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 62ed15255135b953e93fec0cf793b16ce1722163. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:14:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:14:52 -0000 Subject: [GHC] #11595: Merge some TypeInType fixes In-Reply-To: <047.0b5fec0bd3fc52dea06510ee7b852368@haskell.org> References: <047.0b5fec0bd3fc52dea06510ee7b852368@haskell.org> Message-ID: <062.2c8a8fefdff8db44e539019b31370cb6@haskell.org> #11595: Merge some TypeInType fixes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged. ||= `master` =||= `ghc-8.0` =|| || b962bcc609cf3239d61ba281ca0eccc3cd89d99d || 01d00798aae96af9e58e5f115e9dec93bf0c2baf || || 90f35612f16ff9cb2466cc936f12e748402abb85 || 31ab4b6b40f5f411b2e178df5916ae7e88343079 || || aff5bb47b70450bb1e3e4ac3c18ea35d13f9ac7c || c88cd459c97b0c32221721e75c823c8a7064b0a1 || || 7d8031ba3d36a9378a40834aa3e3817d8f7f310f || e1631b3b58b7440d3d5a8bf72f1490df635792fb || || 6f952f58bc4d592265134e4e13af46da9c56560f || 3b80156c4c921a44f917d0e666e4f74137fbffb4 || -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:15:40 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:15:40 -0000 Subject: [GHC] #11590: Typo in documentation In-Reply-To: <055.6da9e84ca8b8331762d57514e277c626@haskell.org> References: <055.6da9e84ca8b8331762d57514e277c626@haskell.org> Message-ID: <070.737860b49a3b7e9190cf07898dee478c@haskell.org> #11590: Typo in documentation -------------------------------------+------------------------------------- Reporter: mark_christiaens | Owner: Type: bug | Status: closed Priority: lowest | Milestone: 8.0.1 Component: Documentation | Version: 8.0.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 004dc1cb5b1e505ca5f91af3d7b91b70855e3e3c. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:16:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:16:44 -0000 Subject: [GHC] #11362: T6137 doesn't pass with reversed uniques In-Reply-To: <046.176cbdce58fe0c2949bc42c9d1fa1775@haskell.org> References: <046.176cbdce58fe0c2949bc42c9d1fa1775@haskell.org> Message-ID: <061.0a203b4b08506af9976bc3914f7f3531@haskell.org> #11362: T6137 doesn't pass with reversed uniques -------------------------------------+------------------------------------- Reporter: niteria | Owner: niteria Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: 4012 Related Tickets: #11371 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed * milestone: => 8.0.1 Comment: Merged fix. Also merged test as 77de825300a71be0769f23d70015716672e91ca4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:17:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:17:11 -0000 Subject: [GHC] #11563: fvProv falls into a hole (instead of detecting missing type argument) (regression from -rc1 to -rc2) In-Reply-To: <049.16d0cb1a68df6b8b24667b8e4900f6c5@haskell.org> References: <049.16d0cb1a68df6b8b24667b8e4900f6c5@haskell.org> Message-ID: <064.62d30a1c9f808c842c51398676c05f5d@haskell.org> #11563: fvProv falls into a hole (instead of detecting missing type argument) (regression from -rc1 to -rc2) -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | typecheck/should_fail/T11563 Blocked By: | Blocking: Related Tickets: #11520, #11516, | Differential Rev(s): #11399 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as d0010d749f80b405f991e88e0e953a21d54a744d. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:18:51 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:18:51 -0000 Subject: [GHC] #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 In-Reply-To: <042.261e60284e26a798be48364a9348d62e@haskell.org> References: <042.261e60284e26a798be48364a9348d62e@haskell.org> Message-ID: <057.2fd7df115505c1f8eaa19a156775df44@haskell.org> #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:1 simonpj]: > How precisely does one reproduce, starting from HEAD? What should work (on Linux at least): {{{ git checkout wip/transformers-0.5.2 git submodule update ./validate --fast }}} If you look at `git show wip/transformers-0.5.2` you'll notice that the only thing needed is to update the transformers submodule and silence a warning accidentally introduced by `transformers`: {{{#!diff diff --git a/libraries/transformers b/libraries/transformers index a2f7dd0..10348c4 160000 --- a/libraries/transformers +++ b/libraries/transformers @@ -1 +1 @@ -Subproject commit a2f7dd057a0ee0c6cb206609594d7a07d26a1861 +Subproject commit 10348c4bbf60debbfc82463e1035aca1cb7b51bc diff --git a/mk/warnings.mk b/mk/warnings.mk index 10c0935..63388fb 100644 --- a/mk/warnings.mk +++ b/mk/warnings.mk @@ -104,6 +104,7 @@ libraries/dph/dph-lifted-common-install_EXTRA_HC_OPTS += -Wwarn libraries/transformers_dist-boot_EXTRA_HC_OPTS += -fno-warn-unused- matches -fno-warn-unused-imports libraries/transformers_dist-install_EXTRA_HC_OPTS += -Wno-unused-matches -Wno-unused-imports libraries/transformers_dist-install_EXTRA_HC_OPTS += -Wno-redundant- constraints +libraries/transformers_dist-install_EXTRA_HC_OPTS += -Wno-orphans # Turn of trustworthy-safe warning libraries/base_dist-install_EXTRA_HC_OPTS += -Wno-trustworthy-safe }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:21:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:21:11 -0000 Subject: [GHC] #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 In-Reply-To: <042.261e60284e26a798be48364a9348d62e@haskell.org> References: <042.261e60284e26a798be48364a9348d62e@haskell.org> Message-ID: <057.43a96cd22a0935f79b69339c1a837112@haskell.org> #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Alternatively, you can on your existing HEAD, say {{{ $ git submodule update --remote libraries/transformers Submodule path 'libraries/transformers': checked out '10348c4bbf60debbfc82463e1035aca1cb7b51bc' }}} and then adapt mk/warnings.mk accordingly, and end up with a similar situation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:25:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:25:31 -0000 Subject: [GHC] #11589: Reexports of wired-in packages don't work. In-Reply-To: <045.ef6d9437d9e0e94059219935e0ffea8d@haskell.org> References: <045.ef6d9437d9e0e94059219935e0ffea8d@haskell.org> Message-ID: <060.e87e82acc9c8cdde1c510c55c251e398@haskell.org> #11589: Reexports of wired-in packages don't work. -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: cabal/cabal09 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1926 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:29:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:29:26 -0000 Subject: [GHC] #11603: Fix/clarify documentation in GHC.Stats Message-ID: <047.d444ccdc28f8e376bec099daa1b220c9@haskell.org> #11603: Fix/clarify documentation in GHC.Stats -------------------------------------+------------------------------------- Reporter: dcturner | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Core | Version: 8.1 Libraries | 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 following were not clear to me until I read the source: `numByteUsageSamples` is (also) the number of major GCs performed. `currentBytesUsed` is the number of live bytes ''at the end of the last major GC''. Is `currentBytesSlop` also at the end of the last major GC? Can't see that it's actually set to anything nonzero anywhere... The comments for `cumulativeBytesUsed` and `parTotBytesCopied` are in the wrong places. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:43:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:43:30 -0000 Subject: [GHC] #11603: Fix/clarify documentation in GHC.Stats In-Reply-To: <047.d444ccdc28f8e376bec099daa1b220c9@haskell.org> References: <047.d444ccdc28f8e376bec099daa1b220c9@haskell.org> Message-ID: <062.c9d7f583d5c19f7c850dc202f4632864@haskell.org> #11603: Fix/clarify documentation in GHC.Stats -------------------------------------+------------------------------------- Reporter: dcturner | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 8.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:D1929 Wiki Page: | -------------------------------------+------------------------------------- Changes (by dcturner): * differential: => Phab:D1929 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:52:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:52:27 -0000 Subject: [GHC] #11572: BangPatterns-related behavior regressions on GHC 8.0 In-Reply-To: <050.d7de474953179e2bffe8b1b2c4c525d3@haskell.org> References: <050.d7de474953179e2bffe8b1b2c4c525d3@haskell.org> Message-ID: <065.d763263b6be38e5d3577220ba49cbb02@haskell.org> #11572: BangPatterns-related behavior regressions on GHC 8.0 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"01449eb552daa082e46ceaaf8481708ee73dc2ad/ghc" 01449eb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="01449eb552daa082e46ceaaf8481708ee73dc2ad" Fix desugaring of bang-pattern let-bindings When implementing Strict Haskell, the patch 46a03fbe didn't faithfully implement the semantics given in the manual. In particular there was an ad-hoc case in mkSelectorBinds for "strict and no binders" that didn't work. This patch fixes it, curing Trac #11572. Howver it forced me to think about banged let-bindings, and I rather think we do not have quite the right semantics yet, so I've opened Trac #11601. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:52:27 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:52:27 -0000 Subject: [GHC] #11601: Strict Haskell is not as strict as it probably should be In-Reply-To: <046.29f8763fff117f73c640765f0dcb62b0@haskell.org> References: <046.29f8763fff117f73c640765f0dcb62b0@haskell.org> Message-ID: <061.647d0c3a864ea028f3fa1ecc103d5f57@haskell.org> #11601: Strict Haskell is not as strict as it probably should be -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"01449eb552daa082e46ceaaf8481708ee73dc2ad/ghc" 01449eb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="01449eb552daa082e46ceaaf8481708ee73dc2ad" Fix desugaring of bang-pattern let-bindings When implementing Strict Haskell, the patch 46a03fbe didn't faithfully implement the semantics given in the manual. In particular there was an ad-hoc case in mkSelectorBinds for "strict and no binders" that didn't work. This patch fixes it, curing Trac #11572. Howver it forced me to think about banged let-bindings, and I rather think we do not have quite the right semantics yet, so I've opened Trac #11601. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:52:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:52:28 -0000 Subject: [GHC] #11581: TypeError requires UndecidableInstances unnecessarily In-Reply-To: <047.4c36e92acb669f967ff5258393f77106@haskell.org> References: <047.4c36e92acb669f967ff5258393f77106@haskell.org> Message-ID: <062.6e37c767e919441d3646ccf0b5fc7785@haskell.org> #11581: TypeError requires UndecidableInstances unnecessarily -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 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 Simon Peyton Jones ): In [changeset:"a008eadfaa4816be349b4fefde9b9b9edc1ca359/ghc" a008eadf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a008eadfaa4816be349b4fefde9b9b9edc1ca359" Take type-function arity into account ...when computing the size of a call on the RHS of a type instance declaration. This came up in Trac #11581. The change is in TcType.tcTyFamInsts which now trims the type arguments in a call. See the comments with that function definition. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:52:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:52:28 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.b70808a2cb2b86c3ef154ef869479f35@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"4d031cf91c5eed9b162703daee274bbbe94bdc42/ghc" 4d031cf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4d031cf91c5eed9b162703daee274bbbe94bdc42" Improve piResultTys and friends Several things here: * Re-implement piResultTys so that its substitution has the correct in-scope set That means paying close attention to performance, since as we discovered in Trac #11371, it's a heavily used function and is often used on ordinary function types, with no foralls to worry about substituting. * Kill off applyTys, which was just the same as piResultTys. * Re-engineer MkCore.mkCoreApps so that it calls piResultTys, rather than repeatedly calling piResultTy. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:54:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:54:00 -0000 Subject: [GHC] #11581: TypeError requires UndecidableInstances unnecessarily In-Reply-To: <047.4c36e92acb669f967ff5258393f77106@haskell.org> References: <047.4c36e92acb669f967ff5258393f77106@haskell.org> Message-ID: <062.3c4bf55602e93c2d4fd50b63f87678f9@haskell.org> #11581: TypeError requires UndecidableInstances unnecessarily -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T11581 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => indexed-types/should_compile/T11581 Comment: > In short, I think the undecidability checker should only include the indexed arguments to a type family when calculating the size of a type family application, and not any additional parametric arguments. But it doesn't work that way currently. Good point. And easily actioned. Thanks. That still leaves the `TypeError` special case, which I have not done anything about yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 12:54:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 12:54:53 -0000 Subject: [GHC] #11572: BangPatterns-related behavior regressions on GHC 8.0 In-Reply-To: <050.d7de474953179e2bffe8b1b2c4c525d3@haskell.org> References: <050.d7de474953179e2bffe8b1b2c4c525d3@haskell.org> Message-ID: <065.15438790e4876014bd65d2249469ae0a@haskell.org> #11572: BangPatterns-related behavior regressions on GHC 8.0 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deSugar/should_run/T11572 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => deSugar/should_run/T11572 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 13:09:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 13:09:38 -0000 Subject: [GHC] #11603: Fix/clarify documentation in GHC.Stats In-Reply-To: <047.d444ccdc28f8e376bec099daa1b220c9@haskell.org> References: <047.d444ccdc28f8e376bec099daa1b220c9@haskell.org> Message-ID: <062.2cb0a84e657bc60252e9a1bdc9e9d182@haskell.org> #11603: Fix/clarify documentation in GHC.Stats -------------------------------------+------------------------------------- Reporter: dcturner | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 8.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:D1929 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 13:09:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 13:09:47 -0000 Subject: [GHC] #11603: Fix/clarify documentation in GHC.Stats In-Reply-To: <047.d444ccdc28f8e376bec099daa1b220c9@haskell.org> References: <047.d444ccdc28f8e376bec099daa1b220c9@haskell.org> Message-ID: <062.59d0e42501aee6237d3d3216496d60b6@haskell.org> #11603: Fix/clarify documentation in GHC.Stats -------------------------------------+------------------------------------- Reporter: dcturner | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 8.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:D1929 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thanks dcturner! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 13:11:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 13:11:53 -0000 Subject: [GHC] #11601: Strict Haskell is not as strict as it probably should be In-Reply-To: <046.29f8763fff117f73c640765f0dcb62b0@haskell.org> References: <046.29f8763fff117f73c640765f0dcb62b0@haskell.org> Message-ID: <061.b09954ed41e17099fb7b2cafd764bc51@haskell.org> #11601: Strict Haskell is not as strict as it probably should be -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge * milestone: => 8.0.1 Comment: Seems like this is something we should fix for 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 13:40:45 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 13:40:45 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.4cadc4577b2839610e93e88b2edf3e71@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by niteria): Is comment:47 still relevant after your patch? The hottest chain goes like this: `promoteCoercion` -> `eqType` -> `cmpType` -> `cmpTypeX` -> `typeKind` -> `piResultTys`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 14:10:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 14:10:08 -0000 Subject: [GHC] #11371: Bogus in-scope set in substitutions In-Reply-To: <046.772da5831321f90972ab679b44e7eb97@haskell.org> References: <046.772da5831321f90972ab679b44e7eb97@haskell.org> Message-ID: <061.4066eec723eeca667e1d736d56ea7c49@haskell.org> #11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by simonpj): Yes absolutely it is. We've may have avoided `piResultTys` more expensive, but I think we are simply calling it far too often. I started #11602 to track this, and will transfer your comment there. I guess that leaves this ticket for removing all those `unchecked` calls! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 14:10:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 14:10:48 -0000 Subject: [GHC] #11602: Exponential behaviour in typeKind, unifyTys etc In-Reply-To: <046.e53628d582e407f397aed54b95187558@haskell.org> References: <046.e53628d582e407f397aed54b95187558@haskell.org> Message-ID: <061.26334dbe73dd4b0089114e6343e60f3a@haskell.org> #11602: Exponential behaviour in typeKind, unifyTys etc -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Bartosz says: The hottest chain goes like this: `promoteCoercion` -> `eqType` -> `cmpType` -> `cmpTypeX` -> `typeKind` -> `piResultTys`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 14:22:35 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 14:22:35 -0000 Subject: [GHC] #11587: Place shared objects in LIBDIR In-Reply-To: <046.ae680f55d8340157abb914750c3f9267@haskell.org> References: <046.ae680f55d8340157abb914750c3f9267@haskell.org> Message-ID: <061.c6df5d34ad2c2f4f0a16885c99ca335b@haskell.org> #11587: Place shared objects in LIBDIR -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Package system | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by trommler): I think the real issue is that Haskell's libraries are all in different directories and so the dynamic linker must read at least one directory and one file for each Haskell dynamic library. The quadratic time required to find a library seems to be small compared to the disk access to read all directories in the `RPATH` from the hard disk. The second read of a directory would most of the time hit the file system cache. I tried this experiment on my x86_64 Linux machine (still using spinning hard drives) with a dynamically linked GHC: {{{ $ time ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 real 0m4.805s user 0m0.044s sys 0m0.080s $ time ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.3 real 0m0.048s user 0m0.024s sys 0m0.024s }}} Given these numbers I am in favour of @bgamari's original suggestion. If we do not want to clutter GHC's `$LIBDIR` then we could still put all Haskell dynamic libraries into one subdirectory with O(1) time cost. The solution in comment:4 could be implemented in Linux (and ELF in general) too but I think performance would be as bad (at least when disk access is slow). To open `foodir/libbar.so` the runtime linker still needs to read `foodir` and then read `libbar.so`. IIRC, GHC 8.0 does not encode the ABI hash in the dynamic library's file name anymore but has it only in the package's directory name. We will need to revisit that decision. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 14:31:50 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 14:31:50 -0000 Subject: [GHC] #11602: Exponential behaviour in typeKind, unifyTys etc In-Reply-To: <046.e53628d582e407f397aed54b95187558@haskell.org> References: <046.e53628d582e407f397aed54b95187558@haskell.org> Message-ID: <061.abe1d82c5209f8bf9d0626ff8fbf1b83@haskell.org> #11602: Exponential behaviour in typeKind, unifyTys etc -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): This is a profile that I got recently on T5030: [https://phabricator.haskell.org/P101 P101]. `promoteCoercionU1` is the `SCC` I added [https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/types/Unify.hs;4c6e95e4f92516a925fd2a1bce0c0f8b5b9cbd17$1073 here] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 14:45:37 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 14:45:37 -0000 Subject: [GHC] #11604: Build system fails after submodule update Message-ID: <046.4b65c4a78081687136c674e8fcb6f19e@haskell.org> #11604: Build system fails after submodule update -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.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 got [https://phabricator.haskell.org/P100 this] error after updating the transformers submodule with `git submodule update --remote libraries/transformers`. Steps to repro: {{{ git checkout 426a25c719f74054758eaaf15daf5760f8d068fb make clean && make distclean && ./boot && ./configure && make git submodule update --remote libraries/transformers make }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 15:14:30 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 15:14:30 -0000 Subject: [GHC] #11604: Build system fails after submodule update In-Reply-To: <046.4b65c4a78081687136c674e8fcb6f19e@haskell.org> References: <046.4b65c4a78081687136c674e8fcb6f19e@haskell.org> Message-ID: <061.abbe0e59e57c445ebb7c7b272b4e4fda@haskell.org> #11604: Build system fails after submodule update -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): What was the state of the submodules before the first call to `make`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 15:18:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 15:18:43 -0000 Subject: [GHC] #11604: Build system fails after submodule update In-Reply-To: <046.4b65c4a78081687136c674e8fcb6f19e@haskell.org> References: <046.4b65c4a78081687136c674e8fcb6f19e@haskell.org> Message-ID: <061.99429ca1c269a594796d0b8b927c8b16@haskell.org> #11604: Build system fails after submodule update -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- @@ -8,0 +8,1 @@ + git submodule update New description: I got [https://phabricator.haskell.org/P100 this] error after updating the transformers submodule with `git submodule update --remote libraries/transformers`. Steps to repro: {{{ git checkout 426a25c719f74054758eaaf15daf5760f8d068fb git submodule update make clean && make distclean && ./boot && ./configure && make git submodule update --remote libraries/transformers make }}} -- Comment (by niteria): They were in sync with `426a25c719f74054758eaaf15daf5760f8d068fb`, the state you get after {{{ git checkout 426a25c719f74054758eaaf15daf5760f8d068fb git submodule update }}} I'll update the repro to reflect that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 15:28:22 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 15:28:22 -0000 Subject: [GHC] #11604: Build system fails after submodule update In-Reply-To: <046.4b65c4a78081687136c674e8fcb6f19e@haskell.org> References: <046.4b65c4a78081687136c674e8fcb6f19e@haskell.org> Message-ID: <061.680be5fdf17ee23024b288af7477d3d1@haskell.org> #11604: Build system fails after submodule update -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Also: * what is the content of your `mk/build.mk` file? * what is the version of your bootstrap compiler (stage0)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 15:30:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 15:30:42 -0000 Subject: [GHC] #11604: Build system fails after submodule update In-Reply-To: <046.4b65c4a78081687136c674e8fcb6f19e@haskell.org> References: <046.4b65c4a78081687136c674e8fcb6f19e@haskell.org> Message-ID: <061.423292684ba9e7ef038bec089760e30d@haskell.org> #11604: Build system fails after submodule update -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): And the sha1 of transformers that you currently get when you run `git submodule update --remote libraries/transformers`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 15:48:06 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 15:48:06 -0000 Subject: [GHC] #11604: Build system fails after submodule update In-Reply-To: <046.4b65c4a78081687136c674e8fcb6f19e@haskell.org> References: <046.4b65c4a78081687136c674e8fcb6f19e@haskell.org> Message-ID: <061.1a58b59d226f62d7bbc7d53244c708d0@haskell.org> #11604: Build system fails after submodule update -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): I will try to repro in a controlled way from a clean checkout and post the results here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 16:18:57 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 16:18:57 -0000 Subject: [GHC] #11605: GHC accepts overlapping instances without pragma Message-ID: <046.8806d4e6739810ee75f8230002e17fc4@haskell.org> #11605: GHC accepts overlapping instances without pragma -------------------------------------+------------------------------------- Reporter: bennofs | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 (Type checker) | Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: GHC accepts (amd64) | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The following code is accepted by GHC (I've tested versions 7.6.3, 7.8.4, 7.10.2, ghc 8.0.0.20160204 (rc2) and ghc 7.11.2015121 (git commit 28638dfe79e915f33d75a1b22c5adce9e2b62b97)), even though it obviously uses OverlappingInstances (yet the extension is not enabled, nor are any of the new overlappable/ing pragmas used). {{{#!hs {-# LANGUAGE GADTs #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE MultiParamTypeClasses #-} import Data.Type.Equality import Data.Proxy import Debug.Trace class TypeEq a b where eqProofClass :: Maybe (a :~: b) instance TypeEq a b where eqProofClass = Nothing instance TypeEq a a where eqProofClass = Just Refl data Foo a = Foo a instance Eq a => Eq (Foo a) where Foo a1 == Foo a2 = case eqProofClass :: Maybe (a :~: Int) of Just Refl -> traceShow (a1 :: Int,a2) (a1 == a2) Nothing -> a1 == (undefined :: a) main :: IO () main = do print (Foo (1 :: Int) == Foo 2) putStrLn "--" print (Foo 'a' == Foo 'b') {- $output (1,2) False -- False -} }}} The example does no longer compiles if I add `TypeEq a Int` to the instance context, it then rightfully requests `OverlappingInstances` to be enabled. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 16:47:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 16:47:08 -0000 Subject: [GHC] #11604: Build system fails after submodule update In-Reply-To: <046.4b65c4a78081687136c674e8fcb6f19e@haskell.org> References: <046.4b65c4a78081687136c674e8fcb6f19e@haskell.org> Message-ID: <061.7cafe3ccd38cbd02c31ec3fb184d74c5@haskell.org> #11604: Build system fails after submodule update -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): Ok, it didn't repro in the same way when I tried. I suspect that when it happened I first built with `stage=2` and then when it failed I tried `stage=1` and it still failed. I run into a different problem though: {{{ /data/users/bnitka/ghc- clena2-t11604/compiler/stage1/build/libHSghc-8.1.a(BasicTypes.o): In function `ciAI_info': (.text+0x1d01): undefined reference to `ghc_SrcLoc_zdtr1R2_closure' /data/users/bnitka/ghc- clena2-t11604/compiler/stage1/build/libHSghc-8.1.a(BasicTypes.o): In function `ciBO_info': (.text+0x1d61): undefined reference to `ghc_SrcLoc_zdcr1R3_closure' /data/users/bnitka/ghc- clena2-t11604/compiler/stage1/build/libHSghc-8.1.a(BasicTypes.o): In function `ciBO_info': (.text+0x1db9): undefined reference to `ghc_SrcLoc_zdtr1R2_closure' /data/users/bnitka/ghc- clena2-t11604/compiler/stage1/build/libHSghc-8.1.a(BasicTypes.o): In function `ciCv_info': (.text+0x1e19): undefined reference to `ghc_SrcLoc_zdcr1R3_closure' /data/users/bnitka/ghc- clena2-t11604/compiler/stage1/build/libHSghc-8.1.a(BasicTypes.o): In function `SinG_srt': (.data+0x7d30): undefined reference to `ghc_SrcLoc_zdtr1R2_closure' /data/users/bnitka/ghc- clena2-t11604/compiler/stage1/build/libHSghc-8.1.a(BasicTypes.o): In function `SinG_srt': (.data+0x7d38): undefined reference to `ghc_SrcLoc_zdcr1R3_closure' collect2: ld returned 1 exit status }}} I got it from: {{{ git checkout 426a25c719f74054758eaaf15daf5760f8d068fb git submodule update make clean && make distclean && ./boot && ./configure && make git submodule update --remote libraries/transformers make }}} where my `mk/build.mk` is https://phabricator.haskell.org/P102 my stage0 is `The Glorious Glasgow Haskell Compilation System, version 7.10.2` and the sha1 is `10348c4bbf60debbfc82463e1035aca1cb7b51bc` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 17:30:53 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 17:30:53 -0000 Subject: [GHC] #11581: TypeError requires UndecidableInstances unnecessarily In-Reply-To: <047.4c36e92acb669f967ff5258393f77106@haskell.org> References: <047.4c36e92acb669f967ff5258393f77106@haskell.org> Message-ID: <062.fa407cf846abe243f71d00d5dece14c3@haskell.org> #11581: TypeError requires UndecidableInstances unnecessarily -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T11581 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Great. Now instead of special-casing `TypeError`, I was hoping to do the following. Replace {{{ type family TypeError (a :: ErrorMessage) :: b where }}} with {{{ type family TypeError :: ErrorMessage -> b where }}} Unfortunately the kind argument `b` is still considered to be an indexed argument rather than a parametric argument, as shown by `-fprint-explicit- kinds`. {{{ *Pair2> :i GHC.TypeLits.TypeError type family GHC.TypeLits.TypeError b (a :: ErrorMessage) Kind: forall b1. ErrorMessage -> b1 -- Defined in ?GHC.TypeLits? *Pair2> :i TypeError type family TypeError b Kind: forall b1. ErrorMessage -> b1 -- Defined at Pair2.hs:16:1 }}} Can we make `b` a parametric argument, i.e., `TypeError` have arity 0, even counting kind arguments? Then we wouldn't need a special case for `TypeError` at all. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 17:33:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 17:33:38 -0000 Subject: [GHC] #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 In-Reply-To: <042.261e60284e26a798be48364a9348d62e@haskell.org> References: <042.261e60284e26a798be48364a9348d62e@haskell.org> Message-ID: <057.ecab3d6d75934add8586f8a7866ea26e@haskell.org> #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): It reproduces for me, but it's a bit tricky to debug since I don't have `CallStack` in my `stage0` compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 17:38:09 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 17:38:09 -0000 Subject: [GHC] #11581: TypeError requires UndecidableInstances unnecessarily In-Reply-To: <047.4c36e92acb669f967ff5258393f77106@haskell.org> References: <047.4c36e92acb669f967ff5258393f77106@haskell.org> Message-ID: <062.17c852f96ae6612aef9c0f088909391a@haskell.org> #11581: TypeError requires UndecidableInstances unnecessarily -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T11581 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: goldfire (added) Comment: I dunno. Maybe these days you can say {{{ type family TypeError :: forall k (b::k). ErrorMessage b }}} We'll have to ask Richard, our kind-polymorphism king. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 17:39:39 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 17:39:39 -0000 Subject: [GHC] #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 In-Reply-To: <042.261e60284e26a798be48364a9348d62e@haskell.org> References: <042.261e60284e26a798be48364a9348d62e@haskell.org> Message-ID: <057.9aba5e0c021a2f0efb16d1c28eb2c868@haskell.org> #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Indeed. `CallStack` is so useful! Maybe you can build HEAD, then use that built HEAD as you stage0 compiler? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 18:00:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 18:00:38 -0000 Subject: [GHC] #11606: name shadowing warnings don't trigger on standalone declarations in ghci Message-ID: <047.da6e0c4abf31fd9d88f2bdf57a7418b8@haskell.org> #11606: name shadowing warnings don't trigger on standalone declarations in ghci -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The name shadowing warnings in ghci catch shadowing from top-level binds and `let` statements, but not from standalone declarations (new in 8.0). {{{ rwbarton at morphism:/tmp$ ~/ghc-HEAD/bin/ghci -fwarn-name-shadowing GHCi, version 8.1.20160212: http://www.haskell.org/ghc/ :? for help Prelude> a <- return () Prelude> a <- return () :2:1: warning: This binding for ?a? shadows the existing binding defined at :1:1 Prelude> let b = return () Prelude> let b = return () :4:5: warning: This binding for ?b? shadows the existing binding defined at :3:5 Prelude> c = return () Prelude> c = return () Prelude> }}} I'm hoping this can be fixed for 8.0, since I would also very much like to turn on name shadowing warnings in ghci by default (in the interactive flags), to reduce confusion from examples like the below, which is now possible for the first time in 8.0: {{{ Prelude> fact 0 = 1 Prelude> fact n = n * fact (n-1) Prelude> fact 5 ^C^CInterrupted. Prelude> -- why did it run forever? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 20:15:33 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 20:15:33 -0000 Subject: [GHC] #11604: Build system fails after submodule update In-Reply-To: <046.4b65c4a78081687136c674e8fcb6f19e@haskell.org> References: <046.4b65c4a78081687136c674e8fcb6f19e@haskell.org> Message-ID: <061.cfca0fa6238516d9532bd4c5deeabac2@haskell.org> #11604: Build system fails after submodule update -------------------------------------+------------------------------------- Reporter: niteria | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): I did not manage to reproduce this issue, using the steps from comment:6. The only difference is that I'm using 7.10.3 instead of 7.10.2. Could that be it? I did see this, but disabled it by adding `libraries/transformers_dist- install_EXTRA_HC_OPTS += -Wno-orphan` to `mk/warnings.mk`, as suggested in #11600. {{{ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m -Wall -Werror -this-unit-id transformers-0.5.2.0 -hide-all-packages -i -ilibraries/transformers/. -ilibraries/transformers/dist-install/build -ilibraries/transformers/dist-install/build/autogen -Ilibraries/transformers/dist-install/build -Ilibraries/transformers/dist- install/build/autogen -Ilibraries/transformers/. -optP-include -optPlibraries/transformers/dist-install/build/autogen/cabal_macros.h -package-id base-4.9.0.0 -XHaskell98 -O0 -no-user-package-db -rtsopts -Wno-unused-matches -Wno-unused-imports -Wno-redundant-constraints -Wno- deprecated-flags -Wnoncanonical-monad-instances -odir libraries/transformers/dist-install/build -hidir libraries/transformers /dist-install/build -stubdir libraries/transformers/dist-install/build -dynamic-too -c libraries/transformers/./Control/Monad/Trans/Error.hs -o libraries/transformers/dist-install/build/Control/Monad/Trans/Error.o -dyno libraries/transformers/dist- install/build/Control/Monad/Trans/Error.dyn_o libraries/transformers/Control/Monad/Trans/Error.hs:95:1: warning: Orphan instance: instance [safe] Error e => Alternative (Either e) To avoid this move the instance declaration to the module of the class or of the type, or wrap the type with a newtype and declare the instance on the new type. libraries/transformers/Control/Monad/Trans/Error.hs:100:1: warning: Orphan instance: instance [safe] Error e => MonadPlus (Either e) To avoid this move the instance declaration to the module of the class or of the type, or wrap the type with a newtype and declare the instance on the new type. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 20:32:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 20:32:05 -0000 Subject: [GHC] #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 In-Reply-To: <042.261e60284e26a798be48364a9348d62e@haskell.org> References: <042.261e60284e26a798be48364a9348d62e@haskell.org> Message-ID: <057.6b10cba65ffdcad168393b72afcb2544@haskell.org> #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Fyi, here's the same panic with a slightly newer snapshot of GHC HEAD (i.e. a008eadfaa4816be349b4fefde9b9b9edc1ca359), but this time bootstrapped with GHC 8.0 (and thus CallStack support): {{{ "inplace/bin/ghc-stage1" -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -fPIC -dynamic -O0 -H64m -Wall -fllvm-fill-undef-with-garbage -Werror -hide-all-packages -i -ighc/. -ighc/stage2/build -ighc/stage2/build/autogen -Ighc/stage2/build -Ighc/stage2/build/autogen -optP-DGHCI -optP-include -optPghc/stage2/build/autogen/cabal_macros.h -package-id array-0.5.1.0 -package-id base-4.9.0.0 -package-id bytestring-0.10.7.0 -package-id containers-0.5.7.1 -package-id deepseq-1.4.2.0 -package-id directory-1.2.5.1 -package-id filepath-1.4.1.0 -package-id ghc-8.1 -package-id ghc-boot-8.1 -package-id ghci-8.1 -package-id haskeline-0.7.2.2 -package-id process-1.4.2.0 -package-id time-1.6 -package-id transformers-0.5.2.0 -package-id unix-2.7.2.0 -Wall -fno-warn-name-shadowing -XHaskell2010 -O -dcore-lint -no-hs-main -threaded -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir ghc/stage2/build -hidir ghc/stage2/build -stubdir ghc/stage2/build -c ghc/./GHCi/UI.hs -o ghc/stage2/build/GHCi/UI.dyn_o WARNING: file compiler/specialise/Specialise.hs, line 1173 Missed specialisation opportunity for $fMonadIOExceptT_$cliftIO [] 2 [] 1 [ALWAYS] WARNING: file compiler/specialise/Specialise.hs, line 1173 Missed specialisation opportunity for $w$c<*> [] 2 [] 1 [0] ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.1.20160218 for x86_64-unknown-linux): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/types/TyCoRep.hs:1932:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2076:17 in ghc:TyCoRep substCo, called at compiler/coreSyn/CoreSubst.hs:605:20 in ghc:CoreSubst in_scope InScope {fromTarget_aiKD pprTT_aj4s pp_resume_aj4J ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 20:48:25 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 20:48:25 -0000 Subject: [GHC] #11589: Reexports of wired-in packages don't work. In-Reply-To: <045.ef6d9437d9e0e94059219935e0ffea8d@haskell.org> References: <045.ef6d9437d9e0e94059219935e0ffea8d@haskell.org> Message-ID: <060.c6d10fed5da35e10f1930ba67058cb98@haskell.org> #11589: Reexports of wired-in packages don't work. -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: cabal/cabal09 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1926 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This has been merged to `ghc-8.0` but not yet `master` (which will require a different patch, it seems). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 21:18:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 21:18:55 -0000 Subject: [GHC] #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 In-Reply-To: <042.261e60284e26a798be48364a9348d62e@haskell.org> References: <042.261e60284e26a798be48364a9348d62e@haskell.org> Message-ID: <057.57dbf1175441a4e94a7730a2ebb84141@haskell.org> #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): Unfortunately that trace is one stack frame too short to be helpful. I've tried bootstrapping with GHC HEAD, but first `./configure` complained and then after I used the flag it suggested it failed with: {{{ libraries/binary/src/Data/Binary/Put.hs:38:0: error: error: missing binary operator before token "(" libraries/binary/src/Data/Binary/Put.hs:78:0: error: error: missing binary operator before token "(" libraries/binary/src/Data/Binary/Put.hs:186:0: error: error: missing binary operator before token "(" `gcc' failed in phase `C pre-processor'. (Exit code: 1) gmake[1]: *** [utils/ghc-cabal/dist/build/tmp/ghc-cabal] Error 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 21:40:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 21:40:44 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.1a12b8d3e00fdb464f42e2375838384a@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1774 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"206a8bf4665af216784357f6741ccf5e68dd2495/ghc" 206a8bf/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="206a8bf4665af216784357f6741ccf5e68dd2495" Unwire Typeable representation types In order to make this work I needed to shuffle around typechecking a bit such that `TyCon` and friends are available during compilation of GHC.Types. I also did a bit of refactoring of `TcTypeable`. Test Plan: Validate Reviewers: simonpj, austin Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1906 GHC Trac Issues: #11120 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 21:41:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 21:41:41 -0000 Subject: [GHC] #11601: Strict Haskell is not as strict as it probably should be In-Reply-To: <046.29f8763fff117f73c640765f0dcb62b0@haskell.org> References: <046.29f8763fff117f73c640765f0dcb62b0@haskell.org> Message-ID: <061.d9100f8cdf91f449e07a8a8785222a9d@haskell.org> #11601: Strict Haskell is not as strict as it probably should be -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged in d6ea90a213fb32ea0af666dec25697228cc09a26. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 21:41:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 21:41:46 -0000 Subject: [GHC] #11572: BangPatterns-related behavior regressions on GHC 8.0 In-Reply-To: <050.d7de474953179e2bffe8b1b2c4c525d3@haskell.org> References: <050.d7de474953179e2bffe8b1b2c4c525d3@haskell.org> Message-ID: <065.8c4821ebc56385c4ca4cfbb60c6a9e42@haskell.org> #11572: BangPatterns-related behavior regressions on GHC 8.0 -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deSugar/should_run/T11572 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged in d6ea90a213fb32ea0af666dec25697228cc09a26. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 21:41:51 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 21:41:51 -0000 Subject: [GHC] #11601: Strict Haskell is not as strict as it probably should be In-Reply-To: <046.29f8763fff117f73c640765f0dcb62b0@haskell.org> References: <046.29f8763fff117f73c640765f0dcb62b0@haskell.org> Message-ID: <061.8500a16e6d3f4f22a5d2d76cb33fb0cd@haskell.org> #11601: Strict Haskell is not as strict as it probably should be -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 21:45:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 21:45:00 -0000 Subject: [GHC] #11589: Reexports of wired-in packages don't work. In-Reply-To: <045.ef6d9437d9e0e94059219935e0ffea8d@haskell.org> References: <045.ef6d9437d9e0e94059219935e0ffea8d@haskell.org> Message-ID: <060.48bfd8097a86ecd9a84583d0d8d78bb9@haskell.org> #11589: Reexports of wired-in packages don't work. -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: cabal/cabal09 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1926 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => new * owner: ezyang => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 21:53:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 21:53:28 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.4f36380050b8c75fd0f9d46d030fd3ec@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1774 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: closed => merge Comment: luite, the above un-wired the typeable representation types and in so doing removes the ugly word-size dependence. I'll be merging this to `ghc-8.0` shortly. If you have time it would be great to know whether this is all that is necessary to get ghcjs working with the `ghc-8.0` branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 21:59:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 21:59:28 -0000 Subject: [GHC] #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 In-Reply-To: <042.261e60284e26a798be48364a9348d62e@haskell.org> References: <042.261e60284e26a798be48364a9348d62e@haskell.org> Message-ID: <057.3623008ee7f35ea3cd40a50513079eb6@haskell.org> #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks Herbert. Since you have a working setup, Could you add a `HasCallStack` to `Subst.substCo` to extend the trace upwards a bit? (It may take another couple of layers.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 22:01:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 22:01:16 -0000 Subject: [GHC] #11601: Strict Haskell is not as strict as it probably should be In-Reply-To: <046.29f8763fff117f73c640765f0dcb62b0@haskell.org> References: <046.29f8763fff117f73c640765f0dcb62b0@haskell.org> Message-ID: <061.2ad07a020afe3a54bf0a47754cc95d56@haskell.org> #11601: Strict Haskell is not as strict as it probably should be -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 22:02:04 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 22:02:04 -0000 Subject: [GHC] #11601: Strict Haskell is not as strict as it probably should be In-Reply-To: <046.29f8763fff117f73c640765f0dcb62b0@haskell.org> References: <046.29f8763fff117f73c640765f0dcb62b0@haskell.org> Message-ID: <061.f911ed018c56c15c755a3c69913af25d@haskell.org> #11601: Strict Haskell is not as strict as it probably should be -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: tibbe (added) Comment: It's #11572 that is fixed. This ticket is very much open. I need feedback about the desired behaviour. (Johan?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 22:03:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 22:03:11 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.de12d5e0d185cfeba08e6ce2d67d7007@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1774 Wiki Page: | -------------------------------------+------------------------------------- Comment (by luite): Thanks, I've been testing with your earlier `unsafeGlobalDynFlags` patch and I can build `ghc-prim` with that, but I'm still fighting some issues with Cabal and a problem desugaring `foreign import javascript` (looks like it's caused by the new levity arguments, this part of the desugarer is hooked, so it should be fixable on my side), causing the build to fail a little bit later. I'll rebuild using your new patch and report back as soon as I find a solution for the other things, hopefully before the weekend. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 22:06:36 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 22:06:36 -0000 Subject: [GHC] #11606: name shadowing warnings don't trigger on standalone declarations in ghci In-Reply-To: <047.da6e0c4abf31fd9d88f2bdf57a7418b8@haskell.org> References: <047.da6e0c4abf31fd9d88f2bdf57a7418b8@haskell.org> Message-ID: <062.52a16c234fb75ea2266178df0edfd6d4@haskell.org> #11606: name shadowing warnings don't trigger on standalone declarations in ghci -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I didn't even know you could say {{{ Prelude> c = "Hello" }}} It seems entirely un-documented in the user manual. It would be great if someone could document it, when implementing Reid's suggestion. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 22:12:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 22:12:01 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.15bbe04af28c7b17e3507af5857e8fca@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1774 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Merged to `ghc-8.0` as 6013321dd013aeb34f0f1a7f7c1c4cd42683ea6e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 22:12:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 22:12:48 -0000 Subject: [GHC] #11120: Missing type representations In-Reply-To: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> References: <047.ed7038f9e6faf469d425a225b8ecbabe@haskell.org> Message-ID: <062.967791b7649b5befca93d2810ad81ed7@haskell.org> #11120: Missing type representations -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1774 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Thanks for the update, luite. Let me know if I can be of help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 22:22:36 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 22:22:36 -0000 Subject: [GHC] #11607: ApplicativeDo easily foiled with `pure` Message-ID: <046.822f388a9e9f7e6ae598d3989cdd9275@haskell.org> #11607: ApplicativeDo easily foiled with `pure` -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (Type checker) | Keywords: ApplicativeDo | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `ApplicativeDo` fails to desugar `do` blocks ending with `pure`. For instance, {{{#!hs {-# LANGUAGE ApplicativeDo #-} {-# LANGUAGE GeneralizedNewtypeDeriving #-} newtype MaybeA a = MaybeA (Maybe a) deriving (Show, Functor, Applicative) main = print $ do x <- MaybeA $ Just 42 pure x }}} However, if the final `pure` is changed to `return` things work as expected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 22:23:22 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 22:23:22 -0000 Subject: [GHC] #11606: name shadowing warnings don't trigger on standalone declarations in ghci In-Reply-To: <047.da6e0c4abf31fd9d88f2bdf57a7418b8@haskell.org> References: <047.da6e0c4abf31fd9d88f2bdf57a7418b8@haskell.org> Message-ID: <062.79308607f6807d7be2102b714c3d7c96@haskell.org> #11606: name shadowing warnings don't trigger on standalone declarations in ghci -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * cc: roshats (added) Comment: > Prelude> c = "Hello" That feature was implemented by Roman Shatsov in #7253 (b98ff3ccb14e36145404f075349c8689762a2913). The patch includes documentation updates. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 22:24:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 22:24:18 -0000 Subject: [GHC] #11607: ApplicativeDo easily foiled with `pure` In-Reply-To: <046.822f388a9e9f7e6ae598d3989cdd9275@haskell.org> References: <046.822f388a9e9f7e6ae598d3989cdd9275@haskell.org> Message-ID: <061.880d4cf226de6414d189376cb0adf215@haskell.org> #11607: ApplicativeDo easily foiled with `pure` -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ocharles): * cc: ocharles (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 22:32:06 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 22:32:06 -0000 Subject: [GHC] #11607: ApplicativeDo easily foiled with `pure` In-Reply-To: <046.822f388a9e9f7e6ae598d3989cdd9275@haskell.org> References: <046.822f388a9e9f7e6ae598d3989cdd9275@haskell.org> Message-ID: <061.019dceaec978e2870dfdfa6276b3c887@haskell.org> #11607: ApplicativeDo easily foiled with `pure` -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 22:32:24 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 22:32:24 -0000 Subject: [GHC] #11607: ApplicativeDo easily foiled with `pure` In-Reply-To: <046.822f388a9e9f7e6ae598d3989cdd9275@haskell.org> References: <046.822f388a9e9f7e6ae598d3989cdd9275@haskell.org> Message-ID: <061.76d8a5e126a346af48b9188d98256e07@haskell.org> #11607: ApplicativeDo easily foiled with `pure` -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1931 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1931 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 22:32:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 22:32:38 -0000 Subject: [GHC] #11607: ApplicativeDo easily foiled with `pure` In-Reply-To: <046.822f388a9e9f7e6ae598d3989cdd9275@haskell.org> References: <046.822f388a9e9f7e6ae598d3989cdd9275@haskell.org> Message-ID: <061.8bd5eee2021504b3f3757c43d6bb3b18@haskell.org> #11607: ApplicativeDo easily foiled with `pure` -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: ado/T11607 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1931 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * testcase: => ado/T11607 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 22:51:35 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 22:51:35 -0000 Subject: [GHC] #11588: haddock documents misleading type signature for TypeError in GHC.TypeLits In-Reply-To: <045.930ffa474ea9a35c110a1f7afc57c5d3@haskell.org> References: <045.930ffa474ea9a35c110a1f7afc57c5d3@haskell.org> Message-ID: <060.d7474fda04503a1c522d188c360057b4@haskell.org> #11588: haddock documents misleading type signature for TypeError in GHC.TypeLits -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Documentation | Version: 8.0.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: This has been merged `haddock` and both `ghc-8.0` and `master` have been updated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 22:53:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 22:53:08 -0000 Subject: [GHC] #229: Integer overflow in array allocation In-Reply-To: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> References: <045.791e3ea8f042e6c7d57ae4cd25dec693@haskell.org> Message-ID: <060.ed88556847df69db195dd5716bf9ccd9@haskell.org> #229: Integer overflow in array allocation -------------------------------------+------------------------------------- Reporter: josefs | Owner: rwbarton Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Core Libraries | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: This will not happen for GHC 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 23:10:58 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 23:10:58 -0000 Subject: [GHC] #11578: Fix GHC on AArch64/Arm64 In-Reply-To: <044.82eed99cc066ccb994128f1f7245b038@haskell.org> References: <044.82eed99cc066ccb994128f1f7245b038@haskell.org> Message-ID: <059.c6c8da1f50b6679c8998642d05999aad@haskell.org> #11578: Fix GHC on AArch64/Arm64 -------------------------------------+------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------- @@ -4,1 +4,0 @@ - @@ -6,1 +5,0 @@ - New description: Raising this to track discussion about GHC on Arm64. There is already some discussion in ticket #11206 (ARM is generally a disaster), but that ticket is about 32 bit Arm which is vastly different and is now mostly fixed. Information worth saving from #11206: * GHC 7.8.4 from Debian can build the ghc-8.0 branch, but cannot build HEAD because HEAD requires ghc-7.10 to build. * GHC 7.10 from Debian is broken because of an unfixed bug in llvm-3.5.2. * ~~User @mfox reports that ghc-7.10 does build against llvm-3.7 and results in a compiler that can build HEAD.~~ * ~~That GHC 7.10 can be build against llvm-3.7 is a happy accident. Versions of GHC are usually locked to a specific version of LLVM.~~ -- Comment (by erikd): Ah now I understand what is going on. When you built your compiler, you didn't have LLVM-3.5 so the compiler was build as `Unregisterised` (See your `ghc --info` output in ticket:11206#comment:35) which uses the C backend instead of the LLVM backend, bypassing the LLVM-3.5 bug. When I took your bindist and installed it on my machine, the configure script detected the presense of llvm-3.5 and used it resulting in a broken compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 18 23:28:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 18 Feb 2016 23:28:55 -0000 Subject: [GHC] #11578: Fix GHC on AArch64/Arm64 In-Reply-To: <044.82eed99cc066ccb994128f1f7245b038@haskell.org> References: <044.82eed99cc066ccb994128f1f7245b038@haskell.org> Message-ID: <059.b5fa694b42177403809d519a00fdb6ef@haskell.org> #11578: Fix GHC on AArch64/Arm64 -------------------------------------+------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------- Comment (by rwbarton): Why would an unregisterised ''bindist'' use LLVM even if it detects an appropriate version though? That is surely a bug if it happens. The libraries in the bindist are all built with the unregisterised calling convention. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 00:52:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 00:52:00 -0000 Subject: [GHC] #11601: Strict Haskell is not as strict as it probably should be In-Reply-To: <046.29f8763fff117f73c640765f0dcb62b0@haskell.org> References: <046.29f8763fff117f73c640765f0dcb62b0@haskell.org> Message-ID: <061.b4d9f17a21b0bb5feea17c7175fbb96a@haskell.org> #11601: Strict Haskell is not as strict as it probably should be -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tibbe): I think the pattern match should be done strictly as well. I'd expect that's what happens in e.g. Scala or Rust. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 07:42:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 07:42:31 -0000 Subject: [GHC] #11354: Install script installs docs without -version suffix In-Reply-To: <043.018901061c911df7ad296ca4936d7024@haskell.org> References: <043.018901061c911df7ad296ca4936d7024@haskell.org> Message-ID: <058.ea3e3af58fceb84d4755521fc8c6cb4b@haskell.org> #11354: Install script installs docs without -version suffix -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.0.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:D1868 Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): This patch might cause problems for some people, see for example: https://github.com/fpco/ghc-rc- stackage/blob/e96839cdf392a217c7638b249a6e56d205b9e614/Dockerfile#L24-L26 I think you should be able to do the following to put the docs in the old place: `./configure --docdir='${datarootdir}/doc/ghc'`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 08:48:54 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 08:48:54 -0000 Subject: [GHC] #11607: ApplicativeDo easily foiled with `pure` In-Reply-To: <046.822f388a9e9f7e6ae598d3989cdd9275@haskell.org> References: <046.822f388a9e9f7e6ae598d3989cdd9275@haskell.org> Message-ID: <061.fdd942a733c740e1660dc0c97cf0d53d@haskell.org> #11607: ApplicativeDo easily foiled with `pure` -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: ado/T11607 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1931 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yikes! there is no user-manual documentation about the magical behaviour of `return`. Adding more magic (`pure` or `return`) sees uncool. E.g. if I have {{{ }}} then using `blah` will surprisingly fail. Simon M? Regardless whatever the behaviour is ought to be carefully specified in the user manual. So I'm not complaining about Phab:D1931, but rather asking for proper documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 08:50:30 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 08:50:30 -0000 Subject: [GHC] #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 In-Reply-To: <042.261e60284e26a798be48364a9348d62e@haskell.org> References: <042.261e60284e26a798be48364a9348d62e@haskell.org> Message-ID: <057.25e9e7095951e2f4fdee7e237917a4e8@haskell.org> #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:8 simonpj]: > Thanks Herbert. Since you have a working setup, Could you add a `HasCallStack` to `Subst.substCo` to extend the trace upwards a bit? (It may take another couple of layers.) Here's a couple more CallStack context (do you need more)? {{{ ghc-stage1: panic! (the 'impossible' happened) (GHC version 8.1.20160219 for x86_64-unknown-linux): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/types/TyCoRep.hs:1932:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2076:17 in ghc:TyCoRep substCo, called at compiler/coreSyn/CoreSubst.hs:607:20 in ghc:CoreSubst substCo, called at compiler/coreSyn/CoreSubst.hs:382:39 in ghc:CoreSubst go, called at compiler/coreSyn/CoreSubst.hs:374:5 in ghc:CoreSubst subst_expr, called at compiler/coreSyn/CoreSubst.hs:370:33 in ghc:CoreSubst substExpr, called at compiler/coreSyn/CoreUnfold.hs:158:27 in ghc:CoreUnfold specUnfolding, called at compiler/specialise/Specialise.hs:1312:32 in ghc:Specialise }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 10:01:34 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 10:01:34 -0000 Subject: [GHC] #11583: Make warning names more consistent In-Reply-To: <046.2c5f65cdcdffbe526873fdbd4a154741@haskell.org> References: <046.2c5f65cdcdffbe526873fdbd4a154741@haskell.org> Message-ID: <061.997b2d6ac2db28cb892efa5b53d8e739@haskell.org> #11583: Make warning names more consistent -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by svenpanne): Hmmm, can we have a fix for this ''before'' the final 8.0.1 comes out? Otherwise things are a bit chaotic: We introduce the new -W form (and new warnings), only to have some of those -Wfoo renamed immediately afterwards, leading to even more CPP magic in projects. The short form of the changes, just for reference: * Use "sigs" or "signatures" consistently (doesn't really matter which one) * Use "pattern-synonyms", not "pat-syn" Currently e.g. the `half` package doesn't work with the GHC 8 series because of the ad-hoc naming changes of `-fno-warn-missing-pat-syn-sigs` (which is called `-Wno-missing-pat-syn-signatures` currently, but will be `-Wno-missing-pattern-synonym-signatures` or `-Wno-missing-pattern- synonym-sigs`, who knows...?). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 10:21:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 10:21:42 -0000 Subject: [GHC] #11583: Make warning names more consistent In-Reply-To: <046.2c5f65cdcdffbe526873fdbd4a154741@haskell.org> References: <046.2c5f65cdcdffbe526873fdbd4a154741@haskell.org> Message-ID: <061.ee7edff4738b53af456fd281bd30f52f@haskell.org> #11583: Make warning names more consistent -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.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 thomie): * keywords: => newcomer Comment: > can we have a fix for this before the final 8.0.1 comes out Seems like an suitable task for a newcomer. * The code is in `compiler/main/DynFlags.hs`. * Don't forget to update the documentation in the `docs/users_guide` and `utils/mkUserGuidePart` directory. * Submit your patch to [wiki:Phabricator]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 10:46:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 10:46:58 -0000 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> References: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> Message-ID: <062.252e88d601e3d9f02363b82ee671dce8@haskell.org> #393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: Type: feature request | Status: closed Priority: normal | Milestone: ? Component: Compiler (Type | Version: None checker) | Resolution: wontfix | 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 thomie): * status: new => closed * resolution: None => wontfix Comment: As mentioned in comment:24, the preferred way to do define a function without definition is to use `-fdefer-typed-holes`: {{{ f = _ }}} Let's use our spare development cycles somewhere else, and close this ticket wontfix. Don't hesitate to reopen if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 11:09:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 11:09:04 -0000 Subject: [GHC] #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` Message-ID: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: (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: -------------------------------------+------------------------------------- I just updated the GHC 8.0 snapshot I was using from 8.0.0.20160214-g977fb8 to 8.0.0.20160218-g23baff7, and suddenly hackage:microlens-0.4.2.0 fails to build with {{{ ... Preprocessing library microlens-0.4.2.0... [1 of 4] Compiling Lens.Micro.Type ( src/Lens/Micro/Type.hs, dist/build/Lens/Micro/Type.o ) [2 of 4] Compiling Lens.Micro.Internal ( src/Lens/Micro/Internal.hs, dist/build/Lens/Micro/Internal.o ) src/Lens/Micro/Internal.hs:184:3: error: ? Couldn't match type ?s? with ?g0 a? ?s? is untouchable inside the constraints: (Traversable g, s ~ g a, t ~ g b, Applicative f) bound by the type signature for: each :: (Traversable g, s ~ g a, t ~ g b, Applicative f) => (a -> f b) -> s -> f t at src/Lens/Micro/Internal.hs:184:3-27 ? In the ambiguity check for ?each? To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the class method: each :: forall s t a b. Each s t a b => Traversal s t a b In the class declaration for ?Each? }}} ...is this a regression or a feature? :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 11:14:59 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 11:14:59 -0000 Subject: [GHC] #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` In-Reply-To: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> References: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> Message-ID: <057.bbeb26d2a99fa81fed6212d62ec136d3@haskell.org> #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 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 hvr): hackage:free-4.12.4 has a similiar sudden failure: {{{ Preprocessing library free-4.12.4... [ 1 of 16] Compiling Control.Monad.Free.TH ( src/Control/Monad/Free/TH.hs, dist/build/Control/Monad/Free/TH.o ) [ 2 of 16] Compiling Control.Monad.Free.Class ( src/Control/Monad/Free/Class.hs, dist/build/Control/Monad/Free/Class.o ) src/Control/Monad/Free/Class.hs:106:3: error: ? Couldn't match type ?m? with ?t0 n0? ?m? is untouchable inside the constraints: (m ~ t n, MonadTrans t, MonadFree f n, Functor f) bound by the type signature for: wrap :: (m ~ t n, MonadTrans t, MonadFree f n, Functor f) => f (m a) -> m a at src/Control/Monad/Free/Class.hs:106:3-24 ? In the ambiguity check for ?wrap? To defer the ambiguity check to use sites, enable AllowAmbiguousTypes When checking the class method: wrap :: forall (f :: * -> *) (m :: * -> *). MonadFree f m => forall a. f (m a) -> m a In the class declaration for ?MonadFree? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 11:37:19 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 11:37:19 -0000 Subject: [GHC] #8981: ghc-pkg complains about missing haddock interface files In-Reply-To: <052.78ede826fe075a79c59e13141ffaad57@haskell.org> References: <052.78ede826fe075a79c59e13141ffaad57@haskell.org> Message-ID: <067.62059fa812bc39076dd482c5b20779df@haskell.org> #8981: ghc-pkg complains about missing haddock interface files -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => Comment: Not a very fun task, and no takers for 1 year. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 11:38:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 11:38:40 -0000 Subject: [GHC] #1574: Broken link testing In-Reply-To: <056.4175938f47088948409e38405f44cd8f@haskell.org> References: <056.4175938f47088948409e38405f44cd8f@haskell.org> Message-ID: <071.56a42d9e5f5da9fe6aa84bcdfd7b61bf@haskell.org> #1574: Broken link testing -------------------------------------+------------------------------------- Reporter: iampure@? | Owner: Type: task | Status: new Priority: lowest | Milestone: Component: Documentation | Version: 6.6.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 thomie): * keywords: newcomer => * type: feature request => task Comment: Removing newcomers keyword, since it doesn't seem a popular task. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 11:39:40 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 11:39:40 -0000 Subject: [GHC] #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction In-Reply-To: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> References: <047.0bca38b39289a4db2d373be62522bc3d@haskell.org> Message-ID: <062.4b09e149e0f9f41fb93c5d29bf0b6021@haskell.org> #10857: "ghci -XMonomorphismRestriction" doesn't turn on the monomorphism restriction -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | 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: #3202, #3217 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => Comment: This might be tricky, and not much fun. Removing newcomers keyword. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 11:43:50 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 11:43:50 -0000 Subject: [GHC] #9518: Improve error message for unacceptable role annotations In-Reply-To: <047.7d86d581088086ed2263f989759fcf30@haskell.org> References: <047.7d86d581088086ed2263f989759fcf30@haskell.org> Message-ID: <062.2a5cbbe5437279ce5ee7dc8278b3383b@haskell.org> #9518: Improve error message for unacceptable role annotations -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature request | Status: infoneeded Priority: low | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => Comment: goldfire: I'm removing the newcomer keyword from this ticket, as it didn't see any takers in 15 months. It might be too difficult or uninteresting, but please put the keyword back if you disagree. By keeping the newcomers list fresh, I hope we will see newcomer activity pick up a little. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 11:45:21 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 11:45:21 -0000 Subject: [GHC] #2742: The -> in ViewPatterns binds more weakly than infix data constructors. In-Reply-To: <044.60b13b19392ff3d7bf14c8ffe9299245@haskell.org> References: <044.60b13b19392ff3d7bf14c8ffe9299245@haskell.org> Message-ID: <059.f7757ce95802df8f07016cae7a62d5ce@haskell.org> #2742: The -> in ViewPatterns binds more weakly than infix data constructors. -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler | Version: 6.10.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => Comment: nomeata: I'm removing the newcomer keyword from this ticket, as it didn't see any takers in 15 months. It might be too difficult or uninteresting, but please put the keyword back if you disagree. By keeping the newcomers list fresh, I hope we will see newcomer activity pick up a little. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 11:47:08 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 11:47:08 -0000 Subject: [GHC] #9993: PostfixOperators doesn't work for types In-Reply-To: <046.c7aa45b49c7f5a6d1b339ea2f860b5ae@haskell.org> References: <046.c7aa45b49c7f5a6d1b339ea2f860b5ae@haskell.org> Message-ID: <061.5d79ca03eb05c0127ad27dcbae7302a9@haskell.org> #9993: PostfixOperators doesn't work for types -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => Comment: No takers. Removing keyword to keep the newcomers list fresh. Please put it back if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 11:47:32 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 11:47:32 -0000 Subject: [GHC] #1262: RecursiveDo in Template Haskell In-Reply-To: <062.2857e038d8ba06eaa6e83d19ada8ff7e@haskell.org> References: <062.2857e038d8ba06eaa6e83d19ada8ff7e@haskell.org> Message-ID: <077.0057f4f81a3f0488aa2feab3748d1c12@haskell.org> #1262: RecursiveDo in Template Haskell -------------------------------------+------------------------------------- Reporter: philip.weaver@? | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.6 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => Comment: No takers. Removing keyword to keep the newcomers list fresh. Please put it back if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 11:48:09 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 11:48:09 -0000 Subject: [GHC] #10089: feature: warn about unused data definitions (with typeclass instances) In-Reply-To: <045.113d906ba3b76ec22ad2f715d9c6da96@haskell.org> References: <045.113d906ba3b76ec22ad2f715d9c6da96@haskell.org> Message-ID: <060.02ab5de4cfa3e38528f830094303bee5@haskell.org> #10089: feature: warn about unused data definitions (with typeclass instances) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #3221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 11:48:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 11:48:56 -0000 Subject: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections In-Reply-To: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> References: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> Message-ID: <060.d028bdcf4be2c8f9eb235fac83cdbf8a@haskell.org> #7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => Comment: Doesn't seem like a popular task. Removing keyword to keep the newcomers list fresh. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 11:51:02 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 11:51:02 -0000 Subject: [GHC] #1831: reify never provides the declaration of variables In-Reply-To: <044.a26292943bffdeb4bdb3ded03525ce1f@haskell.org> References: <044.a26292943bffdeb4bdb3ded03525ce1f@haskell.org> Message-ID: <059.897e18df845f961ae4d91dadbf3fc7ba@haskell.org> #1831: reify never provides the declaration of variables -------------------------------------+------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 11:56:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 11:56:28 -0000 Subject: [GHC] #11565: Restore code to handle '-fmax-worker-args' flag In-Reply-To: <045.9d241621de87bb494a516e9874327ca7@haskell.org> References: <045.9d241621de87bb494a516e9874327ca7@haskell.org> Message-ID: <060.11ba88f14cd538ded5f6418cccde2a33@haskell.org> #11565: Restore code to handle '-fmax-worker-args' flag -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 14:48:31 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 14:48:31 -0000 Subject: [GHC] #11609: Document unicode report deviations Message-ID: <045.cbd707829d3c6ec2d018040f978ed6b1@haskell.org> #11609: Document unicode report deviations -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 Keywords: unicode, | Operating System: Unknown/Multiple report-impact | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #1103, #4373, | #10196, #11012 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- @nomeata mentions in #10196: The report specifies ?Haskell compilers are expected to make use of new versions of Unicode as they are made available.? So if we deviate from that, we should make sure that * the user?s guide explicitly lists all deviations from the report [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs-and- infelicities.html#infelicities-lexical in this section], and * that the Haskell prime committee is going to be aware of these (sensible) deviations, so that they can become official. Certain deviations are (there might be more): * `OtherLetter` are treated as lowercase (#1103), and thus allowed in identifiers. * `ModifierLetter` (#10196) and `OtherNumber` (#4373) are allowed in identifiers, but only starting from the second character. * `$decdigit = $ascdigit -- for now, should really be $digit (ToDo)` (see compiler/parser/Lexer.x) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 14:49:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 14:49:33 -0000 Subject: [GHC] #10196: Regression regarding Unicode subscript characters in identifiers In-Reply-To: <045.6ee5899f7586f6a7c7c268a3fffc6086@haskell.org> References: <045.6ee5899f7586f6a7c7c268a3fffc6086@haskell.org> Message-ID: <060.a602fe5261e7e4eeb1b167fe24e29cbd@haskell.org> #10196: Regression regarding Unicode subscript characters in identifiers -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: unicode, Resolution: fixed | report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | parser/should_compile/T10196, | parser/should_fail/T10196Fail1, | parser/should_fail/T10196Fail2 Blocked By: | Blocking: Related Tickets: #5108 | Differential Rev(s): Phab:D969 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * testcase: => parser/should_compile/T10196, parser/should_fail/T10196Fail1, parser/should_fail/T10196Fail2 * resolution: => fixed * keywords: => unicode, report-impact Comment: > So if we deviate I've opened #11609 for that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 15:17:14 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 15:17:14 -0000 Subject: [GHC] #11191: provide `make uninstall` In-Reply-To: <042.5746e3abd3ed92aad05386db98c39033@haskell.org> References: <042.5746e3abd3ed92aad05386db98c39033@haskell.org> Message-ID: <057.25c8acaf01e4b74e531347a61013f6d1@haskell.org> #11191: provide `make uninstall` -------------------------------------+------------------------------------- Reporter: f-a | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Build System | Version: Resolution: | Keywords: installation Operating System: 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 Feb 19 15:43:36 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 15:43:36 -0000 Subject: [GHC] #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 In-Reply-To: <042.261e60284e26a798be48364a9348d62e@haskell.org> References: <042.261e60284e26a798be48364a9348d62e@haskell.org> Message-ID: <057.08570b3bf70d97732472a167e2a9ba32@haskell.org> #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): {{{specUnfolding dflags (se_subst env `CoreSubst.extendInScopeList` poly_tyvars)}}}[https://phabricator.haskell.org/diffusion/GHC/browse/master/compiler/specialise/Specialise.hs;2f733b3a4b95a35dfdd43915afec9f0f615edacd$1312 here] fixes the issue at hand. I don't know if free vars of `call_ts` should be already in scope, so this might not be enough. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 15:54:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 15:54:27 -0000 Subject: [GHC] #10196: Regression regarding Unicode subscript characters in identifiers In-Reply-To: <045.6ee5899f7586f6a7c7c268a3fffc6086@haskell.org> References: <045.6ee5899f7586f6a7c7c268a3fffc6086@haskell.org> Message-ID: <060.bf9865dbc0bf0930eaa445cd4dea5cc3@haskell.org> #10196: Regression regarding Unicode subscript characters in identifiers -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: unicode, Resolution: fixed | report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | parser/should_compile/T10196, | parser/should_fail/T10196Fail1, | parser/should_fail/T10196Fail2 Blocked By: | Blocking: Related Tickets: #5108 | Differential Rev(s): Phab:D969 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"d738e66450ec09f69211330df05e381bfe996c13/ghc" d738e66/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d738e66450ec09f69211330df05e381bfe996c13" Modifier letter in middle of identifier is ok Refactoring only. Cleanup some loose ends from #10196. Initially the idea was to only allow modifier letters at the end of identifiers. Since we later decided to allow modifier letters also in the middle of identifiers (because not doing so would not fix the regression completely), the names `suffix` and `okIdSuffixChar` don't seem appropriate anymore. Remove TODO. Move test from should_fail to should_compile. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 17:09:00 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 17:09:00 -0000 Subject: [GHC] #7337: GHC does not generate great code for bit-level rotation In-Reply-To: <042.1bdaae6f89f84d88685747f45c6e6712@haskell.org> References: <042.1bdaae6f89f84d88685747f45c6e6712@haskell.org> Message-ID: <057.ae4ef049c483123bffe8d7c413e00fcd@haskell.org> #7337: GHC does not generate great code for bit-level rotation -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.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 jberryman): For my uses (also hashing) a `uncheckedRotateL# :: Word# -> Int# -> Word#` would be sufficient. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 18:45:11 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 18:45:11 -0000 Subject: [GHC] #11610: Remove IEThingAll constructor from IE datatype Message-ID: <049.74bfb9870839f9195b618b2e2024bba7@haskell.org> #11610: Remove IEThingAll constructor from IE datatype -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It seems that now `IEThingWith` can include a wildcard that the `IEThingAll` constructor is a special case. I'm not sure how involved this would be but it seems worth doing. {{{ | IEThingAll (Located name) -- ^ Class/Type plus all methods/constructors -- -- - 'ApiAnnotation.AnnKeywordId's : 'ApiAnnotation.AnnOpen', -- 'ApiAnnotation.AnnDotdot','ApiAnnotation.AnnClose', -- 'ApiAnnotation.AnnType' -- For details on above see note [Api annotations] in ApiAnnotation -- See Note [Located RdrNames] in HsExpr | IEThingWith (Located name) IEWildcard [Located name] [Located (FieldLbl name)] -- ^ Class/Type plus some methods/constructors -- and record fields; see Note [IEThingWith] -- - 'ApiAnnotation.AnnKeywordId's : 'ApiAnnotation.AnnOpen', -- 'ApiAnnotation.AnnClose', -- 'ApiAnnotation.AnnComma', -- 'ApiAnnotation.AnnType' -- For details on above see note [Api annotations] in ApiAnnotation }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 20:12:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 20:12:58 -0000 Subject: [GHC] #11359: Consider removing RelaxedLayout and friends In-Reply-To: <046.26f295ac88026e78626730eb2098b22e@haskell.org> References: <046.26f295ac88026e78626730eb2098b22e@haskell.org> Message-ID: <061.08734c4f1422ede2736f21ca90febd0d@haskell.org> #11359: Consider removing RelaxedLayout and friends -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): More information about `AlternativeLayoutRule` and `AlternativeLayoutRuleTraditional`: https://prime.haskell.org/wiki/AlternativeLayoutRule. It is used for multiline mode in GHCi (`+m`, #4316). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 20:20:01 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 20:20:01 -0000 Subject: [GHC] #11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment In-Reply-To: <047.9b656b30dd7751cce1c00e17927ecd51@haskell.org> References: <047.9b656b30dd7751cce1c00e17927ecd51@haskell.org> Message-ID: <062.8fb1a3e40826b49c12ddf5b7f5f23465@haskell.org> #11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment -------------------------------------+------------------------------------- Reporter: bollmann | Owner: bollmann Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): That's surprising to me, but not so terribly surprising. That's why I wanted a test before deleting the comment! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 20:27:26 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 20:27:26 -0000 Subject: [GHC] #11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied In-Reply-To: <045.7c07d2218cc40ac347ede40d7f240131@haskell.org> References: <045.7c07d2218cc40ac347ede40d7f240131@haskell.org> Message-ID: <060.16055449c090764b87457d1ac70a99c1@haskell.org> #11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * type: bug => feature request Comment: To paraphrase, you want GHC to recognize that an empty closed type family is insoluble. Although this is a decent suggestion, would a use of `TypeError` work for you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 21:21:01 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 21:21:01 -0000 Subject: [GHC] #11581: TypeError requires UndecidableInstances unnecessarily In-Reply-To: <047.4c36e92acb669f967ff5258393f77106@haskell.org> References: <047.4c36e92acb669f967ff5258393f77106@haskell.org> Message-ID: <062.6a589aa6bf767ce6071b72231e89d66c@haskell.org> #11581: TypeError requires UndecidableInstances unnecessarily -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T11581 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Without looking through the whole ticket: There is no problem having a type family's result kind be polymorphic. It should work as intended. Would you intend `TypeError` to be empty and closed? Or open and magically unable to have instances? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 21:48:21 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 21:48:21 -0000 Subject: [GHC] #11581: TypeError requires UndecidableInstances unnecessarily In-Reply-To: <047.4c36e92acb669f967ff5258393f77106@haskell.org> References: <047.4c36e92acb669f967ff5258393f77106@haskell.org> Message-ID: <062.dc1a8cc1e6511b23df41d170da2dc106@haskell.org> #11581: TypeError requires UndecidableInstances unnecessarily -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T11581 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Empty and closed. Exactly like it is now except having arity 0 rather than 2 (as it does currently) or 1 (best I can seem to do currently). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 22:48:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 22:48:35 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.5710e7c42f45f06c8d37bcc61adb7964@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | 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 rem): * owner: rem => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 22:48:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 22:48:56 -0000 Subject: [GHC] #11501: Building nofib/fibon returns permission denied In-Reply-To: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> References: <042.7732253ef90810c7acc41907aecb19ff@haskell.org> Message-ID: <057.23e44ae8ec55eb3d3d3fe293238e2460@haskell.org> #11501: Building nofib/fibon returns permission denied -------------------------------------+------------------------------------- Reporter: rem | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.10.3 suite | Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rem): Can't work on this anymore, someone take a look? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 19 23:01:08 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 19 Feb 2016 23:01:08 -0000 Subject: [GHC] #10752: Print which warning-flag controls/enabled an emitted warning In-Reply-To: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> References: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> Message-ID: <057.3126dc0d26c4bc740e8cd66a77eeddcd@haskell.org> #10752: Print which warning-flag controls/enabled an emitted warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: barrucadu Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Changes (by barrucadu): * owner: quchen => barrucadu -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 00:03:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 00:03:31 -0000 Subject: [GHC] #11611: ghc panics Message-ID: <051.3fd20af57abcb0290dbd3de8c0429ea4@haskell.org> #11611: ghc panics -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE DataKinds, StandaloneDeriving, TypeOperators, GADTs, FlexibleInstances #-} data A a where A :: A (a:as) -> a -> A as deriving instance Show a => Show (A a) }}} gives {{{#!hs % ghci -ignore-dot-ghci Panic.hs GHCi, version 8.1.20160117: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Panic.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160117 for x86_64-unknown-linux): fvProv falls into a hole {a1aV} 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 Feb 20 01:09:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 01:09:33 -0000 Subject: [GHC] #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` In-Reply-To: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> References: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> Message-ID: <057.300f60031da3094f9c8072e22d68918a@haskell.org> #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Specifically, the issue seems to pertain to type equalities in default signatures in typeclasses. Here is the failing code, reduced to reproducible examples: From [http://hackage.haskell.org/package/microlens-0.4.2.0/docs/src/Lens- Micro-Internal.html#line-184 microlens]: {{{#!hs {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeFamilies #-} type Traversal s t a b = forall f. Applicative f => (a -> f b) -> s -> f t class Each s t a b | s -> a, t -> b, s b -> t, t a -> s where each :: Traversal s t a b default each :: (Traversable g, s ~ g a, t ~ g b) => Traversal s t a b each = traverse }}} From [http://hackage.haskell.org/package/free-4.12.4/docs/src/Control- Monad-Free-Class.html#line-106 free]: {{{#!hs {-# LANGUAGE DefaultSignatures #-} {-# LANGUAGE FunctionalDependencies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE TypeFamilies #-} class MonadTrans t where lift :: Monad m => m a -> t m a class Monad m => MonadFree f m | m -> f where wrap :: f (m a) -> m a default wrap :: (m ~ t n, MonadTrans t, MonadFree f n, Functor f) => f (m a) -> m a wrap = join . lift . wrap . fmap return }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 02:07:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 02:07:05 -0000 Subject: [GHC] #2289: Needless reboxing of values when returning from a tight loop In-Reply-To: <043.32b2235b0e9fe1aba0c28a0cd28686b3@haskell.org> References: <043.32b2235b0e9fe1aba0c28a0cd28686b3@haskell.org> Message-ID: <058.6afb261ea1708f281547ee224a874814@haskell.org> #2289: Needless reboxing of values when returning from a tight loop -------------------------------------+------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: | Keywords: boxing, | loops, performance Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #2387,#1600 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by twhitehead): I was just going to open a ticket to report that I had discovered that the compiler can't unbox multiple return values. That is, anytime you create a non-inlined function (such as a loop) that returns multiple values, you must pay the boxing and unboxing penalty. My reading of these tickets (#1600, #2289, and #2387) though is that this is already known. I'll just add a simple example here {{{ #!haskell main :: IO () main = case loop2 100 (10,10) of (au,ad) -> print (au - ad) loop2 :: Int -> (Int,Int) -> (Int,Int) loop2 n (au,ad) | n > 0 = loop2 (n-1) (au+1,ad-1) | otherwise = (au,ad) }}} yielding (with ''-ddump-simpl -dsuppress-all -dno-suppress-type- signatures'') {{{ #!haskell Rec { main_$s$wloop2 [Occ=LoopBreaker] :: Int# -> Int# -> Int# -> (# Int, Int #) [GblId, Arity=3, Caf=NoCafRefs, Str=DmdType ] main_$s$wloop2 = \ (sc_s3vn :: Int#) (sc1_s3vo :: Int#) (sc2_s3vp :: Int#) -> case tagToEnum# (># sc_s3vn 0) of _ [Occ=Dead] { False -> (# I# sc1_s3vo, I# sc2_s3vp #); True -> main_$s$wloop2 (-# sc_s3vn 1) (+# sc1_s3vo 1) (-# sc2_s3vp 1) } end Rec } main1 :: State# RealWorld -> (# State# RealWorld, () #) [GblId, Arity=1, Str=DmdType , Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 171 0}] main1 = \ (eta_B1 [OS=OneShot] :: State# RealWorld) -> case main_$s$wloop2 100 10 10 of _ [Occ=Dead] { (# ww1_s3uF, ww2_s3uG #) -> hPutStr2 stdout (case ww1_s3uF of _ [Occ=Dead] { I# x_a1d4 -> case ww2_s3uG of _ [Occ=Dead] { I# y_a1d8 -> case $wshowSignedInt 0 (-# x_a1d4 y_a1d8) ([]) of _ [Occ=Dead] { (# ww5_a1xQ, ww6_a1xR #) -> : ww5_a1xQ ww6_a1xR } } }) True eta_B1 } }}} Cheers! -Tyson PS: The perfect performance storm comes when you have a very fast inner loop returning multiple values to an outer loop that evaluates the inner loop many many times. * The inner loop can't be inlined because it is a loop. * The return values from the inner loop must be boxed and unboxed because GHC doesn't seem to be able to do otherwise when there are multiple return values. * The inner loop being very fast means the relative cost of boxing and unboxing is high. * The outer loop repeating the inner loop many many times turns the high relative cost into a high absolute cost. In my specific case I was processing around 10G worth of text records. The inner loop found the next field separator. The outer loop built the data records. It was a nasty hit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 02:52:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 02:52:42 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.f353f97115d5717c96f867970b8acadc@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------- Reporter: ocharles | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9766 | Blocking: Related Tickets: #8778 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by conal): * cc: conal (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 04:29:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 04:29:51 -0000 Subject: [GHC] #11581: TypeError requires UndecidableInstances unnecessarily In-Reply-To: <047.4c36e92acb669f967ff5258393f77106@haskell.org> References: <047.4c36e92acb669f967ff5258393f77106@haskell.org> Message-ID: <062.135b3cbfb6f32c2112cdcfdb00286ffc@haskell.org> #11581: TypeError requires UndecidableInstances unnecessarily -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T11581 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Great -- I think this is a fine plan and should work as one would expect. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 05:20:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 05:20:42 -0000 Subject: [GHC] #10752: Print which warning-flag controls/enabled an emitted warning In-Reply-To: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> References: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> Message-ID: <057.ede0ccdcd95e215a607c5424e41b1dde@haskell.org> #10752: Print which warning-flag controls/enabled an emitted warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: barrucadu Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1934 Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Changes (by barrucadu): * differential: => Phab:D1934 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 06:38:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 06:38:31 -0000 Subject: [GHC] #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.5ec15ad7b56387fadd27ae25b881cdc7@haskell.org> #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 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:D876 Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * priority: normal => high * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 06:52:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 06:52:07 -0000 Subject: [GHC] #11574: schedule: re-entered unsafely on minimal hello world program on arm In-Reply-To: <051.5f65ae7b7de5c2aba500f9eaf01974c1@haskell.org> References: <051.5f65ae7b7de5c2aba500f9eaf01974c1@haskell.org> Message-ID: <066.8a106b7fb4b126499750e082acec1e9f@haskell.org> #11574: schedule: re-entered unsafely on minimal hello world program on arm ----------------------------------+---------------------------------- Reporter: andrewufrank | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------- Comment (by andrewufrank): is it sufficient to copy the bin files to where i currently have a llvm bin folder or should i copy them into /usr/bin (where i have links to files in the current llvm bin? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 07:25:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 07:25:27 -0000 Subject: [GHC] #11612: Bug in ApplicativeDo Message-ID: <047.3e578efe5e273399089fa654398b6d79@haskell.org> #11612: Bug in ApplicativeDo -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 discovered a bug in `ApplicativeDo`. Fix coming shortly. The problem is illustrated by this test case, which I will add to `ado001.hs` in the testsuite: {{{ test11 :: M () test11 = do x1 <- a let x2 = x1 x3 <- b let x4 = c x5 = x4 return (const () (x1,x2,x3,x4)) }}} Which should give `(a | b)`, but gives `(a ; b)` in 8.0.1 RC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 07:32:27 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 07:32:27 -0000 Subject: [GHC] #11612: Bug in ApplicativeDo In-Reply-To: <047.3e578efe5e273399089fa654398b6d79@haskell.org> References: <047.3e578efe5e273399089fa654398b6d79@haskell.org> Message-ID: <062.82e7b3366c91f8342be354b2ba076103@haskell.org> #11612: Bug in ApplicativeDo -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * version: 7.10.3 => 8.0.1-rc2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 08:08:58 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 08:08:58 -0000 Subject: [GHC] #11611: ghc panics In-Reply-To: <051.3fd20af57abcb0290dbd3de8c0429ea4@haskell.org> References: <051.3fd20af57abcb0290dbd3de8c0429ea4@haskell.org> Message-ID: <066.bfb032d63602fb7df43a7fb244870ed8@haskell.org> #11611: ghc panics -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): I notice you're not using a recent GHC HEAD snapshot. I've just tried in recent GHC HEAD & GHC 8.0RC and in both cases GHC does not panic: {{{ $ ghci-8.0.0.20160218 -ignore-dot-ghci Panic.hs GHCi, version 8.0.0.20160218: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Panic.hs, interpreted ) Panic.hs:6:37: error: ? Expected kind ?[*]?, but ?a? has kind ?*? ? In the first argument of ?A?, namely ?a? In the first argument of ?Show?, namely ?A a? In the stand-alone deriving instance for ?Show a => Show (A a)? }}} {{{ $ ghci-8.1.20160218 -ignore-dot-ghci Panic.hs GHCi, version 8.1.20160218: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( Panic.hs, interpreted ) Panic.hs:6:37: error: ? Expected kind ?[*]?, but ?a? has kind ?*? ? In the first argument of ?A?, namely ?a? In the first argument of ?Show?, namely ?A a? In the stand-alone deriving instance for ?Show a => Show (A a)? Failed, modules loaded: none. Prelude> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 08:22:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 08:22:53 -0000 Subject: [GHC] #10752: Print which warning-flag controls/enabled an emitted warning In-Reply-To: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> References: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> Message-ID: <057.34293ad52f909b67aad0e44aba64d4c4@haskell.org> #10752: Print which warning-flag controls/enabled an emitted warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: barrucadu Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1934 Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- @@ -30,0 +30,23 @@ + + ----- + + As an obvious extension, (which maybe should be controlled by some `-f` + flag, e.g. `-f(no-)show-warning-groups`), GHC could then also show by + which warning-group a given warning is implied, e.g. + + + {{{ + WCompatWarningsOn.hs:16:1: warning: [-Wsemigroup (in -Wcompat)] + Local definition of ?<>? clashes with a future Prelude name. + This will become an error in a future release. + + WCompatWarningsOn.hs:22:3: warning: [-Wnoncanonical-monoid-instances (in + -Wcompat)] + Noncanonical ?(<>) = mappend? definition detected + in the instance declaration for ?Semi.Semigroup S?. + Move definition from ?mappend? to ?(<>)? + }}} + + For the warning-sets which form a superset chain (Weverything > Wextra > + Wall > Wdefault) we'd only mention the smallest one (and omit the trivial + `-Weverything` set altogether) to keep the output concise. New description: Both `gcc` and `clang` tell which warning flag a reported warning can be controlled with, e.g. {{{ $ clang-3.5 -Wall -c hello.c hello.c:3:7: warning: unused variable 'x' [-Wunused-variable] int x; ^ 1 warning generated. }}} {{{ $ gcc -Wall -c hello.c hello.c: In function ?main?: hello.c:3:7: warning: unused variable ?x? [-Wunused-variable] int x; ^ hello.c:4:1: warning: control reaches end of non-void function [-Wreturn- type] } ^ }}} With GHC however, we need to lookup the documentation (or memorise all warning flags) to find out which `-fno-warn-*` flag we need to use to silence a specific warning. I propose we augment GHC's warnings in a similar style to how `gcc`/`clang` report flags in compile warnings. ----- As an obvious extension, (which maybe should be controlled by some `-f` flag, e.g. `-f(no-)show-warning-groups`), GHC could then also show by which warning-group a given warning is implied, e.g. {{{ WCompatWarningsOn.hs:16:1: warning: [-Wsemigroup (in -Wcompat)] Local definition of ?<>? clashes with a future Prelude name. This will become an error in a future release. WCompatWarningsOn.hs:22:3: warning: [-Wnoncanonical-monoid-instances (in -Wcompat)] Noncanonical ?(<>) = mappend? definition detected in the instance declaration for ?Semi.Semigroup S?. Move definition from ?mappend? to ?(<>)? }}} For the warning-sets which form a superset chain (Weverything > Wextra > Wall > Wdefault) we'd only mention the smallest one (and omit the trivial `-Weverything` set altogether) to keep the output concise. -- Comment (by hvr): @barrucadu This looks very promising... but have you talked to David (`quchen`) before you took the ticket from him? He had already started working on a warning refactoring in his Github repo afaik (see .e.g. https://github.com/quchen/ghc/commits/warn-refactoring)... PS: I've extended the ticket description with a bonus task -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 09:51:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 09:51:35 -0000 Subject: [GHC] #11612: Bug in ApplicativeDo In-Reply-To: <047.3e578efe5e273399089fa654398b6d79@haskell.org> References: <047.3e578efe5e273399089fa654398b6d79@haskell.org> Message-ID: <062.1d2da7b5c28c9d1e1878247c95c518fd@haskell.org> #11612: Bug in ApplicativeDo -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"3259bf658662e7052ae91de2fa27baae8c84b7fa/ghc" 3259bf6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3259bf658662e7052ae91de2fa27baae8c84b7fa" Fix a bug in ApplicativeDo (#11612) In some cases ApplicativeDo would miss some opportunities, due to a wrong calculation of free variables in RnExpr.segments. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 09:53:37 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 09:53:37 -0000 Subject: [GHC] #11612: Bug in ApplicativeDo In-Reply-To: <047.3e578efe5e273399089fa654398b6d79@haskell.org> References: <047.3e578efe5e273399089fa654398b6d79@haskell.org> Message-ID: <062.62c491413e8a1b713a9a5c6c3855aa0d@haskell.org> #11612: Bug in ApplicativeDo -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 12:42:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 12:42:25 -0000 Subject: [GHC] #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` In-Reply-To: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> References: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> Message-ID: <057.b70d35f2d8104fc132bba54b3c1d00ba@haskell.org> #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 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 bgamari): * failure: None/Unknown => GHC rejects valid program * version: => 8.0.1-rc2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 12:44:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 12:44:11 -0000 Subject: [GHC] #11613: Add microlens to testsuite Message-ID: <046.a73f0305ece6b182d4046b964d4e7b8a@haskell.org> #11613: Add microlens to testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `microlens` package on Hackage seems to be a very good stress test for the typechecker while having few dependencies. We should consider adding it to the testsuite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 12:44:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 12:44:16 -0000 Subject: [GHC] #8176: Language extensions not registered In-Reply-To: <045.79de2871493b7288b102990a0c57a18c@haskell.org> References: <045.79de2871493b7288b102990a0c57a18c@haskell.org> Message-ID: <060.53042003f1cdf28dbcddc2651bb0f7bb@haskell.org> #8176: Language extensions not registered -------------------------------------+------------------------------------- Reporter: duncan | Owner: 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: | tests/driver/T4437.hs Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed Comment: This issue is now tracked in #11359. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 12:44:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 12:44:20 -0000 Subject: [GHC] #11613: Add microlens to testsuite In-Reply-To: <046.a73f0305ece6b182d4046b964d4e7b8a@haskell.org> References: <046.a73f0305ece6b182d4046b964d4e7b8a@haskell.org> Message-ID: <061.53920e911f90a4717e83f2a86f1ff091@haskell.org> #11613: Add microlens to testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | 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): * cc: hvr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 12:54:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 12:54:57 -0000 Subject: [GHC] #11106: Turning on optimizer changes behavior in 7.10.3 In-Reply-To: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> References: <042.faebe957f0d96a5ae5e616602276a1cf@haskell.org> Message-ID: <057.382dbcbc358bd2cd10cc63bcff9f9d06@haskell.org> #11106: Turning on optimizer changes behavior in 7.10.3 -------------------------------------+------------------------------------- Reporter: dsf | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 13:47:25 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 13:47:25 -0000 Subject: [GHC] #10752: Print which warning-flag controls/enabled an emitted warning In-Reply-To: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> References: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> Message-ID: <057.bf7bfb8bfc5c097a171fa2b13d4f1c94@haskell.org> #10752: Print which warning-flag controls/enabled an emitted warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: barrucadu Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1934 Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Comment (by barrucadu): I had not, no. I assumed that since nothing had been updated here in a few months nobody was actively working on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 14:05:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 14:05:12 -0000 Subject: [GHC] #11535: Derived instance of Read/Show causes runtime exception for infix Unicode value constructors In-Reply-To: <045.263be43d8d65688efb1e343588c8d0d5@haskell.org> References: <045.263be43d8d65688efb1e343588c8d0d5@haskell.org> Message-ID: <060.21844649a9e23300224a9778620ed087@haskell.org> #11535: Derived instance of Read/Show causes runtime exception for infix Unicode value constructors -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: unicode Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1544, #11529 | Differential Rev(s): Phab:D1884 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"1ef7add01ead4cbe065297f68306d9bc4b456156/ghc" 1ef7add/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="1ef7add01ead4cbe065297f68306d9bc4b456156" Add test (only) to assure that #11535 is fixed Ticket #11535 dealt with derived Read instances of infix Unicode value constructors. GHC 7.10.3 used to derive (Read/Show) instances so that `read . show` for values of such types had no parse. The issue has been fixed by other compiler update. This patch adds only tests, so that derived instance of Read/Show for infix Unicode value constructors has correct parse, satisfying Haskell 2010 Specification. Resolves: #11535 Test Plan: `make test TEST=T11535` Reviewers: austin, rwbarton, thomie, bgamari Reviewed By: rwbarton, thomie, bgamari Subscribers: rwbarton, thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D1884 GHC Trac Issues: #11535 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 15:31:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 15:31:06 -0000 Subject: [GHC] #11574: schedule: re-entered unsafely on minimal hello world program on arm In-Reply-To: <051.5f65ae7b7de5c2aba500f9eaf01974c1@haskell.org> References: <051.5f65ae7b7de5c2aba500f9eaf01974c1@haskell.org> Message-ID: <066.8694dbca907bc67e2d98aeaf50b5716c@haskell.org> #11574: schedule: re-entered unsafely on minimal hello world program on arm ----------------------------------+---------------------------------- Reporter: andrewufrank | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------- Comment (by bgamari): They merely need to be in your `PATH` (and perhaps any shared objects in `LD_LIBRARY_PATH`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 15:45:01 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 15:45:01 -0000 Subject: [GHC] #11579: Bug in parser for named Haddock chunks since GHC 8.0.1-rc1 In-Reply-To: <050.4d0ef6c9d54d8fe326a15d5b3729d82a@haskell.org> References: <050.4d0ef6c9d54d8fe326a15d5b3729d82a@haskell.org> Message-ID: <065.17640d55917f2c833aa50497903f72fd@haskell.org> #11579: Bug in parser for named Haddock chunks since GHC 8.0.1-rc1 -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: thomie Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10398 | Differential Rev(s): Phab:D1935 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * owner: => thomie * differential: => Phab:D1935 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 16:42:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 16:42:45 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.e7405fb2cee495c2420f64f65052322a@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------- Reporter: ocharles | Owner: dreixel Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9766 | Blocking: Related Tickets: #8778 | Differential Rev(s): Phab:D1937 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1937 * milestone: => 8.0.1 Comment: Here is a patch derived from ocharles' branch. Given that this is only a library change I'd be fine with sneaking this in to 8.0.1 if there's no objection. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 16:52:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 16:52:51 -0000 Subject: [GHC] #11614: document TypeInType Message-ID: <047.1743dce4e41c34187f3120f682a53edd@haskell.org> #11614: document TypeInType -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: goldfire Type: task | Status: new Priority: highest | Milestone: 8.0.1 Component: Documentation | Version: 8.0.1-rc2 Keywords: TypeInType | Operating System: Unknown/Multiple Architecture: | Type of failure: Documentation Unknown/Multiple | bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (Just to keep track of the status for 8.0.1.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 17:17:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 17:17:00 -0000 Subject: [GHC] #2289: Needless reboxing of values when returning from a tight loop In-Reply-To: <043.32b2235b0e9fe1aba0c28a0cd28686b3@haskell.org> References: <043.32b2235b0e9fe1aba0c28a0cd28686b3@haskell.org> Message-ID: <058.5c03a7186c2209162d9ac806149dcd01@haskell.org> #2289: Needless reboxing of values when returning from a tight loop -------------------------------------+------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: | Keywords: boxing, | loops, performance Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #2387,#1600 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Your example combines two issues. The big one is that you can in fact call `loop2` like this: {{{ main = case loop2 100 (undefined,undefined) of (_,_) -> return () }}} and it will terminate without evaluating `undefined`. So GHC can't eagerly evaluate `au+1` and `ad-1`, so there is thunk build-up in the argument pair, that eventually becomes the result pair. To fix this you could either * return a strict pair (`data P = P !Int !Int`, `| otherwise = P au ad`), which might be inconvenient, or * manually make the return tuple strict ({{{| otherwise = au `seq` ad `seq` (au,ad)}}}). Then, the second issue, which is the one I think you are interested in, is whether after one of these changes, the unboxed tuple returned by `loop2` contains boxed `Int`s or unboxed `Int#`s. (It can't very well contain `Int#`s without either change, since `au` and `ad` might be `undefined`! Or GHC would have to generate multiple specializations of `loop2` for different demand patterns, which it doesn't currently do.) Currently, `loop2` produces `Int#`s if its result type is a strict pair and `-funbox- small-strict-fields` is on (which it is by default), otherwise `Int`s. Unboxing the `Int`s inside the unboxed tuple is indeed nested CPR, which is the subject of this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 17:38:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 17:38:26 -0000 Subject: [GHC] #11581: TypeError requires UndecidableInstances unnecessarily In-Reply-To: <047.4c36e92acb669f967ff5258393f77106@haskell.org> References: <047.4c36e92acb669f967ff5258393f77106@haskell.org> Message-ID: <062.131406908ffe95e682001b9922925fa8@haskell.org> #11581: TypeError requires UndecidableInstances unnecessarily -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: indexed- valid program | types/should_compile/T11581 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): What exactly is the plan, though? This doesn't work even after a008eadf: {{{#!hs {-# LANGUAGE TypeFamilies, TypeInType, RankNTypes #-} module Arity where import GHC.Types import GHC.TypeLits hiding (TypeError) type family TypeError :: forall b. ErrorMessage -> b where {} type family T (a :: Type) :: Type where T t = TypeError (ShowType t) }}} {{{ rwbarton at morphism:/tmp$ ~/ghc-newest/inplace/bin/ghc-stage2 -fprint- explicit-kinds Arity.hs [1 of 1] Compiling Arity ( Arity.hs, Arity.o ) Arity.hs:10:3: error: ? The type family application ?TypeError Type? is no smaller than the instance head (Use UndecidableInstances to permit this) ? In the equations for closed type family ?T? In the type family declaration for ?T? }}} So I hope the plan involves changing the calculation of the arity of a type family to not include kind arguments that only appear in the result kind of the type family, or something like that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 18:55:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 18:55:23 -0000 Subject: [GHC] #11615: ghci -threaded Message-ID: <044.8c0dae9d570aeaf52d1cce3cbe676cd5@haskell.org> #11615: ghci -threaded -------------------------------------+------------------------------------- Reporter: franz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- ... gives: Warning: -debug, -threaded and -ticky are ignored by GHCi How can I use -threaded in ghci? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 19:00:14 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 19:00:14 -0000 Subject: [GHC] #11188: Confusing "parse error in pattern" for spurious indentation. In-Reply-To: <051.b8c2bb1173a96cc38d2a08ac891825b7@haskell.org> References: <051.b8c2bb1173a96cc38d2a08ac891825b7@haskell.org> Message-ID: <066.2caae522f1412ec5e24008810daf1b00@haskell.org> #11188: Confusing "parse error in pattern" for spurious indentation. -------------------------------------+------------------------------------- Reporter: andreas.abel | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): The suggestion `Possibly caused by a missing 'do'` was added in #984. [ticket:984#comment:9 comment 9] in that ticket says: "Only time will tell whether this causes more confusion (in cases where the suggestion is wrong) than it resolves." -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 19:28:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 19:28:42 -0000 Subject: [GHC] #11615: ghci -threaded In-Reply-To: <044.8c0dae9d570aeaf52d1cce3cbe676cd5@haskell.org> References: <044.8c0dae9d570aeaf52d1cce3cbe676cd5@haskell.org> Message-ID: <059.8d9c1aacb3bc83ba4bc81a7c4f7a1aac@haskell.org> #11615: ghci -threaded -------------------------------------+------------------------------------- Reporter: franz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): `-threaded` is a link-time option, and ghci is linked with the threaded RTS, so it is always threaded (assuming you don't have an unusual configuration; `ghc +RTS --info | grep 'RTS way'` to check, should contain `_thr`). It is never `-debug` or `-ticky` (again unless you built it that way on purpose). We could make that warning say more clearly that `-threaded` is redundant, and `-debug` and `-ticky` are ignored. But strangely that warning has disappeared in 8.0 and HEAD, even though the code to print it still seems to exist. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 19:45:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 19:45:55 -0000 Subject: [GHC] #11615: ghci -threaded In-Reply-To: <044.8c0dae9d570aeaf52d1cce3cbe676cd5@haskell.org> References: <044.8c0dae9d570aeaf52d1cce3cbe676cd5@haskell.org> Message-ID: <059.466f5a1e083264c4eb3fe627ec657646@haskell.org> #11615: ghci -threaded -------------------------------------+------------------------------------- Reporter: franz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by franz): You are correct, the given command returns a string which contains "hr". I have a function "f" that should run on multiple threads. A compiled program (using "ghc -threaded") containing "main = f" runs multithreaded, like I want to. When I however start "ghci +RTS -N" and than manually run "f", the program runs only on one thread. Mh. Any ideas? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 19:55:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 19:55:21 -0000 Subject: [GHC] #11615: ghci -threaded In-Reply-To: <044.8c0dae9d570aeaf52d1cce3cbe676cd5@haskell.org> References: <044.8c0dae9d570aeaf52d1cce3cbe676cd5@haskell.org> Message-ID: <059.5a64db0e6f72de047aeecc18115079c6@haskell.org> #11615: ghci -threaded -------------------------------------+------------------------------------- Reporter: franz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by franz): I have some more information about the problem: I found out that the problem occurs only when I run "cabal exec ghci +RTS -N". When I run it without "cabal exec", getNumCapabilities returns the correct number of kernels, but within "cabal exec ghci +RTS -N" or "cabal repl +RTS -N", the number of kernels is 1. (Even though also "cabal exec ghci +RTS --info" contains "_thr"! Any ideas? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 20:02:37 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 20:02:37 -0000 Subject: [GHC] #11615: ghci -threaded In-Reply-To: <044.8c0dae9d570aeaf52d1cce3cbe676cd5@haskell.org> References: <044.8c0dae9d570aeaf52d1cce3cbe676cd5@haskell.org> Message-ID: <059.87096f5da792f2155eda163f6b3beedc@haskell.org> #11615: ghci -threaded -------------------------------------+------------------------------------- Reporter: franz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Yes, because `cabal` is also written in Haskell. So you ran `cabal exec ghci` itself with multiple capabilities, which is not what you wanted. You could say something like `cabal --RTS exec ghci +RTS -N`, I guess. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 20:08:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 20:08:53 -0000 Subject: [GHC] #11569: make -j24 test In-Reply-To: <043.ebd4ab4cf2b889476fd8b09d162a3605@haskell.org> References: <043.ebd4ab4cf2b889476fd8b09d162a3605@haskell.org> Message-ID: <058.5601245fc34ffb761cd815422f3e5cdf@haskell.org> #11569: make -j24 test -------------------------------+------------------------------- Reporter: mfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 8.1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+------------------------------- Comment (by Thomas Miedema ): In [changeset:"9634e24519981c32b9c2a6570898b87aa9111405/ghc" 9634e24/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="9634e24519981c32b9c2a6570898b87aa9111405" unexport MAKEFLAGS when running tests (#11569) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 20:13:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 20:13:13 -0000 Subject: [GHC] #11569: make -j24 test In-Reply-To: <043.ebd4ab4cf2b889476fd8b09d162a3605@haskell.org> References: <043.ebd4ab4cf2b889476fd8b09d162a3605@haskell.org> Message-ID: <058.0aed43d70d122075254cf7e375a86904@haskell.org> #11569: make -j24 test -------------------------------+------------------------------- Reporter: mfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Comment: Ok, that should fix it, but please reopen if it is still not working correctly. And sorry for misunderstanding the problem at first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 20:20:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 20:20:10 -0000 Subject: [GHC] #11615: ghci -threaded In-Reply-To: <044.8c0dae9d570aeaf52d1cce3cbe676cd5@haskell.org> References: <044.8c0dae9d570aeaf52d1cce3cbe676cd5@haskell.org> Message-ID: <059.5dc30038d1c8b98619cb2df41facd3ef@haskell.org> #11615: ghci -threaded -------------------------------------+------------------------------------- Reporter: franz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by franz): Your guess did not work. I have however tried to set the "+RTS -N" in the Haskell code: {{{ m <- getNumProcessors setNumCapabilities m }}} This did actually work! My problem is solved, but the question remains: why does "cabal repl +RTS -N" and "cabal ghci +RTS -N" not work as expected? The options seem not to "reach" ghc! rwbarton: Thank you very much for your appreciated help! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 20:25:02 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 20:25:02 -0000 Subject: [GHC] #11615: ghci -threaded In-Reply-To: <044.8c0dae9d570aeaf52d1cce3cbe676cd5@haskell.org> References: <044.8c0dae9d570aeaf52d1cce3cbe676cd5@haskell.org> Message-ID: <059.4144f7a4b6dadd22abb05c2024532a1a@haskell.org> #11615: ghci -threaded -------------------------------------+------------------------------------- Reporter: franz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): They don't reach ghci because they are consumed by the Haskell RTS of `cabal` instead. Apparently this is the way to pass additional arguments to `cabal exec`: {{{ cabal exec -- ghci +RTS -N }}} And this works because options after `--` are not processed by the RTS. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 20:26:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 20:26:41 -0000 Subject: [GHC] #11615: ghci -threaded In-Reply-To: <044.8c0dae9d570aeaf52d1cce3cbe676cd5@haskell.org> References: <044.8c0dae9d570aeaf52d1cce3cbe676cd5@haskell.org> Message-ID: <059.68777bd36527ce3aed8e316a9827f373@haskell.org> #11615: ghci -threaded -------------------------------------+------------------------------------- Reporter: franz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Or: {{{ cabal repl --ghc-options='+RTS -N2' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 20:28:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 20:28:38 -0000 Subject: [GHC] #11615: ghci -threaded In-Reply-To: <044.8c0dae9d570aeaf52d1cce3cbe676cd5@haskell.org> References: <044.8c0dae9d570aeaf52d1cce3cbe676cd5@haskell.org> Message-ID: <059.694377cef9df80359c564beaebe5cb18@haskell.org> #11615: ghci -threaded -------------------------------------+------------------------------------- Reporter: franz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by franz): Thank you very much! Both solutions work! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 20:29:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 20:29:00 -0000 Subject: [GHC] #11615: ghci -threaded In-Reply-To: <044.8c0dae9d570aeaf52d1cce3cbe676cd5@haskell.org> References: <044.8c0dae9d570aeaf52d1cce3cbe676cd5@haskell.org> Message-ID: <059.e8196253cc80d13b47a8498c2a94ce88@haskell.org> #11615: ghci -threaded -------------------------------------+------------------------------------- Reporter: franz | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by franz): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 21:30:51 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 21:30:51 -0000 Subject: [GHC] #11616: Kinds aren't instantiated Message-ID: <051.8ecdc328e58df668fa88298bb62fc07f@haskell.org> #11616: Kinds aren't instantiated -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE TypeInType, AllowAmbiugousTypes #-} class Whoami a where whoami :: String instance Whoami Int where whoami = "int" instance Whoami Bool where whoami = "[y/n]" instance Whoami Maybe where whoami = "call me maybe" }}} we can write {{{ >>> whoami @Type @Int "int" >>> whoami @Type @Bool "[y/n]" >>> whoami @(Type -> Type) @Maybe "call me maybe" }}} Attempting to specialise `whoami` to `Type` we can't simply write `whoamiType = whoami @Type` as one might expect. To start we define a synonym: {{{ $ ghci -ignore-dot-ghci /tmp/t17q.hs GHCi, version 8.1.20160117: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( /tmp/t17q.hs, interpreted ) Ok, modules loaded: Main. *Main> whoami2 = whoami :1:1: error: ? Ambiguous type variable ?a0? arising from a use of ?whoami? prevents the constraint ?(Whoami a0)? from being solved. Probable fix: use a type annotation to specify what ?k0?, ?a0? should be. These potential instances exist: three instance involving out-of-scope typess (use -fprint-potential-instances to see them all) ? When instantiating ?whoami2?, initially inferred to have this overly-general type: forall k (a :: k). Whoami a => String NB: This instantiation can be caused by the monomorphism restriction. }}} Using the ?overly-general? inferred type `whoami :: forall k (a :: k). Whoami a => String` fails: {{{#!hs -- ? Could not deduce (Whoami a0) arising from a use of ?whoami? -- from the context: Whoami a -- bound by the type signature for: -- whoami2 :: Whoami a => String -- at /tmp/t17q.hs:20:1-44 -- The type variable ?a0? is ambiguous -- These potential instances exist: -- three instance involving out-of-scope typess -- (use -fprint-potential-instances to see them all) -- ? In the expression: whoami -- In an equation for ?whoami2?: whoami2 = whoami whoami2 :: forall k (a :: k). Whoami a => String whoami2 = whoami }}} so we need `TypeApplications`: {{{#!hs whoami2 :: forall k (a :: k). Whoami a => String whoami2 = whoami @_ @a }}} and then we can write: {{{#!hs whoamiType :: forall (a :: Type). Whoami a => String whoamiType = whoami @_ @a }}} and we can write as intended: {{{ >>> whoamiType @Int "int" >>> whoamiType @Bool "[y/n]" }}} Is there a reason one cannot write: {{{#!hs whoami2 = whoami whoamiType = whoami @Type }}} ---- As a side note, what is the difference between {{{#!hs -- >>> :set -fprintf-explicit-foralls -- >>> :kind Whoami1 -- Whoami1 :: forall {k}. k -> Constraint -- >>> :kind Whoami2 -- Whoami2 :: forall k. k -> Constraint class Whoami1 a class Whoami2 (a :: k) }}} Is there a snippet of code that highlights differences -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 21:51:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 21:51:09 -0000 Subject: [GHC] #11611: ghc panics In-Reply-To: <051.3fd20af57abcb0290dbd3de8c0429ea4@haskell.org> References: <051.3fd20af57abcb0290dbd3de8c0429ea4@haskell.org> Message-ID: <066.551796cf5aab895e4a92aec3d7fa85f0@haskell.org> #11611: ghc panics -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): I have yet to upgrade my compiler. Can someone confirm that this is the same bug: {{{#!hs {-# LANGUAGE MultiParamTypeClasses, TypeOperators, PolyKinds, TypeInType, FunctionalDependencies, AllowAmbiguousTypes, FlexibleInstances, FlexibleContexts #-} import Data.Kind (Type) class ToMimeType k (a :: k) | a -> k where toMimeType :: String instance ToMimeType Type Int where toMimeType = "int" instance ToMimeType Type Float where toMimeType = "fl" instance (ToMimeType a x, ToMimeType [a] xs) => ToMimeType [u] (x:xs) where }}} Feel free to close the ticket if so -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 22:02:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 22:02:12 -0000 Subject: [GHC] #11611: ghc panics In-Reply-To: <051.3fd20af57abcb0290dbd3de8c0429ea4@haskell.org> References: <051.3fd20af57abcb0290dbd3de8c0429ea4@haskell.org> Message-ID: <066.7f2418e25a59957f2784fc309e38e012@haskell.org> #11611: ghc panics -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11563, #11520, | Differential Rev(s): #11516, #11399 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * version: 8.1 => 8.0.1-rc1 * component: Compiler => Compiler (Type checker) * related: => #11563, #11520, #11516, #11399 * milestone: => 8.0.1 Comment: Looks fine: {{{ Test.hs:15:65: error: ? Expected kind ?[u]?, but ?x : xs? has kind ?[a]? ? In the second argument of ?ToMimeType?, namely ?x : xs? In the instance declaration for ?ToMimeType [u] (x : xs)? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 22:12:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 22:12:28 -0000 Subject: [GHC] #10594: the ghc-7.10.1-x86_64-apple-darwin.tar.bz2 doesn't install /sw/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3/GHC In-Reply-To: <046.69b85de5f279bc6fd8a3f5ec62466a80@haskell.org> References: <046.69b85de5f279bc6fd8a3f5ec62466a80@haskell.org> Message-ID: <061.9aa920cbfe75688848e52e15107812bf@haskell.org> #10594: the ghc-7.10.1-x86_64-apple-darwin.tar.bz2 doesn't install /sw/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3/GHC -------------------------------------+------------------------------------- Reporter: howarth | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Build System | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by thomie: @@ -7,0 +7,1 @@ + }}} @@ -13,0 +14,1 @@ + {{{ @@ -22,0 +24,1 @@ + }}} @@ -23,1 +26,1 @@ - This compares to the same installation of the ghc-7.8.3-x86_64-apple- + This compares to the same installation of the ghc-7.8.3-x86_64-apple- @@ -26,0 +29,1 @@ + {{{ New description: Using the ghc-7.10.1-x86_64-apple-darwin.tar.bz2 binary release to install ghc 7.10.1 with... {{{ ./configure --prefix=/sw make DESTDIR=/sw install }}} fails to install a populated /sw/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3/GHC subdirectory causing builds of ghc packages with gcc-prim dependencies to fail. The only non- documentation files installed are... {{{ -rwxr-xr-x root/admin 647620 2015-07-01 13:20 ./sw/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3/libHSghc- prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3-ghc7.10.1.dylib -rw-r--r-- root/admin 1326504 2015-07-01 13:20 ./sw/lib/ghc-7.10.1/ghcpr_8TmvWUcS1U1IKHT0levwg3/libHSghc- prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3.a -rw-r--r-- root/admin 814 2015-07-01 13:20 ./sw/lib/ghc-7.10.1/package.conf.d/ghc- prim-0.4.0.0-7c945cc0c41d3b7b70f3edd125671166.conf }}} This compares to the same installation of the ghc-7.8.3-x86_64-apple- darwin.tar.bz2 binary release which does install the required files as... {{{ drwxr-xr-x root/admin 0 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/ drwxr-xr-x root/admin 0 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/ -rw-r--r-- root/admin 373897 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Classes.dyn_hi -rw-r--r-- root/admin 373885 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Classes.hi -rw-r--r-- root/admin 373889 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Classes.p_hi -rw-r--r-- root/admin 2661 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/CString.dyn_hi -rw-r--r-- root/admin 2649 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/CString.hi -rw-r--r-- root/admin 2653 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/CString.p_hi -rw-r--r-- root/admin 1940 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Debug.dyn_hi -rw-r--r-- root/admin 1928 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Debug.hi -rw-r--r-- root/admin 1932 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Debug.p_hi -rw-r--r-- root/admin 942 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/IntWord64.dyn_hi -rw-r--r-- root/admin 930 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/IntWord64.hi -rw-r--r-- root/admin 934 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/IntWord64.p_hi -rw-r--r-- root/admin 388 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Magic.dyn_hi -rw-r--r-- root/admin 376 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Magic.hi -rw-r--r-- root/admin 380 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Magic.p_hi -rw-r--r-- root/admin 50032 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/PrimopWrappers.dyn_hi -rw-r--r-- root/admin 50020 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/PrimopWrappers.hi -rw-r--r-- root/admin 50024 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/PrimopWrappers.p_hi -rw-r--r-- root/admin 1100 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Tuple.dyn_hi -rw-r--r-- root/admin 1088 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Tuple.hi -rw-r--r-- root/admin 1092 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Tuple.p_hi -rw-r--r-- root/admin 939 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Types.dyn_hi -rw-r--r-- root/admin 927 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Types.hi -rw-r--r-- root/admin 931 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/GHC/Types.p_hi -rwxr-xr-x root/admin 631192 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/libHSghc-prim-0.3.1.0-ghc7.8.3.dylib -rw-r--r-- root/admin 792352 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/libHSghc-prim-0.3.1.0.a -rw-r--r-- root/admin 1134504 2015-07-01 13:08 ./sw/lib/ghc-7.8.3/ghc- prim-0.3.1.0/libHSghc-prim-0.3.1.0_p.a -rw-r--r-- root/admin 871 2015-07-01 13:09 ./sw/lib/ghc-7.8.3/package.conf.d/ghc- prim-0.3.1.0-954cb57749cf319beafdc89b3415422c.conf }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 22:20:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 22:20:28 -0000 Subject: [GHC] #6132: Can't use both shebang line and #ifdef declarations in the same file. In-Reply-To: <046.5a1fb6c2a5c75e33d964893f8930e4ec@haskell.org> References: <046.5a1fb6c2a5c75e33d964893f8930e4ec@haskell.org> Message-ID: <061.93280ad667bcea7bc518cf5c4894214f@haskell.org> #6132: Can't use both shebang line and #ifdef declarations in the same file. ----------------------------------------------+---------------------------- Reporter: gfxmonk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Parser) | Version: 7.0.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects valid program | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------------------+---------------------------- Comment (by Thomas Miedema ): In [changeset:"0b00add03043804211f567a3d0810114c0274252/ghc" 0b00add0/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0b00add03043804211f567a3d0810114c0274252" Add test for #6132: hash bang + CPP }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 22:23:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 22:23:12 -0000 Subject: [GHC] #6132: Can't use both shebang line and #ifdef declarations in the same file. In-Reply-To: <046.5a1fb6c2a5c75e33d964893f8930e4ec@haskell.org> References: <046.5a1fb6c2a5c75e33d964893f8930e4ec@haskell.org> Message-ID: <061.c5854a0853820c63c8a4d5c9d3c33d0f@haskell.org> #6132: Can't use both shebang line and #ifdef declarations in the same file. -------------------------------------+------------------------------------- Reporter: gfxmonk | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.0.4 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: runghc/T6132 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => runghc/T6132 * status: new => closed * resolution: => fixed Comment: This was fixed in commit 7b0695a887c13a431f898d89938e127faa3f4585 (ghc-7.8.1): {{{ Author: Austin Seipp Date: Mon Jun 17 06:12:08 2013 -0500 Use assembler-with-cpp mode when running CPP. This is needed because Clang is very strict about C99 macro rules, which dictate that '#' in a body must have a token immediately following it for string-ification. In practice we break this all the time, because we do very weird stuff like: #define FOOBAR(xyz) \ {-# SOME PRAGMA #-} \ baz :: (xyz) \ baz = ... where the leading '#' in in the macro body clearly breaks this rule. Signed-off-by: Austin Seipp }}} Hurray Austin! I added a test. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 22:29:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 22:29:06 -0000 Subject: [GHC] #11535: Derived instance of Read/Show causes runtime exception for infix Unicode value constructors In-Reply-To: <045.263be43d8d65688efb1e343588c8d0d5@haskell.org> References: <045.263be43d8d65688efb1e343588c8d0d5@haskell.org> Message-ID: <060.1c03bc6ce22b2bdd313536f94ead0080@haskell.org> #11535: Derived instance of Read/Show causes runtime exception for infix Unicode value constructors -------------------------------------+------------------------------------- Reporter: nushio | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: unicode Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1544, #11529 | Differential Rev(s): Phab:D1884 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 8.0.1 Comment: Thanks again nushio. And sorry for the delay, your patch was not showing up in the "Needs review" queue for some reason, so we kind of forgot about it for a while. I hope you can work on some of the other unicode tickets as well. (bgamari: This commit just added a test. Merge to 8.0 at will) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 22:51:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 22:51:42 -0000 Subject: [GHC] #7650: can't use combining characters in identifiers In-Reply-To: <044.4fb0377eab552e230ee53da0d70baa3c@haskell.org> References: <044.4fb0377eab552e230ee53da0d70baa3c@haskell.org> Message-ID: <059.0a57a355d2167b43a183502fcf2d4ba0@haskell.org> #7650: can't use combining characters in identifiers -------------------------------------+------------------------------------- Reporter: guest | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 (Parser) | Resolution: | Keywords: unicode Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1938 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * owner: => thomie * differential: => Phab:D1938 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 23:04:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 23:04:05 -0000 Subject: [GHC] #11617: DYLD_LIBRARY_PATH ignored on Mac OS X 10.11.x Message-ID: <047.d00a5696b889c6d842cf8ac7cce9d67a@haskell.org> #11617: DYLD_LIBRARY_PATH ignored on Mac OS X 10.11.x --------------------------------------+--------------------------------- Reporter: borsboom | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.10.3 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: None/Unknown Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------+--------------------------------- This was first reported on the Stack issue tracker at https://github.com/commercialhaskell/stack/issues/1161, but I've traced it to the fact that GHC uses shell script wrappers for many common commands, including `ghc`, `ghci`, and `hsc2hs`. Background: Mac OS X 10.11 introduced System Integrity Protection, which treats parts of the filesystem specially to prevent tampering with the system. Among those protections is that executables in `/bin`, such as `/bin/sh`, have the DYLD_LIBRARY_PATH variable stripped from the environment before being invoked. Since `ghc`, `hsc2hs`, and others are shell scripts that use `#!/bin/sh`, it means DYLD_LIBRARY_PATH is stripped from the environment when invoking them. I was able to work around this issue by copying `/bin/sh` to my home directory and then modifying the `#!` path in the `hsc2hs` to use the copy. I'm not sure what the best way to move forward is. Some possibilities I can think of: * Have installer tools for OS X (such as Stack, ghcformacosx, and Homebrew) apply the workaround themselves, although that leaves out anyone who installs directly from an official bindist or builds from source, and is a duplication of effort. * Have `make install` on OS X copy `/bin/sh` and "fix" the wrappers itself. * Replace the shell script wrappers with something written in Haskell that reads the paths from a configuration file. Note: I set the component to `hsc2hs` since that's where I encountered the problem, but I wouldn't be surprised if it also effected other cases (like `ghci`, and `ghc` with Template Haskell). I also hesitated to categorize this a "bug" since it's OS X's weird behaviour, and not actually something I feel GHC is doing wrong, causing this problem. But I doubt OS X is going to change, although it is possible (but not recommended) to disable SIP by booting into recovery mode and running `csrutil disable`, after which these protections are no longer in place. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 23:28:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 23:28:16 -0000 Subject: [GHC] #11606: name shadowing warnings don't trigger on standalone declarations in ghci In-Reply-To: <047.da6e0c4abf31fd9d88f2bdf57a7418b8@haskell.org> References: <047.da6e0c4abf31fd9d88f2bdf57a7418b8@haskell.org> Message-ID: <062.1deefe3791a56c57c5f4b87af2827b90@haskell.org> #11606: name shadowing warnings don't trigger on standalone declarations in ghci -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * owner: => rwbarton Comment: I realized the reason is that we never test names defined at top level for shadowing (shadowing names imported from other modules). So the plan is this. Add a flag `-Wtop-level-name-shadowing` that checks top-level bindings for shadowing (like defining `id`). Then make it default in the ghci interactive flags (only). (No, I do not suggest making it part of `-Wall`.) Validating that currently, then will post on Phab. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 20 23:49:11 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 20 Feb 2016 23:49:11 -0000 Subject: [GHC] #11618: Supporting echoing the C compiler invocation instead of the GHC invocation when building the RTS Message-ID: <047.24e0c6d5f3a78d3251b196d72b6dc0e8@haskell.org> #11618: Supporting echoing the C compiler invocation instead of the GHC invocation when building the RTS -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Keywords: ide | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently GHC's build system echos the GHC invocation used to build each C source file. This is incompatible with IDEs like Eclipse, which require that the actual C compiler invocation be emitted so they can determine the flags being passed to the C compiler. As a result, code assistance in Eclipse is poor. This is a feature request for mimicking the build output of a C build. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 21 01:02:28 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Feb 2016 01:02:28 -0000 Subject: [GHC] #2289: Needless reboxing of values when returning from a tight loop In-Reply-To: <043.32b2235b0e9fe1aba0c28a0cd28686b3@haskell.org> References: <043.32b2235b0e9fe1aba0c28a0cd28686b3@haskell.org> Message-ID: <058.bcfaeb9fb0e5df43182f485474e538c8@haskell.org> #2289: Needless reboxing of values when returning from a tight loop -------------------------------------+------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: | Keywords: boxing, | loops, performance Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #2387,#1600 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by twhitehead): Thanks for feedback. I follow that `loop2` in itself is not strict in the accumulators `au` and `ad`. It would seem GHC considers the context, however, as it did go ahead and create a version strict in `au` and `ad` (i.e., `main_$s$wloop2` is clearly specialized to take `au` and `ad` as unboxed `Int#`s). {{{ #!haskell main_$s$wloop2 [Occ=LoopBreaker] :: Int# -> Int# -> Int# -> (# Int, Int #) }}} Possibly the only issue left here is indeed the nested CPR then? At least it is all I can see really different from this single-return-value variant in which GHC wonderfully eliminates all boxing and unboxing. {{{ #!haskell main :: IO () main = case loop1 100 10 of a -> print a loop1 :: Int -> Int -> Int loop1 n a | n > 0 = loop1 (n-1) (-a) | otherwise = a }}} {{{ #!haskell Rec { $wloop1 :: Int# -> Int# -> Int# $wloop1 = \ (ww_s3th :: Int#) (ww1_s3tl :: Int#) -> case tagToEnum# (># ww_s3th 0) of _ { False -> ww1_s3tl; True -> $wloop1 (-# ww_s3th 1) (negateInt# ww1_s3tl) } end Rec } }}} I'm also not sure I follow you on the only-one-specialization rule. From looking at core dumps it seems GHC does do multiple specializations. For example, 1. adding an export of `loop2` causes a purely non-strict version to be generated and 2. adding a `case loop2 100 (10,undefined) of (au,_) -> ...` causes a strict-only-in-the-first-argument version to be generated all in the same code and in addition to `main_$s$wloop2` above. Perhaps things have been relaxed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 21 01:56:32 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Feb 2016 01:56:32 -0000 Subject: [GHC] #11569: make -j24 test In-Reply-To: <043.ebd4ab4cf2b889476fd8b09d162a3605@haskell.org> References: <043.ebd4ab4cf2b889476fd8b09d162a3605@haskell.org> Message-ID: <058.8fd27087d39f70119d114be0efdb3fb3@haskell.org> #11569: make -j24 test -------------------------------+------------------------------- Reporter: mfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+------------------------------- Comment (by Thomas Miedema ): In [changeset:"6e691cacd6484b02df72f3e46a1d2ed0779a3107/ghc" 6e691cac/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6e691cacd6484b02df72f3e46a1d2ed0779a3107" Testsuite: pass '-s --no-print-directory' to MAKE This seems necessary after 9634e24 (#11569). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 21 07:42:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Feb 2016 07:42:09 -0000 Subject: [GHC] #11619: GHC.Stats documentation error Message-ID: <044.1939889567efc47e98f7bce777e30688@haskell.org> #11619: GHC.Stats documentation error -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: new Priority: low | Milestone: Component: | Version: 7.10.3 libraries/base | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The [https://hackage.haskell.org/package/base-4.8.2.0/docs/GHC- Stats.html#t:GCStats documentation] for GCStats is not formatted properly: {{{ numByteUsageSamples :: !Int64 Number of byte usage samples taken | Sum of all byte usage samples, can be used with numByteUsageSamples to calculate averages with arbitrary weighting (if you are sampling this record multiple times). }}} {{{ wallSeconds :: !Double Total wall clock time elapsed since start | Number of bytes copied during GC, minus space held by mutable lists held by the capabilities. Can be used with parMaxBytesCopied to determine how well parallel GC utilized all cores. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 21 07:44:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Feb 2016 07:44:17 -0000 Subject: [GHC] #11508: QuickCheck application hangs with concurrent read/write of Chan In-Reply-To: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> References: <044.50dd08029ef4c6477c57581f1e2d3354@haskell.org> Message-ID: <059.1393d6b33a55c984ee74a613c696b0d9@haskell.org> #11508: QuickCheck application hangs with concurrent read/write of Chan -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 | (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by orion): The status of this ticket is, "infoneeded". What information do you need? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 21 15:59:38 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Feb 2016 15:59:38 -0000 Subject: [GHC] #11618: Supporting echoing the C compiler invocation instead of the GHC invocation when building the RTS In-Reply-To: <047.24e0c6d5f3a78d3251b196d72b6dc0e8@haskell.org> References: <047.24e0c6d5f3a78d3251b196d72b6dc0e8@haskell.org> Message-ID: <062.c6f2bb8c6d0dd2ad843e5235388a4f98@haskell.org> #11618: Supporting echoing the C compiler invocation instead of the GHC invocation when building the RTS -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Resolution: | Keywords: ide Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): I don't understand this request. What do flags being passed to the C compiler when building GHC have to do with code assistance in Eclipse? But you can try putting something like this in your `mk/build.mk` file: `rts_HC_OPTS += -v`. Then the lines you're looking for should show up in the output (together with a bunch of other stuff): {{{ *** C Compiler: ./usr/bin/gcc ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 21 17:35:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Feb 2016 17:35:23 -0000 Subject: [GHC] #11537: GHC fails to compile if source is in /ghc In-Reply-To: <050.7c1644d435e2a21ad9636a7eb5cb10e7@haskell.org> References: <050.7c1644d435e2a21ad9636a7eb5cb10e7@haskell.org> Message-ID: <065.36e07ba0807f85f72c603f63c3e6cf92@haskell.org> #11537: GHC fails to compile if source is in /ghc -------------------------------------+------------------------------------- Reporter: wereHamster | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"f45103908348fb92ef9a16ab97ced87239a66783/ghc" f4510390/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f45103908348fb92ef9a16ab97ced87239a66783" Build system: fix sed expression (#11537) This allows building ghc in '/ghc'. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 21 17:35:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Feb 2016 17:35:23 -0000 Subject: [GHC] #11619: GHC.Stats documentation error In-Reply-To: <044.1939889567efc47e98f7bce777e30688@haskell.org> References: <044.1939889567efc47e98f7bce777e30688@haskell.org> Message-ID: <059.e8730b335258ed63949fbb5528f04e65@haskell.org> #11619: GHC.Stats documentation error -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: new Priority: low | Milestone: Component: libraries/base | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"bb9cd45498b36be1624fbdccb4999bb45a776b4f/ghc" bb9cd45/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bb9cd45498b36be1624fbdccb4999bb45a776b4f" Fix GHC.Stats documentation markup (#11619) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 21 17:36:24 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Feb 2016 17:36:24 -0000 Subject: [GHC] #11619: GHC.Stats documentation error In-Reply-To: <044.1939889567efc47e98f7bce777e30688@haskell.org> References: <044.1939889567efc47e98f7bce777e30688@haskell.org> Message-ID: <059.2605f2ca3a7dbdfba415239ab21d0d8e@haskell.org> #11619: GHC.Stats documentation error -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: merge Priority: low | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => merge * failure: None/Unknown => Documentation bug * milestone: => 8.0.1 Comment: Fixed. Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 21 17:39:26 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Feb 2016 17:39:26 -0000 Subject: [GHC] #11537: GHC fails to compile if source is in /ghc In-Reply-To: <050.7c1644d435e2a21ad9636a7eb5cb10e7@haskell.org> References: <050.7c1644d435e2a21ad9636a7eb5cb10e7@haskell.org> Message-ID: <065.552dfaa4382d53a1ad198f427603c554@haskell.org> #11537: GHC fails to compile if source is in /ghc -------------------------------------+------------------------------------- Reporter: wereHamster | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Build System | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => fixed * milestone: => 8.2.1 Comment: I applied your proposed fix. Building ghc in `/ghc` should work now (I tested it). Thanks for the report. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 21 17:54:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Feb 2016 17:54:07 -0000 Subject: [GHC] #10217: Provide link to GPG signature on download page. In-Reply-To: <042.3be3cfd04f796daabfe8f3ac5fc1b22c@haskell.org> References: <042.3be3cfd04f796daabfe8f3ac5fc1b22c@haskell.org> Message-ID: <057.9a1888caafd6fd3bdf46dc787b9f58c6@haskell.org> #10217: Provide link to GPG signature on download page. -------------------------------------+------------------------------------- Reporter: f-a | Owner: bgamari Type: feature request | Status: new Priority: highest | Milestone: 8.0.1 Component: Documentation | Version: Resolution: | Keywords: GPG, | signature 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 thomie): * priority: normal => highest * owner: thoughtpolice => bgamari * milestone: => 8.0.1 Comment: Setting to priority=highest so @bgamari will see it, not that I think it's //that// important. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 21 17:58:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Feb 2016 17:58:52 -0000 Subject: [GHC] #11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied In-Reply-To: <045.7c07d2218cc40ac347ede40d7f240131@haskell.org> References: <045.7c07d2218cc40ac347ede40d7f240131@haskell.org> Message-ID: <060.9ced834459a2e0edbcff95fb41496650@haskell.org> #11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): I guess it could be viewed as a feature request. I need to play around with the 8.0 / master a bit to have a clear sense of if TypeError alone suffices, but I DO think that from a user / usability perspective, the fact that we DO present the definition of TypeError as being an empty closed type family in GHC.TypeLits will be confusing for some users. I think either a) the documentation in http://downloads.haskell.org/~ghc/8.0.1-rc2/docs/html/libraries/base-4.9.0.0 /GHC-TypeLits.html#g:4 (the GHC.TypeLits module) should be changed to clearly articulate that TypeError has special wired-in behavior that can't be replicated in userland, (including what special treatment it gets versus userland type families that are written simularly) OR b) anything that has a reasonable looking source definition in base that isn't the infinite loop style found in http://downloads.haskell.org/~ghc/8.0.1-rc2/docs/html/libraries/ghc- prim-0.5.0.0/GHC-Prim.html and not explicitly documented as being a deeply magical / wired-in behavior really should be replicable in userland zooming out: its probably the case that for me, TypeError will probably be fine for me, but my main concern is about having a clearer understanding of whats a magical special case and what isnt', and how the semantics of the pieces of magics is clearly articulated -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 21 18:09:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Feb 2016 18:09:59 -0000 Subject: [GHC] #11620: RFC: Type-class type signatures (:: Constraint) Message-ID: <051.2d2cb16f2daf2eaa67da241f55133953@haskell.org> #11620: RFC: Type-class type signatures (:: Constraint) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Data types can be defined: {{{#!hs data A a b -- or data A (a :: Bool) (b :: Type) -- or data A (a :: Bool) (b :: Type) :: Type -- or data A :: Bool -> Type -> Type data B :: Type }}} while type classes can't: {{{#!hs class A a b -- or class A (a :: Bool) (b :: Type) -- but not -- class A (a :: Bool) (b :: Type) :: Constraint -- nor -- class A :: Bool -> Type -> Constraint -- class B :: Constraint }}} I foresee problems with how to bind `a` and `b`, but adding a final `:: Constraint` should be legal: {{{#!hs class A a b :: Constraint class A (a :: Bool) (b :: Type) :: Constraint class B :: Constraint }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 21 18:21:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Feb 2016 18:21:59 -0000 Subject: [GHC] #11621: GHC doesn't see () as a Constraint in type family Message-ID: <051.2614c189cee6aedf6ce97aadd979fbc3@haskell.org> #11621: GHC doesn't see () as a Constraint in type family -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE DataKinds, TypeOperators, KindSignatures, MultiParamTypeClasses, TypeFamilies #-} import Data.Kind class NotFound type family F b where F 'False = (NotFound :: Constraint) F 'True = (() :: Constraint) }}} works fine. Removing all constraints and final line it works without any annotations and infers the type of `F :: Bool -> Constraint`: {{{#!hs type family F b where F 'False = NotFound }}} GHC seems determined that `() :: Type` unless explicitly told otherwise, I would like to be able to write: {{{#!hs type family F b where F 'False = NotFound F 'True = () }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 21 18:24:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Feb 2016 18:24:29 -0000 Subject: [GHC] #11622: Annotating types in type familiy equations without parentheses Message-ID: <051.fa9ccc48e4902c5c4db8bb7f638000aa@haskell.org> #11622: Annotating types in type familiy equations without parentheses -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- When annotating types in right-hand side of type family equations parentheses are required: {{{#!hs type family F a where F _ = (Int :: Type) }}} instead of {{{#!hs type family F a where F _ = Int :: Type }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 21 19:04:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Feb 2016 19:04:18 -0000 Subject: [GHC] #11560: panic: isInjectiveTyCon sees a TcTyCon In-Reply-To: <047.844547fa9c9539b9ad0e369581a719b2@haskell.org> References: <047.844547fa9c9539b9ad0e369581a719b2@haskell.org> Message-ID: <062.b6723cb246aa1578bdc26c365e122a54@haskell.org> #11560: panic: isInjectiveTyCon sees a TcTyCon -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Apparently I was supposed to write {{{ ... where { T (*) Int = * } }}} or {{{ ... where { T Type Int = * } }}} Some bad interaction with TypeOperators perhaps? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 21 19:24:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 21 Feb 2016 19:24:34 -0000 Subject: [GHC] #11623: Wrong error message for type family definition that is wrong in multiple ways Message-ID: <047.ac7120cde85232bfd7b39a31762350cf@haskell.org> #11623: Wrong error message for type family definition that is wrong in multiple ways -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{ GHCi, version 8.1.20160212: http://www.haskell.org/ghc/ :? for help Prelude> :set -XTypeFamilies Prelude> type family T where { Maybe T = Int } :2:23: error: ? Too many parameters to T: T is unexpected; expected only no parameters ? In the type family declaration for ?T? }}} This error message is wrong ("Too many parameters to `T`"). Seems like GHC checks whether the equation `Maybe T = Int` has the right number of arguments before it checks whether it is actually headed by `T`. Then the error message is worded in a way that assumes the instance head actually was `T`. The 7.10 error message was better in this regard: {{{ :3:23: Number of parameters must match family declaration; expected 0 In the type family declaration for ?T? }}} but it would be even better to generate the error below (that is generated once the number of arguments is correct) for the original program: {{{ Prelude> type family T a where { Maybe (T ()) = Int } :5:25: error: ? Mismatched type name in type family instance. Expected: T Actual: Maybe ? In the type family declaration for ?T? }}} We should generate that error before kind-checking the definition too. I don't really understand the difference between these two cases though, so maybe my guess is wrong. {{{ Prelude> type family T where { T () = Int } :10:23: error: ? Too many parameters to T: () is unexpected; expected only no parameters ? In the type family declaration for ?T? Prelude> type family T :: * -> * where { T () = Int } :11:33: error: ? Number of parameters must match family declaration; expected 0 ? In the equations for closed type family ?T? In the type family declaration for ?T? }}} (As an aside, "expected only no parameters" is awkward, if there is some legitimate way to generate this message. It should just be "expected no parameters".) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 00:23:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 00:23:31 -0000 Subject: [GHC] #11624: Cannot declare hs-boot declaration if there is already a value in scope Message-ID: <045.b9ceb4e2b51dd79931a13bc304d99595@haskell.org> #11624: Cannot declare hs-boot declaration if there is already a value in scope -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (Type checker) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This code no longer works: {{{ -- A.hs-boot module A where concat :: Int -> Int -- overlaps with Prelude's concat -- B.hs module B where import Prelude () import {-# SOURCE #-} A x = concat 3 -- A.hs module A where import B concat n = n + 2 }}} Building `ghc --make A`, this crashes with: {{{ [1 of 3] Compiling A[boot] ( A.hs-boot, A.o-boot ) [2 of 3] Compiling B ( B.hs, B.o ) B.hs:4:5: error: ? Can't find interface-file declaration for variable concat 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: concat 3 In an equation for ?x?: x = concat 3 }}} The trouble is that renaming has botched up the top-level declaration for boot: {{{ ezyang at sabre:~$ ghc-8.0 -c A.hs-boot -ddump-rn -dppr-debug A.hs-boot:1:1: ==================== Renamer ==================== {A.hs-boot:2:1-20} base-4.9.0.0:Data.Foldable.concat{v r2S} :: {A.hs-boot:2:11-20} ghc-prim-0.5.0.0:GHC.Types.Int{(w) tc 3J} -> ghc-prim-0.5.0.0:GHC.Types.Int{(w) tc 3J} }}} Is a regression from 7.10. The dodginess is proximal to renameSig but I haven't quite narrowed it down yet. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 01:57:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 01:57:57 -0000 Subject: [GHC] #11616: Kinds aren't instantiated In-Reply-To: <051.8ecdc328e58df668fa88298bb62fc07f@haskell.org> References: <051.8ecdc328e58df668fa88298bb62fc07f@haskell.org> Message-ID: <066.ef13c587bc19c67709f37d8046d9acdd@haskell.org> #11616: Kinds aren't instantiated -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): This is almost correct behavior. The only incorrect part of this is that visible type application is available on the kind argument to `whoami` even though the kind variable was not written in the declaration of `Whomami`. You hint at this weirdness at the end of your post, where the braces mean that a variable is not available for visible type application (because GHC inferred its presence and ordering). This is a known bug that I intend to fix. But everything else is OK. The problem is that visible type application should work on only type variables that are written by the user. (I have clarified this in unpushed edits to the manual.) When you say `whoami2 = whoami`, you're not giving a type signature to `whoami2`, and therefore usages of `whoami2` cannot use visible type application. This design decision was made to help keep usage of visible type application retain the same meaning as GHC's inference algorithm evolves. Without visible type application, `whoami2`'s type is indeed ambiguous and problematic. The problem is the same with `whoamiType`. And indeed, if you give a type signature, all is OK: {{{ whoamiType :: forall a. Whoami (a :: Type) => String whoamiType = whoami @_ @a }}} I'm keeping this bug open to track the fix for the first issue, and as an interesting test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 02:30:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 02:30:13 -0000 Subject: [GHC] #11620: RFC: Type-class type signatures (:: Constraint) In-Reply-To: <051.2d2cb16f2daf2eaa67da241f55133953@haskell.org> References: <051.2d2cb16f2daf2eaa67da241f55133953@haskell.org> Message-ID: <066.0bbef4b50f247f98b180f011bb5d2aae@haskell.org> #11620: RFC: Type-class type signatures (:: Constraint) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I actually ran into this problem in a different context, where the problem was not just cosmetic. Short version: we should devise a syntax where a user can give a full kind signature for a class while binding type variables appropriately. I'm not sure what this syntax would be. Long version: I had this type: {{{#!hs data TypeRep (a :: k) where ... }}} I needed an existential wrapper around this type, something like {{{#!hs data TypeRepX1 where TypeRepX1 :: forall k (a :: k). TypeRep a -> TypeRepX1 }}} But that turned out not to work for me, because it imposes no constraint at all on `k` or `a`. So I wanted a version of `TypeRepX` that is parameterized by a constraint that will be applied to `a`. If the existential `a` is still to be kind-polymorphic, then we have to make the constraint kind-polymorphic, too: {{{#!hs data TypeRepX :: (forall k. k -> Constraint) -> Type where TypeRepX :: forall (c :: forall k1. k1 -> Constraint) k (a :: k). c a => TypeRep a -> TypeRepX c }}} (Sadly, I need to put the kind on `c` explicitly, because GHC won't infer kinds with `forall`s, lest things become impredicative. But it's not so bad, really, to put the signature on.) This actually all works quite well, to my great delight when I first tried it. Then, I wanted to use the constraint `((~~) Bool)`. That is, I wanted to insist that the type `a` is in fact `Bool`. I used heterogeneous equality so that it would all be kind-polymorphic. However, note that {{{#!hs (~~) :: forall k1 k2. k1 -> k2 -> Constraint` }}} and thus that {{{#!hs (~~) Bool :: k2 -> Constraint }}} for some `k2`. That is, the original `forall` is too far to the left. As you will see in the "Practical type inference" paper, the kind of `(~~)` is too specific; it should really be `forall k1. k1 -> forall k2. k2 -> Constraint`. But we have no way of requesting such a kind without being able to specify the full kind signature of a class. (In the case of `(~~)`, GHC could just do this by fiat. But it would be unsporting for me to do this for `(~~)` without letting you do it for your constraints.) Bottom line: it would increase the expressiveness of Haskell to be able to specify a full kind. But what about syntax?? I'm a bit stuck there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 02:35:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 02:35:10 -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.fe22a0a90c5c8fe04d018dcf8dc99411@haskell.org> #11622: Annotating types in type familiy equations without parentheses -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Parentheses are always required around kind annotations. This has been reported in the last six months, but, sadly, a few minutes of searching has not found the ticket number. I believe this would just require a careful look at the parser -- there may not be a fundamental reason for the restriction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 03:40:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 03:40:50 -0000 Subject: [GHC] #7494: Allow compatible type synonyms to be the return type of a GADT data constructor. In-Reply-To: <043.5275617b43517716cbe43613ec435437@haskell.org> References: <043.5275617b43517716cbe43613ec435437@haskell.org> Message-ID: <058.0759827c37f38f79f76d9c328a8bafec@haskell.org> #7494: Allow compatible type synonyms to be the return type of a GADT data constructor. -------------------------------------+------------------------------------- Reporter: topi | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.4.1 checker) | Resolution: | Keywords: GADT, GADTs Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Iceland_jack): * cc: Iceland_jack (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 04:15:19 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 04:15:19 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.28885385b63bf920a3344f00e7597943@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dobenour): I remember reading somewhere that the RTS has a global lock for allocating sufficiently large objects. Could that be the problem? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 04:20:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 04:20:35 -0000 Subject: [GHC] #10822: GHC inconsistently handles \\?\ for long paths on Windows In-Reply-To: <047.7e6bb9965cce015f93541e4a1a931ae5@haskell.org> References: <047.7e6bb9965cce015f93541e4a1a931ae5@haskell.org> Message-ID: <062.5a69ed6906e76e9a65546e6a6d310acf@haskell.org> #10822: GHC inconsistently handles \\?\ for long paths on Windows ---------------------------------+---------------------------------------- Reporter: snoyberg | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ---------------------------------+---------------------------------------- Comment (by dobenour): CoreCLR ran into the same problem and fixed it by adding the {{{\\?\}}} prefix to any overlong path, after making the path absolute with the {{{GetFullPathNameW}}} function in the Windows API. For UNC paths (that begin with {{{\\}}} but not with {{{\\?\}}}), the solution is to replace {{{\\}}} with {{{\\?\UNC\}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 04:36:28 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 04:36:28 -0000 Subject: [GHC] #11620: RFC: Type-class type signatures (:: Constraint) In-Reply-To: <051.2d2cb16f2daf2eaa67da241f55133953@haskell.org> References: <051.2d2cb16f2daf2eaa67da241f55133953@haskell.org> Message-ID: <066.209b2fd73d627f17827ea70491595108@haskell.org> #11620: RFC: Type-class type signatures (:: Constraint) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Thanks for the response, interesting. {{{#!hs -- Dependent function syntax class HRefl :: forall k1. (a::k1) -> forall k2. (b::k2) -> Constraint -- Specify variables separately, as in functions and `type families' -- foo :: forall a. [a] -> forall b. [b] -> Int -- foo xs ys = length xs + length ys class HEq :: forall k1. k1 -> forall k2. k2 -> Constraint HEq a b }}} Is there an effort to unify all these forms (not only syntactically); functions, type families, type classes, GADTs? Just for fun {{{#!hs data Vec Nat Type :: Type Vec n a data Vec :: Nat -> Type -> Type Vec n a class Eq :: forall k. k -> k -> Constraint Eq a b where HEq @k a @k b a implies b b implies a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 04:48:55 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 04:48:55 -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.e6c5d1f59eb3029b803b3b1cbf0159fc@haskell.org> #11622: Annotating types in type familiy equations without parentheses -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Were you thinking of #8708? Removing this restriction would help make the `:kind` command less surprising: {{{ >>> :kind Int Int :: * >>> :kind Int :: * }}} where one might expect it to work like {{{ >>> :type 'a' 'a' :: Char >>> :type 'a' :: Char 'a' :: Char :: Char }}} While we're at it, is it possible to automatically quantify free variables? {{{ >>> :kind Maybe Maybe :: * -> * >>> :kind Maybe a }}} Explicitly quantifying the variables gets tiresome when there are more of them -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 05:28:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 05:28:06 -0000 Subject: [GHC] #11625: Data.Type.Equality is not Trustworthy Message-ID: <045.00b6470b73cd59812d630575ca77009a@haskell.org> #11625: Data.Type.Equality is not Trustworthy -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Core | Version: 7.10.3 Libraries | 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: -------------------------------------+------------------------------------- `Data.Type.Equality` is not inferred safe because it has unsafe imports. I believe it is safe, and should therefore claim `Trustworthy`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 06:52:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 06:52:22 -0000 Subject: [GHC] #11583: Make warning names more consistent In-Reply-To: <046.2c5f65cdcdffbe526873fdbd4a154741@haskell.org> References: <046.2c5f65cdcdffbe526873fdbd4a154741@haskell.org> Message-ID: <061.5db0a2e4262cfc4e7d8e4e1fb5a899c2@haskell.org> #11583: Make warning names more consistent -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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 svenpanne): * priority: normal => high * milestone: 8.2.1 => 8.0.1 Comment: Setting milestone to 8.0.1 and raising priority a bit, trying to avoid an upcoming compatibility nightmare for package maintainers... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 07:23:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 07:23:08 -0000 Subject: [GHC] #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` In-Reply-To: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> References: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> Message-ID: <057.0c279f47796a98940d3035543adfb227@haskell.org> #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 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 hvr): Just to be clear, afaik this doesn't occur with 8.0.1-rc2, but rather with a more recent 8.0.01 snapshot (as described in the description). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 07:42:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 07:42:15 -0000 Subject: [GHC] #11578: Fix GHC on AArch64/Arm64 In-Reply-To: <044.82eed99cc066ccb994128f1f7245b038@haskell.org> References: <044.82eed99cc066ccb994128f1f7245b038@haskell.org> Message-ID: <059.b3e45638b5d786a394e09e8056635b34@haskell.org> #11578: Fix GHC on AArch64/Arm64 -------------------------------------+------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------- Comment (by hypoon): I'm not sure if it's useful, but it seems appropriate to link [[Arm64|my attempt]] to this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 08:46:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 08:46:09 -0000 Subject: [GHC] #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` In-Reply-To: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> References: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> Message-ID: <057.56620ccffd07bd7f2e36cd66ab0c1df8@haskell.org> #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 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 hvr): * cc: goldfire (added) Comment: It seems like e1631b3b58b7440d3d5a8bf72f1490df635792fb may have been the culprit -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 10:47:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 10:47:07 -0000 Subject: [GHC] #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` In-Reply-To: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> References: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> Message-ID: <057.40ffc799bc9528501d647e62cc33fcc9@haskell.org> #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 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 hvr): I've temporarily reverted e1631b3b58b7440d3d5a8bf72f1490df635792fb in the `ghc-8.0` branch ''only'', via 881b6ccf5c1dbc09d1d16b1b4643e3dec9387047. I'm not reverting this in GHC HEAD yet, waiting for Richard to comment how we should proceed here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 10:48:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 10:48:53 -0000 Subject: [GHC] #11475: Lint should check for inexhaustive alternatives In-Reply-To: <046.fd80dcd8f8868c23b12a0a5bfb5d7bcb@haskell.org> References: <046.fd80dcd8f8868c23b12a0a5bfb5d7bcb@haskell.org> Message-ID: <061.27d8ce2e186a347eee82ab91f078214d@haskell.org> #11475: Lint should check for inexhaustive alternatives -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Transferred from ghc-defs list I am currently giving #11475 a try. However I hit a few problems and wanted to ask for a bit of advice about how to proceed. I already can handle the following: {{{ case x of A y -> e1 _ -> ....(case x of B -> r2 C -> r3) ... }}} My first problem then was the following construct: {{{ case (case ... of ... -> Left x) of Left y -> ... }}} Or more simple: {{{ case Left x of Left y -> ... }}} So I have to check which constructors the scrutinee may return. I know the simplifier has to implement such logic somewhere but did not want to use the implementation for two reasons: - I didn't know where to find it - If GHC uses the same test to prune impossible alternatives and to check if they were pruned correctly, extending the linter is useless. A bug in the test code will cause also cause a bug in the linter. So I implemented such a test myself, but now I am stuck at something like this: {{{ foo a b = a : b bar = ... case foo a b of (:) x y -> ... }}} I cannot see through `foo`, so I assume it may return `(:)` and `[]`. The simplifier on the other hand is able to see through foo and did remove the `[]` case, causing my current implementation to throw an incorrect lint error. How can I get a list/set of all possible `AltCons` returned by a function/constant? Or a list of the impossible ones? I tried to get some information from the unfolding of a variable, but it seems like unfoldings are only attached to top-level names. Jonas -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 10:51:25 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 10:51:25 -0000 Subject: [GHC] #11475: Lint should check for inexhaustive alternatives In-Reply-To: <046.fd80dcd8f8868c23b12a0a5bfb5d7bcb@haskell.org> References: <046.fd80dcd8f8868c23b12a0a5bfb5d7bcb@haskell.org> Message-ID: <061.a3bcfc4010b08c537ce43392508643ed@haskell.org> #11475: Lint should check for inexhaustive alternatives -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I suggest being less ambitious! Do the simple things first. {{{ case (case ... of ... -> Left x) of Left y -> ... }}} GHC itself is unlikely to prune the alternative in the outer case, precisely because it's not so obvious that the inner case can only return Left. {{{ bar = ... case foo a b of (:) x y -> ... }}} Same here. In short, dealing with in-scope pattern matches and GADTs is worth doing first. Then when you get a false positive (which you say you are) we can think about them. (For `foo`, the `CprResult` part of the strictness signature will tell that `foo` only returns `(:)` but I'm a bit surprised that GHC actually uses this to prune the case alternatives. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 10:51:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 10:51:46 -0000 Subject: [GHC] #11475: Lint should check for inexhaustive alternatives In-Reply-To: <046.fd80dcd8f8868c23b12a0a5bfb5d7bcb@haskell.org> References: <046.fd80dcd8f8868c23b12a0a5bfb5d7bcb@haskell.org> Message-ID: <061.0eece8a9eeb9bc5e006bcbf22d55a398@haskell.org> #11475: Lint should check for inexhaustive alternatives -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: anselm.scholl@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 11:57:25 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 11:57:25 -0000 Subject: [GHC] #11610: Remove IEThingAll constructor from IE datatype In-Reply-To: <049.74bfb9870839f9195b618b2e2024bba7@haskell.org> References: <049.74bfb9870839f9195b618b2e2024bba7@haskell.org> Message-ID: <064.c30f9edb7d9d88e2f10a004b0b824ffc@haskell.org> #11610: Remove IEThingAll constructor from IE datatype -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm dubious about the benefit. It'll need special treatment regardless. Do we allow wildcards in exports lists today? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 12:51:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 12:51:47 -0000 Subject: [GHC] #7644: Hackage docs for base library contain broken links In-Reply-To: <048.2cecb456976c34b85b0536b320a18c3d@haskell.org> References: <048.2cecb456976c34b85b0536b320a18c3d@haskell.org> Message-ID: <063.fabd3d1863afdb6f576636bc5ecb04d7@haskell.org> #7644: Hackage docs for base library contain broken links -------------------------------------+------------------------------------- Reporter: JulesBean | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): There are still many dead links. For example the link to `par` on the page http://hackage.haskell.org/package/ghc-prim-0.4.0.0/docs/GHC-Magic.html. I guess it has something to do with `parallel` not being built by default. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 12:52:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 12:52:54 -0000 Subject: [GHC] #11613: Add microlens to testsuite In-Reply-To: <046.a73f0305ece6b182d4046b964d4e7b8a@haskell.org> References: <046.a73f0305ece6b182d4046b964d4e7b8a@haskell.org> Message-ID: <061.5400b586a07daef4f1d72fb959631d0f@haskell.org> #11613: Add microlens to testsuite -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Test Suite | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm all for it! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 13:11:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 13:11:53 -0000 Subject: [GHC] #11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment In-Reply-To: <047.9b656b30dd7751cce1c00e17927ecd51@haskell.org> References: <047.9b656b30dd7751cce1c00e17927ecd51@haskell.org> Message-ID: <062.06a82cce8d09ffa9e2341cd6388db13a@haskell.org> #11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment -------------------------------------+------------------------------------- Reporter: bollmann | Owner: bollmann Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bollmann): @rwbarton: interesting. Thanks for clarifying the true nature of this comment! I sadly hadn't run the generated splice `g "1" "2"` as you then suggested, but had found the comment misleading solely based on enabling the `-ddump- splices` flag. When enabled, the splice in your program expands to something like: {{{ \ x -> \ x_a3uK -> x }}} And thus I thought, that the comment of `newName` capturing `mkName`s didn't make sense at all, since the generated splice agrees with the specified TH AST. Hence, it seems that the splice expansion displayed by `-ddump-splices` does not agree with what is actually generated when running the code `g "1" "2"`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 13:32:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 13:32:13 -0000 Subject: [GHC] #9917: ddump-llvm runs opt/llc even when -fllvm isnt set In-Reply-To: <045.a11323789867f7415acb20ec316ad1c7@haskell.org> References: <045.a11323789867f7415acb20ec316ad1c7@haskell.org> Message-ID: <060.65f02c87a8349e9d971dfd1c2aac46e3@haskell.org> #9917: ddump-llvm runs opt/llc even when -fllvm isnt set -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Documentation | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"ed119096be6739b67d99acfa4c2d43627960f0e3/ghc" ed119096/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ed119096be6739b67d99acfa4c2d43627960f0e3" Docs: -keep-llvm-file(s)/-ddump-llvm imply -fllvm This fixes #9917. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 13:32:59 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 13:32:59 -0000 Subject: [GHC] #9917: ddump-llvm runs opt/llc even when -fllvm isnt set In-Reply-To: <045.a11323789867f7415acb20ec316ad1c7@haskell.org> References: <045.a11323789867f7415acb20ec316ad1c7@haskell.org> Message-ID: <060.03362579c7c240b801f470c6c2f57c0e@haskell.org> #9917: ddump-llvm runs opt/llc even when -fllvm isnt set -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: merge Priority: low | Milestone: 8.0.1 Component: Documentation | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => merge * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 13:41:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 13:41:13 -0000 Subject: [GHC] #2289: Needless reboxing of values when returning from a tight loop In-Reply-To: <043.32b2235b0e9fe1aba0c28a0cd28686b3@haskell.org> References: <043.32b2235b0e9fe1aba0c28a0cd28686b3@haskell.org> Message-ID: <058.3a06d1fe48fdfe3280b4b0c841afb1f0@haskell.org> #2289: Needless reboxing of values when returning from a tight loop -------------------------------------+------------------------------------- Reporter: dons | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 6.8.2 Resolution: | Keywords: boxing, | loops, performance Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #2387,#1600 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Yes, nested CPR would be great. See [wiki:NestedCPR] for Joachim's writeup of his work on it; lots of stuff there. Re one-specialisation: `SpecConstr` is free to generate lots of specialisations. But the demand analyser does not make many copies of a function, one for each demand pattern. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 14:34:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 14:34:47 -0000 Subject: [GHC] #11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment In-Reply-To: <047.9b656b30dd7751cce1c00e17927ecd51@haskell.org> References: <047.9b656b30dd7751cce1c00e17927ecd51@haskell.org> Message-ID: <062.52a06267a64a826f7a6999c3b3ec19c0@haskell.org> #11584: [Template Haskell] Language.Haskell.TH.Syntax.hs contains misleading comment -------------------------------------+------------------------------------- Reporter: bollmann | Owner: bollmann Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Ah, yes, that makes some sense. When the pretty-printer appends `_xyz` to an identifier, that's the identifier's `Unique`. TH `Name`s sometimes lead to identifiers with `Unique`s (e.g., `newName` identifiers and identifiers from quoting) and sometimes not (`mkName`). In the latter case, the variable will refer to the innermost identifier with the same name, regardless of its `Unique`. I agree the pretty-printer is confusing here. Maybe instead of `x_a3uK`, it should be `x{a3uK}`? It would then be clear that the underscore isn't part of the name proper. Not sure if this is better or worse. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 14:48:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 14:48:57 -0000 Subject: [GHC] #11583: Make warning names more consistent In-Reply-To: <046.2c5f65cdcdffbe526873fdbd4a154741@haskell.org> References: <046.2c5f65cdcdffbe526873fdbd4a154741@haskell.org> Message-ID: <061.599d7f2bee1f8d61884d74cb70bbef0a@haskell.org> #11583: Make warning names more consistent -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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:D1939 Wiki Page: | -------------------------------------+------------------------------------- Changes (by manav): * differential: => Phab:D1939 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 15:22:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 15:22:20 -0000 Subject: [GHC] #11626: type variable out of scope core lint error when compiling attoparsec Message-ID: <044.3b54a1a1868c7f532f99f416b8fae60d@haskell.org> #11626: type variable out of scope core lint error when compiling attoparsec -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- I'm getting a core lint error when compiling attoparsec with the `-dcore- lint` option {{{ *** Core Lint errors : in result of SpecConstr *** : warning: In the type ?Buffer -> Pos -> More -> a_aaPH -> IResult Text r_aaPI? @ a_aaPH is out of scope *** Offending Program *** ... 57000 lines of offending program cut *** End of Offense *** }}} * attoparsec 0.13.0.2 commit 4f137347be02106765f6897059b88219c79bb86c * ghc 8.0.1-rc2 and also 892de051aaaf9a346dadc74592a9cc375b3223a4 (feb 20) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 16:09:11 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 16:09:11 -0000 Subject: [GHC] #8710: Overlapping patterns warning misplaced In-Reply-To: <047.1f227e0dac37dd7309646386f280164b@haskell.org> References: <047.1f227e0dac37dd7309646386f280164b@haskell.org> Message-ID: <062.c29541cc4c52f50283ebac306872ffe6@haskell.org> #8710: Overlapping patterns warning misplaced -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1910, Wiki Page: | Phab:D1920 -------------------------------------+------------------------------------- Comment (by simonpj): So we are agreed on one warning per equation, with the location of the equation in the warning header. George: I think you are saying that D1910 and D1920 do the same thing. So what's the difference? Which should we choose? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 16:27:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 16:27:38 -0000 Subject: [GHC] #11329: Visible type applications: failing tests with WAY=hpc In-Reply-To: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> References: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> Message-ID: <060.e46f473e5440c80298edaa99a434307e@haskell.org> #11329: Visible type applications: failing tests with WAY=hpc -------------------------------------+------------------------------------- Reporter: thomie | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_compile/VtaParse | typecheck/should_compile/Vta1 | typecheck/should_compile/Vta2 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1824 Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: highest => high Comment: Not a release blocker -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 16:27:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 16:27:57 -0000 Subject: [GHC] #8710: Overlapping patterns warning misplaced In-Reply-To: <047.1f227e0dac37dd7309646386f280164b@haskell.org> References: <047.1f227e0dac37dd7309646386f280164b@haskell.org> Message-ID: <062.fa2e193435bb65ed612d684d380777f6@haskell.org> #8710: Overlapping patterns warning misplaced -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1910, Wiki Page: | Phab:D1920 -------------------------------------+------------------------------------- Comment (by gkaracha): Replying to [comment:11 simonpj]: > So we are agreed on one warning per equation, with the location of the equation in the warning header. > > George: I think you are saying that D1910 and D1920 do the same thing. So what's the difference? Which should we choose? If we agree on one warning per equation, with the location of the equation in the warning header, then Phab:D1920 is the one we want. Phab:D1910 implements what you describe in you previous [comment:8 comment]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 16:30:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 16:30:01 -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.35eaf9c28250e425ead44dd1da4ab3c4@haskell.org> #11126: Entered absent arg in a Repa program -------------------------------------+------------------------------------- Reporter: tuplanolla | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: highest => high Comment: Right, now we understand what is going on. It's pretty difficult to tickle it and it seems OK in 8.0. So let's not make it a release blocker. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 16:36:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 16:36:30 -0000 Subject: [GHC] #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` In-Reply-To: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> References: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> Message-ID: <057.fa83ca1675fec8e6b0dee1ab64c310d0@haskell.org> #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` -------------------------------------+------------------------------------- Reporter: hvr | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 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 goldfire): * owner: => goldfire Comment: I think there's an underlying problem here and that putting the fundep back in is not necessarily the right solution. Will need to look a bit deeper to really know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 16:43:03 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 16:43:03 -0000 Subject: [GHC] #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 In-Reply-To: <042.261e60284e26a798be48364a9348d62e@haskell.org> References: <042.261e60284e26a798be48364a9348d62e@haskell.org> Message-ID: <057.ab44658289f4ab251cc3009f4dab2869@haskell.org> #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): We will disable `-DDEBUG` on `ghc-8.0` and keep this as a release blocker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 16:47:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 16:47:08 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.f753cf16139dcb0936c448326c09ce69@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonmar): * owner: => bgamari Comment: The plan is: * `-Wall` will include `-Wredundant-constraints` * If at some point we have a compat warning that requires the addition of a redundant constraint to suppress it, then when this warning is enabled at the same time as `-Wredundant-constraints`, we will arrange to not emit a redundant constraint warning for constraints that are required to suppress the compatibility warning. Please let us know if this will cause a problem. @bgamari is going to action the first change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 17:25:07 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 17:25:07 -0000 Subject: [GHC] #5654: Profiling semantics bug In-Reply-To: <047.ac296d247951e42a341a674c3c07d355@haskell.org> References: <047.ac296d247951e42a341a674c3c07d355@haskell.org> Message-ID: <062.39e876df619d7d6d138dd277764668a8@haskell.org> #5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Profiling | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Simon: in 85daac593c498f581d46f44982ee5dcf1001f611, you defined two new tests (`T5654b-O0` and `T5654b-O0`), but didn't add `.hs` files for them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 17:48:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 17:48:44 -0000 Subject: [GHC] #8761: Make pattern synonyms work with Template Haskell In-Reply-To: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> References: <047.c5d8ed063e9e82c354c50c5724ebe787@haskell.org> Message-ID: <062.fccbd7aae538142d35c3fe662e79c092@haskell.org> #8761: Make pattern synonyms work with Template Haskell -------------------------------------+------------------------------------- Reporter: goldfire | Owner: bollmann Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 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): Phab:D1940 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bollmann): * differential: => Phab:D1940 Comment: I added an initial version of "pattern synonym support in TH" with a couple of questions for feedback. See https://phabricator.haskell.org/D1940. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 18:30:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 18:30:04 -0000 Subject: [GHC] #11627: Segmentation fault for space_leak_001 with profiling (-hc) Message-ID: <045.274c910606d60239cadf6f398a2dd711@haskell.org> #11627: Segmentation fault for space_leak_001 with profiling (-hc) -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Profiling | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: perf/space_leaks/space_leak_001 | Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `WAY=profasm` is omitted by default for this test, but the code looks like this: Test.hs: {{{ import Data.List main = print $ length $ show (foldl' (*) 1 [1..100000] :: Integer) }}} {{{ $ ghc Test.hs -prof -O $ ./Test +RTS -hc Segmentation fault (core dumped) }}} Reproducible with at least 7.10.3 and HEAD, also without `-O`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 20:21:26 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 20:21:26 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.6c739319302bb7f05f1b9be251403207@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): Including `-fwarn-redundant-constraints` but not `-Wcompat` in `-Wall` to avoid contradictory suggestions, does indeed seem like a reasonable compromise. Going through all of the code I've updated for GHC 8, `-fwarn-redundant- constraints` actually gave useful information in 18/20 cases, and had to be manually disabled because there was no appropriate "fix" in 2 places, putting it on similar footing with `-fwarn-orphans`, where most times you can slide the instance around to live with the data type or class in question, but sometimes you get boxed in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 20:36:12 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 20:36:12 -0000 Subject: [GHC] #11628: Unexpected results with Read/Show Message-ID: <047.67f72fa6cbf623849a3900e4692f1352@haskell.org> #11628: Unexpected results with Read/Show -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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: -------------------------------------+------------------------------------- In the following simplified example, `Foo` and `U` correspond to GADTs that GHC will not derive `Read`/`Show` for. I attempted to work around that by using newtypes for each GADT constructor, and letting GHC derive the `Show`/`Read` instances for those instead. However, I get a runtime error (`Prelude.read: no parse`) on the second print statement in `main`: {{{ {-# LANGUAGE FlexibleContexts, FlexibleInstances, GADTs, ScopedTypeVariables #-} import Text.Read (Read(readPrec)) newtype Bar r = Bar r deriving (Show, Read) newtype Foo r = Foo (Bar r) -- use the GHC-derived Show/Read for Bar instance (Show r) => Show (Foo r) where show (Foo x) = show x instance (Read r) => Read (Foo r) where readPrec = Foo <$> readPrec data U t rep r where U1 :: t r -> U t Int r U2 :: t r -> U t Char r -- use the Read/Show instances for U1Wrap and U2Wrap newtype U1Wrap t r = U1Wrap {unU1Wrap :: t r} deriving (Show, Read) newtype U2Wrap t r = U2Wrap (t r) deriving (Show, Read) instance (Read (t r)) => Read (U t Int r) where readPrec = (U1 . unU1Wrap) <$> readPrec instance (Read (U2Wrap t r)) => Read (U t Char r) where readPrec = do x <- readPrec return $ case x of (U2Wrap y) -> U2 y instance (Show (t r)) => Show (U t Int r) where show (U1 x) = show $ U1Wrap x instance (Show (t r)) => Show (U t Char r) where show (U2 x) = show (U2Wrap x :: U2Wrap t r) main :: IO () main = do let x = U1 $ Foo $ Bar 3 y = U2 $ Foo $ Bar 3 print $ show (read (show x) `asTypeOf` x) print $ show (read (show y) `asTypeOf` y) }}} Someone mentioned that I should define `showsPrec` rather than `show`, but these are listed as alternatives in [https://downloads.haskell.org/~ghc/latest/docs/html/libraries/base-4.8.2.0 /Text-Show.html the docs]. It's not clear to me if GHCs derived instances are invalid, or if I'm doing something illegal. In the latter case, the docs need some improvement. (Verified this behavior in 7.10.2 and HEAD.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 21:21:32 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 21:21:32 -0000 Subject: [GHC] #11628: Unexpected results with Read/Show In-Reply-To: <047.67f72fa6cbf623849a3900e4692f1352@haskell.org> References: <047.67f72fa6cbf623849a3900e4692f1352@haskell.org> Message-ID: <062.3c175bba426866bd6ab3641c103c3b25@haskell.org> #11628: Unexpected results with Read/Show -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 simonpj): What exactly is the bug here? What does not work that you expect to work? What does "does not work" mean? (Compile time error? Run time crash? Run time success but data printed does not look right?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 21:22:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 21:22:58 -0000 Subject: [GHC] #11628: Unexpected results with Read/Show In-Reply-To: <047.67f72fa6cbf623849a3900e4692f1352@haskell.org> References: <047.67f72fa6cbf623849a3900e4692f1352@haskell.org> Message-ID: <062.cd4de5e36ebc5b63f05bf9c33c64db03@haskell.org> #11628: Unexpected results with Read/Show -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 rwbarton): Lots of distractions here. Here is the crux of the matter: {{{ newtype X u = X u instance Show u => Show (X u) where show (X u) = show u main = print (Just (X (Just 1))) -- prints "Just Just 1" }}} Of course, you should just define `showsPrec` like you mentioned. Just defining `show` should be okay if (either you don't care about compatibility with Read or) the output is a single token, like a number or a quoted string. Otherwise you need to define `showsPrec`. Agree that the docs should be clearer on this point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 21:25:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 21:25:36 -0000 Subject: [GHC] #11628: Unexpected results with Read/Show In-Reply-To: <047.67f72fa6cbf623849a3900e4692f1352@haskell.org> References: <047.67f72fa6cbf623849a3900e4692f1352@haskell.org> Message-ID: <062.103bd5f000f3b689b6f21b31a1606495@haskell.org> #11628: Unexpected results with Read/Show -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 simonpj): Great, thanks. Nothing to do with GADTs then. Documentation patches would be v welcome. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 21:26:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 21:26:49 -0000 Subject: [GHC] #11628: Unexpected results with Read/Show In-Reply-To: <047.67f72fa6cbf623849a3900e4692f1352@haskell.org> References: <047.67f72fa6cbf623849a3900e4692f1352@haskell.org> Message-ID: <062.cdd4ed0e4247fccc0137bb6feb36a98e@haskell.org> #11628: Unexpected results with Read/Show -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 crockeea): Replying to [comment:2 rwbarton]: > Lots of distractions here. Here is the crux of the matter: > {{{ > newtype X u = X u > instance Show u => Show (X u) where show (X u) = show u > main = print (Just (X (Just 1))) -- prints "Just Just 1" > }}} > Of course, you should just define `showsPrec` like you mentioned. > > Just defining `show` should be okay if (either you don't care about compatibility with Read or) the output is a single token, like a number or a quoted string. Otherwise you need to define `showsPrec`. Agree that the docs should be clearer on this point. Thanks for clarifying. So it seems like this is just a documentation problem. For SPJ or future visitors: the problem as I see it is that the second print statement results in a runtime exception (`Prelude.read: no parse`). I believe it should run without exception. Apparently, based on my `Show` instances, this is non unexpected behavior. However, the documentation for show/read doesn't make it clear that I should define `showsPrec` rather than `show`. Given that rwbarton thinks the behavior is expected, then this ticket is about updated the documentation for Text.Read and Text.Show. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 21:36:13 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 21:36:13 -0000 Subject: [GHC] #11628: Unexpected results with Read/Show In-Reply-To: <047.67f72fa6cbf623849a3900e4692f1352@haskell.org> References: <047.67f72fa6cbf623849a3900e4692f1352@haskell.org> Message-ID: <062.42ec1ee1f6b1ee3c8f998c9cf5ea6557@haskell.org> #11628: Unexpected results with Read/Show -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by crockeea): * failure: Incorrect result at runtime => Documentation bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 22:30:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 22:30:27 -0000 Subject: [GHC] #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` In-Reply-To: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> References: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> Message-ID: <057.ee50ee47df5c1066679fc1aad9f6755b@haskell.org> #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` -------------------------------------+------------------------------------- Reporter: hvr | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 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): Aha. In a class decl we use a `TyVar` (not a skolem `TcTyVar`) for the class variable(s). (There is a good reason for this: in the final `Class` value we don't want any `TcTyVar`s.) Then in `TcFlatten.flatten_tyvar` we see {{{ flatten_tyvar tv | not (isTcTyVar tv) -- Happens when flatten under a (forall a. ty) = flatten_tyvar3 tv }}} This case catches that class variable. In the ambiguity check for the type sig for `each` we have a Given equality for the class variable. Then, because of the above test we fail to take advantage of the Given. (And the error message too is misleading.) Solution: delete the above equation, so that we treat `TyVar` and skolem `TcTyVar` the same. I'm validating now. The `TyVar`/`TcTyVar` story is not great. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 22:56:18 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 22:56:18 -0000 Subject: [GHC] #11629: reify returns Dec that use ConT instead of PromotedT Message-ID: <045.3a9e8f83fc23a014023064d2c545236e@haskell.org> #11629: reify returns Dec that use ConT instead of PromotedT -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 22:56:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 22:56:41 -0000 Subject: [GHC] #11629: reify returns Dec that use ConT instead of PromotedT In-Reply-To: <045.3a9e8f83fc23a014023064d2c545236e@haskell.org> References: <045.3a9e8f83fc23a014023064d2c545236e@haskell.org> Message-ID: <060.e10f1670c5429e796669f138ffa68588@haskell.org> #11629: reify returns Dec that use ConT instead of PromotedT -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by aavogt): * Attachment "C.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 22:56:49 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 22:56:49 -0000 Subject: [GHC] #11629: reify returns Dec that use ConT instead of PromotedT In-Reply-To: <045.3a9e8f83fc23a014023064d2c545236e@haskell.org> References: <045.3a9e8f83fc23a014023064d2c545236e@haskell.org> Message-ID: <060.39bf30f322a29570799f066f621799fd@haskell.org> #11629: reify returns Dec that use ConT instead of PromotedT -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by aavogt): * Attachment "Main.hs" added. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 22 23:17:25 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 22 Feb 2016 23:17:25 -0000 Subject: [GHC] #11629: reify returns Dec that use ConT instead of PromotedT In-Reply-To: <045.3a9e8f83fc23a014023064d2c545236e@haskell.org> References: <045.3a9e8f83fc23a014023064d2c545236e@haskell.org> Message-ID: <060.256101b68a7526c8b242f5ad6fd6a98b@haskell.org> #11629: reify returns Dec that use ConT instead of PromotedT -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.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 aavogt): running Main.hs leads to output: {{{ reify uses ConT True AppT (ConT C.C) (ConT GHC.Types.False) AppT (ConT C.C) (ConT GHC.Types.True) oxford brackets use PromotedT AppT (ConT C.C) (PromotedT GHC.Types.True) }}} The output should be: {{{ reify uses ConT True AppT (ConT C.C) (PromotedT GHC.Types.False) AppT (ConT C.C) (PromotedT GHC.Types.True) oxford brackets use PromotedT AppT (ConT C.C) (PromotedT GHC.Types.True) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 00:01:08 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 00:01:08 -0000 Subject: [GHC] #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` In-Reply-To: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> References: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> Message-ID: <057.47fe9873a21b07c23a35098a1bb39865@haskell.org> #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 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 simonpj): * owner: goldfire => simonpj Comment: Actually there's a better way. Anyway I'm on this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 01:10:16 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 01:10:16 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.c047a265575e549ef56026e047da0c9c@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910, #8224 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by kazu-yamamoto): FYI: http://www.yesodweb.com/blog/2014/02/new-warp -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 01:56:38 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 01:56:38 -0000 Subject: [GHC] #11630: More precise LANGUAGE pragma when forall is used Message-ID: <045.22a59df4966bdaf17511666fc5bde70a@haskell.org> #11630: More precise LANGUAGE pragma when forall is used -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 8.1 (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: -------------------------------------+------------------------------------- In all cases when a user attempts to use the `forall` keyword, GHC suggests enabling `RankNTypes`. This seems suboptimal, since a more direct way to enable just the syntax is `ExplicitForAll`. So maybe we should just suggest that instead. In some cases, the user will immediately thereafter have to add `RankNTypes`, or `Rank2Types`, or `ExistentialQuantification`, etc. So it would be more user friendly to suggest the appropriate extension directly. I don't know how much harder this would be to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 02:31:58 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 02:31:58 -0000 Subject: [GHC] #10691: certain operations in new integer-gmp are too lazy In-Reply-To: <047.5a091b0736d5db136f703c98736ac583@haskell.org> References: <047.5a091b0736d5db136f703c98736ac583@haskell.org> Message-ID: <062.11152dc2e1fb0584cd1f41211a324f0f@haskell.org> #10691: certain operations in new integer-gmp are too lazy -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.10.1 (other) | 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): This is indeed quite surprising, and breaks my own intuition about performance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 09:04:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 09:04:25 -0000 Subject: [GHC] #5654: Profiling semantics bug In-Reply-To: <047.ac296d247951e42a341a674c3c07d355@haskell.org> References: <047.ac296d247951e42a341a674c3c07d355@haskell.org> Message-ID: <062.9a6fbad5f70badd3e5a80564cc092574@haskell.org> #5654: Profiling semantics bug -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Profiling | Version: 7.2.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | profiling/should_run/scc004 Blocked By: | Blocking: Related Tickets: #10007 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): Fixed, sorry about that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 09:35:55 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 09:35:55 -0000 Subject: [GHC] #11429: Make unrecognised `-W` flags a warning rather than an error In-Reply-To: <042.40e6ba51faf91f5384d7881fa490aec2@haskell.org> References: <042.40e6ba51faf91f5384d7881fa490aec2@haskell.org> Message-ID: <057.85838723fa771d2c4ecf9b39e9466451@haskell.org> #11429: Make unrecognised `-W` flags a warning rather than an error -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1830, Wiki Page: Design/Warnings | Phab:D1942 -------------------------------------+------------------------------------- Changes (by hvr): * owner: bgamari => * status: closed => new * differential: Phab:D1830 => Phab:D1830, Phab:D1942 * resolution: fixed => Comment: See Phab:D1492 for extending this warning to `-f(no-)warn-*` flags as well -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 10:55:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 10:55:10 -0000 Subject: [GHC] #11631: Delete Windows line endings from testsuite files Message-ID: <045.8492becc3679f262ada10d15b1971fb2@haskell.org> #11631: Delete Windows line endings from testsuite files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- They bothered me one time too many, so I deleted them. Patches can be merged to ghc-8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 11:26:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 11:26:59 -0000 Subject: [GHC] #11631: Delete Windows line endings from testsuite files In-Reply-To: <045.8492becc3679f262ada10d15b1971fb2@haskell.org> References: <045.8492becc3679f262ada10d15b1971fb2@haskell.org> Message-ID: <060.0163e9e4c67a114a87fa03ba27594c86@haskell.org> #11631: Delete Windows line endings from testsuite files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"31c312ebd29a4e79c166ad5dbbd5b57b42b6fafa/ghc" 31c312e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="31c312ebd29a4e79c166ad5dbbd5b57b42b6fafa" Testsuite: delete Windows line endings [skip ci] (#11631) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 11:26:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 11:26:59 -0000 Subject: [GHC] #11631: Delete Windows line endings from testsuite files In-Reply-To: <045.8492becc3679f262ada10d15b1971fb2@haskell.org> References: <045.8492becc3679f262ada10d15b1971fb2@haskell.org> Message-ID: <060.77b07eb5100fbc974cc90b87cae40def@haskell.org> #11631: Delete Windows line endings from testsuite files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"8626ac91a3cac028bbe742f07a1ce9fb598589f6/ghc" 8626ac9/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8626ac91a3cac028bbe742f07a1ce9fb598589f6" Testsuite: delete Windows line endings [skip ci] (#11631) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 11:26:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 11:26:59 -0000 Subject: [GHC] #11631: Delete Windows line endings from testsuite files In-Reply-To: <045.8492becc3679f262ada10d15b1971fb2@haskell.org> References: <045.8492becc3679f262ada10d15b1971fb2@haskell.org> Message-ID: <060.a6e2d8ef265b29341046a2b16aa815f4@haskell.org> #11631: Delete Windows line endings from testsuite files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"754a2f2bb7416bd7fe453ba7bcb7c089f5ef3b8f/ghc" 754a2f2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="754a2f2bb7416bd7fe453ba7bcb7c089f5ef3b8f" Testsuite: delete Windows line endings [skip ci] (#11631) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 11:26:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 11:26:59 -0000 Subject: [GHC] #11631: Delete Windows line endings from testsuite files In-Reply-To: <045.8492becc3679f262ada10d15b1971fb2@haskell.org> References: <045.8492becc3679f262ada10d15b1971fb2@haskell.org> Message-ID: <060.318972a8ff82bcba0100fdb8dcb82346@haskell.org> #11631: Delete Windows line endings from testsuite files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"6074c108b66ec9cd2230852addb60782a8b17e0a/ghc" 6074c108/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6074c108b66ec9cd2230852addb60782a8b17e0a" Testsuite: delete Windows line endings [skip ci] (#11631) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 11:26:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 11:26:59 -0000 Subject: [GHC] #11631: Delete Windows line endings from testsuite files In-Reply-To: <045.8492becc3679f262ada10d15b1971fb2@haskell.org> References: <045.8492becc3679f262ada10d15b1971fb2@haskell.org> Message-ID: <060.6d3392f59db0226cbe8e6d2a0abea55f@haskell.org> #11631: Delete Windows line endings from testsuite files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"d5e8b3940e8f190e9ad94e044014162bcb808c3a/ghc" d5e8b394/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d5e8b3940e8f190e9ad94e044014162bcb808c3a" Testsuite: delete Windows line endings [skip ci] (#11631) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 11:26:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 11:26:59 -0000 Subject: [GHC] #11631: Delete Windows line endings from testsuite files In-Reply-To: <045.8492becc3679f262ada10d15b1971fb2@haskell.org> References: <045.8492becc3679f262ada10d15b1971fb2@haskell.org> Message-ID: <060.bae42a459be19ed93044811e462101c9@haskell.org> #11631: Delete Windows line endings from testsuite files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"42f06f6821a221b88d67b0adc110eea78c159d7f/ghc" 42f06f6/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="42f06f6821a221b88d67b0adc110eea78c159d7f" Testsuite: accept output without Windows line endings (#11631) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 11:26:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 11:26:59 -0000 Subject: [GHC] #11631: Delete Windows line endings from testsuite files In-Reply-To: <045.8492becc3679f262ada10d15b1971fb2@haskell.org> References: <045.8492becc3679f262ada10d15b1971fb2@haskell.org> Message-ID: <060.0dcd1fb65626f51afd297adabbe782c7@haskell.org> #11631: Delete Windows line endings from testsuite files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"28620ba6a7968ef3ab589f62ac761fffe4f42caa/ghc" 28620ba/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="28620ba6a7968ef3ab589f62ac761fffe4f42caa" Testsuite: delete Windows line endings [skip ci] (#11631) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 11:26:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 11:26:59 -0000 Subject: [GHC] #11631: Delete Windows line endings from testsuite files In-Reply-To: <045.8492becc3679f262ada10d15b1971fb2@haskell.org> References: <045.8492becc3679f262ada10d15b1971fb2@haskell.org> Message-ID: <060.0be55a3092370ff69377ca700d7e6e46@haskell.org> #11631: Delete Windows line endings from testsuite files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"978c3ea14a4fb9be577fe64e1e6b724a44f332a8/ghc" 978c3ea/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="978c3ea14a4fb9be577fe64e1e6b724a44f332a8" Testsuite: accept output without Windows line endings (#11631) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 11:26:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 11:26:59 -0000 Subject: [GHC] #11631: Delete Windows line endings from testsuite files In-Reply-To: <045.8492becc3679f262ada10d15b1971fb2@haskell.org> References: <045.8492becc3679f262ada10d15b1971fb2@haskell.org> Message-ID: <060.b4349fa76093e8114b3f0bf2e56caa3d@haskell.org> #11631: Delete Windows line endings from testsuite files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"6d0aa9ffc094ec69f1fbd7f9e15bcf7535e3370b/ghc" 6d0aa9ff/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6d0aa9ffc094ec69f1fbd7f9e15bcf7535e3370b" Testsuite: delete Windows line endings [skip ci] (#11631) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 11:26:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 11:26:59 -0000 Subject: [GHC] #11521: Test failures for the `profasm` way when BUILD_PROF_LIBS=YES In-Reply-To: <045.daf56e9bd8ee4ad19ba9daea05cb163a@haskell.org> References: <045.daf56e9bd8ee4ad19ba9daea05cb163a@haskell.org> Message-ID: <060.8f9508bda2473dcbd782be7f17963d8d@haskell.org> #11521: Test failures for the `profasm` way when BUILD_PROF_LIBS=YES -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"176be87cb28f675d87ea8f5c07eaef7ca47ff8de/ghc" 176be87c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="176be87cb28f675d87ea8f5c07eaef7ca47ff8de" Filter out -prof callstacks from test output (#11521) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 11:26:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 11:26:59 -0000 Subject: [GHC] #10037: Several profiling tests give different results optimised vs. unoptimised In-Reply-To: <047.efcb9e013309246f2cfca887b5137899@haskell.org> References: <047.efcb9e013309246f2cfca887b5137899@haskell.org> Message-ID: <062.7ee7ae42d13a26cd3096a3e91d46b492@haskell.org> #10037: Several profiling tests give different results optimised vs. unoptimised -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"661aa07ed1b133a5ba1ae90525115f8aca0ac92b/ghc" 661aa07e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="661aa07ed1b133a5ba1ae90525115f8aca0ac92b" Testsuite: failing profiling tests (#10037) These tests fail not only for WAY=prof, but also for WAY=profllvm. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 11:26:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 11:26:59 -0000 Subject: [GHC] #11521: Test failures for the `profasm` way when BUILD_PROF_LIBS=YES In-Reply-To: <045.daf56e9bd8ee4ad19ba9daea05cb163a@haskell.org> References: <045.daf56e9bd8ee4ad19ba9daea05cb163a@haskell.org> Message-ID: <060.232664628848d2f51d0df4ee5bb83ea2@haskell.org> #11521: Test failures for the `profasm` way when BUILD_PROF_LIBS=YES -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"73e409555019d370f3644bdf02b37dd526de4d8a/ghc" 73e4095/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="73e409555019d370f3644bdf02b37dd526de4d8a" Testsuite: cleanup profiling/should_run/all.T (#11521) Refactoring only. I compared before and after with 'make slow', and it still runs each test with the same 'ways' as before. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 11:26:59 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 11:26:59 -0000 Subject: [GHC] #7650: can't use combining characters in identifiers In-Reply-To: <044.4fb0377eab552e230ee53da0d70baa3c@haskell.org> References: <044.4fb0377eab552e230ee53da0d70baa3c@haskell.org> Message-ID: <059.8fff148e4567fd138a1e0b58bc846164@haskell.org> #7650: can't use combining characters in identifiers -------------------------------------+------------------------------------- Reporter: guest | Owner: thomie Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.2 (Parser) | Resolution: | Keywords: unicode Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1938 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"2aee41960aa00fe09a2cd1983e02c15e06013037/ghc" 2aee419/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2aee41960aa00fe09a2cd1983e02c15e06013037" Allow combining characters in identifiers (#7650) Reviewed by: austin, rwbarton Differential Revision: https://phabricator.haskell.org/D1938 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 11:34:14 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 11:34:14 -0000 Subject: [GHC] #11521: Test failures for the `profasm` way when BUILD_PROF_LIBS=YES In-Reply-To: <045.daf56e9bd8ee4ad19ba9daea05cb163a@haskell.org> References: <045.daf56e9bd8ee4ad19ba9daea05cb163a@haskell.org> Message-ID: <060.79aa1fef83a328f5c6fb58268c49fc51@haskell.org> #11521: Test failures for the `profasm` way when BUILD_PROF_LIBS=YES -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Test Suite | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => merge * milestone: => 8.0.1 Comment: Not quite done yet (still some failing prof tests), but this is a start. To merge 73e409555019d370f3644bdf02b37dd526de4d8a to ghc-8.0, you first need 85daac593c498f581d46f44982ee5dcf1001f611 (#5654). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 11:37:16 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 11:37:16 -0000 Subject: [GHC] #7650: can't use combining characters in identifiers In-Reply-To: <044.4fb0377eab552e230ee53da0d70baa3c@haskell.org> References: <044.4fb0377eab552e230ee53da0d70baa3c@haskell.org> Message-ID: <059.83679621b8fa35a8ed5d378c5d61e3e5@haskell.org> #7650: can't use combining characters in identifiers -------------------------------------+------------------------------------- Reporter: guest | Owner: thomie Type: feature request | Status: closed Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.6.2 (Parser) | Resolution: fixed | Keywords: unicode Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1938 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * type: bug => feature request * resolution: => fixed * milestone: => 8.2.1 Comment: I guess this is a feature, so don't merge to 8.0. See #11609 for documentation (todo). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 11:38:15 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 11:38:15 -0000 Subject: [GHC] #11609: Document unicode report deviations In-Reply-To: <045.cbd707829d3c6ec2d018040f978ed6b1@haskell.org> References: <045.cbd707829d3c6ec2d018040f978ed6b1@haskell.org> Message-ID: <060.594b98872d4c37fd7b962c92dba5287a@haskell.org> #11609: Document unicode report deviations -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 Resolution: | Keywords: unicode, | report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1103, #4373, | Differential Rev(s): #7650, #10196, #11012 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: #1103, #4373, #10196, #11012 => #1103, #4373, #7650, #10196, #11012 @@ -16,2 +16,3 @@ - * `ModifierLetter` (#10196) and `OtherNumber` (#4373) are allowed in - identifiers, but only starting from the second character. + * `ModifierLetter` (#10196), `OtherNumber` (#4373) and `NonSpacingMark` + (#7650) are allowed in identifiers, but only starting from the second + character. New description: @nomeata mentions in #10196: The report specifies ?Haskell compilers are expected to make use of new versions of Unicode as they are made available.? So if we deviate from that, we should make sure that * the user?s guide explicitly lists all deviations from the report [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/bugs-and- infelicities.html#infelicities-lexical in this section], and * that the Haskell prime committee is going to be aware of these (sensible) deviations, so that they can become official. Certain deviations are (there might be more): * `OtherLetter` are treated as lowercase (#1103), and thus allowed in identifiers. * `ModifierLetter` (#10196), `OtherNumber` (#4373) and `NonSpacingMark` (#7650) are allowed in identifiers, but only starting from the second character. * `$decdigit = $ascdigit -- for now, should really be $digit (ToDo)` (see compiler/parser/Lexer.x) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 12:08:10 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 12:08:10 -0000 Subject: [GHC] #11609: Document unicode report deviations In-Reply-To: <045.cbd707829d3c6ec2d018040f978ed6b1@haskell.org> References: <045.cbd707829d3c6ec2d018040f978ed6b1@haskell.org> Message-ID: <060.d3f7a54fb2c69ee203cf188dbdd76510@haskell.org> #11609: Document unicode report deviations -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 Resolution: | Keywords: unicode, | report-impact Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #1103, #4373, | Differential Rev(s): #7650, #10196, #11012 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Oh, I was going to comment on the subject of documentation, so I'll do it here. We should have a changelog entry about allowing combining characters in identifiers; and we should be clear about what kind of normalization we do to decide when a sequence involving combining characters is considered the same as a precomposed sequence. (I assume the answer is currently "none", but it would probably be nice to change that for 8.2. NFC normalization seems to be a popular choice for programming languages.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 12:11:01 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 12:11:01 -0000 Subject: [GHC] #10752: Print which warning-flag controls/enabled an emitted warning In-Reply-To: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> References: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> Message-ID: <057.2faae1af84f4e9011c8449d52437ebcd@haskell.org> #10752: Print which warning-flag controls/enabled an emitted warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: barrucadu Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1943 Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Changes (by barrucadu): * differential: Phab:D1934 => Phab:D1943 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 12:11:40 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 12:11:40 -0000 Subject: [GHC] #11631: Delete Windows line endings from testsuite files In-Reply-To: <045.8492becc3679f262ada10d15b1971fb2@haskell.org> References: <045.8492becc3679f262ada10d15b1971fb2@haskell.org> Message-ID: <060.44c6fa0ea4eebf40fbb1df4a8cef1249@haskell.org> #11631: Delete Windows line endings from testsuite files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * status: new => merge Comment: The commits don't include any changes that conflict with the 8.0 branch. `git cherry-pick 31c312e 8626ac9 754a2f2 6074c108 d5e8b394 978c3ea 42f06f6 28620ba 6d0aa9ff` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 15:28:25 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 15:28:25 -0000 Subject: [GHC] #10840: Periodic alarm signals can cause a retry loop to get stuck In-Reply-To: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> References: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> Message-ID: <064.7879782d46d13babcf649ee595121cdc@haskell.org> #10840: Periodic alarm signals can cause a retry loop to get stuck -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 hsyl20): On Mac OS, you can try to enable USE_PTHREAD_FOR_ITIMER in rts/posix/Itimer.c to make the RTS avoid using alarm signals. Maybe we should make it a flag (or the default) for the threaded RTS? On Linux the same problem may occur. We can use the same solution and even improve it by using the timerfd_* syscalls instead of usleep (cf the following attachment). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 15:29:04 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 15:29:04 -0000 Subject: [GHC] #10840: Periodic alarm signals can cause a retry loop to get stuck In-Reply-To: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> References: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> Message-ID: <064.f109686bd3790c0ef2ad7b50b46783c0@haskell.org> #10840: Periodic alarm signals can cause a retry loop to get stuck -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hsyl20): * Attachment "0001-rts-timer-use-timerfd_-on-Linux-instead-of- signals.patch" added. Make the RTS use timerfd_* on Linux -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 15:51:28 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 15:51:28 -0000 Subject: [GHC] #11407: -XTypeInType uses up all memory when used in data family instance In-Reply-To: <050.503f410a2cdf5d269f1863841d6a706e@haskell.org> References: <050.503f410a2cdf5d269f1863841d6a706e@haskell.org> Message-ID: <065.58c56dd7db18e90048c18391c46e3ff3@haskell.org> #11407: -XTypeInType uses up all memory when used in data family instance -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Keywords: TypeInType, Resolution: | TypeFamilies Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Hmm, on `master` this merely results in a stack overflow, not that this is much of an improvement. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 19:46:03 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 19:46:03 -0000 Subject: [GHC] #11569: make -j24 test In-Reply-To: <043.ebd4ab4cf2b889476fd8b09d162a3605@haskell.org> References: <043.ebd4ab4cf2b889476fd8b09d162a3605@haskell.org> Message-ID: <058.acc0799ab6f49ae5daf6308a203f2823@haskell.org> #11569: make -j24 test -------------------------------+------------------------------- Reporter: mfox | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.2.1 Component: Test Suite | Version: 8.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+------------------------------- Comment (by Thomas Miedema ): In [changeset:"a3e0e9365e4f195d5dad9389955869744f2cdba9/ghc" a3e0e936/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="a3e0e9365e4f195d5dad9389955869744f2cdba9" Testsuite: MAKEFLAGS is magic, do not unexport it Call `+$(PYTHON) ...` to fix #11569 instead. See Note [Communicating options and variables to a submake]. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 20:43:11 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 20:43:11 -0000 Subject: [GHC] #11140: add command-line option to GHC to dump raw parse trees of Haskell programs In-Reply-To: <044.9ca7a94e52e643694da7336bc4c35d24@haskell.org> References: <044.9ca7a94e52e643694da7336bc4c35d24@haskell.org> Message-ID: <059.4bf167a034d1abd04daa0b3a903c16c0@haskell.org> #11140: add command-line option to GHC to dump raw parse trees of Haskell programs -------------------------------------+------------------------------------- Reporter: bollu | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | 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 alanz): * cc: alanz (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 21:28:06 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 21:28:06 -0000 Subject: =?utf-8?q?=5BGHC=5D_=2311632=3A_Data=2EChar_repeated_readLitChar?= =?utf-8?q?_barfs_on_output_from_show_=22=C3=B31=22?= Message-ID: <049.9bf2436e7fb9c211d83d1b0ba3c6ee23@haskell.org> #11632: Data.Char repeated readLitChar barfs on output from show "?1" -------------------------------------+------------------------------------- Reporter: inversemot | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.3 libraries/base | Keywords: | Operating System: Linux Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- "?1" is "\243\&1" and when shown that's "\"\\243\\&1\"" {{{#!hs readLitChar "\"\\243\\&1\"" = [("\"", "\243\\&1")] readLitChar "\243\\&1" = [("\243", "\\&1")] --should have consumed "\\&" readLitChar "\\&1" = [] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 21:29:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 21:29:02 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2311632=3A_Data=2EChar_repeated_readL?= =?utf-8?q?itChar_barfs_on_output_from_show_=22=C3=B31=22?= In-Reply-To: <049.9bf2436e7fb9c211d83d1b0ba3c6ee23@haskell.org> References: <049.9bf2436e7fb9c211d83d1b0ba3c6ee23@haskell.org> Message-ID: <064.0daaeb95d2ca8e33951116229bc3d39c@haskell.org> #11632: Data.Char repeated readLitChar barfs on output from show "?1" -------------------------------------+------------------------------------- Reporter: inversemot | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by inversemot: @@ -1,1 +1,1 @@ - "?1" is "\243\&1" and when shown that's "\"\\243\\&1\"" + "?1" is "\243\&1" and when shown that's `"\"\\243\\&1\""` New description: "?1" is "\243\&1" and when shown that's `"\"\\243\\&1\""` {{{#!hs readLitChar "\"\\243\\&1\"" = [("\"", "\243\\&1")] readLitChar "\243\\&1" = [("\243", "\\&1")] --should have consumed "\\&" readLitChar "\\&1" = [] }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 22:00:19 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 22:00:19 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMTYzMjogcmVhZCAoc2hvdyAiw7MxIikgZmFp?= =?utf-8?q?ls_=28was=3A_Data=2EChar_repeated_readLitChar_barfs_on?= =?utf-8?b?IG91dHB1dCBmcm9tIHNob3cgIsOzMSIp?= In-Reply-To: <049.9bf2436e7fb9c211d83d1b0ba3c6ee23@haskell.org> References: <049.9bf2436e7fb9c211d83d1b0ba3c6ee23@haskell.org> Message-ID: <064.e9ec546bef437a975590200b42042421@haskell.org> #11632: read (show "?1") fails -------------------------------------+------------------------------------- Reporter: inversemot | Owner: Type: bug | Status: new Priority: high | Milestone: Component: libraries/base | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * priority: normal => high @@ -0,0 +1,5 @@ + {{{ + Prelude> let s = "?1" in read (show s) + *** Exception: Prelude.read: no parse + }}} + @@ -4,3 +9,4 @@ - readLitChar "\"\\243\\&1\"" = [("\"", "\243\\&1")] - readLitChar "\243\\&1" = [("\243", "\\&1")] --should have consumed "\\&" - readLitChar "\\&1" = [] + readLitChar "\"\\243\\&1\"" = [('"', "\\243\\&1\"")] + readLitChar "\\243\\&1\"" = [('\243', "\\&1\"")] --should have consumed + "\\&" + readLitChar "\\&1\"" = [] New description: {{{ Prelude> let s = "?1" in read (show s) *** Exception: Prelude.read: no parse }}} "?1" is "\243\&1" and when shown that's `"\"\\243\\&1\""` {{{#!hs readLitChar "\"\\243\\&1\"" = [('"', "\\243\\&1\"")] readLitChar "\\243\\&1\"" = [('\243', "\\&1\"")] --should have consumed "\\&" readLitChar "\\&1\"" = [] }}} -- Comment: Thanks for the report. I fixed some errors in the ticket description, hope this is what you meant. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 22:02:39 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 22:02:39 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2311632=3A_Data=2EChar_repeated_readL?= =?utf-8?q?itChar_barfs_on_output_from_show_=22=C3=B31=22_=28was?= =?utf-8?b?OiByZWFkIChzaG93ICLDszEiKSBmYWlscyk=?= In-Reply-To: <049.9bf2436e7fb9c211d83d1b0ba3c6ee23@haskell.org> References: <049.9bf2436e7fb9c211d83d1b0ba3c6ee23@haskell.org> Message-ID: <064.399759df0efe3df249b3603f51d01cc3@haskell.org> #11632: Data.Char repeated readLitChar barfs on output from show "?1" -------------------------------------+------------------------------------- Reporter: inversemot | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by rwbarton): * priority: high => normal @@ -1,5 +1,0 @@ - {{{ - Prelude> let s = "?1" in read (show s) - *** Exception: Prelude.read: no parse - }}} - New description: "?1" is "\243\&1" and when shown that's `"\"\\243\\&1\""` {{{#!hs readLitChar "\"\\243\\&1\"" = [('"', "\\243\\&1\"")] readLitChar "\\243\\&1\"" = [('\243', "\\&1\"")] --should have consumed "\\&" readLitChar "\\&1\"" = [] }}} -- Comment: Wait no, I'm wrong. `read (show "?1")` works fine, I just forgot to ask for a string. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 22:06:00 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 22:06:00 -0000 Subject: [GHC] #11583: Make warning names more consistent In-Reply-To: <046.2c5f65cdcdffbe526873fdbd4a154741@haskell.org> References: <046.2c5f65cdcdffbe526873fdbd4a154741@haskell.org> Message-ID: <061.c20de83162fb58c1cdd81a23cec1d90f@haskell.org> #11583: Make warning names more consistent -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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:D1939 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 22:37:18 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 22:37:18 -0000 Subject: [GHC] #8710: Overlapping patterns warning misplaced In-Reply-To: <047.1f227e0dac37dd7309646386f280164b@haskell.org> References: <047.1f227e0dac37dd7309646386f280164b@haskell.org> Message-ID: <062.371764444e9bbbc7d2c40af510e023e9@haskell.org> #8710: Overlapping patterns warning misplaced -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1910, Wiki Page: | Phab:D1920 -------------------------------------+------------------------------------- Comment (by bgamari): So to be clear, I believe that given a function with redundant patterns, {{{#!hs module Bug where hello _ = "world" hello 1 = "turtle" hello 2 = "frog" }}} Phab:D1910 will provide a warning like, {{{ Bug.hs:3:1: Warning: Pattern match(es) are overlapped In an equation for ?hello?: hello 1 = ... hello 2 = ... }}} whereas Phab:D1920 will provide, {{{ Bug.hs:3:1: Warning: Pattern match is overlapped In an equation for ?hello?: hello 1 = ... Bug.hs:4:1: Warning: Pattern match is overlapped In an equation for ?hello?: hello 2 = ... }}} Is this right George? The former seems more user friendly to me -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 22:50:02 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 22:50:02 -0000 Subject: [GHC] #8710: Overlapping patterns warning misplaced In-Reply-To: <047.1f227e0dac37dd7309646386f280164b@haskell.org> References: <047.1f227e0dac37dd7309646386f280164b@haskell.org> Message-ID: <062.621981080df98cd9b38957e8f56b79b0@haskell.org> #8710: Overlapping patterns warning misplaced -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1910, Wiki Page: | Phab:D1920 -------------------------------------+------------------------------------- Comment (by simonpj): I prefer the latter. It's rare for more than one to be overlapped, and when there is I'd like to find my way quickly to the correct source line for each. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 22:50:53 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 22:50:53 -0000 Subject: [GHC] #8710: Overlapping patterns warning misplaced In-Reply-To: <047.1f227e0dac37dd7309646386f280164b@haskell.org> References: <047.1f227e0dac37dd7309646386f280164b@haskell.org> Message-ID: <062.8d36539b8c4bc7a788c9136816eb465e@haskell.org> #8710: Overlapping patterns warning misplaced -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1910, Wiki Page: | Phab:D1920 -------------------------------------+------------------------------------- Comment (by gkaracha): Replying to [comment:13 bgamari]: Phab:D1910 will actually provide the following: {{{ Bug.hs:3:1: Warning: Pattern match(es) are overlapped In an equation for ?hello?: hello 1 = ... (at Bug.hs:3:1) hello 2 = ... (at Bug.hs:4:1) }}} , since there are two redundant clauses. If there was just one it would omit the (at )-part. From Phab:D1920, we will indeed get the warnings you mentioned. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 22:51:42 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 22:51:42 -0000 Subject: [GHC] #11429: Make unrecognised `-W` flags a warning rather than an error In-Reply-To: <042.40e6ba51faf91f5384d7881fa490aec2@haskell.org> References: <042.40e6ba51faf91f5384d7881fa490aec2@haskell.org> Message-ID: <057.8a74045a1659cbd8fa2a3fb5f3949286@haskell.org> #11429: Make unrecognised `-W` flags a warning rather than an error -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1830, Wiki Page: Design/Warnings | Phab:D1942 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"32a9a7f514bdd33ff72a673ade2591e4e815be58/ghc" 32a9a7f5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="32a9a7f514bdd33ff72a673ade2591e4e815be58" Extend `-Wunrecognised-warning-flag` to cover `-f(no-)warn-*` The original implementation for #11429 covers only `-W*` flags. However, old packages will continue to use `-f(no-)warn-*` flags, so it seems desirable to have `-Wunrecognised-warning-flag` apply to those legacy aliases as well. Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1942 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Feb 23 22:56:35 2016 From: ghc-devs at haskell.org (GHC) Date: Tue, 23 Feb 2016 22:56:35 -0000 Subject: [GHC] #8710: Overlapping patterns warning misplaced In-Reply-To: <047.1f227e0dac37dd7309646386f280164b@haskell.org> References: <047.1f227e0dac37dd7309646386f280164b@haskell.org> Message-ID: <062.9b8cf4e1e1d38a13ec53e9a36de13dfd@haskell.org> #8710: Overlapping patterns warning misplaced -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1910, Wiki Page: | Phab:D1920 -------------------------------------+------------------------------------- Comment (by simonpj): I vote for 1920. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 08:45:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 08:45:38 -0000 Subject: [GHC] #11574: schedule: re-entered unsafely on minimal hello world program on arm In-Reply-To: <051.5f65ae7b7de5c2aba500f9eaf01974c1@haskell.org> References: <051.5f65ae7b7de5c2aba500f9eaf01974c1@haskell.org> Message-ID: <066.20d1412093aadf1acb4f25ae650c3c8d@haskell.org> #11574: schedule: re-entered unsafely on minimal hello world program on arm ----------------------------------+---------------------------------- Reporter: andrewufrank | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ----------------------------------+---------------------------------- Comment (by andrewufrank): i did move the bin files into my path (~/.bin which is in $PATH) but do not see a difference. same issue. i assume i had to install ghc anew and tried to install with apt-get install from jessie backports, but no change. how to i install ghc to use the llvm that i have downloaded? (sorry - building ghc is not my regular thing, i need some more instructions). thank you! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 09:02:25 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 09:02:25 -0000 Subject: [GHC] #10840: Periodic alarm signals can cause a retry loop to get stuck In-Reply-To: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> References: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> Message-ID: <064.d18ab1e37ed0243c11c244aee9df43c2@haskell.org> #10840: Periodic alarm signals can cause a retry loop to get stuck -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 simonmar): I like this patch a lot, those signals have been causing problems for a long time. Want to put it on Phabricator so we can review and get it in? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 09:17:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 09:17:51 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.f3591bac07422140d4e61deeff3c1b0c@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I've put up some notes collected from the course of my implementation [[https://ghc.haskell.org/trac/ghc/wiki/Typeable/BenGamari|here]]. At the moment I am struggling to find a design for serialization (or, more specifically, deserialization). The current scheme is described in this [[https://ghc.haskell.org/trac/ghc/wiki/Typeable/BenGamari#Deserialization|section]], although the need for `unsafeCoerce` is worrying. I'd love to hear what others have to say about this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 10:56:51 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 10:56:51 -0000 Subject: [GHC] #11633: Record field order in a bidirectional pattern synonym match is order dependent Message-ID: <046.0c4427b2dcf79f3f6a57a5376b7a4d59@haskell.org> #11633: Record field order in a bidirectional pattern synonym match is order dependent -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.3 (Type checker) | Keywords: | Operating System: Unknown/Multiple PatternSynonyms | Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this example, {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Test where data ARecord = ARecord {anInt :: Int, aString :: String} -- This works... pattern AGoodPat :: Int -> String -> ARecord pattern AGoodPat n s = ARecord {anInt=n, aString=s} -- But if we invert the order of the fields things break... pattern ABadPat :: Int -> String -> ARecord pattern ABadPat n s = ARecord {aString=s, anInt=n} }}} Despite the fact that `AGoodPat` and `ABadPat` differ only in the order of the fields in their matches, `ABadPat` fails to typecheck with, {{{ Test.hs:12:40: error: ? Couldn't match type ?[Char]? with ?Int? Expected type: Int Actual type: String ? In the first argument of ?ARecord?, namely ?s? In the expression: ARecord s n In an equation for ?$bABadPat?: $bABadPat n s = ARecord s n Test.hs:12:49: error: ? Couldn't match type ?Int? with ?[Char]? Expected type: String Actual type: Int ? In the second argument of ?ARecord?, namely ?n? In the expression: ARecord s n In an equation for ?$bABadPat?: $bABadPat n s = ARecord s n }}} This can be observed with both 7.10.3 and `master`. If one makes `ABadPat` into a one-directional pattern then the error vanishes. The fact that field order matters in the case of bi-directional record pattern synonyms seems a bit odd. If there's a good reason why this must be the case then fair enough, but we should make sure this is mentioned in the users guide and provide a more helpful error message. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 12:04:20 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 12:04:20 -0000 Subject: [GHC] #11633: Record field order in a bidirectional pattern synonym match is order dependent In-Reply-To: <046.0c4427b2dcf79f3f6a57a5376b7a4d59@haskell.org> References: <046.0c4427b2dcf79f3f6a57a5376b7a4d59@haskell.org> Message-ID: <061.128524ee6ba1cc6db7123c1a187e9e67@haskell.org> #11633: Record field order in a bidirectional pattern synonym match is order dependent -------------------------------------+------------------------------------- Reporter: bgamari | Owner: mpickering Type: bug | Status: new Priority: high | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * owner: => mpickering Comment: This is a bug which looks easy to fix but I wonder whether doing some restructuring would help prevent bugs like this in future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 12:09:00 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 12:09:00 -0000 Subject: [GHC] #10840: Periodic alarm signals can cause a retry loop to get stuck In-Reply-To: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> References: <049.c792fb7fbab25e12997f6231b1f3472d@haskell.org> Message-ID: <064.973b6eaddc75907a15fbc110b737e0bd@haskell.org> #10840: Periodic alarm signals can cause a retry loop to get stuck -------------------------------------+------------------------------------- Reporter: Rufflewind | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 hsyl20): Done: https://phabricator.haskell.org/D1947 A potential issue is that these syscalls have been introduced in 2.6.25. Do we want to support older kernels? The issue remains for Mac OS X. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 12:34:36 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 12:34:36 -0000 Subject: [GHC] #11634: Bang patterns bind... unexpectedly. Deserves loud warning Message-ID: <046.c476185b8deeaab965f0dca5d519ed3d@haskell.org> #11634: Bang patterns bind... unexpectedly. Deserves loud warning -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider the following, {{{#!hs {-# LANGUAGE BangPatterns #-} hello :: [Int] -> () hello (!x:xs) = ... }}} To me it seems like the bang pattern should be applied to `x`; but it's not! In fact, this program is equivalent to, {{{#!hs hello (!(x:xs)) = ... }}} This strikes me as quite surprising, yet there is no mention of how `!` is supposed to bind in the [[http://downloads.haskell.org/~ghc/master/users- guide//glasgow_exts.html#ghc-flag--XBangPatterns|users guide]] nor the [[https://prime.haskell.org/wiki/BangPatterns|Haskell Prime proposal]]. This behavior is slightly less surprising if you consider that the bang pattern `!Just x` is equivalent to `!(Just x)` (although this also strikes me as a bit unfortunate, although it is likely too late to do much about this). In sum: We need to document the current syntactic binding properties of `!` in the users guide. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 12:46:49 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 12:46:49 -0000 Subject: [GHC] #11635: Missleading error message when using polymorpic kinds Message-ID: <045.6b11e0ecfa17cf92f6e3c3787bd24cd0@haskell.org> #11635: Missleading error message when using polymorpic kinds -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Example program: {{{ {-# LANGUAGE TypeInType, KindSignatures, ExplicitForAll #-} import Data.Kind data X (a :: forall k. k -> * ) = X }}} errors with {{{ polykind.hs:3:1: error: Expecting one more argument to ?a? Expected kind ?k0?, but ?a? has kind ?forall k. k -> *? }}} Without `TypeInType`, the error is better, yet gives false hint: {{{ polykind.hs:3:23: error: Illegal kind: forall k. k -> * Did you mean to enable TypeInType? }}} --- For the record 7.10.3 doesn't recognise polymorphic kinds at all (same program, without `Data.Kind` import): {{{ polykind.hs:3:23: parse error on input ?forall? }}} Which makes me think that polymorphic kinds are somehow supported, but maybe not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 13:11:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 13:11:06 -0000 Subject: [GHC] #11634: Bang patterns bind... unexpectedly. Deserves loud warning In-Reply-To: <046.c476185b8deeaab965f0dca5d519ed3d@haskell.org> References: <046.c476185b8deeaab965f0dca5d519ed3d@haskell.org> Message-ID: <061.493880478bb714606f9808ec67b623f0@haskell.org> #11634: Bang patterns bind... unexpectedly. Deserves loud warning -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I think it would be better to make bang bind more tightly so that it behaves the way you expect. We go to some trouble to make {{{ f !x y = e }}} mean {{{ f (!x) y = e }}} so bang binds pretty tightly there. This is a purely syntactic matter. Would anyone like to tackle it? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 13:12:06 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 13:12:06 -0000 Subject: [GHC] #11635: Missleading error message when using polymorpic kinds In-Reply-To: <045.6b11e0ecfa17cf92f6e3c3787bd24cd0@haskell.org> References: <045.6b11e0ecfa17cf92f6e3c3787bd24cd0@haskell.org> Message-ID: <060.a8af13feef356a8d7b92c987b1d2388a@haskell.org> #11635: Missleading error message when using polymorpic kinds -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeInType -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 13:15:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 13:15:19 -0000 Subject: [GHC] #11635: Missleading error message when using polymorpic kinds In-Reply-To: <045.6b11e0ecfa17cf92f6e3c3787bd24cd0@haskell.org> References: <045.6b11e0ecfa17cf92f6e3c3787bd24cd0@haskell.org> Message-ID: <060.f74dcf9dfb54675ef4791f0a03342597@haskell.org> #11635: Missleading error message when using polymorpic kinds -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 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 phadej): And I found a workaround to make a code compile. It's not usable, but that's probably another issue: {{{ {-# LANGUAGE TypeInType, ImpredicativeTypes, KindSignatures, ExplicitForAll #-} import Data.Kind import Data.Proxy newtype X (a :: forall k. k -> * ) = X { x :: a Bool -> a (*) } -- X { x = \_ -> Proxy :: Proxy (*) } {- fails with: ? Couldn't match kind ?forall k1. k1 -> *? with ?forall k. k -> *? When matching the kind of ?Proxy? ? In the expression: Proxy :: Proxy * In the ?x? field of a record In the expression: X {x = \ _ -> Proxy :: Proxy *} -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 13:25:01 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 13:25:01 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.f27a68acdfd28064f4359f3ffe2df548@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think that `unsafeCoerce` is quite bad and does threaten safety of the whole system, because you can always unpack a `TypeRep` from a `TypeRepX`. But I think I may have an answer -- I have written a very partial `Read` instance in a similar setup [https://github.com/goldfirere/dependent- db/blob/master/Basics.hs here] (used to implement my job talk). That indexed `TypeRepX` by a constraint, but I don't think you need that to get this done. A big difference between my approach and the real one will be that the real one must be open (allow datatype definitions), while my setup is closed. I don't think this is so terrible, though, as we can use a class (somewhat like my `TyConAble`) that provides the ability to read in a tycon. This class could be internal, perhaps protected by a name that can't be written in Haskell. Does this get you unstuck or have I done something silly? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 13:33:07 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 13:33:07 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.d1aeaafae808a12f99e5b4cee8e37d5b@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I don't understand your proposal about how to make it open. (I agree, closed is (relatively) easy.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 14:44:04 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 14:44:04 -0000 Subject: [GHC] #11635: Higher-rank kind in datatype definition rejected (was: Missleading error message when using polymorpic kinds) In-Reply-To: <045.6b11e0ecfa17cf92f6e3c3787bd24cd0@haskell.org> References: <045.6b11e0ecfa17cf92f6e3c3787bd24cd0@haskell.org> Message-ID: <060.ac293dd01299ba5096a92d39c834a4d2@haskell.org> #11635: Higher-rank kind in datatype definition rejected -------------------------------------+------------------------------------- Reporter: phadej | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 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): * owner: => goldfire Comment: I think the original program should be accepted. I see nothing wrong with it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 15:26:26 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 15:26:26 -0000 Subject: [GHC] #8710: Overlapping patterns warning misplaced In-Reply-To: <047.1f227e0dac37dd7309646386f280164b@haskell.org> References: <047.1f227e0dac37dd7309646386f280164b@haskell.org> Message-ID: <062.edf1032a201cc908afd8b364be1de220@haskell.org> #8710: Overlapping patterns warning misplaced -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1910, Wiki Page: | Phab:D1920 -------------------------------------+------------------------------------- Comment (by thomie): I flipped a coin, and it also said 1920. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 15:55:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 15:55:42 -0000 Subject: [GHC] #8710: Overlapping patterns warning misplaced In-Reply-To: <047.1f227e0dac37dd7309646386f280164b@haskell.org> References: <047.1f227e0dac37dd7309646386f280164b@haskell.org> Message-ID: <062.249bdfdfac3e8a781ff1c605e87a9af2@haskell.org> #8710: Overlapping patterns warning misplaced -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1910, Wiki Page: | Phab:D1920 -------------------------------------+------------------------------------- Comment (by gkaracha): Replying to [comment:17 thomie]: > I flipped a coin, and it also said 1920. I am rather indifferent too about it. I agree with Ben that the shorter warning seems more user friendly, yet I think Simon is right that it is incredibly rare to have more than one redundant clause in a match (I can only imagine it happening as a copy-paste error) so I don't think it really makes a big difference. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 16:48:39 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 16:48:39 -0000 Subject: [GHC] #11636: Promoting newtype destructor Message-ID: <045.0a5eaaf72ec2e2d10e023f3eda63667e@haskell.org> #11636: Promoting newtype destructor -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: feature | Status: new request | 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: -------------------------------------+------------------------------------- given {{{ newtype LOL a = MkLOL { unLOL :: [[a]] } }}} I'd like to write {{{ type family UnLOL (lol :: LOL a) = (result :: [[a]]) | result -> lol type instance UnLOL ('MkLOL xss) = xss }}} This is currently not accepted, but AFAICS it should be injective, as `lol` is kind restricted. Especially the example in injective type families paper do not apply, as `UnLOL Int` is ill-kinded. With this GHC could infer `lol ~ MkLOL xss` from `UnLOL lol ~ xss`, so newtypes would be useful for type-level programming, as type (kind) synonyms cannot be partially applied. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 16:50:44 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 16:50:44 -0000 Subject: [GHC] #11616: Kinds aren't instantiated In-Reply-To: <051.8ecdc328e58df668fa88298bb62fc07f@haskell.org> References: <051.8ecdc328e58df668fa88298bb62fc07f@haskell.org> Message-ID: <066.3b7a976bff172ccbfb3d9409edf7c87a@haskell.org> #11616: Kinds aren't instantiated -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 17:20:00 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 17:20:00 -0000 Subject: [GHC] #11633: Record field order in a bidirectional pattern synonym match is order dependent In-Reply-To: <046.0c4427b2dcf79f3f6a57a5376b7a4d59@haskell.org> References: <046.0c4427b2dcf79f3f6a57a5376b7a4d59@haskell.org> Message-ID: <061.4492d865da75d0b6f67356ae3df83f38@haskell.org> #11633: Record field order in a bidirectional pattern synonym match is order dependent -------------------------------------+------------------------------------- Reporter: bgamari | Owner: mpickering Type: bug | Status: patch Priority: high | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: Resolution: | PatternSynonyms 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:D1949 Wiki Page: | -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch * differential: => Phab:D1949 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 17:58:42 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 17:58:42 -0000 Subject: [GHC] #11637: single-module recursion and import aliases Message-ID: <044.2eb4774959afb487f0c4bf63cdcd5d44@haskell.org> #11637: single-module recursion and import aliases -------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 put the following code in {{{Foo.hs}}}: {{{ module Foo where import Prelude (Either(..)) import {-# SOURCE #-} Foo as F not (Left x) = x not (Right x) = F.not (Left x) }}} And the following code in {{{Foo.hs-boot}}}: {{{ module Foo where import Prelude(Either) not :: Either a a -> a }}} I get the following error when trying to compile: {{{ % ghc -c Foo.hs-boot % ghc -c Foo.hs Foo.hs:5:17: Not in scope: ?F.not? zsh: exit 1 ghc -c Foo.hs }}} This surprises me, as running ghci on a slightly modified version (replacing {{{F.not (Left x)}}} with simply {{{x}}}) confirms that `not` is exported correctly; hence I believe {{{F.not}}} should indeed be in scope. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 17:59:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 17:59:34 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.46a503ce73fde417d0536339393f4d1f@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, I see your point. I guess I have indeed done something silly and that `unsafeCoerce` may be the only way forward. This means that an invalid input file could cause a segfault. But I suppose that's just the old "garbage in, garbage out" situation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 19:00:18 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 19:00:18 -0000 Subject: [GHC] #11638: referring to the existential type from a GADT pattern match with a type application Message-ID: <047.7c8b5ea224dc1a576a93e34811383394@haskell.org> #11638: referring to the existential type from a GADT pattern match with a type application -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 (Type checker) | Keywords: | Operating System: Unknown/Multiple TypeApplications | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #11387 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Currently I can define a GADT like {{{ data T where MkT :: forall a. (Num a, Show a) => T }}} but it's useless on two counts: * At a use of the constructor `MkT`, I can't specify what type `a` I want to pack dictionaries for. (In fact the declaration is an error unless either the constraints are defaultable (as in the case above) or AllowAmbiguousTypes is enabled.) * At a pattern match against `MkT`, I have no way to refer to the type for which dictionaries were packed. The solution is to add a field of type `Proxy a` (possibly strict/unpacked) or `Proxy# a` to `MkT`. But these options are all a bit verbose and each have minor drawbacks. I had hoped that TypeApplications would address the two points above directly. * At a use of the constructor `MkT`, specify the type with a type application `MkT @a`. This part works as of 90f35612f16ff9cb2466cc936f12e748402abb85. * At a pattern match against `MkT`, I would like to be able to match the type directly like this: {{{ f :: T -> String f t = case t of MkT @a -> show (0 :: a) }}} This is the feature request. Note that, while this may be stressful for the parser due to as-patterns, I don't think there is any actual ambiguity as long as (1) type applications only appear on constructors, not variables, and (2) all type applications appear before any value-level fields of the constructor. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 19:16:26 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 19:16:26 -0000 Subject: [GHC] #11638: referring to the existential type from a GADT pattern match with a type application In-Reply-To: <047.7c8b5ea224dc1a576a93e34811383394@haskell.org> References: <047.7c8b5ea224dc1a576a93e34811383394@haskell.org> Message-ID: <062.6928086f67d6a7a7409ae71a2407f3cd@haskell.org> #11638: referring to the existential type from a GADT pattern match with a type application -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Keywords: Resolution: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11387 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I actually implemented this partially. But there are devilish details (numbered only for reference): 1. We only pattern-match on ''existentials'', never ''universals''. That is, if we have {{{#!hs data T1 a where MkT1 :: a -> b -> T1 a }}} Using `MkT1` as an expression: we could say `MkT1 @Int @Bool 5 True`. But as a pattern, we would have to omit the first argument: `foo (MkT1 @b x y)`. This is confusing. I suppose we could include the universals in the pattern-match, but they would have to be underscores or an exact match for the inferred instantiation of the universal type variable. 2. Users can reorder the variables in a data constructor, making point (1) even worse: {{{#!hs data T2 a where MkT2 :: forall b a. a -> b -> T2 a }}} Note the explicit `forall` reordering the variables. So it's not necessarily a prefix of variables that get dropped. 3. Naturally, any visible type patterns would have to bind only bare type variables, never match against types. Otherwise, we've lost type erasure and parametricity. 4. Do visible type patterns extend beyond data constructors? To wit: {{{#!hs foo :: forall a. a -> a foo @b x = (x :: b) }}} Is that accepted? What about {{{#!hs (\ @a x -> (x :: a)) :: forall b. b -> b }}} It sure would be nice to be able to do this -- it would make continuation-passing style with fancy types easier. There are solutions here, of course, but I just wanted to write down a few thoughts while I still remember them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 19:26:50 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 19:26:50 -0000 Subject: [GHC] #11329: Visible type applications: failing tests with WAY=hpc In-Reply-To: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> References: <045.7549ebde8344b9bd5a2b1fc47268b5a3@haskell.org> Message-ID: <060.c7acc48fa7efbdb67504a414fd91a4ae@haskell.org> #11329: Visible type applications: failing tests with WAY=hpc -------------------------------------+------------------------------------- Reporter: thomie | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: | TypeApplications Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | parser/should_compile/VtaParse | typecheck/should_compile/Vta1 | typecheck/should_compile/Vta2 Blocked By: | Blocking: Related Tickets: #11456 | Differential Rev(s): Phab:D1824 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * related: => #11456 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 19:27:21 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 19:27:21 -0000 Subject: [GHC] #11456: Type application and :set +c command cause panic In-Reply-To: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> References: <051.8c51eb92e178f36ab21dc70abd461ea2@haskell.org> Message-ID: <066.8e7574697f0dfe069233b86fae3b52a7@haskell.org> #11456: Type application and :set +c command cause panic -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | TypeApplications GHCi Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11329 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * related: => #11329 Comment: I have this refactoring done locally and will push in (short) due course. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 19:49:13 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 19:49:13 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.9489b67c8d4f1a0f1963885c26827be7@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1891 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"d8c64e86361f6766ebe26a262bb229fb8301a42a/ghc" d8c64e86/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="d8c64e86361f6766ebe26a262bb229fb8301a42a" Address #11471 by putting RuntimeRep in kinds. See Note [TYPE] in TysPrim. There are still some outstanding pieces in #11471 though, so this doesn't actually nail the bug. This commit also contains a few performance improvements: * Short-cut equality checking of nullary type syns * Compare types before kinds in eqType * INLINE coreViewOneStarKind * Store tycon binders separately from kinds. This resulted in a ~10% performance improvement in compiling the Cabal package. No change in functionality other than performance. (This affects the interface file format, though.) This commit updates the haddock submodule. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 19:54:09 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 19:54:09 -0000 Subject: [GHC] #10484: hPutBuf crashes when trying to write a large string to stdout (resource exhausted) In-Reply-To: <046.8764c6246b23f1309a5c029d47994521@haskell.org> References: <046.8764c6246b23f1309a5c029d47994521@haskell.org> Message-ID: <061.e23d00a1322f7732f82eaffa784bacff@haskell.org> #10484: hPutBuf crashes when trying to write a large string to stdout (resource exhausted) -------------------------------------+------------------------------------- Reporter: bayloff | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Remi): * cc: remi (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 19:54:47 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 19:54:47 -0000 Subject: [GHC] #7670: StablePtrs should be organized by generation for efficient minor collections In-Reply-To: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> References: <045.3e79ce9413679adff14ececd359ab7ff@haskell.org> Message-ID: <060.5515604af16d157603a451434c48eef7@haskell.org> #7670: StablePtrs should be organized by generation for efficient minor collections -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by Remi): * cc: remi.turk@? (removed) * cc: remi (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 21:25:43 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 21:25:43 -0000 Subject: [GHC] #11639: `:print` being wacky Message-ID: <048.c516bc228e8d9a9b263488a0df177e98@haskell.org> #11639: `:print` being wacky ----------------------------------------+------------------------------- Reporter: TheKing42 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ----------------------------------------+------------------------------- {{{ $ ghci GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help Prelude> let x = 1:x Prelude> :print x x = (_t1::Num a => [a]) Prelude> head _t1 ghc: panic! (the 'impossible' happened) (GHC version 7.10.3 for x86_64-unknown-linux): tcTyVarDetails a_avB 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 Feb 24 21:26:55 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 21:26:55 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.d9f9bcffe833d09645598daec5fdeaf1@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) Comment: Ben, perhaps I'm missing something (your wiki page doesn't appear to define `mkTyCon` or `mkTRApp`), but I don't see why you can't write `getTypeRepX` without resorting to `unsafeCoerce`. If `TyCon` is unindexed then the first case should just work without it, and in the second case, isn't it possible to do a runtime check that the kinds of `rep_f` and `rep_x` agree? Apologies if I've overlooked something obvious by being late to the party. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 21:36:49 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 21:36:49 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.87f478d3acbfbbb7cfcca436c15fc265@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1891 Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Terrific. So what happens with the examples in comment:1 and comment:2? Can we add tests for them? Also does this fix #11473? Can we add a test for that? Ben, might you do these things? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 21:38:19 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 21:38:19 -0000 Subject: [GHC] #11640: Panic because of "updateRole" Message-ID: <051.a2aa2f07407d8fdc661bf953d330894a@haskell.org> #11640: Panic because of "updateRole" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- Not the most recent GHC {{{#!hs {-# LANGUAGE RankNTypes, TypeInType #-} import Data.Kind data HEq :: forall k1. k1 -> forall k2. k2 -> Type where }}} gives {{{ % ghci -ignore-dot-ghci tx9F.hs GHCi, version 8.1.20160117: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( tx9F.hs, interpreted ) ghc: panic! (the 'impossible' happened) (GHC version 8.1.20160117 for x86_64-unknown-linux): updateRole HEq k2_a115 [a114 :-> 0, a11e :-> 1, a11f :-> 2] 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 Feb 24 21:40:00 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 21:40:00 -0000 Subject: [GHC] #11637: single-module recursion and import aliases In-Reply-To: <044.2eb4774959afb487f0c4bf63cdcd5d44@haskell.org> References: <044.2eb4774959afb487f0c4bf63cdcd5d44@haskell.org> Message-ID: <059.3927052ca54eb9d9c4f5dabaf3138402@haskell.org> #11637: single-module recursion and import aliases -------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): We disabled self-boot imports in GHC 8.0, in part because cases like this didn't work and would be annoying to make work: {{{ ezyang at sabre:~$ ghc-8.0 --make Foo.hs [1 of 2] Compiling Foo[boot] ( Foo.hs-boot, Foo.o-boot ) [2 of 2] Compiling Foo ( Foo.hs, Foo.o ) Foo.hs:3:1: error: A module cannot import itself: Foo }}} Is this something you can easily work around, or something you quite need? If it's the latter, we can reconsider how to make this work out correctly (but the fix is nontriival.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 22:10:22 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 22:10:22 -0000 Subject: [GHC] #11637: single-module recursion and import aliases In-Reply-To: <044.2eb4774959afb487f0c4bf63cdcd5d44@haskell.org> References: <044.2eb4774959afb487f0c4bf63cdcd5d44@haskell.org> Message-ID: <059.ee20ca3d0977b2b3aedefa1287955a86@haskell.org> #11637: single-module recursion and import aliases -------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): See also: #10336 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 22:20:38 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 22:20:38 -0000 Subject: [GHC] #11637: single-module recursion and import aliases In-Reply-To: <044.2eb4774959afb487f0c4bf63cdcd5d44@haskell.org> References: <044.2eb4774959afb487f0c4bf63cdcd5d44@haskell.org> Message-ID: <059.2d6f65d2456b923b20e7cea294070b3e@haskell.org> #11637: single-module recursion and import aliases -------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by dmwit): * status: new => closed * resolution: => duplicate Comment: Looks like an exact duplicate to me. I don't need this for anything; I encountered the problem while trying to write an answer to [http://stackoverflow.com/q/35608734/791604 a StackOverflow question]. I'll let people who spot that question and make their way here speak for themselves (on the suggested dupe). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 22:26:10 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 22:26:10 -0000 Subject: [GHC] #11637: single-module recursion and import aliases In-Reply-To: <044.2eb4774959afb487f0c4bf63cdcd5d44@haskell.org> References: <044.2eb4774959afb487f0c4bf63cdcd5d44@haskell.org> Message-ID: <059.cd6ced5205115264763b422458cf7eb0@haskell.org> #11637: single-module recursion and import aliases -------------------------------------+------------------------------------- Reporter: dmwit | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 10336 | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by ezyang): * blockedby: => 10336 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 22:27:23 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 22:27:23 -0000 Subject: [GHC] #10336: Support qualified self {-# SOURCE #-} import In-Reply-To: <045.e4521d2ed9990a69119569a9c3002eed@haskell.org> References: <045.e4521d2ed9990a69119569a9c3002eed@haskell.org> Message-ID: <060.6a87e53aaf3ca7dae8410423574d6978@haskell.org> #10336: Support qualified self {-# SOURCE #-} import -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: lowest | Milestone: ? Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 7672 | Blocking: 11637 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ezyang): This StackOverflow question suggests one possible use for this: http://stackoverflow.com/questions/35608734/alias-a-module-defined-in-the- same-file-in-haskell which is to make it possible to disambiguate an locally defined identifier which is ambiguous due to another identifier in scope with the same name. But it is definitely a bit goofy to use an hs- boot file to achieve this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 22:39:34 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 22:39:34 -0000 Subject: [GHC] #11439: Request for comments: Allow duplicate type signatures In-Reply-To: <051.e7fa516c0e4f1f1253703388b646123a@haskell.org> References: <051.e7fa516c0e4f1f1253703388b646123a@haskell.org> Message-ID: <066.c7c2072b99e528cd938835ce2c66fb87@haskell.org> #11439: Request for comments: Allow duplicate type signatures -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:1 goldfire]: > On the other hand, this is a good idea for a pragma. Perhaps > > {{{ > foo :: a -> a > foo x = x > > {-# TYPECHECK > foo :: Bool -> Bool > foo :: Int -> Int > foo :: Maybe a -> Maybe a > foo True :: Bool > map id [] > #-} > }}} My gut feeling is that it must take local assumptions into account, swapping equations may confuse more than it helps (resulting from shifting equations around): {{{#!hs {-# TYPECHECK sum :: SBool False -> [Natural] -> Natural #-} sum STrue x = x {-# TYPECHECK sum :: SBool True -> Natural -> Natural #-} sum SFalse [] = 0 sum SFalse (x : xs) = x + sum SFalse xs }}} One of my syntax suggestions was an attempt to capture the local assumptions (#11387?): {{{#!hs sum @False :: SBool False -> [Natural] -> Natural sum @False SFalse :: [Natural] -> Natural }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 22:54:29 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 22:54:29 -0000 Subject: [GHC] #11439: Request for comments: Allow duplicate type signatures In-Reply-To: <051.e7fa516c0e4f1f1253703388b646123a@haskell.org> References: <051.e7fa516c0e4f1f1253703388b646123a@haskell.org> Message-ID: <066.134bb045c35177fcb67e85d7119a29d9@haskell.org> #11439: Request for comments: Allow duplicate type signatures -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Similar for type families: {{{#!hs type family Sing (res :: k -> Type) | res -> k where -- Sing :: Nat -> Type Sing = SingNat -- Sing :: Nat -> Type Sing = SingBool }}} Annotations work fine here `Sing = (SingNat :: Nat -> Type)`, ... but its utility is clearer in this [https://gist.github.com/AndrasKovacs/c7d385aa117929503feb gist] where we could annotate `(@@)` instances in different ways without modifying the definitions: {{{#!hs data Con1 :: (a -> b) -> (a ~> b) data Con2 :: (a -> b -> c) -> (a ~> b ~> c) data Con3 :: (a -> b -> c -> d) -> (a ~> b ~> c ~> d) type family (@@) (f :: a ~> b) (x :: a) :: b -- (@@) :: (a ~> b) -> (a -> b) type instance Con1 c @@ a = c a -- (@@) :: (a ~> b ~> c) -> a -> (b ~> c) -- (@@) :: (a ~> (b ~> c)) -> (a -> (b ~> c)) -- (@@) :: (a ~> b ~> c) -> (a -> b ~> c) type instance Con2 c @@ a = Con1 (c a) -- (@@) :: (a ~> b ~> c ~> d) -> a -> (b ~> c ~> d) -- (@@) :: (a ~> (b ~> c ~> d)) -> (a -> (b ~> c ~> d)) -- (@@) :: (a ~> b ~> c ~> d) -> (a -> b ~> c ~> d) type instance Con3 c @@ a = Con2 (c a) }}} I think this will only become more useful as GHC's type system evolves -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Feb 24 23:02:25 2016 From: ghc-devs at haskell.org (GHC) Date: Wed, 24 Feb 2016 23:02:25 -0000 Subject: [GHC] #11439: Request for comments: Allow duplicate type signatures In-Reply-To: <051.e7fa516c0e4f1f1253703388b646123a@haskell.org> References: <051.e7fa516c0e4f1f1253703388b646123a@haskell.org> Message-ID: <066.44d4daba3fa2db287ea1d9e4a702820a@haskell.org> #11439: Request for comments: Allow duplicate type signatures -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Iceland_jack): Replying to [comment:4 adamgundry]: > I'm not really convinced by the original ticket: couldn't you just as well do something like Yes you can at the expense of introducing extraneous definitions, your solution works fine for the original example but I fear it does not scale. > On the other hand, being able to declare a bunch of specializations such that GHCi or Haddock can display them does seem rather useful, especially for the kind of very polymorphic code you get in `lens` or the post-FTP Prelude. Yes, I also emphasise parentheses to shift students' thinking from: {{{#!hs map :: (a -> b) -> [a] -> [b] }}} to {{{#!hs map :: (a -> b) -> ([a] -> [b]) }}} You would never create a new function to accomplish this minor task but maybe this definition of `fmap` would prove useful to some: {{{#!hs class Functor f where {-# TYPECHECK fmap :: (a -> b) -> (f a -> f b) #-} fmap :: (a -> b) -> f a -> f b }}} Who knows. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 00:01:02 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 00:01:02 -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.a4a545a2f3679cc46c393c48d4e79073@haskell.org> #11622: Annotating types in type familiy equations without parentheses -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): This can't be hard; just some careful work in the parser. Any volunteers? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 00:03:49 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 00:03:49 -0000 Subject: [GHC] #11606: name shadowing warnings don't trigger on standalone declarations in ghci In-Reply-To: <047.da6e0c4abf31fd9d88f2bdf57a7418b8@haskell.org> References: <047.da6e0c4abf31fd9d88f2bdf57a7418b8@haskell.org> Message-ID: <062.2b4fbd3bd6dc68adfe73f539e3290748@haskell.org> #11606: name shadowing warnings don't trigger on standalone declarations in ghci -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Great, looking forward to it. Thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 01:27:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 01:27:18 -0000 Subject: [GHC] #11641: Allow wildcards for parameters functionally determined (also type synonyms) Message-ID: <051.4197dd5726816208c81417014cf4fc04@haskell.org> #11641: Allow wildcards for parameters functionally determined (also type synonyms) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: lowest | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple PartialTypeSignatures | Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs class F a b | a -> b where foo :: a -- ... myFoo :: F a b => a myFoo = foo }}} Since ''b'' is not used and fully determined by ''a'' could the restriction on wildcards in constraints be lifted? {{{#!hs myFoo :: F a _ => a myFoo = foo }}} and eventually hiding it behind a type synonym: {{{#!hs type F' a = F a _ myFoo' :: F' a => a myFoo' = foo }}} I raised this issue at ICFP 2014, I haven't looked into whether dominique's response to [https://haskell- phabricator.global.ssl.fastly.net/D168#4818 my comment] applies. ---- I could achieve similar things with a type family but that work as I'd intended. ---- Or CPP :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 01:27:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 01:27:42 -0000 Subject: [GHC] #11641: Allow wildcards for parameters functionally determined (also type synonyms) In-Reply-To: <051.4197dd5726816208c81417014cf4fc04@haskell.org> References: <051.4197dd5726816208c81417014cf4fc04@haskell.org> Message-ID: <066.3dcd1484109a41b093ecff0b337211d4@haskell.org> #11641: Allow wildcards for parameters functionally determined (also type synonyms) -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 8.1 Resolution: | Keywords: | PartialTypeSignatures Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by Iceland_jack: @@ -33,2 +33,1 @@ - I could achieve similar things with a type family but that work as I'd - intended. + I could achieve similar things with a type family but not quite. New description: {{{#!hs class F a b | a -> b where foo :: a -- ... myFoo :: F a b => a myFoo = foo }}} Since ''b'' is not used and fully determined by ''a'' could the restriction on wildcards in constraints be lifted? {{{#!hs myFoo :: F a _ => a myFoo = foo }}} and eventually hiding it behind a type synonym: {{{#!hs type F' a = F a _ myFoo' :: F' a => a myFoo' = foo }}} I raised this issue at ICFP 2014, I haven't looked into whether dominique's response to [https://haskell- phabricator.global.ssl.fastly.net/D168#4818 my comment] applies. ---- I could achieve similar things with a type family but not quite. ---- Or CPP :) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 04:16:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 04:16:42 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2311632=3A_Data=2EChar_repeated_readL?= =?utf-8?q?itChar_barfs_on_output_from_show_=22=C3=B31=22?= In-Reply-To: <049.9bf2436e7fb9c211d83d1b0ba3c6ee23@haskell.org> References: <049.9bf2436e7fb9c211d83d1b0ba3c6ee23@haskell.org> Message-ID: <064.82e2acdeb539fa15b89a63365981918a@haskell.org> #11632: Data.Char repeated readLitChar barfs on output from show "?1" -------------------------------------+------------------------------------- Reporter: inversemot | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by inversemot): By the way this applies to any of the numeric escapes followed by a number. ?1 just happens to be the string quickcheck found while checking that Unicode characters were parsed correctly. So technically this effects megaparsec's charLiteral which uses readLitChar. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 08:14:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 08:14:26 -0000 Subject: [GHC] #11639: `:print` being wacky In-Reply-To: <048.c516bc228e8d9a9b263488a0df177e98@haskell.org> References: <048.c516bc228e8d9a9b263488a0df177e98@haskell.org> Message-ID: <063.94ce9a80589bd2e9eaf72e758844415e@haskell.org> #11639: `:print` being wacky -------------------------------+---------------------------------------- Reporter: TheKing42 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Linux | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------+---------------------------------------- Comment (by alexbiehl): Happens on Windows too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 11:06:12 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 11:06:12 -0000 Subject: [GHC] #11495: TH_spliceE5_prof is failing with release candidate 8.0.1 In-Reply-To: <045.e71529dd8c6b021f985c7b75a2a26fb0@haskell.org> References: <045.e71529dd8c6b021f985c7b75a2a26fb0@haskell.org> Message-ID: <060.6064979156da4d097886405ff4e68d83@haskell.org> #11495: TH_spliceE5_prof is failing with release candidate 8.0.1 -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): > I guess we should not put -dynamic in ghcThWayFlags That doesn't work in batch mode. Take this example: A.hs: {{{ {-# LANGUAGE TemplateHaskell #-} module A where import B $(dec) }}} B.hs: {{{ {-# LANGUAGE TemplateHaskell #-} module B where import Language.Haskell.TH dec = [d| x = 1 |] }}} Result: {{{ $ ghc -c B.hs $ ghc -c A.hs A.hs:1:1: cannot find normal object file ?./B.dyn_o? while linking an interpreted expression }}} How about this: when compiling with `-dynamic`, create `.dyn_o` and `.dyn_hi` files by default instead of `.o` and `.hi` files. Is there any drawback to this? It would be more consistent with what `-dynamic-too` does as well. `-osuf` and `-hisuf` could keep working as before. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 13:00:22 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 13:00:22 -0000 Subject: [GHC] #9406: unexpected failure for T7837(profasm) In-Reply-To: <042.6cf0b0817037f8cfba5de5652e277f8a@haskell.org> References: <042.6cf0b0817037f8cfba5de5652e277f8a@haskell.org> Message-ID: <057.0a8005946c24f20b7aa8190eefacd463@haskell.org> #9406: unexpected failure for T7837(profasm) -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.8.3 Resolution: | Keywords: T7837 Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: T7837 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * priority: low => normal * component: Test Suite => Profiling * status: closed => new * resolution: worksforme => Comment: I can absolutely reproduce this with ghc-7.10.3 and HEAD. {{{ $ make TEST=T7837 WAY=prof TEST_HC=/opt/ghc/7.10.3/bin/ghc CLEANUP=1 ... -Rule fired: Class op signum Rule fired: Class op abs +Rule fired: Class op signum Rule fired: normalize/Double -Rule fired: Class op HEq_sc -Rule fired: Class op HEq_sc -Rule fired: Class op HEq_sc }}} With HEAD (2aee41960aa00fe09a2cd1983e02c15e06013037): {{{ Rule fired: normalize/Double Rule fired: Class op HEq_sc Rule fired: Class op HEq_sc -Rule fired: Class op HEq_sc }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 14:40:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 14:40:29 -0000 Subject: [GHC] #11585: Overload the static form to reduce verbosity In-Reply-To: <056.41ddf713d7e0fe1de83ff400ce602f67@haskell.org> References: <056.41ddf713d7e0fe1de83ff400ce602f67@haskell.org> Message-ID: <071.c4ba806946ef98a53d84f37758b036de@haskell.org> #11585: Overload the static form to reduce verbosity -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1923 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"c1efdcc40209bc4f0ded85269eb8ba49c7d1ff09/ghc" c1efdcc4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="c1efdcc40209bc4f0ded85269eb8ba49c7d1ff09" Overload the static form to reduce verbosity. Static pointers are rarely used naked: most often they are defined at the base of a Closure, as defined in e.g. the distributed-closure and distributed-static packages. So a typical usage pattern is: distributeMap (closure (static (\x -> x * 2))) which is more verbose than it needs to be. Ideally we'd just have to write distributeMap (static (\x -> x * 2)) and let the static pointer be lifted to a Closure implicitly. i.e. what we want is to overload static literals, just like we already overload list literals and string literals. This is achieved by introducing the IsStatic type class and changing the typing rule for static forms slightly: static (e :: t) :: IsStatic p => p t Test Plan: ./validate Reviewers: austin, hvr, bgamari Reviewed By: bgamari Subscribers: simonpj, mboes, thomie Differential Revision: https://phabricator.haskell.org/D1923 GHC Trac Issues: #11585 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 14:40:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 14:40:29 -0000 Subject: [GHC] #11260: Re-compilation driver/recomp11 test fails In-Reply-To: <047.28b99765e1530b4875c5afc418e3bf27@haskell.org> References: <047.28b99765e1530b4875c5afc418e3bf27@haskell.org> Message-ID: <062.f7a8e6950d9d06c0299c4d67c81234a3@haskell.org> #11260: Re-compilation driver/recomp11 test fails -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | driver/recomp011 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"feb19eae3d7b70a2c0038624dcfe2c417213d5c5/ghc" feb19eae/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="feb19eae3d7b70a2c0038624dcfe2c417213d5c5" testsuite: mark tests broken on powerpc64 The following tests fail on powerpc64 and have a ticket. Mark those tests as expect_broken. Here are the details: The PowerPC native code generator does not support DWARF debug information. This is tracked in ticket #11261. Mark the respective tests broken on powerpc64. testsuite: mark print022 broken on powerpc64 Ticket #11262 tracks difference in stdout for print022. testsuite: mark recomp015 broken on powerpc64 testsuite: mark recomp011 broken on powerpc64 This is tracked as ticket #11323 and #11260. testsuite: mark linker tests broken on powerpc64 Ticket #11259 tracks tests failing because there is no RTS linker on powerpc64. Test Plan: validate Reviewers: erikd, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1928 GHC Trac Issues: #11259, #11260, #11261, #11262, #11323 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 14:40:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 14:40:29 -0000 Subject: [GHC] #11262: Test print022: wrong stdout on powerpc64 In-Reply-To: <047.0409b41ca7e7566752abaefb0ae702eb@haskell.org> References: <047.0409b41ca7e7566752abaefb0ae702eb@haskell.org> Message-ID: <062.3de5caaba91611d45139ca1ba070fb57@haskell.org> #11262: Test print022: wrong stdout on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: print022 at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"feb19eae3d7b70a2c0038624dcfe2c417213d5c5/ghc" feb19eae/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="feb19eae3d7b70a2c0038624dcfe2c417213d5c5" testsuite: mark tests broken on powerpc64 The following tests fail on powerpc64 and have a ticket. Mark those tests as expect_broken. Here are the details: The PowerPC native code generator does not support DWARF debug information. This is tracked in ticket #11261. Mark the respective tests broken on powerpc64. testsuite: mark print022 broken on powerpc64 Ticket #11262 tracks difference in stdout for print022. testsuite: mark recomp015 broken on powerpc64 testsuite: mark recomp011 broken on powerpc64 This is tracked as ticket #11323 and #11260. testsuite: mark linker tests broken on powerpc64 Ticket #11259 tracks tests failing because there is no RTS linker on powerpc64. Test Plan: validate Reviewers: erikd, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1928 GHC Trac Issues: #11259, #11260, #11261, #11262, #11323 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 14:40:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 14:40:29 -0000 Subject: [GHC] #11261: Implement DWARF debugging on powerpc64 In-Reply-To: <047.fcb308b656617448e39264eeafa29658@haskell.org> References: <047.fcb308b656617448e39264eeafa29658@haskell.org> Message-ID: <062.008932b86c29fa10208550c21015fa4e@haskell.org> #11261: Implement DWARF debugging on powerpc64 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 (CodeGen) | Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Incorrect result | Test Case: debug, T10667 at runtime | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"feb19eae3d7b70a2c0038624dcfe2c417213d5c5/ghc" feb19eae/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="feb19eae3d7b70a2c0038624dcfe2c417213d5c5" testsuite: mark tests broken on powerpc64 The following tests fail on powerpc64 and have a ticket. Mark those tests as expect_broken. Here are the details: The PowerPC native code generator does not support DWARF debug information. This is tracked in ticket #11261. Mark the respective tests broken on powerpc64. testsuite: mark print022 broken on powerpc64 Ticket #11262 tracks difference in stdout for print022. testsuite: mark recomp015 broken on powerpc64 testsuite: mark recomp011 broken on powerpc64 This is tracked as ticket #11323 and #11260. testsuite: mark linker tests broken on powerpc64 Ticket #11259 tracks tests failing because there is no RTS linker on powerpc64. Test Plan: validate Reviewers: erikd, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1928 GHC Trac Issues: #11259, #11260, #11261, #11262, #11323 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 14:40:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 14:40:29 -0000 Subject: [GHC] #11323: powerpc64: recomp015 fails with redundant linking In-Reply-To: <047.1148580a44ecdf753373d9211c559f12@haskell.org> References: <047.1148580a44ecdf753373d9211c559f12@haskell.org> Message-ID: <062.81866413b4e179a535d3582bb6d4b21e@haskell.org> #11323: powerpc64: recomp015 fails with redundant linking -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: Compile-time | Test Case: performance bug | driver/recomp15 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"feb19eae3d7b70a2c0038624dcfe2c417213d5c5/ghc" feb19eae/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="feb19eae3d7b70a2c0038624dcfe2c417213d5c5" testsuite: mark tests broken on powerpc64 The following tests fail on powerpc64 and have a ticket. Mark those tests as expect_broken. Here are the details: The PowerPC native code generator does not support DWARF debug information. This is tracked in ticket #11261. Mark the respective tests broken on powerpc64. testsuite: mark print022 broken on powerpc64 Ticket #11262 tracks difference in stdout for print022. testsuite: mark recomp015 broken on powerpc64 testsuite: mark recomp011 broken on powerpc64 This is tracked as ticket #11323 and #11260. testsuite: mark linker tests broken on powerpc64 Ticket #11259 tracks tests failing because there is no RTS linker on powerpc64. Test Plan: validate Reviewers: erikd, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1928 GHC Trac Issues: #11259, #11260, #11261, #11262, #11323 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 14:40:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 14:40:29 -0000 Subject: [GHC] #11607: ApplicativeDo easily foiled with `pure` In-Reply-To: <046.822f388a9e9f7e6ae598d3989cdd9275@haskell.org> References: <046.822f388a9e9f7e6ae598d3989cdd9275@haskell.org> Message-ID: <061.654c2e4771443f1aa381a6c3dfa93426@haskell.org> #11607: ApplicativeDo easily foiled with `pure` -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: ado/T11607 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1931 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"0c7db61f8a17b2c5c4335b62103eb9ffc5d24154/ghc" 0c7db61f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="0c7db61f8a17b2c5c4335b62103eb9ffc5d24154" ApplicativeDo: Handle terminal `pure` statements ApplicativeDo handled terminal `return` statements properly, but not `pure`. Test Plan: Validate with included testcase Reviewers: austin, simonmar Reviewed By: austin, simonmar Subscribers: simonpj, thomie Differential Revision: https://phabricator.haskell.org/D1931 GHC Trac Issues: #11607 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 14:40:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 14:40:29 -0000 Subject: [GHC] #11603: Fix/clarify documentation in GHC.Stats In-Reply-To: <047.d444ccdc28f8e376bec099daa1b220c9@haskell.org> References: <047.d444ccdc28f8e376bec099daa1b220c9@haskell.org> Message-ID: <062.f34ca314e4880920b00ca5dab0be7bd0@haskell.org> #11603: Fix/clarify documentation in GHC.Stats -------------------------------------+------------------------------------- Reporter: dcturner | Owner: Type: task | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 8.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:D1929 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"8e19d3a3066b883d9bc10a75c8d3183907272a9f/ghc" 8e19d3a/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="8e19d3a3066b883d9bc10a75c8d3183907272a9f" base: A selection of fixes to the comments in GHC.Stats Use `-- |` comments throughout. Note that numByteUsageSamples is also the number of major GCs Note that numGcs counts GCs for all generations Note that 'current' really means 'at the end of the last major GC' Reviewers: ezyang, hvr, simonmar, austin, bgamari Reviewed By: ezyang, simonmar, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1929 GHC Trac Issues: #11603 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 14:40:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 14:40:29 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.73d199cd7917c1d592edb16357ef1cb2@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------- Reporter: ocharles | Owner: dreixel Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9766 | Blocking: Related Tickets: #8778 | Differential Rev(s): Phab:D1937 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"673efccb3b348e9daf23d9e65460691bbea8586e/ghc" 673efcc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="673efccb3b348e9daf23d9e65460691bbea8586e" Add more type class instances for GHC.Generics GHC.Generics provides several representation data types that have obvious instances of various type classes in base, along with various other types of meta-data (such as associativity and fixity). Specifically, instances have been added for the following type classes (where possible): - Applicative - Data - Functor - Monad - MonadFix - MonadPlus - MonadZip - Foldable - Traversable - Enum - Bounded - Ix - Generic1 Thanks to ocharles for starting this! Test Plan: Validate Reviewers: ekmett, austin, hvr, bgamari Reviewed By: bgamari Subscribers: RyanGlScott, thomie Differential Revision: https://phabricator.haskell.org/D1937 GHC Trac Issues: #9043 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 14:40:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 14:40:29 -0000 Subject: [GHC] #11259: Use system runtime linker in GHCi on PowerPC 64 bit In-Reply-To: <047.f1dbe111d1a2b1b825a51a6a842cbde6@haskell.org> References: <047.f1dbe111d1a2b1b825a51a6a842cbde6@haskell.org> Message-ID: <062.960b59fd77e40b907fa46770b72a6265@haskell.org> #11259: Use system runtime linker in GHCi on PowerPC 64 bit -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: GHCi | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: GHCi crash | Test Case: ghcilink004, | prog001, and 11 more Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"feb19eae3d7b70a2c0038624dcfe2c417213d5c5/ghc" feb19eae/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="feb19eae3d7b70a2c0038624dcfe2c417213d5c5" testsuite: mark tests broken on powerpc64 The following tests fail on powerpc64 and have a ticket. Mark those tests as expect_broken. Here are the details: The PowerPC native code generator does not support DWARF debug information. This is tracked in ticket #11261. Mark the respective tests broken on powerpc64. testsuite: mark print022 broken on powerpc64 Ticket #11262 tracks difference in stdout for print022. testsuite: mark recomp015 broken on powerpc64 testsuite: mark recomp011 broken on powerpc64 This is tracked as ticket #11323 and #11260. testsuite: mark linker tests broken on powerpc64 Ticket #11259 tracks tests failing because there is no RTS linker on powerpc64. Test Plan: validate Reviewers: erikd, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1928 GHC Trac Issues: #11259, #11260, #11261, #11262, #11323 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 14:40:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 14:40:29 -0000 Subject: [GHC] #11583: Make warning names more consistent In-Reply-To: <046.2c5f65cdcdffbe526873fdbd4a154741@haskell.org> References: <046.2c5f65cdcdffbe526873fdbd4a154741@haskell.org> Message-ID: <061.441b2b1afb1ed20d98c122984154208d@haskell.org> #11583: Make warning names more consistent -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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:D1939 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"665849142bca36c14bcb25d64180c153a1ef1f2c/ghc" 6658491/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="665849142bca36c14bcb25d64180c153a1ef1f2c" Make warning names more consistent - Replace "Sigs" with "Signatures" in WarningFlag data constructors. - Replace "PatSyn" with "PatternSynonym" in WarningFlag data constructors. - Deprecate "missing-local-sigs" in favor of "missing-local-signatures". - Deprecate "missing-exported-sigs" in favor of "missing-exported-signatures". - Deprecate "missing-pat-syn-signatures" in favor of "missing-pattern-synonym-signatures". - Replace "ddump-strsigs" with "ddump-str-signatures" These complete the tasks that were explicitly mentioned in #11583 Test Plan: Executed `ghc --show-options` and verified that the flags were changed as expected. Reviewers: svenpanne, austin, bgamari Reviewed By: austin, bgamari Subscribers: mpickering, thomie Differential Revision: https://phabricator.haskell.org/D1939 GHC Trac Issues: #11583 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 14:47:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 14:47:05 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.d17b860d5a915bf216747861387e3f91@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------- Reporter: ocharles | Owner: dreixel Type: feature request | Status: merge Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9766 | Blocking: Related Tickets: #8778 | Differential Rev(s): Phab:D1937 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 14:47:26 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 14:47:26 -0000 Subject: [GHC] #8710: Overlapping patterns warning misplaced In-Reply-To: <047.1f227e0dac37dd7309646386f280164b@haskell.org> References: <047.1f227e0dac37dd7309646386f280164b@haskell.org> Message-ID: <062.b24015a7de9fd45bf24b5ca6254adadd@haskell.org> #8710: Overlapping patterns warning misplaced -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1910, Wiki Page: | Phab:D1920 -------------------------------------+------------------------------------- Comment (by bgamari): I'm happy to go with the flow here. D1920 it is. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 14:57:42 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 14:57:42 -0000 Subject: [GHC] #11603: Fix/clarify documentation in GHC.Stats In-Reply-To: <047.d444ccdc28f8e376bec099daa1b220c9@haskell.org> References: <047.d444ccdc28f8e376bec099daa1b220c9@haskell.org> Message-ID: <062.9f2d7a0c24f5cf10d6a2ee756b64fc4d@haskell.org> #11603: Fix/clarify documentation in GHC.Stats -------------------------------------+------------------------------------- Reporter: dcturner | Owner: Type: task | Status: merge Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 8.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:D1929 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 14:58:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 14:58:28 -0000 Subject: [GHC] #11607: ApplicativeDo easily foiled with `pure` In-Reply-To: <046.822f388a9e9f7e6ae598d3989cdd9275@haskell.org> References: <046.822f388a9e9f7e6ae598d3989cdd9275@haskell.org> Message-ID: <061.6dbf39c8de318d760c6ba1198b1c4962@haskell.org> #11607: ApplicativeDo easily foiled with `pure` -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: merge Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: ado/T11607 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1931 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 14:59:15 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 14:59:15 -0000 Subject: [GHC] #11583: Make warning names more consistent In-Reply-To: <046.2c5f65cdcdffbe526873fdbd4a154741@haskell.org> References: <046.2c5f65cdcdffbe526873fdbd4a154741@haskell.org> Message-ID: <061.58e9b698e170a145fa86f15979f32fc2@haskell.org> #11583: Make warning names more consistent -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: merge Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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:D1939 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 15:00:25 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 15:00:25 -0000 Subject: [GHC] #11633: Record field order in a bidirectional pattern synonym match is order dependent In-Reply-To: <046.0c4427b2dcf79f3f6a57a5376b7a4d59@haskell.org> References: <046.0c4427b2dcf79f3f6a57a5376b7a4d59@haskell.org> Message-ID: <061.983a6b6741e2e8034494df16192510a8@haskell.org> #11633: Record field order in a bidirectional pattern synonym match is order dependent -------------------------------------+------------------------------------- Reporter: bgamari | Owner: mpickering Type: bug | Status: merge Priority: high | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: Resolution: | PatternSynonyms 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:D1949 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 15:27:19 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 15:27:19 -0000 Subject: [GHC] #11011: Add type-indexed type representations (`TypeRep a`) In-Reply-To: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> References: <047.c73f466ae3b4d7fe3bfc6781e66855ef@haskell.org> Message-ID: <062.829216bff2c0e65fd2566e972d026a14@haskell.org> #11011: Add type-indexed type representations (`TypeRep a`) -------------------------------------+------------------------------------- Reporter: bjmprice | Owner: 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): > If TyCon is unindexed then the first case should just work without it, Well, not quite. The trouble here is that kinds are necessarily of type `*`. That is, `mkTrCon` has type, {{{#!hs mkTrCon :: forall (k :: *) (a :: k). TyCon -> TTypeRep k -> TTypeRep a }}} That being said, a runtime check will suffice here. This still leaves the question of whether the given `TyCon` may plausibly have the requested kind, but at least this does away with the `unsafeCoerce`s. > in the second case, isn't it possible to do a runtime check that the kinds of rep_f and rep_x agree? Indeed, this ought to be possible. Thanks for bringing this up! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 15:36:44 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 15:36:44 -0000 Subject: [GHC] #10484: hPutBuf crashes when trying to write a large string to stdout (resource exhausted) In-Reply-To: <046.8764c6246b23f1309a5c029d47994521@haskell.org> References: <046.8764c6246b23f1309a5c029d47994521@haskell.org> Message-ID: <061.2ff56063a98fa911d6086a9196249e7d@haskell.org> #10484: hPutBuf crashes when trying to write a large string to stdout (resource exhausted) -------------------------------------+------------------------------------- Reporter: bayloff | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bayloff): After googling around, it seems that this is not an issue of hPutBuf per se, but probably a limitation of the Windows API call that it uses to print to the console. See this issue in a Python bug tracker. The reported symptoms are exactly the same: https://bugs.python.org/issue11395 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 16:16:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 16:16:46 -0000 Subject: [GHC] #11597: Optimize cmpTypeX In-Reply-To: <047.c45212e57d1b61470e39791921d06b96@haskell.org> References: <047.c45212e57d1b61470e39791921d06b96@haskell.org> Message-ID: <062.ed5e42ed99c8fac3db8523604b4da095@haskell.org> #11597: Optimize cmpTypeX -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"073e20ebda73309173b6b6e3ea10164e8808cc79/ghc" 073e20e/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="073e20ebda73309173b6b6e3ea10164e8808cc79" cmpTypeX: Avoid kind comparison when possible This comparison is only necessary when the types being compared contain casts. Otherwise the structural equality of the types implies that their kinds are equal. Test Plan: Validate Reviewers: goldfire, austin, simonpj Reviewed By: simonpj Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1944 GHC Trac Issues: #11597 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 16:16:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 16:16:46 -0000 Subject: [GHC] #8710: Overlapping patterns warning misplaced In-Reply-To: <047.1f227e0dac37dd7309646386f280164b@haskell.org> References: <047.1f227e0dac37dd7309646386f280164b@haskell.org> Message-ID: <062.c98731e3e933ee09d6a4d4b566671736@haskell.org> #8710: Overlapping patterns warning misplaced -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.7 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1910, Wiki Page: | Phab:D1920 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"67393977489942ef41f4f7d4a77076c15db18b92/ghc" 67393977/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="67393977489942ef41f4f7d4a77076c15db18b92" (Alternative way to) address #8710 Issue a separate warning per redundant (or inaccessible) clause. This way each warning can have more precice location information (the location of the clause under consideration and not the whole match). I thought that this could be too much but actually the number of such warnings is bound by the number of cases matched against (in contrast to the non-exhaustive warnings which may be exponentially more). Test Plan: validate Reviewers: simonpj, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1920 GHC Trac Issues: #8710 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 16:16:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 16:16:46 -0000 Subject: [GHC] #10398: Support consecutive named Haddock comments In-Reply-To: <047.7740b80be062ec1bb48c700ce8a4b3f6@haskell.org> References: <047.7740b80be062ec1bb48c700ce8a4b3f6@haskell.org> Message-ID: <062.46709dd749eeeab960b376d6fd7aebe6@haskell.org> #10398: Support consecutive named Haddock comments -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.1 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: | haddock/should_compile_flag_haddock/T10398 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1025 -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6350eb1126e29b93829de688623c91b772f6d9eb/ghc" 6350eb1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6350eb1126e29b93829de688623c91b772f6d9eb" Handle multiline named haddock comments properly Fixes #10398 in a different way, thereby also fixing #11579. I inverted the logic of the Bool argument to "worker", to hopefully make it more self-explanatory. Reviewers: austin, hvr, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1935 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 16:16:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 16:16:46 -0000 Subject: [GHC] #11579: Bug in parser for named Haddock chunks since GHC 8.0.1-rc1 In-Reply-To: <050.4d0ef6c9d54d8fe326a15d5b3729d82a@haskell.org> References: <050.4d0ef6c9d54d8fe326a15d5b3729d82a@haskell.org> Message-ID: <065.85c6004e41398273b971f207544cba36@haskell.org> #11579: Bug in parser for named Haddock chunks since GHC 8.0.1-rc1 -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: thomie Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10398 | Differential Rev(s): Phab:D1935 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"6350eb1126e29b93829de688623c91b772f6d9eb/ghc" 6350eb1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6350eb1126e29b93829de688623c91b772f6d9eb" Handle multiline named haddock comments properly Fixes #10398 in a different way, thereby also fixing #11579. I inverted the logic of the Bool argument to "worker", to hopefully make it more self-explanatory. Reviewers: austin, hvr, bgamari Reviewed By: bgamari Differential Revision: https://phabricator.haskell.org/D1935 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 16:27:00 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 16:27:00 -0000 Subject: [GHC] #11642: Typechecker doesn't use evidence available from pattern synonym? Message-ID: <046.32db5cb4e79f0588d07e2dbd35cff7c7@haskell.org> #11642: Typechecker doesn't use evidence available from pattern synonym? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 (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: -------------------------------------+------------------------------------- Either that or I am missing something... Consider the following, {{{#!hs {-# LANGUAGE GADTs, PolyKinds, PatternSynonyms, RankNTypes, TypeOperators, ViewPatterns #-} module Test where data TypeRep (a :: k) where TypeCon :: String -> TypeRep a TypeApp :: TypeRep f -> TypeRep x -> TypeRep (f x) data TypeRepX where TypeRepX :: TypeRep a -> TypeRepX data (a :: k1) :~~: (b :: k2) where HRefl :: a :~~: a trArrow :: TypeRep (->) trArrow = undefined eqTypeRep :: TypeRep (a :: k1) -> TypeRep (b :: k2) -> Maybe (a :~~: b) eqTypeRep = undefined typeRepKind :: forall (k :: *). forall (a :: k). TypeRep a -> TypeRep k typeRepKind = undefined pattern TRFun :: forall fun. () => forall arg res. (fun ~ (arg -> res)) => TypeRep arg -> TypeRep res -> TypeRep fun pattern TRFun arg res <- TypeApp (TypeApp (eqTypeRep trArrow -> Just HRefl) arg) res buildApp :: TypeRepX -> TypeRepX -> TypeRepX buildApp (TypeRepX f) (TypeRepX x) = case typeRepKind f of TRFun arg _ -> case eqTypeRep arg x of Just HRefl -> TypeRepX $ TypeApp f x }}} This fails with, {{{ $ ghc Test.hs -fprint-explicit-kinds [1 of 1] Compiling Test ( Test.hs, Test.o ) Test.hs:38:30: error: ? Expected kind ?TypeRep (k1 -> res) a?, but ?f? has kind ?TypeRep k a? ? In the first argument of ?TypeApp?, namely ?f? In the second argument of ?($)?, namely ?TypeApp f x? In the expression: TypeRepX $ TypeApp f x ? Relevant bindings include arg :: TypeRep * arg (bound at Test.hs:35:11) }}} That is, the typechecker doesn't believe that `f`'s type (why is it saying "kind" here?), `TypeRep k a`, will unify with `TypeRep (k1 -> res) a`, despite the `TRFun` pattern match, which should have brought into scope that `k ~ (arg -> res)`. This was tested with a recent snapshot from `ghc-8.0` (23baff798aca5856650508ad0f7727045efe3680). Am I missing something here or is this a bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 17:10:23 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 17:10:23 -0000 Subject: [GHC] #11579: Bug in parser for named Haddock chunks since GHC 8.0.1-rc1 In-Reply-To: <050.4d0ef6c9d54d8fe326a15d5b3729d82a@haskell.org> References: <050.4d0ef6c9d54d8fe326a15d5b3729d82a@haskell.org> Message-ID: <065.72079c9db964f3f5611f3945ff4166ab@haskell.org> #11579: Bug in parser for named Haddock chunks since GHC 8.0.1-rc1 -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: thomie Type: bug | Status: merge Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (Parser) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10398 | Differential Rev(s): Phab:D1935 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 17:17:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 17:17:05 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.7451240e06702c35f8b336b05533b92f@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1891 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 17:17:11 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 17:17:11 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.0efde10772b4845d01dd3ee0737f4dd2@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1891 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: goldfire => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 17:20:13 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 17:20:13 -0000 Subject: [GHC] #11585: Overload the static form to reduce verbosity In-Reply-To: <056.41ddf713d7e0fe1de83ff400ce602f67@haskell.org> References: <056.41ddf713d7e0fe1de83ff400ce602f67@haskell.org> Message-ID: <071.650586cad20eed77260e59b3b5dca60b@haskell.org> #11585: Overload the static form to reduce verbosity -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1923 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 17:22:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 17:22:16 -0000 Subject: [GHC] #11597: Optimize cmpTypeX In-Reply-To: <047.c45212e57d1b61470e39791921d06b96@haskell.org> References: <047.c45212e57d1b61470e39791921d06b96@haskell.org> Message-ID: <062.f47056771e369cd0e1cc04d7c6f80d72@haskell.org> #11597: Optimize cmpTypeX -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1944 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge * failure: None/Unknown => Compile-time performance bug * differential: => Phab:D1944 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 17:36:14 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 17:36:14 -0000 Subject: [GHC] #11643: Core lint error in simplifier when compiling Rules1 with -O -prof -dcore-lint Message-ID: <045.64be924d003e88a5dbf3c5cb9b9fa49c@haskell.org> #11643: Core lint error in simplifier when compiling Rules1 with -O -prof -dcore- lint -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Running `make TEST=Rules1 WAY=profasm` results in a core lint error (see attachment) with ghc-8.0.1-rc2. This is the code: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Rules1 where class C a where data T a instance (C a, C b) => C (a,b) where data T (a,b) = TPair (T a) (T b) mapT :: (C a, C b) => (a -> b) -> T a -> T b {-# NOINLINE mapT #-} -- Otherwwise we get a warning from the rule mapT = undefined zipT :: (C a, C b) => T a -> T b -> T (a,b) {-# NOINLINE [1] zipT #-} zipT = undefined {-# RULES "zipT/mapT" forall f x y. zipT (mapT f x) y = mapT (\(x,y) -> (f x, y)) (zipT x y) #-} }}} {{{ $ ghc-8.0.1 -O -prof Rules1.hs -dcore-lint }}} This is a regression from 7.10.3, and core lint errors are bad, so setting priority to highest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 17:36:48 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 17:36:48 -0000 Subject: [GHC] #11643: Core lint error in simplifier when compiling Rules1 with -O -prof -dcore-lint In-Reply-To: <045.64be924d003e88a5dbf3c5cb9b9fa49c@haskell.org> References: <045.64be924d003e88a5dbf3c5cb9b9fa49c@haskell.org> Message-ID: <060.9206ad060296462164a77218b5f79225@haskell.org> #11643: Core lint error in simplifier when compiling Rules1 with -O -prof -dcore- lint -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * Attachment "T11643.log" added. Core lint error -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 17:40:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 17:40:43 -0000 Subject: [GHC] #11643: Core lint error in simplifier when compiling Rules1 with -O -prof -dcore-lint In-Reply-To: <045.64be924d003e88a5dbf3c5cb9b9fa49c@haskell.org> References: <045.64be924d003e88a5dbf3c5cb9b9fa49c@haskell.org> Message-ID: <060.7b6b3bba5fefca0de0dc1e8dab1b3db9@haskell.org> #11643: Core lint error in simplifier when compiling Rules1 with -O -prof -dcore- lint -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/Rules1 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => indexed-types/should_compile/Rules1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 18:01:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 18:01:47 -0000 Subject: [GHC] #11644: Core lint error in result of Specialise for TEST=T3220 WAY=profasm Message-ID: <045.682eeaccfb8fedc9aed75a81ae76afb5@haskell.org> #11644: Core lint error in result of Specialise for TEST=T3220 WAY=profasm -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: indexed- | Blocked By: types/should_compile/T3220 | Blocking: | Related Tickets: #11371, #11643 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- This is the code: {{{ {-# LANGUAGE TypeFamilies, ScopedTypeVariables#-} module T3220 where class Foo m where type Bar m :: * action :: m -> Bar m -> m right x m = action m (Right x) right' :: (Either a b ~ Bar m, Foo m) => b -> m -> m right' x m = action m (Right x) instance Foo Int where type Bar Int = Either Int Int action m a = either (*) (+) a m instance Foo Float where type Bar Float = Either Float Float action m a = either (*) (+) a m foo = print $ right (1::Int) (3 :: Int) bar = print $ right (1::Float) (3 :: Float) }}} Invocation: {{{ $ ghc-8.0.1 T3220.hs -prof -O -dcore-lint }}} {{{ [1 of 1] Compiling T3220 ( T3220.hs, T3220.o ) *** Core Lint errors : in result of Specialise *** : warning: In the expression: action @ Float $fFooFloat m_ayb ((Right @ Float @ Float x_aya) `cast` (Sub (Sym cobox_aUe) :: Either a_aU3 b_aU4 ~R# Bar m_aU1)) cobox_aUe :: Bar m_aU1 ~# Either a_aU3 b_aU4 [LclId[CoVarId], Str=DmdType] is out of scope }}} Interestingly, with HEAD (2aee41960aa00fe09a2cd1983e02c15e06013037), it hits an assert from #11371. {{{ =====> T3220(profasm) 12 of 21 [0, 11, 0] cd ./indexed-types/should_compile && "/home/thomas/ghc- validate/inplace/test spaces/ghc-stage2" -c T3220.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno-ghci-history -O -prof -static -auto-all > T3220.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160221 for x86_64-unknown-linux): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/types/TyCoRep.hs:1942:51 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2076:17 in ghc:TyCoRep substCo, called at compiler/coreSyn/CoreSubst.hs:605:20 in ghc:CoreSubst in_scope InScope {x_axS m_axT $caction_a1dp $caction_a1dR right right' foo bar $tcFoo $tc'C:Foo $fFooFloat $fFooInt $trModule a_s1fZ a_s1g0 a_s1g1 a_s1g2} tenv [aTT :-> Float, aTV :-> Float, aTW :-> Float] cenv [] tys [] cos [Sub (Sym cobox_aU6)] needInScope [aU6 :-> cobox_aU6] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This is a regression from 7.10.3. Setting priority=highest. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 18:02:09 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 18:02:09 -0000 Subject: [GHC] #11644: Core lint error in result of Specialise for TEST=T3220 WAY=profasm In-Reply-To: <045.682eeaccfb8fedc9aed75a81ae76afb5@haskell.org> References: <045.682eeaccfb8fedc9aed75a81ae76afb5@haskell.org> Message-ID: <060.ba3429251bee3e4c53c0b99626bbcd0c@haskell.org> #11644: Core lint error in result of Specialise for TEST=T3220 WAY=profasm -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T3220 Blocked By: | Blocking: Related Tickets: #11371, #11643 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * Attachment "T11644.log" added. Core lint error -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 18:18:46 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 18:18:46 -0000 Subject: [GHC] #11471: Kind polymorphism and unboxed types: bad things are happening In-Reply-To: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> References: <046.c36f8dbe1b6b1111c7523ed17ddcf692@haskell.org> Message-ID: <061.a773d7a6de5e0b67a13773f0a6e80bed@haskell.org> #11471: Kind polymorphism and unboxed types: bad things are happening -------------------------------------+------------------------------------- Reporter: bgamari | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: TypeInType, Resolution: | LevityPolymorphism Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1891 Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: bgamari => goldfire Comment: I'm still on this, actually. The `RuntimeRep` stuff was just a necessary stop along the way. The actual fix should be quite simple to put in on top of this all. Ben, if you want to add tests, I won't stop you, but I don't imagine they will pass. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 18:23:16 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 18:23:16 -0000 Subject: [GHC] #11642: Typechecker doesn't use evidence available from pattern synonym? In-Reply-To: <046.32db5cb4e79f0588d07e2dbd35cff7c7@haskell.org> References: <046.32db5cb4e79f0588d07e2dbd35cff7c7@haskell.org> Message-ID: <061.b9fb2eb9b6627c179a0bd5348d2f2b64@haskell.org> #11642: Typechecker doesn't use evidence available from pattern synonym? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 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 goldfire): Looks like a bug to me. Also you're right that the error message should say "type". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 18:29:35 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 18:29:35 -0000 Subject: [GHC] #11644: Core lint error in result of Specialise for TEST=T3220 WAY=profasm In-Reply-To: <045.682eeaccfb8fedc9aed75a81ae76afb5@haskell.org> References: <045.682eeaccfb8fedc9aed75a81ae76afb5@haskell.org> Message-ID: <060.fb2d0929ca09ea8ac079087edd089737@haskell.org> #11644: Core lint error in result of Specialise for TEST=T3220 WAY=profasm -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T3220, | indexed- | types/should_compile/ColInference3 Blocked By: | Blocking: Related Tickets: #11371, #11643 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: indexed-types/should_compile/T3220 => indexed-types/should_compile/T3220, indexed- types/should_compile/ColInference3 Comment: `indexed-types/should_compile/ColInference3` fails with a similar error. I'll mark both as expect_broken for this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 18:31:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 18:31:20 -0000 Subject: [GHC] #11349: [TypeApplications] Create Proxy-free alternatives of functions in base In-Reply-To: <051.287da149b49626768faa704af8139943@haskell.org> References: <051.287da149b49626768faa704af8139943@haskell.org> Message-ID: <066.875141db51029ac2aaceac95ac82704d@haskell.org> #11349: [TypeApplications] Create Proxy-free alternatives of functions in base -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.3 Resolution: | Keywords: | TypeApplications, Typeable Operating System: Other | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:7 goldfire]: > Might I suggest that we experiment with this outside of `base` for a bit? `TypeApplications` is awfully new. I honestly don't think it will, but it might well change. Given the very loud grumbling we've all heard about changes to `base`, I think it would be prudent to make a `proxyfree- base` that users can opt into. If all goes well, I think merging into `base` somehow is great. But maybe for 8.2. Coincidentally, I just started a [http://hackage.haskell.org/package/proxied-0.1.1/docs/Data-Proxied.html proxied] library to retrofit functions like `sizeOf` to take a `Proxy` as an argument. I'd be eager to add a `Data.Proxyless` module to `proxied` that gives the corresponding `Proxy`-free equivalent functions that leverage `TypeApplications`. (The name `proxied` then becomes kind of a misnomer, but at the end of the day it'd accomplish what this ticket sets out to do.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 18:39:09 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 18:39:09 -0000 Subject: [GHC] #10336: Support qualified self {-# SOURCE #-} import In-Reply-To: <045.e4521d2ed9990a69119569a9c3002eed@haskell.org> References: <045.e4521d2ed9990a69119569a9c3002eed@haskell.org> Message-ID: <060.6d96f2907d52a8a2bdd3bc61cc2b093f@haskell.org> #10336: Support qualified self {-# SOURCE #-} import -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: lowest | Milestone: ? Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 7672 | Blocking: 11637 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I vote that this is a bug, not a feature. The real problem is that we can't qualify the current module, not that we can't do a silly recursive self-import. Why not just {{{#!hs module A as MyA where }}} That seems much more direct. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 18:43:25 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 18:43:25 -0000 Subject: [GHC] #10336: Support qualified self {-# SOURCE #-} import In-Reply-To: <045.e4521d2ed9990a69119569a9c3002eed@haskell.org> References: <045.e4521d2ed9990a69119569a9c3002eed@haskell.org> Message-ID: <060.2922193c43e1127d84787cd265a91e70@haskell.org> #10336: Support qualified self {-# SOURCE #-} import -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: lowest | Milestone: ? Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: 7672 | Blocking: 11637 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): FWIW I also tried `module A as MyA where` to see if it was legal Haskell in response to that StackOverflow question, so I agree it is a pretty natural thing to want. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 18:57:31 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 18:57:31 -0000 Subject: [GHC] #11643: Core lint error in simplifier when compiling Rules1 with -O -dcore-lint (was: Core lint error in simplifier when compiling Rules1 with -O -prof -dcore-lint) In-Reply-To: <045.64be924d003e88a5dbf3c5cb9b9fa49c@haskell.org> References: <045.64be924d003e88a5dbf3c5cb9b9fa49c@haskell.org> Message-ID: <060.7d2977829b0688cdf1f2e8a0191cf397@haskell.org> #11643: Core lint error in simplifier when compiling Rules1 with -O -dcore-lint -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/Rules1 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- @@ -1,1 +1,1 @@ - Running `make TEST=Rules1 WAY=profasm` results in a core lint error (see + Running `make TEST=Rules1 WAY=optasm` results in a core lint error (see @@ -33,1 +33,1 @@ - $ ghc-8.0.1 -O -prof Rules1.hs -dcore-lint + $ ghc-8.0.1 -O Rules1.hs -dcore-lint New description: Running `make TEST=Rules1 WAY=optasm` results in a core lint error (see attachment) with ghc-8.0.1-rc2. This is the code: {{{#!hs {-# LANGUAGE TypeFamilies #-} module Rules1 where class C a where data T a instance (C a, C b) => C (a,b) where data T (a,b) = TPair (T a) (T b) mapT :: (C a, C b) => (a -> b) -> T a -> T b {-# NOINLINE mapT #-} -- Otherwwise we get a warning from the rule mapT = undefined zipT :: (C a, C b) => T a -> T b -> T (a,b) {-# NOINLINE [1] zipT #-} zipT = undefined {-# RULES "zipT/mapT" forall f x y. zipT (mapT f x) y = mapT (\(x,y) -> (f x, y)) (zipT x y) #-} }}} {{{ $ ghc-8.0.1 -O Rules1.hs -dcore-lint }}} This is a regression from 7.10.3, and core lint errors are bad, so setting priority to highest. -- Comment (by thomie): Update: also without `-prof`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 18:58:41 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 18:58:41 -0000 Subject: [GHC] #11644: Core lint error in result of Specialise for TEST=T3220 WAY=optasm (was: Core lint error in result of Specialise for TEST=T3220 WAY=profasm) In-Reply-To: <045.682eeaccfb8fedc9aed75a81ae76afb5@haskell.org> References: <045.682eeaccfb8fedc9aed75a81ae76afb5@haskell.org> Message-ID: <060.2a790179b8ca0009ba5958734f9cba40@haskell.org> #11644: Core lint error in result of Specialise for TEST=T3220 WAY=optasm -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T3220, | indexed- | types/should_compile/ColInference3 Blocked By: | Blocking: Related Tickets: #11371, #11643 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- @@ -30,1 +30,1 @@ - $ ghc-8.0.1 T3220.hs -prof -O -dcore-lint + $ ghc-8.0.1 T3220.hs -O -dcore-lint New description: This is the code: {{{ {-# LANGUAGE TypeFamilies, ScopedTypeVariables#-} module T3220 where class Foo m where type Bar m :: * action :: m -> Bar m -> m right x m = action m (Right x) right' :: (Either a b ~ Bar m, Foo m) => b -> m -> m right' x m = action m (Right x) instance Foo Int where type Bar Int = Either Int Int action m a = either (*) (+) a m instance Foo Float where type Bar Float = Either Float Float action m a = either (*) (+) a m foo = print $ right (1::Int) (3 :: Int) bar = print $ right (1::Float) (3 :: Float) }}} Invocation: {{{ $ ghc-8.0.1 T3220.hs -O -dcore-lint }}} {{{ [1 of 1] Compiling T3220 ( T3220.hs, T3220.o ) *** Core Lint errors : in result of Specialise *** : warning: In the expression: action @ Float $fFooFloat m_ayb ((Right @ Float @ Float x_aya) `cast` (Sub (Sym cobox_aUe) :: Either a_aU3 b_aU4 ~R# Bar m_aU1)) cobox_aUe :: Bar m_aU1 ~# Either a_aU3 b_aU4 [LclId[CoVarId], Str=DmdType] is out of scope }}} Interestingly, with HEAD (2aee41960aa00fe09a2cd1983e02c15e06013037), it hits an assert from #11371. {{{ =====> T3220(profasm) 12 of 21 [0, 11, 0] cd ./indexed-types/should_compile && "/home/thomas/ghc- validate/inplace/test spaces/ghc-stage2" -c T3220.hs -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-warn-missed-specialisations -fno-ghci-history -O -prof -static -auto-all > T3220.comp.stderr 2>&1 Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160221 for x86_64-unknown-linux): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/types/TyCoRep.hs:1942:51 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:2076:17 in ghc:TyCoRep substCo, called at compiler/coreSyn/CoreSubst.hs:605:20 in ghc:CoreSubst in_scope InScope {x_axS m_axT $caction_a1dp $caction_a1dR right right' foo bar $tcFoo $tc'C:Foo $fFooFloat $fFooInt $trModule a_s1fZ a_s1g0 a_s1g1 a_s1g2} tenv [aTT :-> Float, aTV :-> Float, aTW :-> Float] cenv [] tys [] cos [Sub (Sym cobox_aU6)] needInScope [aU6 :-> cobox_aU6] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This is a regression from 7.10.3. Setting priority=highest. -- Comment (by thomie): Update: also without `-prof`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 19:20:47 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 19:20:47 -0000 Subject: [GHC] #10691: certain operations in new integer-gmp are too lazy In-Reply-To: <047.5a091b0736d5db136f703c98736ac583@haskell.org> References: <047.5a091b0736d5db136f703c98736ac583@haskell.org> Message-ID: <062.d6ba739775bc9398ead0dd33e8722ef4@haskell.org> #10691: certain operations in new integer-gmp are too lazy -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.2.1 Component: libraries | Version: 7.10.1 (other) | 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.2.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 19:49:29 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 19:49:29 -0000 Subject: [GHC] #10873: Bad error message for incorrect pattern synonym signature In-Reply-To: <049.1015737e7e3a324fd7db7cc49a97b354@haskell.org> References: <049.1015737e7e3a324fd7db7cc49a97b354@haskell.org> Message-ID: <064.1072c9669b2f45312b25e681353eb02e@haskell.org> #10873: Bad error message for incorrect pattern synonym signature -------------------------------------+------------------------------------- Reporter: mpickering | Owner: rdragon Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1866 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"116528c8429257a0ae855251fd266547bb23d01d/ghc" 116528c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="116528c8429257a0ae855251fd266547bb23d01d" Improve pattern synonym error messages (add `PatSynOrigin`) Adds a new data constructor `PatSynOrigin Bool Name` to the `CtOrigin` data type. This allows for better error messages when the origin of a wanted constraint is a pattern synonym declaration. Fixes T10873. Reviewers: mpickering, simonpj, austin, thomie, bgamari Reviewed By: simonpj, thomie, bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1866 GHC Trac Issues: #10873 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 20:05:22 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 20:05:22 -0000 Subject: [GHC] #11619: GHC.Stats documentation error In-Reply-To: <044.1939889567efc47e98f7bce777e30688@haskell.org> References: <044.1939889567efc47e98f7bce777e30688@haskell.org> Message-ID: <059.505ec4c844efa93e227b7f3daef96d05@haskell.org> #11619: GHC.Stats documentation error -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: merge Priority: low | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged in ae49f3dac7f6197f3928b2fd9dc38600e83c102f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 20:15:19 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 20:15:19 -0000 Subject: [GHC] #11626: type variable out of scope core lint error when compiling attoparsec In-Reply-To: <044.3b54a1a1868c7f532f99f416b8fae60d@haskell.org> References: <044.3b54a1a1868c7f532f99f416b8fae60d@haskell.org> Message-ID: <059.7204140f576ef39867c75f3553bdab52@haskell.org> #11626: type variable out of scope core lint error when compiling attoparsec -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Looks to me like this should have been instantiated at `Text`; seems like this might be a bug in the SpecConstr pass. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 20:26:52 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 20:26:52 -0000 Subject: [GHC] #10217: Provide link to GPG signature on download page. In-Reply-To: <042.3be3cfd04f796daabfe8f3ac5fc1b22c@haskell.org> References: <042.3be3cfd04f796daabfe8f3ac5fc1b22c@haskell.org> Message-ID: <057.05173e4e4d53991374c8e6313fcd4c0b@haskell.org> #10217: Provide link to GPG signature on download page. -------------------------------------+------------------------------------- Reporter: f-a | Owner: bgamari Type: feature request | Status: closed Priority: highest | Milestone: 8.0.1 Component: Documentation | Version: Resolution: fixed | Keywords: GPG, | signature Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: Thanks for bringing this to my attention thomie. I've implemented this and updated the 7.10.3 release download page. All future releases should look similar. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 20:47:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 20:47:55 -0000 Subject: [GHC] #8710: Overlapping patterns warning misplaced In-Reply-To: <047.1f227e0dac37dd7309646386f280164b@haskell.org> References: <047.1f227e0dac37dd7309646386f280164b@haskell.org> Message-ID: <062.e9abc419211e88e88e9f8fcca1409f87@haskell.org> #8710: Overlapping patterns warning misplaced -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1910, Wiki Page: | Phab:D1920 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 21:11:08 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 21:11:08 -0000 Subject: [GHC] #393: functions without implementations In-Reply-To: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> References: <047.8e9c859b4db83c0d687094f53af0d886@haskell.org> Message-ID: <062.0888204d1edf4e87acb6ed27cbb37405@haskell.org> #393: functions without implementations -------------------------------------+------------------------------------- Reporter: c_maeder | Owner: Type: feature request | Status: closed Priority: normal | Milestone: ? Component: Compiler (Type | Version: None checker) | Resolution: wontfix | 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 Iceland_jack): I am in favour of this, see also #11367 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 21:11:18 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 21:11:18 -0000 Subject: [GHC] #11642: Typechecker doesn't use evidence available from pattern synonym? In-Reply-To: <046.32db5cb4e79f0588d07e2dbd35cff7c7@haskell.org> References: <046.32db5cb4e79f0588d07e2dbd35cff7c7@haskell.org> Message-ID: <061.35143d96693d68164d31542ec3ccf891@haskell.org> #11642: Typechecker doesn't use evidence available from pattern synonym? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 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 bgamari): The problem isn't actually the pattern synonym at all. Even the straightforward nested-case approach fails in the same way, {{{#!hs buildApp :: TypeRepX -> TypeRepX -> TypeRepX buildApp (TypeRepX f) (TypeRepX x) = case typeRepKind f of TypeApp (TypeApp ty arg) res -> case eqTypeRep trArrow ty of Just HRefl -> case eqTypeRep arg x of Just HRefl -> TypeRepX $ TypeApp f x }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 21:22:55 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 21:22:55 -0000 Subject: [GHC] #11642: Typechecker doesn't use evidence available from pattern synonym? In-Reply-To: <046.32db5cb4e79f0588d07e2dbd35cff7c7@haskell.org> References: <046.32db5cb4e79f0588d07e2dbd35cff7c7@haskell.org> Message-ID: <061.f4858e4e8c8fa6bcef139ea112b0024e@haskell.org> #11642: Typechecker doesn't use evidence available from pattern synonym? -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 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 bgamari): * cc: simonpj (added) Comment: Make sure Simon sees this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 21:38:35 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 21:38:35 -0000 Subject: [GHC] #11645: Heap profiling - hp2ps: samples out of sequence Message-ID: <045.b3866e053eb1eb6cf46e7327a6d7e479@haskell.org> #11645: Heap profiling - hp2ps: samples out of sequence -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: #664 Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- `make TEST=hpc_fork WAY=prof` is failing, but it has nothing to do with `hpc`. {{{ hp2ps: hpc_fork.hp, line 9, samples out of sequence hp2ps error when processing heap profile for hpc_fork }}} hpc_fork.hs: {{{ module main where import system.posix.process import control.concurrent main = do pid1 <- forkprocess $ do threaddelay 100000 pid2 <- forkprocess $ do threaddelay 100000 print () }}} To reproduce: {{{ $ ghc-8.0.1 hpc_fork.hs -fforce-recomp -prof $ ./hpc_fork +RTS -hc $ hp2ps hpc_fork.hp }}} Example hpc_fork.hp: {{{ JOB "hpc_fork +RTS -hc" DATE "Thu Feb 25 22:37 2016" SAMPLE_UNIT "seconds" VALUE_UNIT "bytes" BEGIN_SAMPLE 0.000000 END_SAMPLE 0.000000 BEGIN_SAMPLE 0.005672 END_SAMPLE 0.005672 BEGIN_SAMPLE 0.003167 END_SAMPLE 0.003167 BEGIN_SAMPLE 0.003311 END_SAMPLE 0.003311 }}} This is a regression from 7.10.3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 21:39:28 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 21:39:28 -0000 Subject: [GHC] #11642: Heterogeneous type equality evidence ignored (was: Typechecker doesn't use evidence available from pattern synonym?) In-Reply-To: <046.32db5cb4e79f0588d07e2dbd35cff7c7@haskell.org> References: <046.32db5cb4e79f0588d07e2dbd35cff7c7@haskell.org> Message-ID: <061.6214d3b0014cb2eab2429ac77c066a31@haskell.org> #11642: Heterogeneous type equality evidence ignored -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 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: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 21:39:43 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 21:39:43 -0000 Subject: [GHC] #11645: Heap profiling - hp2ps: samples out of sequence In-Reply-To: <045.b3866e053eb1eb6cf46e7327a6d7e479@haskell.org> References: <045.b3866e053eb1eb6cf46e7327a6d7e479@haskell.org> Message-ID: <060.b22fae63d31b55b428d2a1e342982152@haskell.org> #11645: Heap profiling - hp2ps: samples out of sequence -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | libraries/hpc/tests/fork/hpc_fork Blocked By: | Blocking: Related Tickets: #664 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => libraries/hpc/tests/fork/hpc_fork -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 21:46:56 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 21:46:56 -0000 Subject: [GHC] #11646: Make pattern synonym export type mismatch a warning Message-ID: <045.9eb8b2d1f35f468ff5981bb2e5b0840b@haskell.org> #11646: Make pattern synonym export type mismatch a warning -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.0.1-rc2 (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: -------------------------------------+------------------------------------- As I understand it, attempting to associate a pattern synonym with a type constructor that it "obviously" doesn't match is an error. This is strange for two reasons: 1. An "erroneous" association cannot compromise type safety. 2. The test is incomplete. Therefore, I believe such mismatches should lead to warnings instead of errors. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 21:48:01 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 21:48:01 -0000 Subject: [GHC] #11642: Heterogeneous type equality evidence ignored In-Reply-To: <046.32db5cb4e79f0588d07e2dbd35cff7c7@haskell.org> References: <046.32db5cb4e79f0588d07e2dbd35cff7c7@haskell.org> Message-ID: <061.8aa837376aaf2a9d92c38f85b312551f@haskell.org> #11642: Heterogeneous type equality evidence ignored -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 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 bgamari): Judging by the `-ddump-tc-trace` output (for the fully expanded `case` version given in comment:2), the problem is that this wanted is unsolved, {{{ (~#) k_a1Lg[ssk] k_a1Lg[ssk] x_a1Li[ssk] ((TYPE |> _N -> Sym cobox_a1Mi) 'Lifted) (CNonCanonical)} }}} given these givens, {{{ (~#) * * k_a1L4[ssk] (f_a1Ld[ssk] x_a1Le[ssk]) (~#) (k_a1Lc[ssk] -> *) (k_a1Lc[ssk] -> *) f_a1Ld[ssk] (f_a1Lh[ssk] x_a1Li[ssk]) (~#) * * (* -> * -> *) (k_a1Lg[ssk] -> k_a1Lc[ssk] -> *) (~#) (* -> * -> *) (k_a1Lg[ssk] -> k_a1Lc[ssk] -> *) (->) f_a1Lh[ssk] (~#) * * k_a1Lg[ssk] k_a1L6[ssk] (~#) k_a1Lg[ssk] k_a1L6[ssk] x_a1Li[ssk] a_a1L7[ssk] }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 21:56:20 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 21:56:20 -0000 Subject: [GHC] #11646: Make pattern synonym export type mismatch a warning In-Reply-To: <045.9eb8b2d1f35f468ff5981bb2e5b0840b@haskell.org> References: <045.9eb8b2d1f35f468ff5981bb2e5b0840b@haskell.org> Message-ID: <060.e18627f2d381c274d830c7b649cb37ed@haskell.org> #11646: Make pattern synonym export type mismatch a warning -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Keywords: Resolution: | PatternSynonyms 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: | PatternSynonyms/AssociatingSynonyms| -------------------------------------+------------------------------------- Changes (by thomie): * cc: mpickering, rdragon (added) * keywords: => PatternSynonyms * wikipage: => PatternSynonyms/AssociatingSynonyms Comment: dfeuer: do you have an example, so the PatternSynonyms experts have something to work with. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 22:24:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 22:24:38 -0000 Subject: [GHC] #11643: Core lint error in simplifier when compiling Rules1 with -O -dcore-lint In-Reply-To: <045.64be924d003e88a5dbf3c5cb9b9fa49c@haskell.org> References: <045.64be924d003e88a5dbf3c5cb9b9fa49c@haskell.org> Message-ID: <060.1d5b350fb5a1b583f553ee95ee1840c4@haskell.org> #11643: Core lint error in simplifier when compiling Rules1 with -O -dcore-lint -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/Rules1 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"90fa8cf2bf1677545c3f4a8bc967b1674822e90a/ghc" 90fa8cf2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="90fa8cf2bf1677545c3f4a8bc967b1674822e90a" Mark tests for #11643, #11644, #11645 and #9406 expect_broken For opt_ways or prof_ways only. indexed-types/should_compile/all.T called setTestOpts to not run the tests with opt_ways. Since I'm finding regressions for opt_ways, I removed it. This only makes a difference when running `./validate --slow` or `make slowtest`. Update submodule hpc. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 22:24:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 22:24:38 -0000 Subject: [GHC] #11644: Core lint error in result of Specialise for TEST=T3220 WAY=optasm In-Reply-To: <045.682eeaccfb8fedc9aed75a81ae76afb5@haskell.org> References: <045.682eeaccfb8fedc9aed75a81ae76afb5@haskell.org> Message-ID: <060.7b18655c1b83ab8ada27670007c162cb@haskell.org> #11644: Core lint error in result of Specialise for TEST=T3220 WAY=optasm -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: indexed- | types/should_compile/T3220, | indexed- | types/should_compile/ColInference3 Blocked By: | Blocking: Related Tickets: #11371, #11643 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"90fa8cf2bf1677545c3f4a8bc967b1674822e90a/ghc" 90fa8cf2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="90fa8cf2bf1677545c3f4a8bc967b1674822e90a" Mark tests for #11643, #11644, #11645 and #9406 expect_broken For opt_ways or prof_ways only. indexed-types/should_compile/all.T called setTestOpts to not run the tests with opt_ways. Since I'm finding regressions for opt_ways, I removed it. This only makes a difference when running `./validate --slow` or `make slowtest`. Update submodule hpc. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 22:24:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 22:24:38 -0000 Subject: [GHC] #11645: Heap profiling - hp2ps: samples out of sequence In-Reply-To: <045.b3866e053eb1eb6cf46e7327a6d7e479@haskell.org> References: <045.b3866e053eb1eb6cf46e7327a6d7e479@haskell.org> Message-ID: <060.bea9bc8d022b20efce71e3e0b5c98caf@haskell.org> #11645: Heap profiling - hp2ps: samples out of sequence -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | libraries/hpc/tests/fork/hpc_fork Blocked By: | Blocking: Related Tickets: #664 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"90fa8cf2bf1677545c3f4a8bc967b1674822e90a/ghc" 90fa8cf2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="90fa8cf2bf1677545c3f4a8bc967b1674822e90a" Mark tests for #11643, #11644, #11645 and #9406 expect_broken For opt_ways or prof_ways only. indexed-types/should_compile/all.T called setTestOpts to not run the tests with opt_ways. Since I'm finding regressions for opt_ways, I removed it. This only makes a difference when running `./validate --slow` or `make slowtest`. Update submodule hpc. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 22:24:38 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 22:24:38 -0000 Subject: [GHC] #9406: unexpected failure for T7837(profasm) In-Reply-To: <042.6cf0b0817037f8cfba5de5652e277f8a@haskell.org> References: <042.6cf0b0817037f8cfba5de5652e277f8a@haskell.org> Message-ID: <057.7261df919d0784b067465e51b8af2226@haskell.org> #9406: unexpected failure for T7837(profasm) -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.8.3 Resolution: | Keywords: T7837 Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: T7837 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"90fa8cf2bf1677545c3f4a8bc967b1674822e90a/ghc" 90fa8cf2/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="90fa8cf2bf1677545c3f4a8bc967b1674822e90a" Mark tests for #11643, #11644, #11645 and #9406 expect_broken For opt_ways or prof_ways only. indexed-types/should_compile/all.T called setTestOpts to not run the tests with opt_ways. Since I'm finding regressions for opt_ways, I removed it. This only makes a difference when running `./validate --slow` or `make slowtest`. Update submodule hpc. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 22:46:21 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 22:46:21 -0000 Subject: [GHC] #11642: Heterogeneous type equality evidence ignored In-Reply-To: <046.32db5cb4e79f0588d07e2dbd35cff7c7@haskell.org> References: <046.32db5cb4e79f0588d07e2dbd35cff7c7@haskell.org> Message-ID: <061.5d1e0f75ff6400c5ed73f0d71cec5dbc@haskell.org> #11642: Heterogeneous type equality evidence ignored -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 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 bgamari): Oddly enough, if I ask for the same wanted in a slightly more direct way, things work, {{{#!hs data IsFunc' a b where IsFunc' :: forall x y a b (f :: x -> y). IsFunc' (TypeRep f) (TypeRep x) buildApp :: forall k. forall (a :: k) b. TypeRep a -> TypeRep b -> IsFunc' (TypeRep a) (TypeRep b) buildApp f x = case typeRepKind f of TypeApp (TypeApp ty arg) res -> case eqTypeRep trArrow ty of Just HRefl -> case eqTypeRep arg x of Just HRefl -> IsFunc' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Feb 25 22:55:05 2016 From: ghc-devs at haskell.org (GHC) Date: Thu, 25 Feb 2016 22:55:05 -0000 Subject: [GHC] #10752: Print which warning-flag controls/enabled an emitted warning In-Reply-To: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> References: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> Message-ID: <057.f6d112f8199aae3aed37c1889b7cc7af@haskell.org> #10752: Print which warning-flag controls/enabled an emitted warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: barrucadu Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1943 Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"bb5afd3c274011c5ea302210b4c290ec1f83209c/ghc" bb5afd3/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bb5afd3c274011c5ea302210b4c290ec1f83209c" Print which warning-flag controls an emitted warning Both gcc and clang tell which warning flag a reported warning can be controlled with, this patch makes ghc do the same. More generally, this allows for annotated compiler output, where an optional annotation is displayed in brackets after the severity. This also adds a new flag `-f(no-)show-warning-groups` to control whether to show which warning-group (such as `-Wall` or `-Wcompat`) a warning belongs to. This flag is on by default. This implements #10752 Reviewed By: quchen, bgamari, hvr Differential Revision: https://phabricator.haskell.org/D1943 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 08:21:27 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 08:21:27 -0000 Subject: [GHC] #11647: GHCi does not honour implicit `module Main (main) where` for re-exported `main`s Message-ID: <042.bdc5ad3927502391eb42801db38e8cb4@haskell.org> #11647: GHCi does not honour implicit `module Main (main) where` for re-exported `main`s -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.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: -------------------------------------+------------------------------------- Haskell2010 states: > An abbreviated form of module, consisting only of the module body, is permitted. If this is used, the header is assumed to be `module Main(main) where`. Consider the following two modules: {{{#!hs -- module Main (main) where import Main2 (main) }}} {{{#!hs module Main2 (main) where main :: IO () main = return () }}} A non-interactive GHC happily compiles `ghc --make Main`, however, GHCi fails with {{{ $ ghci Main.hs GHCi, version 7.10.3: http://www.haskell.org/ghc/ :? for help unknown option: 'c' [1 of 2] Compiling Main2 ( Main2.hs, interpreted ) [2 of 2] Compiling Main ( Main.hs, interpreted ) Main.hs:1:1: The IO action ?main? is not exported by module ?Main? Failed, modules loaded: Main2. }}} For GHCi we need to uncomment the explicit `module Main (main) where` line to make it work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 08:21:55 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 08:21:55 -0000 Subject: [GHC] #11647: GHCi does not honour implicit `module Main (main) where` for re-exported `main`s In-Reply-To: <042.bdc5ad3927502391eb42801db38e8cb4@haskell.org> References: <042.bdc5ad3927502391eb42801db38e8cb4@haskell.org> Message-ID: <057.26b04c72eb0d4ed8aa8d354257dad4fa@haskell.org> #11647: GHCi does not honour implicit `module Main (main) where` for re-exported `main`s -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by hvr): * failure: None/Unknown => GHC rejects valid program -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 10:52:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 10:52:45 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 Message-ID: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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: -------------------------------------+------------------------------------- As mentioned in https://mail.haskell.org/pipermail/ghc- devs/2016-February/011455.html, the following tests currently hit an assert when the compiler is built with -DDEBUG: {{{ patsyn/should_compile MoreEx [exit code non-0] (normal) patsyn/should_compile T11224b [exit code non-0] (normal) polykinds MonoidsTF [exit code non-0] (normal) polykinds T11480b [exit code non-0] (normal) polykinds T11523 [exit code non-0] (normal) }}} {{{ Compile failed (status 256) errors were: ghc-stage2: panic! (the 'impossible' happened) (GHC version 8.1.20160218 for x86_64-unknown-linux): ASSERT failed! CallStack (from HasCallStack): assertPprPanic, called at compiler/types/TyCoRep.hs:1932:56 in ghc:TyCoRep checkValidSubst, called at compiler/types/TyCoRep.hs:1991:17 in ghc:TyCoRep substTys, called at compiler/types/TyCoRep.hs:2012:14 in ghc:TyCoRep substTheta, called at compiler/typecheck/TcPatSyn.hs:255:20 in ghc:TcPatSyn in_scope InScope {d_ap0 c_apv} tenv [ap1 :-> c_apv[tau:5]] tenvFVs [aps :-> t_aps[tau:1], apv :-> c_apv[tau:5]] cenv [] cenvFVs [] tys [] cos [] }}} Phab:D1951 contained a stopgap patch, but since it wasn't accepted, I'll just mark the tests as expect_broken for this ticket, so that other developers aren't bothered by this issue. The offending commit is b5292557dcf2e3844b4837172230575d40a8917e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 10:53:38 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 10:53:38 -0000 Subject: [GHC] #11649: LLVM code generator produces mal-formed LLVM blocks Message-ID: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> #11649: LLVM code generator produces mal-formed LLVM blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (CodeGen) | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It appears that the recent addition (673efccb3b348e9daf23d9e65460691bbea8586e) of some instances for types in `GHC.Generics` has uncovered a bug in the LLVM code generator (at least on ARM). `libraries/base/GHC/Generics.hs` fails to compile with, {{{ Entry block to function must not have predecessors! label %cjGw /home/ben/ghc/roots/llvm-3.7/bin/opt: libraries/base/GHC/Generics.ll: error: input module is broken! }}} The problematic block in question appears to be, {{{ define internal ghccc void @rhSw_info$def(i32* noalias nocapture %Base_Arg, i32* noalias nocapture %Sp_Arg, i32* noal ias nocapture %Hp_Arg, i32 %R1_Arg, i32 %R2_Arg, i32 %R3_Arg, i32 %R4_Arg, i32 %SpLim_Arg) align 4 nounwind prefix <{ i32, i32, i32}><{i32 65541, i32 0, i32 15}> { clpH: br label %clpH } }}} Which arose from this Cmm, {{{ ==================== Post control-flow optimisations ==================== 2016-02-26 10:39:28.656744 UTC [section ""data" . lvl_rhSw_closure" { lvl_rhSw_closure: const lvl_rhSw_info; }, lvl_rhSw_entry() // [] { info_tbl: [(clpH, label: lvl_rhSw_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 5} })] stack_info: arg_space: 0 updfr_space: Nothing } {offset clpH: goto clpH; // CmmBranch } }] }}} Which arose from this input Cmm, {{{ ==================== Cmm produced by new codegen ==================== 2016-02-26 10:39:28.611641 UTC [section ""data" . lvl_rhSw_closure" { lvl_rhSw_closure: const lvl_rhSw_info; }, lvl_rhSw_entry() // [R2] { info_tbl: [(clpD, label: lvl_rhSw_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 5} })] stack_info: arg_space: 4 updfr_space: Just 4 } {offset clpD: _shWa::P32 = R2; // CmmAssign goto clpz; // CmmBranch clpz: if ((old + 0) - < SpLim) goto clpE; else goto clpF; // CmmCondBranch clpE: R2 = _shWa::P32; // CmmAssign R1 = lvl_rhSw_closure; // CmmAssign call (stg_gc_fun)(R2, R1) args: 4, res: 0, upd: 4; // CmmCall clpF: goto clpy; // CmmBranch clpy: goto shWb; // CmmBranch shWb: goto clpH; // CmmBranch clpH: goto shWb; // CmmBranch } }] }}} Which arose from this STG, {{{#!hs lvl_rhSw :: forall a_a99i. GHC.Generics.U1 a_a99i -> GHC.Generics.U1 [a_a99i] [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType x, Unf=OtherCon []] = sat-only \r [eta_shWa] let-no-escape { some_v_shWb [Occ=LoopBreaker] :: GHC.Generics.U1 [a12_a99i] [LclId, Str=DmdType b] = NO_CCS[] \u [] some_v_shWb; } in some_v_shWb; }}} Which arose from this Core, {{{#!hs lvl_rhSw :: forall a_a99i. U1 a_a99i -> U1 [a_a99i] [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType x] lvl_rhSw = \ (@ a12_a99i) _ [Occ=Dead] -> letrec { some_v_a99l [Occ=LoopBreaker] :: U1 [a12_a99i] [LclId, Str=DmdType b] some_v_a99l = some_v_a99l; } in some_v_a99l }}} Which is apparently the body of the `some` implementation in the `Alternative` instance for `GHC.Generics.U1`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 10:56:18 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 10:56:18 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 In-Reply-To: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> References: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> Message-ID: <060.bd6629fbe174c89b0d58886d9f97b53e@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Happily I'm about to commit a proper fix for this. (I think.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 11:14:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 11:14:51 -0000 Subject: [GHC] #11649: LLVM code generator produces mal-formed LLVM blocks In-Reply-To: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> References: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> Message-ID: <061.141f53e010e556c0edf1a5b89485a875@haskell.org> #11649: LLVM code generator produces mal-formed LLVM blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- @@ -106,1 +106,1 @@ - Which arose from this Core, + Which arose from this Core (from `-ddump-simpl`), New description: It appears that the recent addition (673efccb3b348e9daf23d9e65460691bbea8586e) of some instances for types in `GHC.Generics` has uncovered a bug in the LLVM code generator (at least on ARM). `libraries/base/GHC/Generics.hs` fails to compile with, {{{ Entry block to function must not have predecessors! label %cjGw /home/ben/ghc/roots/llvm-3.7/bin/opt: libraries/base/GHC/Generics.ll: error: input module is broken! }}} The problematic block in question appears to be, {{{ define internal ghccc void @rhSw_info$def(i32* noalias nocapture %Base_Arg, i32* noalias nocapture %Sp_Arg, i32* noal ias nocapture %Hp_Arg, i32 %R1_Arg, i32 %R2_Arg, i32 %R3_Arg, i32 %R4_Arg, i32 %SpLim_Arg) align 4 nounwind prefix <{ i32, i32, i32}><{i32 65541, i32 0, i32 15}> { clpH: br label %clpH } }}} Which arose from this Cmm, {{{ ==================== Post control-flow optimisations ==================== 2016-02-26 10:39:28.656744 UTC [section ""data" . lvl_rhSw_closure" { lvl_rhSw_closure: const lvl_rhSw_info; }, lvl_rhSw_entry() // [] { info_tbl: [(clpH, label: lvl_rhSw_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 5} })] stack_info: arg_space: 0 updfr_space: Nothing } {offset clpH: goto clpH; // CmmBranch } }] }}} Which arose from this input Cmm, {{{ ==================== Cmm produced by new codegen ==================== 2016-02-26 10:39:28.611641 UTC [section ""data" . lvl_rhSw_closure" { lvl_rhSw_closure: const lvl_rhSw_info; }, lvl_rhSw_entry() // [R2] { info_tbl: [(clpD, label: lvl_rhSw_info rep:HeapRep static { Fun {arity: 1 fun_type: ArgSpec 5} })] stack_info: arg_space: 4 updfr_space: Just 4 } {offset clpD: _shWa::P32 = R2; // CmmAssign goto clpz; // CmmBranch clpz: if ((old + 0) - < SpLim) goto clpE; else goto clpF; // CmmCondBranch clpE: R2 = _shWa::P32; // CmmAssign R1 = lvl_rhSw_closure; // CmmAssign call (stg_gc_fun)(R2, R1) args: 4, res: 0, upd: 4; // CmmCall clpF: goto clpy; // CmmBranch clpy: goto shWb; // CmmBranch shWb: goto clpH; // CmmBranch clpH: goto shWb; // CmmBranch } }] }}} Which arose from this STG, {{{#!hs lvl_rhSw :: forall a_a99i. GHC.Generics.U1 a_a99i -> GHC.Generics.U1 [a_a99i] [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType x, Unf=OtherCon []] = sat-only \r [eta_shWa] let-no-escape { some_v_shWb [Occ=LoopBreaker] :: GHC.Generics.U1 [a12_a99i] [LclId, Str=DmdType b] = NO_CCS[] \u [] some_v_shWb; } in some_v_shWb; }}} Which arose from this Core (from `-ddump-simpl`), {{{#!hs lvl_rhSw :: forall a_a99i. U1 a_a99i -> U1 [a_a99i] [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType x] lvl_rhSw = \ (@ a12_a99i) _ [Occ=Dead] -> letrec { some_v_a99l [Occ=LoopBreaker] :: U1 [a12_a99i] [LclId, Str=DmdType b] some_v_a99l = some_v_a99l; } in some_v_a99l }}} Which is apparently the body of the `some` implementation in the `Alternative` instance for `GHC.Generics.U1`. -- Comment (by bgamari): The second-to-last pass output by `verbose-core2core` has this analogue to `lvl_rhSw`, {{{#!hs lvl_sfQZ :: forall a_a99i. U1 a_a99i -> U1 [a_a99i] [LclId, Arity=1, Str=DmdType x] lvl_sfQZ = \ (@ a_a99i) (eta_a99j :: U1 a_a99i) -> letrec { some_v_a99l [Occ=LoopBreaker] :: U1 [a_a99i] [LclId, Str=DmdType b] some_v_a99l = case eta_a99j of wild_XkW [Dmd=] { U1 -> some_v_a99l }; } in some_v_a99l }}} It seems that this arose out of, {{{#!hs $csome_a87d [Occ=LoopBreaker] :: forall a_a3vu. U1 a_a3vu -> U1 [a_a3vu] [LclId, Arity=1, Str=DmdType] $csome_a87d = GHC.Base.$dmsome @ U1 GHC.Generics.$fAlternativeU1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 11:19:18 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 11:19:18 -0000 Subject: [GHC] #11649: LLVM code generator produces mal-formed LLVM blocks In-Reply-To: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> References: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> Message-ID: <061.09cfd9c2c78eb4182bc826dbbff030c3@haskell.org> #11649: LLVM code generator produces mal-formed LLVM blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I was strangely unable to reproduce this on x86_64 with LLVM 3.7 and 2b46fa060092537d93ba1b3b1a4c4b6fa607a5c6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 11:22:28 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 11:22:28 -0000 Subject: [GHC] #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler In-Reply-To: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> References: <045.918a9569238e9d04ed4e2e3a730bb569@haskell.org> Message-ID: <060.dbb2334e6584e2d23ebb3125a9015137@haskell.org> #10382: Template Haskell (non-quasi) quotes should work with stage 1 compiler -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: patch Priority: high | Milestone: 8.0.1 Component: Template Haskell | Version: 7.11 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:D876 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"bbfff2298d7ea7d0f4e590f8137f43a651e8f61d/ghc" bbfff229/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="bbfff2298d7ea7d0f4e590f8137f43a651e8f61d" Unconditionally handle TH known key names. Previously, we didn't add Template Haskell key names to the list of known uniques when building a stage 1 compiler. But with f16ddcee0c64a92ab911a7841a8cf64e3ac671fd we may refer to TH names even in stage 1, and this was causing uniques to not be setup properly. Signed-off-by: Edward Z. Yang Test Plan: validate and run stage1 test suite Reviewers: osa1, austin, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1520 GHC Trac Issues: #10382 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 11:24:44 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 11:24:44 -0000 Subject: [GHC] #11649: LLVM code generator produces mal-formed LLVM blocks In-Reply-To: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> References: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> Message-ID: <061.11c0cbf93ea8870efde27fb6906b7d67@haskell.org> #11649: LLVM code generator produces mal-formed LLVM blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): This simpler testcase reproduces the issue on ARM, {{{#!hs {-# LANGUAGE NoImplicitPrelude #-} module Test where import GHC.Base data U1 p = U1 instance Functor U1 where fmap f U1 = U1 instance Applicative U1 where pure _ = U1 U1 <*> U1 = U1 instance Alternative U1 where empty = U1 U1 <|> U1 = U1 }}} {{{ $ inplace/bin/ghc-stage1 Test.hs -O -fforce-recomp [1 of 1] Compiling Test ( Test.hs, Test.o ) Entry block to function must not have predecessors! label %cPR /home/ben/ghc/roots/llvm-3.7/bin/opt: /tmp/ghc26431_0/ghc_2.ll: error: input module is broken! `opt' failed in phase `LLVM Optimiser'. (Exit code: 1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 11:32:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 11:32:51 -0000 Subject: [GHC] #11649: LLVM code generator produces mal-formed LLVM blocks In-Reply-To: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> References: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> Message-ID: <061.2925d20e2d00476ae8ca4124166e93e4@haskell.org> #11649: LLVM code generator produces mal-formed LLVM blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): Not just a problem on Arm. Happens on x86_64 as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 11:33:10 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 11:33:10 -0000 Subject: [GHC] #11649: LLVM code generator produces mal-formed LLVM blocks In-Reply-To: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> References: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> Message-ID: <061.068ac96a3e11c7efe8b11a12c9dc2e30@haskell.org> #11649: LLVM code generator produces mal-formed LLVM blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by erikd): * cc: erikd (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 11:34:49 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 11:34:49 -0000 Subject: [GHC] #11649: LLVM code generator produces mal-formed LLVM blocks In-Reply-To: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> References: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> Message-ID: <061.ecab5b770cf2256831e1380a157463bd@haskell.org> #11649: LLVM code generator produces mal-formed LLVM blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Explicitly defining `many _ = U1; some _ = U1` works around the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 11:44:44 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 11:44:44 -0000 Subject: [GHC] #11649: LLVM code generator produces mal-formed LLVM blocks In-Reply-To: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> References: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> Message-ID: <061.5eafcfc115dd98c1673c3f799cb3250a@haskell.org> #11649: LLVM code generator produces mal-formed LLVM blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Indeed if you compile with the native code generator you'll find that compilation succeeds as expected, but the resulting executable loops when you attempt to evaluate `some U1`. I suspect overriding `some` and `many` is the right thing to do in this particular case. That being said, apart from the `Generics` issue, there is clearly an LLVM code generator issue as well: we shouldn't be passing code to LLVM that it can't compile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 11:48:35 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 11:48:35 -0000 Subject: [GHC] #11649: LLVM code generator produces mal-formed LLVM blocks In-Reply-To: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> References: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> Message-ID: <061.d6254a28cf92155f799e7923ed8c10b6@haskell.org> #11649: LLVM code generator produces mal-formed LLVM blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #9043 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * related: => #9043 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 11:54:51 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 11:54:51 -0000 Subject: [GHC] #11650: Default definitions for Alternative(some, many) can easily blow up Message-ID: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> #11650: Default definitions for Alternative(some, many) can easily blow up -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Consider this case (taken from #11649) {{{#!hs import Control.Applicative data U1 p = U1 instance Functor U1 where fmap f U1 = U1 instance Applicative U1 where pure _ = U1 U1 <*> U1 = U1 instance Alternative U1 where empty = U1 U1 <|> U1 = U1 instance Show (U1 p) where show U1 = "U1" main = print (some U1) }}} This looks fine, right? Wrong, {{{ $ ./Main Main: <> }}} It seems that the default definitions of `some` and `many` will produce looping code in these cases (although it's not entirely clear to me which cases "these" cases are). I suppose this is due to the fact that `U1` will always "succeed". We should ensure that this is noted in the documentation to ensure that users don't end up with accidentally bottoming instances. Well, consider what happens -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 11:55:03 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 11:55:03 -0000 Subject: [GHC] #11650: Default definitions for Alternative(some, many) can easily blow up In-Reply-To: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> References: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> Message-ID: <061.e01f7bc8465502eebae8d8ffecfdd932@haskell.org> #11650: Default definitions for Alternative(some, many) can easily blow up -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: core-libraries-committe (removed) * cc: core-libraries-committee (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 11:55:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 11:55:46 -0000 Subject: [GHC] #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up (was: Default definitions for Alternative(some, many) can easily blow up) In-Reply-To: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> References: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> Message-ID: <061.6865267a5197f9cde9231d5ea7cb8b01@haskell.org> #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: core-libraries-committee (removed) * cc: core-libraries-committee@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 11:57:02 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 11:57:02 -0000 Subject: [GHC] #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up In-Reply-To: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> References: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> Message-ID: <061.54f848f594a11386d1aa8fb5476d0a63@haskell.org> #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -30,0 +30,10 @@ + Of course, this can be avoided by simply defining `some` and `many` in + `U1`'s `Alternative` instance, + {{{#!hs + instance Alternative U1 where + empty = U1 + U1 <|> U1 = U1 + some U1 = U1 + many U1 = U1 + }}} + New description: Consider this case (taken from #11649) {{{#!hs import Control.Applicative data U1 p = U1 instance Functor U1 where fmap f U1 = U1 instance Applicative U1 where pure _ = U1 U1 <*> U1 = U1 instance Alternative U1 where empty = U1 U1 <|> U1 = U1 instance Show (U1 p) where show U1 = "U1" main = print (some U1) }}} This looks fine, right? Wrong, {{{ $ ./Main Main: <> }}} Of course, this can be avoided by simply defining `some` and `many` in `U1`'s `Alternative` instance, {{{#!hs instance Alternative U1 where empty = U1 U1 <|> U1 = U1 some U1 = U1 many U1 = U1 }}} It seems that the default definitions of `some` and `many` will produce looping code in these cases (although it's not entirely clear to me which cases "these" cases are). I suppose this is due to the fact that `U1` will always "succeed". We should ensure that this is noted in the documentation to ensure that users don't end up with accidentally bottoming instances. Well, consider what happens -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 12:02:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 12:02:46 -0000 Subject: [GHC] #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up In-Reply-To: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> References: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> Message-ID: <061.308aff749651797b65f3292637ff0a10@haskell.org> #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by bgamari: @@ -45,3 +45,2 @@ - should ensure that this is noted in the documentation to ensure that users - don't end up with accidentally bottoming instances. - Well, consider what happens + should note this in the documentation to ensure that users don't end up + with accidentally bottoming instances. New description: Consider this case (taken from #11649) {{{#!hs import Control.Applicative data U1 p = U1 instance Functor U1 where fmap f U1 = U1 instance Applicative U1 where pure _ = U1 U1 <*> U1 = U1 instance Alternative U1 where empty = U1 U1 <|> U1 = U1 instance Show (U1 p) where show U1 = "U1" main = print (some U1) }}} This looks fine, right? Wrong, {{{ $ ./Main Main: <> }}} Of course, this can be avoided by simply defining `some` and `many` in `U1`'s `Alternative` instance, {{{#!hs instance Alternative U1 where empty = U1 U1 <|> U1 = U1 some U1 = U1 many U1 = U1 }}} It seems that the default definitions of `some` and `many` will produce looping code in these cases (although it's not entirely clear to me which cases "these" cases are). I suppose this is due to the fact that `U1` will always "succeed". We should note this in the documentation to ensure that users don't end up with accidentally bottoming instances. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 13:48:29 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 13:48:29 -0000 Subject: [GHC] #11649: LLVM code generator produces mal-formed LLVM blocks In-Reply-To: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> References: <046.ced8b12036dacbe8c8f7262f13026df2@haskell.org> Message-ID: <061.6cc962e2cd7eaa3d34a57e6c1a95e2e7@haskell.org> #11649: LLVM code generator produces mal-formed LLVM blocks -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (CodeGen) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #9043 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 13:49:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 13:49:45 -0000 Subject: [GHC] #11429: Make unrecognised `-W` flags a warning rather than an error In-Reply-To: <042.40e6ba51faf91f5384d7881fa490aec2@haskell.org> References: <042.40e6ba51faf91f5384d7881fa490aec2@haskell.org> Message-ID: <057.56376a2ef19ff1798e453615841c1bc9@haskell.org> #11429: Make unrecognised `-W` flags a warning rather than an error -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1830, Wiki Page: Design/Warnings | Phab:D1942 -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 14:27:54 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 14:27:54 -0000 Subject: [GHC] #11651: Allow plugins to define built-in rules Message-ID: <046.77c73b278fc4c153a0c0fa875f2b0ef3@haskell.org> #11651: Allow plugins to define built-in rules -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- Conal Eliot has an application in which he wants a plugin to add some new `BuiltinRules` to the `mg_rules` of the `ModGuts` of the module being compiled. He needs a built-in rule (which runs some custom code) rather than a vanilla `CoreRule` (which pattern-matches the argument). But then he got a GHC panic {{{ get a GHC panic: ?No match in record selector ru_args?. }}} Turns out it comes from these lines in `OccAnal` {{{ imp_rule_edges = foldr (plusVarEnv_C unionVarSet) emptyVarEnv [ mapVarEnv (const maps_to) (exprFreeIds arg `delVarSetList` ru_bndrs imp_rule) | imp_rule <- imp_rules , let maps_to = exprFreeIds (ru_rhs imp_rule) `delVarSetList` ru_bndrs imp_rule , arg <- ru_args imp_rule ] }}} This code is just working out what locally-defined variables should be kept alive by the `mg_rules` for imported Ids. But `BuiltinRules` don't have any `ru_args`. Easy fix: just don't traverse builtin rules in this scan. In Conal's case, the rules that his plugin adds certainly don't mention locally- defined Ids. I'll do this shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 14:31:45 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 14:31:45 -0000 Subject: [GHC] #11651: Allow plugins to define built-in rules In-Reply-To: <046.77c73b278fc4c153a0c0fa875f2b0ef3@haskell.org> References: <046.77c73b278fc4c153a0c0fa875f2b0ef3@haskell.org> Message-ID: <061.51cad3aae9751583b4892158c07f8c2c@haskell.org> #11651: Allow plugins to define built-in rules -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => highest * milestone: => 8.0.1 Comment: Making high priority for 8.0 because it's a one-line, low-risk change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 14:53:25 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 14:53:25 -0000 Subject: [GHC] #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up In-Reply-To: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> References: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> Message-ID: <061.c9e5b0a1b57f254ed426af304c4f1812@haskell.org> #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): We could also fix this issue by making the `Applicative` instance less strict: {{{#!hs instance Applicative U1 where U1 <*> _ = U1 }}} I'm not sure which is the best approach. `Proxy` (which is isomorphic to `U1`) doesn't pattern-match on its arguments in ''any'' of its instances, which allows it to short-circuit in a lot of possibly diverging computations. Then again, `Proxy` doesn't have an `Alternative`/`MonadPlus` instance for some reason... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 15:18:46 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 15:18:46 -0000 Subject: [GHC] #11640: Panic because of "updateRole" In-Reply-To: <051.a2aa2f07407d8fdc661bf953d330894a@haskell.org> References: <051.a2aa2f07407d8fdc661bf953d330894a@haskell.org> Message-ID: <066.d876f3c20a38c29c8459fd16b8879992@haskell.org> #11640: Panic because of "updateRole" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Same thing happens in HEAD too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 17:02:48 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 17:02:48 -0000 Subject: [GHC] #11640: Panic because of "updateRole" In-Reply-To: <051.a2aa2f07407d8fdc661bf953d330894a@haskell.org> References: <051.a2aa2f07407d8fdc661bf953d330894a@haskell.org> Message-ID: <066.63034875b008ffc57a9fcf3fd3a46e31@haskell.org> #11640: Panic because of "updateRole" -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: goldfire Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 17:14:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 17:14:33 -0000 Subject: [GHC] #11601: Strict Haskell is not as strict as it probably should be In-Reply-To: <046.29f8763fff117f73c640765f0dcb62b0@haskell.org> References: <046.29f8763fff117f73c640765f0dcb62b0@haskell.org> Message-ID: <061.d97d34438b7a2725347ca4bf114a2bbd@haskell.org> #11601: Strict Haskell is not as strict as it probably should be -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"e3f341f334d89c88f388d8e864ed8762d0890a64/ghc" e3f341f/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e3f341f334d89c88f388d8e864ed8762d0890a64" Fix and refactor strict pattern bindings This patch was triggered by Trac #11601, where I discovered that -XStrict was really not doing the right thing. In particular, f y = let !(Just x) = blah[y] in body[y,x] This was evaluating 'blah' but not pattern matching it against Just until x was demanded. This is wrong. The patch implements a new semantics which ensures that strict patterns (i.e. ones with an explicit bang, or with -XStrict) are evaluated fully when bound. * There are extensive notes in DsUtils: Note [mkSelectorBinds] * To do this I found I need one-tuples; see Note [One-tuples] in TysWiredIn I updated the user manual to give the new semantics }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 17:14:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 17:14:33 -0000 Subject: [GHC] #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` In-Reply-To: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> References: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> Message-ID: <057.38e5b894eca549bfe7ef61ee6baf0077@haskell.org> #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 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 Simon Peyton Jones ): In [changeset:"7496be5c0ab96bcc9ab70ab873aa561674b7789d/ghc" 7496be5c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="7496be5c0ab96bcc9ab70ab873aa561674b7789d" Exclude TyVars from the constraint solver There is a general invariant that the constraint solver doesn't see TyVars, only TcTyVars. But when checking the generic-default signature of a class, we called checkValidType on the generic-default type, which had the class TyVar free. That in turn meant that it wasn't considered during flattening, which led to the error reported in Trac #11608. The fix is simple: call checkValidType on the /closed/ type. Easy. While I was at it, I added a bunch of ASSERTs about the TcTyVar invariant. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 17:14:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 17:14:33 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 In-Reply-To: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> References: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> Message-ID: <060.a345eed24243a4c811f4f9b005fdcd68@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b4dfe04aa77bb2d0ce2c7d82cab5e4425e0b738c/ghc" b4dfe04/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b4dfe04aa77bb2d0ce2c7d82cab5e4425e0b738c" Fix kind generalisation for pattern synonyms We were failing to zonk, after quantifyTyVars, and that left un-zonked type variables in the final PatSyn. This fixes the patsyn/ problems in Trac #11648, but not the polykinds/ ones. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 17:14:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 17:14:33 -0000 Subject: [GHC] #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 In-Reply-To: <042.261e60284e26a798be48364a9348d62e@haskell.org> References: <042.261e60284e26a798be48364a9348d62e@haskell.org> Message-ID: <057.8351cc887c8e17d33703b93a7b41754b@haskell.org> #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"4ddfe1352e20d805a0ad6eeea0400ee218023bfb/ghc" 4ddfe13/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="4ddfe1352e20d805a0ad6eeea0400ee218023bfb" Get the right in-scope set in specUnfolding This fixes Trac #11600 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 17:14:33 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 17:14:33 -0000 Subject: [GHC] #11651: Allow plugins to define built-in rules In-Reply-To: <046.77c73b278fc4c153a0c0fa875f2b0ef3@haskell.org> References: <046.77c73b278fc4c153a0c0fa875f2b0ef3@haskell.org> Message-ID: <061.813faf7dbe5ac72beef4f6e8ce3b5c27@haskell.org> #11651: Allow plugins to define built-in rules -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"e193f66669eda712e832a05349055f8e518f770a/ghc" e193f666/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e193f66669eda712e832a05349055f8e518f770a" Filter out BuiltinRules in occurrence analysis Fixes Trac #11651. Merge to 8.0. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 17:16:07 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 17:16:07 -0000 Subject: [GHC] #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 In-Reply-To: <042.261e60284e26a798be48364a9348d62e@haskell.org> References: <042.261e60284e26a798be48364a9348d62e@haskell.org> Message-ID: <057.42c47ea5faea9519c9fa9cbcea4963ce@haskell.org> #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge Comment: I believe this is done. Can you check, and merge to the 8.0 branch? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 17:18:36 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 17:18:36 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 In-Reply-To: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> References: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> Message-ID: <060.462e5bd503af1ddd2bc113f6cbf6b02d@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Still open: the `polykinds/` tests. So leave the ticket open. But pls merge the above patch to 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 17:20:06 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 17:20:06 -0000 Subject: [GHC] #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` In-Reply-To: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> References: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> Message-ID: <057.85be4d906f5812b4fd0e6f53d774fbfc@haskell.org> #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 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): NB: the `isTcTyVar` could conceivably cause extra ASSERT failures when DEBUG is on. I didn't see any, but keep your eyes open. However, ignoring them (ie no `-DDEBUG`) is simply what happens today and is fine. So things will not be worse. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 17:21:30 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 17:21:30 -0000 Subject: [GHC] #11601: Strict Haskell is not as strict as it probably should be In-Reply-To: <046.29f8763fff117f73c640765f0dcb62b0@haskell.org> References: <046.29f8763fff117f73c640765f0dcb62b0@haskell.org> Message-ID: <061.b20e4141fab23336222f0ec9891d2f75@haskell.org> #11601: Strict Haskell is not as strict as it probably should be -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deSugar/should_run/T11601 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => deSugar/should_run/T11601 Comment: Yay. This is much better. Merge to 8.0 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 17:21:50 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 17:21:50 -0000 Subject: [GHC] #11651: Allow plugins to define built-in rules In-Reply-To: <046.77c73b278fc4c153a0c0fa875f2b0ef3@haskell.org> References: <046.77c73b278fc4c153a0c0fa875f2b0ef3@haskell.org> Message-ID: <061.f6a63ef150dcc46a8390b875f9a28337@haskell.org> #11651: Allow plugins to define built-in rules -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 17:24:01 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 17:24:01 -0000 Subject: [GHC] #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` In-Reply-To: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> References: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> Message-ID: <057.566f8d94301c5945adae6626fe53d36d@haskell.org> #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11608 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => typecheck/should_compile/T11608 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 17:28:13 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 17:28:13 -0000 Subject: [GHC] #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up In-Reply-To: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> References: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> Message-ID: <061.a67f1f29f65c41c92d744b0a2a896709@haskell.org> #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): The only reason it doesn't have `Alternative` and `MonadPlus` instances is that I didn't think of them! (Similarly, `MonadZip`) I have absolutely no objection to adding them. If someone concocts a patch to add them to `base`, I'll readily retroactively add them to the `tagged` package, and Ryan can incorporate backports of them into `base-orphans`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 17:32:42 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 17:32:42 -0000 Subject: [GHC] #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up In-Reply-To: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> References: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> Message-ID: <061.1d9da49d85dc45ce4f14b9f78284439f@haskell.org> #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): OK. I noticed that `U1` is also missing a `MonadPlus` instance as well, so we can scoop up all the missing `U1`/`Proxy` instances in another patch. So now that question remains: do we fix `U1`'s `Alternative` instance by overriding `some`/`many`, or do we fix it by making `<*>` lazier? I'm inclined to pick the former, since `U1` is almost always used in the context of GHC generics, and strictly pattern-matching on it is almost always what you intend to do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 17:34:05 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 17:34:05 -0000 Subject: [GHC] #11646: Make pattern synonym export type mismatch a warning In-Reply-To: <045.9eb8b2d1f35f468ff5981bb2e5b0840b@haskell.org> References: <045.9eb8b2d1f35f468ff5981bb2e5b0840b@haskell.org> Message-ID: <060.7f55374a905955c8548d9aec88223f4d@haskell.org> #11646: Make pattern synonym export type mismatch a warning -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Keywords: Resolution: | PatternSynonyms 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: | PatternSynonyms/AssociatingSynonyms| -------------------------------------+------------------------------------- Comment (by mpickering): You understand correctly. The check would be better but it is difficult to specify when a pattern synonym should and should not be allowed to bundled. Do you have an example where the check prevents you from writing the program you want to write? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 17:43:29 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 17:43:29 -0000 Subject: [GHC] #11611: ghc panics In-Reply-To: <051.3fd20af57abcb0290dbd3de8c0429ea4@haskell.org> References: <051.3fd20af57abcb0290dbd3de8c0429ea4@haskell.org> Message-ID: <066.25f53c9807b19e44e799de6ea18a47a2@haskell.org> #11611: ghc panics -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11563, #11520, | Differential Rev(s): #11516, #11399 | Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"ef7b1d5efb17fdca14ee1269f79b9c08d4f8636f/ghc" ef7b1d5/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ef7b1d5efb17fdca14ee1269f79b9c08d4f8636f" Test Trac #11611 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 17:43:41 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 17:43:41 -0000 Subject: [GHC] #11611: ghc panics In-Reply-To: <051.3fd20af57abcb0290dbd3de8c0429ea4@haskell.org> References: <051.3fd20af57abcb0290dbd3de8c0429ea4@haskell.org> Message-ID: <066.9001037b3096f3c501b97efcd084280a@haskell.org> #11611: ghc panics -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | polykinds/T11611 Blocked By: | Blocking: Related Tickets: #11563, #11520, | Differential Rev(s): #11516, #11399 | Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => polykinds/T11611 * status: new => closed * resolution: => fixed Comment: Both programs produce a kind error; neither panics. So I think we are good and I'll close. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 18:01:58 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 18:01:58 -0000 Subject: [GHC] #4029: ghci leaks memory when loading a file In-Reply-To: <046.7e3cd0db8a339c9dc956ab26c7e5c0ec@haskell.org> References: <046.7e3cd0db8a339c9dc956ab26c7e5c0ec@haskell.org> Message-ID: <061.6da1a2d0b6d3af9e0b4760376fc22d6a@haskell.org> #4029: ghci leaks memory when loading a file -------------------------------------+------------------------------------- Reporter: blarsen | Owner: jme Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: GHCi | Version: Resolution: | Keywords: memory leak 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:D1950 Wiki Page: | -------------------------------------+------------------------------------- Changes (by jme): * status: new => patch * differential: => Phab:D1950 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 18:07:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 18:07:04 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 In-Reply-To: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> References: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> Message-ID: <060.47d03ef8973032b8841397d5844a166e@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => merge * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 18:42:02 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 18:42:02 -0000 Subject: [GHC] #11651: Allow plugins to define built-in rules In-Reply-To: <046.77c73b278fc4c153a0c0fa875f2b0ef3@haskell.org> References: <046.77c73b278fc4c153a0c0fa875f2b0ef3@haskell.org> Message-ID: <061.2aef9b85e0cddd349816ed6da1b6058a@haskell.org> #11651: Allow plugins to define built-in rules -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- @@ -1,2 +1,2 @@ - Conal Eliot has an application in which he wants a plugin to add some new - `BuiltinRules` to the `mg_rules` of the `ModGuts` of the module being + Conal Elliott has an application in which he wants a plugin to add some + new `BuiltinRules` to the `mg_rules` of the `ModGuts` of the module being New description: Conal Elliott has an application in which he wants a plugin to add some new `BuiltinRules` to the `mg_rules` of the `ModGuts` of the module being compiled. He needs a built-in rule (which runs some custom code) rather than a vanilla `CoreRule` (which pattern-matches the argument). But then he got a GHC panic {{{ get a GHC panic: ?No match in record selector ru_args?. }}} Turns out it comes from these lines in `OccAnal` {{{ imp_rule_edges = foldr (plusVarEnv_C unionVarSet) emptyVarEnv [ mapVarEnv (const maps_to) (exprFreeIds arg `delVarSetList` ru_bndrs imp_rule) | imp_rule <- imp_rules , let maps_to = exprFreeIds (ru_rhs imp_rule) `delVarSetList` ru_bndrs imp_rule , arg <- ru_args imp_rule ] }}} This code is just working out what locally-defined variables should be kept alive by the `mg_rules` for imported Ids. But `BuiltinRules` don't have any `ru_args`. Easy fix: just don't traverse builtin rules in this scan. In Conal's case, the rules that his plugin adds certainly don't mention locally- defined Ids. I'll do this shortly. -- Comment (by conal): Fixed spelling of my last name. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 20:09:54 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 20:09:54 -0000 Subject: [GHC] #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up In-Reply-To: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> References: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> Message-ID: <061.3e04cd60c85888d6bca22095f8d846b6@haskell.org> #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by ekmett): I mostly lack a preference here, but if we make it match the semantics of `Proxy` it'd avoid complications later on if we were to ever decide to make the leap and unify `(:*:)` with `Product`, `(:+:)` with `Sum`, `U1` with `Proxy`, etc. rather than retain two of each. I'm not proposing that we unify these things today, when and if we decide to do so it should be carefully deliberated, with possible wins weighed against ecosystem disruption, but anything that takes them further apart for trivial reasons forecloses interesting possible futures for no real gain. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 21:41:04 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 21:41:04 -0000 Subject: [GHC] #8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved In-Reply-To: <047.29151f124b3d302c83805a31219608ea@haskell.org> References: <047.29151f124b3d302c83805a31219608ea@haskell.org> Message-ID: <062.bd8dec36ec56cc56d0c756839d8f35e3@haskell.org> #8025: "During interactive linking, GHCi couldn't find the following symbol" typechecker error with TemplateHaskell involved -------------------------------------+------------------------------------- Reporter: mojojojo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.6.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: Incorrect | Test Case: warning at compile-time | Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gershomb): * cc: gershomb (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Feb 26 22:00:56 2016 From: ghc-devs at haskell.org (GHC) Date: Fri, 26 Feb 2016 22:00:56 -0000 Subject: [GHC] #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up In-Reply-To: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> References: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> Message-ID: <061.78a9352aec449be1f6e0aed5f917c6d2@haskell.org> #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"890e2bb72b9953ca3e6990911b4cf6e51a0dd0f8/ghc" 890e2bb/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="890e2bb72b9953ca3e6990911b4cf6e51a0dd0f8" GHC.Generics: Ensure some, many for U1 don't bottom Reviewers: austin, hvr, ekmett, RyanGlScott Reviewed By: RyanGlScott Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1952 GHC Trac Issues: #11650 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 01:35:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 01:35:45 -0000 Subject: [GHC] #11009: Errors reading stdin on Windows In-Reply-To: <045.6536b0b9909b2bd209cff5be9e0bf17c@haskell.org> References: <045.6536b0b9909b2bd209cff5be9e0bf17c@haskell.org> Message-ID: <060.ed61442f3bab549fa5fa620d11427f3f@haskell.org> #11009: Errors reading stdin on Windows -------------------------------------+------------------------------------- Reporter: ncreep | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by gershomb): * cc: gershomb (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 02:06:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 02:06:57 -0000 Subject: [GHC] #7337: GHC does not generate great code for bit-level rotation In-Reply-To: <042.1bdaae6f89f84d88685747f45c6e6712@haskell.org> References: <042.1bdaae6f89f84d88685747f45c6e6712@haskell.org> Message-ID: <057.f20496b054b6c18104dd1efb44b82ec2@haskell.org> #7337: GHC does not generate great code for bit-level rotation -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.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 jberryman): FWIW I'm trying my hand at this, though it may take me a while as it's my first time working on GHC, and I'm not sure how much time I'll have to spend. It looks like I can take my lead from the byteswap patches (`git show 5ae238504 da7db19 1c5b0511 c5d5e3ac 86ca77ecb`). Also I'm considering just implementing a rotateR primop since that's what ARM supports (I think) and my use case only has constant rotate values which I know GHC would simplify to a single instruction if Data.Bits.rotateL was implemented in terms of the rotateR primop. Hm, but that would be extra bad for people who have variable left rotate values which also might be `0`, because they's need to do a AND mask and a subtraction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 03:24:46 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 03:24:46 -0000 Subject: [GHC] #11652: Cyclical dependencies aren't reported in pure functions Message-ID: <045.2f44d98317e387d0b4bcd9258037d7f2@haskell.org> #11652: Cyclical dependencies aren't reported in pure functions -------------------------------------+------------------------------------- Reporter: keynan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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: -------------------------------------+------------------------------------- No compile error. found in 7.10.2 {{{#!hs main :: IO () main = do putStrLn $ "Hello " ++ (show x) where x = y + 1 y = x + 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 06:00:24 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 06:00:24 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.f7a5b1d7a0640b8cbdfac76036ef0174@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------- Reporter: ocharles | Owner: dreixel Type: feature request | Status: merge Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9766 | Blocking: Related Tickets: #8778 | Differential Rev(s): Phab:D1937 Wiki Page: | -------------------------------------+------------------------------------- Comment (by erikd): This patch tirggered the LLVM code gen bug in #11649. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 07:21:56 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 07:21:56 -0000 Subject: [GHC] #11652: Cyclical dependencies aren't reported in pure functions In-Reply-To: <045.2f44d98317e387d0b4bcd9258037d7f2@haskell.org> References: <045.2f44d98317e387d0b4bcd9258037d7f2@haskell.org> Message-ID: <060.b6c72585d8e1eff97f4a83faada0b29b@haskell.org> #11652: Cyclical dependencies aren't reported in pure functions -------------------------------------+------------------------------------- Reporter: keynan | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 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 ezyang): Solving this problem in general would amount to solving the halting problem but I would definitely like to see some heuristics to give warnings in cases like this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 12:39:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 12:39:35 -0000 Subject: [GHC] #11475: Lint should check for inexhaustive alternatives In-Reply-To: <046.fd80dcd8f8868c23b12a0a5bfb5d7bcb@haskell.org> References: <046.fd80dcd8f8868c23b12a0a5bfb5d7bcb@haskell.org> Message-ID: <061.bfd0b7a3820457ea30d7e135b3b71f59@haskell.org> #11475: Lint should check for inexhaustive alternatives -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by jscholl): Using the {{{CRPResult}}} did indeed help, I can now compile a few more modules. However, the next false positive is a little bit more complicated as there is no evidence I could use attached to it as far as I can tell. Suppose there is an expression {{{ foo x = case x of A -> ... B -> ... y -> error $ "foo" ++ (case y of C -> "C" D -> "D") }}} This is fine and works as expected. But now GHC decides to float out the expression, yielding: {{{ lvl y = error $ "foo" ++ (case y of C -> "C" D -> "D") foo x = case x of A -> ... B -> ... y -> lvl y }}} I don't see where GHC would record that {{{y}}} can only match {{{C}}} and {{{D}}}. I think it doesn't do it anywhere, most likely because no one needed that information until today. A possible solution might be to look for unexported local functions which are non-exhaustive and record the set of allowed constructors for their arguments. All calls to such a function would then be required to only included the correct possible constructors. Or is there a better way? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 13:09:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 13:09:21 -0000 Subject: [GHC] #11123: Arm: checkProddableBlock: invalid fixup in runtime linker In-Reply-To: <044.92e8587d5182968d745cf903b273dfec@haskell.org> References: <044.92e8587d5182968d745cf903b273dfec@haskell.org> Message-ID: <059.92a47b6702b60f18df3df8e984dcca5a@haskell.org> #11123: Arm: checkProddableBlock: invalid fixup in runtime linker ----------------------------------------+------------------------------ Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | 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 => closed * resolution: => fixed Comment: I'm going to close this under the assumption that it was fixed in fixing Thumb linkage. Re-open if not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 13:54:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 13:54:19 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.e9e7e95c0e656dcdf6eb1fe27e7c9c4c@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Changes (by slyfox): * Attachment "0001-c-codegen-split-external-symbol-prototypes-EF_.patch" added. 0001-c-codegen-split-external-symbol-prototypes-EF_.patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 13:55:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 13:55:40 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.c3e67e463d005b1d9e9366db736ea368@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by slyfox): Please try the 0001-c-codegen-split-external-symbol-prototypes-EF_.patch patch on vanilla gcc. I hope it will workaround a problem on m68k without breaking other platforms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 14:10:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 14:10:12 -0000 Subject: [GHC] #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up In-Reply-To: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> References: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> Message-ID: <061.07c3cec63d169208a99509e6316de58e@haskell.org> #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): RyanGlScott, I've committed the patch in comment:9 as a stop-gap measure; I hope you'll have a chance to add the instance mentioned in comment:7 and when you do so fix `U1` to your liking. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 14:11:12 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 14:11:12 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.dc8699d91918f4629efbdd4b143f094c@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by glaubitz): Replying to [comment:13 slyfox]: > Please try the 0001-c-codegen-split-external-symbol-prototypes-EF_.patch patch on vanilla gcc. Thanks. I'll give it a shot and report back. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 14:11:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 14:11:59 -0000 Subject: [GHC] #11631: Delete Windows line endings from testsuite files In-Reply-To: <045.8492becc3679f262ada10d15b1971fb2@haskell.org> References: <045.8492becc3679f262ada10d15b1971fb2@haskell.org> Message-ID: <060.602b27dc14ade0fec1a6fcbebb4287b3@haskell.org> #11631: Delete Windows line endings from testsuite files -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 14:13:17 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 14:13:17 -0000 Subject: [GHC] #11603: Fix/clarify documentation in GHC.Stats In-Reply-To: <047.d444ccdc28f8e376bec099daa1b220c9@haskell.org> References: <047.d444ccdc28f8e376bec099daa1b220c9@haskell.org> Message-ID: <062.20023a0c9ef743363617d1713c8cb86a@haskell.org> #11603: Fix/clarify documentation in GHC.Stats -------------------------------------+------------------------------------- Reporter: dcturner | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 8.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:D1929 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 14:13:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 14:13:18 -0000 Subject: [GHC] #11601: Strict Haskell is not as strict as it probably should be In-Reply-To: <046.29f8763fff117f73c640765f0dcb62b0@haskell.org> References: <046.29f8763fff117f73c640765f0dcb62b0@haskell.org> Message-ID: <061.3328d0cbc38416f1c9dae7c804f4e8ff@haskell.org> #11601: Strict Haskell is not as strict as it probably should be -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | deSugar/should_run/T11601 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 14:41:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 14:41:06 -0000 Subject: [GHC] #11585: Overload the static form to reduce verbosity In-Reply-To: <056.41ddf713d7e0fe1de83ff400ce602f67@haskell.org> References: <056.41ddf713d7e0fe1de83ff400ce602f67@haskell.org> Message-ID: <071.591e781726bffad58e36b0a8d947f8b3@haskell.org> #11585: Overload the static form to reduce verbosity -------------------------------------+------------------------------------- Reporter: | Owner: facundo.dominguez | facundo.dominguez Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1923 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 70287bceb5a339456179f08bfbe64c4fe2ff718a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 14:47:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 14:47:52 -0000 Subject: [GHC] #11521: Test failures for the `profasm` way when BUILD_PROF_LIBS=YES In-Reply-To: <045.daf56e9bd8ee4ad19ba9daea05cb163a@haskell.org> References: <045.daf56e9bd8ee4ad19ba9daea05cb163a@haskell.org> Message-ID: <060.b90131d753d19769d77f5130b7cfe68b@haskell.org> #11521: Test failures for the `profasm` way when BUILD_PROF_LIBS=YES -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Test Suite | 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 14:50:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 14:50:33 -0000 Subject: [GHC] #11612: Bug in ApplicativeDo In-Reply-To: <047.3e578efe5e273399089fa654398b6d79@haskell.org> References: <047.3e578efe5e273399089fa654398b6d79@haskell.org> Message-ID: <062.b1d03c72fbab3cbd31e3e82aa2b65c60@haskell.org> #11612: Bug in ApplicativeDo -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: merge Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged as e3020f26e322e0fcbc7ea2403479d6a734578bc8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 15:04:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 15:04:55 -0000 Subject: [GHC] #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 In-Reply-To: <042.261e60284e26a798be48364a9348d62e@haskell.org> References: <042.261e60284e26a798be48364a9348d62e@haskell.org> Message-ID: <057.446937774b0f029310cef4fc0f92007f@haskell.org> #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: merge Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged as c7d83f84a51c0f8b8e60bb824efa7830516f9da9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 15:26:08 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 15:26:08 -0000 Subject: [GHC] #11429: Make unrecognised `-W` flags a warning rather than an error In-Reply-To: <042.40e6ba51faf91f5384d7881fa490aec2@haskell.org> References: <042.40e6ba51faf91f5384d7881fa490aec2@haskell.org> Message-ID: <057.8a82949b59902baa03fdee41d32c23da@haskell.org> #11429: Make unrecognised `-W` flags a warning rather than an error -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1830, Wiki Page: Design/Warnings | Phab:D1942 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 3d345e8f1551b21980aeef9110463ecd2ee2686f. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 15:28:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 15:28:43 -0000 Subject: [GHC] #11619: GHC.Stats documentation error In-Reply-To: <044.1939889567efc47e98f7bce777e30688@haskell.org> References: <044.1939889567efc47e98f7bce777e30688@haskell.org> Message-ID: <059.e27a99cd321255536c33b1502aca761a@haskell.org> #11619: GHC.Stats documentation error -------------------------------------+------------------------------------- Reporter: orion | Owner: Type: bug | Status: closed Priority: low | Milestone: 8.0.1 Component: libraries/base | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 15:29:48 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 15:29:48 -0000 Subject: [GHC] #9917: ddump-llvm runs opt/llc even when -fllvm isnt set In-Reply-To: <045.a11323789867f7415acb20ec316ad1c7@haskell.org> References: <045.a11323789867f7415acb20ec316ad1c7@haskell.org> Message-ID: <060.16792d391f9e86cc310093eef62c7746@haskell.org> #9917: ddump-llvm runs opt/llc even when -fllvm isnt set -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: merge Priority: low | Milestone: 8.0.1 Component: Documentation | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged as c980640302e38801bf3642addb7c9f7c6be34cc7. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 15:29:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 15:29:55 -0000 Subject: [GHC] #9917: ddump-llvm runs opt/llc even when -fllvm isnt set In-Reply-To: <045.a11323789867f7415acb20ec316ad1c7@haskell.org> References: <045.a11323789867f7415acb20ec316ad1c7@haskell.org> Message-ID: <060.8b5d965c06c6909b41afd053ee78ad30@haskell.org> #9917: ddump-llvm runs opt/llc even when -fllvm isnt set -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: closed Priority: low | Milestone: 8.0.1 Component: Documentation | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 15:30:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 15:30:44 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 In-Reply-To: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> References: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> Message-ID: <060.6df672a75d274dc1f362b913d42b2583@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: merge Priority: normal | Milestone: 8.0.1 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged as 6fd8cf4c9f597af907b2fbb5721e1c16204f1a28. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 15:31:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 15:31:00 -0000 Subject: [GHC] #8710: Overlapping patterns warning misplaced In-Reply-To: <047.1f227e0dac37dd7309646386f280164b@haskell.org> References: <047.1f227e0dac37dd7309646386f280164b@haskell.org> Message-ID: <062.4e8d29b8da099be13cd37bf2a07e7374@haskell.org> #8710: Overlapping patterns warning misplaced -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: low | Milestone: 8.0.1 Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: | PatternMatchWarnings Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1910, Wiki Page: | Phab:D1920 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 680557c125021a1f248ef010418b1234d9a2aa4a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 15:31:04 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 15:31:04 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 In-Reply-To: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> References: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> Message-ID: <060.0bdccc2cca8c13ad2e4ad0a05e6a2748@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 15:32:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 15:32:57 -0000 Subject: [GHC] #11633: Record field order in a bidirectional pattern synonym match is order dependent In-Reply-To: <046.0c4427b2dcf79f3f6a57a5376b7a4d59@haskell.org> References: <046.0c4427b2dcf79f3f6a57a5376b7a4d59@haskell.org> Message-ID: <061.7e348d55aa0c8d3a8f9a2169d289034b@haskell.org> #11633: Record field order in a bidirectional pattern synonym match is order dependent -------------------------------------+------------------------------------- Reporter: bgamari | Owner: mpickering Type: bug | Status: merge Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: Resolution: | PatternSynonyms 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:D1949 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: => 8.0.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 15:33:10 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 15:33:10 -0000 Subject: [GHC] #11633: Record field order in a bidirectional pattern synonym match is order dependent In-Reply-To: <046.0c4427b2dcf79f3f6a57a5376b7a4d59@haskell.org> References: <046.0c4427b2dcf79f3f6a57a5376b7a4d59@haskell.org> Message-ID: <061.52715ba1b6a8789f437e89c56e1b4be8@haskell.org> #11633: Record field order in a bidirectional pattern synonym match is order dependent -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: Resolution: | PatternSynonyms 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:D1949 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => new * owner: mpickering => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 15:33:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 15:33:16 -0000 Subject: [GHC] #11633: Record field order in a bidirectional pattern synonym match is order dependent In-Reply-To: <046.0c4427b2dcf79f3f6a57a5376b7a4d59@haskell.org> References: <046.0c4427b2dcf79f3f6a57a5376b7a4d59@haskell.org> Message-ID: <061.6e90d21d65fdb810fc1a2fefdda610d2@haskell.org> #11633: Record field order in a bidirectional pattern synonym match is order dependent -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: Resolution: | PatternSynonyms 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:D1949 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 15:33:52 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 15:33:52 -0000 Subject: [GHC] #11651: Allow plugins to define built-in rules In-Reply-To: <046.77c73b278fc4c153a0c0fa875f2b0ef3@haskell.org> References: <046.77c73b278fc4c153a0c0fa875f2b0ef3@haskell.org> Message-ID: <061.46a913b80db88801b94ed253450d45d1@haskell.org> #11651: Allow plugins to define built-in rules -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 934022c088778303fcfac9c63d8c2fd4a4f1fdc2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 15:33:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 15:33:53 -0000 Subject: [GHC] #10752: Print which warning-flag controls/enabled an emitted warning In-Reply-To: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> References: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> Message-ID: <057.657b9a1f82e51b736420ca69740bae86@haskell.org> #10752: Print which warning-flag controls/enabled an emitted warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: barrucadu Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1943 Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"b9c697eefd34fcba3ab9c1f831baf7f651ad7503/ghc" b9c697ee/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b9c697eefd34fcba3ab9c1f831baf7f651ad7503" Print which flag controls emitted desugaring warnings This is extends bb5afd3c274011c5ea302210b4c290ec1f83209c to cover warnings emitted during the desugaring phase. This implements another part of #10752 Reviewed-by: quchen, bgamari Differential Revision: https://phabricator.haskell.org/D1954 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 15:34:23 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 15:34:23 -0000 Subject: [GHC] #11597: Optimize cmpTypeX In-Reply-To: <047.c45212e57d1b61470e39791921d06b96@haskell.org> References: <047.c45212e57d1b61470e39791921d06b96@haskell.org> Message-ID: <062.adf9bb5c9325ef646e58144afb05b010@haskell.org> #11597: Optimize cmpTypeX -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: fixed | 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:D1944 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 6f7baa0eb995b6cef8b9ae4ad0845f76a229bd3b. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 15:34:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 15:34:55 -0000 Subject: [GHC] #11607: ApplicativeDo easily foiled with `pure` In-Reply-To: <046.822f388a9e9f7e6ae598d3989cdd9275@haskell.org> References: <046.822f388a9e9f7e6ae598d3989cdd9275@haskell.org> Message-ID: <061.81bee2910bec06a089a197eceb856cb7@haskell.org> #11607: ApplicativeDo easily foiled with `pure` -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: fixed | Keywords: ApplicativeDo Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: ado/T11607 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1931 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 32e2d58c8b767d791dd79f5e77f39a776f784054. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 15:35:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 15:35:09 -0000 Subject: [GHC] #11612: Bug in ApplicativeDo In-Reply-To: <047.3e578efe5e273399089fa654398b6d79@haskell.org> References: <047.3e578efe5e273399089fa654398b6d79@haskell.org> Message-ID: <062.67a5520eadf69ece3b6b092965b25c75@haskell.org> #11612: Bug in ApplicativeDo -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 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: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 15:35:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 15:35:43 -0000 Subject: [GHC] #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 In-Reply-To: <042.261e60284e26a798be48364a9348d62e@haskell.org> References: <042.261e60284e26a798be48364a9348d62e@haskell.org> Message-ID: <057.cec77139661fed42d857c365c03cffd0@haskell.org> #11600: Panic (ASSERT failed) in compiler/types/TyCoRep.hs:1939 -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 15:36:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 15:36:31 -0000 Subject: [GHC] #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` In-Reply-To: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> References: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> Message-ID: <057.d7bf300378e2809e5558ae6950a0276a@haskell.org> #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11608 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as 7f15c2b8cd0b8c9f2e407b3a91a5541677df306b. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 15:36:57 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 15:36:57 -0000 Subject: [GHC] #11583: Make warning names more consistent In-Reply-To: <046.2c5f65cdcdffbe526873fdbd4a154741@haskell.org> References: <046.2c5f65cdcdffbe526873fdbd4a154741@haskell.org> Message-ID: <061.b418b4af889f3a98af429e0588c3cdd5@haskell.org> #11583: Make warning names more consistent -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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:D1939 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as e61e29081c8f73d3fa933f456fac49c51a9599db. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 15:37:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 15:37:30 -0000 Subject: [GHC] #11579: Bug in parser for named Haddock chunks since GHC 8.0.1-rc1 In-Reply-To: <050.4d0ef6c9d54d8fe326a15d5b3729d82a@haskell.org> References: <050.4d0ef6c9d54d8fe326a15d5b3729d82a@haskell.org> Message-ID: <065.b9dcd782ca2803b040406de3ce9f4f8d@haskell.org> #11579: Bug in parser for named Haddock chunks since GHC 8.0.1-rc1 -------------------------------------+------------------------------------- Reporter: SimonHengel | Owner: thomie Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 (Parser) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10398 | Differential Rev(s): Phab:D1935 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed Comment: Merged as a69542ba51f7dd1d77b2e16f2b3259263cc375f6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 16:00:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 16:00:33 -0000 Subject: [GHC] #11633: Record field order in a bidirectional pattern synonym match is order dependent In-Reply-To: <046.0c4427b2dcf79f3f6a57a5376b7a4d59@haskell.org> References: <046.0c4427b2dcf79f3f6a57a5376b7a4d59@haskell.org> Message-ID: <061.7f7ce60a5640c77456bbe7da488bff3c@haskell.org> #11633: Record field order in a bidirectional pattern synonym match is order dependent -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: Resolution: | PatternSynonyms 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:D1949 Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Merged to `master` in 52879d1f5d804bf1a32d11d9cefc36d7b6fea382. To `ghc-8.0` as 66029ccb2f98c2e7c1687b1eeb4e03750cbc263e. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 16:00:39 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 16:00:39 -0000 Subject: [GHC] #11633: Record field order in a bidirectional pattern synonym match is order dependent In-Reply-To: <046.0c4427b2dcf79f3f6a57a5376b7a4d59@haskell.org> References: <046.0c4427b2dcf79f3f6a57a5376b7a4d59@haskell.org> Message-ID: <061.63d97e7e4ae0250764afd706f1ff7341@haskell.org> #11633: Record field order in a bidirectional pattern synonym match is order dependent -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Keywords: Resolution: fixed | PatternSynonyms 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:D1949 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 16:19:33 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 16:19:33 -0000 Subject: [GHC] #11625: Data.Type.Equality is not Trustworthy In-Reply-To: <045.00b6470b73cd59812d630575ca77009a@haskell.org> References: <045.00b6470b73cd59812d630575ca77009a@haskell.org> Message-ID: <060.6c687216e1b8e13fd7aee7d0fc03157f@haskell.org> #11625: Data.Type.Equality is not Trustworthy -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.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:D1957 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1957 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 16:20:00 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 16:20:00 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.d05079a16b37c941e983c7e1a2eb2623@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Phab:D1956 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1956 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 16:24:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 16:24:43 -0000 Subject: [GHC] #10316: Move Typeable type-rep generation from use site to definition site In-Reply-To: <046.706fb26d1689686d9c617262ebfd6cc9@haskell.org> References: <046.706fb26d1689686d9c617262ebfd6cc9@haskell.org> Message-ID: <061.067c36edbed56800da37be96905cd633@haskell.org> #10316: Move Typeable type-rep generation from use site to definition site -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.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:D757 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * type: bug => task * resolution: => fixed Comment: This was merged quite some time ago (see #9858). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 16:58:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 16:58:59 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.c04846bc4fdae6c9210b77cdeb4a5b49@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: 11362 | Blocking: Related Tickets: #10424 | Differential Rev(s): Phab:D910, | Phab:D1073, Phab:D1133, Phab:D1192, | Phab:D1268, Phab:D1360, Phab:D1373, Wiki Page: | Phab:D1396, Phab:D1457, Phab:D1468, DeterministicBuilds | Phab:D1487, Phab:D1504, Phab:D1508 -------------------------------------+------------------------------------- Changes (by niteria): * wikipage: => DeterministicBuilds -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 17:08:05 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 17:08:05 -0000 Subject: [GHC] #10752: Print which warning-flag controls/enabled an emitted warning In-Reply-To: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> References: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> Message-ID: <057.cbb6aeded13eb335046b9a6bf1805a42@haskell.org> #10752: Print which warning-flag controls/enabled an emitted warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: barrucadu Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1943 Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"869d9c62d8329022f9f5504a92d2d74efec4f2e8/ghc" 869d9c62/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="869d9c62d8329022f9f5504a92d2d74efec4f2e8" Print which flag controls emitted lexer warnings This is extends bb5afd3c274011c5ea302210b4c290ec1f83209c to cover warnings emitted during lexing. This implements another part of #10752 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 17:26:24 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 17:26:24 -0000 Subject: [GHC] #10752: Print which warning-flag controls/enabled an emitted warning In-Reply-To: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> References: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> Message-ID: <057.242904a426b290606da2da3a85f061ca@haskell.org> #10752: Print which warning-flag controls/enabled an emitted warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: barrucadu Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1943 Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"82f200b74ac1ea8c5593e2909c0033eb251eeaf2/ghc" 82f200b/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="82f200b74ac1ea8c5593e2909c0033eb251eeaf2" Annotate `[-Wredundant-constraints]` in warnings (re #10752) This was missed in bb5afd3c274011c5ea302210b4c290ec1f83209c }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 17:47:13 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 17:47:13 -0000 Subject: [GHC] #10752: Print which warning-flag controls/enabled an emitted warning In-Reply-To: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> References: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> Message-ID: <057.61eaad012a4c2314ef60f6677e78cc8a@haskell.org> #10752: Print which warning-flag controls/enabled an emitted warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: barrucadu Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1943 Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"b6c61e372a1a783b32f1bbd1ceb446e89478a138/ghc" b6c61e37/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="b6c61e372a1a783b32f1bbd1ceb446e89478a138" Print which flag controls emitted SafeHaskell warnings This is extends bb5afd3c274011c5ea302210b4c290ec1f83209c to cover SafeHaskell warnings. This implements yet another part of #10752 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 18:09:35 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 18:09:35 -0000 Subject: [GHC] #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up In-Reply-To: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> References: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> Message-ID: <061.37d120d89b4086a7a8e02141015e5bca@haskell.org> #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): Replying to [comment:8 ekmett]: > I mostly lack a preference here, but if we make it match the semantics of `Proxy` it'd avoid complications later on if we were to ever decide to make the leap and unify `(:*:)` with `Product`, `(:+:)` with `Sum`, `U1` with `Proxy`, etc. rather than retain two of each. That's a pretty convincing argument. It does seem like it would save us work in the long run to make `U1` as `Proxy`-like as possible (and similarly with other `GHC.Generics` datatypes), so I'll do this before 8.0 lands. Some questions we should answer: 1. Do change `U1`'s derived `Eq`, `Ord`, `Read`, and `Show` instances (which have been around for a while) and manually implement them with lazy pattern-matching? That seems like the sensible thing to do, although it would be a subtle semantic change. 2. Do we add all of the extra instances which `Proxy` has but `U1` doesn't? (`Enum`, `Bounded`, `Ix`, etc.) My gut reaction is to punt on this and only add them if someone requests it. Plus, if we decide to merge `U1` and `Proxy`, it will be a moot point after that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 18:50:06 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 18:50:06 -0000 Subject: [GHC] #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) In-Reply-To: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> References: <047.70d23a45a2ce05ad6e26dcf653b86ffa@haskell.org> Message-ID: <062.2f38f86ccbac3b716a60a08af71d4d0b@haskell.org> #11395: The via-C code generation backend is incompatible with gcc 5.3.1 on m68k (ELF) --------------------------------------------+------------------------------ Reporter: mkarcher | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: m68k Type of failure: GHC doesn't work at all | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | --------------------------------------------+------------------------------ Comment (by glaubitz): Just cloned ghc from git, applied the patch and cross-compiled it. Unfortunately, it segfaults right away: {{{ root at pacman:~> ./ghc Segmentation fault (core dumped) root at pacman:~> file ./ghc ./ghc: ELF 32-bit MSB executable, Motorola m68k, 68020, version 1 (SYSV), dynamically linked, interpreter /lib/ld.so.1, for GNU/Linux 3.2.0, BuildID[sha1]=b7cc59d2d71bcb64fef73c1628602253f24bfa9f, not stripped root at pacman:~> }}} Will remove the patch and test again, just to make sure it's not a general issue with ghc 8.x on m68k. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 19:45:45 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 19:45:45 -0000 Subject: [GHC] #10752: Print which warning-flag controls/enabled an emitted warning In-Reply-To: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> References: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> Message-ID: <057.808cbbbffe0ebc67408fe3d0c30e48d6@haskell.org> #10752: Print which warning-flag controls/enabled an emitted warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: barrucadu Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1943 Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"3cd4c9ca4564982cf159f11f59d434235ba28808/ghc" 3cd4c9ca/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="3cd4c9ca4564982cf159f11f59d434235ba28808" Annotate `[-Wdeferred-type-errors]` in warnings (re #10752) This was missed in bb5afd3c274011c5ea302210b4c290ec1f83209c }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 20:26:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 20:26:16 -0000 Subject: [GHC] #11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied In-Reply-To: <045.7c07d2218cc40ac347ede40d7f240131@haskell.org> References: <045.7c07d2218cc40ac347ede40d7f240131@haskell.org> Message-ID: <060.23c45ec93d47d3f8d227cd14a929b56d@haskell.org> #11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9636 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) * related: => #9636 Comment: Replying to [comment:3 goldfire]: > To paraphrase, you want GHC to recognize that an empty closed type family is insoluble. Note that empty closed type families are not necessarily insoluble in the presence of type-checker plugins. Indeed, the whole point of adding empty CTFs was to allow them to be given special reduction behaviour by plugins. So I think the implementation should be left alone (but for some contrasting views see the discussion on #9636). Documentation improvements are welcome, of course. :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 21:56:16 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 21:56:16 -0000 Subject: [GHC] #11174: Traversable can't be derived for datatypes with unboxed arguments In-Reply-To: <050.8afc974fb1620698fac2f086504cf230@haskell.org> References: <050.8afc974fb1620698fac2f086504cf230@haskell.org> Message-ID: <065.6a677721f06d4de030c386d28c906035@haskell.org> #11174: Traversable can't be derived for datatypes with unboxed arguments -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: RyanGlScott Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Resolution: fixed | Keywords: Generics 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:D1908 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.2.1 => 8.0.1 Comment: I went ahead and merged this to `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 21:56:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 21:56:29 -0000 Subject: [GHC] #9043: Add missing type class instances for data types in GHC.Generics In-Reply-To: <047.559a569dcd60e85eae168b55411f2520@haskell.org> References: <047.559a569dcd60e85eae168b55411f2520@haskell.org> Message-ID: <062.25dbbc75397574f5467b8a6a35bcca3b@haskell.org> #9043: Add missing type class instances for data types in GHC.Generics -------------------------------------+------------------------------------- Reporter: ocharles | Owner: dreixel Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.8.2 Resolution: fixed | Keywords: Generics Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: 9766 | Blocking: Related Tickets: #8778 | Differential Rev(s): Phab:D1937 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 21:58:09 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 21:58:09 -0000 Subject: [GHC] #11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied In-Reply-To: <045.7c07d2218cc40ac347ede40d7f240131@haskell.org> References: <045.7c07d2218cc40ac347ede40d7f240131@haskell.org> Message-ID: <060.ecf9665723350a5612d32b7c1bf3d56a@haskell.org> #11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9636 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by carter): So if I wanted a new userland insolvable type family that errors out eagerly rather than down stream, I'd have to have a type solver plugin active in the defining module to enforce that? I guess that would enable simulating the type error family in userland In 7.10 right? I guess my main worry is that afaict, any type solver plugin usage forces ghc to rebuild The offending module every time. And then every down stream user possibly too! Or am I mis understanding your point? What if instead, when defining an empty closed type family, we could pragma Annotate it with "requires plugin foo" when we want this other plugin adhuncated semantics, Because otherwise requiring the offending type plugin is implicit in any down stream module! Replying to [comment:5 adamgundry]: > Replying to [comment:3 goldfire]: > > To paraphrase, you want GHC to recognize that an empty closed type family is insoluble. > > Note that empty closed type families are not necessarily insoluble in the presence of type-checker plugins. Indeed, the whole point of adding empty CTFs was to allow them to be given special reduction behaviour by plugins. So I think the implementation should be left alone (but for some contrasting views see the discussion on #9636). > > Documentation improvements are welcome, of course. :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 22:09:07 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 22:09:07 -0000 Subject: [GHC] #11625: Data.Type.Equality is not Trustworthy In-Reply-To: <045.00b6470b73cd59812d630575ca77009a@haskell.org> References: <045.00b6470b73cd59812d630575ca77009a@haskell.org> Message-ID: <060.57778d12c98c01a6bf856b7328318c6e@haskell.org> #11625: Data.Type.Equality is not Trustworthy -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.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:D1957 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 22:09:59 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 22:09:59 -0000 Subject: [GHC] #11653: Time compiler passes Message-ID: <046.3012c59d1edbf72f1f7df879f738aa80@haskell.org> #11653: Time compiler passes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- It would be very useful if the compiler would produce timings of various phases of compilation. Even better, if could produce allocation numbers as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 22:10:19 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 22:10:19 -0000 Subject: [GHC] #11653: Time compiler passes In-Reply-To: <046.3012c59d1edbf72f1f7df879f738aa80@haskell.org> References: <046.3012c59d1edbf72f1f7df879f738aa80@haskell.org> Message-ID: <061.f78a3a5917431596e411c66562a6e08f@haskell.org> #11653: Time compiler passes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * owner: => bgamari @@ -1,3 +1,3 @@ - It would be very useful if the compiler would produce timings of various - phases of compilation. Even better, if could produce allocation numbers as - well. + It would be very useful for compiler performance analysis if the compiler + would produce timings of various phases of compilation. Even better, if + could produce allocation numbers as well. New description: It would be very useful for compiler performance analysis if the compiler would produce timings of various phases of compilation. Even better, if could produce allocation numbers as well. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 22:26:37 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 22:26:37 -0000 Subject: [GHC] #11654: User Guide: Generate command line options table from ghc-flags directives Message-ID: <046.ddd00ea2d6129f4c2ecb14404cf0a699@haskell.org> #11654: User Guide: Generate command line options table from ghc-flags directives -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Documentation | Version: 7.10.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: -------------------------------------+------------------------------------- Since the move to ReStructuredText and Sphinx we've generated the options summary tables and manpage with `utils/mkUserGuidePart`. The options are described in a set of Haskell modules which are a pain to edit and may easily fall out of date. It would be far better if we could generate these tables from the `.. ghc- flags` directives already present in the users guide. This will involve a bit of hacking with Sphinx, although it should be more than up to the task. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 22:59:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 22:59:21 -0000 Subject: [GHC] #11655: Ambiguous types in pattern synonym not determined by functional dependencies Message-ID: <051.594ea8df445a741b9cbfd97613b98e7e@haskell.org> #11655: Ambiguous types in pattern synonym not determined by functional dependencies -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.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 Glorious Glasgow Haskell Compilation System, version 8.1.20160117 {{{#!hs {-# LANGUAGE UndecidableInstances, KindSignatures, DataKinds, GADTs, MultiParamTypeClasses, FunctionalDependencies, FlexibleInstances #-} data Ty ty where I :: Ty Int A :: Ty a -> Ty [a] data NUM = MKINT data SCALAR = MKNUM NUM data TYPE = MKSCALAR SCALAR | MKARR TYPE -- Each type determines a TYPE -- Int -> MKSCALAR (MKNUM MKINT) -- [Int] -> MKARR (MKSCALAR (MKNUM MKINT)) class GetTy ty (rep :: TYPE) | ty -> rep where getTy :: Ty ty instance GetTy Int (MKSCALAR (MKNUM MKINT)) where getTy = I instance GetTy a rep => GetTy [a] (MKARR rep) where getTy = A getTy data Unary a b where Un :: (GetTy a a_rep, GetTy b b_rep) => UnOp a b -> (a -> b) -> Unary a b data UnOp a b where OpLen :: UnOp [a] Int data E a where UnOp :: Unary a b -> (E a -> E b) }}} Now I'd like to create an explicitly-bidirectional pattern synonym, defining a unidirectional pattern synonym works fine: {{{#!hs pattern Len xs <- UnOp (Un OpLen _) xs }}} but the inferred type is rejected: {{{#!hs -- >>> :i Len -- pattern Len :: () => (GetTy a a_rep, GetTy t b_rep, -- a GHC.Prim.~# [a1], t GHC.Prim.~# Int) => E a -> E t pattern Len :: () => (GetTy a a_rep, GetTy t b_rep, a ~ [a1], t ~ Int) => E a -> E t pattern Len xs <- UnOp (Un OpLen _) xs -- tgxg.hs:31:37-38: error: ? -- ? Could not deduce (GetTy a1 rep) arising from a pattern -- from the context: (GetTy a a_rep, GetTy t b_rep) -- bound by a pattern with constructor: -- Un :: forall a b (a_rep :: TYPE) (b_rep :: TYPE). -- (GetTy a a_rep, GetTy b b_rep) => -- UnOp a b -> (a -> b) -> Unary a b, -- in a pattern synonym declaration -- at /tmp/tgxg.hs:31:25-34 -- or from: (a ~ [a1], t ~ Int) -- bound by a pattern with constructor: -- OpLen :: forall a. UnOp [a] Int, -- in a pattern synonym declaration -- at /tmp/tgxg.hs:31:28-32 -- The type variable ?rep? is ambiguous -- ? In the declaration for pattern synonym ?Len? -- Compilation failed. }}} Constructing it works fine: {{{#!hs len :: GetTy a rep => E [a] -> E Int len = UnOp (Un OpLen length) }}} but adding it to the pattern makes it fail: {{{#!hs pattern Len xs <- UnOp (Un OpLen _) xs where Len xs = len xs -- tgxg.hs:32:18-23: error: ? -- ? Could not deduce (GetTy a1 rep) arising from a use of ?len? -- from the context: (GetTy a a_rep, GetTy t b_rep, a ~ [a1], t ~ Int) -- bound by the type signature for: -- Main.$bLen :: (GetTy a a_rep, GetTy t b_rep, a ~ [a1], t ~ Int) => -- E a -> E t -- at /tmp/tgxg.hs:(31,1)-(32,23) -- The type variable ?rep? is ambiguous -- These potential instances exist: -- instance GetTy Int ('MKSCALAR ('MKNUM 'MKINT)) -- -- Defined at /tmp/tgxg.hs:14:10 -- instance GetTy a rep => GetTy [a] ('MKARR rep) -- -- Defined at /tmp/tgxg.hs:17:10 -- ? In the expression: len xs -- In an equation for ?$bLen?: $bLen xs = len xs -- Compilation failed. }}} Mixing functional dependencies, GADTs and pattern synonyms is confusing to me but is GHC correct that this type is ambiguous and if so what is missing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Feb 27 23:17:31 2016 From: ghc-devs at haskell.org (GHC) Date: Sat, 27 Feb 2016 23:17:31 -0000 Subject: [GHC] #10752: Print which warning-flag controls/enabled an emitted warning In-Reply-To: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> References: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> Message-ID: <057.7fb36a0728bf005ddfa9660294449bdf@haskell.org> #10752: Print which warning-flag controls/enabled an emitted warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: barrucadu Type: feature request | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1943 Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"46f3775c683faeb710c9dc22f360f39334947d73/ghc" 46f3775c/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="46f3775c683faeb710c9dc22f360f39334947d73" Default to -fno-show-warning-groups (re #10752) As `-fno-show-warning-groups` shows associated warning groups regardless of whether the respective warning group flag as been passed on the CLI, the warning-group information may be confusing to users. At this point, `-fshow-warning-groups` is useful mostly to GHC developers and possibly GHC users who want to see which warning groups an emitted warning is part of. (Btw, this is particularly interesting in combination with `-Weverything` which enables *every* warning flag known to GHC.) Consequently, starting with this commit, one has to opt-in via `-fshow-warning-groups` for GHC to show warning groups. In order to reduce the testsuite delta in this commit, the `-fshow-warning-groups` flag has been added to TEST_HC_OPTS. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 28 10:45:18 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Feb 2016 10:45:18 -0000 Subject: [GHC] #11653: Time compiler passes In-Reply-To: <046.3012c59d1edbf72f1f7df879f738aa80@haskell.org> References: <046.3012c59d1edbf72f1f7df879f738aa80@haskell.org> Message-ID: <061.c5ab62e081977978a3506f351478879a@haskell.org> #11653: Time compiler passes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by nomeata): Note that at least the Core-to-Core passes have SCC annotations for each pass: http://git.haskell.org/ghc.git/blob/HEAD:/compiler/simplCore/SimplCore.hs#l365 Also, laziness would make such timing statistics more tricky. But in general, you are of course right. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 28 11:04:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Feb 2016 11:04:41 -0000 Subject: [GHC] #7388: CAPI doesn't work with ghci In-Reply-To: <044.45a130d5455804a7b37a7d8862986ddd@haskell.org> References: <044.45a130d5455804a7b37a7d8862986ddd@haskell.org> Message-ID: <059.1d8b2e76f67c39214cb26fb2a57c36c6@haskell.org> #7388: CAPI doesn't work with ghci -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T4012 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jystic): * cc: jystic@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 28 11:08:49 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Feb 2016 11:08:49 -0000 Subject: [GHC] #11653: Time compiler passes In-Reply-To: <046.3012c59d1edbf72f1f7df879f738aa80@haskell.org> References: <046.3012c59d1edbf72f1f7df879f738aa80@haskell.org> Message-ID: <061.b40084d2efc7ea218b204ba73495fef7@haskell.org> #11653: Time compiler passes -------------------------------------+------------------------------------- Reporter: bgamari | Owner: bgamari Type: feature request | Status: patch Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1959 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1959 * milestone: => 8.0.1 Comment: > Note that at least the Core-to-Core passes have SCC annotations for each pass Indeed, but these help little when working with an un-profiled compiler. I would really like to be able to track these timings over time, in hopes that they will help in localizing performance regressions within the compiler. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 28 11:34:41 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Feb 2016 11:34:41 -0000 Subject: [GHC] #11656: Alllow static pointers to local closed definitions Message-ID: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> #11656: Alllow static pointers to local closed definitions -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: -------------------------------------+------------------------------------- A limitation of the original patch implementing `-XStaticPointers` is that while the following all work, {{{#!hs t1 = static not t2 = static (\x -> case x of True -> False; False -> True) }}} the below does not: {{{#!hs t3 = static foo where foo True = False }}} Yet `foo` is perfectly "static": it's a closed expression that can readily be floated to top-level. So in short: `-XStaticPointers` should not consider only expressions with top-level identifiers, but in general any closed expression (which may involve local closed identifiers too). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 28 11:37:34 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Feb 2016 11:37:34 -0000 Subject: [GHC] #11656: Alllow static pointers to local closed definitions In-Reply-To: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> References: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> Message-ID: <059.cad72f271dcb9b5cb5caf06e378f3996@haskell.org> #11656: Alllow static pointers to local closed definitions -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mboes): Note that the main reason that this was not implemented the first time around is that we couldn't get floating of closed local identifiers to top-level to work properly. This is likely an easy and straightforward task though - Facundo and I just don't have the requisite knowledge it seems. So any help from core developers more familiar with GHC would be greatly appreciated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 28 12:33:29 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Feb 2016 12:33:29 -0000 Subject: [GHC] #11549: Add -fshow-runtime-rep In-Reply-To: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> References: <047.266b1817848e78f8afbd8fee6528ff72@haskell.org> Message-ID: <062.85acb4cd54b91badc71afdbfd826a76a@haskell.org> #11549: Add -fshow-runtime-rep -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.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:D1961 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch * differential: => Phab:D1961 Comment: I gave this a shot in Phab:D1961. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 28 12:55:40 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Feb 2016 12:55:40 -0000 Subject: [GHC] #7388: CAPI doesn't work with ghci In-Reply-To: <044.45a130d5455804a7b37a7d8862986ddd@haskell.org> References: <044.45a130d5455804a7b37a7d8862986ddd@haskell.org> Message-ID: <059.e4241dd747dd061bd2ee7b3f51579373@haskell.org> #7388: CAPI doesn't work with ghci -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T4012 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Can someone clarify what "CAPI" means in this context? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 28 14:15:21 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Feb 2016 14:15:21 -0000 Subject: [GHC] #11657: Varpes.L!plock trojan shipped in HaskellPlatform-7.10.3-i386-setup.exe? Message-ID: <047.4bb1daa7256cf24e94aebb75995c386c@haskell.org> #11657: Varpes.L!plock trojan shipped in HaskellPlatform-7.10.3-i386-setup.exe? --------------------------------------------+---------------------------- Reporter: swithers | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Keywords: Virus Trojan Malware | Operating System: Windows Architecture: x86 | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: --------------------------------------------+---------------------------- Windows defender scan of HaskellPlatform-7.10.3-i386-setup.exe detected severe malware. Varpes.L!plock trojan "This program is dangerous and executes commands from an attacker" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 28 14:16:20 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Feb 2016 14:16:20 -0000 Subject: [GHC] #11657: Varpes.L!plock trojan shipped in HaskellPlatform-7.10.3-i386-setup.exe? In-Reply-To: <047.4bb1daa7256cf24e94aebb75995c386c@haskell.org> References: <047.4bb1daa7256cf24e94aebb75995c386c@haskell.org> Message-ID: <062.251cb34daa613b3b048e67df2cf5cd81@haskell.org> #11657: Varpes.L!plock trojan shipped in HaskellPlatform-7.10.3-i386-setup.exe? -------------------------------------+------------------------------------- Reporter: swithers | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Resolution: | Keywords: Virus Trojan | Malware Operating System: Windows | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by swithers): * Attachment "haskellMalware.GIF" added. Screenshot of Windows Defender History log -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 28 14:23:55 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Feb 2016 14:23:55 -0000 Subject: [GHC] #11657: Varpes.L!plock trojan shipped in HaskellPlatform-7.10.3-i386-setup.exe? In-Reply-To: <047.4bb1daa7256cf24e94aebb75995c386c@haskell.org> References: <047.4bb1daa7256cf24e94aebb75995c386c@haskell.org> Message-ID: <062.e6515622803aa6289b4e50ccba05088a@haskell.org> #11657: Varpes.L!plock trojan shipped in HaskellPlatform-7.10.3-i386-setup.exe? -------------------------------------+------------------------------------- Reporter: swithers | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Resolution: | Keywords: Virus Trojan | Malware Operating System: Windows | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): Most likely a false positive. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 28 14:26:30 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Feb 2016 14:26:30 -0000 Subject: [GHC] #11657: Varpes.L!plock trojan shipped in HaskellPlatform-7.10.3-i386-setup.exe? In-Reply-To: <047.4bb1daa7256cf24e94aebb75995c386c@haskell.org> References: <047.4bb1daa7256cf24e94aebb75995c386c@haskell.org> Message-ID: <062.e7fac1ebbe23f58471601ac1fc140edb@haskell.org> #11657: Varpes.L!plock trojan shipped in HaskellPlatform-7.10.3-i386-setup.exe? -------------------------------------+------------------------------------- Reporter: swithers | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Resolution: | Keywords: Virus Trojan | Malware Operating System: Windows | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by refold): Seems to be a common issue: * https://github.com/paralect/robomongo/issues/1024 * https://github.com/mridgers/clink/issues/381 * http://forums.codeblocks.org/index.php?topic=20954.0 * https://forums.sabnzbd.org/viewtopic.php?f=11&t=20216 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 28 15:03:44 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Feb 2016 15:03:44 -0000 Subject: [GHC] #11657: Varpes.L!plock trojan shipped in HaskellPlatform-7.10.3-i386-setup.exe? In-Reply-To: <047.4bb1daa7256cf24e94aebb75995c386c@haskell.org> References: <047.4bb1daa7256cf24e94aebb75995c386c@haskell.org> Message-ID: <062.1df1816eaaba688819725501e68afe44@haskell.org> #11657: Varpes.L!plock trojan shipped in HaskellPlatform-7.10.3-i386-setup.exe? -------------------------------------+------------------------------------- Reporter: swithers | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.10.3 Resolution: invalid | Keywords: Virus Trojan | Malware Operating System: Windows | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by swithers): * status: new => closed * resolution: => invalid Comment: Concur.. BTW Malwarebytes hapy with the file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 28 20:42:53 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Feb 2016 20:42:53 -0000 Subject: [GHC] #7388: CAPI doesn't work with ghci In-Reply-To: <044.45a130d5455804a7b37a7d8862986ddd@haskell.org> References: <044.45a130d5455804a7b37a7d8862986ddd@haskell.org> Message-ID: <059.e922ae809959c09a0db71bfd8150d126@haskell.org> #7388: CAPI doesn't work with ghci -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: T4012 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Replying to [comment:10 bgamari]: > Can someone clarify what "CAPI" means in this context? Something like {{{#!hs {-# LANGUAGE CApiFFI #-} import Foreign.C foreign import capi "stdio.h printf" printfb :: CString -> CInt -> IO () }}} There was a minor improvement in the error-message since 7.10 however: With 7.10 you get the somewhat cryptic message: {{{ [1 of 1] Compiling T4012_B ( T4012_B.hs, interpreted ) ByteCodeLink: can't find label During interactive linking, GHCi couldn't find the following symbol: ghczuwrapperZC0ZCmainZCT4012zuBZCprintf 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 }}} whereas with GHC 8.0 you get {{{ [1 of 1] Compiling T4012_B ( T4012_B.hs, interpreted ) Error: bytecode compiler can't handle some foreign calling conventions Workaround: use -fobject-code, or compile this module to .o separately. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 28 20:51:42 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Feb 2016 20:51:42 -0000 Subject: [GHC] #10752: Print which warning-flag controls/enabled an emitted warning In-Reply-To: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> References: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> Message-ID: <057.af287f372eb575d10c283b82c7c5e9ed@haskell.org> #10752: Print which warning-flag controls/enabled an emitted warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: barrucadu Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1943 Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Changes (by hvr): * status: new => closed * resolution: => fixed * milestone: 8.2.1 => 8.0.1 Comment: Let's call it a day and declare this ticket's scope done... at least I didn't notice any other warning-flags not being annotated in warnings (but there could still be!). There'll likely be follow-up tickets for evolving this feature in the future. ----- Merged to ghc-8.0 via - 975353bfdfab375cb5c47dc2460792190abac277 - 966cc28ffe1707685cb908753bb6f8fb78fc86c9 - 2ffd9b167a107a82fff42adb22d15b185d8b8757 - 94b2681507db793359b101b945c710e504971556 - 02e91accf082967cd28ad0d081f774117ee3386b - 209143945233726a8cf5c4eb2605a4f8084e5fa0 - 4f5b7ad8fe567bc520e5c1b185beadda9007afea -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Feb 28 22:16:43 2016 From: ghc-devs at haskell.org (GHC) Date: Sun, 28 Feb 2016 22:16:43 -0000 Subject: [GHC] #11658: Type synonym with context in pattern synonym Message-ID: <051.ae548a3938223856c1b70c4e976a1872@haskell.org> #11658: Type synonym with context in pattern synonym -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: Compiler | Version: 8.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- {{{#!hs pattern :: (Num a, Eq a) => a pattern Fiskur = 42 }}} unlike {{{#!hs type Diskur a = Num a => a fiskur :: Num a => a fiskur = 42 }}} we cannot write {{{#!hs type Fugl a = (Num a, Eq a) => a pattern Fiskur :: Fugl a pattern Fiskur = 42 -- Exp.hs:54:18-19: error: ? -- ? No instance for (Eq a) arising from a pattern -- Possible fix: -- add (Eq a) to the context of -- the type signature for pattern synonym ?Fiskur?: -- Fugl a -- ? In the pattern: 42 -- In the declaration for pattern synonym ?Fiskur? -- Compilation failed. }}} Given that the story of pattern synonym contexts is more complicated than usual patterns given provided constraints, I know there are other issues (#11524, #10928). ---- For fun why not type synonym with provided and required constraints: {{{#!hs data T a where MkT :: (Show b) => a -> b -> T a f1 :: (Eq a, Num a) => T a -> String f1 (MkT 42 x) = show x type MKNUMPAT a b = (Num a, Eq a) => (Show b) => b -> T a -- pattern ExNumPat :: (Num a, Eq a) => (Show b) => b -> T a pattern ExNumPat :: MKNUMPAT a b pattern ExNumPat x = MkT 42 x }}} What would that mean in a regular type signature? `CE := CP + CR` where `EXNUMPAT a b` means the same as `EXNUMPAT' a b`? (#8581) {{{#!hs type MKNUMPAT' a b = (Num a, Eq a, Show b) => b -> T a -- This works: mkNumPat :: MKNUMPAT a b mkNumPat = ExNumPat }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 04:49:34 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 04:49:34 -0000 Subject: [GHC] #11658: Type synonym with context in pattern synonym In-Reply-To: <051.ae548a3938223856c1b70c4e976a1872@haskell.org> References: <051.ae548a3938223856c1b70c4e976a1872@haskell.org> Message-ID: <066.5380dc0cd8c4a64a7b2103eb8c1d06b7@haskell.org> #11658: Type synonym with context in pattern synonym -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): While I understand why the syntax might suggest that this is a good idea. I don't support this proposal. The thing after `pattern Blah ::` is '''not''' a type. It's a pattern synonym type, which is something else. Of course, type synonyms should be allowed in pattern synonym types, but we shouldn't confuse the normal `=>` that might appear in a type synonym with the `=>` that appears in a pattern synonym type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 05:06:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 05:06:16 -0000 Subject: [GHC] #11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied In-Reply-To: <045.7c07d2218cc40ac347ede40d7f240131@haskell.org> References: <045.7c07d2218cc40ac347ede40d7f240131@haskell.org> Message-ID: <060.da33e271229b662fb75b871def053dff@haskell.org> #11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9636 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): I think option (a) from comment:4 is the best way forward here: document `TypeError` more carefully. I will say that the feature is described in the manual in the section entitled `Custom compile-time errors`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 05:08:52 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 05:08:52 -0000 Subject: [GHC] #11627: Segmentation fault for space_leak_001 with profiling (-hc) In-Reply-To: <045.274c910606d60239cadf6f398a2dd711@haskell.org> References: <045.274c910606d60239cadf6f398a2dd711@haskell.org> Message-ID: <060.10ac76b4a799bc7e35ff806f8ad22c59@haskell.org> #11627: Segmentation fault for space_leak_001 with profiling (-hc) -------------------------------------+------------------------------------- Reporter: thomie | Owner: jme Type: bug | Status: new Priority: high | Milestone: Component: Profiling | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: | perf/space_leaks/space_leak_001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jme): * owner: => jme Comment: The segfault occurs because `shrinkMutableByteArray#` and `resizeMutableByteArray#` introduce slop at the ends of the `large_object` `MutableByteArray#`s holding the `Integer`s. Since the arrays are large, they are not copied during GC, so this slop is still present when the heap census is run (after GC). But when `heapCensusChain` encounters a shrunken `MutableByteArray#`, it thinks the slop following the array is another closure, and chaos quickly ensues. The fix should be straightforward. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 05:11:45 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 05:11:45 -0000 Subject: [GHC] #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` In-Reply-To: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> References: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> Message-ID: <057.0fd166557cf175301211c8807378c7a2@haskell.org> #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11608 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Hm. These `ASSERT`s used to be here, and I removed them because they were triggering on kind variables, which were not always `TcTyVar`s. However, if the `dependent` set of tests in the testsuite aren't failing here, then perhaps things improved from when I removed the `ASSERT`s. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 07:18:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 07:18:48 -0000 Subject: [GHC] #11636: Promoting newtype destructor In-Reply-To: <045.0a5eaaf72ec2e2d10e023f3eda63667e@haskell.org> References: <045.0a5eaaf72ec2e2d10e023f3eda63667e@haskell.org> Message-ID: <060.aa0c45b93b92ff38bc3a1c756a301c0f@haskell.org> #11636: Promoting newtype destructor -------------------------------------+------------------------------------- Reporter: phadej | Owner: 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: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 07:18:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 07:18:57 -0000 Subject: [GHC] #11560: panic: isInjectiveTyCon sees a TcTyCon In-Reply-To: <047.844547fa9c9539b9ad0e369581a719b2@haskell.org> References: <047.844547fa9c9539b9ad0e369581a719b2@haskell.org> Message-ID: <062.50d5d661e162fdaf6d91f316009a172d@haskell.org> #11560: panic: isInjectiveTyCon sees a TcTyCon -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 8.1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 08:24:02 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 08:24:02 -0000 Subject: [GHC] #10143: Separate PprFlags (used by Outputable) from DynFlags In-Reply-To: <045.0c964cf0fdf539316860c6c8c56c5f9e@haskell.org> References: <045.0c964cf0fdf539316860c6c8c56c5f9e@haskell.org> Message-ID: <060.700e9787b372e1c7c6b1dd5487437f2a@haskell.org> #10143: Separate PprFlags (used by Outputable) from DynFlags -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10961 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dalaing): Unless I've missed something, this might be required for #10961. I'm keen to have a go at this if ezyang isn't working on it anymore. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 08:24:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 08:24:41 -0000 Subject: [GHC] #10961: Make it possible to purely use the parser In-Reply-To: <049.fcc8c76168c1ad7ed5e00c80467dcc18@haskell.org> References: <049.fcc8c76168c1ad7ed5e00c80467dcc18@haskell.org> Message-ID: <064.b564234d3caa8622037a709fdc8358d7@haskell.org> #10961: Make it possible to purely use the parser -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.2 (Parser) | Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10143 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by dalaing): This looks like it might be pretty intimately related to #10143, since in Lexer.x we have uses of `mkWarnMsg`, which in turn use `showSDoc`, which requires `DynFlags`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 08:29:30 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 08:29:30 -0000 Subject: [GHC] #11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied In-Reply-To: <045.7c07d2218cc40ac347ede40d7f240131@haskell.org> References: <045.7c07d2218cc40ac347ede40d7f240131@haskell.org> Message-ID: <060.504c4c80fa93f56c9a63ddcda3e01781@haskell.org> #11594: closed empty type families fully applied get reduced lazily when in a constraint tuple and fully applied -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: feature request | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9636 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by adamgundry): Replying to [comment:6 carter]: > So if I wanted a new userland insolvable type family that errors out eagerly rather than down stream, I'd have to have a type solver plugin active in the defining module to enforce that? > > I guess that would enable simulating the type error family in userland In 7.10 right? The plugin would need to be active at use sites, not definition sites, but yes - it is possible for plugins to approximately simulate `TypeError`. They can't give exactly the same semantics, because plugins only get to see unsolved constraints, but can work the same way for uses of `TypeError` at kind `Constraint`. In fact I hacked together a quick prototype plugin that does exactly that during the last ICFP. If there's interest, I'm happy to share the code, though it's not entirely consistent with the `TypeError` API. > What if instead, when defining an empty closed type family, we could pragma > Annotate it with "requires plugin foo" when we want this other plugin adhuncated semantics, > Because otherwise requiring the offending type plugin is implicit in any down stream module! Right, there is currently no way to indicate which type-checker plugins a module requires, and it might be nice to do so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 08:33:54 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 08:33:54 -0000 Subject: [GHC] #11354: Install script installs docs without -version suffix In-Reply-To: <043.018901061c911df7ad296ca4936d7024@haskell.org> References: <043.018901061c911df7ad296ca4936d7024@haskell.org> Message-ID: <058.b420f8141a26b5023c483d89288b8fec@haskell.org> #11354: Install script installs docs without -version suffix -------------------------------------+------------------------------------- Reporter: osa1 | Owner: Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.0.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:D1868 Wiki Page: | -------------------------------------+------------------------------------- Comment (by juhpetersen): I think this is not refected in the 'configure --help' output which still says docdir defaults to [DATAROOTDIR/doc/ghc], which is confusing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 08:45:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 08:45:48 -0000 Subject: [GHC] #11659: configure --help incorrectly says --docdir is still unversioned by default Message-ID: <050.007b9aca933c6049d4b4848346195a1d@haskell.org> #11659: configure --help incorrectly says --docdir is still unversioned by default -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 8.0.1-rc1 Keywords: | 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-8.0.1 it seems docdir is no longer unversioned (#11354) by default, however 'configure --help' still says the default value is unversioned. This is a bit confusing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 08:45:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 08:45:53 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 In-Reply-To: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> References: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> Message-ID: <060.58d67bb9fa38f8fc82e8a4bdf428a008@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: fixed => Comment: The `polykinds` ASSERT errors are not yet fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 09:41:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 09:41:14 -0000 Subject: [GHC] #11624: Cannot declare hs-boot declaration if there is already a value in scope In-Reply-To: <045.b9ceb4e2b51dd79931a13bc304d99595@haskell.org> References: <045.b9ceb4e2b51dd79931a13bc304d99595@haskell.org> Message-ID: <060.582fb10761e1a690a48090a8aa38b3b0@haskell.org> #11624: Cannot declare hs-boot declaration if there is already a value in scope -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 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 hvr): * priority: normal => highest Comment: This seems to be the same problem that causes regression in hackage:enumerator-0.4.20 with GHC HEAD/8.0: {{{ [ 4 of 10] Compiling Data.Enumerator.Compatibility ( lib/Data/Enumerator/Compatibility.hs, /tmp/enumerator-0.4.20/dist- newstyle/build/enumerator-0.4.20/build/Data/Enumerator/Compatibility.o ) lib/Data/Enumerator/Compatibility.hs:55:8: error: ? Can't find interface-file declaration for variable EL.head 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: EL.head In an equation for ?head?: head = EL.head ...and several more... }}} I'm increasing priority as this is a regression relative to 7.10 and there's at least on package on Hackage suffering from it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 09:43:46 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 09:43:46 -0000 Subject: [GHC] #11134: Limit frequency of idle GCs In-Reply-To: <047.b7adbd5e9207ae18bb8e48502cfb8e5f@haskell.org> References: <047.b7adbd5e9207ae18bb8e48502cfb8e5f@haskell.org> Message-ID: <062.a56ff3a49cd6318024bd557b03d684fa@haskell.org> #11134: Limit frequency of idle GCs -------------------------------------+------------------------------------- Reporter: dcturner | Owner: dcturner Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1930 Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * owner: => dcturner * differential: => Phab:D1930 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 09:50:03 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 09:50:03 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 In-Reply-To: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> References: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> Message-ID: <060.006bcb025a98cb5486f85def9153b216@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Here's a smaller test case for the polykinds error {{{ class Monoidy (to :: k0 -> k1 -> *) (m :: k1) where type MComp to m :: k1 -> k1 -> k0 mjoin :: MComp to m m m `to` m }}} The problem is this: * `TcTyClsDecls.getFamDeclInitialKind` thinks that `MComp` has a CUSK. * When it quantifies over it, it gives it the kind: {{{ MComp :: forall k1_aLj[sk] (k0_aLi[sk] :: TYPE t_aSB[tau:1]). (k0_aLi[sk] -> k1_aLj[sk] -> *) -> k1_aLj[sk] -> k1_aLj[sk] -> k1_aLj[sk] -> k0_aLi[sk] }}} This is wrong: the `t_aSB` should be instantiated to `Lifted`. It's terrible for a meta-tyvar to end up in the kind of a `TyCon`. * So I'm worried about where this defaulting happens in `TcHsType.kcHsTyVarBndrs` with `cusk` = True. Indeed, by adding tracing to this program I've confirmed that `Monoidy` also gets a kind (at least during kind-checking) looking like {{{ forall (k1{tv aLi} [sk] :: *) ((k0{tv aLh} [sk] :: TYPE{(w) tc 32Q} (t_aSs{tv} [tau:1] :: RuntimeRep{(w) tc 334})) :: TYPE{(w) tc 32Q} (t_aSs{tv} [tau:1] :: RuntimeRep{(w) tc 334})). ((k0{tv aLh} [sk] :: TYPE{(w) tc 32Q} (t_aSs{tv} [tau:1] :: RuntimeRep{(w) tc 334})) -> (k1{tv aLi} [sk] :: *) -> *{(w) tc 330}) -> (k1{tv aLi} [sk] :: *) -> Constraint{(w) tc 32Y} }}} Notice that `t_aSB`. But even if we fix that I'm worried about doing this CUSK stuff for associated types. I think it's probably wrong. We are crawling over the class decl to find constraints on the kind variables so we can infer the class decl's kind. We start that process with `getInitialKinds`; and we can't at that moment quantify over the kind variables we are about to gather constraints for! At very least we must elaborate `Note [Complete user-supplied kind signatures]` to cover associated types. An associate type should have a CUSK iff (a) its parent class does, and (b) any private tyvars have kind sigs. I'm a bit puzzled about why we call `kcTyClDecl` and `generaliseTCD` ''at all'' for decls with a CUSK. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 09:51:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 09:51:17 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 In-Reply-To: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> References: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> Message-ID: <060.dc7aee7a8c82b5f926c98086c0a33a7d@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.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 simonpj): * keywords: => TypeInType * priority: normal => highest * owner: => goldfire Comment: Richard, I'm making this 'highest' because it's not just to do with substitutions; there seems to be a clear violation of the invariants about meta-tyvars. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 10:11:25 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 10:11:25 -0000 Subject: [GHC] #11652: Cyclical dependencies aren't reported in pure functions In-Reply-To: <045.2f44d98317e387d0b4bcd9258037d7f2@haskell.org> References: <045.2f44d98317e387d0b4bcd9258037d7f2@haskell.org> Message-ID: <060.0866359c4824f6dd45707b0dd2062603@haskell.org> #11652: Cyclical dependencies aren't reported in pure functions -------------------------------------+------------------------------------- Reporter: keynan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * type: bug => feature request Comment: It's a feature request, but yes even a (necessarily) partial check would be good. In this case it's harder because `(+)` is overloaded, so in principle mutual recursion might be just fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 10:44:52 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 10:44:52 -0000 Subject: [GHC] #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` In-Reply-To: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> References: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> Message-ID: <057.414089867290a1f15a2c99a6e0834b5d@haskell.org> #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11608 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): It seems that way, but I did not do a full stage2 build with DEBUG on. Thomie may do that for us :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 10:53:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 10:53:16 -0000 Subject: [GHC] #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` In-Reply-To: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> References: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> Message-ID: <057.bc6c197eac61d77fd0cfa1f017760def@haskell.org> #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11608 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Travis is reporting this at the moment: {{{ Unexpected failures: polykinds MonoidsTF [exit code non-0] (normal) polykinds T11480b [exit code non-0] (normal) polykinds T11523 [exit code non-0] (normal) th T3100 [exit code non-0] (normal) typecheck/should_compile T3692 [exit code non-0] (normal) typecheck/should_fail T3592 [stderr mismatch] (normal) typecheck/should_fail TcCoercibleFail [stderr mismatch] (normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 10:57:35 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 10:57:35 -0000 Subject: [GHC] #11589: Reexports of wired-in packages don't work. In-Reply-To: <045.ef6d9437d9e0e94059219935e0ffea8d@haskell.org> References: <045.ef6d9437d9e0e94059219935e0ffea8d@haskell.org> Message-ID: <060.71a84df4bc06a81f40da7298c092bc99@haskell.org> #11589: Reexports of wired-in packages don't work. -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: cabal/cabal09 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1926 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This has been merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 10:59:33 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 10:59:33 -0000 Subject: [GHC] #11606: name shadowing warnings don't trigger on standalone declarations in ghci In-Reply-To: <047.da6e0c4abf31fd9d88f2bdf57a7418b8@haskell.org> References: <047.da6e0c4abf31fd9d88f2bdf57a7418b8@haskell.org> Message-ID: <062.d0487acf81042158ed5b88b63d43e057@haskell.org> #11606: name shadowing warnings don't trigger on standalone declarations in ghci -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: rwbarton Type: bug | Status: new Priority: high | Milestone: 8.0.1 Component: GHCi | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): Reid, I don't believe this ever made it up onto Phab. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 11:01:38 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 11:01:38 -0000 Subject: [GHC] #8224: Excessive system time -- new IO manager problem? In-Reply-To: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> References: <047.560f2473b19a53c27f0a194339ba0f97@haskell.org> Message-ID: <062.72e1d1c4886e8fa7228baed0ab42e9a0@haskell.org> #8224: Excessive system time -- new IO manager problem? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.7 Resolution: | Keywords: IO Manager, | System Time Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9221 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: Sadly this won't be resolved for 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 11:03:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 11:03:08 -0000 Subject: [GHC] #8281: The impossible happened: primRepToFFIType In-Reply-To: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> References: <044.47e20917996e473150de04c1ce1afc0b@haskell.org> Message-ID: <059.e6b1072eb9160602b6e123bb34ca191f@haskell.org> #8281: The impossible happened: primRepToFFIType -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.6.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: Not happening for 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 11:06:59 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 11:06:59 -0000 Subject: [GHC] #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) In-Reply-To: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> References: <046.e2d123aa0cc7380f3c5c662bb8d8022e@haskell.org> Message-ID: <061.aeeea3115d107c6c1ff98efe4ef78dbe@haskell.org> #9007: fails to build with hardening flags enabled (relocation R_X86_64_32 against `stg_CHARLIKE_closure'...) -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: Sadly not happening for 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 11:10:50 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 11:10:50 -0000 Subject: [GHC] #10355: Dynamic linker not initialised In-Reply-To: <046.b020405a0b5eb69acc1047433b42d151@haskell.org> References: <046.b020405a0b5eb69acc1047433b42d151@haskell.org> Message-ID: <061.336c5d6a85917f2f4b09adcffb2358dd@haskell.org> #10355: Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: dpiponi | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 (Linker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9868, #10919 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by adamgundry): * related: #9868 => #9868, #10919 Comment: See also #10919, which suggests this may be fixed in 7.10.3. I've just seen it in a large codebase using 7.10.2, where it appears to be related to the fact that my `.cabal` file was missing some `exposed-modules`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 11:11:48 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 11:11:48 -0000 Subject: [GHC] #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module In-Reply-To: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> References: <045.e2e9bbeb8a2151371c0306e4a7b88a0a@haskell.org> Message-ID: <060.82b78a3933b22c29d23d735a8119e0fd@haskell.org> #9370: unfolding info as seen when building a module depends on flags in a previously-compiled module -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: newcomers Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8635 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * keywords: => newcomers * milestone: 8.0.1 => 8.2.1 Comment: Seems like a reasonable bite-sized project for a newcomer. Sadly, it won't be happening for 8.0.1, however. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 11:12:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 11:12:43 -0000 Subject: [GHC] #10068: Make the runtime reflection API for names, modules, locations more systematic In-Reply-To: <046.e24e266e9d617fc4224d115c2a203db8@haskell.org> References: <046.e24e266e9d617fc4224d115c2a203db8@haskell.org> Message-ID: <061.9c83506734b1c190122bdb8d6ecb3180@haskell.org> #10068: Make the runtime reflection API for names, modules, locations more systematic -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: task | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * type: bug => task * milestone: 8.0.1 => 8.2.1 Comment: I'm very sorry to say that this won't be happening in 8.0.1. Hopefully we'll be able to make this happen for 8.2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 11:15:00 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 11:15:00 -0000 Subject: [GHC] #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` In-Reply-To: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> References: <042.d8c1a08f5b913b1831f401cd9bacdd67@haskell.org> Message-ID: <057.ff1588b4511b9dc0a7b32ceaa21de8b2@haskell.org> #11608: Possible type-checker regression in GHC 8.0 when compiling `microlens` -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | typecheck/should_compile/T11608 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): Jolly good. * The `polykinds` ones are discussed in #11648 * `TcCoercibleFail` is really supposed to fail with `-DDEBUG` (exponential sized types) * I have a patch coming for the other three. So this is good news really. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 11:18:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 11:18:57 -0000 Subject: [GHC] #10599: Template Haskell doesn't allow `newName "type"` In-Reply-To: <048.829d4ff7778a587a956aa230325a65a0@haskell.org> References: <048.829d4ff7778a587a956aa230325a65a0@haskell.org> Message-ID: <063.d51909f7b22598d2c0d080d38d5fecaa@haskell.org> #10599: Template Haskell doesn't allow `newName "type"` -------------------------------------+------------------------------------- Reporter: meteficha | Owner: goldfire Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Template Haskell | Version: 7.10.2-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: It seems pretty unlikely that this will happen for 8.0.1, although who knows what might happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 11:20:01 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 11:20:01 -0000 Subject: [GHC] #10860: setnumcapabilities001: internal error: ASSERTION FAILED: file rts/Schedule.c, line 400 In-Reply-To: <045.1b9d7e0fabda0a4b3797cc5dc85f2044@haskell.org> References: <045.1b9d7e0fabda0a4b3797cc5dc85f2044@haskell.org> Message-ID: <060.77b076ba8e0ea788349884061cbe6d91@haskell.org> #10860: setnumcapabilities001: internal error: ASSERTION FAILED: file rts/Schedule.c, line 400 -------------------------------------+------------------------------------- Reporter: thomie | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: Sadly won't be getting fixed for 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 12:41:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 12:41:10 -0000 Subject: [GHC] #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up In-Reply-To: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> References: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> Message-ID: <061.2d96ef5387df1aa0557870ec1b452c4a@haskell.org> #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"171d95df24dc2d9d0c1a3af9e75f021438a7da50/ghc" 171d95df/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="171d95df24dc2d9d0c1a3af9e75f021438a7da50" Missing Proxy instances, make U1 instance more Proxy-like This accomplishes three things: * Adds missing `Alternative`, `MonadPlus`, and `MonadZip` instances for `Proxy` * Adds a missing `MonadPlus` instance for `U1` * Changes several existing `U1` instances to use lazy pattern-matching, exactly how `Proxy` does it (in case we ever replace `U1` with `Proxy`). This is technically a breaking change (albeit an extremely minor one). Test Plan: ./validate Reviewers: austin, ekmett, hvr, bgamari Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1962 GHC Trac Issues: #11650 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 12:41:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 12:41:10 -0000 Subject: [GHC] #11625: Data.Type.Equality is not Trustworthy In-Reply-To: <045.00b6470b73cd59812d630575ca77009a@haskell.org> References: <045.00b6470b73cd59812d630575ca77009a@haskell.org> Message-ID: <060.2b2e2b0ca68020fec8ba3376f507dc07@haskell.org> #11625: Data.Type.Equality is not Trustworthy -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: bug | Status: patch Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.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:D1957 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"ad4428ddd33f80a883a268dc31f5a2ef68330161/ghc" ad4428dd/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="ad4428ddd33f80a883a268dc31f5a2ef68330161" base: Mark Data.Type.Equality as Trustworthy Test Plan: Validate Reviewers: austin, ekmett, hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1957 GHC Trac Issues: #11625 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 12:41:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 12:41:10 -0000 Subject: [GHC] #11589: Reexports of wired-in packages don't work. In-Reply-To: <045.ef6d9437d9e0e94059219935e0ffea8d@haskell.org> References: <045.ef6d9437d9e0e94059219935e0ffea8d@haskell.org> Message-ID: <060.3419120e0a01844fa2d5a856d242d934@haskell.org> #11589: Reexports of wired-in packages don't work. -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: cabal/cabal09 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1926 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2535c82179f3c7431543babfd11a0ba4514a57b4/ghc" 2535c821/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2535c82179f3c7431543babfd11a0ba4514a57b4" Fix bug where reexports of wired-in packages don't work. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: hvr, bgamari, austin Reviewed By: bgamari Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1926 GHC Trac Issues: #11589 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 12:41:10 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 12:41:10 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.aecb05dc17f83146def29512fcf62477@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: bgamari Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Phab:D1956 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ben Gamari ): In [changeset:"2e49a31658afb4f730fcfec69edfc9e785af71f4/ghc" 2e49a316/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="2e49a31658afb4f730fcfec69edfc9e785af71f4" DynFlags: Add -Wredundant-constraints to -Wall Test Plan: It works, I promise. Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1956 GHC Trac Issues: #11370 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 12:59:25 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 12:59:25 -0000 Subject: [GHC] #11108: Weak references related crash In-Reply-To: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> References: <046.1b25661a2ebf5aa23d3a93aae541239e@haskell.org> Message-ID: <061.db02ae5ce27ad41691cbced5dc729248@haskell.org> #11108: Weak references related crash -------------------------------------+------------------------------------- Reporter: Saulzar | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Linux | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: This clearly won't be fixed for GHC 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 13:00:39 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 13:00:39 -0000 Subject: [GHC] #10296: Segfaults when using dynamic wrappers and concurrency In-Reply-To: <046.5415c655699223aa287cb69e9ee1b595@haskell.org> References: <046.5415c655699223aa287cb69e9ee1b595@haskell.org> Message-ID: <061.93309e95d92b95083beb25664e38ac20@haskell.org> #10296: Segfaults when using dynamic wrappers and concurrency -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * failure: None/Unknown => Runtime crash * milestone: 8.0.1 => 8.2.1 Comment: Sadly this won't be addressed in 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 13:03:09 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 13:03:09 -0000 Subject: [GHC] #7325: threadDelay mistreats minBound and maxBound in some configurations In-Reply-To: <048.f6376e5e233d59dcc7fd251637dbe84b@haskell.org> References: <048.f6376e5e233d59dcc7fd251637dbe84b@haskell.org> Message-ID: <063.4da17c3b254236af186b5f22dfe1a45a@haskell.org> #7325: threadDelay mistreats minBound and maxBound in some configurations -------------------------------------+------------------------------------- Reporter: joeyadams | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 7.6.1 Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | base/tests/T8089 Blocked By: | Blocking: Related Tickets: #9722 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: This won't be fixed in 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 13:20:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 13:20:57 -0000 Subject: [GHC] #11062: Type families + hs-boot files = panic In-Reply-To: <047.7c49c2177d004f32c0696dfdb91a7434@haskell.org> References: <047.7c49c2177d004f32c0696dfdb91a7434@haskell.org> Message-ID: <062.8fec17ffd639083cfd2e71a61c940fc5@haskell.org> #11062: Type families + hs-boot files = panic -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.11 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 bgamari): * milestone: 8.0.1 => 8.2.1 Comment: It doesn't appear that this will get fixed for 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 13:21:27 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 13:21:27 -0000 Subject: [GHC] #10946: Typed hole inside typed Template Haskell bracket causes panic In-Reply-To: <048.bb931422119631f05ab09abe14bd4c46@haskell.org> References: <048.bb931422119631f05ab09abe14bd4c46@haskell.org> Message-ID: <063.8f5456202df7634ebedb88cd9710691b@haskell.org> #10946: Typed hole inside typed Template Haskell bracket causes panic -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: th/T10946 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: This still fails and won't be fixed for 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 13:25:04 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 13:25:04 -0000 Subject: [GHC] #11066: Inacessible branch should be warning - otherwise breaks type soundness? In-Reply-To: <047.0785946e31f05741dc32414264d84d16@haskell.org> References: <047.0785946e31f05741dc32414264d84d16@haskell.org> Message-ID: <062.7366e43f252ae58d42c710a5013a8662@haskell.org> #11066: Inacessible branch should be warning - otherwise breaks type soundness? -------------------------------------+------------------------------------- Reporter: rrnewton | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 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: #8128, #8740 | Differential Rev(s): Phab:D1454 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: Unfortunately it doesn't look like this will happen for 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 13:39:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 13:39:36 -0000 Subject: [GHC] #10601: GHC should be distributed with debug symbols In-Reply-To: <046.ddcd45dcc3f972fc17c42b77b9184272@haskell.org> References: <046.ddcd45dcc3f972fc17c42b77b9184272@haskell.org> Message-ID: <061.77b3b0ead5163338e0dd5258bd1187fe@haskell.org> #10601: GHC should be distributed with debug symbols -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Build System | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #9894 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Adding `-g` to `GhcRtsHcOpts` shouldn't be necessary, as the debug version of the RTS is already compiled with `-g`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 13:43:28 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 13:43:28 -0000 Subject: [GHC] #11495: TH_spliceE5_prof is failing with release candidate 8.0.1 In-Reply-To: <045.e71529dd8c6b021f985c7b75a2a26fb0@haskell.org> References: <045.e71529dd8c6b021f985c7b75a2a26fb0@haskell.org> Message-ID: <060.ab428ff2432d2279c5d62fae60e56523@haskell.org> #11495: TH_spliceE5_prof is failing with release candidate 8.0.1 -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc1 Resolution: | Keywords: Operating System: 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): Would you also make `-prof` produce `.p_o` and `.p_hi`? This is quite a big change to make, and I suspect would break quite a lot of things (though I'm not sure exactly what). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 13:49:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 13:49:51 -0000 Subject: [GHC] #11625: Data.Type.Equality is not Trustworthy In-Reply-To: <045.00b6470b73cd59812d630575ca77009a@haskell.org> References: <045.00b6470b73cd59812d630575ca77009a@haskell.org> Message-ID: <060.b152c0dbad75bd4a404d2be8fe5ade95@haskell.org> #11625: Data.Type.Equality is not Trustworthy -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: bug | Status: closed Priority: high | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1957 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.0` as 90d2cd72927116339b6c911a2017a535167089a9. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 14:04:55 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 14:04:55 -0000 Subject: [GHC] #11656: Alllow static pointers to local closed definitions In-Reply-To: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> References: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> Message-ID: <059.1c3d6d424e4017771cd50a4c23aedd22@haskell.org> #11656: Alllow static pointers to local closed definitions -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj): I'm happy to help, but too snowed under to take the lead. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 14:09:51 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 14:09:51 -0000 Subject: [GHC] #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" In-Reply-To: <045.3571b52d282565941cbfe29e22050176@haskell.org> References: <045.3571b52d282565941cbfe29e22050176@haskell.org> Message-ID: <060.da2bdc670d0bc41ca076f0fdd1c984f2@haskell.org> #11370: Redundant superclass warnings being included in -Wall destroys the "3 Release Policy" -------------------------------------+------------------------------------- Reporter: ekmett | Owner: bgamari Type: bug | Status: closed Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: #11369, #11429 | Differential Rev(s): Phab:D1956 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-8.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 14:16:58 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 14:16:58 -0000 Subject: [GHC] #11334: GHC panic when calling typeOf on a promoted data constructor In-Reply-To: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> References: <050.319316d7546e69cb63d5f3dc484f3940@haskell.org> Message-ID: <065.6af21dfd39952e400df61ae8b214ab29@haskell.org> #11334: GHC panic when calling typeOf on a promoted data constructor -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: goldfire Type: bug | Status: patch Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc1 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1757 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => patch Comment: There is a patch for this in goldfire's branch which he'll hopefully submit soon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 14:18:57 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 14:18:57 -0000 Subject: [GHC] #6166: Performance regression in mwc-random since 7.0.x In-Reply-To: <042.f838154dee2d7e7158fd4f9ebd6ea928@haskell.org> References: <042.f838154dee2d7e7158fd4f9ebd6ea928@haskell.org> Message-ID: <057.c2444c9fefdfc180e0bd0653d4877346@haskell.org> #6166: Performance regression in mwc-random since 7.0.x -------------------------------------+------------------------------------- Reporter: bos | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: Nothing will be happening on this front for 8.0.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 14:20:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 14:20:06 -0000 Subject: [GHC] #11046: lookupTypeName does not support type operators not starting with : In-Reply-To: <045.eabc8eeec9cc920f3e0838e9774eff4d@haskell.org> References: <045.eabc8eeec9cc920f3e0838e9774eff4d@haskell.org> Message-ID: <060.1d38909c67ab5c5af32430a2a64f0a9c@haskell.org> #11046: lookupTypeName does not support type operators not starting with : -------------------------------------+------------------------------------- Reporter: oerjan | Owner: albertus Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | testsuite/tests/th/TH_lookupName.hs, | testsuite/tests/th/T11046.hs Blocked By: | Blocking: Related Tickets: #10583 | Differential Rev(s): Phab:D1451 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: This won't be fixed for 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 14:22:31 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 14:22:31 -0000 Subject: [GHC] #10873: Bad error message for incorrect pattern synonym signature In-Reply-To: <049.1015737e7e3a324fd7db7cc49a97b354@haskell.org> References: <049.1015737e7e3a324fd7db7cc49a97b354@haskell.org> Message-ID: <064.8f3a7f85c4cb7a9329efdfd9eae5786b@haskell.org> #10873: Bad error message for incorrect pattern synonym signature -------------------------------------+------------------------------------- Reporter: mpickering | Owner: rdragon Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.2 checker) | Keywords: Resolution: fixed | PatternSynonyms Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1866 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * status: new => closed * resolution: => fixed Comment: This is greatly improved with the patch in comment:10. The original example now fails with, {{{ Hi.hs:6:22: error: ? No instance for (Show a) arising from the "provided" constraints claimed by the signature of ?Pat? In other words, a successful match on the pattern Just a does not provide the constraint (Show a) ? In the declaration for pattern synonym ?Pat? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 14:24:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 14:24:15 -0000 Subject: [GHC] #11642: Heterogeneous type equality evidence ignored In-Reply-To: <046.32db5cb4e79f0588d07e2dbd35cff7c7@haskell.org> References: <046.32db5cb4e79f0588d07e2dbd35cff7c7@haskell.org> Message-ID: <061.bedddf691b76ea96f78d9720f17b8b3a@haskell.org> #11642: Heterogeneous type equality evidence ignored -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 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 bgamari): * priority: high => highest Comment: Bumping in priority/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 14:28:55 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 14:28:55 -0000 Subject: [GHC] #11642: Heterogeneous type equality evidence ignored In-Reply-To: <046.32db5cb4e79f0588d07e2dbd35cff7c7@haskell.org> References: <046.32db5cb4e79f0588d07e2dbd35cff7c7@haskell.org> Message-ID: <061.c4f4bb95513b30eb06744099b8f85253@haskell.org> #11642: Heterogeneous type equality evidence ignored -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 7.10.3 checker) | Resolution: | Keywords: TypeInType Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => TypeInType Comment: Richard I think this needs your loving care. I had a look but ran out of time in a maze of twisty little casts, all alike. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 14:48:45 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 14:48:45 -0000 Subject: [GHC] #6113: Profiling with -p not written if killed with SIGTERM In-Reply-To: <045.764bc656e63c4390b5e307b27a89b060@haskell.org> References: <045.764bc656e63c4390b5e307b27a89b060@haskell.org> Message-ID: <060.e888ab9cf7d8299d2a4694babd011ba9@haskell.org> #6113: Profiling with -p not written if killed with SIGTERM -------------------------------------+------------------------------------- Reporter: Veinor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"e3b9dbf48c7b7b1ac4a5d6ecf1411469b5f7666c/ghc" e3b9dbf4/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="e3b9dbf48c7b7b1ac4a5d6ecf1411469b5f7666c" Testsuite: check actual_prof_file only when needed Might be a little faster. Avoids testing for #6113 (.prof file not written when process is killed with any signal but SIGINT) for tests that don't have a .prof.sample file (which is almost all of them) when running the profiling ways. Tests that were failing because of #6113: T8089, overflow1, overflow2 and overflow3. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 14:48:45 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 14:48:45 -0000 Subject: [GHC] #10752: Print which warning-flag controls/enabled an emitted warning In-Reply-To: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> References: <042.f644641d9b90b7c893a460f85d1840e2@haskell.org> Message-ID: <057.c8d696caf9cc5e87317d8aa554ae63e4@haskell.org> #10752: Print which warning-flag controls/enabled an emitted warning -------------------------------------+------------------------------------- Reporter: hvr | Owner: barrucadu Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1943 Wiki Page: Design/Warnings | -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"f8a5dd05ed50fe46eb86f30dc12f4c341b980e61/ghc" f8a5dd05/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="f8a5dd05ed50fe46eb86f30dc12f4c341b980e61" Only add -fshow-warning-groups for ghc >= 7.11 (#10752) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 14:55:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 14:55:16 -0000 Subject: [GHC] #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up In-Reply-To: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> References: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> Message-ID: <061.2d62f880a3d486730b7bc98c754c6d14@haskell.org> #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): We could still use some documentation for `Alternative` to point out this gotcha? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 15:05:22 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 15:05:22 -0000 Subject: [GHC] #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up In-Reply-To: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> References: <046.addb56c2356e84ea74ee83978f43632a@haskell.org> Message-ID: <061.8d0d703f321dd0fd38051ab152de7b33@haskell.org> #11650: Documentation does not mention that default definitions for Alternative(some, many) can easily blow up -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by RyanGlScott): We could, although I'm not quite sure what is the best way to describe the problem (and solution). There is a [https://mail.haskell.org/pipermail /haskell-cafe/2011-December/097589.html haskell-cafe] thread from 2011 which tried to address the issue of documenting `some`/`many` more precisely, but that never seemed to reach a consensus. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 15:45:06 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 15:45:06 -0000 Subject: [GHC] #10853: Refine addTopDecls In-Reply-To: <047.c86dd8a253022fe77935e07f26b94dc1@haskell.org> References: <047.c86dd8a253022fe77935e07f26b94dc1@haskell.org> Message-ID: <062.ca20d0a2b3b5f5c63fdd47a879d190a8@haskell.org> #10853: Refine addTopDecls -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Template Haskell | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by siddhanathan): * owner: siddhanathan => Comment: I haven't been able to keep up the TH changes in master, and I'm getting some weird behavior on current master with the restriction removed. I think someone else would be able to do this faster than I could. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 16:03:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 16:03:17 -0000 Subject: [GHC] #10886: Remove the magic from `Any` In-Reply-To: <047.f678cbb73069d1c6ee1f63fe7d449257@haskell.org> References: <047.f678cbb73069d1c6ee1f63fe7d449257@haskell.org> Message-ID: <062.0ff810d20706c27b549a609e839f6f13@haskell.org> #10886: Remove the magic from `Any` -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: normal | Milestone: 8.2.1 Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.2.1 Comment: Won't happen for GHC 8.0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 16:18:17 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 16:18:17 -0000 Subject: [GHC] #11054: GHC on Windows could not use more than 64 logical processors In-Reply-To: <045.741627474d8a57d1af2339a943171c04@haskell.org> References: <045.741627474d8a57d1af2339a943171c04@haskell.org> Message-ID: <060.39e6e946de2e912cf760232a4cac3cd1@haskell.org> #11054: GHC on Windows could not use more than 64 logical processors -------------------------------------+------------------------------------- Reporter: varosi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by thomie): Related: https://github.com/haskell/cabal/issues/3191 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 16:20:25 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 16:20:25 -0000 Subject: [GHC] #11596: ghci gets confused if a file is deleted In-Reply-To: <051.d9ce7de3f29efd32f3cc7f9d9dcf6a05@haskell.org> References: <051.d9ce7de3f29efd32f3cc7f9d9dcf6a05@haskell.org> Message-ID: <066.ea110cd565b89fc148696cda46f1b215@haskell.org> #11596: ghci gets confused if a file is deleted -------------------------------------+------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11256 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by jme): * related: => #11256 Comment: I also agree that the previous behavior is preferable. Unfortunately, it appears that the change was caused by the fix for #11256. One possibility is to restore the eager reporting of missing imports only when using GHCi. Or with a little more work, only when the source file which is importing the missing module hasn't changed since the last load/reload. Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 16:52:15 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 16:52:15 -0000 Subject: [GHC] #11555: catch _|_ breaks at -O1 In-Reply-To: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> References: <045.f4f0ac6dcd2c99c5fed8e1a116742666@haskell.org> Message-ID: <060.9d24d290754648bed0001d96d5b8c299@haskell.org> #11555: catch _|_ breaks at -O1 -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.0.1-rc2 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): Neil: re comment:12, can you boil out a smaller test case that shows what goes wrong with `safeCatch2`? Thanks! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 17:10:41 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 17:10:41 -0000 Subject: [GHC] #11660: Remove Type pretty-printer in favor of IfaceType Message-ID: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> #11660: Remove Type pretty-printer in favor of IfaceType -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The `Type` pretty-printer has a fair amount of code in common with the pretty-printer for `IfaceType`. Moreover, both cases handle a number of special cases. With the introduction of `-fprint-explicit-runtime-reps` (Phab:D1961), there is now an inconsistency between these two. Let's resolve this inconsistency by eliminating the `Type` pretty-printer in favor of using the `IfaceType` printer. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 17:16:53 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 17:16:53 -0000 Subject: [GHC] #11660: Remove Type pretty-printer in favor of IfaceType In-Reply-To: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> References: <046.fafe0c333321c83ab1a59d159df4d00e@haskell.org> Message-ID: <061.1c6dd41f71b6b8d33e742a8f82491cde@haskell.org> #11660: Remove Type pretty-printer in favor of IfaceType -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, this duplication has been annoying. I worry a bit in choosing to prioritize `IfaceType` over `Type` because `Type` can do more (that is, we have `typeKind` to hand). But perhaps it will enforce better pretty- printing hygiene to have fewer capabilities... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 17:23:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 17:23:43 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 In-Reply-To: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> References: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> Message-ID: <060.9cbab4b2ac82d310bd4d52484a4cbf51@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.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): I've been wondering if this dragon would bite. And now it has. Consider {{{ data T (a :: Proxy k) }}} Does that have a CUSK? According to the CUSK rules for datatypes, it does indeed: all of the type variables have a kind signature. But there's a problem in that we don't know `k`'s type! So this kind signature isn't complete. Instead, we should need to say, e.g., {{{ data T :: forall (k :: *). Proxy k -> * }}} Note the explicit `:: *` on `k`'s binder, which is necessary for us to have completely specify the kind. However, in looking more closely at this case, I don't actually think this is the problem. A mistake in detecting CUSKness should affect type inference and whether or not we have principal kinds, etc., but it shouldn't produce the drastic failure that we're seeing above. Somehow, it seems that `quantifyTyVars` is making a mistake. I don't have the ability to test this at the moment (I'm in an intermediate state) but should get to this later this week. I propose to fix the immediate problem (which should be straightforward) and then to delay the debate about CUSKs for another time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 17:30:23 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 17:30:23 -0000 Subject: [GHC] #11656: Alllow static pointers to local closed definitions In-Reply-To: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> References: <044.9cd8af9f533a09aabdba922a1db355ab@haskell.org> Message-ID: <059.8cca9e6ab79aa865f8051830ced49440@haskell.org> #11656: Alllow static pointers to local closed definitions -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by facundo.dominguez): This is the mechanism we were considering so far: 1. Have the renamer compute whether bindings in scope are closed. 2. When the renamer finds a static form, allow the free vars to be top- level or closed local bindings. 3. Desugar the static form. This produces a list of floated Core bindings. 4. For each such Core binding find the free variables of local definitions. 5. For each found local definition traverse the enclosing top-level binding to remove it. 6. Add each removed local definition at the top level. If it simplifies anything, a variant is to skip (5) and have (6) copy the local definitions as local definitions of the Core bindings produced in (3). This might duplicate local definitions once per static form in which they are used. Does copying definitions like this require also renaming bindings? Local definitions may transitively use other local definitions, in which case all of them should be floated. We were wondering if we are the first hackers in need of a function in GHC to determine if bindings are closed or not. Maybe someone could point if this is computed elsewhere already. We only found a flag {{{tct_closed}}} which only applies to types, not expressions. Is floating local definitions to the top-level disruptive for other compilation stages? We are open to proposals of alternative mechanisms. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 17:32:08 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 17:32:08 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 In-Reply-To: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> References: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> Message-ID: <060.6d81387b5e82e5c79f351df150d54bf7@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.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 don't think it's anything to do with `quantifyTyVars`. Under CUSK conditions we don't call `quantifyTyVars`; instead `kcHsTyVarBndrs` does something inscrutable to generate the offending kind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 17:34:37 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 17:34:37 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 In-Reply-To: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> References: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> Message-ID: <060.340b02d0b670bbdb9542b8c2a9a06c4a@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.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): But `quantifyTyVars` is called from `kindGeneralize` within `kcTyClGroup.generalise`, no? I agree that, if our CUSK check were totally accurate, we should skip `kcTyClDecl` and `generaliseTCD`, but we currently don't. So `quantifyTyVars` should get called. Or am I horribly confused? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 17:38:43 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 17:38:43 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.144bb7c0d675e86f08a6310a90a44316@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sjcjoosten): How about a program that would turn a sequence of characters into a sequence of space-characters of the same length? Such a program could be written as part of a pretty-printer or other template-like code. {{{ asIndentation chars = do{_<-chars;return ' '}::Seq Char }}} This particular example would benefit asymptotically from replacing {{{(\_ -> pure ' ') <$>}}} with {{{pure ' ' <$}}}. On a side note, I ran into this strange (but understandable) behavior, not sure if it should be considered a bug: {{{ Prelude Data.Sequence> :t (\x -> do{_ <- x; return x}) (\x -> do{_ <- x; return x}) :: Functor f => f t -> f (f t) Prelude Data.Sequence> :t (\x -> do{_ <- x; pure x}) (\x -> do{_ <- x; pure x}) :: Monad m => m a -> m (m a) Prelude Data.Sequence> :t (\x -> do{pure x}) (\x -> do{pure x}) :: Applicative f => a -> f a Prelude Data.Sequence> :t (\x -> do{return x}) (\x -> do{return x}) :: Monad m => a -> m a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 17:46:20 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 17:46:20 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 In-Reply-To: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> References: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> Message-ID: <060.2c5ca2f25daff088a781af2d307d25dc@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.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): Well maybe it does, but the ASSERT fails because in `getInitialKinds` because there is a CUSK we compute an initial kind for `MComp` that contains a unification variable. Now, if the ASSERT isn't there nothing actually breaks. But it's plainly wrong for `MComp` to have a kind (even temporarily) that has a free levity variable. I don't want to fix this by adding this bogus unification variable to the in-scope set; nor by disabling the ASSERT. But you could argue that since nothing is actually broken this doesn't matter, and the dragon is sleeping. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 17:47:47 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 17:47:47 -0000 Subject: [GHC] #10892: ApplicativeDo should use *> and <* In-Reply-To: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> References: <047.75544cc852e1b71af89f5571354ace9a@haskell.org> Message-ID: <062.57a5843db0d3820bafa752745a87d4ee@haskell.org> #10892: ApplicativeDo should use *> and <* -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 8.0.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: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:8 sjcjoosten]: > On a side note, I ran into this strange (but understandable) behavior, not sure if it should be considered a bug: > {{{ > Prelude Data.Sequence> :t (\x -> do{_ <- x; return x}) > (\x -> do{_ <- x; return x}) :: Functor f => f t -> f (f t) > Prelude Data.Sequence> :t (\x -> do{_ <- x; pure x}) > (\x -> do{_ <- x; pure x}) :: Monad m => m a -> m (m a) > Prelude Data.Sequence> :t (\x -> do{pure x}) > (\x -> do{pure x}) :: Applicative f => a -> f a > Prelude Data.Sequence> :t (\x -> do{return x}) > (\x -> do{return x}) :: Monad m => a -> m a > }}} This is #11607. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 17:59:36 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 17:59:36 -0000 Subject: [GHC] #11610: Remove IEThingAll constructor from IE datatype In-Reply-To: <049.74bfb9870839f9195b618b2e2024bba7@haskell.org> References: <049.74bfb9870839f9195b618b2e2024bba7@haskell.org> Message-ID: <064.2b9ef460c3a2e2a2cd423fb50997c2f4@haskell.org> #11610: Remove IEThingAll constructor from IE datatype -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by mpickering): Yes, Today you can write {{{#!hs {-# LANGUAGE PatternSynonyms #-} module Foo(T(.., P)) where data T = T pattern P :: T pattern P = T }}} which is documented here - http://downloads.haskell.org/~ghc/8.0.1-rc2/docs/html/users_guide/glasgow_exts.html #import-and-export-of-pattern-synonyms -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 18:49:44 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 18:49:44 -0000 Subject: [GHC] #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 In-Reply-To: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> References: <045.97169ce3e65115811faff1f74bae1fb0@haskell.org> Message-ID: <060.3d3252aa383ff2383b14cae8c4f7e824@haskell.org> #11648: assertPprPanic, called at compiler/types/TyCoRep.hs:1932 -------------------------------------+------------------------------------- Reporter: thomie | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler | Version: 8.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): Ah -- so the meta-tyvars aren't making it to the real `TyCon`, only the `TcTyCon`? It's quite normal for `TcTyCon`s to have meta-tyvars. (Indeed, that's what they're for.) But I'm missing some context. The ASSERT that's breaking is the check during substitutions. But which substitution? I don't see an obvious substitution in `getFamDeclInitialKind`. To be clear, I think there are two related problems going on: 1. The CUSK check is inaccurate in the presence of `TypeInType`, because implicitly-bound kind variables (like `k` in `data Proxy (a :: k)`) can have non-trivial types. 2. The code in !TcTyClsDecls is tripping over CUSK types that aren't actually CUSKs. I propose to fully defer (1). It can be triggered only with `TypeInType` enabled and has some thorny design issues. And when it goes wrong, it won't be catastrophic (i.e., no panicking, segfaulting, or launching rockets, just an unexpected -- but still sound -- result of type inference). (2) is the real issue at hand. And, currently without the ability to test, I don't fully understand what's going wrong. I hope to be out of my intermediate state today or tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 20:47:14 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 20:47:14 -0000 Subject: [GHC] #11661: Missing MonadFail instance for Q monad from TemplateHaskell Message-ID: <049.ba7b5aef3d5f3cb5cbf38862d89aa24e@haskell.org> #11661: Missing MonadFail instance for Q monad from TemplateHaskell -------------------------------------+------------------------------------- Reporter: PeterTrsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 8.0.1-rc2 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: -------------------------------------+------------------------------------- Since GHC 8.0.1 introduces MonadFailDesugaring one would expect Q monad to have an instance for MonadFail. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Feb 29 23:24:16 2016 From: ghc-devs at haskell.org (GHC) Date: Mon, 29 Feb 2016 23:24:16 -0000 Subject: [GHC] #11624: Cannot declare hs-boot declaration if there is already a value in scope In-Reply-To: <045.b9ceb4e2b51dd79931a13bc304d99595@haskell.org> References: <045.b9ceb4e2b51dd79931a13bc304d99595@haskell.org> Message-ID: <060.e4c7584c7f16df32b29b0e9130bbf4f5@haskell.org> #11624: Cannot declare hs-boot declaration if there is already a value in scope -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: highest | Milestone: 8.0.1 Component: Compiler (Type | Version: 8.0.1-rc2 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 RyanGlScott): * cc: RyanGlScott (added) -- Ticket URL: GHC The Glasgow Haskell Compiler