From ghc-devs at haskell.org Wed Apr 1 01:11:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 01:11:30 -0000 Subject: [GHC] #10221: LLVM does not work on OSX In-Reply-To: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> References: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> Message-ID: <061.bf2f690d97045904e72a5d546d5dfa35@haskell.org> #10221: LLVM does not work on OSX -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by yongqli): See also http://lpaste.net/129949 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 07:49:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 07:49:32 -0000 Subject: [GHC] #10225: GHC does not specialize based on type equality Message-ID: <046.56c40228dad7f1d8895238a61375d58f@haskell.org> #10225: GHC does not specialize based on type equality -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Based on my testing, it seems that if I have a function like f :: (v ~ V2) => v -> v this will be slower than f :: v -> v It would be great if GHC could do this optimization. The reason I want this is that I have written some very generic functions in my program, which are actually only used for one type. SPECIALIZE doesn't seem to do enough, as it's hard to get those GHC to "see" all of those types. As a compromise, I tried to tell GHC what those types actually are via type equalities, so that I can keep type constraints around for the future. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 07:49:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 07:49:47 -0000 Subject: [GHC] #10225: GHC does not specialize based on type equality In-Reply-To: <046.56c40228dad7f1d8895238a61375d58f@haskell.org> References: <046.56c40228dad7f1d8895238a61375d58f@haskell.org> Message-ID: <061.3de1badf26da168b0dd112ec0ef54326@haskell.org> #10225: GHC does not specialize based on type equality -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by yongqli: Old description: > Based on my testing, it seems that if I have a function like > > f :: (v ~ V2) => v -> v > > this will be slower than > > f :: v -> v > > It would be great if GHC could do this optimization. The reason I want > this is that I have written some very generic functions in my program, > which are actually only used for one type. SPECIALIZE doesn't seem to do > enough, as it's hard to get those GHC to "see" all of those types. As a > compromise, I tried to tell GHC what those types actually are via type > equalities, so that I can keep type constraints around for the future. New description: Based on my testing, it seems that if I have a function like f :: (v ~ V2) => v -> v this will be slower than f :: V2 -> V2 It would be great if GHC could do this optimization. The reason I want this is that I have written some very generic functions in my program, which are actually only used for one type. SPECIALIZE doesn't seem to do enough, as it's hard to get those GHC to "see" all of those types. As a compromise, I tried to tell GHC what those types actually are via type equalities, so that I can keep type constraints around for the future. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 07:54:26 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 07:54:26 -0000 Subject: [GHC] #3699: Wildcards in type functions In-Reply-To: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> References: <060.b01af1dc1c462193a392550aa45e1d6c@haskell.org> Message-ID: <075.5cfc9170c01855fec6f57e64064135fa@haskell.org> #3699: Wildcards in type functions -------------------------------------+------------------------------------- Reporter: | Owner: dalaing MartijnVanSteenbergen | Status: new Type: feature request | Milestone: 7.12.1 Priority: low | Version: 6.10.4 Component: Compiler (Type | Keywords: newcomer checker) | Architecture: Resolution: | Unknown/Multiple Operating System: Unknown/Multiple | Test Case: Type of failure: None/Unknown | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by dalaing): * owner: => dalaing -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 07:59:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 07:59:38 -0000 Subject: [GHC] #8811: Profiling output jumbled together In-Reply-To: <047.8dc5a7d9bb9c749a985d563ff91e4df0@haskell.org> References: <047.8dc5a7d9bb9c749a985d563ff91e4df0@haskell.org> Message-ID: <062.ba9ffb4a4cd9757406e0b4f8c093f640@haskell.org> #8811: Profiling output jumbled together -------------------------------------+------------------------------------- Reporter: augustss | Owner: dalaing Type: bug | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D779 -------------------------------------+------------------------------------- Changes (by dalaing): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 10:20:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 10:20:28 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.7da9d2c73874399fae3ee1c8498bb032@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by shachaf): This doesn't seem to be completely fixed: {{{ ?> type A = (() :: *) ?> type B = (() :: Constraint) ?> typeRep (Proxy :: Proxy A) == typeRep (Proxy :: Proxy B) True ?> typeRep (Proxy :: Proxy (Proxy A)) == typeRep (Proxy :: Proxy (Proxy B)) False }}} Though I can't think of a way to write `unsafeCoerce` in this case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 11:00:09 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 11:00:09 -0000 Subject: [GHC] #10218: GHC creates incorrect code which throws <> In-Reply-To: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> References: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> Message-ID: <061.64ca527fc9dfbe7de4d3ecd01a0644c9@haskell.org> #10218: GHC creates incorrect code which throws <> -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: yes Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jstolarek): I can confirm this happens on my 64bit Debian Wheezy with GHC 7.10.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 12:38:36 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 12:38:36 -0000 Subject: [GHC] #9724: reexport IsList class from a trustworthy module In-Reply-To: <044.b4b824d4864a7071bef003961687614b@haskell.org> References: <044.b4b824d4864a7071bef003961687614b@haskell.org> Message-ID: <059.438688c3f90a84168a1cb0260db52448@haskell.org> #9724: reexport IsList class from a trustworthy module -------------------------------------+------------------------------------- Reporter: int-e | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by oerjan): * cc: oerjan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 13:45:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 13:45:23 -0000 Subject: [GHC] #10226: Regression in constraint solver from 7.8 to 7.10 Message-ID: <044.82bc8202e2a2f838b899ceb019365912@haskell.org> #10226: Regression in constraint solver from 7.8 to 7.10 -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Best explained by example: {{{#!hs {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE AllowAmbiguousTypes #-} -- only necessary in 7.10 {-# LANGUAGE FlexibleContexts #-} -- necessary for showFromF' example type family F a type family FInv a -- This definition is accepted in 7.8 without anything extra, but requires -- AllowAmbiguousTypes in 7.10 (this, by itself, is not a problem): showFromF :: (Show a, FInv (F a) ~ a) => F a -> String showFromF fa = undefined -- Consider what happens when we attempt to call `showFromF` at some type b. -- In order to check that this is valid, we have to find an a such that -- -- > b ~ F a /\ Show a /\ FInv (F a) ~ a -- -- Introducing an intermeidate variable `x` for the result of `F a` gives us -- -- > b ~ F a /\ Show a /\ FInv x ~ a /\ F a ~ x -- -- Simplifying -- -- > b ~ x /\ Show a /\ FInv x ~ a /\ F a ~ x -- -- Set x := b -- -- > Show a /\ FInv b ~ a /\ F a ~ b -- -- Set a := FInv b -- -- > Show (FInv b) /\ FInv b ~ FInv b /\ F (FInv b) ~ b -- -- Simplifying -- -- > Show (FInv b) /\ F (FInv b) ~ b -- -- Indeed, we can give this definition in 7.8, but not in 7.10: showFromF' :: (Show (FInv b), F (FInv b) ~ b) => b -> String showFromF' = showFromF {------------------------------------------------------------------------------- In 7.10 the definition of showFromF' is not accepted, but it gets stranger. In 7.10 we cannot _call_ showFromF at all all, even at a concrete type. Below we try to call it at type b ~ Int. It would need to show > Show (FInv Int) /\ F (FInt Int) ~ Int all of which should easily get resolved, but somehow don't. -------------------------------------------------------------------------------} type instance F Int = Int type instance FInv Int = Int test :: String test = showFromF (0 :: Int) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 13:47:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 13:47:22 -0000 Subject: [GHC] #10226: Regression in constraint solver from 7.8 to 7.10 In-Reply-To: <044.82bc8202e2a2f838b899ceb019365912@haskell.org> References: <044.82bc8202e2a2f838b899ceb019365912@haskell.org> Message-ID: <059.1af9c44c084fc45c2f9d4f56edaa28ab@haskell.org> #10226: Regression in constraint solver from 7.8 to 7.10 -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 13:57:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 13:57:52 -0000 Subject: [GHC] #10226: Regression in constraint solver from 7.8 to 7.10 In-Reply-To: <044.82bc8202e2a2f838b899ceb019365912@haskell.org> References: <044.82bc8202e2a2f838b899ceb019365912@haskell.org> Message-ID: <059.ceb28383dabfef4dcc4880170db0c03c@haskell.org> #10226: Regression in constraint solver from 7.8 to 7.10 -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10009 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jstolarek (added) * related: => #10009 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 13:58:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 13:58:04 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.7ae6e4cda31dbfc46b65b6e4897399b0@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10226 | -------------------------------------+------------------------------------- Changes (by jstolarek): * related: => #10226 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 13:58:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 13:58:21 -0000 Subject: [GHC] #8057: Warn when supplying version number to package-qualified import In-Reply-To: <046.dcdda60f854692c73464ccaeed842287@haskell.org> References: <046.dcdda60f854692c73464ccaeed842287@haskell.org> Message-ID: <061.3623362ecb64a6704987367c4cb43493@haskell.org> #8057: Warn when supplying version number to package-qualified import -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by asr): * cc: asr@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 14:03:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 14:03:14 -0000 Subject: [GHC] #8057: Warn when supplying version number to package-qualified import In-Reply-To: <046.dcdda60f854692c73464ccaeed842287@haskell.org> References: <046.dcdda60f854692c73464ccaeed842287@haskell.org> Message-ID: <061.a991ff11c37699cd926ca4ec51b2b769@haskell.org> #8057: Warn when supplying version number to package-qualified import -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9225 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #9225 Comment: Oh, I just fixed this one (39 hours ago, see #9225)! Slated for 7.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 14:10:05 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 14:10:05 -0000 Subject: [GHC] #10226: Regression in constraint solver from 7.8 to 7.10 In-Reply-To: <044.82bc8202e2a2f838b899ceb019365912@haskell.org> References: <044.82bc8202e2a2f838b899ceb019365912@haskell.org> Message-ID: <059.dbab49dc25a902c05ac173138c2338fb@haskell.org> #10226: Regression in constraint solver from 7.8 to 7.10 -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: duplicate | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10009 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by edsko): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 14:10:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 14:10:15 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.8ae01b96a96bf8ab090821de789eed4a@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10226 | -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 14:16:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 14:16:22 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.85707cd8d50b8e0bf61a5962ab5b7d6e@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10226 | -------------------------------------+------------------------------------- Comment (by edsko): Reported this independently, didn't see this ticket, sorry. But we were just bitten by this in ide-backend as well (we can work around it with proxies). See https://ghc.haskell.org/trac/ghc/ticket/10226 for an independent example, might perhaps be useful as a second test case (and some detailed comments there as well). Note that I do *not* think, as per @simonpj 's comment above, that "It can always be fixed by adding a type signature". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 14:17:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 14:17:02 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.89df49406f51d3f7820b4c74a5fe9837@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10226 | -------------------------------------+------------------------------------- Changes (by kosmikus): * cc: kosmikus (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 16:48:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 16:48:44 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.ebf6744df32d80805e7f8f8d5d5848c0@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by goldfire): You've hit smack into a blind spot of a dark corner of GHC's type system: `*` and `Constraint` are actually considered interchangeable in Core. So this failure isn't terribly surprising. But it's indeed a bug. I don't think it should be too hard to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 17:25:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 17:25:06 -0000 Subject: [GHC] #10220: Imports from `.hspp` and `.hscpp` files not loaded in --make mode In-Reply-To: <045.620241abff5b66e6139f3b60e61ef101@haskell.org> References: <045.620241abff5b66e6139f3b60e61ef101@haskell.org> Message-ID: <060.5ececd66d850a6b09b36c5125300f1b3@haskell.org> #10220: Imports from `.hspp` and `.hscpp` files not loaded in --make mode -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Driver | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D778 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"7cec6c7b2973b34c18da1c74c87cead33bb1bfd7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7cec6c7b2973b34c18da1c74c87cead33bb1bfd7" Change which files --make thinks are 'Haskellish' (#10220) `.hspp` and `.hscpp` are haskell files that have already been preprocessed. Treat `.hspp` and `.hscpp` as Haskellish sources again, as they were before commit a10e1990. This way, ghc --make will load their imports. Make sure that `.cmm` and `.cmmcpp` are still not treated as Haskellish, by moving them out of `haskell_src_suffixes` (but still keeping them in haskellish_suffixes, though I'm not sure what the purpose of that group is). Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D778 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 17:25:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 17:25:06 -0000 Subject: [GHC] #10223: Cleanup `mk/build.mk.sample` In-Reply-To: <045.7ed59dbe44609faf808ed2eef55dcc31@haskell.org> References: <045.7ed59dbe44609faf808ed2eef55dcc31@haskell.org> Message-ID: <060.46e8271aad6e8b4714bb55ad12a3eb24@haskell.org> #10223: Cleanup `mk/build.mk.sample` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"3749c05216339df60e1ffbb28c8b957ad5020b00/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3749c05216339df60e1ffbb28c8b957ad5020b00" Reformat build flavours in build.mk.sample (#10223) Use same format for each build flavour, to make it easier to compare them. Refactoring only. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D782 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 17:27:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 17:27:17 -0000 Subject: [GHC] #10220: Imports from `.hspp` and `.hscpp` files not loaded in --make mode In-Reply-To: <045.620241abff5b66e6139f3b60e61ef101@haskell.org> References: <045.620241abff5b66e6139f3b60e61ef101@haskell.org> Message-ID: <060.9da3da446ddbb776f40c8170a5775605@haskell.org> #10220: Imports from `.hspp` and `.hscpp` files not loaded in --make mode -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Driver | Version: 7.8.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | driver/T10220 | Blocking: | Differential Revisions: Phab:D778 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * testcase: => driver/T10220 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 17:30:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 17:30:42 -0000 Subject: [GHC] #10223: Cleanup `mk/build.mk.sample` In-Reply-To: <045.7ed59dbe44609faf808ed2eef55dcc31@haskell.org> References: <045.7ed59dbe44609faf808ed2eef55dcc31@haskell.org> Message-ID: <060.af2acc7e5834c0c8f70878ae8fbf3707@haskell.org> #10223: Cleanup `mk/build.mk.sample` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"43351ff0905a098c382487c502ccad53783ba9ee/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="43351ff0905a098c382487c502ccad53783ba9ee" Filter out `-Rghc-timing` for V=0 builds (#10223) Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D783 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 19:12:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 19:12:16 -0000 Subject: [GHC] #9803: Poor error message for unbound variable in pattern synonym In-Reply-To: <047.24e2cdf338c6978d0128990061b5e44d@haskell.org> References: <047.24e2cdf338c6978d0128990061b5e44d@haskell.org> Message-ID: <062.86483fad002e4ebdc3ae6621e9426204@haskell.org> #9803: Poor error message for unbound variable in pattern synonym -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8841 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * cc: cactus (added) * component: Compiler => Compiler (Type checker) * related: => #8841 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 19:18:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 19:18:27 -0000 Subject: [GHC] #9737: List ANN in pragmas chapter of user manual In-Reply-To: <047.d95ed21ed5b0c0a2ce03e4a2154ae9c7@haskell.org> References: <047.d95ed21ed5b0c0a2ce03e4a2154ae9c7@haskell.org> Message-ID: <062.b240579177ca840ac9066339790b861d@haskell.org> #9737: List ANN in pragmas chapter of user manual -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): For future reference, `ANN` is described here: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/extending- ghc.html#annotation-pragmas -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 20:06:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 20:06:57 -0000 Subject: [GHC] #10221: LLVM does not work on OSX In-Reply-To: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> References: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> Message-ID: <061.6798d6666c7328e99b660c80468010f0@haskell.org> #10221: LLVM does not work on OSX -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): You probably have a non-Apple (e.g., homebrew) `clang` installed then, that doesn't know about `.macosx_version_min`. The use of `clang` (whichever one is first on your PATH) is hard-coded. I would guess that the original issue that led to this situation (#5636) is no longer relevant, but I don't know whether using the configured C compiler is more likely to work here in general. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 20:14:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 20:14:02 -0000 Subject: [GHC] #10221: LLVM does not work on OSX In-Reply-To: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> References: <046.a27bcc824218c152901bbcce2f7fae6d@haskell.org> Message-ID: <061.f5240ca4f7ed577bca2826b05f9cef47@haskell.org> #10221: LLVM does not work on OSX -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (LLVM) | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jakzale): Actually, it is seems to be the other way round. Apple's clang is based on LLVM 3.5, and it seems to have some difficulties with compiling the assembly code generated by LLVM used as backend (which is probably newer). Using the version of clang that comes with the LLVM used as a backend for GHC seems to sort out the problem for me. Try `PATH=/path/to/llvm ghc -fllvm File.hs` to ensure that GHC uses the correct version of clang. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 1 23:31:36 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 01 Apr 2015 23:31:36 -0000 Subject: [GHC] #10218: GHC creates incorrect code which throws <> In-Reply-To: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> References: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> Message-ID: <061.c3bac88b6d57c9bd222074c87dbf6edf@haskell.org> #10218: GHC creates incorrect code which throws <> -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: yes Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by AlexET): I have managed to reproduce on windows 64-bit on GHC-7.10.1. I have shrunk the example down. It requires linear, vector and transformers. It needs to be complied with -O1 and -feager-blackholes. The redundant constraint in the context of the type of guessStates is required for the bug to trigger. Inlining calc_zs also prevents the bug from triggering. Adding sharing between xs and ys in guessStates also prevents the bug. Changing the monad to the Identity monad prevents the bug. Removing the VectorSpace space class and just adding the constraints to LinAlg also prevents the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 00:29:34 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 00:29:34 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.54f8736eb444a5d78579304a8dee88d5@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.12.1 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 Revisions: -------------------------------------+------------------------------------- Changes (by bgamari): * cc: bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 00:45:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 00:45:42 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.e25d152e35aa2928971aafe5380927be@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by oerjan): I also thought of that core thing but I doubt that's it... it seems to me that it's just two more entities that don't have different TypeCons, like in the original report of this ticket, and which don't get kind information added since they're both kind monomorphic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 01:52:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 01:52:32 -0000 Subject: [GHC] #4931: hsc2hs emits invalid OPTIONS_GHC pragmas In-Reply-To: <044.1c25c557108c2107caf9aec19c931e7c@haskell.org> References: <044.1c25c557108c2107caf9aec19c931e7c@haskell.org> Message-ID: <059.95e46e7828fae38e064329afe7b41ccc@haskell.org> #4931: hsc2hs emits invalid OPTIONS_GHC pragmas -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: hsc2hs | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by peddie): I started to poke at this, following the second suggestion in comment:6. It's more complicated than I thought at first, because it ought to handle escaped strings (e.g. `#define FOO "bar \"baz\""`) and multiple command- line flags per line (though `hsc2hs` doesn't do this, the current code handles it). This is more than GHC has to do to parse `-D'"FOO BAR"'`, I think, because GHC gets handed `argv`. I have a patch that addresses the above cases, but it's ~22 lines in place of `words str`, and it's still ad-hoc parsing, so I hesitate to submit it. Can anyone suggest what I should shoot for here? Just address the immediate bug and punt on escaped strings etc.? More complicated ad-hoc parsing? Split as `argv` would be and pull in the command-line options parser? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 04:56:37 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 04:56:37 -0000 Subject: [GHC] #10194: Shouldn't this require ImpredicativeTypes? In-Reply-To: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> References: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> Message-ID: <062.464ba20bea06bb650c541386da86a515@haskell.org> #10194: Shouldn't this require ImpredicativeTypes? -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 07:13:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 07:13:42 -0000 Subject: [GHC] #10218: GHC creates incorrect code which throws <> In-Reply-To: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> References: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> Message-ID: <061.45d8d74e9e5306af55a9a539b2da7805@haskell.org> #10218: GHC creates incorrect code which throws <> -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: yes Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by shachaf): I simplified AlexET's example some more. This bug is very touchy. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 07:51:01 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 07:51:01 -0000 Subject: [GHC] #10218: GHC creates incorrect code which throws <> In-Reply-To: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> References: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> Message-ID: <061.46181e391a13a5e48e97aad5acd35b03@haskell.org> #10218: GHC creates incorrect code which throws <> -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: yes Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Did you systematically try enabling/disabling the various `-fsomething` options? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 08:00:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 08:00:56 -0000 Subject: [GHC] #4931: hsc2hs emits invalid OPTIONS_GHC pragmas In-Reply-To: <044.1c25c557108c2107caf9aec19c931e7c@haskell.org> References: <044.1c25c557108c2107caf9aec19c931e7c@haskell.org> Message-ID: <059.5736d2012137bc3a575a95e4634ecc22@haskell.org> #4931: hsc2hs emits invalid OPTIONS_GHC pragmas -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: hsc2hs | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Thanks for working on this. Check out `compiler/utils/Util.hs`, it has a function `toArgs` which seems to do what you need. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 09:26:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 09:26:27 -0000 Subject: [GHC] #10207: parser: ParStmt has incorrect SrcSpan In-Reply-To: <044.58d70da3f3be10a135bd8c2190ecc4c5@haskell.org> References: <044.58d70da3f3be10a135bd8c2190ecc4c5@haskell.org> Message-ID: <059.19c69d0e6dfa8c98eead8855e5e3655d@haskell.org> #10207: parser: ParStmt has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by alanz): * milestone: => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 09:27:21 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 09:27:21 -0000 Subject: [GHC] #10209: parser: opt_kind_sig has incorrect SrcSpan In-Reply-To: <044.4df35a96b087f820c01c3c57f4238bf6@haskell.org> References: <044.4df35a96b087f820c01c3c57f4238bf6@haskell.org> Message-ID: <059.2c5b7d60e78118955a139799cf1f5578@haskell.org> #10209: parser: opt_kind_sig has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by alanz): * milestone: => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 09:28:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 09:28:24 -0000 Subject: [GHC] #10214: parser: TransStmt has incorrect SrcSpan In-Reply-To: <049.354eb02c7a1c2cda9ae89642a039bee8@haskell.org> References: <049.354eb02c7a1c2cda9ae89642a039bee8@haskell.org> Message-ID: <064.fb2fad3ceb7569cd3a03a49e76217e84@haskell.org> #10214: parser: TransStmt has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by alanz): * milestone: => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 09:42:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 09:42:12 -0000 Subject: [GHC] #10145: :info (->) should list its fixity In-Reply-To: <045.b793bfebd21acea22cc8b71109f4ac0d@haskell.org> References: <045.b793bfebd21acea22cc8b71109f4ac0d@haskell.org> Message-ID: <060.4571d87fbbf321ac5324d7a163b44357@haskell.org> #10145: :info (->) should list its fixity -------------------------------------+------------------------------------- Reporter: oerjan | Owner: phadej Type: bug | Status: new Priority: low | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D741 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"0721e552b863c28ffb5920c70b208947831c3dc2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0721e552b863c28ffb5920c70b208947831c3dc2" Fake (->) fixity declaration (#10145) Reviewed By: simonpj, austin Differential Revision: https://phabricator.haskell.org/D741 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 09:42:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 09:42:12 -0000 Subject: [GHC] #10223: Cleanup `mk/build.mk.sample` In-Reply-To: <045.7ed59dbe44609faf808ed2eef55dcc31@haskell.org> References: <045.7ed59dbe44609faf808ed2eef55dcc31@haskell.org> Message-ID: <060.53b965df737adf847605079a6af37bd8@haskell.org> #10223: Cleanup `mk/build.mk.sample` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"9b66a7f3d04ed93972e7daa1c6307c8d68ac3720/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9b66a7f3d04ed93972e7daa1c6307c8d68ac3720" Do not set -fasm explicitly in build.mk.sample (#10223) On platforms that support -fasm, it is already the default, so we don't have to set it. Reviewed By: austin, erikd (tested on powerpc and armhf) Differential Revision: https://phabricator.haskell.org/D784 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 09:42:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 09:42:12 -0000 Subject: [GHC] #10223: Cleanup `mk/build.mk.sample` In-Reply-To: <045.7ed59dbe44609faf808ed2eef55dcc31@haskell.org> References: <045.7ed59dbe44609faf808ed2eef55dcc31@haskell.org> Message-ID: <060.3c459e72b7e0a4962d4b48827b278595@haskell.org> #10223: Cleanup `mk/build.mk.sample` -------------------------------------+------------------------------------- Reporter: thomie | Owner: thomie Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"4c1e1c870e294990a44d8d6837742fb0d00f5456/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4c1e1c870e294990a44d8d6837742fb0d00f5456" Disable same warnings for normal builds as for validate (#10223) The default validate settings currently disable some warnings in the libraries. This patch moves those settings to a new file called `mk/warnings.mk`, and applies them also to normal builds. Through uncommenting a line in build.mk, developers can now build with -Werror. -Werror is not the default, because: * We can not guarantee that the build is warning free on platforms we don't run regularly run validate (as part of continuous integration systems), and we still want the build to go through on those platforms. * quoting rwbarton on irc > "I think -Werror by default has come up in the past and the argument was that it is too annoying when you are doing nontrivial development" Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D785 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 09:46:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 09:46:12 -0000 Subject: [GHC] #10145: :info (->) should list its fixity In-Reply-To: <045.b793bfebd21acea22cc8b71109f4ac0d@haskell.org> References: <045.b793bfebd21acea22cc8b71109f4ac0d@haskell.org> Message-ID: <060.6b4337991b58b036e5a1c7997ff2157f@haskell.org> #10145: :info (->) should list its fixity -------------------------------------+------------------------------------- Reporter: oerjan | Owner: phadej Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: GHCi | Version: 7.8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | ghci/should_run/T10145 Related Tickets: | Blocking: | Differential Revisions: Phab:D741 -------------------------------------+------------------------------------- Changes (by thomie): * testcase: => ghci/should_run/T10145 * milestone: => 7.12.1 Comment: Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 10:58:55 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 10:58:55 -0000 Subject: [GHC] #4931: hsc2hs emits invalid OPTIONS_GHC pragmas In-Reply-To: <044.1c25c557108c2107caf9aec19c931e7c@haskell.org> References: <044.1c25c557108c2107caf9aec19c931e7c@haskell.org> Message-ID: <059.1de272b2cfbb146b5498041af993436d@haskell.org> #4931: hsc2hs emits invalid OPTIONS_GHC pragmas -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: hsc2hs | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by peddie): Thanks for the tip! I came across `toArgs` earlier and tried to use it at first, but on my example, `-optc-DFOO="bar baz" -optc-DQUUX="qq rr"` in the `OPTIONS_GHC` pragma yields `Right ["-optc-DFOO=\"bar","baz\"","-optc-DQUUX=\"qq","rr\""]` when I run it through `toArgs`. So it seems it's the same as `words` for this purpose. Have I misunderstood something? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 11:17:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 11:17:54 -0000 Subject: [GHC] #10227: Type checker cannot deduce type Message-ID: <047.38bc9ed8d3484bd4c9bcb2480f8e1743@haskell.org> #10227: Type checker cannot deduce type -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When using closed type families the type checker does not use all the information that the closedness condition implies. In the following module the type checker fails to deduce the type for `f`. But lets start with `descrIn` since it has the same problem. The deduced type is `(D d Bool ~ Bool, D d Double ~ Bool, D d (Maybe String) ~ Bool) => Descr d`. But it is (to quote Simon PJ) plain as a pikestaff that `D d Double ~ Bool` can only hold if `d ~ In`, since there are only two equations and it cannot be the second. Similar reasoning can be used to deduce all the commented out type signatures. {{{#!hs {-# LANGUAGE RecordWildCards, TypeFamilies, DataKinds, NoMonomorphismRestriction, FlexibleContexts #-} module Main(main) where import Data.Maybe data InOut = In | Out type family D (d :: InOut) a where D 'In a = Bool D 'Out a = a data Descr d = Descr { abc :: D d Bool, def :: D d Double, ghi :: D d (Maybe String) } --descrIn :: Descr 'In descrIn = Descr { abc = False, def = True, ghi = True } --f :: Descr 'Out -> Double f Descr{..} = def + read (fromMaybe "0" ghi) --g :: Descr 'In -> Descr 'Out g d = Descr { abc = if abc d then True else False, def = if def d then 1234 else 0, ghi = if ghi d then Just "3008" else Nothing } main :: IO () main = do print $ f $ g descrIn }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 11:32:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 11:32:28 -0000 Subject: [GHC] #4931: hsc2hs emits invalid OPTIONS_GHC pragmas In-Reply-To: <044.1c25c557108c2107caf9aec19c931e7c@haskell.org> References: <044.1c25c557108c2107caf9aec19c931e7c@haskell.org> Message-ID: <059.298088bfa1202bc8d19ad8d3b33bd2a5@haskell.org> #4931: hsc2hs emits invalid OPTIONS_GHC pragmas -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: hsc2hs | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): Yes, that could be considered a bug. If you could try fixing it, then we don't need to add another function. Check call sites of `toArgs` and `toCmdArgs` to make sure nothing breaks. {{{ *Main> toArgs "a \"b c\" d" Right ["a","b c","d"] *Main> toArgs "a\"b c\" d" Right ["a\"b","c\"","d"] -- * should be ["a\"b c\"", "d"] I suppose. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 11:45:14 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 11:45:14 -0000 Subject: [GHC] #4931: hsc2hs emits invalid OPTIONS_GHC pragmas In-Reply-To: <044.1c25c557108c2107caf9aec19c931e7c@haskell.org> References: <044.1c25c557108c2107caf9aec19c931e7c@haskell.org> Message-ID: <059.d65462c380012b9b5a27ce3be5b0c076@haskell.org> #4931: hsc2hs emits invalid OPTIONS_GHC pragmas -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: hsc2hs | Version: 7.0.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by peddie): Thank you for clarifying -- I couldn't tell from the comments that `toArgs` was expected to do something differently. I'll try that approach. I appreciate the guidance, as this is the first time I've dived into the GHC code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 13:44:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 13:44:48 -0000 Subject: [GHC] #10228: Increased memory usage with GHC 7.10.1 Message-ID: <048.689dfbc555185e5a975e80819cf26fc7@haskell.org> #10228: Increased memory usage with GHC 7.10.1 -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- (Repost from ghc-devs) I just uprgaded both of my machines to use GHC 7.10.1. I keep sandboxed installations of GHC and this means I had to rebuild Agda and Idris because the binaries built with GHC 7.8.4 were stored inside deactivated 7.8.4 sandbox. Sadly, I had problems building both Agda and Idris due to GHC taking up all of available memory. With Idris the problematic module was Idris.ElabTerm (~2900LOC). The interesting part of the story is that when I do a clean build of Idris GHC consumes all of memory when compiling that module and I have to kill the build. But when I restart the build after killing GHC the module is compiled using a reasonable amount of memory and within reasonable time. With Agda the problematic module is Agda.TypeChecking.Serialise (~2000LOC). The trick with killing the build and restarting it didn't work in this case. I had to compile Agda with GHC 7.8.4 (which works without problems though the mentioned module still requires a lot of memory) and alter my setup so that Agda binary is not stored inside GHC sandbox. I wonder if any of you came across similar issues with GHC 7.10.1? Do we have any performance data that allows to compare memory usage and performance of GHC 7.10.1 with previous stable releases? All of the above happened on 64bit Debian Wheezy with 2GB of RAM. On my second machine, this time with 4GB of RAM, compiling Agda ran out of memory (again Agda.TypeChecking.Serialise module) and I had to kill the build. But once I restarted the build the module was compiled succesfully in a matter of minutes and using around 50% of memory. This looks like some kind of memory leak in GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 14:30:30 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 14:30:30 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.b0b9efb9c75b0f1f283a32070429d57c@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Changes (by oerjan): * priority: normal => highest Comment: Sorry, but GHC 7.10.1 is still vulnerable. {{{ -- This exploit still works in GHC 7.10.1. -- By Shachaf Ben-Kiki, ?rjan Johansen and Nathan van Doorn {-# LANGUAGE Safe #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE ImpredicativeTypes #-} import Data.Typeable type E = (:~:) type PX = Proxy (((),()) => ()) type PY = Proxy (() -> () -> ()) data family F p a b newtype instance F a b PX = ID (a -> a) newtype instance F a b PY = UC (a -> b) {-# NOINLINE ecast #-} ecast :: E p q -> f p -> f q ecast Refl = id supercast :: F a b PX -> F a b PY supercast = case cast e of Just e' -> ecast e' where e = Refl e :: E PX PX uc :: a -> b uc = case supercast (ID id) of UC f -> f }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 15:40:55 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 15:40:55 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.3d76ec5395f0cc6789556ba31bacb845@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by diatchki): Hm, I think I can see what might be the issue, in fact there might be 2: * {{{() :: *}}} and {{{() :: Constraint}}} will end up having the same representation * Have to look at how we compute type reps for odd rank-2 types like {{{ ((),()) => () }}} I'll have a go at a fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 16:59:49 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 16:59:49 -0000 Subject: [GHC] #9723: Give Tab warning only once per file In-Reply-To: <046.f226613e47ca73faa0ff03e64040a117@haskell.org> References: <046.f226613e47ca73faa0ff03e64040a117@haskell.org> Message-ID: <061.37d5526f28f29de1a456e0b7c5f77a77@haskell.org> #9723: Give Tab warning only once per file -------------------------------------+------------------------------------- Reporter: nomeata | Owner: dalaing Type: feature request | Status: patch Priority: low | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D760 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"afcfb62b748c41d31b8c8e3ef7f623fa00a1cfd2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="afcfb62b748c41d31b8c8e3ef7f623fa00a1cfd2" Change 'Tab character' warnings so there is one per file (#9723) Reviewed By: nomeata, thomie Differential Revision: https://phabricator.haskell.org/D760 Signed-off-by: Dave Laing }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 17:02:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 17:02:44 -0000 Subject: [GHC] #9723: Give Tab warning only once per file In-Reply-To: <046.f226613e47ca73faa0ff03e64040a117@haskell.org> References: <046.f226613e47ca73faa0ff03e64040a117@haskell.org> Message-ID: <061.8195b7c6f05df243edb2fe858188b07e@haskell.org> #9723: Give Tab warning only once per file -------------------------------------+------------------------------------- Reporter: nomeata | Owner: dalaing Type: feature request | Status: closed Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | parser/should_compile/T9723{a,b} | Blocking: | Differential Revisions: Phab:D760 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * testcase: => parser/should_compile/T9723{a,b} * resolution: => fixed * milestone: => 7.12.1 Comment: Yeah! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 17:05:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 17:05:11 -0000 Subject: [GHC] #10229: setThreadAffinity assumes a certain CPU virtual core layout Message-ID: <042.260955fa92da12cf89056e026fcec607@haskell.org> #10229: setThreadAffinity assumes a certain CPU virtual core layout -------------------------------------+------------------------------------- Reporter: nh2 | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The {{{RTS -qa}}} option that can set thread affinity was implemented in https://git.haskell.org/ghc.git/commitdiff/31caec794c3978d55d79f715f21fb72948c9f300 {{{ // Schedules the thread to run on CPU n of m. m may be less than the // number of physical CPUs, in which case, the thread will be allowed // to run on CPU n, n+m, n+2m etc. void setThreadAffinity (nat n, nat m) }}} Today I discovered that on some machines, this option helps parallel performance (e.g. {{{+RTS -N4}}}) a lot, while on others it doesn't. Together with thomie on #ghc, I found out the reason: Lets assume I have 4 real cores with hyperthreading, so 8 virtual cores. The mapping of hyperthreading cores to physical cores is different across machines. On my one machine (Intel i5), the layout is 11223344, meaning that the first two vCPUs (hyperthreads) that the OS announces (visible e.g. in HTOP) map to the first physical core in the system, and so on. On my other machine (Intel Xeon), the layout is 12341234; here the 1st and the 5th vCPU map to the same physical core. This layout can be (on Linux) observed by running: {{{ cat /proc/cpuinfo|egrep "processor|physical id|core id" |sed 's/^processor/\nprocessor/g' }}} I do not know whether this layout is dictated by the processor, chosen by the OS, or even changing across reboots; what is clear is that the layout can vary across machines. Now, as explained by thomie: {{{ -qa will set your 4 capabilities to cores [(1,5), (2,6), (3,7), (4,8)], and then the os randomly chooses out of those tuples }}} This strategy is optimal for the 12341234 layout; for example, when running with -N4, it ensures that two threads are not scheduled onto vCPUs that are on the same physical core. The possible {{{+RTS -aq}}} choice {{{1__4_23_}}} is a great assignment in this case, as is {{{1234____}}} ({{{_}}} means the vCPU is not chosen). But for the 11223344, the choice {{{1234____}}} isn't good, because it uses only 2 of our 4 physical cores; our program now takes twice as long to run. ---- It seems likely to me that {{{setThreadAffinity}}} was written on a machine with 12341234 layout, and with the assumption that all machines have this layout. It would be great if we could change it to take the actual layout into account. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 17:32:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 17:32:39 -0000 Subject: [GHC] #10229: setThreadAffinity assumes a certain CPU virtual core layout In-Reply-To: <042.260955fa92da12cf89056e026fcec607@haskell.org> References: <042.260955fa92da12cf89056e026fcec607@haskell.org> Message-ID: <057.dade6cb67a11fbc960a6d4870d6613b2@haskell.org> #10229: setThreadAffinity assumes a certain CPU virtual core layout -------------------------------------+------------------------------------- Reporter: nh2 | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by fryguybob): I have a version of GHC that I use to allow explicit setting of thread affinity for GHC capabilities. https://github.com/fryguybob/ghc/commit/09f8abd6e89eb2c830b1dc0702ce9a0a0c4f3705 For a real patch we would want to think about the details of the RTS flag and file format as well as allowing some more friendly command-line options for common settings and low core counts (things that, at the moment, I don't have time to do). I needed explicit setting to get consistent results on a Xeon E5-2699v3 machine with 72 threads where we wanted to consider not only hyperthreads and sockets, but also the proximity of particular cores on the same die. Without setting thread affinity for capabilities results were quite scattered. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 17:36:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 17:36:03 -0000 Subject: [GHC] #10229: setThreadAffinity assumes a certain CPU virtual core layout In-Reply-To: <042.260955fa92da12cf89056e026fcec607@haskell.org> References: <042.260955fa92da12cf89056e026fcec607@haskell.org> Message-ID: <057.be81eb5f4b4de0120bc6ee4efae7f1a2@haskell.org> #10229: setThreadAffinity assumes a certain CPU virtual core layout -------------------------------------+------------------------------------- Reporter: nh2 | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by fryguybob): Also I'll note that the optimal mapping of capabilities to threads is very workload dependent. It also seems likely that, in the near future at least, the gains from finding the best mapping over what the OS gives you will continue to increase. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 17:49:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 17:49:58 -0000 Subject: [GHC] #10229: setThreadAffinity assumes a certain CPU virtual core layout In-Reply-To: <042.260955fa92da12cf89056e026fcec607@haskell.org> References: <042.260955fa92da12cf89056e026fcec607@haskell.org> Message-ID: <057.ff40ce0d84a2241f8e5e232fa38a33fc@haskell.org> #10229: setThreadAffinity assumes a certain CPU virtual core layout -------------------------------------+------------------------------------- Reporter: nh2 | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #1741 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: => #1741 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 18:53:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 18:53:39 -0000 Subject: [GHC] #10230: multiline literals doesn't work with CPP extension. Message-ID: <045.9376d599c752191abeb407238b734b88@haskell.org> #10230: multiline literals doesn't work with CPP extension. -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- If LANGUAGE CPP is enabled then multiline literals stops working. Steps to reproduce. 1. write a program with multiline literal: cat 1.hs {{{#!hs test = "mutli\ \line" main = putStrLn test }}} 2. it should compile without CPP: ghc 1.hs [1 of 1] Compiling Main ( 1.hs, 1.o ) Linking 1 ... 3. compile it with CPP extension Expected result: program compiles {{{ ghc 1.hs [1 of 1] Compiling Main ( 1.hs, 1.o ) Linking 1 ... }}} Actual result: compilation breaks {{{ ghc -XCPP 1.hs [1 of 1] Compiling Main ( 1.hs, 1.o ) [flags changed] 1.hs:1:18: lexical error in string/character literal at character 'l' }}} At least ghc-7.8.4 and ghc-7.10 are affected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 19:09:59 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 19:09:59 -0000 Subject: [GHC] #2710: -main-is flag in {-# OPTIONS #-} pragma not fully supported In-Reply-To: <049.221c5dae52503c4c900cfb790e2e9425@haskell.org> References: <049.221c5dae52503c4c900cfb790e2e9425@haskell.org> Message-ID: <064.3a5c7c0646752c174b5e0471a977e675@haskell.org> #2710: -main-is flag in {-# OPTIONS #-} pragma not fully supported -------------------------------------+------------------------------------- Reporter: Stephan202 | Owner: Type: bug | Status: infoneeded Priority: lowest | Milestone: 7.12.1 Component: Compiler | Version: 6.8.3 Resolution: | Keywords: -main-is Operating System: Unknown/Multiple | ghc Type of failure: Incorrect | Architecture: warning at compile-time | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #1312 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => infoneeded * related: => #1312 Comment: Please read the following irc discussion. {{{ thomie > Should `-main-is` be a dynamic flag? That is, should the following be allowed: {-# OPTIONS_GHC -main-is Foo.bar -#} thomie > It's currently broken #2710 thomie > But what should happen when it is specified in multiple modules? rwbarton > yeah, or if a module specifies that Main is another module rwbarton > it's really a link-time setting isn't it? rwbarton > Probably the only thing that makes sense to put in an OPTIONS pragma is for a module to redefine which of its own symbols is main, but I'm not sure even that is worth supporting rwbarton > for that matter, what does it mean to mean to specify in an OPTIONS pragma something like -rtsopts/-with-rtopts/-debug/etc. rwbarton > IMO anything like that that doesn't affect the compilation of an individual module should just be forbidden carter_cloud > sounds reasonable to me }}} If there are no objections, I'd like to close this ticket as wontfix, and open a new ticket to show a warning when -main-is/-rtsopts/-with- rtopts/-debug etc. are used in an OPTIONS pragma. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 19:26:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 19:26:08 -0000 Subject: [GHC] #10230: multiline literals doesn't work with CPP extension. In-Reply-To: <045.9376d599c752191abeb407238b734b88@haskell.org> References: <045.9376d599c752191abeb407238b734b88@haskell.org> Message-ID: <060.cd2c25e7938c76d7717ddc9d4547338c@haskell.org> #10230: multiline literals doesn't work with CPP extension. -------------------------------------+------------------------------------- Reporter: qnikst | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: If you use `-XCPP` then you are responsible for ensuring that the output of the C preprocessor is a valid Haskell program. Line continuations (`\` at the end of a line) are handled by the C preprocessor (so that you can define multi-line macros). See https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/options- phases.html#cpp-string-gaps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 21:04:57 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 21:04:57 -0000 Subject: [GHC] #10208: libffi issues executable stacks on i386 In-Reply-To: <045.d069052078e86f4dc9cd61c2cbb3a538@haskell.org> References: <045.d069052078e86f4dc9cd61c2cbb3a538@haskell.org> Message-ID: <060.b67155ca95016829411fe562a87cfa70@haskell.org> #10208: libffi issues executable stacks on i386 -----------------------------------+------------------------------------ Reporter: slyfox | Owner: simonmar Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D764 -----------------------------------+------------------------------------ Comment (by Sergei Trofimovich ): In [changeset:"47f821a1a24553dc29b9581b1a259a9b1394c955/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="47f821a1a24553dc29b9581b1a259a9b1394c955" libffi: backport noexecstack fix for x86/win32.S Got detected by gentoo's QA preinstall hook: * RWX --- --- usr/lib/ghc-7.10.1/rts/libffi.so.6.0.2 * RWX --- --- usr/lib/ghc-7.10.1/rts/libffi.so * RWX --- --- usr/lib/ghc-7.10.1/rts/libffi.so.6 * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi.a:win32.o * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_p.a:win32.o * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_l.a:win32.o * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_debug.a:win32.o * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_thr.a:win32.o * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_thr_debug.a:win32.o * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_thr_l.a:win32.o * !WX --- --- usr/lib/ghc-7.10.1/rts/libCffi_thr_p.a:win32.o Signed-off-by: Sergei Trofimovich Test Plan: built ghc-7.10.1 binary and checked stacks as NX Reviewers: rwbarton, hvr, austin Reviewed By: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D764 GHC Trac Issues: #10208 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 21:05:13 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 21:05:13 -0000 Subject: [GHC] #10231: TMVar - fmap - orElse clashes in ghc 7.8.4 Message-ID: <042.620d7d29164da7e2e1d8dc301b07ab66@haskell.org> #10231: TMVar - fmap - orElse clashes in ghc 7.8.4 -------------------------------------+------------------------------------- Reporter: ran | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.8.4 (other) | Operating System: Linux Keywords: | Type of failure: Incorrect result Architecture: x86_64 | at runtime (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Attached is a tar archive with minimal reproducible example. The problem is that after orElse success I get wrong constructor: I should have timer tick but get reset instead. That is, expected output is {{{ timer thread timer tick timer thread timer tick ... }}} but I get {{{ timer thread reset timer thread reset ... }}} The strange thing is that the problem presents, first, only when the binary is built by cabal (checked only inside sandbox): {{{ $ cabal sandbox init ... $ cabal configure Resolving dependencies... Configuring mvk-0.1.0.0... cabal: At least the following dependencies are missing: stm ==2.4.4 $ cabal install --dependencies-only ... $ cabal build }}} When I run {{{ cabal exec -- ghc --make mvk.hs }}} the resulting binary doesn't show the problem. Also, problem disappears if I: * either comment start of the (long-sleeping) reset thread at all; * or change content type of one of TMVars to, say, Bool But if I change type of content for both to, say, Bool, the problem presents. Furthermore, if with Bool content type I put False in timer thread and True in reset thread (and derive Show and output received value) I get {{{ timer thread received Reset False reset ... }}} That is, underlying Bool is right, but fmapped constructor is wrong. The problem was absent in Debian Wheezy's ghc 7.4.1 (not sure about STM version). Reproduced both in * Debian Jessie on x86_64 with GHC 7.8.4 binary from official site and cabal-install 1.20.0.3 from deb.haskell.org * Debian Wheezy on x86 with GHC 7.8.3 binary from deb.haskell.org and cabal-install 1.20.0.3 built by GHC from dist. In all cases used cabal.config from Stackage's lts-1.4 (included in the attached archive) Output from cabal build -v: {{{ Skipping add-source deps check... Using a sandbox located at /.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox The sandbox was created after the package was already configured. Re-configuring with most recently used options. If this fails, please run configure manually. Using a sandbox located at /.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox '/opt/ghc/7.8.4/bin/ghc' '--numeric-version' looking for tool ghc-pkg near compiler in /opt/ghc/7.8.4/bin found ghc-pkg in /opt/ghc/7.8.4/bin/ghc-pkg '/opt/ghc/7.8.4/bin/ghc-pkg' '--version' '/opt/ghc/7.8.4/bin/ghc' '--supported-languages' '/opt/ghc/7.8.4/bin/ghc' '--info' Reading available packages... Reading available packages... Choosing modular solver. Resolving dependencies... Configuring mvk-0.1.0.0... Dependency base ==4.7.0.2: using base-4.7.0.2 Dependency stm ==2.4.4: using stm-2.4.4 Using Cabal-1.20.0.0 compiled by ghc-7.4 Using compiler: ghc-7.8.4 Using install prefix: /.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox Binaries installed in: /.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox/bin Libraries installed in: /.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox/lib/x86_64 -linux-ghc-7.8.4/mvk-0.1.0.0 Private binaries installed in: /.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox/libexec Data files installed in: /.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox/share/x86_64 -linux-ghc-7.8.4/mvk-0.1.0.0 Documentation installed in: /.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox/share/doc/x86_64 -linux-ghc-7.8.4/mvk-0.1.0.0 Configuration files installed in: /.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox/etc Using alex version 3.1.3 found on system at: /usr/bin/alex Using ar found on system at: /usr/bin/ar No c2hs found No cpphs found No ffihugs found Using gcc version 4.9.2 found on system at: /usr/bin/gcc Using ghc version 7.8.4 found on system at: /opt/ghc/7.8.4/bin/ghc Using ghc-pkg version 7.8.4 found on system at: /opt/ghc/7.8.4/bin/ghc-pkg No greencard found Using haddock version 2.14.3 found on system at: /opt/ghc/7.8.4/bin/haddock Using happy version 1.19.4 found on system at: /usr/bin/happy Using haskell-suite found on system at: haskell-suite-dummy-location Using haskell-suite-pkg found on system at: haskell-suite-pkg-dummy- location No hmake found Using hpc version 0.67 found on system at: /opt/ghc/7.8.4/bin/hpc Using hsc2hs version 0.67 found on system at: /opt/ghc/7.8.4/bin/hsc2hs Using hscolour version 1.20 found on system at: /usr/bin/HsColour No hugs found No jhc found Using ld found on system at: /usr/bin/ld No lhc found No lhc-pkg found No nhc98 found Using pkg-config version 0.28 found on system at: /usr/bin/pkg-config Using strip found on system at: /usr/bin/strip Using tar found on system at: /bin/tar No uhc found Component build order: executable 'mvk' creating dist/build creating dist/build/autogen Building mvk-0.1.0.0... Preprocessing executable 'mvk' for mvk-0.1.0.0... Building executable mvk... creating dist/build/mvk creating dist/build/mvk/mvk-tmp /opt/ghc/7.8.4/bin/ghc --make -no-link -fbuilding-cabal-package -O -j4 -static -outputdir dist/build/mvk/mvk-tmp -odir dist/build/mvk/mvk-tmp -hidir dist/build/mvk/mvk-tmp -stubdir dist/build/mvk/mvk-tmp -i -idist/build/mvk/mvk-tmp -i. -idist/build/autogen -Idist/build/autogen -Idist/build/mvk/mvk-tmp -optP-include -optPdist/build/autogen/cabal_macros.h -hide-all-packages -no-user- package-db -package-db /.main/home/ran/src/transas/knei24/mvk.bug/.cabal- sandbox/x86_64-linux-ghc-7.8.4-packages.conf.d -package-db dist/package.conf.inplace -package-id base-4.7.0.2-bfd89587617e381ae01b8dd7b6c7f1c1 -package-id stm-2.4.4-c36cb8072081a12d13d98a3b4449e55c -XHaskell98 ./mvk.hs -Wall Linking... /opt/ghc/7.8.4/bin/ghc --make -fbuilding-cabal-package -O -static -outputdir dist/build/mvk/mvk-tmp -odir dist/build/mvk/mvk-tmp -hidir dist/build/mvk/mvk-tmp -stubdir dist/build/mvk/mvk-tmp -i -idist/build/mvk /mvk-tmp -i. -idist/build/autogen -Idist/build/autogen -Idist/build/mvk /mvk-tmp -optP-include -optPdist/build/autogen/cabal_macros.h -hide-all- packages -no-user-package-db -package-db /.main/home/ran/src/transas/knei24/mvk.bug/.cabal-sandbox/x86_64-linux- ghc-7.8.4-packages.conf.d -package-db dist/package.conf.inplace -package- id base-4.7.0.2-bfd89587617e381ae01b8dd7b6c7f1c1 -package-id stm-2.4.4-c36cb8072081a12d13d98a3b4449e55c -XHaskell98 ./mvk.hs -o dist/build/mvk/mvk -Wall Linking dist/build/mvk/mvk ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 21:07:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 21:07:24 -0000 Subject: [GHC] #10208: libffi issues executable stacks on i386 In-Reply-To: <045.d069052078e86f4dc9cd61c2cbb3a538@haskell.org> References: <045.d069052078e86f4dc9cd61c2cbb3a538@haskell.org> Message-ID: <060.f86bdaac3efa8d331c9b1d0277dd53a6@haskell.org> #10208: libffi issues executable stacks on i386 -----------------------------------+------------------------------------ Reporter: slyfox | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D764 -----------------------------------+------------------------------------ Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10` (via 56ecec4986d21468e7146017831a110bd3a4a86c). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 2 22:30:46 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 02 Apr 2015 22:30:46 -0000 Subject: [GHC] #10232: versionedAppDir ignores projectVersion from DynFlags Message-ID: <044.192b03678e7009d8d199d6157ad48aaf@haskell.org> #10232: versionedAppDir ignores projectVersion from DynFlags -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- versionedAppDir uses the constant cProjectVersion rather than (projectVersion dflags). versionedAppDir was introduced after GHC 7.10 RC1 and I unfortunately didn't catch this before the release. This changes the location of the user package DB, which is now inconsistent between Cabal and GHCJS, making the user pkg db unusable when GHC has been compiled with 7.10.1 Symlinking the user package db directory is a workaround, but it's only a partial solution since multiple GHCJS versions on the same GHC will clash. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 00:46:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 00:46:21 -0000 Subject: [GHC] #10233: Reexporting GHC.Exts does not export Constraint Message-ID: <044.25d86cfd1dd1041b5ff2433b8060fd47@haskell.org> #10233: Reexporting GHC.Exts does not export Constraint -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I expected the following code {{{ module T (module GHC.Exts) where import GHC.Exts (Constraint) }}} to reexport `Constraint`, but in fact `T` exports nothing at all. Explicitely exporting `Constraint` from `T` works as expected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 01:07:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 01:07:15 -0000 Subject: [GHC] #10218: GHC creates incorrect code which throws <> In-Reply-To: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> References: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> Message-ID: <061.39fa522578a2831b893ca03782412ced@haskell.org> #10218: GHC creates incorrect code which throws <> -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: yes Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by AlexET): I have simplified the example further. The difference between the working and not working cases is now really small. I think the simplifier core is mostly equal (modulo alpha). However the demand analysis is different. The core-prep also has a case in one which is a let in the other. The stg differ similarly. The cmm differs more (but the difference between a case and a let would cause a larger difference there). In terms of flags currently I know that specialise ,funbox-strict-fields and static-argument-transformation are uneeded. cse, strictness are needed. I will try more later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 02:25:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 02:25:41 -0000 Subject: [GHC] #10231: TMVar - fmap - orElse clashes in ghc 7.8.4 In-Reply-To: <042.620d7d29164da7e2e1d8dc301b07ab66@haskell.org> References: <042.620d7d29164da7e2e1d8dc301b07ab66@haskell.org> Message-ID: <057.939878477867817e8085c4fa0f2ed1c0@haskell.org> #10231: TMVar - fmap - orElse clashes in ghc 7.8.4 -------------------------------------+------------------------------------- Reporter: ran | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.8.4 (other) | Keywords: Resolution: | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by fryguybob): When using `unsafePerformIO` to make a global mutable variable like `timerTM` in your program you also need to have a `NOINLINE` pragma `{-# NOINLINE timerTM #-}` to avoid separate variables due to inlining (see [https://wiki.haskell.org/Top_level_mutable_state top level mutable state]): {{{ #!haskell timerTM :: TMVar () {-# NOINLINE timerTM #-} timerTM = unsafePerformIO $ newEmptyTMVarIO resetTM :: TMVar () {-# NOINLINE resetTM #-} resetTM = unsafePerformIO $ newEmptyTMVarIO }}} Can you try your test again with this change? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 02:32:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 02:32:53 -0000 Subject: [GHC] #10205: On Windows ghc-pkg always reports cache out of date In-Reply-To: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> References: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> Message-ID: <061.2665cc7c3ca91f040f6fc9fc1d0e425a@haskell.org> #10205: On Windows ghc-pkg always reports cache out of date -------------------------------------+------------------------------------- Reporter: hgolden | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: ghc-pkg | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: x86 Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by dmcclean): This happens to me too, on Windows 7 Home Premium, SP1, x64. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 02:36:20 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 02:36:20 -0000 Subject: [GHC] #10195: GHC forgets constraints when matching on GADTs In-Reply-To: <047.0020e481c0d5cc2154e7ca7e404b2a9e@haskell.org> References: <047.0020e481c0d5cc2154e7ca7e404b2a9e@haskell.org> Message-ID: <062.0c5a5a0e504c194b2ec5719401c2eec8@haskell.org> #10195: GHC forgets constraints when matching on GADTs -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by crockeea: Old description: > Here's a relatively short piece of code that doesn't compile: > > {{{#!hs > {-# LANGUAGE MultiParamTypeClasses, TypeFamilies, GADTs, > ConstraintKinds, KindSignatures, > FlexibleInstances #-} > > module Foo where > > import GHC.Exts > > data Foo m zp r'q = Foo zp > data Dict :: Constraint -> * where > Dict :: a => Dict a > > type family BarFamily a b :: Bool > class Bar m m' > instance (BarFamily m m' ~ 'True) => Bar m m' > > magic :: (Bar m m') => c m zp -> Foo m zp (c m' zq) > magic = error "" > getDict :: a -> Dict (Num a) > getDict _ = error "" > fromScalar :: r -> c m r > fromScalar = error "" > > foo :: (Bar m m') > => c m zp -> Foo m zp (c m' zq) -> Foo m zp (c m' zq) > foo b (Foo sc) = > let scinv = fromScalar sc > in case getDict scinv of > Dict -> magic $ scinv * b > }}} > > GHC complains that it {{{ cannot deduce (BarFamily m m' ~ 'True) arising > from a use of `magic` }}} in the definition of `foo`. Of course this is > silly: `magic` requires `Bar m m'`, which is supplied as a constraint to > `foo`. So GHC is forgetting about the constraint on `foo` and instead > trying to satisfy the generic instance of `Bar` which has the constraint > `(BarFamily m m' ~ 'True)`. > > I've found no less than six different ways to poke this code to make it > compile, and some of them seem to reveal dangerous/unexpected behavior. > The following are all deltas from the original code above and result in > compiling code. > > 1. Add `ScopedTypeVariables` and give `scinv` an explicit signature: > {{{ let scinv = fromScalar sc :: c m z in ... }}} > I'm not sure why this would make GHC suddenly realize that it > already has the constraint `Bar m m'`, but it seems to. (What it > definitely does *not* do is result in a `BarFamily m m' ~ 'True` > constraint.) > > 2. Remove the instance for `Bar`. > This seems highly suspicious: the presence (or lack thereof) of an > instance changes how GHC resolves the constraint in `foo`. > > 3. Change the constraint on `foo` to `BarFamily m m' ~ 'True`. In this > case, GHC does *not* forget the constraint on `foo` and successfully uses > it to satisfy the instance of `Bar`. Why does GHC forget about `Bar m m'` > but not `BarFamily m m' ~ 'True`? > > 4. Add the superclass constraint `BarFamily m m' ~ 'True` to class > `Bar`. Adding this constraint either makes GHC find the `Bar m m'` > constraint on `foo` or, even more bizarrely, GHC still forgets about `Bar > m m'` but manages to get the superclass constraint from `Bar m m'` and > uses it to satisfy the instance. > > 5. Add `PolyKinds`. Not sure why this would affect anything. > > 6. Change the signature of `fromScalar` to `r -> s`. Not sure why this > would affect anything. New description: Here's a relatively short piece of code that doesn't compile: {{{#!hs {-# LANGUAGE MultiParamTypeClasses, TypeFamilies, GADTs, ConstraintKinds, KindSignatures, FlexibleInstances #-} module Foo where import GHC.Exts data Foo m zp r'q = Foo zp data Dict :: Constraint -> * where Dict :: a => Dict a type family BarFamily a b :: Bool class Bar m m' instance (BarFamily m m' ~ 'True) => Bar m m' magic :: (Bar m m') => c m zp -> Foo m zp (c m' zq) magic = undefined getDict :: a -> Dict (Num a) getDict _ = undefined fromScalar :: r -> c m r fromScalar = undefined foo :: (Bar m m') => c m zp -> Foo m zp (c m' zq) -> Foo m zp (c m' zq) foo b (Foo sc) = let scinv = fromScalar sc in case getDict scinv of Dict -> magic $ scinv * b }}} GHC complains that it {{{ cannot deduce (BarFamily m m' ~ 'True) arising from a use of `magic` }}} in the definition of `foo`. Of course this is silly: `magic` requires `Bar m m'`, which is supplied as a constraint to `foo`. So GHC is forgetting about the constraint on `foo` and instead trying to satisfy the generic instance of `Bar` which has the constraint `(BarFamily m m' ~ 'True)`. I've found no less than six different ways to poke this code to make it compile, and some of them seem to reveal dangerous/unexpected behavior. The following are all deltas from the original code above and result in compiling code. 1. Add `ScopedTypeVariables` and give `scinv` an explicit signature: {{{ let scinv = fromScalar sc :: c m z in ... }}} I'm not sure why this would make GHC suddenly realize that it already has the constraint `Bar m m'`, but it seems to. (What it definitely does *not* do is result in a `BarFamily m m' ~ 'True` constraint.) 2. Remove the instance for `Bar`. This seems highly suspicious: the presence (or lack thereof) of an instance changes how GHC resolves the constraint in `foo`. 3. Change the constraint on `foo` to `BarFamily m m' ~ 'True`. In this case, GHC does *not* forget the constraint on `foo` and successfully uses it to satisfy the instance of `Bar`. Why does GHC forget about `Bar m m'` but not `BarFamily m m' ~ 'True`? 4. Add the superclass constraint `BarFamily m m' ~ 'True` to class `Bar`. Adding this constraint either makes GHC find the `Bar m m'` constraint on `foo` or, even more bizarrely, GHC still forgets about `Bar m m'` but manages to get the superclass constraint from `Bar m m'` and uses it to satisfy the instance. 5. Add `PolyKinds`. Not sure why this would affect anything. 6. Change the signature of `fromScalar` to `r -> s`. Not sure why this would affect anything. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 04:16:47 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 04:16:47 -0000 Subject: [GHC] #10234: Validate fails on armhf Message-ID: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> #10234: Validate fails on armhf -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build | Version: 7.11 System | Operating System: Unknown/Multiple Keywords: llvm | Type of failure: Other Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The failure is: {{{ /usr/bin/install -c -m 644 libraries/prologue.txt "/home/erikd/ghc- git/bindisttest/install dir/share/doc/ghc/html/libraries/" /usr/bin/install -c -m 755 libraries/gen_contents_index "/home/erikd/ghc- git/bindisttest/install dir/share/doc/ghc/html/libraries/" bindisttest/"install dir"/bin/runghc bindisttest/HelloWorld > bindisttest/output diff -U 1 bindisttest/output bindisttest/expected_output bindisttest/"install dir"/bin/ghc --make bindisttest/HelloWorld [1 of 1] Compiling Main ( bindisttest/HelloWorld.lhs, bindisttest/HelloWorld.o ) : Warning: Couldn't figure out LLVM version! Make sure you have installed LLVM ghc: could not execute: opt }}} Since this is armhf, this was built with llvm, and the configure process found the correct versions of the llvm tools; ie `/usr/bin/llc-3.6` and `/usr/bin/opt-3.6`. Furthermore, file `inplace/lib/settings` file specifies the correct versions. However, file `bindisttest/install dir/lib/ghc-7.11.20150402/settings` file just uses `llc` and `opt` which don't actually exist. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 04:16:57 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 04:16:57 -0000 Subject: [GHC] #10235: Get profiling info without stopping program Message-ID: <046.6c9d95866bf21a8a5f1fe2d9c5fba073@haskell.org> #10235: Get profiling info without stopping program -------------------------------------+------------------------------------- Reporter: mwotton | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I frequently want to know profiling information for web servers in production. Unfortunately there doesn't seem to be a way to trigger this without stopping the program, which might annoy my users. My ideal would be to able to call "dumpProfile :: Filename -> IO()" and then call that from a timer thread. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 04:37:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 04:37:01 -0000 Subject: [GHC] #10234: Validate fails on armhf In-Reply-To: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> References: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> Message-ID: <059.3fb38a83d6d798295073ee6b26516f48@haskell.org> #10234: Validate fails on armhf -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: llvm Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): The `configure` script in `bindistprep/ghc-7.11.20150402` contains: {{{ if test -z "$LlcCmd" then SettingsLlcCommand="llc" else SettingsLlcCommand="$LlcCmd" fi if test -z "$OptCmd" then SettingsOptCommand="opt" else SettingsOptCommand="$OptCmd" fi }}} and niether `LlcCmd` not `OptCmd` variables are set anywhere. Obviously, that is no longer sufficient. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 05:31:23 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 05:31:23 -0000 Subject: [GHC] #10236: DWARF unwind info is broken Message-ID: <052.423eb6b33b554d26dbce2d20e8e80a98@haskell.org> #10236: DWARF unwind info is broken -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice | Status: new Type: bug | Milestone: 7.10.2 Priority: high | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple (Debugging) | Type of failure: Incorrect result Keywords: dwarf | at runtime Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: Phab:D792 | -------------------------------------+------------------------------------- As reported by `bitonic` and `petermw` on `#ghc` (April 2nd): {{{ 07:02 < bitonic> I'm trying to get a meaningful backtrace with DWARF, using as a guide. however, all I get is `Backtrace stopped: previous frame identical to this frame (corrupt stack?)` 07:03 < bitonic> I've re-built GHC 7.10.1 using `GhcRtsHcOpts += -g` and `GhcLibHcOpts += -g`, even if I'm not sure it's even necessary 07:04 < bitonic> are there any additional steps I should take? or any way to make sure that the binary I'm generating is sane? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 05:33:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 05:33:03 -0000 Subject: [GHC] #10110: Compiling unit fails with Loading temp shared object failed In-Reply-To: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> References: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> Message-ID: <062.7943a3dd3d1ec3b674fe6333c3712792@haskell.org> #10110: Compiling unit fails with Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: highest | Milestone: 7.10.2 Component: Template Haskell | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10058 | Differential Revisions: Phab:D731 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"13a0d5ac95a80e8b3604e084ae189da405a47270/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="13a0d5ac95a80e8b3604e084ae189da405a47270" clarify --no-as-needed is only needed on ELF From the code it was not clear that `--no-as-needed` was not necessary on Windows. Add this fact and describe the fix for #10110 in a separate note. See audit for rGHC1b7f59769052fd8193c6acc561216e070d0ca335 raised by @thomie. Reviewed By: thomie Differential Revision: https://phabricator.haskell.org/D791 GHC Trac Issues: #10110 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 05:33:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 05:33:03 -0000 Subject: [GHC] #10236: DWARF unwind info is broken In-Reply-To: <052.423eb6b33b554d26dbce2d20e8e80a98@haskell.org> References: <052.423eb6b33b554d26dbce2d20e8e80a98@haskell.org> Message-ID: <067.1b881cc788d0fa270f709d6f3ba073c6@haskell.org> #10236: DWARF unwind info is broken -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Debugging) | Keywords: dwarf Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Phab:D792 Related Tickets: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"59f7a7b6091e9c0564f3f370d09398d8c9cd8ad5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="59f7a7b6091e9c0564f3f370d09398d8c9cd8ad5" Restore unwind information generation While we want to reduce the amount of information generated into debug_info, it really doesn't make sense to remove block information for unwinding. This is a simple oversight introduced in 4ab57024, which severly reduces the usefulness of generated unwind data. Thanks to bitonic for spotting this! Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D792 GHC Trac Issues: #10236 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 05:39:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 05:39:05 -0000 Subject: [GHC] #10236: DWARF unwind info is broken In-Reply-To: <052.423eb6b33b554d26dbce2d20e8e80a98@haskell.org> References: <052.423eb6b33b554d26dbce2d20e8e80a98@haskell.org> Message-ID: <067.191d9f293e798bcd7ac155cc47a07b4b@haskell.org> #10236: DWARF unwind info is broken -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Debugging) | Keywords: dwarf Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Phab:D792 Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 05:42:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 05:42:38 -0000 Subject: [GHC] #10236: DWARF unwind info is broken In-Reply-To: <052.423eb6b33b554d26dbce2d20e8e80a98@haskell.org> References: <052.423eb6b33b554d26dbce2d20e8e80a98@haskell.org> Message-ID: <067.be1a92f637f66719c96cf071f61853d8@haskell.org> #10236: DWARF unwind info is broken -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Debugging) | Keywords: dwarf Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Phab:D792 Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10` via 2f7eb6c74f4c7f0f6ea4eea476cf56bdbb7d0d62. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 05:44:29 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 05:44:29 -0000 Subject: [GHC] #10110: Compiling unit fails with Loading temp shared object failed In-Reply-To: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> References: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> Message-ID: <062.0bcd2f8368129c4496e31ed036613d68@haskell.org> #10110: Compiling unit fails with Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Template Haskell | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10058 | Differential Revisions: Phab:D731, | Phab:D791 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: trommler => * priority: highest => high * differential: Phab:D731 => Phab:D731, Phab:D791 * status: patch => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 05:44:47 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 05:44:47 -0000 Subject: [GHC] #10110: Compiling unit fails with Loading temp shared object failed In-Reply-To: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> References: <047.f770ac35bffd0831096ff597afaa0bde@haskell.org> Message-ID: <062.2ea369b79f9f83cb235f1e1013567182@haskell.org> #10110: Compiling unit fails with Loading temp shared object failed -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Template Haskell | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #10058 | Differential Revisions: Phab:D731, | Phab:D791 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: => trommler -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 05:49:47 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 05:49:47 -0000 Subject: [GHC] #10188: prefix type-level cons can't be parsed In-Reply-To: <048.7e4900ef2bdc3f1cec59a189bfabf4f0@haskell.org> References: <048.7e4900ef2bdc3f1cec59a189bfabf4f0@haskell.org> Message-ID: <063.e134f070b7db5b1e8f66f2d35a8e1d33@haskell.org> #10188: prefix type-level cons can't be parsed -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Kinokkory Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Phab:D768 Related Tickets: #10189 | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"012ea0b96cc041bced4565d74bef7ccb75f1af0d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="012ea0b96cc041bced4565d74bef7ccb75f1af0d" parser: allow type-level cons in prefix position Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D768 GHC Trac Issues: #10188 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 05:49:47 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 05:49:47 -0000 Subject: [GHC] #10213: GHC User Guide documentation of -fwarn-tabs is now incorrect In-Reply-To: <046.b07a81ccfccd7d2f630b4e33f5b84abb@haskell.org> References: <046.b07a81ccfccd7d2f630b4e33f5b84abb@haskell.org> Message-ID: <061.7e4a29d6c9391e0f202b3ae58aba196a@haskell.org> #10213: GHC User Guide documentation of -fwarn-tabs is now incorrect -------------------------------------+------------------------------------- Reporter: bmjames | Owner: dalaing Type: bug | Status: patch Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D772 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"2255c76c7049314d3d8545efb6317688ba0da72c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2255c76c7049314d3d8545efb6317688ba0da72c" Remove an incorrect statement about -fwarn-tabs Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D772 GHC Trac Issues: #10213 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 05:51:24 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 05:51:24 -0000 Subject: [GHC] #10213: GHC User Guide documentation of -fwarn-tabs is now incorrect In-Reply-To: <046.b07a81ccfccd7d2f630b4e33f5b84abb@haskell.org> References: <046.b07a81ccfccd7d2f630b4e33f5b84abb@haskell.org> Message-ID: <061.11511f3b8a732b104bf04eee16792149@haskell.org> #10213: GHC User Guide documentation of -fwarn-tabs is now incorrect -------------------------------------+------------------------------------- Reporter: bmjames | Owner: dalaing Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Documentation | Version: 7.10.1 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D772 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed * milestone: => 7.10.2 Comment: Merged, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 06:02:06 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 06:02:06 -0000 Subject: [GHC] #10205: On Windows ghc-pkg always reports cache out of date In-Reply-To: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> References: <046.5c996b873263a26e2fbcfb59ab0dc22d@haskell.org> Message-ID: <061.ac8af6dcaad82550f1d4927da0575a40@haskell.org> #10205: On Windows ghc-pkg always reports cache out of date -------------------------------------+------------------------------------- Reporter: hgolden | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: ghc-pkg | Version: 7.10.1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * architecture: x86 => Unknown/Multiple * milestone: => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 07:14:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 07:14:28 -0000 Subject: [GHC] #10237: compiler/ghci/LibFFI.hsc:42 sizeof(ffi_cif) is not an integer Message-ID: <044.d74cccd78b90a9b3ae1f196d2af9942f@haskell.org> #10237: compiler/ghci/LibFFI.hsc:42 sizeof(ffi_cif) is not an integer -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Cross-compiling from linux-amd64 to linux-armhf and I get the above error message. The command (after removing a bunhc of irrelevant command line flags) is: {{{ inplace/bin/hsc2hs --cc=/usr/bin/aarch64-linux-gnu-gcc \ --ld=/usr/bin/aarch64-linux-gnu-gcc \ --cross-safe --cflag=-fno-stack-protector --cross-compile \ --cflag=-Daarch64_HOST_ARCH=1 \ --cflag=-Dlinux_HOST_OS=1 --cflag=-D__GLASGOW_HASKELL__=711 \ --cflag=-Icompiler/../rts/dist/build \ --cflag=-Werror=unused-but-set-variable \ --cflag=-include \ --cflag=compiler/stage2/build/autogen/cabal_macros.h \ compiler/ghci/LibFFI.hsc -o compiler/stage2/build/LibFFI.hs }}} The command `grep 'sizeof(ffi_cif)' compiler/ghci/LibFFI.hsc` finds: {{{#!hs cif <- mallocBytes (#const sizeof(ffi_cif)) }}} Native compile on this system works fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 07:28:56 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 07:28:56 -0000 Subject: [GHC] #10237: compiler/ghci/LibFFI.hsc:42 sizeof(ffi_cif) is not an integer In-Reply-To: <044.d74cccd78b90a9b3ae1f196d2af9942f@haskell.org> References: <044.d74cccd78b90a9b3ae1f196d2af9942f@haskell.org> Message-ID: <059.464f083d82f0be47ea57e5ec4324f22d@haskell.org> #10237: compiler/ghci/LibFFI.hsc:42 sizeof(ffi_cif) is not an integer -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by erikd: Old description: > Cross-compiling from linux-amd64 to linux-armhf and I get the above error > message. The command (after removing a bunhc of irrelevant command line > flags) is: > > {{{ > inplace/bin/hsc2hs --cc=/usr/bin/aarch64-linux-gnu-gcc \ > --ld=/usr/bin/aarch64-linux-gnu-gcc \ > --cross-safe --cflag=-fno-stack-protector --cross-compile \ > --cflag=-Daarch64_HOST_ARCH=1 \ > --cflag=-Dlinux_HOST_OS=1 --cflag=-D__GLASGOW_HASKELL__=711 \ > --cflag=-Icompiler/../rts/dist/build \ > --cflag=-Werror=unused-but-set-variable \ > --cflag=-include \ > --cflag=compiler/stage2/build/autogen/cabal_macros.h \ > compiler/ghci/LibFFI.hsc -o compiler/stage2/build/LibFFI.hs > }}} > > The command `grep 'sizeof(ffi_cif)' compiler/ghci/LibFFI.hsc` finds: > > {{{#!hs > cif <- mallocBytes (#const sizeof(ffi_cif)) > }}} > > Native compile on this system works fine. New description: Cross-compiling git HEAD from linux-amd64 to linux-aarch64 and I get the above error message. The command (after removing a bunhc of irrelevant command line flags) is: {{{ inplace/bin/hsc2hs --cc=/usr/bin/aarch64-linux-gnu-gcc \ --ld=/usr/bin/aarch64-linux-gnu-gcc \ --cross-safe --cflag=-fno-stack-protector --cross-compile \ --cflag=-Daarch64_HOST_ARCH=1 \ --cflag=-Dlinux_HOST_OS=1 --cflag=-D__GLASGOW_HASKELL__=711 \ --cflag=-Icompiler/../rts/dist/build \ --cflag=-Werror=unused-but-set-variable \ --cflag=-include \ --cflag=compiler/stage2/build/autogen/cabal_macros.h \ compiler/ghci/LibFFI.hsc -o compiler/stage2/build/LibFFI.hs }}} The command `grep 'sizeof(ffi_cif)' compiler/ghci/LibFFI.hsc` finds: {{{#!hs cif <- mallocBytes (#const sizeof(ffi_cif)) }}} Native compile on this system works fine. Checking out an older revision that was know to compile correctly also fails. That suggests that something in the tool chain has changed. My GHC is still 7.8.3, but `aarch64-linux-gnu-gcc` was recently updated. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 07:37:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 07:37:31 -0000 Subject: [GHC] #10237: compiler/ghci/LibFFI.hsc:42 sizeof(ffi_cif) is not an integer In-Reply-To: <044.d74cccd78b90a9b3ae1f196d2af9942f@haskell.org> References: <044.d74cccd78b90a9b3ae1f196d2af9942f@haskell.org> Message-ID: <059.559aa3ffb89ec4e2e75911f89c99f0d4@haskell.org> #10237: compiler/ghci/LibFFI.hsc:42 sizeof(ffi_cif) is not an integer -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Nope, `aarch64-linux-gnu-gcc` was changed over a month ago and this was working much more recently than that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 07:52:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 07:52:08 -0000 Subject: [GHC] #10234: Validate fails on armhf In-Reply-To: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> References: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> Message-ID: <059.595ac74287d0d57de0891ced602059df@haskell.org> #10234: Validate fails on armhf -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: llvm Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): It seems the distribution tarball has its own configure script (generated from `distrib/configure.ac.in`) which needs to be updated to include some of the configure magic in the top level `configure.ac`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 08:10:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 08:10:48 -0000 Subject: [GHC] #10238: Update libffi shortly before first GHC 7.12.1 RC Message-ID: <042.27be62378f24cc29ae2d842288972a74@haskell.org> #10238: Update libffi shortly before first GHC 7.12.1 RC -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: highest | Milestone: 7.12.1 Component: Runtime | Version: System | Operating System: Unknown/Multiple Keywords: libffi | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Making this ticket so I don't forget to check for the latest libffi release shortly before the first RC (like I missed that "libffi-3.2.1 was released on November 12, 2014" which would have been in time for 7.10.1RC1) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 08:14:55 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 08:14:55 -0000 Subject: [GHC] #10208: libffi issues executable stacks on i386 In-Reply-To: <045.d069052078e86f4dc9cd61c2cbb3a538@haskell.org> References: <045.d069052078e86f4dc9cd61c2cbb3a538@haskell.org> Message-ID: <060.77e9c90098aef1fbe57f5853d4c51586@haskell.org> #10208: libffi issues executable stacks on i386 -----------------------------------+------------------------------------ Reporter: slyfox | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Runtime System | Version: 7.10.1 Resolution: fixed | Keywords: libffi Operating System: Linux | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D764 -----------------------------------+------------------------------------ Changes (by hvr): * keywords: => libffi -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 08:31:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 08:31:26 -0000 Subject: [GHC] #10237: compiler/ghci/LibFFI.hsc:42 sizeof(ffi_cif) is not an integer In-Reply-To: <044.d74cccd78b90a9b3ae1f196d2af9942f@haskell.org> References: <044.d74cccd78b90a9b3ae1f196d2af9942f@haskell.org> Message-ID: <059.2b5868a2b745aa2f46bdf4fd79db433a@haskell.org> #10237: compiler/ghci/LibFFI.hsc:42 sizeof(ffi_cif) is not an integer -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Ok, here's the problem: {{{ LibFFI.hsc: In function ?_hsc2hs_test?: LibFFI.hsc:11:14: error: variable ?test_array? set but not used [-Werror =unused-but-set-variable] cc1: some warnings being treated as errors }}} It seems `hsc2hs` generates some test files to measure the size of values that looks like this: {{{ void _hsc2hs_test() { static int test_array[1 - 2 * !((long long)(sizeof(ffi_cif)) == (sizeof(ffi_cif)))]; test_array[0] = 0; } }}} The value of `test_array[0]` is set but not used. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 08:35:42 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 08:35:42 -0000 Subject: [GHC] #10237: compiler/ghci/LibFFI.hsc:42 sizeof(ffi_cif) is not an integer In-Reply-To: <044.d74cccd78b90a9b3ae1f196d2af9942f@haskell.org> References: <044.d74cccd78b90a9b3ae1f196d2af9942f@haskell.org> Message-ID: <059.830837fe42f2e22d8ff5ce30e7d71b6f@haskell.org> #10237: compiler/ghci/LibFFI.hsc:42 sizeof(ffi_cif) is not an integer -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Ah, the code path is different for the native compiler case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 08:51:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 08:51:22 -0000 Subject: [GHC] #10231: TMVar - fmap - orElse clashes in ghc 7.8.4 In-Reply-To: <042.620d7d29164da7e2e1d8dc301b07ab66@haskell.org> References: <042.620d7d29164da7e2e1d8dc301b07ab66@haskell.org> Message-ID: <057.28b73bb87f68895cbd3523ce528cb986@haskell.org> #10231: TMVar - fmap - orElse clashes in ghc 7.8.4 -------------------------------------+------------------------------------- Reporter: ran | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries | Version: 7.8.4 (other) | Keywords: Resolution: worksforme | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by ran): * status: new => closed * resolution: => worksforme Comment: NOINLINE helps, thank you -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 08:51:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 08:51:32 -0000 Subject: [GHC] #10239: Fragile CPP test for big endian in T7600 Message-ID: <047.4141fef62b155ef45c7ff2e676f4002e@haskell.org> #10239: Fragile CPP test for big endian in T7600 -------------------------------------+------------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Blocked By: Test Case: T7600 | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In test T7600 the C pre-processor test for big endian is broken in older versions of glibc. I have a patch that replaces the fragile CPP test with an integer read, which will always be the correct endianness. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 09:27:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 09:27:30 -0000 Subject: [GHC] #10239: Fragile CPP test for big endian in T7600 In-Reply-To: <047.4141fef62b155ef45c7ff2e676f4002e@haskell.org> References: <047.4141fef62b155ef45c7ff2e676f4002e@haskell.org> Message-ID: <062.949173b1ff8aeff61bb30622e92ab4cc@haskell.org> #10239: Fragile CPP test for big endian in T7600 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: T7600 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by trommler): * owner: => trommler -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 09:37:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 09:37:30 -0000 Subject: [GHC] #10237: compiler/ghci/LibFFI.hsc:42 sizeof(ffi_cif) is not an integer In-Reply-To: <044.d74cccd78b90a9b3ae1f196d2af9942f@haskell.org> References: <044.d74cccd78b90a9b3ae1f196d2af9942f@haskell.org> Message-ID: <059.9c4d7c526882d82ff4a670661aee8434@haskell.org> #10237: compiler/ghci/LibFFI.hsc:42 sizeof(ffi_cif) is not an integer -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * status: new => patch Comment: Patch attached. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 09:39:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 09:39:05 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.5ab05bda5c50eb467f6758008361a4ea@haskell.org> #8276: Building Haddock documentation panics with perf build on x86_64 Linux -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | thoughtpolice Priority: high | Status: new Component: Documentation | Milestone: 7.10.2 Resolution: | Version: 7.7 Operating System: Unknown/Multiple | Keywords: Type of failure: Compile-time | Architecture: x86_64 crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mjmrotek): Hello, A similar panic also happens when running Liquid Haskell [http://goto.ucsd.edu/~rjhala/liquid/haskell/blog/about/] on a file that uses the Units of Measure plugin [https://github.com/adamgundry/uom- plugin] {{{ liquid: liquid: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): Static flags have not been initialised! Please call GHC.parseStaticFlags early enough. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 09:42:37 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 09:42:37 -0000 Subject: [GHC] #10239: Fragile CPP test for big endian in T7600 In-Reply-To: <047.4141fef62b155ef45c7ff2e676f4002e@haskell.org> References: <047.4141fef62b155ef45c7ff2e676f4002e@haskell.org> Message-ID: <062.e11096e1ee0d2759f1603c49678414c4@haskell.org> #10239: Fragile CPP test for big endian in T7600 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: T7600 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by trommler): This is fixed in HEAD. The fix is to include `ghcconfig.h`, which defines the appropriate macro. I'll submit my patch anyway and we can discuss it in Phabricator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 10:01:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 10:01:31 -0000 Subject: [GHC] #10240: Build flavour 'quick-cross' tries to build integer-gmp Message-ID: <044.9e4a73dd0758228c164871a6558e5140@haskell.org> #10240: Build flavour 'quick-cross' tries to build integer-gmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build | Version: 7.11 System | Operating System: Unknown/Multiple Keywords: cross- | Type of failure: None/Unknown compiling | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The `BuildFlavour=quick-cross` setting is supposed to build `integer- simple` but some time after commit 5971ad56af it started trying to build `integer-gmp` regardless of the setting of `INTEGER_LIBRARY`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 10:26:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 10:26:09 -0000 Subject: [GHC] #10237: hsc2hs : compiler/ghci/LibFFI.hsc:42 sizeof(ffi_cif) is not an integer (was: compiler/ghci/LibFFI.hsc:42 sizeof(ffi_cif) is not an integer) In-Reply-To: <044.d74cccd78b90a9b3ae1f196d2af9942f@haskell.org> References: <044.d74cccd78b90a9b3ae1f196d2af9942f@haskell.org> Message-ID: <059.f16452a80e66f173d622093dd5a05da1@haskell.org> #10237: hsc2hs : compiler/ghci/LibFFI.hsc:42 sizeof(ffi_cif) is not an integer -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 11:23:19 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 11:23:19 -0000 Subject: [GHC] #10240: Build flavour 'quick-cross' tries to build integer-gmp In-Reply-To: <044.9e4a73dd0758228c164871a6558e5140@haskell.org> References: <044.9e4a73dd0758228c164871a6558e5140@haskell.org> Message-ID: <059.d1ce700a4e1b7a0b755f26d88d3d2e78@haskell.org> #10240: Build flavour 'quick-cross' tries to build integer-gmp -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: invalid | Keywords: cross- Operating System: Unknown/Multiple | compiling Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * status: new => closed * resolution: => invalid Comment: False alarm. Running `make distclean` as suggested by @hvr fixed it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 11:37:16 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 11:37:16 -0000 Subject: [GHC] #10239: Fragile CPP test for big endian in T7600 In-Reply-To: <047.4141fef62b155ef45c7ff2e676f4002e@haskell.org> References: <047.4141fef62b155ef45c7ff2e676f4002e@haskell.org> Message-ID: <062.39d087309a0c0b4bbdf7876c0410f996@haskell.org> #10239: Fragile CPP test for big endian in T7600 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: T7600 Related Tickets: | Blocking: | Differential Revisions: Phab:D795 -------------------------------------+------------------------------------- Changes (by trommler): * status: new => patch * differential: => Phab:D795 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 11:43:55 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 11:43:55 -0000 Subject: [GHC] #10239: Fragile CPP test for big endian in T7600 In-Reply-To: <047.4141fef62b155ef45c7ff2e676f4002e@haskell.org> References: <047.4141fef62b155ef45c7ff2e676f4002e@haskell.org> Message-ID: <062.3e4344c8d233d30f6fc2c7f3bc42b2f0@haskell.org> #10239: Fragile CPP test for big endian in T7600 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: T7600 Related Tickets: | Blocking: | Differential Revisions: Phab:D795 -------------------------------------+------------------------------------- Comment (by trommler): Replying to [ticket:10239 trommler]: > In test T7600 the C pre-processor test for big endian is broken in older versions of glibc. I tested HEAD on one machine and ghc-7.10 on the other and the machine with HEAD also had a newer glibc. Karel had posted a fix in [changeset:3f30912fcceceea68b8ea6ada6c3135447c6871a] already that was not merged. My patch removes the need for CPP altogether. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 13:07:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 13:07:04 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.20822cfa261ef32e4d4354575b2d33bd@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:77 diatchki]: > Hm, I think I can see what might be the issue, in fact there might be 2: > * {{{() :: *}}} and {{{() :: Constraint}}} will end up having the same representation > * Have to look at how we compute type reps for odd rank-2 types like {{{ ((),()) => () }}} > > I'll have a go at a fix. Although the automatic currying makes it disappear in this particular example, tuples like `((),())` also get the same representation as `*` and `Constraint`. I guess you currently need the `()` case to build any others, but I'm not sure if that should be counted on. (I also guess this all means Richard was right.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 13:13:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 13:13:07 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.d24888e2ca67434d327053a6500c3137@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by int-e): I've implemented the simple semantics where `-fprint-unicode-syntax` determines whether printing types and kind uses unicode syntax or not. The three-state behaviour from comment 17 would require more work. In any case I'm now using this implementation with lambdabot. (The patch is against ghc's HEAD; a patch for ghc-7.10.1 can be found in lambdabot's repository: https://github.com/lambdabot/lambdabot/blob/freenode/patches/ghc-7.10.1.patch) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 16:17:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 16:17:22 -0000 Subject: [GHC] #10218: GHC creates incorrect code which throws <> In-Reply-To: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> References: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> Message-ID: <061.f8e8981160842be369fd2577ac749a70@haskell.org> #10218: GHC creates incorrect code which throws <> -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: yes Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by AlexET): Looking at the difference in usage demands it seems that there is a variable (specifically a dictionary for A) with demand ``. But it is used twice, specifically its first component (a Foldable dictionary) is also used. This demand was correct in the dump-stranal file but then later the first component is used (due to cse) in a later section. This means the usage demand is incorrect. In the working version it is used in both locations already during demand analysis and hence is given the correct usage information. I don't know if this is the cause or whether the demand analysis information is irrelevant after cse. But if the demand analysis is used after cse then cse should make sure sure it is correct. I have tried making a smaller example but I am finding it hard to get cse to fire (most examples are inlined first before cse can fire but cse wont fire if they are marked noinline). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 3 17:23:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 03 Apr 2015 17:23:07 -0000 Subject: [GHC] #10229: setThreadAffinity assumes a certain CPU virtual core layout In-Reply-To: <042.260955fa92da12cf89056e026fcec607@haskell.org> References: <042.260955fa92da12cf89056e026fcec607@haskell.org> Message-ID: <057.c7b399e6602f15b26fd0d32abeeb84e6@haskell.org> #10229: setThreadAffinity assumes a certain CPU virtual core layout -------------------------------------+------------------------------------- Reporter: nh2 | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #1741 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by fryguybob): Phab:D800 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 4 00:17:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Apr 2015 00:17:50 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.78bb91d0783e5fe5bdc0a9ef8db8f38d@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:45 goldfire]: > I believe a sufficiently smart solver should be able to do this without difficulty. After all the discussion way above, I'll just point out now that the current implementation isn't one of those. I guess it was too much to hope for in such a hurried situation. For example, it breaks on the following expression (with `PolyKinds`, thanks to Shachaf): {{{ typeOf :: Typeable a => Proxy a -> TypeRep }}} It seems here that it cannot deduce `Typeable (Proxy a)` from `Typeable a` when the kind isn't known at compile time. More seriously, I think the current `TypeRep` for `Typeable (a :: k)` doesn't contain enough information to extract the `KindRep` for `k`, much less to decompose it, even if the solver were to try. It seems to have been designed such that type application of known `Typeable` types (with known kinds) will work almost effortlessly, but anything fancier is impossible. Ironically I thought (with my convoluted attempts to represent everything in 7.8 types) that type application would be the main thing forcing kind decomposition to be implemented for handling currently existing code, but this representation simply bypasses that. And I guess if no one else has complained then that is currently enough for people's needs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 4 11:23:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Apr 2015 11:23:09 -0000 Subject: [GHC] #10241: BlockedIndefinitelyOnMVar thrown to the thread which is not blocked indefinitely Message-ID: <049.aa2da898b4545668797a015c17e2bd6d@haskell.org> #10241: BlockedIndefinitelyOnMVar thrown to the thread which is not blocked indefinitely -------------------------------------+------------------------------------- Reporter: asukamirai | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.8.3 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: x86_64 | at runtime (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- BlockedIndefinatelyOnMVar exception is thrown to the main thread in below source code although the thread is not blocked indefinitely. {{{#!hs module Main where import qualified Control.Concurrent.MVar as MV import qualified Control.Concurrent as CC import qualified Control.Exception as E main :: IO () main = do -- call this thread "threadA" mvar1 <- MV.newEmptyMVar :: IO (MV.MVar ()) mvar2 <- MV.newEmptyMVar :: IO (MV.MVar ()) _ <- CC.forkIO $ do -- call this thread "threadB" MV.takeMVar mvar1 `E.catch` errorHandler1 putStrLn "after error catch" CC.threadDelay 1000000 MV.putMVar mvar2 () putStrLn "after putMVar" MV.readMVar mvar2 `E.catch` errorHandler2 putStrLn "after readMVar" CC.threadDelay 5000000 where errorHandler1 :: E.BlockedIndefinitelyOnMVar -> IO () errorHandler1 e = putStrLn $ "errorHandler1 : " ++ show e errorHandler2 :: E.BlockedIndefinitelyOnMVar -> IO () errorHandler2 e = putStrLn $ "errorHandler2 : " ++ show e }}} Save above as "mvar.hs" and run by ghc as below. {{{ > runhaskell mvar.hs errorHandler1 : thread blocked indefinitely in an MVar operation errorHandler2 : thread blocked indefinitely in an MVar operation after error catch after readMVar after putMVar }}} BlockedIndefinitelyOnMVar thrown for mvar1 is correct. It will be caught by errorHandler1 and "threadB" can continue to put the value to mvar2. It means that "threadA" can wait for the value of mvar2 and it is not blocked indefinately. However, BlockedIndefinitelyOnMVar is thrown for mvar2 on "threadA" before "threadB" puts value to the mvar2. I think it is incorrect. ---- I tested another case that adding "CC.threadDelay 10000000" before "readMVar" as below. {{{#!hs module Main where import qualified Control.Concurrent.MVar as MV import qualified Control.Concurrent as CC import qualified Control.Exception as E main :: IO () main = do -- call this thread "threadA" mvar1 <- MV.newEmptyMVar :: IO (MV.MVar ()) mvar2 <- MV.newEmptyMVar :: IO (MV.MVar ()) _ <- CC.forkIO $ do -- call this thread "threadB" MV.takeMVar mvar1 `E.catch` errorHandler1 putStrLn "after error catch" CC.threadDelay 1000000 MV.putMVar mvar2 () putStrLn "after putMVar" CC.threadDelay 10000000 -- <-- this line is added MV.readMVar mvar2 `E.catch` errorHandler2 putStrLn "after readMVar" CC.threadDelay 5000000 where errorHandler1 :: E.BlockedIndefinitelyOnMVar -> IO () errorHandler1 e = putStrLn $ "errorHandler1 : " ++ show e errorHandler2 :: E.BlockedIndefinitelyOnMVar -> IO () errorHandler2 e = putStrLn $ "errorHandler2 : " ++ show e }}} And it will run correctly (BlockedIndefinitelyOnMVar is not thrown for mvar2). {{{ > runhaskell mvar.hs errorHandler1 : thread blocked indefinitely in an MVar operation after error catch after putMVar after readMVar }}} ---- I found this behavior is same on STM / BlockedIndefinitelyOnSTM. {{{#!hs module Main where import qualified Control.Concurrent.STM as STM import qualified Control.Concurrent as CC import qualified Control.Exception as E main :: IO () main = do tmv1 <- STM.newEmptyTMVarIO :: IO (STM.TMVar ()) tmv2 <- STM.newEmptyTMVarIO :: IO (STM.TMVar ()) _ <- CC.forkIO $ do STM.atomically (STM.takeTMVar tmv1) `E.catch` errorHandler1 putStrLn "after error catch" CC.threadDelay 1000000 STM.atomically $ STM.putTMVar tmv2 () putStrLn "after putTMVar" STM.atomically (STM.readTMVar tmv2) `E.catch` errorHandler2 putStrLn "after readTMVar" CC.threadDelay 5000000 where errorHandler1 :: E.BlockedIndefinitelyOnSTM -> IO () errorHandler1 e = putStrLn $ "errorHandler1 : " ++ show e errorHandler2 :: E.BlockedIndefinitelyOnSTM -> IO () errorHandler2 e = putStrLn $ "errorHandler2 : " ++ show e }}} {{{ > runhaskell stm.hs errorHandler1 : thread blocked indefinitely in an STM transaction errorHandler2 : thread blocked indefinitely in an STM transaction after error catch after readTMVar after putTMVar }}} ---- I tested this in below versions/OSs and got same result (exception thrown for mvar2/tmv2). ghc7.8.3 on Windows7 ghc7.8.3 on lubuntu14.04 on VirtualBox on Windows7 ghc7.8.4 on lubuntu14.04 on VirtualBox on Windows7 ghc7.10.1 on lubuntu14.04 on VirtualBox on Windows7 Similar report https://ghc.haskell.org/trac/ghc/ticket/8804 found but not the same. (In this case, the reference to the MVar is not weak) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 4 14:54:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Apr 2015 14:54:02 -0000 Subject: [GHC] #10214: parser: TransStmt has incorrect SrcSpan In-Reply-To: <049.354eb02c7a1c2cda9ae89642a039bee8@haskell.org> References: <049.354eb02c7a1c2cda9ae89642a039bee8@haskell.org> Message-ID: <064.b6c43d470261f95e3a2cbd794692d5f3@haskell.org> #10214: parser: TransStmt has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: mpickering | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by alanz): * owner: => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 4 18:51:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 04 Apr 2015 18:51:20 -0000 Subject: [GHC] #10207: parser: ParStmt has incorrect SrcSpan In-Reply-To: <044.58d70da3f3be10a135bd8c2190ecc4c5@haskell.org> References: <044.58d70da3f3be10a135bd8c2190ecc4c5@haskell.org> Message-ID: <059.dff4f8a35c46caca451ebb613b08b3e6@haskell.org> #10207: parser: ParStmt has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: D803 -------------------------------------+------------------------------------- Changes (by alanz): * differential: => D803 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 5 05:58:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Apr 2015 05:58:14 -0000 Subject: [GHC] #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable In-Reply-To: <046.667caeee812579621ec3ac8601656752@haskell.org> References: <046.667caeee812579621ec3ac8601656752@haskell.org> Message-ID: <061.6b3858a44e5dc13acbf9ac8cd61eae84@haskell.org> #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable -------------------------------------+------------------------------------- Reporter: afcowie | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9324 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by whisky): I'm taking a look at this bug. Would it suffice to include a comment to chmod 644 the .ghci file? I've tested it out and it works fine on my local machine after running the command. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 5 06:42:47 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Apr 2015 06:42:47 -0000 Subject: [GHC] #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable In-Reply-To: <046.667caeee812579621ec3ac8601656752@haskell.org> References: <046.667caeee812579621ec3ac8601656752@haskell.org> Message-ID: <061.04a7efb989576c32e7121eec95c84683@haskell.org> #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable -------------------------------------+------------------------------------- Reporter: afcowie | Owner: whisky Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9324 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by whisky): * owner: => whisky -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 5 09:46:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Apr 2015 09:46:14 -0000 Subject: [GHC] #10242: Multiple constraint wildcards allowed with PartialTypeSignatures Message-ID: <049.a953ada63cab8a32d81242f76b55213a@haskell.org> #10242: Multiple constraint wildcards allowed with PartialTypeSignatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple PartialTypeSignatures | Type of failure: GHC accepts Architecture: | invalid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The [https://ghc.haskell.org/trac/ghc/wiki/PartialTypeSignatures wiki] states that > As a single extra-constraints wildcard is enough to infer any number of constraints, only one is allowed in a type signature and it should come last in the list of constraints. However the following program compiles with GHC 7.10.1 {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} f :: (Eq a, _, _) => a -> a -> Bool f x y = x == y }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 5 10:42:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Apr 2015 10:42:22 -0000 Subject: [GHC] #10243: SrcSpan incorrect for non-alphanumeric VarPat Message-ID: <049.4361a588787ca3b7591aac0d5c120eb9@haskell.org> #10243: SrcSpan incorrect for non-alphanumeric VarPat -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- There is an inconsistency when parsing patterns which contain non- alphanumeric characters. For example, {{{!#hs foo (.) = 5 }}} the pattern parses as the following. {{{ (L {tests/examples/ArgPuncParens.hs:2:5-7} (VarPat (Unqual {OccName: .})))] }}} Then consider the following similar program. {{{#!hs foo (x) = 5 }}} The parse is as follows. {{{ (L {tests/examples/ArgPuncParens.hs:2:5-7} (ParPat (L {tests/examples/ArgPuncParens.hs:2:6} (VarPat (Unqual {OccName: x})))))] }}} Notice two differences. 1. The first parse lacks a surrounding `ParPat`. 2. If the `ParPat` is deliberately omitted then the given location encompasses the surrounding parentheses which is not consistent with the second example where `VarPat` specifically refers to `x`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 5 10:42:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Apr 2015 10:42:45 -0000 Subject: [GHC] #10243: SrcSpan incorrect for non-alphanumeric VarPat In-Reply-To: <049.4361a588787ca3b7591aac0d5c120eb9@haskell.org> References: <049.4361a588787ca3b7591aac0d5c120eb9@haskell.org> Message-ID: <064.3507ddae1be0fd45493d444c93d8b93a@haskell.org> #10243: SrcSpan incorrect for non-alphanumeric VarPat -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by mpickering: Old description: > There is an inconsistency when parsing patterns which contain non- > alphanumeric characters. > > For example, > > {{{!#hs > foo (.) = 5 > }}} > > the pattern parses as the following. > > {{{ > (L {tests/examples/ArgPuncParens.hs:2:5-7} > (VarPat > (Unqual {OccName: .})))] > }}} > > Then consider the following similar program. > > {{{#!hs > foo (x) = 5 > }}} > > The parse is as follows. > > {{{ > (L {tests/examples/ArgPuncParens.hs:2:5-7} > (ParPat > (L {tests/examples/ArgPuncParens.hs:2:6} > (VarPat > (Unqual {OccName: x})))))] > }}} > > Notice two differences. > > 1. The first parse lacks a surrounding `ParPat`. > 2. If the `ParPat` is deliberately omitted then the given location > encompasses the surrounding parentheses which is not consistent with the > second example where `VarPat` specifically refers to `x`. New description: There is an inconsistency when parsing patterns which contain non- alphanumeric characters. For example, {{{#!hs foo (.) = 5 }}} the pattern parses as the following. {{{ (L {tests/examples/ArgPuncParens.hs:2:5-7} (VarPat (Unqual {OccName: .})))] }}} Then consider the following similar program. {{{#!hs foo (x) = 5 }}} The parse is as follows. {{{ (L {tests/examples/ArgPuncParens.hs:2:5-7} (ParPat (L {tests/examples/ArgPuncParens.hs:2:6} (VarPat (Unqual {OccName: x})))))] }}} Notice two differences. 1. The first parse lacks a surrounding `ParPat`. 2. If the `ParPat` is deliberately omitted then the given location encompasses the surrounding parentheses which is not consistent with the second example where `VarPat` specifically refers to `x`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 5 14:50:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Apr 2015 14:50:49 -0000 Subject: [GHC] #10243: SrcSpan incorrect for non-alphanumeric VarPat In-Reply-To: <049.4361a588787ca3b7591aac0d5c120eb9@haskell.org> References: <049.4361a588787ca3b7591aac0d5c120eb9@haskell.org> Message-ID: <064.4512b43cb806b6e0d6c38dc35b570e51@haskell.org> #10243: SrcSpan incorrect for non-alphanumeric VarPat -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => invalid Comment: These really do parse differently though: `(x)` is a pattern `x` enclosed in parentheses, while `(.)` is a single identifier (infix operator in prefix form). If you consult https://www.haskell.org/onlinereport/haskell2010/haskellch10.html I think you will find that these outputs match the parses specified by the Report. Please reopen if you disagree. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 5 16:31:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Apr 2015 16:31:03 -0000 Subject: [GHC] #10244: "memory barriers unimplemented on this architecture" on ARM pre-ARMv7 Message-ID: <047.d95ba9704c88f743540840872a0fc12b@haskell.org> #10244: "memory barriers unimplemented on this architecture" on ARM pre-ARMv7 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Building GHC Architecture: arm | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Phab:D33 broke the build on ARM pre-ARMv7, because there is no definition of `store_load_barrier` or `load_load_barrier` for those platforms. (Granted, the old fall-back behavior of doing nothing was almost certainly incorrect.) I don't know whether we need CPU-level barriers here, or whether they are available. At a minimum, we need a compiler-level barrier. If we need a CPU-level barrier and it isn't provided by the instruction set, then I guess we should disable SMP for these platforms in `mk/config.mk.in`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 5 18:52:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Apr 2015 18:52:01 -0000 Subject: [GHC] #10245: panic in new integer switch logic with "out-of-range" literals Message-ID: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> #10245: panic in new integer switch logic with "out-of-range" literals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time Architecture: x86_64 | crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Compiling this module {{{ module D (f) where f :: Int -> String f n = case n of 0x8000000000000000 -> "yes" _ -> "no" }}} crashes with the error {{{ [1 of 1] Compiling D ( /tmp/D.hs, /tmp/D.o ) ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.11.20150403 for x86_64-unknown-linux): Map.findMin: empty map has no minimal element }}} The constant does not have to be exactly `0x8000000000000000`, everything I tested from there up to `0xffffffffffffffff` yields the same crash. Also occurs with `Word` and negative literals. The bug seems to be tied to the target's word size somehow, though: a 64-bit compiler does not panic on `Int32` and `0x80000000`, but a 32-bit compiler does. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 5 19:04:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Apr 2015 19:04:34 -0000 Subject: [GHC] #10245: panic in new integer switch logic with "out-of-range" literals In-Reply-To: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> References: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> Message-ID: <062.83806a0a5e83970a368c61be1ac9512c@haskell.org> #10245: panic in new integer switch logic with "out-of-range" literals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Resolution: | Architecture: x86_64 Operating System: Unknown/Multiple | (amd64) Type of failure: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by nomeata): * owner: => nomeata Comment: Thanks, I?ll look into it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 5 20:01:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Apr 2015 20:01:14 -0000 Subject: [GHC] #10237: hsc2hs : compiler/ghci/LibFFI.hsc:42 sizeof(ffi_cif) is not an integer In-Reply-To: <044.d74cccd78b90a9b3ae1f196d2af9942f@haskell.org> References: <044.d74cccd78b90a9b3ae1f196d2af9942f@haskell.org> Message-ID: <059.0dd0e12d850abc84fed6b9675e8ac31a@haskell.org> #10237: hsc2hs : compiler/ghci/LibFFI.hsc:42 sizeof(ffi_cif) is not an integer -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: patch => closed * resolution: => fixed Comment: I pushed this for now but it would be good to have something that is more robust to changes in warnings. See #9457. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 5 20:05:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Apr 2015 20:05:29 -0000 Subject: [GHC] #9457: hsc2hs breaks with `--cflag=-Werror` in cross-compilation mode In-Reply-To: <047.1a08fdc9c8e87e7e04f09b9f3fcedabf@haskell.org> References: <047.1a08fdc9c8e87e7e04f09b9f3fcedabf@haskell.org> Message-ID: <062.307e97500aa1488d35e3cf0a2d77b45a@haskell.org> #9457: hsc2hs breaks with `--cflag=-Werror` in cross-compilation mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #10237 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * related: => #10237 Comment: #10237 fixes the immediate issue but I'm going to leave this open for a more robust solution. It's pretty bad that hsc2hs silently gives the wrong answer when there are spurious warnings and that we have no automated tests that would catch something going wrong in the cross-compilation code path. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 5 20:28:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Apr 2015 20:28:03 -0000 Subject: [GHC] #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable In-Reply-To: <046.667caeee812579621ec3ac8601656752@haskell.org> References: <046.667caeee812579621ec3ac8601656752@haskell.org> Message-ID: <061.49a0bb1d5189431fd689991b8319685e@haskell.org> #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable -------------------------------------+------------------------------------- Reporter: afcowie | Owner: whisky Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9324 | Differential Revisions: Phab:D805 -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * differential: => Phab:D805 * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 5 20:33:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Apr 2015 20:33:34 -0000 Subject: [GHC] #10245: panic in new integer switch logic with "out-of-range" literals In-Reply-To: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> References: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> Message-ID: <062.06c66c17fae48c010472e6390aab7ad1@haskell.org> #10245: panic in new integer switch logic with "out-of-range" literals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Resolution: | Architecture: x86_64 Operating System: Unknown/Multiple | (amd64) Type of failure: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): Interesting, as a test case it fails with {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20150403 for x86_64-unknown-linux): ASSERT failed! file compiler/basicTypes/Literal.hs line 220 9223372036854775808 }}} due to {{{ mkMachInt :: DynFlags -> Integer -> Literal mkMachInt dflags x = ASSERT2( inIntRange dflags x, integer x ) MachInt x }}} This makes we wonder: Is that even legal Haskell, or should we fail much earlier? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 5 20:53:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Apr 2015 20:53:03 -0000 Subject: [GHC] #10245: panic in new integer switch logic with "out-of-range" literals In-Reply-To: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> References: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> Message-ID: <062.389144271dee95b419af1c1d29ed95fb@haskell.org> #10245: panic in new integer switch logic with "out-of-range" literals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Resolution: fixed | Architecture: x86_64 Operating System: Unknown/Multiple | (amd64) Type of failure: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: Fixed. One could think about whether that is legal haskell or whether the ASSERT is wrong, but that?s a different story, and not one for Easter night. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 5 20:53:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Apr 2015 20:53:04 -0000 Subject: [GHC] #10245: panic in new integer switch logic with "out-of-range" literals In-Reply-To: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> References: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> Message-ID: <062.90d2aa838fd8be845e2c887edace42ee@haskell.org> #10245: panic in new integer switch logic with "out-of-range" literals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Resolution: fixed | Architecture: x86_64 Operating System: Unknown/Multiple | (amd64) Type of failure: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"a838d1f7c668f6c5886ce350cb456f3ecbcb1499/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a838d1f7c668f6c5886ce350cb456f3ecbcb1499" CmmSwitch: Do not trip over a case with no (valid) branches This fixes #10245. I did not commit the test case, as it fails unconditionally with a compiler built with -DDEBUG, so maybe it is bogus Haskell anyways. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 5 21:02:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Apr 2015 21:02:06 -0000 Subject: [GHC] #10245: panic in new integer switch logic with "out-of-range" literals In-Reply-To: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> References: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> Message-ID: <062.3a935f08ded27d125aae3df24884dcad@haskell.org> #10245: panic in new integer switch logic with "out-of-range" literals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Resolution: fixed | Architecture: x86_64 Operating System: Unknown/Multiple | (amd64) Type of failure: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by rwbarton): FWIW I encountered this in the wild (https://github.com/ghc/packages- time/blob/master/lib/Data/Time/LocalTime/TimeZone.hs#L88) while trying to cross-compile GHC to x86. I'm pretty sure it is valid Haskell; what if the type signature was `f :: Num a => a -> String`? Should specializing `a` to `Int` turn a valid program into an invalid one? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 5 22:27:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Apr 2015 22:27:40 -0000 Subject: [GHC] #9457: hsc2hs breaks with `--cflag=-Werror` in cross-compilation mode In-Reply-To: <047.1a08fdc9c8e87e7e04f09b9f3fcedabf@haskell.org> References: <047.1a08fdc9c8e87e7e04f09b9f3fcedabf@haskell.org> Message-ID: <062.c2135b3bb06acbd03ae24d1e88d3879b@haskell.org> #9457: hsc2hs breaks with `--cflag=-Werror` in cross-compilation mode -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: hsc2hs | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #10237 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): I think what `hsc2hs` needs is a test suite that is always compiled with `-Werror` switched on. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 5 23:05:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 05 Apr 2015 23:05:18 -0000 Subject: [GHC] #10245: panic in new integer switch logic with "out-of-range" literals In-Reply-To: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> References: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> Message-ID: <062.eb58dae37e6836f4b796ee1998b02a62@haskell.org> #10245: panic in new integer switch logic with "out-of-range" literals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Resolution: fixed | Architecture: x86_64 Operating System: Unknown/Multiple | (amd64) Type of failure: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by rwbarton): Curiously for a 32-bit compiler I can reproduce the issue with `Int` but not with `Int32`. Maybe the ASSERT is really checking an intended invariant, and something went wrong earlier (desugaring?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 00:36:54 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 00:36:54 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.4a255e02fa062dd4172efcb9e2718d24@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D807 -------------------------------------+------------------------------------- Changes (by int-e): * differential: => Phab:D807 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 01:13:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 01:13:28 -0000 Subject: [GHC] #7961: Remove restrictions on promoting GADT's In-Reply-To: <047.d0069eb42fb0ed6b29e5044acfcdabb7@haskell.org> References: <047.d0069eb42fb0ed6b29e5044acfcdabb7@haskell.org> Message-ID: <062.4bec87b3ff66fc4fcaf819d00df647a7@haskell.org> #7961: Remove restrictions on promoting GADT's -------------------------------------+------------------------------------- Reporter: danharaj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #6024 | Blocking: | Differential Revisions: Phab:D808 -------------------------------------+------------------------------------- Changes (by goldfire): * differential: => Phab:D808 Comment: I have posted an early version of my patch to implement kind equalities, fixing this ticket. Comments/experimentation welcome. It is easiest to access the branch from https://github.com/goldfirere/ghc, on the `nokinds` branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 06:56:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 06:56:42 -0000 Subject: [GHC] #10245: panic in new integer switch logic with "out-of-range" literals In-Reply-To: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> References: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> Message-ID: <062.0d2b32121be74cf0c8aa6ea66c8217dd@haskell.org> #10245: panic in new integer switch logic with "out-of-range" literals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Resolution: fixed | Architecture: x86_64 Operating System: Unknown/Multiple | (amd64) Type of failure: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): > I'm pretty sure it is valid Haskell; for some reason I was assuming you were writing unboxed literals. With regular literals, you are right of course! But I think we are implementing it wrongly. According to the report, your code should be treated like {{{ f n = if n == fromIntegral 0x8000000000000000 then "yes" else "no" }}} but my impression is that we produce a literal 0x8000000000000000 :: Int# internally, which is then dropped from the case. I?ll check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 07:03:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 07:03:26 -0000 Subject: [GHC] #10245: panic in new integer switch logic with "out-of-range" literals In-Reply-To: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> References: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> Message-ID: <062.d82ddf74eca2bedcbe78d136db321f67@haskell.org> #10245: panic in new integer switch logic with "out-of-range" literals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Resolution: | Architecture: x86_64 Operating System: Unknown/Multiple | (amd64) Type of failure: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by nomeata): * owner: nomeata => * status: closed => new * resolution: fixed => Comment: Ok, I think I broke something else since 7.8. If I add {{{ main = do let string = "0x8000000000000000" let i = read string :: Integer let i' = fromIntegral i :: Int print i print i' print (f i') }}} to your example, 7.8.4 produces {{{ 9223372036854775808 -9223372036854775808 "yes" }}} while HEAD produces {{{ 9223372036854775808 -9223372036854775808 "no" }}} I?ll investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 07:33:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 07:33:58 -0000 Subject: [GHC] #10246: Literal Pattern match loses order Message-ID: <046.c354b1968b798b1bb50a4f6cbd4fc699@haskell.org> #10246: Literal Pattern match loses order -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I found this long-standing bug while investigating #10245: Consider this code: {{{ f1 :: Int -> String f1 n = case n of 0 -> "bar" 0x10000000000000000 -> "foo" _ -> "c" {-# NOINLINE f1 #-} g1 :: Int -> String g1 n = if n == 0 then "bar" else if n == 0x10000000000000000 then "foo" else "c" {-# NOINLINE g1 #-} f2 :: Int -> String f2 n = case n of 0x10000000000000000 -> "foo" 0 -> "bar" _ -> "c" {-# NOINLINE f2 #-} g2 :: Int -> String g2 n = if n == 0x10000000000000000 then "foo" else if n == 0 then "bar" else "c" {-# NOINLINE g2 #-} main = do let i = read "0" :: Int print (f1 i) print (g1 i) print (f2 i) print (g2 i) }}} According to the report, `f1` should behave like `g1` and `f2` should behave like `g2`. But that is not the case: I get {{{ "foo" "bar" "foo" "foo" }}} The reason is that the branches are sorted, to create fancy code for it, but this does not take into account that `0x10000000000000000 = 0`, at least for `Int`. This bug is present also in 7.8.4, and not (directly) related to my CmmSwitch code: It can also be observed with interpreted code, so the fix must happen earlier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 07:38:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 07:38:15 -0000 Subject: [GHC] #10245: panic in new integer switch logic with "out-of-range" literals In-Reply-To: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> References: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> Message-ID: <062.b81875f1792b13a05368600d41820657@haskell.org> #10245: panic in new integer switch logic with "out-of-range" literals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Resolution: | Architecture: x86_64 Operating System: Unknown/Multiple | (amd64) Type of failure: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"8f0709249826dd2eda9bf53be89f176a4f30c81f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8f0709249826dd2eda9bf53be89f176a4f30c81f" Test case for #10246 still marked known_broken. This also adds the test case for #10245, which should pass once #10246 is fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 07:38:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 07:38:15 -0000 Subject: [GHC] #10246: Literal Pattern match loses order In-Reply-To: <046.c354b1968b798b1bb50a4f6cbd4fc699@haskell.org> References: <046.c354b1968b798b1bb50a4f6cbd4fc699@haskell.org> Message-ID: <061.3d720ab8dc1555dd8217994d701b68ce@haskell.org> #10246: Literal Pattern match loses order -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"8f0709249826dd2eda9bf53be89f176a4f30c81f/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8f0709249826dd2eda9bf53be89f176a4f30c81f" Test case for #10246 still marked known_broken. This also adds the test case for #10245, which should pass once #10246 is fixed. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 07:41:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 07:41:25 -0000 Subject: [GHC] #10245: panic in new integer switch logic with "out-of-range" literals In-Reply-To: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> References: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> Message-ID: <062.701082790036568cfd427903935f0436@haskell.org> #10245: panic in new integer switch logic with "out-of-range" literals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Resolution: | Architecture: x86_64 Operating System: Unknown/Multiple | (amd64) Type of failure: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by nomeata): There is something larger at miss. I created #10246 for that, and left this for the (now fixed) partiality of the new switch logic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 07:42:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 07:42:36 -0000 Subject: [GHC] #10242: Multiple constraint wildcards allowed with PartialTypeSignatures In-Reply-To: <049.a953ada63cab8a32d81242f76b55213a@haskell.org> References: <049.a953ada63cab8a32d81242f76b55213a@haskell.org> Message-ID: <064.f2c9cfd1e991ca0a70466c7cde194d0a@haskell.org> #10242: Multiple constraint wildcards allowed with PartialTypeSignatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | PartialTypeSignatures Type of failure: GHC accepts | Architecture: invalid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * cc: dominique.devriese@?, Thomas, Winant, (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 07:43:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 07:43:17 -0000 Subject: [GHC] #10246: Literal Pattern match loses order In-Reply-To: <046.c354b1968b798b1bb50a4f6cbd4fc699@haskell.org> References: <046.c354b1968b798b1bb50a4f6cbd4fc699@haskell.org> Message-ID: <061.5fd250fad763148932f1b00aa08b772a@haskell.org> #10246: Literal Pattern match loses order -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * cc: rwbarton, simonmar (added) Comment: Currently, the above code will produce {{{ ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20150403 for x86_64-unknown-linux): ASSERT failed! file compiler/basicTypes/Literal.hs line 220 18446744073709551616 }}} Maybe that is a hint as to where this needs to be fixed? Maybe {{{ mkMachInt :: DynFlags -> Integer -> Literal mkMachInt dflags x = ASSERT2( inIntRange dflags x, integer x ) MachInt x }}} is where the clamping to the range of the machine integers should happen? Can we always deduce that from the `dflags`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 07:52:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 07:52:21 -0000 Subject: [GHC] #10199: Sending SIGINT to a program that uses forkOS may crash with various errors In-Reply-To: <044.16ed099f787ddebd86daad09ea2544a1@haskell.org> References: <044.16ed099f787ddebd86daad09ea2544a1@haskell.org> Message-ID: <059.6b1e061fbc45dfdff2fbc576172098e7@haskell.org> #10199: Sending SIGINT to a program that uses forkOS may crash with various errors -------------------------------------+------------------------------------- Reporter: adeon | Owner: simonmar Type: bug | Status: new Priority: low | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonmar): Yes, what happens here is that the RTS shuts down while one of the forkOS calls is just about to call back into Haskell to create the bound thread. The effect is similar to calling a foreign exported function before calling `hs_init()` - that's where the `newBoundTask` message comes from. Depending on the timing, we might have got past the `newBoundTask` check when the RTS shuts down. We should close that race condition. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 08:02:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 08:02:20 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDIxNjogQWxsb3cgYXJyIOKIpyAoZmlyc3Qg?= =?utf-8?q?=E2=88=A8_=28***=29=29_as_minimal_definition_of_Arrow_?= =?utf-8?q?instance?= In-Reply-To: <048.64b271a00a46843da0df000240882f80@haskell.org> References: <048.64b271a00a46843da0df000240882f80@haskell.org> Message-ID: <063.c038399eb13a6b6c07d61519d0087b90@haskell.org> #10216: Allow arr ? (first ? (***)) as minimal definition of Arrow instance -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I suggest that * You add a description to the ticket that explains what you are doing, and why it is a good thing. Perhaps add comments in the code to explain subtleties? * Pursue it through the core libraries committee (Edward clearly has it on his radar, which is good). Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 08:10:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 08:10:59 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDIxNjogQWxsb3cgYXJyIOKIpyAoZmlyc3Qg?= =?utf-8?q?=E2=88=A8_=28***=29=29_as_minimal_definition_of_Arrow_?= =?utf-8?q?instance?= In-Reply-To: <048.64b271a00a46843da0df000240882f80@haskell.org> References: <048.64b271a00a46843da0df000240882f80@haskell.org> Message-ID: <063.2a4ffad86ebda851260c1fd00499ffd1@haskell.org> #10216: Allow arr ? (first ? (***)) as minimal definition of Arrow instance -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 08:32:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 08:32:01 -0000 Subject: [GHC] #10204: Odd interaction between rank-2 types and type families In-Reply-To: <047.40c7f4223ed199be95aee7f3ef8794b7@haskell.org> References: <047.40c7f4223ed199be95aee7f3ef8794b7@haskell.org> Message-ID: <062.57f6482a8161549b08057ba3b9c08cd8@haskell.org> #10204: Odd interaction between rank-2 types and type families -------------------------------------+------------------------------------- Reporter: diatchki | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonpj): * type: bug => feature request * milestone: => ? Comment: You could indeed consider this a failure of inference, but it's by-design (currently), and it's one I don't know how to fix. Consider this constraint that arise from `example`: {{{ forall s. (F s ~ Int) => (s -> beta) ~ (sigma ~ Char) }}} Here * `beta` is a unification variable that arises from instantiating `b` in the call to `f`. * `sigma` is a unification variable that arises from instantiating `s` in the call to `k`. We can safely unify `sigma := s`, because the call to `k` is inside the polymorphic argument to `f`. But it is less clear that we can unify `beta := Char` because both (a) it affects the inferred type of `(f k)`, and (b) the `(beta ~ Char)` is under an equality `F s ~ Int`.. Suppose that instead of `F s ~ Int` it had been `F s ~ Char`. Then should we unify `beta := Char` or `beta := F s`? GHC never guesses,so instead it refrains from unifying `beta`, saying that it is "untouchable", hoping that some other constraint will determine how to unify `beta`. You may say that `(F s ~ Int)` can't possibly affect `beta`, but it should be clear that it's ''really'' hard to be sure about that. GHC simply treats ''any'' equality in an implication constraint as making all the unification variables from an outer scope untouchable. This issue is discussed (somewhat) in 5.6.1 of the [https://wiki.haskell.org/Simonpj/Talk:OutsideIn OutsideIn paper] I'll mark this as a feature request! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 08:33:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 08:33:31 -0000 Subject: [GHC] #10246: Literal Pattern match loses order In-Reply-To: <046.c354b1968b798b1bb50a4f6cbd4fc699@haskell.org> References: <046.c354b1968b798b1bb50a4f6cbd4fc699@haskell.org> Message-ID: <061.30ab5d70537c3733aedeec1fb2dabd1a@haskell.org> #10246: Literal Pattern match loses order -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * owner: => nomeata Comment: Or maybe the problem is the part of the code that changes the patter {{{ 0x10000000000000000 -> "foo" }}} to {{{ I# 0x10000000000000000# -> "foo" }}} which would be `tidyNPat` in `MatchLit.hs`. Unfortunately, that is far way from the nearest `dflags`. Maybe `hsLitKey :: DynFlags -> HsLit -> Literal` is a good spot for making sure the literal is in range... that seems to work. I?ll shortly open a DR with some questions to those in the know in these matters. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 08:37:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 08:37:31 -0000 Subject: [GHC] #9539: TQueue can lead to thread starvation In-Reply-To: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> References: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> Message-ID: <060.8e9635ec92bcbce0b51ff2d1ca54340c@haskell.org> #9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): * I'm all for fixing bugs in the STM library -- thank you! * Simon M is the expert. * I think the Core Libraries Committee makes the decision. * In any patch, ''please'' comment the relevant point carefully, referring to this ticket, so that no one changes it back! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 08:39:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 08:39:47 -0000 Subject: [GHC] #10246: Literal Pattern match loses order In-Reply-To: <046.c354b1968b798b1bb50a4f6cbd4fc699@haskell.org> References: <046.c354b1968b798b1bb50a4f6cbd4fc699@haskell.org> Message-ID: <061.9e651dd9ce4726f31e36f9b347fd6915@haskell.org> #10246: Literal Pattern match loses order -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D810 -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D810 Comment: See Phab:D810 for a possible fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 08:45:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 08:45:16 -0000 Subject: [GHC] #8581: Add support for explicitly-bidirectional pattern synonyms In-Reply-To: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> References: <045.ffb8b433d262c0e3b5b415c2eeca2eee@haskell.org> Message-ID: <060.692dbcfb7d588a961b10b3bfef4ec816@haskell.org> #8581: Add support for explicitly-bidirectional pattern synonyms -------------------------------------+------------------------------------- Reporter: cactus | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | PatternSynonyms Type of failure: None/Unknown | Architecture: Blocked By: 5144 | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Interesting. Gergo, what's the status on this ticket? Done, or incomplete? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 08:54:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 08:54:02 -0000 Subject: [GHC] #9533: Signed/unsigned integer difference between compiled and interpreted code In-Reply-To: <051.798fa83a4f89bc51a274a942ec137896@haskell.org> References: <051.798fa83a4f89bc51a274a942ec137896@haskell.org> Message-ID: <066.39ec30832784951af045cc0781180078@haskell.org> #9533: Signed/unsigned integer difference between compiled and interpreted code -------------------------------------+------------------------------------- Reporter: MichaelBurge | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 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 Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Also see #10246, which is basically the same, it seems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 08:54:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 08:54:28 -0000 Subject: [GHC] #10246: Literal Pattern match loses order In-Reply-To: <046.c354b1968b798b1bb50a4f6cbd4fc699@haskell.org> References: <046.c354b1968b798b1bb50a4f6cbd4fc699@haskell.org> Message-ID: <061.05b36445a4c85f6974d9370f11b968bf@haskell.org> #10246: Literal Pattern match loses order -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9533 | Blocking: | Differential Revisions: Phab:D810 -------------------------------------+------------------------------------- Changes (by nomeata): * related: => #9533 Comment: Has come up before: #9533. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 09:01:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 09:01:09 -0000 Subject: [GHC] #10207: parser: ParStmt has incorrect SrcSpan In-Reply-To: <044.58d70da3f3be10a135bd8c2190ecc4c5@haskell.org> References: <044.58d70da3f3be10a135bd8c2190ecc4c5@haskell.org> Message-ID: <059.09a3acc03bfb697fe7ba611163edcf17@haskell.org> #10207: parser: ParStmt has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: D803 -------------------------------------+------------------------------------- Comment (by alanz): Review required on Phabricator, at https://phabricator.haskell.org/D803 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 09:26:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 09:26:38 -0000 Subject: [GHC] #10224: Partial type signatures generate typed hole warnings In-Reply-To: <045.c9ae412f65588bd6476cb40ffda876e8@haskell.org> References: <045.c9ae412f65588bd6476cb40ffda876e8@haskell.org> Message-ID: <060.cc0b5668973bad5a6f73cb764456e6cb@haskell.org> #10224: Partial type signatures generate typed hole warnings -------------------------------------+------------------------------------- Reporter: quchen | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 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 Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: I think mpickering is right. Seem ok? I'll close as invalid, but reopen if you think this is wrong. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 09:40:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 09:40:40 -0000 Subject: [GHC] #10225: GHC does not specialize based on type equality In-Reply-To: <046.56c40228dad7f1d8895238a61375d58f@haskell.org> References: <046.56c40228dad7f1d8895238a61375d58f@haskell.org> Message-ID: <061.3c546e0085e0b60860a645279d6b70e5@haskell.org> #10225: GHC does not specialize based on type equality -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Can you give a concrete example of what you mean? Does `f` need the fact that `(v ~ V2)`? If not, I'm surprised that the former is slower than the latter. Can you give a test case? The smaller the better Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 10:10:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 10:10:26 -0000 Subject: [GHC] #10228: Increased memory usage with GHC 7.10.1 In-Reply-To: <048.689dfbc555185e5a975e80819cf26fc7@haskell.org> References: <048.689dfbc555185e5a975e80819cf26fc7@haskell.org> Message-ID: <063.3aa84536df096d864e2e27f46a80db5f@haskell.org> #10228: Increased memory usage with GHC 7.10.1 -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): It would be extremely helpful if you, or someone else, could boil out a test case that demonstrates the problem. And, better still, use a profiled compiler to isolate where the problem is. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 10:11:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 10:11:38 -0000 Subject: [GHC] #8811: Profiling output jumbled together In-Reply-To: <047.8dc5a7d9bb9c749a985d563ff91e4df0@haskell.org> References: <047.8dc5a7d9bb9c749a985d563ff91e4df0@haskell.org> Message-ID: <062.a342572f464f35ee196f65945f59d6ac@haskell.org> #8811: Profiling output jumbled together -------------------------------------+------------------------------------- Reporter: augustss | Owner: dalaing Type: bug | Status: patch Priority: normal | Milestone: Component: Profiling | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D779 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"c81e07063dd4f792d65f5933cfb906620d120b24/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c81e07063dd4f792d65f5933cfb906620d120b24" Stop profiling output from running together (#8811) Reviewed By: thomie Differential Revision: https://phabricator.haskell.org/D779 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 10:13:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 10:13:23 -0000 Subject: [GHC] #10228: Increased memory usage with GHC 7.10.1 In-Reply-To: <048.689dfbc555185e5a975e80819cf26fc7@haskell.org> References: <048.689dfbc555185e5a975e80819cf26fc7@haskell.org> Message-ID: <063.88253c9a14010a0844cffb20e569487b@haskell.org> #10228: Increased memory usage with GHC 7.10.1 -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): See also [this email thread](https://mail.haskell.org/pipermail/ghc- devs/2015-April/008751.html), which has further responses. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 10:31:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 10:31:19 -0000 Subject: [GHC] #10247: 5x increase in total memory allocation for `prof-doc-fib` test since 2011 Message-ID: <045.d8aaa0bc0f02908f22bf1b71ccb674d4@haskell.org> #10247: 5x increase in total memory allocation for `prof-doc-fib` test since 2011 -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: high | Milestone: Component: Profiling | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Commit c81e07063dd4f792d65f5933cfb906620d120b24 (#8811) makes a small change to the formatting of the profiling output. When updating the prof.sample files in the `testsuite/tests/profiling/should_run` directory, we noticed that memory allocation numbers for several tests have increased substantially since 2011. {{{ -total alloc = 107,829,264 bytes (excludes profiling overheads) +total alloc = 538,951,032 bytes (excludes profiling overheads) }}} The following tests need investigation: * T680.prof.sample (2x total alloc) * prof-doc-fib.prof.sample (5x) * prof-doc-last.prof.sample (3x) * scc003.prof.sample (2x) Maybe it's nothing serious, but I'm setting priority to high since it seems like a regression. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 10:37:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 10:37:03 -0000 Subject: [GHC] #8811: Profiling output jumbled together In-Reply-To: <047.8dc5a7d9bb9c749a985d563ff91e4df0@haskell.org> References: <047.8dc5a7d9bb9c749a985d563ff91e4df0@haskell.org> Message-ID: <062.f2d8dbdaad35195c13b5a933df9c8c8a@haskell.org> #8811: Profiling output jumbled together -------------------------------------+------------------------------------- Reporter: augustss | Owner: dalaing Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Profiling | Version: 7.6.3 Resolution: fixed | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | prof.sample files in | profiling/should_run | Blocking: | Differential Revisions: Phab:D779 -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => closed * testcase: => prof.sample files in profiling/should_run * resolution: => fixed * milestone: => 7.12.1 Comment: Thanks Dave. I opened for #10247 for the 5x increase in memory allocation since 2011 of several profiling tests (seen in this patch, but unrelated to this ticket). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 10:55:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 10:55:18 -0000 Subject: [GHC] #10214: parser: TransStmt has incorrect SrcSpan In-Reply-To: <049.354eb02c7a1c2cda9ae89642a039bee8@haskell.org> References: <049.354eb02c7a1c2cda9ae89642a039bee8@haskell.org> Message-ID: <064.3c7a50a0d3da48e409de03859e179b5c@haskell.org> #10214: parser: TransStmt has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: mpickering | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 10:56:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 10:56:18 -0000 Subject: [GHC] #10214: parser: TransStmt has incorrect SrcSpan In-Reply-To: <049.354eb02c7a1c2cda9ae89642a039bee8@haskell.org> References: <049.354eb02c7a1c2cda9ae89642a039bee8@haskell.org> Message-ID: <064.8f4e6d9d87993cf98496278518e2a5f3@haskell.org> #10214: parser: TransStmt has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: mpickering | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D806 -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D806 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 10:56:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 10:56:47 -0000 Subject: [GHC] #10207: parser: ParStmt has incorrect SrcSpan In-Reply-To: <044.58d70da3f3be10a135bd8c2190ecc4c5@haskell.org> References: <044.58d70da3f3be10a135bd8c2190ecc4c5@haskell.org> Message-ID: <059.1234b72cfb5d66a209c9082f2943fcb3@haskell.org> #10207: parser: ParStmt has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D803 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch * differential: D803 => Phab:D803 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 13:14:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 13:14:02 -0000 Subject: [GHC] #10191: Interactive linker crash when partially applying seq# In-Reply-To: <044.ad92b336cebde1d35da0df353ea4f495@haskell.org> References: <044.ad92b336cebde1d35da0df353ea4f495@haskell.org> Message-ID: <059.bee297584bb399c4a8fc71266d5f34cf@haskell.org> #10191: Interactive linker crash when partially applying seq# -------------------------------+----------------------------------------- Reporter: mniip | Owner: Type: bug | Status: closed Priority: low | Milestone: Component: GHCi | Version: 7.8.4-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D759 -------------------------------+----------------------------------------- Comment (by simonpj): Thanks for chasing this down, Reid. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 14:09:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 14:09:36 -0000 Subject: [GHC] #10209: parser: opt_kind_sig has incorrect SrcSpan In-Reply-To: <044.4df35a96b087f820c01c3c57f4238bf6@haskell.org> References: <044.4df35a96b087f820c01c3c57f4238bf6@haskell.org> Message-ID: <059.1c97eb828cb5e1f6a3130ea768195aa6@haskell.org> #10209: parser: opt_kind_sig has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D813 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch * differential: => Phab:D813 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 14:10:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 14:10:46 -0000 Subject: [GHC] #9539: TQueue can lead to thread starvation In-Reply-To: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> References: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> Message-ID: <060.e5d4029be3eb09d1be555c79cd9650d8@haskell.org> #9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): I'm happy to defer to simonmar as the resident expert here. The fix seems pretty straightforward though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 14:20:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 14:20:55 -0000 Subject: [GHC] #10227: Type checker cannot deduce type In-Reply-To: <047.38bc9ed8d3484bd4c9bcb2480f8e1743@haskell.org> References: <047.38bc9ed8d3484bd4c9bcb2480f8e1743@haskell.org> Message-ID: <062.eac42d1f32f377765d67f47b6b050ee1@haskell.org> #10227: Type checker cannot deduce type -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): True. Jan Stolarek's work on [https://ghc.haskell.org/trac/ghc/wiki/InjectiveTypeFamilies injective type families] is a start in that direction. But you want more. Would you care to write a specification of exactly what you want, and an algorithm for achieving it? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 14:42:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 14:42:37 -0000 Subject: [GHC] #7258: Compiling DynFlags is jolly slow In-Reply-To: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> References: <046.5b0ca13f8e67074efa6f0020a75c7792@haskell.org> Message-ID: <061.4768efd877c213b4f6c163ec279ffcba@haskell.org> #7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.12.1 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 Revisions: -------------------------------------+------------------------------------- Changes (by asr): * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 14:46:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 14:46:03 -0000 Subject: [GHC] #3085: warn about language extensions that are not used In-Reply-To: <051.bedfbd02c24cc787d0bf163c67d17d1e@haskell.org> References: <051.bedfbd02c24cc787d0bf163c67d17d1e@haskell.org> Message-ID: <066.dafa0d65c690ff0f664d1f109467c2cd@haskell.org> #3085: warn about language extensions that are not used -------------------------------------+------------------------------------- Reporter: PVerswyvelen | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.10.1 Resolution: | Keywords: warnings Operating System: Unknown/Multiple | extensions language Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #9757 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by asr): * cc: asr@? (removed) * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 14:59:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 14:59:35 -0000 Subject: [GHC] #9225: Missing syntax error for package qualified import with version number In-Reply-To: <045.491fa452f637375b8cf3acd2fe942041@haskell.org> References: <045.491fa452f637375b8cf3acd2fe942041@haskell.org> Message-ID: <060.72bf6af35af18ad292000bf8895663f3@haskell.org> #9225: Missing syntax error for package qualified import with version number -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 (Parser) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | parser/should_fail/T9225 Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D755 -------------------------------------+------------------------------------- Changes (by asr): * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 15:00:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 15:00:34 -0000 Subject: [GHC] #8057: Warn when supplying version number to package-qualified import In-Reply-To: <046.dcdda60f854692c73464ccaeed842287@haskell.org> References: <046.dcdda60f854692c73464ccaeed842287@haskell.org> Message-ID: <061.b553bb892b56e1b0eb0dc2e6954635b8@haskell.org> #8057: Warn when supplying version number to package-qualified import -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9225 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by asr): * cc: asr@? (removed) * cc: asr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 15:12:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 15:12:22 -0000 Subject: [GHC] #9225: Missing syntax error for package qualified import with version number In-Reply-To: <045.491fa452f637375b8cf3acd2fe942041@haskell.org> References: <045.491fa452f637375b8cf3acd2fe942041@haskell.org> Message-ID: <060.2c28864f33cbd02ba258c759e8078c0d@haskell.org> #9225: Missing syntax error for package qualified import with version number -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 (Parser) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | parser/should_fail/T9225 Blocked By: | Blocking: Related Tickets: 8057 | Differential Revisions: Phab:D755 -------------------------------------+------------------------------------- Changes (by Lemming): * related: => 8057 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 15:13:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 15:13:40 -0000 Subject: [GHC] #9225: Missing syntax error for package qualified import with version number In-Reply-To: <045.491fa452f637375b8cf3acd2fe942041@haskell.org> References: <045.491fa452f637375b8cf3acd2fe942041@haskell.org> Message-ID: <060.f467c4be65921c14e172c24f349bdfce@haskell.org> #9225: Missing syntax error for package qualified import with version number -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 (Parser) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | parser/should_fail/T9225 Blocked By: | Blocking: Related Tickets: #8057 | Differential Revisions: Phab:D755 -------------------------------------+------------------------------------- Changes (by Lemming): * related: 8057 => #8057 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 15:31:10 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 15:31:10 -0000 Subject: [GHC] #10197: Release note links to Trac are wrong In-Reply-To: <046.db0c7be7cbdf5d0bc567f33daa660daa@haskell.org> References: <046.db0c7be7cbdf5d0bc567f33daa660daa@haskell.org> Message-ID: <061.e19c3e9262a9486d699041f060e37dcd@haskell.org> #10197: Release note links to Trac are wrong -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #10197 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => closed * resolution: => duplicate * related: => #10197 Comment: Thanks for reporting. We now have another ticket for the same issue however, so I'm closing this one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 15:31:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 15:31:36 -0000 Subject: [GHC] #10197: Release note links to Trac are wrong In-Reply-To: <046.db0c7be7cbdf5d0bc567f33daa660daa@haskell.org> References: <046.db0c7be7cbdf5d0bc567f33daa660daa@haskell.org> Message-ID: <061.e83f39bd6cc68e8d38c59620b7dd8663@haskell.org> #10197: Release note links to Trac are wrong -------------------------------------+------------------------------------- Reporter: Lemming | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #10210 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * related: #10197 => #10210 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 16:08:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 16:08:22 -0000 Subject: [GHC] #10206: Incorrect links are generated for modules in the index of "Haskell Hiearchical Libraries" In-Reply-To: <042.42f9ef42100e34be4ebb160898f1d318@haskell.org> References: <042.42f9ef42100e34be4ebb160898f1d318@haskell.org> Message-ID: <057.b121d2847f7b9ab40bec801ca18b3e8d@haskell.org> #10206: Incorrect links are generated for modules in the index of "Haskell Hiearchical Libraries" -------------------------------------+------------------------------------- Reporter: pgj | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Documentation | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by carter): I'm seeing the same problem with userland haddocks wrt the haddock index.html file :( glad to see this is on the plate for 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 16:09:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 16:09:01 -0000 Subject: [GHC] #10245: panic in new integer switch logic with "out-of-range" literals In-Reply-To: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> References: <047.75ea0dc3feddacd480f06c86ecf69bf6@haskell.org> Message-ID: <062.c4f488a558dc9975acac5a1e5fb4bc80@haskell.org> #10245: panic in new integer switch logic with "out-of-range" literals -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 (CodeGen) | Keywords: Resolution: | Architecture: x86_64 Operating System: Unknown/Multiple | (amd64) Type of failure: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by rwbarton): Good catch on the relation to #9533, I had totally forgotten about that ticket! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 17:28:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 17:28:09 -0000 Subject: [GHC] #10248: GHC panic when used with deferred type errors, again Message-ID: <051.64f05a661854466d873285ae46733b99@haskell.org> #10248: GHC panic when used with deferred type errors, again ---------------------------------------+------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc3 Keywords: | Operating System: Linux Architecture: x86 | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+------------------------------- Similar to previous report of mine #9834. Given `error.hs` {{{#!hs data I a = I a }}} I get the following result: {{{#!hs $ ghci -fdefer-type-errors -ignore-dot-ghci error.hs I <$> _ I <$> _ :2:7: Warning: Found hole ?_? with type: IO a0 Where: ?a0? is an ambiguous type variable In the second argument of ?(<$>)?, namely ?_? In the first argument of ?GHC.GHCi.ghciStepIO :: IO a_auR -> IO a_auR?, namely ?I <$> _? In a stmt of an interactive GHCi command: it <- GHC.GHCi.ghciStepIO :: IO a_auR -> IO a_auR (I <$> _) ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20150316 for i386-unknown-linux): nameModule $dShow_aIT Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *Main> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 17:29:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 17:29:07 -0000 Subject: [GHC] #10248: GHC panic when used with deferred type errors, again In-Reply-To: <051.64f05a661854466d873285ae46733b99@haskell.org> References: <051.64f05a661854466d873285ae46733b99@haskell.org> Message-ID: <066.ac628116f0cfa7d4f57b2b21b35103f9@haskell.org> #10248: GHC panic when used with deferred type errors, again ---------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > Similar to previous report of mine #9834. Given `error.hs` > {{{#!hs > data I a = I a > }}} > > I get the following result: > {{{#!hs > $ ghci -fdefer-type-errors -ignore-dot-ghci error.hs > GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help > [1 of 1] Compiling Main ( error.hs, interpreted ) > Ok, modules loaded: Main. > *Main> I <$> _ > I <$> _ > > :2:7: Warning: > Found hole ?_? with type: IO a0 > Where: ?a0? is an ambiguous type variable > In the second argument of ?(<$>)?, namely ?_? > In the first argument of ?GHC.GHCi.ghciStepIO :: > IO a_auR -> IO a_auR?, namely > ?I <$> _? > In a stmt of an interactive GHCi command: > it <- GHC.GHCi.ghciStepIO :: IO a_auR -> IO a_auR (I <$> _) > ghc: panic! (the 'impossible' happened) > (GHC version 7.10.0.20150316 for i386-unknown-linux): > nameModule $dShow_aIT > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > *Main> > }}} New description: Similar to previous report of mine #9834. Given `error.hs` {{{#!hs data I a = I a }}} I get the following result: {{{#!hs $ ghci -fdefer-type-errors -ignore-dot-ghci error.hs GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( error.hs, interpreted ) Ok, modules loaded: Main. *Main> I <$> _ I <$> _ :2:7: Warning: Found hole ?_? with type: IO a0 Where: ?a0? is an ambiguous type variable In the second argument of ?(<$>)?, namely ?_? In the first argument of ?GHC.GHCi.ghciStepIO :: IO a_auR -> IO a_auR?, namely ?I <$> _? In a stmt of an interactive GHCi command: it <- GHC.GHCi.ghciStepIO :: IO a_auR -> IO a_auR (I <$> _) ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20150316 for i386-unknown-linux): nameModule $dShow_aIT Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *Main> }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 17:32:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 17:32:37 -0000 Subject: [GHC] #10249: Suboptimal error message with deferred type errors Message-ID: <051.818ff8bc84030bedfa7f9663d4a7c3ef@haskell.org> #10249: Suboptimal error message with deferred type errors -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: feature | Milestone: request | Version: 7.10.1 Priority: normal | Operating System: Unknown/Multiple Component: GHCi | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs $ ghci -fdefer-type-errors -ignore-dot-ghci GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help Prelude> _ :2:1: Warning: Found hole ?_? with type: IO t0 Where: ?t0? is an ambiguous type variable In the first argument of ?GHC.GHCi.ghciStepIO :: IO a_aly -> IO a_aly?, namely ?_? In a stmt of an interactive GHCi command: it <- GHC.GHCi.ghciStepIO :: IO a_aly -> IO a_aly _ *** Exception: :2:1: Found hole ?_? with type: IO t0 Where: ?t0? is an ambiguous type variable In the first argument of ?GHC.GHCi.ghciStepIO :: IO a_aly -> IO a_aly?, namely ?_? In a stmt of an interactive GHCi command: it <- GHC.GHCi.ghciStepIO :: IO a_aly -> IO a_aly _ (deferred type error) Prelude> }}} It should ideally not expose `ghciStepIO` to the user. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 17:46:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 17:46:05 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.5acb1c63d78eb2269f5dade035fad78f@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D807 -------------------------------------+------------------------------------- Comment (by int-e): Replying to [comment:18 int-e]: > The three-state behaviour from comment 17 would require more work. Perhaps more importantly, it would be more difficult to explain to users. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 18:29:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 18:29:06 -0000 Subject: [GHC] #10249: Suboptimal error message with deferred type errors In-Reply-To: <051.818ff8bc84030bedfa7f9663d4a7c3ef@haskell.org> References: <051.818ff8bc84030bedfa7f9663d4a7c3ef@haskell.org> Message-ID: <066.b8f050c062877ea77532c6be8f6499db@haskell.org> #10249: Suboptimal error message with deferred type errors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Yes, that's true. Generally, GHC checks exactly what the user writes, but for GHCi it actually checks a synthesised expression wrapping what the user writes. This would not be difficult to fix; perhaps a bit fiddly. I'm happy to advise. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 19:26:54 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 19:26:54 -0000 Subject: [GHC] #10250: API Annotations : add Locations in hsSyn were layout occurs Message-ID: <044.e9f7429502526fbd11c0a38b5739b89e@haskell.org> #10250: API Annotations : add Locations in hsSyn were layout occurs -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- At the moment ghc-exactprint, which uses the GHC API Annotations to provide a framework for roundtripping Haskell source code with optional AST edits, has to implement a horrible workaround to manage the points where layout needs to be captured. These are MatchGroup HsDo HsCmdDo HsLet LetStmt HsCmdLet GRHSs To provide a more natural representation, the contents subject to layout rules need to be wrapped in a SrcSpan. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 19:42:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 19:42:03 -0000 Subject: [GHC] #10248: GHC panic when used with deferred type errors, again In-Reply-To: <051.64f05a661854466d873285ae46733b99@haskell.org> References: <051.64f05a661854466d873285ae46733b99@haskell.org> Message-ID: <066.fb75ba61edb9a55bd3f59f2354164919@haskell.org> #10248: GHC panic when used with deferred type errors, again ---------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+------------------------------------- Comment (by simonpj): Well that's odd. It works fine in HEAD. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 20:41:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 20:41:20 -0000 Subject: [GHC] #10251: Bad rule generated in pathological cases Message-ID: <046.d0cd20a41390a427daa0aa93adec4030@haskell.org> #10251: Bad rule generated in pathological cases -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- George reports: I am also seeing this on ghc 7.10.1, not sure if this is another instance of this bug (#9160): {{{ cabal install bitmap [ 3 of 10] Compiling Data.Bitmap.IO ( Data/Bitmap/IO.hs, dist/build/Data/Bitmap/IO.o ) Data/Bitmap/IO.hs:1248:1: Warning: SPECIALISE pragma for non-overloaded function ?myPlusPtr? Data/Bitmap/IO.hs:1249:1: Warning: SPECIALISE pragma for non-overloaded function ?myPlusPtr? ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-apple-darwin): Template variable unbound in rewrite rule $fPixelComponentFloat3_X2Rc [$fPixelComponentFloat3_X2Rc] [$fPixelComponentFloat3_X2Rc] [] [] }}} But it's ''not'' #9160 at all. So I'm making a new ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 20:42:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 20:42:45 -0000 Subject: [GHC] #10251: Bad rule generated in pathological cases In-Reply-To: <046.d0cd20a41390a427daa0aa93adec4030@haskell.org> References: <046.d0cd20a41390a427daa0aa93adec4030@haskell.org> Message-ID: <061.38d97768ad1035c4ece584b5359de1c6@haskell.org> #10251: Bad rule generated in pathological cases -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Old description: > George reports: I am also seeing this on ghc 7.10.1, not sure if this is > another instance of this bug (#9160): > {{{ > cabal install bitmap > [ 3 of 10] Compiling Data.Bitmap.IO ( Data/Bitmap/IO.hs, > dist/build/Data/Bitmap/IO.o ) > > Data/Bitmap/IO.hs:1248:1: Warning: > > SPECIALISE pragma for non-overloaded function ?myPlusPtr? > > Data/Bitmap/IO.hs:1249:1: Warning: > > SPECIALISE pragma for non-overloaded function ?myPlusPtr? > > ghc: panic! (the 'impossible' happened) > > (GHC version 7.10.1 for x86_64-apple-darwin): > > Template variable unbound in rewrite rule > > $fPixelComponentFloat3_X2Rc > [$fPixelComponentFloat3_X2Rc] > [$fPixelComponentFloat3_X2Rc] > [] > [] > }}} > But it's ''not'' #9160 at all. So I'm making a new ticket. New description: George reports: I am also seeing this on ghc 7.10.1, not sure if this is another instance of this bug (#9160): {{{ cabal install bitmap [ 3 of 10] Compiling Data.Bitmap.IO ( Data/Bitmap/IO.hs, dist/build/Data/Bitmap/IO.o ) Data/Bitmap/IO.hs:1248:1: Warning: SPECIALISE pragma for non-overloaded function ?myPlusPtr? Data/Bitmap/IO.hs:1249:1: Warning: SPECIALISE pragma for non-overloaded function ?myPlusPtr? ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-apple-darwin): Template variable unbound in rewrite rule $fPixelComponentFloat3_X2Rc [$fPixelComponentFloat3_X2Rc] [$fPixelComponentFloat3_X2Rc] [] [] }}} But it's ''not'' #9160 at all. So I'm making a new ticket. -- Comment (by simonpj): Slyfox says I've distilled it a bit to a selfcontained test: {{{ -- sf 9160 # cat B.hs {-# LANGUAGE NoImplicitPrelude #-} {-# OPTIONS_GHC -O2 #-} module B (bug) where data D = D data E = E class Storable a where poke2 :: a -> E instance Storable D where poke2 = poke2 -- undefined class Foo a where instance Foo D where class (Foo t, Storable t) => FooStorable t where instance FooStorable D where {-# SPECIALIZE instance FooStorable D #-} {-# SPECIALIZE bug :: D -> E #-} bug :: FooStorable t => t -> E bug = poke2 {- sf 9160 # ghc -c -fforce-recomp -Wall B.hs B.hs:5:10: Warning: Defined but not used: data constructor ?D? B.hs:6:10: Warning: Defined but not used: data constructor ?E? ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): Template variable unbound in rewrite rule $fFooStorableD_XU [$fFooStorableD_XU] [$fFooStorableD_XU] [] [] 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 Apr 6 20:43:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 20:43:55 -0000 Subject: [GHC] #10250: API Annotations : add Locations in hsSyn were layout occurs In-Reply-To: <044.e9f7429502526fbd11c0a38b5739b89e@haskell.org> References: <044.e9f7429502526fbd11c0a38b5739b89e@haskell.org> Message-ID: <059.4eb5d75553274bed6dd0926d5c58c3d6@haskell.org> #10250: API Annotations : add Locations in hsSyn were layout occurs -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D815 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch * differential: => Phab:D815 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 20:49:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 20:49:02 -0000 Subject: [GHC] #10249: Suboptimal error message with deferred type errors In-Reply-To: <051.818ff8bc84030bedfa7f9663d4a7c3ef@haskell.org> References: <051.818ff8bc84030bedfa7f9663d4a7c3ef@haskell.org> Message-ID: <066.ad8d2e921100949216eca43f9d393d57@haskell.org> #10249: Suboptimal error message with deferred type errors -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by monoidal): For what's worth you don't need deferred type errors to see `ghciStepIO`; `x <- 'a'` shows a type error with it as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 21:02:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 21:02:55 -0000 Subject: [GHC] #10252: Abstract newtype in hs-boot Message-ID: <045.e8a839b6d77317fe3fc87a446f262426@haskell.org> #10252: Abstract newtype in hs-boot -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: None/Unknown Keywords: backpack | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently, the following syntax is not supported in an `hs-boot` file: {{{ module A where newtype F }}} This functionality would be pretty useful, since often the RHS of a newtype is intended to be abstract, and would be a pain to place in the boot file. This is also useful for Backpack. It's a bit hard for me to tell what this should do under the hood: we would have newtypes without the coercions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 21:06:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 21:06:43 -0000 Subject: [GHC] #10252: Abstract newtype in hs-boot In-Reply-To: <045.e8a839b6d77317fe3fc87a446f262426@haskell.org> References: <045.e8a839b6d77317fe3fc87a446f262426@haskell.org> Message-ID: <060.5c8f457ce935aff48819b6ea5866057b@haskell.org> #10252: Abstract newtype in hs-boot -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: backpack Resolution: worksforme | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => worksforme Comment: Actually, the `data` keyword seems to work fine here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 21:35:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 21:35:23 -0000 Subject: [GHC] #9160: Panic: Template variable unbound in rewrite rule In-Reply-To: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> References: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> Message-ID: <060.3d021ab0e31f0bb259e7051d9140d0df@haskell.org> #9160: Panic: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | indexed_types/should_fail/T9160 Related Tickets: #4524 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Good report, but comment:15 and comment:16 are definitely a different bug to #9160. I've opened #10251. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 22:18:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 22:18:21 -0000 Subject: [GHC] #10193: TypeRep Show instance doesn't add parens around type operators In-Reply-To: <050.ff6cff2e03c64787c90e72c6c5c4a299@haskell.org> References: <050.ff6cff2e03c64787c90e72c6c5c4a299@haskell.org> Message-ID: <065.78964b744e1977d385ac8a585d53500f@haskell.org> #10193: TypeRep Show instance doesn't add parens around type operators -------------------------------------+------------------------------------- Reporter: pawel.nowak | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: libraries/base | Version: 7.10.1-rc3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): A better `Show` instance for `TypeRep` would be extremely welcome, thank you. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 6 23:01:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 06 Apr 2015 23:01:34 -0000 Subject: [GHC] #10195: GHC forgets constraints when matching on GADTs In-Reply-To: <047.0020e481c0d5cc2154e7ca7e404b2a9e@haskell.org> References: <047.0020e481c0d5cc2154e7ca7e404b2a9e@haskell.org> Message-ID: <062.a414dcfb14ba2e624f4ec3ba54844d0c@haskell.org> #10195: GHC forgets constraints when matching on GADTs -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I understand what is going on here. We get this constraint from the call to `magic`: {{{ forall[2] c m m' zp. Bar m m' => forall[3]. Num (c m zp) => Bar meta[2] m', meta[2]~m }}} The [2] and [3] are the "untouchable" levels, and `meta[2]` is a level-2 unification variable. When checking whether we can safely fire the top- level instance `(Bar b b')`, we try to ''unify'' the given `Bar m m'` with `Bar meta[2] m'`. The unification variable `meta[2]` is untouchable, so we wrongly made it behave like a skolem in this unification, so the unification failed, and so we fired the top-level instance. But the `(meta[2] ~ m)` constraint, if allowed to float out and then fire, will make the `Bar meta[2] m'` turn into `Bar m m'`, which can then be discharged by the given `Bar m m'`. So the mistake here is being a bit too eager when asking "is the top-level instance the only one that could apply?". The fix is easy. But of course it means that fewer top-level instances will fire, so it's possible that it will break other examples that currently "work". But rightly so, I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 04:36:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 04:36:11 -0000 Subject: [GHC] #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable In-Reply-To: <046.667caeee812579621ec3ac8601656752@haskell.org> References: <046.667caeee812579621ec3ac8601656752@haskell.org> Message-ID: <061.6461bfeffde627a0cb3ad8ac8b50b429@haskell.org> #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable -------------------------------------+------------------------------------- Reporter: afcowie | Owner: whisky Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9324 | Differential Revisions: Phab:D805 -------------------------------------+------------------------------------- Comment (by afcowie): Of course the user can use chmod. The point is they shouldn't have to. If they (or their distro) chooses to make the file group writable, it's not an increased attack surface. You're just screwing the user. AfC -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 08:53:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 08:53:15 -0000 Subject: [GHC] #9958: System.IO.Error: Fix a documentation link to Control.Exception.Exception In-Reply-To: <044.f8406cf4d09c8eb4152860b58e11bb5f@haskell.org> References: <044.f8406cf4d09c8eb4152860b58e11bb5f@haskell.org> Message-ID: <059.ea93e7ede484f21ab67f16ec77b159c7@haskell.org> #9958: System.IO.Error: Fix a documentation link to Control.Exception.Exception -------------------------------------+------------------------------------- Reporter: mineo | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by mineo): * status: new => closed * resolution: => fixed Comment: If you click on the "Source" link next to the type, you'll see that the version of base (4.8.0.0) the docs were built from does not yet include this change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 08:57:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 08:57:35 -0000 Subject: [GHC] #8785: Replace hooks API in the RTS with something better In-Reply-To: <047.cfaec68e96673ab1544c0369207069d6@haskell.org> References: <047.cfaec68e96673ab1544c0369207069d6@haskell.org> Message-ID: <062.be7ec98f4aad2c4549b7cbb6530529f8@haskell.org> #8785: Replace hooks API in the RTS with something better -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 7.12.1 Component: Runtime System | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D8 -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"a7ab161602aa0b5833d22c66e64eebb1d9275235/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a7ab161602aa0b5833d22c66e64eebb1d9275235" Replace hooks by callbacks in RtsConfig (#8785) Summary: Hooks rely on static linking semantics, and are broken by -Bsymbolic which we need when using dynamic linking. Test Plan: Built it Reviewers: austin, hvr, tibbe Differential Revision: https://phabricator.haskell.org/D8 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 09:41:22 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 09:41:22 -0000 Subject: [GHC] #10242: Multiple constraint wildcards allowed with PartialTypeSignatures In-Reply-To: <049.a953ada63cab8a32d81242f76b55213a@haskell.org> References: <049.a953ada63cab8a32d81242f76b55213a@haskell.org> Message-ID: <064.5f5e79286fa575e89e0e3d78efc399c1@haskell.org> #10242: Multiple constraint wildcards allowed with PartialTypeSignatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: thomasw Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | PartialTypeSignatures Type of failure: GHC accepts | Architecture: invalid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomasw): * owner: => thomasw -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 09:49:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 09:49:15 -0000 Subject: [GHC] #10242: Multiple constraint wildcards allowed with PartialTypeSignatures In-Reply-To: <049.a953ada63cab8a32d81242f76b55213a@haskell.org> References: <049.a953ada63cab8a32d81242f76b55213a@haskell.org> Message-ID: <064.5e50b742c1d8d3ed713b2113a1f26f4e@haskell.org> #10242: Multiple constraint wildcards allowed with PartialTypeSignatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: thomasw Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | PartialTypeSignatures Type of failure: GHC accepts | Architecture: invalid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #10098 | Blocking: | Differential Revisions: Phab:D613 -------------------------------------+------------------------------------- Changes (by thomasw): * differential: => Phab:D613 * related: => #10098 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 09:54:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 09:54:19 -0000 Subject: [GHC] #10242: Multiple constraint wildcards allowed with PartialTypeSignatures In-Reply-To: <049.a953ada63cab8a32d81242f76b55213a@haskell.org> References: <049.a953ada63cab8a32d81242f76b55213a@haskell.org> Message-ID: <064.162b6a5a36c78e2d3afd378e3cf67331@haskell.org> #10242: Multiple constraint wildcards allowed with PartialTypeSignatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: thomasw Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | PartialTypeSignatures Type of failure: GHC accepts | Architecture: invalid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #10098 | Blocking: | Differential Revisions: Phab:D613 -------------------------------------+------------------------------------- Comment (by thomasw): This is fixed by Phab:D613, which still needs to be merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 09:59:07 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 09:59:07 -0000 Subject: [GHC] #10242: Multiple constraint wildcards allowed with PartialTypeSignatures In-Reply-To: <049.a953ada63cab8a32d81242f76b55213a@haskell.org> References: <049.a953ada63cab8a32d81242f76b55213a@haskell.org> Message-ID: <064.631729d3d9fe1bd69233f028de18134d@haskell.org> #10242: Multiple constraint wildcards allowed with PartialTypeSignatures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: thomasw Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | PartialTypeSignatures Type of failure: GHC accepts | Architecture: invalid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #10098 | Blocking: | Differential Revisions: Phab:D613 -------------------------------------+------------------------------------- Comment (by simonpj): Good. Let's land Phab:D613. I doubt it's worth putting it into 7.10.2 Austin can you do that? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 10:08:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 10:08:54 -0000 Subject: [GHC] #10253: Variable name with special characters Message-ID: <045.857fe9364bac9bb00e7e02f75648b137@haskell.org> #10253: Variable name with special characters -------------------------------------+------------------------------------- Reporter: songzh | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Declaring a variable in GHCi with $ . is allowed, but they are not referable. I suppose that the parser should impose more restrictions at this. {{{#!hs *Main> let a$1 = 10 *Main> a$1 :20:1: Not in scope: ?a? Prelude> let a.1 = 10 Prelude> a.1 :9:1: Not in scope: ?a? Prelude> let a%1 = 1 Prelude> a%1 1 Prelude> let a^1 = 1 Prelude> a^1 1 Prelude> a^1 + 1 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 10:12:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 10:12:00 -0000 Subject: [GHC] #10253: Variable name with special characters In-Reply-To: <045.857fe9364bac9bb00e7e02f75648b137@haskell.org> References: <045.857fe9364bac9bb00e7e02f75648b137@haskell.org> Message-ID: <060.ae422f8801ad15c9b8f90594ccd18b1d@haskell.org> #10253: Variable name with special characters -------------------------------------+------------------------------------- Reporter: songzh | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => invalid Comment: You are not defining `a` there, but rather the operator `$`: {{{ Prelude> :t ($) ($) :: (a -> b) -> a -> b Prelude> let a$1 = 10 Prelude> :t ($) ($) :: (Num a1, Num a, Eq a) => t -> a -> a1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 12:59:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 12:59:47 -0000 Subject: [GHC] #10254: parser : the API annotation on opt_sig is being discarded Message-ID: <044.a5d202689c44d12743acba1f8d07ab48@haskell.org> #10254: parser : the API annotation on opt_sig is being discarded -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The `opt_sig` production is defined as {{{ opt_sig :: { ([AddAnn],Maybe (LHsType RdrName)) } : {- empty -} { ([],Nothing) } | '::' sigtype { ([mj AnnDcolon $1],Just $2) } }}} It is used in the `alt` and `decl_no_th` productions, but neither of them add the returned annotations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 13:11:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 13:11:17 -0000 Subject: [GHC] #10255: API Annotations : ExprWithTySig processing discards annotated spans Message-ID: <044.3995d3b4b19bd7e56b8289f8de527db1@haskell.org> #10255: API Annotations : ExprWithTySig processing discards annotated spans -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: Other ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In `RdrHsSyn.checkAPat` the processing for `ExprWithTySig` is defined as {{{#!hs ExprWithTySig e t _ -> do e <- checkLPat msg e -- Pattern signatures are parsed as sigtypes, -- but they aren't explicit forall points. Hence -- we have to remove the implicit forall here. let t' = case t of L _ (HsForAllTy Implicit _ _ (L _ []) ty) -> ty other -> other return (SigPatIn e (mkHsWithBndrs t')) }}} The `t'` variable ends up losing its original SrcSpan in the first case branch. This results in annotations becoming detached from the AST. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 13:23:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 13:23:33 -0000 Subject: [GHC] #10255: API Annotations : ExprWithTySig processing discards annotated spans In-Reply-To: <044.3995d3b4b19bd7e56b8289f8de527db1@haskell.org> References: <044.3995d3b4b19bd7e56b8289f8de527db1@haskell.org> Message-ID: <059.6c82be5a43edb66d59e0b041459acda5@haskell.org> #10255: API Annotations : ExprWithTySig processing discards annotated spans -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by alanz): Potential solution: call `mkHsWithBndrs` with `t'` replaced by `(L l (HsParTy t'))` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 13:43:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 13:43:14 -0000 Subject: [GHC] #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable In-Reply-To: <046.667caeee812579621ec3ac8601656752@haskell.org> References: <046.667caeee812579621ec3ac8601656752@haskell.org> Message-ID: <061.8c3fec385562136c0fc0ae8aa13a323d@haskell.org> #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable -------------------------------------+------------------------------------- Reporter: afcowie | Owner: whisky Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9324 | Differential Revisions: Phab:D805 -------------------------------------+------------------------------------- Comment (by Thomas Miedema ): In [changeset:"b972de0365f94e1be9d78537152eee969dc5f4cb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b972de0365f94e1be9d78537152eee969dc5f4cb" Suggest how to fix .ghci when it is group writeable (#8248) ``` chmod 664 $PATH_TO_GHCI_CONF/.ghci ``` Run ghci. You will now get a warning + a suggestion: ``` *** WARNING: $PATH_TO_GHCI_CONF/.ghci is writable by someone else, IGNORING! Suggested fix: execute 'chmod 644 $PATH_TO_GHCI_CONF/.ghci' ``` Execute fix and the warning should disappear. Reviewed By: mboes, thomie Differential Revision: https://phabricator.haskell.org/D805 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 13:49:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 13:49:36 -0000 Subject: [GHC] #10256: parser: API Annotations : squals does not annotate commas properly Message-ID: <044.8484e8ecf97da86fae5e843371f60830@haskell.org> #10256: parser: API Annotations : squals does not annotate commas properly -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The `squals` production includes {{{ | squals ',' qual {% addAnnotation (gl $ head $ unLoc $1) AnnComma (gl $2) >> return (sLL $1 $> ($3 : unLoc $1)) } }}} The `AnnComma` should be attached to `(gl $ last $ unLoc $1)`, rather than the head. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 13:58:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 13:58:27 -0000 Subject: [GHC] #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable In-Reply-To: <046.667caeee812579621ec3ac8601656752@haskell.org> References: <046.667caeee812579621ec3ac8601656752@haskell.org> Message-ID: <061.e6981d1e22272dac5a40a302c084b941@haskell.org> #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable -------------------------------------+------------------------------------- Reporter: afcowie | Owner: whisky Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.6.3 Resolution: wontfix | Keywords: Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9324 | Differential Revisions: Phab:D805 -------------------------------------+------------------------------------- Changes (by thomie): * keywords: newcomer => * status: patch => closed * resolution: => wontfix Comment: afcowie: I don't think there is a consensus to remove the current check. Please use #6017 for further discussion. For reference, this feature was introduced 14 years ago, in commit dfbbfedc7e68d3095a37e4359b69eccc27e5398c: {{{ Author: simonmar Date: Fri May 4 14:56:53 2001 +0000 [project @ 2001-05-04 14:56:53 by simonmar] - only read ~/.ghci if it is owned by the current user and isn't writable by anyone else. - Only read ./.ghci if both . and ./.ghci are owned by the current user and aren't writable by anyone else. I think this is sufficient: we don't need to check .. and ../.. etc. because "." always refers to the same directory while a process is running. ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 14:10:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 14:10:40 -0000 Subject: [GHC] #10148: Optimization causes repeated computation In-Reply-To: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> References: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> Message-ID: <058.e9c9bf22ed48b6d34d21c1e01d50d9b9@haskell.org> #10148: Optimization causes repeated computation -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"9f0f99fd41ff82cc223d3b682703e508efb564d2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9f0f99fd41ff82cc223d3b682703e508efb564d2" Fix a long-standing bug in the demand analyser This patch fixes Trac #10148, an outright and egregious bug in the demand analyser. It is explained in Note [Demand on case-alternative binders] in Demand.hs. I did some other minor refactoring. To my astonishment I got some big compiler perf changes * perf/compiler/T5837: bytes allocated -76% * perf/compiler/T5030: bytes allocated -10% * perf/compiler/T3294: max bytes used -25% Happy days }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 14:10:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 14:10:40 -0000 Subject: [GHC] #10233: Reexporting GHC.Exts does not export Constraint In-Reply-To: <044.25d86cfd1dd1041b5ff2433b8060fd47@haskell.org> References: <044.25d86cfd1dd1041b5ff2433b8060fd47@haskell.org> Message-ID: <059.5bfb00dfc673b8e7f8001a6ea0828411@haskell.org> #10233: Reexporting GHC.Exts does not export Constraint -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"74d2c33a1f4ebe3de090bc73d08910bbdd31f8f1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="74d2c33a1f4ebe3de090bc73d08910bbdd31f8f1" GHC.Prim.Constraint is not built-in syntax This fixes Trac #10233 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 14:10:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 14:10:40 -0000 Subject: [GHC] #10251: Bad rule generated in pathological cases In-Reply-To: <046.d0cd20a41390a427daa0aa93adec4030@haskell.org> References: <046.d0cd20a41390a427daa0aa93adec4030@haskell.org> Message-ID: <061.a870e218bfb2e8b33369b6386623e893@haskell.org> #10251: Bad rule generated in pathological cases -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"cfb60421a43f23e75ead85d99cec207a156f9312/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="cfb60421a43f23e75ead85d99cec207a156f9312" Do not quantify over the function itself in a RULE We were erroneously quantifying over the function when it had a dictionary type. A bit pathological, but possible. This fixes Trac #10251 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 14:10:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 14:10:40 -0000 Subject: [GHC] #10195: GHC forgets constraints when matching on GADTs In-Reply-To: <047.0020e481c0d5cc2154e7ca7e404b2a9e@haskell.org> References: <047.0020e481c0d5cc2154e7ca7e404b2a9e@haskell.org> Message-ID: <062.c917ff4779988a0348fcc9a794d01340@haskell.org> #10195: GHC forgets constraints when matching on GADTs -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"8b7ceece52d2a0bb8a4ea5609da286fb76d88211/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8b7ceece52d2a0bb8a4ea5609da286fb76d88211" More aggressive Given/Wanted overlap check This fixes Trac #10195 For some reason we considered untouchability before, but Trac #10195 shows that this is positively worng. See Note [Instance and Given overlap] in TcInteract. Looking at the Git log, it seems that this bug was introduced at the same time that we introduced the Given/Wanted overlap check in the first place. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 14:10:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 14:10:41 -0000 Subject: [GHC] #10194: Shouldn't this require ImpredicativeTypes? In-Reply-To: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> References: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> Message-ID: <062.7bac3d7337a25703471352598f16784c@haskell.org> #10194: Shouldn't this require ImpredicativeTypes? -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"553c5182156c5e4c15e3bd1c17c6d83a95a6c408/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="553c5182156c5e4c15e3bd1c17c6d83a95a6c408" Look inside synonyms for foralls when unifying This fixes Trac #10194 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 14:13:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 14:13:25 -0000 Subject: [GHC] #10239: Fragile CPP test for big endian in T7600 In-Reply-To: <047.4141fef62b155ef45c7ff2e676f4002e@haskell.org> References: <047.4141fef62b155ef45c7ff2e676f4002e@haskell.org> Message-ID: <062.76122b60ac89ba43cee115a9179d4888@haskell.org> #10239: Fragile CPP test for big endian in T7600 -------------------------------------+------------------------------------- Reporter: trommler | Owner: trommler Type: bug | Status: patch Priority: normal | Milestone: Component: Test Suite | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: T7600 Related Tickets: | Blocking: | Differential Revisions: Phab:D795 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"4f8e34822f18cf3d31414676f900b3714367d38e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4f8e34822f18cf3d31414676f900b3714367d38e" Replace endian test by 64-bit word access in T7600 In commit 3f30912f an include `ghcconfig.h` was added for `WORDS_BIGENDIAN`. Converting the floating point array to a `Word64` array avoids using the preprocessor altogether and leads to smaller code. Fixes #10239 Reviewed By: rwbarton, austin Differential Revision: https://phabricator.haskell.org/D795 GHC Trac Issues: #10239 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 14:13:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 14:13:25 -0000 Subject: [GHC] #10207: parser: ParStmt has incorrect SrcSpan In-Reply-To: <044.58d70da3f3be10a135bd8c2190ecc4c5@haskell.org> References: <044.58d70da3f3be10a135bd8c2190ecc4c5@haskell.org> Message-ID: <059.9c556a5b98c5ffffec3c67c8fa6fef90@haskell.org> #10207: parser: ParStmt has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D803 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"f1a4e42ea2e5302147dcb69b9baa6f4aa3af6e37/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f1a4e42ea2e5302147dcb69b9baa6f4aa3af6e37" The production for `pquals` is incorrect; the specifics are in D803. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D803 GHC Trac Issues: #10207 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 14:13:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 14:13:25 -0000 Subject: [GHC] #10214: parser: TransStmt has incorrect SrcSpan In-Reply-To: <049.354eb02c7a1c2cda9ae89642a039bee8@haskell.org> References: <049.354eb02c7a1c2cda9ae89642a039bee8@haskell.org> Message-ID: <064.f9009c458d5db82c7bf37129ad433a6e@haskell.org> #10214: parser: TransStmt has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: mpickering | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D806 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"cf196400609d920e7f8189b9376833f4f5886360/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="cf196400609d920e7f8189b9376833f4f5886360" The production for squals is incorrect; see D806 for specifics. This diff depends on D803. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D806 GHC Trac Issues: #10214 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 14:14:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 14:14:04 -0000 Subject: [GHC] #10194: Shouldn't this require ImpredicativeTypes? In-Reply-To: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> References: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> Message-ID: <062.e9947d21302d16b151d562b46e6aabd1@haskell.org> #10194: Shouldn't this require ImpredicativeTypes? -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T10194 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => typecheck/should_fail/T10194 Comment: Excellent point. Fixed. (I doubt this is worth the trouble of merging to 7.10.2, but could be.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 14:17:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 14:17:28 -0000 Subject: [GHC] #10233: Reexporting GHC.Exts does not export Constraint In-Reply-To: <044.25d86cfd1dd1041b5ff2433b8060fd47@haskell.org> References: <044.25d86cfd1dd1041b5ff2433b8060fd47@haskell.org> Message-ID: <059.593a5d4a627747493b34032a003d8377@haskell.org> #10233: Reexporting GHC.Exts does not export Constraint -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | module/T10233 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => module/T10233 Comment: Aha, quite right. Result of an oversight in `TysPrim`. This probably is worth merging to 7.10, although some error messages will start saying `GHC.Prim.Constraint` instead of `Constraint`. I've addressed that in 547c597112954353cef7157cb0a389bc4f6303eb, but I don't think the latter is worth merging. So just accept the error message changes. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 14:18:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 14:18:32 -0000 Subject: [GHC] #10195: GHC forgets constraints when matching on GADTs In-Reply-To: <047.0020e481c0d5cc2154e7ca7e404b2a9e@haskell.org> References: <047.0020e481c0d5cc2154e7ca7e404b2a9e@haskell.org> Message-ID: <062.94db662aa9278aa9e9d4a222b894eaf9@haskell.org> #10195: GHC forgets constraints when matching on GADTs -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | typecheck/should_compile/T10195 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => typecheck/should_compile/T10195 * milestone: => 7.10.2 Comment: Very good! Fixed. This is worth merging. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 14:29:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 14:29:17 -0000 Subject: [GHC] #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable In-Reply-To: <046.667caeee812579621ec3ac8601656752@haskell.org> References: <046.667caeee812579621ec3ac8601656752@haskell.org> Message-ID: <061.bd2cd4366e4fc09dc1c4b2979d2a6b01@haskell.org> #8248: GHCi should not fail to honour ghci.conf or .ghci if group writable -------------------------------------+------------------------------------- Reporter: afcowie | Owner: whisky Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.6.3 Resolution: wontfix | Keywords: Operating System: Linux | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9324 | Differential Revisions: Phab:D805 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.12.1 => 7.10.2 Comment: I went ahead and picked this into the `ghc-7.10` branch; see 53f723589819f5e232d2333a993a4d0341702dc4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 14:31:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 14:31:34 -0000 Subject: [GHC] #10251: Bad rule generated in pathological cases In-Reply-To: <046.d0cd20a41390a427daa0aa93adec4030@haskell.org> References: <046.d0cd20a41390a427daa0aa93adec4030@haskell.org> Message-ID: <061.78b4df46c2b27bc9fedeeffcbde25a51@haskell.org> #10251: Bad rule generated in pathological cases -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | deSugar/should_compile/T10251 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => deSugar/should_compile/T10251 * milestone: => 7.10.2 Comment: Very good, thanks for the report. This is worth merging to 7.10, because it makes the `bitmap` library compile again Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 14:33:07 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 14:33:07 -0000 Subject: [GHC] #10207: parser: ParStmt has incorrect SrcSpan In-Reply-To: <044.58d70da3f3be10a135bd8c2190ecc4c5@haskell.org> References: <044.58d70da3f3be10a135bd8c2190ecc4c5@haskell.org> Message-ID: <059.ef17f3f5a019f07d9619b100868d6f67@haskell.org> #10207: parser: ParStmt has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: fixed | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D803 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10` and `master`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 14:33:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 14:33:15 -0000 Subject: [GHC] #10214: parser: TransStmt has incorrect SrcSpan In-Reply-To: <049.354eb02c7a1c2cda9ae89642a039bee8@haskell.org> References: <049.354eb02c7a1c2cda9ae89642a039bee8@haskell.org> Message-ID: <064.cbffb0bb546b511abde97a400c08cb52@haskell.org> #10214: parser: TransStmt has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: mpickering | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: fixed | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D806 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10` and `master`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 14:36:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 14:36:23 -0000 Subject: [GHC] #9964: GHC crash with NOINLINE and weird IO stuff In-Reply-To: <045.9a8dda45bf1bf3aa22c69d27e354c51f@haskell.org> References: <045.9a8dda45bf1bf3aa22c69d27e354c51f@haskell.org> Message-ID: <060.875288a94edabc325b2a939aaf3a842b@haskell.org> #9964: GHC crash with NOINLINE and weird IO stuff -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | codeGen/should_compile/T9964 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. @mietek - please file another bug for the behavior you're seeing; it's likely unrelated to this I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 14:40:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 14:40:11 -0000 Subject: [GHC] #10194: Shouldn't this require ImpredicativeTypes? In-Reply-To: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> References: <047.58cd14073ee2fddfc8b76b5a23ea1041@haskell.org> Message-ID: <062.201ea52d3ea73748a117018004386083@haskell.org> #10194: Shouldn't this require ImpredicativeTypes? -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | typecheck/should_fail/T10194 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.10.2 Comment: Merged to `ghc-7.10` via 681d82c0d44f06f0b958b75778c30b0910df982b -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 14:40:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 14:40:32 -0000 Subject: [GHC] #10251: Bad rule generated in pathological cases In-Reply-To: <046.d0cd20a41390a427daa0aa93adec4030@haskell.org> References: <046.d0cd20a41390a427daa0aa93adec4030@haskell.org> Message-ID: <061.1a3dc24c31868b3a061c903a1aac427f@haskell.org> #10251: Bad rule generated in pathological cases -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | deSugar/should_compile/T10251 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10` via 211cc28688c9424105c204f535ff54033a2c657e -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 15:13:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 15:13:34 -0000 Subject: [GHC] #10177: Typeable solver regression In-Reply-To: <044.31773993d01a9acbca1586a9db429c36@haskell.org> References: <044.31773993d01a9acbca1586a9db429c36@haskell.org> Message-ID: <059.6dff17e90940df190cea5c97b917d875@haskell.org> #10177: Typeable solver regression -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1-rc3 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | testsuite/tests/typecheck/should_compile/T10177 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Austin: check that this works on the 7.10 branch; assuming that it does, re-milestone for 7.12. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 15:14:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 15:14:33 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.2068bf86a6e293230906155dfe1ffcdf@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.12.1 => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 15:15:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 15:15:19 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.7a00f1d489d7e3f10671820e0ada488e@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: 7.10.2 => 7.12.1 Comment: Iavor, how's it going? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 15:15:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 15:15:53 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.b758756d7fd06061884a958f2daaf5dd@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: 7.12.1 => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 15:22:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 15:22:40 -0000 Subject: [GHC] #10218: GHC creates incorrect code which throws <> In-Reply-To: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> References: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> Message-ID: <061.966c18084f2ed8ddf944b9f3d6b694aa@haskell.org> #10218: GHC creates incorrect code which throws <> -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: yes Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * priority: normal => highest * milestone: => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 15:24:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 15:24:02 -0000 Subject: [GHC] #10218: GHC creates incorrect code which throws <> In-Reply-To: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> References: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> Message-ID: <061.3cb9227a76dfcdbcb24d5ae73bdc60be@haskell.org> #10218: GHC creates incorrect code which throws <> -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: yes Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * priority: highest => normal * milestone: 7.10.2 => Comment: Could you try `-flate-dmd-anal` (7.10 only)? Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 15:35:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 15:35:54 -0000 Subject: [GHC] #10188: prefix type-level cons can't be parsed In-Reply-To: <048.7e4900ef2bdc3f1cec59a189bfabf4f0@haskell.org> References: <048.7e4900ef2bdc3f1cec59a189bfabf4f0@haskell.org> Message-ID: <063.b80ec5233e850271d5bf606b05db61d5@haskell.org> #10188: prefix type-level cons can't be parsed -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Kinokkory Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Phab:D768 Related Tickets: #10189 | -------------------------------------+------------------------------------- Changes (by Kinokkory): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 15:43:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 15:43:24 -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.a0d4f42086805bb77a7a98d32b22eb07@haskell.org> #10068: Make the runtime reflection API for names, modules, locations more systematic -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Currently in `base` we have > > * `GHC.SrcLoc`: the data type `SrcLoc` contains `srcLocPackage` and > `srcLocModule` > > * `Data.Typeable.Internals`: the data type `TyCon` contains > `tyConPackage`, `tyConModule` and `tyConName. > > * `GHC.Generics`: the data type `Datatype` contains `dataTypePackage`, > `dataTypeModule` and `dataTypeName` > > * `Data.Data`: the data type `DataType` (yes the capitalisation > differs!) contains a field `tycon :: String`, and there are functions > `tyconModule :: String -> String`, and `tyconUQname :: String -> String`, > for parsing that string and extracting the module name and tycon name. > > * `GHC.StaticPtr`: the data type `StaticPtrInfo` contains > `spInfoPackageKey`, `spInfoModuleName`, `spInfoName` (all `String`s). > Oh, and `spInfoSrcLoc :: (Int,Int)` too! > > This is madness! Five different representations for the same information > in one package! > > Let's fix this by defining some shared data types, for > > * `Module` = `ModuleName` + package > * `Entity` = `Module` + unqualified name > > There would be a tiresome changeover period; but `Typeable` and > `StaticPtr` are in flux anyway. > > Would anyone be willing to lead on this? New description: Currently in `base` we have * `GHC.SrcLoc`: the data type `SrcLoc` contains `srcLocPackage` and `srcLocModule` * `Data.Typeable.Internals`: the data type `TyCon` contains `tyConPackage`, `tyConModule` and `tyConName`. * `GHC.Generics`: the data type `Datatype` contains `dataTypePackage`, `dataTypeModule` and `dataTypeName` * `Data.Data`: the data type `DataType` (yes the capitalisation differs!) contains a field `tycon :: String`, and there are functions `tyconModule :: String -> String`, and `tyconUQname :: String -> String`, for parsing that string and extracting the module name and tycon name. * `GHC.StaticPtr`: the data type `StaticPtrInfo` contains `spInfoPackageKey`, `spInfoModuleName`, `spInfoName` (all `String`s). Oh, and `spInfoSrcLoc :: (Int,Int)` too! This is madness! Five different representations for the same information in one package! Let's fix this by defining some shared data types, for * `Module` = `ModuleName` + package * `Entity` = `Module` + unqualified name There would be a tiresome changeover period; but `Typeable` and `StaticPtr` are in flux anyway. Would anyone be willing to lead on this? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 16:07:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 16:07:53 -0000 Subject: [GHC] #10252: Abstract newtype in hs-boot In-Reply-To: <045.e8a839b6d77317fe3fc87a446f262426@haskell.org> References: <045.e8a839b6d77317fe3fc87a446f262426@haskell.org> Message-ID: <060.3c970be3ac3f883fbaa6641a62e10acc@haskell.org> #10252: Abstract newtype in hs-boot -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: backpack Resolution: worksforme | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): This scares me. `data` and `newtype` are different! After a quick ponder, I don't see damage that can be caused by abusing this. But, if we ever had representational type families (where `type instance RepF Int = Bool` would be used to reduce `RepF Age` to `Bool`), this would be a disaster. I can't seem to find a ticket requesting representational matching for type families (or classes, or data families), but the idea has come up. (See some wonderings in this direction in #9112, for example.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 16:10:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 16:10:04 -0000 Subject: [GHC] #10252: Abstract newtype in hs-boot In-Reply-To: <045.e8a839b6d77317fe3fc87a446f262426@haskell.org> References: <045.e8a839b6d77317fe3fc87a446f262426@haskell.org> Message-ID: <060.d81757a78acb39369a0cc5b2015b79db@haskell.org> #10252: Abstract newtype in hs-boot -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: backpack Resolution: worksforme | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): You already can define instances of a data family that are newtypes, isn't this sort of like a special case of that? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 16:10:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 16:10:06 -0000 Subject: [GHC] #9160: Panic: Template variable unbound in rewrite rule In-Reply-To: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> References: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> Message-ID: <060.8075290d08c793c7288d045587de901e@haskell.org> #9160: Panic: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | indexed_types/should_fail/T9160 Related Tickets: #4524 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Should we re-close this ticket then? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 16:40:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 16:40:40 -0000 Subject: [GHC] #10252: Abstract newtype in hs-boot In-Reply-To: <045.e8a839b6d77317fe3fc87a446f262426@haskell.org> References: <045.e8a839b6d77317fe3fc87a446f262426@haskell.org> Message-ID: <060.52a0bae0c8aabee3e479456728b136e5@haskell.org> #10252: Abstract newtype in hs-boot -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: backpack Resolution: worksforme | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Hmmm... I guess so. It means that we can't tell whether something is a `data` or a `newtype` right away. This throws out the idea of representational matching, for better or worse. Good point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 16:48:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 16:48:25 -0000 Subject: [GHC] #10148: Optimization causes repeated computation In-Reply-To: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> References: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> Message-ID: <058.5360b2e241fcab6c41a4105f522aa686@haskell.org> #10148: Optimization causes repeated computation -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"eacda9244913709ed025767418468b4cfc878cf9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="eacda9244913709ed025767418468b4cfc878cf9" Test Trac #10148 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 16:50:07 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 16:50:07 -0000 Subject: [GHC] #10257: internal error: evacuate: strange closure type 3269 Message-ID: <047.9511e1d29a6fe19a254bb4b081209d96@haskell.org> #10257: internal error: evacuate: strange closure type 3269 -------------------------------------------+------------------------------- Reporter: lukaramu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+------------------------------- When trying to load the attatched source into GHCi, it spit out the following error: {{{ ghc.exe: internal error: evacuate: strange closure type 3269 (GHC version 7.8.3 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 16:51:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 16:51:57 -0000 Subject: [GHC] #10258: internal error: evacuate: strange closure type 3269 Message-ID: <047.cc59713a7da2897a27b68eb8f93d7d29@haskell.org> #10258: internal error: evacuate: strange closure type 3269 -------------------------------------------+------------------------------- Reporter: lukaramu | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+------------------------------- When trying to load the attatched source into GHCi, it spit out the following error: {{{ ghc.exe: internal error: evacuate: strange closure type 3269 (GHC version 7.8.3 for i386_unknown_mingw32) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. }}} I could not reproduce the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 17:07:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 17:07:27 -0000 Subject: [GHC] #10257: internal error: evacuate: strange closure type 3269 In-Reply-To: <047.9511e1d29a6fe19a254bb4b081209d96@haskell.org> References: <047.9511e1d29a6fe19a254bb4b081209d96@haskell.org> Message-ID: <062.32098c721581806ccccad5741caf27ff@haskell.org> #10257: internal error: evacuate: strange closure type 3269 -------------------------------+------------------------------------------- Reporter: lukaramu | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: duplicate | Keywords: Operating System: Windows | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: #10258 | Differential Revisions: -------------------------------+------------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate * related: => #10258 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 18:15:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 18:15:06 -0000 Subject: [GHC] #10247: 5x increase in total memory allocation for `prof-doc-fib` test since 2011 In-Reply-To: <045.d8aaa0bc0f02908f22bf1b71ccb674d4@haskell.org> References: <045.d8aaa0bc0f02908f22bf1b71ccb674d4@haskell.org> Message-ID: <060.95c0fee97da3a1e6462f146ae01c2faa@haskell.org> #10247: 5x increase in total memory allocation for `prof-doc-fib` test since 2011 -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: high | Milestone: Component: Profiling | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I tried running the tests with 7.8.4 since I don't have HEAD built with profiling libraries at the moment. I see almost exactly 2x factors on T680, prof-doc-last, and scc003. I also notice that these prof files are all from Oct 25-27 2011. Probably they were just generated on a 32-bit processor? For prof-doc-fib I notice that the profiling output changed in a recent (not in 7.8.4) commit daed18c35cda114d8a5303bcb645195e1fd397e3, and the old file agrees with the above. That is, it showed almost exactly half the total allocation that I see, and it is from the same date range. So there seems to be no alarm through 7.8.4. I'll try HEAD to see if there is any change. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 18:55:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 18:55:21 -0000 Subject: [GHC] #10209: parser: opt_kind_sig has incorrect SrcSpan In-Reply-To: <044.4df35a96b087f820c01c3c57f4238bf6@haskell.org> References: <044.4df35a96b087f820c01c3c57f4238bf6@haskell.org> Message-ID: <059.946401e3aac075fe26ca6bcdcbe4ad91@haskell.org> #10209: parser: opt_kind_sig has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D813 -------------------------------------+------------------------------------- Changes (by alanz): * owner: alanz => * status: patch => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 18:55:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 18:55:32 -0000 Subject: [GHC] #9252: Generalize hs-boot files to be more like module signatures In-Reply-To: <045.b5edee1aab2b53d61b6209a32a6babdb@haskell.org> References: <045.b5edee1aab2b53d61b6209a32a6babdb@haskell.org> Message-ID: <060.a59daac2f4d632878bd1c24bc8c7d007@haskell.org> #9252: Generalize hs-boot files to be more like module signatures -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D130 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"a7524eaed33324e2155c47d4a705bef1d70a2b5b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a7524eaed33324e2155c47d4a705bef1d70a2b5b" Support for multiple signature files in scope. Summary: A common pattern when programming with signatures is to combine multiple signatures together (signature linking). We achieve this by making it not-an-error to have multiple, distinct interface files for the same module name, as long as they have the same backing implementation. When a user imports a module name, they get ALL matching signatures dumped into their scope. On the way, I refactored the module finder code, which now distinguishes between exact finds (when you had a 'Module') and regular finds (when you had a 'ModuleName'). I also refactored the package finder code to use a Monoid instance on LookupResult to collect together various results. ToDo: At the moment, if a signature is declared in the local package, it completely overrides any remote signatures. Eventually, we'll want to also pull in the remote signatures (or even override the local signature, if the full implementation is available.) There are bunch of ToDos in the code for what to do once this is done. ToDo: At the moment, whenever a module name lookup occurs in GHCi and we would have seen a signature, we instead continue and return the Module for the backing implementation. This is correct for most cases, but there might be some situations where we want something a little more fine- grained (e.g. :browse should only list identifiers which are available through the in-scope signatures, and not ALL of them.) Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, hvr, austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D790 GHC Trac Issues: #9252 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 18:55:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 18:55:50 -0000 Subject: [GHC] #10209: parser: opt_kind_sig has incorrect SrcSpan In-Reply-To: <044.4df35a96b087f820c01c3c57f4238bf6@haskell.org> References: <044.4df35a96b087f820c01c3c57f4238bf6@haskell.org> Message-ID: <059.1351671da861b6e6f8151fd1c246ff9c@haskell.org> #10209: parser: opt_kind_sig has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D813 -------------------------------------+------------------------------------- Changes (by alanz): * owner: => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 18:57:22 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 18:57:22 -0000 Subject: [GHC] #10209: parser: opt_kind_sig has incorrect SrcSpan In-Reply-To: <044.4df35a96b087f820c01c3c57f4238bf6@haskell.org> References: <044.4df35a96b087f820c01c3c57f4238bf6@haskell.org> Message-ID: <059.f9ce15c989c79aaa26c76c5bdd8b9179@haskell.org> #10209: parser: opt_kind_sig has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D813 -------------------------------------+------------------------------------- Comment (by alanz): From ezyang ...but the LHsKind shouldn't include the ::, right? Because that's not part of the kind. Proposed fix: pass the AnnDcolon up to whatever contains the opt_kind_sig. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 19:20:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 19:20:18 -0000 Subject: [GHC] #10247: 5x increase in total memory allocation for `prof-doc-fib` test since 2011 In-Reply-To: <045.d8aaa0bc0f02908f22bf1b71ccb674d4@haskell.org> References: <045.d8aaa0bc0f02908f22bf1b71ccb674d4@haskell.org> Message-ID: <060.e934071509a7208b0b3c445b0dede658@haskell.org> #10247: 5x increase in total memory allocation for `prof-doc-fib` test since 2011 -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: new Priority: high | Milestone: Component: Profiling | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Now testing with HEAD, on a hunch I tried `make fast TEST=prof-doc-fib` (which only runs the profasm test way), and I got a number which (exactly!) matched the previous prof-doc-fib.prof.sample value. So I think that file was produced with profasm. (Would be nice to record this information...) prof-doc-last really did regress from 7.8.4 to 7.10.1, though: {{{ total alloc = 408,053,512 bytes (excludes profiling overheads) -- 7.8.4 total alloc = 648,053,536 bytes (excludes profiling overheads) -- 7.10.1 }}} presumably due to b709f0a047dc036de15dc43d3b0ab88d3e32c5e6. But the extra allocations go away when optimizations are enabled, so I guess it's okay. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 19:29:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 19:29:55 -0000 Subject: [GHC] #10210: Documentation link to 7.10.1 migration guide broken In-Reply-To: <052.f02bf8afd4996dd8619e6f1820ea86bb@haskell.org> References: <052.f02bf8afd4996dd8619e6f1820ea86bb@haskell.org> Message-ID: <067.4b3dda1828bd6f3ce7a0a0bae92ac536@haskell.org> #10210: Documentation link to 7.10.1 migration guide broken -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | thoughtpolice Priority: normal | Status: new Component: Documentation | Milestone: 7.10.2 Resolution: | Version: 7.10.1 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by crockeea): There are other broken links on that page: in particular the links to trac questions at the very bottom don't work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 19:34:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 19:34:01 -0000 Subject: [GHC] #10259: HPC code coverage fails Message-ID: <051.5eb6d52bae1ecbfd49110a391027e287@haskell.org> #10259: HPC code coverage fails -------------------------------------+------------------------------------- Reporter: | Owner: LukeHoersten | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: MacOS X Keywords: hpc | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- in a completely clean sandbox environment: cabal install --dependencies-only --enable-tests --enable-coverage --enable-benchmarks cabal build test --dependencies-only --enable-tests --enable-coverage --enable-benchmarks cabal test project --test-options=--html=dist/tasty/index.html Command: cabal test project --test-options=--html=dist/tasty/index.html Exit code: 1 Stderr: hpc: can not find text_IINWRW1LxFGIctooOLjJAI/Data.Text.Unsafe in ["./.hpc","./dist/hpc/vanilla/mix/project-0.1.0.0","./dist/hpc/vanilla/mix /project-test"] $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.1 $ cabal --version cabal-install version 1.22.2.0 using version 1.22.2.0 of the Cabal library $ clang --version Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.3.0 Thread model: posix OS X version 10.10.3 Installed from home-brew and Haskell for Mac OS X both have the same problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 19:36:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 19:36:20 -0000 Subject: [GHC] #10259: HPC code coverage fails In-Reply-To: <051.5eb6d52bae1ecbfd49110a391027e287@haskell.org> References: <051.5eb6d52bae1ecbfd49110a391027e287@haskell.org> Message-ID: <066.259a3cb8cb3cfbe7fcc39ff74cbbf9e9@haskell.org> #10259: HPC code coverage fails -------------------------------------+------------------------------------- Reporter: LukeHoersten | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: hpc Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by LukeHoersten: Old description: > in a completely clean sandbox environment: > > cabal install --dependencies-only --enable-tests --enable-coverage > --enable-benchmarks > cabal build test --dependencies-only --enable-tests --enable-coverage > --enable-benchmarks > cabal test project --test-options=--html=dist/tasty/index.html > > Command: cabal test project --test-options=--html=dist/tasty/index.html > Exit code: 1 > Stderr: > hpc: can not find text_IINWRW1LxFGIctooOLjJAI/Data.Text.Unsafe in > ["./.hpc","./dist/hpc/vanilla/mix/project-0.1.0.0","./dist/hpc/vanilla/mix > /project-test"] > > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version 7.10.1 > > $ cabal --version > cabal-install version 1.22.2.0 > using version 1.22.2.0 of the Cabal library > > $ clang --version > Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) > Target: x86_64-apple-darwin14.3.0 > Thread model: posix > > OS X version 10.10.3 > > Installed from home-brew and Haskell for Mac OS X both have the same > problem. New description: in a completely clean sandbox environment: cabal install --dependencies-only --enable-tests --enable-coverage --enable-benchmarks cabal build test --enable-tests --enable-coverage --enable-benchmarks cabal test project --test-options=--html=dist/tasty/index.html Command: cabal test project --test-options=--html=dist/tasty/index.html Exit code: 1 Stderr: hpc: can not find text_IINWRW1LxFGIctooOLjJAI/Data.Text.Unsafe in ["./.hpc","./dist/hpc/vanilla/mix/project-0.1.0.0","./dist/hpc/vanilla/mix /project-test"] $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.1 $ cabal --version cabal-install version 1.22.2.0 using version 1.22.2.0 of the Cabal library $ clang --version Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) Target: x86_64-apple-darwin14.3.0 Thread model: posix OS X version 10.10.3 Installed from home-brew and Haskell for Mac OS X both have the same problem. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 19:49:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 19:49:05 -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.eb0e62845ede42c76da5a73ab4c60f4e@haskell.org> #10068: Make the runtime reflection API for names, modules, locations more systematic -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gridaphobe): * cc: gridaphobe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 19:51:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 19:51:40 -0000 Subject: [GHC] #10256: parser: API Annotations : guardquals1 does not annotate commas properly (was: parser: API Annotations : squals does not annotate commas properly) In-Reply-To: <044.8484e8ecf97da86fae5e843371f60830@haskell.org> References: <044.8484e8ecf97da86fae5e843371f60830@haskell.org> Message-ID: <059.ebe85e736a128726b6be2dd44afd080d@haskell.org> #10256: parser: API Annotations : guardquals1 does not annotate commas properly -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by alanz: Old description: > The `squals` production includes > > {{{ > | squals ',' qual > {% addAnnotation (gl $ head $ unLoc $1) AnnComma (gl $2) >> > return (sLL $1 $> ($3 : unLoc $1)) } > }}} > > The `AnnComma` should be attached to `(gl $ last $ unLoc $1)`, rather > than the head. New description: The `guardquals1` production includes {{{ : guardquals1 ',' qual {% addAnnotation (gl $ last $ unLoc $1) AnnComma (gl $2) >> return (sLL $1 $> ($3 : unLoc $1)) } }}} The `AnnComma` should be attached to `(gl $ head $ unLoc $1)`, rather than last. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 19:51:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 19:51:41 -0000 Subject: [GHC] #10209: parser: opt_kind_sig has incorrect SrcSpan In-Reply-To: <044.4df35a96b087f820c01c3c57f4238bf6@haskell.org> References: <044.4df35a96b087f820c01c3c57f4238bf6@haskell.org> Message-ID: <059.93f2c28d7948843396812ae6e965f9d7@haskell.org> #10209: parser: opt_kind_sig has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D813 -------------------------------------+------------------------------------- Comment (by jstolarek): My two cents: this part of the parser will be touched by Phab:D202 once it is merged. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 19:54:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 19:54:36 -0000 Subject: [GHC] #10148: Optimization causes repeated computation In-Reply-To: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> References: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> Message-ID: <058.340048643d805a1d8a18bd2f733f2230@haskell.org> #10148: Optimization causes repeated computation -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | stranal/should_run/T10148 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => stranal/should_run/T10148 * milestone: => 7.10.2 Comment: Thank you akio and Joachim for your help in tracking this one down. Austin: please merge. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 20:02:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 20:02:14 -0000 Subject: [GHC] #10256: parser: API Annotations : guardquals1 does not annotate commas properly In-Reply-To: <044.8484e8ecf97da86fae5e843371f60830@haskell.org> References: <044.8484e8ecf97da86fae5e843371f60830@haskell.org> Message-ID: <059.b56ac735526780c1838edce72ba4eb49@haskell.org> #10256: parser: API Annotations : guardquals1 does not annotate commas properly -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D818 -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D818 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 20:02:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 20:02:38 -0000 Subject: [GHC] #10260: last uses too much space with optimizations disabled Message-ID: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> #10260: last uses too much space with optimizations disabled -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.1 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I know we don't worry too much about performance when optimizations are disabled, but `last [1..n]` using O(n) space when the naive definition would run in O(1) space is a bit too much I think. Can we split out the new definition to a separate function and use a rule to rewrite `last` to that function when optimizations are enabled? I'm not expert enough on the use of rules and inlining phases etc. to write the patch myself, but I think it should be simple. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 20:03:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 20:03:58 -0000 Subject: [GHC] #10247: 5x increase in total memory allocation for `prof-doc-fib` test since 2011 In-Reply-To: <045.d8aaa0bc0f02908f22bf1b71ccb674d4@haskell.org> References: <045.d8aaa0bc0f02908f22bf1b71ccb674d4@haskell.org> Message-ID: <060.75638973445e2b83d22b39c71a715b69@haskell.org> #10247: 5x increase in total memory allocation for `prof-doc-fib` test since 2011 -------------------------------------+------------------------------------- Reporter: thomie | Owner: Type: task | Status: closed Priority: high | Milestone: Component: Profiling | Version: 7.10.1 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => worksforme Comment: I filed the `last` issue as #10260 so I'm going to close this--would really be nice to record more information about those prof.sample files though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 20:05:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 20:05:25 -0000 Subject: [GHC] #10148: Optimization causes repeated computation In-Reply-To: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> References: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> Message-ID: <058.cfc6b9cb7d6d43fcb3778e128ae02514@haskell.org> #10148: Optimization causes repeated computation -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | stranal/should_run/T10148 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): PS: on Linux I did not see the big compiler perf changes which I did on Windows. Mysterious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 20:07:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 20:07:52 -0000 Subject: [GHC] #10260: last uses too much space with optimizations disabled In-Reply-To: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> References: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> Message-ID: <062.31eae0a5acf0f54d06b5136f529db204@haskell.org> #10260: last uses too much space with optimizations disabled -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > I know we don't worry too much about performance when optimizations are > disabled, but `last [1..n]` using O(n) space when the naive definition > would run in O(1) space is a bit too much I think. > > Can we split out the new definition to a separate function and use a rule > to rewrite `last` to that function when optimizations are enabled? I'm > not expert enough on the use of rules and inlining phases etc. to write > the patch myself, but I think it should be simple. New description: I know we don't worry too much about performance when optimizations are disabled, but `last [1..n]` using O(n) space when the naive definition would run in O(1) space is a bit too much I think. Can we split out the new definition to a separate function and use a rule to rewrite `last` to that function when optimizations are enabled? I'm not expert enough on the use of rules and inlining phases etc. to write the patch myself, but I think it should be simple. This showed up when investigating #10247 -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 20:09:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 20:09:38 -0000 Subject: [GHC] #10260: last uses too much space with optimizations disabled In-Reply-To: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> References: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> Message-ID: <062.1ff1da1ea9a86b8e36b5cbef9b9f69a0@haskell.org> #10260: last uses too much space with optimizations disabled -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): What is the "new definition"? I'm pretty hazy about what exactly you are proposing here. Could you write it out explicitly and then the Core Libraries Committee can decide. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 20:14:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 20:14:53 -0000 Subject: [GHC] #10261: Don't build runghc if we don't have GhcWithInterpreter Message-ID: <047.dfa917e245584a02acef03b6e546904f@haskell.org> #10261: Don't build runghc if we don't have GhcWithInterpreter -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- On configurations with GhcWithInterpreter=NO, we should not build runghc (since it will never work), and especially not install runghc/runhaskell scripts/symlinks when the system might already have another working runhaskell (e.g., Hugs). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 21:07:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 21:07:38 -0000 Subject: [GHC] #10256: parser: API Annotations : guardquals1 does not annotate commas properly In-Reply-To: <044.8484e8ecf97da86fae5e843371f60830@haskell.org> References: <044.8484e8ecf97da86fae5e843371f60830@haskell.org> Message-ID: <059.1f5788f20ba8b7a5f7c4c648b6739347@haskell.org> #10256: parser: API Annotations : guardquals1 does not annotate commas properly -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D818 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 21:31:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 21:31:17 -0000 Subject: [GHC] #10262: Improve documentation of module signatures Message-ID: <047.d5f9e11a25bfdcf531f13050a898429b@haskell.org> #10262: Improve documentation of module signatures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.11 Documentation | Operating System: Unknown/Multiple Keywords: backpack | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Out of curiosity, I read the bit in the user manual about the new module signatures, and I find the text a little confusing. Could those in the know clarify the points below in the manual? Thanks! * (typo) The first example refers to `String.hs`. I think you mean `Text.hs`. * Is there a way to use module signatures to deal with mutually recursive modules? The example with `TextSig` seems to require that both `Text` and `TextSig` are compiled before `A`. * Could you provide an example of specifying multiple signature/implementation pairs with `--make`? * The manual says that the dialect of Haskell used in signature files is "essentially" the same as with hs-boot files. Are there any differences? * The most recent paragraph addition doesn't make sense to me, starting with "Signatures can be installed like ordinary modules". What do you mean by "installed"? What does it mean to bring multiple signatures into scope by the same name? Can two signatures have the same name? Wouldn't their filenames also need to be the same? * Is there currently any facility available to have multiple implementations of one signature? Of course, this is all work in progress, and I don't necessarily expect an immediate fix. But, when it's nearing completion, it may be worth revisiting this stretch of text. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 21:31:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 21:31:26 -0000 Subject: [GHC] #10218: GHC creates incorrect code which throws <> In-Reply-To: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> References: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> Message-ID: <061.5541a8550359f0cb20ced6ec7a8ea19e@haskell.org> #10218: GHC creates incorrect code which throws <> -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: yes Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by AlexET): Running late demand analysis does seem to fix this. I am now pretty sure this is a problem with cse and demand. There seems to be two ways to fix it. Either drop demand information on variables involved in cse or somehow infer the correct demand information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 22:03:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 22:03:26 -0000 Subject: [GHC] #10218: GHC creates incorrect code which throws <> In-Reply-To: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> References: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> Message-ID: <061.e154043735757332fb9242677d9a0488@haskell.org> #10218: GHC creates incorrect code which throws <> -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: yes Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): OK good. Can you also try `-fno-cse`. I guess that too will fix it. I would still ''really'' like to know how the incorrect demand info leads to a loop. I still don't understand that. I wonder if adding some `trace` calls might help show what is going on, without making the bug disappear? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 22:32:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 22:32:17 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDIxNjogQWxsb3cgYXJyIOKIpyAoZmlyc3Qg?= =?utf-8?q?=E2=88=A8_=28***=29=29_as_minimal_definition_of_Arrow_?= =?utf-8?q?instance?= In-Reply-To: <048.64b271a00a46843da0df000240882f80@haskell.org> References: <048.64b271a00a46843da0df000240882f80@haskell.org> Message-ID: <063.3768433b8556fe673381aca82b127b50@haskell.org> #10216: Allow arr ? (first ? (***)) as minimal definition of Arrow instance -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by strake888: Old description: New description: Add default definitions of `first`, `second` in terms of `(***)` to let one define an `Arrow` instance in terms of `(***)` rather than `first`, which is sometimes more elegant. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 22:38:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 22:38:55 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICMxMDIxNjogQWxsb3cgYXJyIOKIpyAoZmlyc3Qg?= =?utf-8?q?=E2=88=A8_=28***=29=29_as_minimal_definition_of_Arrow_?= =?utf-8?q?instance?= In-Reply-To: <048.64b271a00a46843da0df000240882f80@haskell.org> References: <048.64b271a00a46843da0df000240882f80@haskell.org> Message-ID: <063.8bbec0d60cf13b8d06f1243aa38c5e3f@haskell.org> #10216: Allow arr ? (first ? (***)) as minimal definition of Arrow instance -------------------------------------+------------------------------------- Reporter: strake888 | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by strake888): Replying to [comment:3 simonpj]: > Perhaps add comments in the code to explain subtleties? I'm not sure what is subtle here; you mean any subtleties in particular? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 22:57:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 22:57:18 -0000 Subject: [GHC] #10232: versionedAppDir ignores projectVersion from DynFlags In-Reply-To: <044.192b03678e7009d8d199d6157ad48aaf@haskell.org> References: <044.192b03678e7009d8d199d6157ad48aaf@haskell.org> Message-ID: <059.d4907d8bc9e2ff650864eb0cc46ad714@haskell.org> #10232: versionedAppDir ignores projectVersion from DynFlags -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by luite): * milestone: => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 7 23:22:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 07 Apr 2015 23:22:33 -0000 Subject: [GHC] #10218: GHC creates incorrect code which throws <> In-Reply-To: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> References: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> Message-ID: <061.4dbf751fd874dff0b65c53a78eca9239@haskell.org> #10218: GHC creates incorrect code which throws <> -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: yes Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): OK I think I have it. * There is a dictionary thunk thus (in STG syntax): {{{ let { $dA_s7fS [Dmd=] :: Main.A t_a2qQ [LclId, Str=DmdType] = \s srt:SRT:[] [] Main.$p1C $dC_s7fP; } in }}} Note that it claims to be single-entry. But in fact it is used twice, due to CSE. * Because it is single-entry, it is not updated when evaluation is complete. * But, with eager blackholing, it ''is'' blackholed on entry, I think in an effort to kill off any space leak. * So the second use finds the black hole, and reports `<>`. I was very puzzled because `<>` usually only arises from a `letrec` that is too strict, like `rec { x = 1+x }`. But the single-entry thing explains it. So, now we understand why Alex's guess is right: the CSE pass is failing to update (or zap) the demand info for the shared things, and that causes something to be single-entry when it should not be. Next: fix it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 01:55:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 01:55:51 -0000 Subject: [GHC] #10263: Role annotation should never be ambiguous Message-ID: <045.9af8436dde3df6d4df68ec603758d4b7@haskell.org> #10263: Role annotation should never be ambiguous -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ [ezyang at hs01 ghc-backpack]$ cat A.hs {-# LANGUAGE RoleAnnotations #-} module A where data Maybe a = AF type role Maybe representational [ezyang at hs01 ghc-backpack]$ ghc -c A.hs A.hs:4:11: Ambiguous occurrence ?Maybe? It could refer to either ?A.Maybe?, defined at A.hs:3:1 or ?Prelude.Maybe?, imported from ?Prelude? at A.hs:2:8 (and originally defined in ?GHC.Base?) }}} This is silly because roles can only ever be defined with the declaration, so only one reference makes sense. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 03:31:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 03:31:47 -0000 Subject: [GHC] #10264: AArch64 : Installing 7.10.1 fails Message-ID: <044.73aa6628849c2f0907bb73b896adc3cc@haskell.org> #10264: AArch64 : Installing 7.10.1 fails -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Built 7.10.1 from the release tarball, using ghc-7.6.3 from Debian. Build of the compiler goes fine, but when I install it I get: {{{ "inplace/bin/ghc-cabal" register libraries/ghc-prim dist-install \ "/home/erikd/GHC/7.10.1/lib/ghc-7.10.1/bin/ghc" \ "/home/erikd/GHC/7.10.1/lib/ghc-7.10.1/bin/ghc-pkg" \ "/home/erikd/GHC/7.10.1/lib/ghc-7.10.1" '' '/home/erikd/GHC/7.10.1' \ '/home/erikd/GHC/7.10.1/lib/ghc-7.10.1' \ '/home/erikd/GHC/7.10.1/share/doc/ghc/html/libraries' NO Warning: cannot determine version of /home/erikd/GHC/7.10.1/lib/ghc-7.10.1/bin/ghc-pkg : "" ghc-cabal: libraries/Cabal/Cabal/Distribution/Simple/GHC.hs:1050:5-47: Irrefutable pattern failed for pattern Data.Maybe.Just ver }}} The code in question is: {{{#!hs hcPkgInfo :: ProgramConfiguration -> HcPkg.HcPkgInfo hcPkgInfo conf = HcPkg.HcPkgInfo { HcPkg.hcPkgProgram = ghcPkgProg , HcPkg.noPkgDbStack = v < [6,9] , HcPkg.noVerboseFlag = v < [6,11] , HcPkg.flagPackageConf = v < [7,5] , HcPkg.useSingleFileDb = v < [7,9] } where v = versionBranch ver Just ghcPkgProg = lookupProgram ghcPkgProgram conf Just ver = programVersion ghcPkgProg }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 03:33:34 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 03:33:34 -0000 Subject: [GHC] #10264: AArch64 : Installing 7.10.1 fails In-Reply-To: <044.73aa6628849c2f0907bb73b896adc3cc@haskell.org> References: <044.73aa6628849c2f0907bb73b896adc3cc@haskell.org> Message-ID: <059.ef052d17bee2e5ede3ac7c3054e77890@haskell.org> #10264: AArch64 : Installing 7.10.1 fails -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * failure: None/Unknown => Installing GHC failed * milestone: => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 03:44:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 03:44:52 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.21e2145b25ce2cf31c15f0f5576de091@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: ryan.gl.scott@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 04:18:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 04:18:23 -0000 Subject: [GHC] #10259: HPC code coverage fails In-Reply-To: <051.5eb6d52bae1ecbfd49110a391027e287@haskell.org> References: <051.5eb6d52bae1ecbfd49110a391027e287@haskell.org> Message-ID: <066.652c1248caded75549729160b4276f8e@haskell.org> #10259: HPC code coverage fails -------------------------------------+------------------------------------- Reporter: LukeHoersten | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: hpc Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by LukeHoersten): I was able to reproduce this on 7.8.4 as well. The error is slightly different though: hpc: can not find text-1.2.0.4/Data.Text.Unsafe in ["./.hpc","./dist/hpc/prof/mix/project-0.1.0.0","./dist/hpc/prof/mix/project"] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 04:19:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 04:19:58 -0000 Subject: [GHC] #10264: AArch64 : Installing 7.10.1 fails In-Reply-To: <044.73aa6628849c2f0907bb73b896adc3cc@haskell.org> References: <044.73aa6628849c2f0907bb73b896adc3cc@haskell.org> Message-ID: <059.bd9b72bda210d05d96be5abebc8224c5@haskell.org> #10264: AArch64 : Installing 7.10.1 fails -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): This part looks ok! {{{ /home/erikd/GHC/7.10.1/lib/ghc-7.10.1/bin/ghc-pkg --version GHC package manager version 7.10.1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 05:03:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 05:03:04 -0000 Subject: [GHC] #10265: HEAD fails with -DDEBUG Message-ID: <046.893757ca1ff4bbbc22a56712ffe52487@haskell.org> #10265: HEAD fails with -DDEBUG -------------------------------------+------------------------------------- Reporter: dalaing | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- With the following errors: compiler/main/Packages.hs:1269:11: Not in scope: data constructor ?ASSERT? compiler/main/Packages.hs:1271:11: Not in scope: data constructor ?ASSERT? compiler/main/Packages.hs:1286:11: Not in scope: data constructor ?ASSERT? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 05:03:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 05:03:27 -0000 Subject: [GHC] #10265: HEAD fails with -DDEBUG In-Reply-To: <046.893757ca1ff4bbbc22a56712ffe52487@haskell.org> References: <046.893757ca1ff4bbbc22a56712ffe52487@haskell.org> Message-ID: <061.3a440a5ecf4a569d14086c47e171c0ef@haskell.org> #10265: HEAD fails with -DDEBUG -------------------------------------+------------------------------------- Reporter: dalaing | Owner: dalaing Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by dalaing): * owner: => dalaing -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 05:08:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 05:08:39 -0000 Subject: [GHC] #10265: HEAD fails with -DDEBUG In-Reply-To: <046.893757ca1ff4bbbc22a56712ffe52487@haskell.org> References: <046.893757ca1ff4bbbc22a56712ffe52487@haskell.org> Message-ID: <061.d0f20df7072dc511d5e47907c66b1f74@haskell.org> #10265: HEAD fails with -DDEBUG -------------------------------------+------------------------------------- Reporter: dalaing | Owner: dalaing Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D821 -------------------------------------+------------------------------------- Changes (by dalaing): * status: new => patch * differential: => Phab:D821 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 05:14:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 05:14:28 -0000 Subject: [GHC] #10265: HEAD fails with -DDEBUG In-Reply-To: <046.893757ca1ff4bbbc22a56712ffe52487@haskell.org> References: <046.893757ca1ff4bbbc22a56712ffe52487@haskell.org> Message-ID: <061.4ab71c481ca8f6b160da0d1754ff0f6e@haskell.org> #10265: HEAD fails with -DDEBUG -------------------------------------+------------------------------------- Reporter: dalaing | Owner: dalaing Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D821 -------------------------------------+------------------------------------- Changes (by dalaing): * failure: None/Unknown => Building GHC failed * os: Unknown/Multiple => MacOS X -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 07:37:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 07:37:24 -0000 Subject: [GHC] #10254: parser : the API annotation on opt_sig is being discarded In-Reply-To: <044.a5d202689c44d12743acba1f8d07ab48@haskell.org> References: <044.a5d202689c44d12743acba1f8d07ab48@haskell.org> Message-ID: <059.ca256b7f7b502d4541c042e3a72dae94@haskell.org> #10254: parser : the API annotation on opt_sig is being discarded -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D822 -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D822 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 07:41:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 07:41:55 -0000 Subject: [GHC] #10261: Don't build runghc if we don't have GhcWithInterpreter In-Reply-To: <047.dfa917e245584a02acef03b6e546904f@haskell.org> References: <047.dfa917e245584a02acef03b6e546904f@haskell.org> Message-ID: <062.962062198a4891fe79307f8739ec2f08@haskell.org> #10261: Don't build runghc if we don't have GhcWithInterpreter -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 07:51:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 07:51:22 -0000 Subject: [GHC] #10263: Role annotation should never be ambiguous In-Reply-To: <045.9af8436dde3df6d4df68ec603758d4b7@haskell.org> References: <045.9af8436dde3df6d4df68ec603758d4b7@haskell.org> Message-ID: <060.6e3e9543aa39b932c1b0753ac401ff27@haskell.org> #10263: Role annotation should never be ambiguous -------------------------------------+------------------------------------- Reporter: ezyang | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => goldfire Comment: You are quite right. I have not looked into how role annotations are renamed, but presumably they are rather like signatures. For those we use `RnEnv.lookupSigOccRn`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 08:01:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 08:01:01 -0000 Subject: [GHC] #9160: Panic: Template variable unbound in rewrite rule In-Reply-To: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> References: <045.cda94ec6e6410fff035f0639058b2886@haskell.org> Message-ID: <060.b9fd93d1e89247505f5e6f326bda3c62@haskell.org> #9160: Panic: Template variable unbound in rewrite rule -------------------------------------+------------------------------------- Reporter: mietek | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.3 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | indexed_types/should_fail/T9160 Related Tickets: #4524 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Well, comment:10 claims that GHC 7.8.3 couldn't compile `singletons`. However I've confirmed that HEAD can compile `singletons-1.1`, so yes, I'll close this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 08:26:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 08:26:12 -0000 Subject: [GHC] #10265: HEAD fails on OS X (was: HEAD fails with -DDEBUG) In-Reply-To: <046.893757ca1ff4bbbc22a56712ffe52487@haskell.org> References: <046.893757ca1ff4bbbc22a56712ffe52487@haskell.org> Message-ID: <061.ddb65584c16b7aed6e497e816fcc14cf@haskell.org> #10265: HEAD fails on OS X -------------------------------------+------------------------------------- Reporter: dalaing | Owner: dalaing Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D821 -------------------------------------+------------------------------------- Description changed by dalaing: Old description: > With the following errors: > > compiler/main/Packages.hs:1269:11: > Not in scope: data constructor ?ASSERT? > > compiler/main/Packages.hs:1271:11: > Not in scope: data constructor ?ASSERT? > > compiler/main/Packages.hs:1286:11: > Not in scope: data constructor ?ASSERT? New description: Failed for -DDEBUG builds initially, but also turned out it was failing to validate. The failure produced the following errors: compiler/main/Packages.hs:1269:11: Not in scope: data constructor ?ASSERT? compiler/main/Packages.hs:1271:11: Not in scope: data constructor ?ASSERT? compiler/main/Packages.hs:1286:11: Not in scope: data constructor ?ASSERT? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 08:26:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 08:26:52 -0000 Subject: [GHC] #10266: Split base for Backpack Message-ID: <045.81e58b6e2b97dd039d014c76c016ea80@haskell.org> #10266: Split base for Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: | Version: 7.11 libraries/base | Operating System: Unknown/Multiple Keywords: backpack | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Let's resurrect #1338 and #1580. Our new concrete goal is to have users be able to replace 'base' with 'base-sig', which is some signature representing the modules from 'base' which we depend on. Since 'base' is a big, complicated package, the ability to specify subsets of 'base' is very useful: it can be used to define things like Haskell'98 base, base without any unsafe operations, etc. Right now, all wired in things live in ghc-prim (I believe). This is good, since we can't reasonably abstract wired in things away with a signature: GHC will always put them in some well-known place. However, this is not enough: there are many known-key/Rdr things the compiler knows about too, which need to be placed in specific package + module locations for GHC to be able to reference them; e.g. when deriving instances, etc. At the moment, most of these identifiers live in 'base', which is no good. So, here's the proposal: all non-rebindable GHC-known identifiers (as per PrelNames) should be moved to ghc-prim (or perhaps a new package? I don't really care either way) and reexported from the old packages which they were available from base. I'll try to work out in detail what moves, how to avoid orphan instances, etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 08:29:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 08:29:47 -0000 Subject: [GHC] #10266: Split base for Backpack In-Reply-To: <045.81e58b6e2b97dd039d014c76c016ea80@haskell.org> References: <045.81e58b6e2b97dd039d014c76c016ea80@haskell.org> Message-ID: <060.288bd43d65ee50d5fab71c37f524774f@haskell.org> #10266: Split base for Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by ezyang: Old description: > Let's resurrect #1338 and #1580. Our new concrete goal is to have users > be able to replace 'base' with 'base-sig', which is some signature > representing the modules from 'base' which we depend on. Since 'base' is > a big, complicated package, the ability to specify subsets of 'base' is > very useful: it can be used to define things like Haskell'98 base, base > without any unsafe operations, etc. > > Right now, all wired in things live in ghc-prim (I believe). This is > good, since we can't reasonably abstract wired in things away with a > signature: GHC will always put them in some well-known place. However, > this is not enough: there are many known-key/Rdr things the compiler > knows about too, which need to be placed in specific package + module > locations for GHC to be able to reference them; e.g. when deriving > instances, etc. > > At the moment, most of these identifiers live in 'base', which is no > good. So, here's the proposal: all non-rebindable GHC-known identifiers > (as per PrelNames) should be moved to ghc-prim (or perhaps a new package? > I don't really care either way) and reexported from the old packages > which they were available from base. I'll try to work out in detail what > moves, how to avoid orphan instances, etc. New description: Let's resurrect #1338 and #1580. Our new concrete goal is to have users be able to replace 'base' with 'base-sig', which is some signature representing the modules from 'base' which we depend on. Since 'base' is a big, complicated package, the ability to specify subsets of 'base' is very useful: it can be used to define things like Haskell'98 base, base without any unsafe operations, etc. Right now, all wired in things live in ghc-prim (I believe). This is good, since we can't reasonably abstract wired in things away with a signature: GHC will always put them in some well-known place. However, this is not enough: there are many known-key/Rdr things the compiler knows about too, which need to be placed in specific package + module locations for GHC to be able to reference them; e.g. when deriving instances, etc. At the moment, most of these identifiers live in 'base', which is no good: even if we make base sig abstract, GHC will still go right ahead and try to use a specific implementation of base. So, here's the proposal: all non-rebindable GHC-known identifiers (as per PrelNames) should be moved to ghc-prim (or perhaps a new package? I don't really care either way) and reexported from the old packages which they were available from base. The further upshot is base now truly can have an implementation replaced: ghc- prim is the ONLY package which must be used verbatim (since GHC hardcodes to it.) I'll try to work out in detail what moves, how to avoid orphan instances, etc. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 08:31:40 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 08:31:40 -0000 Subject: [GHC] #10265: HEAD fails to compile on OS X (was: HEAD fails on OS X) In-Reply-To: <046.893757ca1ff4bbbc22a56712ffe52487@haskell.org> References: <046.893757ca1ff4bbbc22a56712ffe52487@haskell.org> Message-ID: <061.f44c6fccf72c856c1e6a41d289a4ac2b@haskell.org> #10265: HEAD fails to compile on OS X -------------------------------------+------------------------------------- Reporter: dalaing | Owner: dalaing Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D821 -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 08:44:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 08:44:18 -0000 Subject: [GHC] #8030: FlexibleContexts PolyKinds Type Families bug In-Reply-To: <042.54ee6c0fdb0fba6e2b8357f8ae0511fe@haskell.org> References: <042.54ee6c0fdb0fba6e2b8357f8ae0511fe@haskell.org> Message-ID: <057.9bc281d311f0fef856abc6ffe049bb12@haskell.org> #8030: FlexibleContexts PolyKinds Type Families bug -------------------------------------+------------------------------------- Reporter: wvv | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #8034 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"53cc9af94122866aaae751f94f83ce7b940e5494/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="53cc9af94122866aaae751f94f83ce7b940e5494" Test Trac #8030 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 08:44:49 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 08:44:49 -0000 Subject: [GHC] #8030: FlexibleContexts PolyKinds Type Families bug In-Reply-To: <042.54ee6c0fdb0fba6e2b8357f8ae0511fe@haskell.org> References: <042.54ee6c0fdb0fba6e2b8357f8ae0511fe@haskell.org> Message-ID: <057.daac47c3dbf0e3b006f25b4589005ced@haskell.org> #8030: FlexibleContexts PolyKinds Type Families bug -------------------------------------+------------------------------------- Reporter: wvv | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | typecheck/should_fail/T8030 Related Tickets: #8034 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => typecheck/should_fail/T8030 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 09:48:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 09:48:33 -0000 Subject: [GHC] #10254: parser : the API annotation on opt_sig is being discarded In-Reply-To: <044.a5d202689c44d12743acba1f8d07ab48@haskell.org> References: <044.a5d202689c44d12743acba1f8d07ab48@haskell.org> Message-ID: <059.55f2e238519cf50029ed07ed7c89026e@haskell.org> #10254: parser : the API annotation on opt_sig is being discarded -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D822 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 09:56:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 09:56:23 -0000 Subject: [GHC] #10255: API Annotations : ExprWithTySig processing discards annotated spans In-Reply-To: <044.3995d3b4b19bd7e56b8289f8de527db1@haskell.org> References: <044.3995d3b4b19bd7e56b8289f8de527db1@haskell.org> Message-ID: <059.72a6714ffa750722b0fe32d8b943fcf5@haskell.org> #10255: API Annotations : ExprWithTySig processing discards annotated spans -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D823 -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D823 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 10:20:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 10:20:16 -0000 Subject: [GHC] #10267: Add support for typed holes in Template Haskell Message-ID: <048.c1c64a1e465638edb9cc6eb9b5affa9b@haskell.org> #10267: Add support for typed holes in Template Haskell -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I want to be able to work with typed holes using Template Haskell. These are currently rejected: {{{#!hs [d| i :: a -> a i x = _ |] }}} {{{ Expression form not (yet) handled by Template Haskell _ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 11:03:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 11:03:32 -0000 Subject: [GHC] #10267: Add support for typed holes in Template Haskell In-Reply-To: <048.c1c64a1e465638edb9cc6eb9b5affa9b@haskell.org> References: <048.c1c64a1e465638edb9cc6eb9b5affa9b@haskell.org> Message-ID: <063.d8612d8e74366d77ff7ae6dff152c7ae@haskell.org> #10267: Add support for typed holes in Template Haskell -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by jstolarek): * owner: => jstolarek -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 11:49:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 11:49:42 -0000 Subject: [GHC] #10268: ApiAnnotations : quoted type variables missing leading quote Message-ID: <044.7f87ca00076e0696584b5c734a247e24@haskell.org> #10268: ApiAnnotations : quoted type variables missing leading quote -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The `HsOpTy` can be constructed for a promoted type operator, in which case it has the following form {{{ | btype SIMPLEQUOTE qconop type { sLL $1 $> $ mkHsOpTy $1 $3 $4 } | btype SIMPLEQUOTE varop type { sLL $1 $> $ mkHsOpTy $1 $3 $4 } }}} The SIMPLEQUOTE does not get an annotation, so cannot be reproduced via the API Annotations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 11:55:36 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 11:55:36 -0000 Subject: [GHC] #10114: Kind mismatches with AnyK in rank-2 types In-Reply-To: <042.b276c0a2c2e93f214c57d6cb2cc81838@haskell.org> References: <042.b276c0a2c2e93f214c57d6cb2cc81838@haskell.org> Message-ID: <057.fd2654a0417f47c2ba01e4252c0d9c3d@haskell.org> #10114: Kind mismatches with AnyK in rank-2 types -------------------------------------+------------------------------------- Reporter: cam | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): NB the [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide /kind-polymorphism.html rule for kind generalisation in 7.8.2 of the user manual]. {{{ f1 :: (forall a. Proxy a) -> Int -- Means f :: forall k. (forall (a:k). Proxy k a) -> Int f2 :: (forall (a::k). Proxy a) -> Int -- Means f :: (forall k. forall (a:k). Proxy k a) -> Int }}} (Richard's new branch, which collapses types and kinds, allows explicit kind quantification, so we can then control this more explicitly.) So maybe the same should be true for `T`: {{{ type T = forall f a. f a -- Means type T k = forall (f::k->*) (a::k). f a type T = forall f (a::k). f a -- Means type T = forall k (f::k->*) (a::k). f a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 12:33:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 12:33:12 -0000 Subject: [GHC] #10114: Kind mismatches with AnyK in rank-2 types In-Reply-To: <042.b276c0a2c2e93f214c57d6cb2cc81838@haskell.org> References: <042.b276c0a2c2e93f214c57d6cb2cc81838@haskell.org> Message-ID: <057.c89853e0946df9b94c5093289b905244@haskell.org> #10114: Kind mismatches with AnyK in rank-2 types -------------------------------------+------------------------------------- Reporter: cam | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Current BUG (HEAD, 7.10) {{{ type T = forall (f :: k -> k2) (a::k). f a }}} Compile with `-fprint-explicit-kinds -ddump-types -XRankNTypes -XPolyKinds` {{{ TYPE CONSTRUCTORS type T (k2 :: BOX) = forall (k :: BOX) (k1 :: BOX) (f :: k -> k1) (a :: k). f a }}} But this elaborated `T` simply doesn't have a sensible kind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 12:38:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 12:38:23 -0000 Subject: [GHC] #10268: ApiAnnotations : quoted type variables missing leading quote In-Reply-To: <044.7f87ca00076e0696584b5c734a247e24@haskell.org> References: <044.7f87ca00076e0696584b5c734a247e24@haskell.org> Message-ID: <059.a87bbc771ad5fe982924631669eb018a@haskell.org> #10268: ApiAnnotations : quoted type variables missing leading quote -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by alanz: Old description: > The `HsOpTy` can be constructed for a promoted type operator, in which > case it has the following form > > {{{ > | btype SIMPLEQUOTE qconop type { sLL $1 $> $ mkHsOpTy $1 $3 > $4 } > | btype SIMPLEQUOTE varop type { sLL $1 $> $ mkHsOpTy $1 $3 > $4 } > }}} > > The SIMPLEQUOTE does not get an annotation, so cannot be reproduced via > the API Annotations. New description: The `HsOpTy` can be constructed for a promoted type operator, in which case it has the following form {{{ | btype SIMPLEQUOTE qconop type { sLL $1 $> $ mkHsOpTy $1 $3 $4 } | btype SIMPLEQUOTE varop type { sLL $1 $> $ mkHsOpTy $1 $3 $4 } }}} The SIMPLEQUOTE does not get an annotation, so cannot be reproduced via the API Annotations. Also, in {{{ splice_exp :: { LHsExpr RdrName } : TH_ID_SPLICE { sL1 $1 $ mkHsSpliceE (sL1 $1 $ HsVar (mkUnqual varName (getTH_ID_SPLICE $1))) } | '$(' exp ')' {% ams (sLL $1 $> $ mkHsSpliceE $2) [mo $1,mc $3] } | TH_ID_TY_SPLICE { sL1 $1 $ mkHsSpliceTE (sL1 $1 $ HsVar (mkUnqual varName (getTH_ID_TY_SPLICE $1))) } | '$$(' exp ')' {% ams (sLL $1 $> $ mkHsSpliceTE $2) [mo $1,mc $3] } }}} the `TH_ID_SPLICE` and `TH_ID_TY_SPLICE` positions are lost. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 13:34:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 13:34:06 -0000 Subject: [GHC] #10232: versionedAppDir ignores projectVersion from DynFlags In-Reply-To: <044.192b03678e7009d8d199d6157ad48aaf@haskell.org> References: <044.192b03678e7009d8d199d6157ad48aaf@haskell.org> Message-ID: <059.e2b0aeaba894d63739d8cd3a00cc37a8@haskell.org> #10232: versionedAppDir ignores projectVersion from DynFlags -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D824 -------------------------------------+------------------------------------- Changes (by luite): * status: new => patch * differential: => Phab:D824 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 14:11:56 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 14:11:56 -0000 Subject: [GHC] #10268: ApiAnnotations : quoted type variables missing leading quote In-Reply-To: <044.7f87ca00076e0696584b5c734a247e24@haskell.org> References: <044.7f87ca00076e0696584b5c734a247e24@haskell.org> Message-ID: <059.38f2995b06f948525cc8a05fd6b22898@haskell.org> #10268: ApiAnnotations : quoted type variables missing leading quote -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D825 -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D825 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 15:39:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 15:39:27 -0000 Subject: [GHC] #10269: ApiAnnotations : RdrHsSyn.isFunLhs discards parentheses Message-ID: <044.c829a8ccbd4a0502d00b1e225b04f036@haskell.org> #10269: ApiAnnotations : RdrHsSyn.isFunLhs discards parentheses -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The RdrHsSyn.isFunLhs function has the following {{{#!hs isFunLhs e = go e [] where go (L loc (HsVar f)) es | not (isRdrDataCon f) = return (Just (L loc f, False, es)) go (L _ (HsApp f e)) es = go f (e:es) go (L _ (HsPar e)) es@(_:_) = go e es }}} The treatment of `HsPar` means that any parentheses around an infix function will be discarded. e.g. {{{#!hs (f =*= g) sa i = f (toF sa i) =^= g (toG sa i) }}} will lose the `(` before `f` and the closing one after `g` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 16:09:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 16:09:30 -0000 Subject: [GHC] #10269: ApiAnnotations : RdrHsSyn.isFunLhs discards parentheses In-Reply-To: <044.c829a8ccbd4a0502d00b1e225b04f036@haskell.org> References: <044.c829a8ccbd4a0502d00b1e225b04f036@haskell.org> Message-ID: <059.5be54352dec763e097b7709b7743a4e0@haskell.org> #10269: ApiAnnotations : RdrHsSyn.isFunLhs discards parentheses -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by alanz): See `RdrHsSyn.checkTyClHdr` for an example of how to handle this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 16:35:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 16:35:54 -0000 Subject: [GHC] #10259: HPC code coverage fails In-Reply-To: <051.5eb6d52bae1ecbfd49110a391027e287@haskell.org> References: <051.5eb6d52bae1ecbfd49110a391027e287@haskell.org> Message-ID: <066.670d366f92b4be6d6566ffb2e9e8c683@haskell.org> #10259: HPC code coverage fails -------------------------------------+------------------------------------- Reporter: LukeHoersten | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: hpc Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by LukeHoersten): Turns out this was my fault: Using --enable-coverage on cabal install was causing deps to get included in the mix file but for some reason no tix were being generated for the deps. Either way, I did not want deps to be tested for coverage. Is this correct behavior that using --enable-coverage on cabal install should include deps in the mix file? It seems like that is never correct and for someone only using 'cabal install' it will never work for them. Also, it's unclear to me when to use -fhpc vs. --enable-coverage. Is there anywhere this is documented? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 17:30:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 17:30:35 -0000 Subject: [GHC] #10259: HPC code coverage fails In-Reply-To: <051.5eb6d52bae1ecbfd49110a391027e287@haskell.org> References: <051.5eb6d52bae1ecbfd49110a391027e287@haskell.org> Message-ID: <066.9797a697ff5929cda4d7cc24cefc8022@haskell.org> #10259: HPC code coverage fails -------------------------------------+------------------------------------- Reporter: LukeHoersten | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: invalid | Keywords: hpc Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by LukeHoersten): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 18:12:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 18:12:01 -0000 Subject: [GHC] #10270: inconsistent semantics of type class instance visibility outside recursive modules Message-ID: <046.f680b68172950f0c3de20daf82432978@haskell.org> #10270: inconsistent semantics of type class instance visibility outside recursive modules -------------------------------------+------------------------------------- Reporter: skilpat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: x86_64 | Type of failure: GHC rejects (amd64) | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When you have an instance defined in a module that's part of a recursive module loop, when should modules outside the loop see it? Right now, GHC behaves differently depending on whether it's in batch or in single-shot compilation mode. Which one is correct? Dunno! Here's the example (code at the bottom). The gist is that you have two modules A and B that define data types T and U, respectively, which depend on each other, so A and B are recursive modules and we need a boot file -- say, for A. Now suppose we define an instance Eq T in the implementation of A but not in the boot file. B imports the boot file, so it doesn't know about this instance. And then I have some third module, Main, outside the loop, which imports only B. And now the central question: ''Does Main know about the Eq T defined in A?'' We can test how GHC answers this question by defining an (orphan) instance for Eq T in Main. In batch compilation mode, Main is rejected for defining a duplicate instance. In single-shot compilation mode, however, Main is accepted and any equality test in Main uses the locally defined instance; i.e., B doesn't know about A's Eq T and so neither does Main. So which is correct? If you ask me, the latter semantics is correct, but I can see why the former might be argued as well (e.g., according to the fixed-point semantics of import/export described in (1)). In any case, the semantics between the two compilation modes should probably agree, right? {{{#!hs -- A.hs-boot module A where data T -- a mutually recursive data type, along with B.U t :: T -- some value to test for Eq in Main -- B.hs module B(module A, module B) where -- export A.{T,t} since Main doesn't import A import {-# SOURCE #-} A -- mutually recursive data type across modules data U = U | UT T -- A.hs module A where import B -- mutually recursive data type across modules data T = T | TU U -- the true instance instance Eq T where _ == _ = True -- some value to test Eq instance in Main t :: T t = T -- Main.hs module Main where import B -- no import of A -- an orphan instance for Eq T. -- okay in one-shot mode; not okay in batch (--make) mode instance Eq T where _ == _ = False -- in one-shot mode, this prints False main = putStrLn $ show $ t == t }}} Commands and output for batch mode: {{{ $ ghc --make Main [1 of 4] Compiling A[boot] ( A.hs-boot, A.o-boot ) [2 of 4] Compiling B ( B.hs, B.o ) [3 of 4] Compiling A ( A.hs, A.o ) [4 of 4] Compiling Main ( Main.hs, Main.o ) A.hs:8:10: Duplicate instance declarations: instance Eq T -- Defined at A.hs:8:10 instance Eq T -- Defined at Main.hs:7:10 }}} Commands and output for single-shot mode: {{{ $ ghc -c A.hs-boot $ ghc -c B.hs $ ghc -c A.hs $ ghc -c Main.hs $ ghc A.o B.o Main.o -o main $ ./main False }}} Tested on GHC 7.6.3, 7.8.3, and 7.10.1. (1) ''A Formal Specification for the Haskell 98 Module System''. Iavor S. Diatchki, Mark P. Jones, and Thomas Hallgren. Haskell '02. http://web.cecs.pdx.edu/~mpj/pubs/hsmods.pdf -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 18:31:29 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 18:31:29 -0000 Subject: [GHC] #9965: getChanContents BlockedIndefinitelyOnMVar on 7.10 RC1 In-Reply-To: <048.6b5c6098010f0774bb9a0a6fd07b5609@haskell.org> References: <048.6b5c6098010f0774bb9a0a6fd07b5609@haskell.org> Message-ID: <063.fdc02bc3ab6817043e5947af53e12c13@haskell.org> #9965: getChanContents BlockedIndefinitelyOnMVar on 7.10 RC1 -------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => fixed Comment: Works for me with 7.10 RC 2 and 7.10.1, highly likely to have been a result of #9949. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 18:39:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 18:39:10 -0000 Subject: [GHC] #10265: HEAD fails to compile on OS X In-Reply-To: <046.893757ca1ff4bbbc22a56712ffe52487@haskell.org> References: <046.893757ca1ff4bbbc22a56712ffe52487@haskell.org> Message-ID: <061.4b89eb066121264cd91e5941571331de@haskell.org> #10265: HEAD fails to compile on OS X -------------------------------------+------------------------------------- Reporter: dalaing | Owner: dalaing Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D821 -------------------------------------+------------------------------------- Comment (by Reid Barton ): In [changeset:"6b96eeb72a17e35c59830952732170d29d99a598/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6b96eeb72a17e35c59830952732170d29d99a598" Fixes a compiler error with -DDEBUG (#10265) Test Plan: validate Reviewers: austin, ezyang, erikd, rwbarton Reviewed By: ezyang, erikd, rwbarton Subscribers: erikd, thomie Differential Revision: https://phabricator.haskell.org/D821 GHC Trac Issues: #10265 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 18:41:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 18:41:14 -0000 Subject: [GHC] #10265: HEAD fails to compile on OS X In-Reply-To: <046.893757ca1ff4bbbc22a56712ffe52487@haskell.org> References: <046.893757ca1ff4bbbc22a56712ffe52487@haskell.org> Message-ID: <061.2697ed125bf57c75d488a5ae96ec28d0@haskell.org> #10265: HEAD fails to compile on OS X -------------------------------------+------------------------------------- Reporter: dalaing | Owner: dalaing Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D821 -------------------------------------+------------------------------------- Changes (by rwbarton): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 18:51:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 18:51:50 -0000 Subject: [GHC] #10228: Increased memory usage with GHC 7.10.1 In-Reply-To: <048.689dfbc555185e5a975e80819cf26fc7@haskell.org> References: <048.689dfbc555185e5a975e80819cf26fc7@haskell.org> Message-ID: <063.fac87b039158bb62c329a4d0dd876842@haskell.org> #10228: Increased memory usage with GHC 7.10.1 -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): The type of behavior you describe is not totally unexpected since when GHC compiles multiple modules in a single run, it retains the information read from all the interface files it has encountered in case it needs that information later. So it's a time/space trade-off, not really a memory leak. Of course, it's possible that that interface file information is consuming much more space than it needs to. (Or the cause could be something else entirely.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 18:53:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 18:53:04 -0000 Subject: [GHC] #10261: Don't build runghc if we don't have GhcWithInterpreter In-Reply-To: <047.dfa917e245584a02acef03b6e546904f@haskell.org> References: <047.dfa917e245584a02acef03b6e546904f@haskell.org> Message-ID: <062.fc027022593787c0bb111bc76d3e77fa@haskell.org> #10261: Don't build runghc if we don't have GhcWithInterpreter -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Build System | Version: 7.10.1 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * keywords: => newcomer Comment: This might be quite easy, or not. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 19:09:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 19:09:42 -0000 Subject: [GHC] #10124: Simple case analyses generate too many branches In-Reply-To: <046.a2efb21732640768a877c0ce17a28486@haskell.org> References: <046.a2efb21732640768a877c0ce17a28486@haskell.org> Message-ID: <061.2b249ccbbf8c019682639226a9c5aea2@haskell.org> #10124: Simple case analyses generate too many branches -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6135, | Differential Revisions: #9661,#10137 | -------------------------------------+------------------------------------- Comment (by rwbarton): This benchmark does quite a lot of allocation, unless that changes in HEAD (I tested with 7.10.1). It would be better for microbenchmarking purposes to avoid all the allocation. Anyways I would expect the original to be a bit faster for this particular microbenchmark, since the branches will all be predicted correctly and a predicted branch is basically free. It might be a different matter with `concat (replicate 100000000 ['\001'..'z'])`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 19:14:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 19:14:16 -0000 Subject: [GHC] #10159: cabal build/ghc compiler causes sudden hard reboot of my computer! In-Reply-To: <046.f6a8819131c1ac525f6581f5be865c05@haskell.org> References: <046.f6a8819131c1ac525f6581f5be865c05@haskell.org> Message-ID: <061.2189108d8ae544fb2f9196b60c200d78@haskell.org> #10159: cabal build/ghc compiler causes sudden hard reboot of my computer! ---------------------------------+----------------------------------------- Reporter: jamshid | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Changes (by rwbarton): * status: new => infoneeded Comment: Maybe build with `-v3` and point a 60 FPS camera at the screen while the build runs? :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 19:21:05 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 19:21:05 -0000 Subject: [GHC] #10270: inconsistent semantics of type class instance visibility outside recursive modules In-Reply-To: <046.f680b68172950f0c3de20daf82432978@haskell.org> References: <046.f680b68172950f0c3de20daf82432978@haskell.org> Message-ID: <061.6d9e49996ba450afd5c360e80f55fcc4@haskell.org> #10270: inconsistent semantics of type class instance visibility outside recursive modules -------------------------------------+------------------------------------- Reporter: skilpat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): This is probably due to the retypecheck loop: {{{ See bug #930. This code fixes a long-standing bug in --make. The problem is that when compiling the modules *inside* a loop, a data type that is only defined at the top of the loop looks opaque; but after the loop is done, the structure of the data type becomes apparent. The difficulty is then that two different bits of code have different notions of what the data type looks like. The idea is that after we compile a module which also has an .hs-boot file, we re-generate the ModDetails for each of the modules that depends on the .hs-boot file, so that everyone points to the proper TyCons, Ids etc. defined by the real module, not the boot module. Fortunately re-generating a ModDetails from a ModIface is easy: the function TcIface.typecheckIface does exactly that. Picking the modules to re-typecheck is slightly tricky. Starting from the module graph consisting of the modules that have already been compiled, we reverse the edges (so they point from the imported module to the importing module), and depth-first-search from the .hs-boot node. This gives us all the modules that depend transitively on the .hs-boot module, and those are exactly the modules that we need to re-typecheck. Following this fix, GHC can compile itself with --make -O2. }}} As a side effect, the instances also get dragged in. In one-shot mode, we use a different mechanism, the `tcg_type_env_var`, to ensure we can deal with the recursive case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 19:42:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 19:42:31 -0000 Subject: [GHC] #10124: Simple case analyses generate too many branches In-Reply-To: <046.a2efb21732640768a877c0ce17a28486@haskell.org> References: <046.a2efb21732640768a877c0ce17a28486@haskell.org> Message-ID: <061.4c0497db7608e65284b6a4ee5d79c970@haskell.org> #10124: Simple case analyses generate too many branches -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6135, | Differential Revisions: #9661,#10137 | -------------------------------------+------------------------------------- Comment (by rwbarton): Oh, I needed a `{-# NOINLINE myIsSpace #-}` to avoid the allocation, interesting... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 19:54:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 19:54:58 -0000 Subject: [GHC] #10209: parser: opt_kind_sig has incorrect SrcSpan In-Reply-To: <044.4df35a96b087f820c01c3c57f4238bf6@haskell.org> References: <044.4df35a96b087f820c01c3c57f4238bf6@haskell.org> Message-ID: <059.813e52a032dba80eed6cee47f7c2b431@haskell.org> #10209: parser: opt_kind_sig has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D813 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 19:56:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 19:56:50 -0000 Subject: [GHC] #9562: Type families + hs-boot files = unsafeCoerce In-Reply-To: <047.0928965f4d9302995273a5c9d11eab3c@haskell.org> References: <047.0928965f4d9302995273a5c9d11eab3c@haskell.org> Message-ID: <062.acd056b13eea0e16e2a4392b04a6930d@haskell.org> #9562: Type families + hs-boot files = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #10270 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * related: => #10270 Comment: I think #10270 is related -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 19:57:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 19:57:21 -0000 Subject: [GHC] #10255: API Annotations : ExprWithTySig processing discards annotated spans In-Reply-To: <044.3995d3b4b19bd7e56b8289f8de527db1@haskell.org> References: <044.3995d3b4b19bd7e56b8289f8de527db1@haskell.org> Message-ID: <059.84057a8463867cf1f04eaf9a139211a7@haskell.org> #10255: API Annotations : ExprWithTySig processing discards annotated spans -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D823 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 19:57:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 19:57:35 -0000 Subject: [GHC] #10270: inconsistent semantics of type class instance visibility outside recursive modules In-Reply-To: <046.f680b68172950f0c3de20daf82432978@haskell.org> References: <046.f680b68172950f0c3de20daf82432978@haskell.org> Message-ID: <061.c469feaa4471030107e917acf11dcfa0@haskell.org> #10270: inconsistent semantics of type class instance visibility outside recursive modules -------------------------------------+------------------------------------- Reporter: skilpat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9562 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * related: => #9562 Comment: I think #9562 is related. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 19:58:40 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 19:58:40 -0000 Subject: [GHC] #10268: ApiAnnotations : quoted type variables missing leading quote In-Reply-To: <044.7f87ca00076e0696584b5c734a247e24@haskell.org> References: <044.7f87ca00076e0696584b5c734a247e24@haskell.org> Message-ID: <059.d1635bf281379464530744b15211931f@haskell.org> #10268: ApiAnnotations : quoted type variables missing leading quote -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D825 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 21:22:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 21:22:55 -0000 Subject: [GHC] #10270: inconsistent semantics of type class instance visibility outside recursive modules In-Reply-To: <046.f680b68172950f0c3de20daf82432978@haskell.org> References: <046.f680b68172950f0c3de20daf82432978@haskell.org> Message-ID: <061.955315aa0b7a8d7d050b330af9b71fbc@haskell.org> #10270: inconsistent semantics of type class instance visibility outside recursive modules -------------------------------------+------------------------------------- Reporter: skilpat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9562 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I rather agree that the one-shot story is the right one. And yes, the two should agree. Edward I recall that we had extensive discussion about how to arrange that the right instances are in scope. We had a New Plan; but (a) I have forgotten the plan and (b) I'm not sure whether it was ever implemented. Can you remind me? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 21:24:29 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 21:24:29 -0000 Subject: [GHC] #9562: Type families + hs-boot files = unsafeCoerce In-Reply-To: <047.0928965f4d9302995273a5c9d11eab3c@haskell.org> References: <047.0928965f4d9302995273a5c9d11eab3c@haskell.org> Message-ID: <062.5ac2d728a1faf8531ef8d9fd9415be2f@haskell.org> #9562: Type families + hs-boot files = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #10270 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * cc: ezyang (added) Comment: Edward, you are familiar with this territory. Is this bug something you might look at? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 21:38:36 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 21:38:36 -0000 Subject: [GHC] #10270: inconsistent semantics of type class instance visibility outside recursive modules In-Reply-To: <046.f680b68172950f0c3de20daf82432978@haskell.org> References: <046.f680b68172950f0c3de20daf82432978@haskell.org> Message-ID: <061.8ba28208f2ba9a33b9d83a693b55604e@haskell.org> #10270: inconsistent semantics of type class instance visibility outside recursive modules -------------------------------------+------------------------------------- Reporter: skilpat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: GHC rejects | (amd64) valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9562 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): The plan was for orphan instances, to check if any given instance was in the set of orphan modules which are transitively imported from this module. We did implement it. Unfortunately, this doesn't directly help here because the instance in A.hs is NOT an orphan, so we just assume that it's in scope. So in some sense, this is the same problem that we were grappling with hsigs: sometimes, a non-orphan instance should NOT be visible, because it was not defined in the hs-boot/hsig file. We ''also'' spent a bit of time thinking about how to solve this, but all of our solutions boiled down to some variant of "put the set of transitively imported modules (including non- orphan modules)" into the interface, with various schemes for optimizing this since this results in quadratic growth of interface files. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 21:48:52 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 21:48:52 -0000 Subject: [GHC] #10267: Add support for typed holes in Template Haskell In-Reply-To: <048.c1c64a1e465638edb9cc6eb9b5affa9b@haskell.org> References: <048.c1c64a1e465638edb9cc6eb9b5affa9b@haskell.org> Message-ID: <063.34def818697d83f755bea91299b14d02@haskell.org> #10267: Add support for typed holes in Template Haskell -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): By all means add typed holes. Should not be hard. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 21:52:53 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 21:52:53 -0000 Subject: [GHC] #10266: Split base for Backpack In-Reply-To: <045.81e58b6e2b97dd039d014c76c016ea80@haskell.org> References: <045.81e58b6e2b97dd039d014c76c016ea80@haskell.org> Message-ID: <060.71f94ab8b79ef296808447effbe1c618@haskell.org> #10266: Split base for Backpack -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): It'd be good to keep Luite and Joachim in the loop as they had been the biggest proponents of split base in the first place and intended to lead the charge from the core libraries committee front. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 22:30:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 22:30:41 -0000 Subject: [GHC] #10234: Validate fails on armhf In-Reply-To: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> References: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> Message-ID: <059.b0b870e02807e1016f02a059e0081f24@haskell.org> #10234: Validate fails on armhf -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: llvm Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * owner: => erikd Comment: Currently testing a patch for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 22:31:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 22:31:30 -0000 Subject: [GHC] #10271: Typed Template Haskell splice difficulty when resolving overloading Message-ID: <046.badc08a7987a9ad09aee9fd76d6b2f30@haskell.org> #10271: Typed Template Haskell splice difficulty when resolving overloading -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- J Garrett Morris describes the following surprising behaviour for typed Template Haskell {{{ {-# LANGUAGE TemplateHaskell, FlexibleInstances #-} module PrintfLib where import Language.Haskell.TH class Printf t where printf :: String -> Q (TExp String) -> Q (TExp t) instance Printf [Char] where tf s t | '%' `notElem` s = [|| $$t ++ s ||] | otherwise = fail ("Unexpected format %" ++ [c]) where (_, _:c:_) = break ('%' ==) s instance Printf t => Printf (Char -> t) where printf s t | c /= 'c' = fail ("Unexpected format %" ++ [c] ++ " for character") | otherwise = [|| \c -> $$(printf s'' [|| $$t ++ s' ++ [c] ||]) ||] where (s', '%':c:s'') = break ('%' ==) s ------------------------- {-# LANGUAGE TemplateHaskell #-} module Printf where import PrintfLib f :: Char -> String f = $$(printf "foo %c" [||""||]) h :: Char -> String h y = $$(printf "foo %c" [||""||]) y }}} Oddly, `f` typechecks but `h` does not, even though `h` is just an eta- expanded version of `f`: {{{ Printf.hs:9:10: No instance for (Printf t0) arising from a use of ?printf? The type variable ?t0? is ambiguous Note: there are several potential instances: instance Printf t => Printf (Char -> t) -- Defined in ?PrintfLib? instance Printf [Char] -- Defined in ?PrintfLib? In the expression: printf "foo %c" [|| "" ||] }}} What is going on? Here's the deal * To run the splice, GHC must solve any constraints that arise form the expression `(printf "foo %c" ...)`. * Since `printf` is overloaded, and overloaded on its result type, the type needed by the context of the splice is what determines which instance of `Printf` is needed. * In `f` the context needs `Char -> String`, and so the call to `printf` must have type `TExpr (Char -> String)`, so we get the constraint `Printf (Char -> String)` which we can solve. * But in `h` the rule for application tries to ''infer'' a type for the splice. So the context for the call just says `TExp t0` for some unification variable `t0`; and that leads to the insoluble constraint. You may say that GHC should be cleverer, and push that type signature information into the application. And perhaps it should. But you can never win. For example: {{{ hard x = [ $$(printf "gluk" [|| "" ||]), undefined :: Char -> String ] }}} Here the RHS of `hard` is a 2-element list. Since all elements of a list have the same type, the splice must have the same type as the second element of the list, namely `Char->String`. But seeing that would mean that we'd have to typecheck right-to-left. In general GHC tries very very hard NOT to depend on traveral order. There is no way in general to ensure that we have all the information now that constraint solving may ultimately produce. I'm not sure what to do about this. * It seldom matters, because resolving the overloading on the splice seldom depends on the result type. * When it does matter, you can fix it by giving a type signature to the splice itself. But it seems unsatisfactory. Ideas welcome. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 22:32:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 22:32:23 -0000 Subject: [GHC] #10234: armhf : Validate fails during bindisttest configure (was: Validate fails on armhf) In-Reply-To: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> References: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> Message-ID: <059.152cca5f933c1487fa127c18ab8e3957@haskell.org> #10234: armhf : Validate fails during bindisttest configure -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: llvm Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 22:32:34 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 22:32:34 -0000 Subject: [GHC] #10271: Typed Template Haskell splice difficulty when resolving overloading In-Reply-To: <046.badc08a7987a9ad09aee9fd76d6b2f30@haskell.org> References: <046.badc08a7987a9ad09aee9fd76d6b2f30@haskell.org> Message-ID: <061.3fb7363c7dce5c3268d3285e38b4a011@haskell.org> #10271: Typed Template Haskell splice difficulty when resolving overloading -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > J Garrett Morris describes the following surprising > behaviour for typed Template Haskell > {{{ > {-# LANGUAGE TemplateHaskell, FlexibleInstances #-} > module PrintfLib where > import Language.Haskell.TH > > class Printf t where > printf :: String -> Q (TExp String) -> Q (TExp t) > > instance Printf [Char] where > tf s t | '%' `notElem` s = [|| $$t ++ s ||] > | otherwise = fail ("Unexpected format %" > ++ [c]) > where (_, _:c:_) = break ('%' ==) s > > instance Printf t => Printf (Char -> t) where > printf s t > | c /= 'c' = fail ("Unexpected format %" ++ [c] ++ > " for character") > | otherwise = [|| \c -> $$(printf s'' > [|| $$t ++ s' ++ [c] ||]) > ||] > where (s', '%':c:s'') = break ('%' ==) s > > ------------------------- > {-# LANGUAGE TemplateHaskell #-} > module Printf where > import PrintfLib > > f :: Char -> String > f = $$(printf "foo %c" [||""||]) > > h :: Char -> String > h y = $$(printf "foo %c" [||""||]) y > }}} > Oddly, `f` typechecks but `h` does not, even though `h` is just an eta- > expanded version of `f`: > {{{ > Printf.hs:9:10: > No instance for (Printf t0) arising from a use of ?printf? > The type variable ?t0? is ambiguous > Note: there are several potential instances: > instance Printf t => Printf (Char -> t) -- Defined in ?PrintfLib? > instance Printf [Char] -- Defined in ?PrintfLib? > In the expression: printf "foo %c" [|| "" ||] > }}} > What is going on? Here's the deal > > * To run the splice, GHC must solve any constraints that arise form the > expression `(printf "foo %c" ...)`. > * Since `printf` is overloaded, and overloaded on its result type, the > type needed by the context of the splice is what determines which > instance of `Printf` is needed. > * In `f` the context needs `Char -> String`, and so the call to `printf` > must have type `TExpr (Char -> String)`, so we get the constraint `Printf > (Char -> String)` which we can solve. > * But in `h` the rule for application tries to ''infer'' a type for the > splice. So the context for the call just says `TExp t0` for some > unification variable `t0`; and that leads to the insoluble constraint. > > You may say that GHC should be cleverer, and push that type signature > information into the application. And perhaps it should. But you can > never win. For example: > {{{ > hard x = [ $$(printf "gluk" [|| "" ||]), undefined :: Char -> String ] > }}} > Here the RHS of `hard` is a 2-element list. Since all elements of a list > have the same type, > the splice must have the same type as the second element of the list, > namely `Char->String`. But seeing that would mean that we'd have to > typecheck right-to-left. In general GHC tries very very hard NOT to > depend on traveral order. There is no way in general to ensure that we > have all the information now that constraint solving may ultimately > produce. > > I'm not sure what to do about this. > * It seldom matters, because resolving the overloading on the splice > seldom depends on the result type. > * When it does matter, you can fix it by giving a type signature to the > splice itself. > But it seems unsatisfactory. Ideas welcome. New description: J Garrett Morris describes the following surprising behaviour for typed Template Haskell {{{ {-# LANGUAGE TemplateHaskell, FlexibleInstances #-} module PrintfLib where import Language.Haskell.TH class Printf t where printf :: String -> Q (TExp String) -> Q (TExp t) instance Printf [Char] where tf s t | '%' `notElem` s = [|| $$t ++ s ||] | otherwise = fail ("Unexpected format %" ++ [c]) where (_, _:c:_) = break ('%' ==) s instance Printf t => Printf (Char -> t) where printf s t | c /= 'c' = fail ("Unexpected format %" ++ [c] ++ " for character") | otherwise = [|| \c -> $$(printf s'' [|| $$t ++ s' ++ [c] ||]) ||] where (s', '%':c:s'') = break ('%' ==) s ------------------------- {-# LANGUAGE TemplateHaskell #-} module Printf where import PrintfLib f :: Char -> String f = $$(printf "foo %c" [||""||]) h :: Char -> String h y = $$(printf "foo %c" [||""||]) y }}} Oddly, `f` typechecks but `h` does not, even though `h` is just an eta- expanded version of `f`: {{{ Printf.hs:9:10: No instance for (Printf t0) arising from a use of ?printf? The type variable ?t0? is ambiguous Note: there are several potential instances: instance Printf t => Printf (Char -> t) -- Defined in ?PrintfLib? instance Printf [Char] -- Defined in ?PrintfLib? In the expression: printf "foo %c" [|| "" ||] }}} What is going on? Here's the deal * To run the splice, GHC must solve any constraints that arise form the expression `(printf "foo %c" ...)`. * Since `printf` is overloaded, and overloaded on its result type, the type needed by the context of the splice is what determines which instance of `Printf` is needed. * In `f` the context needs `Char -> String`, and so the call to `printf` must have type `TExpr (Char -> String)`, so we get the constraint `Printf (Char -> String)` which we can solve. * But in `h` the rule for application tries to ''infer'' a type for the splice. So the context for the call just says `TExp t0` for some unification variable `t0`; and that leads to the insoluble constraint. You may say that GHC should be cleverer, and push that type signature information into the application. And perhaps it should. But you can never win. For example: {{{ hard x = [ $$(printf "gluk" [|| "" ||]), undefined :: Char -> String ] }}} Here the RHS of `hard` is a 2-element list. Since all elements of a list have the same type, the splice must have the same type as the second element of the list, namely `Char->String`. But seeing that would mean that we'd have to typecheck right-to-left. In general GHC tries very very hard NOT to depend on traversal order. There is no way in general to ensure that we have all the information now that constraint solving may ultimately produce. I'm not sure what to do about this. * It seldom matters, because resolving the overloading on the splice seldom depends on the result type. * When it does matter, you can fix it by giving a type signature to the splice itself. But it seems unsatisfactory. Ideas welcome. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 23:34:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 23:34:54 -0000 Subject: [GHC] #10272: hsc2hs : directive let cannot be handled in cross-compilation mode Message-ID: <044.8913742417593b59443e51343d8c3d48@haskell.org> #10272: hsc2hs : directive let cannot be handled in cross-compilation mode -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: hsc2hs | Version: 7.11 Keywords: cross- | Operating System: Unknown/Multiple compiling | Type of failure: Building GHC Architecture: | failed Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #10070 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Attempting to cross-compile from linux to windows (after an in-progress fix to #10070) and ran into: {{{ libraries/haskeline/System/Console/Haskeline/Backend/Win32.hsc:170 directive let cannot be handled in cross-compilation mode }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 23:35:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 23:35:23 -0000 Subject: [GHC] #10070: Cross compiling from Linux to Windows fails with mising Win32 library In-Reply-To: <044.c3a265d6b6d17d46b973ed2b3e37c5c7@haskell.org> References: <044.c3a265d6b6d17d46b973ed2b3e37c5c7@haskell.org> Message-ID: <059.c75a53affe1c8aac5705c926d47f76ba@haskell.org> #10070: Cross compiling from Linux to Windows fails with mising Win32 library -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: cross- Operating System: Unknown/Multiple | compiling Type of failure: Building GHC | Architecture: failed | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #10272 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * related: => #10272 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 23:46:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 23:46:22 -0000 Subject: [GHC] #10273: haskeline : Cross-compile from Linux to Windows fails due to Message-ID: <044.16994f6a5932b910b77581b817b33330@haskell.org> #10273: haskeline : Cross-compile from Linux to Windows fails due to -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: libraries | Version: 7.11 (other) | Operating System: Unknown/Multiple Keywords: | Type of failure: Building GHC Architecture: | failed Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #10070 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The #include of doesn't work when cross-compiling from Linux to Windows because the Linux file system is case sensitive and on Linux the file is . Down casing the name of this include file should not cause problems on Windows as the Windows file system is case insensitive. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 8 23:47:19 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 08 Apr 2015 23:47:19 -0000 Subject: [GHC] #10273: haskeline : Cross-compile from Linux to Windows fails due to In-Reply-To: <044.16994f6a5932b910b77581b817b33330@haskell.org> References: <044.16994f6a5932b910b77581b817b33330@haskell.org> Message-ID: <059.c1d6eae89a72b304086c05788b8e007c@haskell.org> #10273: haskeline : Cross-compile from Linux to Windows fails due to -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: libraries | Version: 7.11 (other) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10070 | -------------------------------------+------------------------------------- Changes (by erikd): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 04:59:59 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 04:59:59 -0000 Subject: [GHC] #10274: foreign import ccall "rand" in System.IO fails on Android Message-ID: <047.c01313c49328bdb7ebd948eb990c1812@haskell.org> #10274: foreign import ccall "rand" in System.IO fails on Android -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.1 Libraries | Operating System: Other Keywords: | Type of failure: Building GHC Architecture: | failed Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- On Android `rand` is a static inline function. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 05:01:55 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 05:01:55 -0000 Subject: [GHC] #10274: foreign import ccall "rand" in System.IO fails on Android In-Reply-To: <047.c01313c49328bdb7ebd948eb990c1812@haskell.org> References: <047.c01313c49328bdb7ebd948eb990c1812@haskell.org> Message-ID: <062.e0e08cdf868ddfb2f67f3b29e97a4a6f@haskell.org> #10274: foreign import ccall "rand" in System.IO fails on Android -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Other | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D826 -------------------------------------+------------------------------------- Changes (by rwbarton): * differential: => Phab:D826 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 05:17:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 05:17:51 -0000 Subject: [GHC] #10264: AArch64 : Installing 7.10.1 fails In-Reply-To: <044.73aa6628849c2f0907bb73b896adc3cc@haskell.org> References: <044.73aa6628849c2f0907bb73b896adc3cc@haskell.org> Message-ID: <059.16bf2ecc8de42623b3a7c118a8c2cade@haskell.org> #10264: AArch64 : Installing 7.10.1 fails -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Installing GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * status: new => closed * resolution: => duplicate Comment: This is a duplicate of #9673. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 05:19:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 05:19:38 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.c6cc535a12be2f102cd46919bb70bcc2@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by erikd): Closed #10264 as a duplicate of this. Tracked it down to somewhere in the `process` library. Debugging continues. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 05:23:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 05:23:08 -0000 Subject: [GHC] #10272: hsc2hs : directive let cannot be handled in cross-compilation mode In-Reply-To: <044.8913742417593b59443e51343d8c3d48@haskell.org> References: <044.8913742417593b59443e51343d8c3d48@haskell.org> Message-ID: <059.95b128550f70d315c67332d9b5181aec@haskell.org> #10272: hsc2hs : directive let cannot be handled in cross-compilation mode -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: hsc2hs | Version: 7.11 Resolution: | Keywords: cross- Operating System: Unknown/Multiple | compiling Type of failure: Building GHC | Architecture: failed | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #10070 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Well, it can't, but this should work fine instead. {{{ instance Storable Coord where sizeOf _ = (#size COORD) alignment _ = (#const offsetof(struct {char x__; COORD (y__); }, y__)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 05:54:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 05:54:18 -0000 Subject: [GHC] #10275: LLVM/cross-compilation fixes to be backported Message-ID: <047.198f43801006c337c216b389cb955d85@haskell.org> #10275: LLVM/cross-compilation fixes to be backported -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'd like to have these fixes backported so that ghc-android will be able to build on 7.10.2 without having to duplicate patches that already exist in HEAD. The patches I needed are: - Phab:D597 - Phab:D683 - Phab:D745 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 05:54:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 05:54:31 -0000 Subject: [GHC] #10275: LLVM/cross-compilation fixes to be backported In-Reply-To: <047.198f43801006c337c216b389cb955d85@haskell.org> References: <047.198f43801006c337c216b389cb955d85@haskell.org> Message-ID: <062.b0b64030b76caf526517bfa2029f4f31@haskell.org> #10275: LLVM/cross-compilation fixes to be backported -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Build System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 05:55:19 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 05:55:19 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.df3435eb5e28fa291cb7372f0f5d1ff2@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by erikd): Have a tiny test program (trimmed down version of `Distribution.Simple.Utils.rawSystemStdInOut` running the problem arguments) as follows: {{{#! hs import System.IO import System.Exit ( ExitCode(..) ) import Control.Concurrent import Control.Monad import Control.Exception (evaluate, finally) import System.Environment import System.Process main :: IO () main = do [path] <- getArgs -- "/home/erikd/GHC/7.11/bin/ghc-pkg" -- "/usr/bin /ghc-pkg" runInteractiveProcess path ["--version"] Nothing Nothing >>= \(inh,outh,errh,pid) -> do err <- hGetContents errh out <- hGetContents outh mv <- newEmptyMVar let force str = (evaluate (length str) >> return ()) `finally` putMVar mv () --TODO: handle exceptions like text decoding. _ <- forkIO $ force out _ <- forkIO $ force err -- wait for both to finish, in either order takeMVar mv takeMVar mv -- wait for the program to terminate exitcode <- waitForProcess pid unless (exitcode == ExitSuccess) $ print $ path ++ " returned " ++ show exitcode ++ if null err then "" else " with error message:\n" ++ err print (out, err, exitcode) }}} Compiling and running this in a couple of different ways results in some interesting results: {{{ $ /usr/bin/ghc-7.6.3 --make test.hs -o prog && ./prog /usr/bin/ghc-pkg Linking prog ... ("GHC package manager version 7.6.3\n","",ExitSuccess) $ /usr/bin/ghc-7.6.3 --make test.hs -o prog && \ ./prog /home/erikd/GHC/7.11/bin/ghc-pkg ("","",ExitSuccess) }}} This may be an output encoding issue as the `TODO` warning in the code warns about. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 06:49:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 06:49:25 -0000 Subject: [GHC] #10148: Optimization causes repeated computation In-Reply-To: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> References: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> Message-ID: <058.da7a799163b219bf2fc1b1f3408a9ac7@haskell.org> #10148: Optimization causes repeated computation -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | stranal/should_run/T10148 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 06:49:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 06:49:53 -0000 Subject: [GHC] #10148: Optimization causes repeated computation In-Reply-To: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> References: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> Message-ID: <058.4de781a011200abf749711b89dcb2d53@haskell.org> #10148: Optimization causes repeated computation -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | stranal/should_run/T10148 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 07:10:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 07:10:39 -0000 Subject: [GHC] #10276: ApiAnnotations : ITopenExpQuote needs SourceText Message-ID: <044.2a289d9c9e324d361db842bc55632f22@haskell.org> #10276: ApiAnnotations : ITopenExpQuote needs SourceText -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In the lexer, `ITopenExpQuote` can be recognised for '[e|' or '[|'. The token definition needs to capture the original `SourceText`, and pass it through to `ExpBr`, which also needs a `SrcText` field. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 07:59:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 07:59:39 -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.3f07adce783da4d36434d522b9bccf59@haskell.org> #8827: Inferring Safe mode with GeneralizedNewtypeDeriving is wrong -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: 8226, 8745 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): The GHC 7.6 user manual [https://downloads.haskell.org/~ghc/7.6.3/docs/html/users_guide/safe- haskell.html#safe-language used to say]: ''GeneralizedNewtypeDeriving ? It can be used to violate constructor access control, by allowing untrusted code to manipulate protected data types in ways the data type author did not intend, breaking invariants they have established.''. But that was removed in [https://downloads.haskell.org/~ghc/7.8.2/docs/html/users_guide/safe- haskell.html#safe-language the 7.8 user manual], which seems to contradict the conclusion in comment:36. Would someone like to fix the manual to say what it should say, whatever that now is? See [https://mail.haskell.org/pipermail/haskell- cafe/2015-April/118970.html this Haskell Cafe thread]. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 08:45:17 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 08:45:17 -0000 Subject: [GHC] #10277: ApiAnnotations : lexer discards comment close in nested comment Message-ID: <044.23b3ff5c4f760c1e4ecc1ce3ba0c35c5@haskell.org> #10277: ApiAnnotations : lexer discards comment close in nested comment -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When parsing a nested comment, such as {{{#!hs {- {- nested comment -} {-# nested pragma #-} -} }}} The lexer returns the comment annotation as {{{#!hs {- {- nested comment {-# nested pragma # -} }}} Restore the missing comment end markers in the annotation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 08:47:46 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 08:47:46 -0000 Subject: [GHC] #10234: armhf : Validate fails during bindisttest configure In-Reply-To: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> References: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> Message-ID: <059.6bc1e7648bc889b4ea44c949bfb12756@haskell.org> #10234: armhf : Validate fails during bindisttest configure -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: llvm Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: ?Phab:D828 -------------------------------------+------------------------------------- Changes (by erikd): * differential: => ?Phab:D828 Comment: The patch in ?Phab:828 validates fine (ie successfully builds the binary- dist) on both amd64-linux and armhf-linux. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 09:08:34 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 09:08:34 -0000 Subject: [GHC] #10278: ApiAnnotations : Nested forall loses forall annotation Message-ID: <044.1731f429fad7dec49ad689a5b7ccbeb0@haskell.org> #10278: ApiAnnotations : Nested forall loses forall annotation -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When parsing {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} extremumNewton :: forall tag. forall tag1. tag -> tag1 -> Int extremumNewton = undefined }}} The parser attaches an `AnnForall` to the second `forall`, which appears as a nested `HsForAllTy`. Somewhere this nesting is flattened, and the tyvarbndrs are collapsed into a single `HsForAllTy`. In this process the second `AnnForAll` loses its anchor in the AST. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 10:14:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 10:14:06 -0000 Subject: [GHC] #10279: panic on haskell-src-exts Message-ID: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: | Owner: throwaway123 | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Linux Keywords: | Type of failure: Compile-time Architecture: x86_64 | crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Compiling `Bug.hs`: {{{ {-# LANGUAGE QuasiQuotes #-} import Language.Haskell.Exts.QQ (dec) main :: IO () main = return () where foo = [dec| bar = 3 |] }}} by `ghc --make -v -dcore-lint Bug.hs` gives {{{ ghc --make -v -dcore-lint Bug.hs Glasgow Haskell Compiler, Version 7.10.1, stage 2 booted by GHC version 7.8.4 Using binary package database: /usr/lib/ghc-7.10.1/package.conf.d/package.cache wired-in package ghc-prim mapped to ghc- prim-0.4.0.0-7c945cc0c41d3b7b70f3edd125671166 wired-in package integer-gmp mapped to integer- gmp-1.0.0.0-3c947e5fb6dca14804d9b2793c521b67 wired-in package base mapped to base-4.8.0.0-1b689eb8d72c4d4cc88f445839c1f01a wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.10.0.0-e895139a0ffff267d412e3d0191ce93b wired-in package ghc mapped to ghc-7.10.1-325809317787a897b7a97d646ceaa3a3 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-7c945cc0c41d3b7b70f3edd125671166 wired-in package integer-gmp mapped to integer- gmp-1.0.0.0-3c947e5fb6dca14804d9b2793c521b67 wired-in package base mapped to base-4.8.0.0-1b689eb8d72c4d4cc88f445839c1f01a wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.10.0.0-e895139a0ffff267d412e3d0191ce93b wired-in package ghc mapped to ghc-7.10.1-325809317787a897b7a97d646ceaa3a3 wired-in package dph-seq not found. wired-in package dph-par not found. *** Chasing dependencies: Chasing modules from: *Bug.hs Stable obj: [] Stable BCO: [] Ready for upsweep [NONREC ModSummary { ms_hs_date = 2015-04-09 10:01:43.312180074 UTC ms_mod = Main, ms_textual_imps = [import (implicit) Prelude, import Language.Haskell.Exts.QQ ( dec )] ms_srcimps = [] }] *** Deleting temp files: Deleting: compile: input file Bug.hs Created temporary directory: /tmp/ghc7356_0 *** Checking old interface for Main: [1 of 1] Compiling Main ( Bug.hs, Bug.o ) *** Parser: *** Renamer/typechecker: *** Simplify: *** CorePrep: *** ByteCodeGen: Loading package ghc-prim-0.4.0.0 ... linking ... done. *** gcc: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/usr/lib/ghc-7.10.1/integ_2aU3IZNMF9a7mQ0OzsZ0dS --print-file-name libgmp.so Loading package integer-gmp-1.0.0.0 ... linking ... done. Loading package base-4.8.0.0 ... linking ... done. Loading package array-0.5.1.0 ... linking ... done. Loading package filepath-1.4.0.0 ... linking ... done. Loading package deepseq-1.4.1.1 ... linking ... done. Loading package time-1.5.0.1 ... linking ... done. Loading package bytestring-0.10.6.0 ... linking ... done. *** gcc: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/usr/lib/ghc-7.10.1/unix_G4Yo1pNtYrk8nCq1cx8P9d --print-file-name librt.so *** gcc: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/usr/lib/ghc-7.10.1/unix_G4Yo1pNtYrk8nCq1cx8P9d --print-file-name libutil.so *** gcc: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/usr/lib/ghc-7.10.1/unix_G4Yo1pNtYrk8nCq1cx8P9d --print-file-name libdl.so *** gcc: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -L/usr/lib/ghc-7.10.1/unix_G4Yo1pNtYrk8nCq1cx8P9d --print-file-name libpthread.so Loading package unix-2.7.1.0 ... linking ... done. Loading package directory-1.2.2.0 ... linking ... done. Loading package old-locale-1.0.0.7 ... linking ... done. Loading package old-time-1.1.0.3 ... linking ... done. Loading package text-1.2.0.4 ... linking ... done. Loading package polyparse-1.11 ... linking ... done. Loading package cpphs-1.19 ... linking ... done. Loading package pretty-1.1.2.0 ... linking ... done. Loading package haskell-src-exts-1.16.0.1 ... linking ... done. Loading package syb-0.4.4 ... linking ... done. Loading package template-haskell-2.10.0.0 ... linking ... done. Loading package transformers-0.4.2.0 ... linking ... done. Loading package mtl-2.2.1 ... linking ... done. Loading package nats-1 ... linking ... done. Loading package th-lift-0.7.2 ... linking ... done. Loading package containers-0.5.6.2 ... linking ... done. Loading package safe-0.3.8 ... linking ... done. Loading package th-expand-syns-0.3.0.6 ... linking ... done. Loading package th-reify-many-0.1.3 ... linking ... done. Loading package th-orphans-0.11.1 ... linking ... done. Loading package haskell-src-meta-0.6.0.9 ... linking ... done. Loading package haskell-src-exts-qq-0.6.1 ... linking ... done. Bug.hs:8:16:*** Deleting temp files: Deleting: /tmp/ghc7356_0/ghc7356_1.s Warning: deleting non-existent /tmp/ghc7356_0/ghc7356_1.s *** Deleting temp dirs: Deleting: /tmp/ghc7356_0 ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): qual_pkg haskell-src-exts-1.16.0.1 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} on my machine: {{{ $ uname -a Linux io 3.19.3-1-ARCH #1 SMP PREEMPT Thu Mar 26 14:56:16 CET 2015 x86_64 GNU/Linux $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto- wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc/src/gcc-4.9-20150304/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable- libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --enable-lto --enable-plugin --enable-install- libiberty --with-linker-hash-style=gnu --disable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 4.9.2 20150304 (prerelease) (GCC) $ ghc-pkg list /usr/lib/ghc-7.10.1/package.conf.d Cabal-1.22.2.0 array-0.5.1.0 async-2.0.2 base-4.8.0.0 bin-package-db-0.0.0.0 binary-0.7.3.0 bytestring-0.10.6.0 containers-0.5.6.2 cpphs-1.19 deepseq-1.4.1.1 directory-1.2.2.0 filepath-1.4.0.0 ghc-7.10.1 ghc-paths-0.1.0.9 ghc-prim-0.4.0.0 haddock-api-2.16.0 haddock-library-1.2.0 haskeline-0.7.2.1 haskell-src-exts-1.16.0.1 haskell-src-exts-qq-0.6.1 haskell-src-meta-0.6.0.9 hoopl-3.10.0.2 hpc-0.6.0.2 integer-gmp-1.0.0.0 minisat-0.1.1 mtl-2.2.1 nats-1 old-locale-1.0.0.7 old-time-1.1.0.3 polyparse-1.11 pretty-1.1.2.0 process-1.2.3.0 rts-1.0 safe-0.3.8 satchmo-core-0.8.0 stm-2.4.4 syb-0.4.4 template-haskell-2.10.0.0 terminfo-0.4.0.1 text-1.2.0.4 th-expand-syns-0.3.0.6 th-lift-0.7.2 th-orphans-0.11.1 th-reify-many-0.1.3 time-1.5.0.1 transformers-0.4.2.0 unix-2.7.1.0 xhtml-3000.2.1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 10:34:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 10:34:11 -0000 Subject: [GHC] #10277: ApiAnnotations : lexer discards comment close in nested comment In-Reply-To: <044.23b3ff5c4f760c1e4ecc1ce3ba0c35c5@haskell.org> References: <044.23b3ff5c4f760c1e4ecc1ce3ba0c35c5@haskell.org> Message-ID: <059.6368fb2d43385575aaa4bac312eaa4e2@haskell.org> #10277: ApiAnnotations : lexer discards comment close in nested comment -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D829 -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D829 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 11:10:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 11:10:58 -0000 Subject: [GHC] #10277: ApiAnnotations : lexer discards comment close in nested comment In-Reply-To: <044.23b3ff5c4f760c1e4ecc1ce3ba0c35c5@haskell.org> References: <044.23b3ff5c4f760c1e4ecc1ce3ba0c35c5@haskell.org> Message-ID: <059.80b5af5b54aa43311cdc354b9e2cc8b6@haskell.org> #10277: ApiAnnotations : lexer discards comment close in nested comment -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D829 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 12:04:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 12:04:48 -0000 Subject: [GHC] #10278: ApiAnnotations : Nested forall loses forall annotation In-Reply-To: <044.1731f429fad7dec49ad689a5b7ccbeb0@haskell.org> References: <044.1731f429fad7dec49ad689a5b7ccbeb0@haskell.org> Message-ID: <059.79e99b816d965182f01335bb7339382b@haskell.org> #10278: ApiAnnotations : Nested forall loses forall annotation -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by alanz): @jstolarek has pointed out that the offending function is `HsTypes.mk_forall_ty` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 14:17:41 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 14:17:41 -0000 Subject: [GHC] #10280: ApiAnnotations : AnnComma missing in TupleSection Message-ID: <044.2fe39b4134d14da15a3ceacceb7456a6@haskell.org> #10280: ApiAnnotations : AnnComma missing in TupleSection -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- For the following code {{{#!hs {-# LANGUAGE TupleSections #-} foo = do liftIO $ atomicModifyIORef ciTokens ((,()) . f) }}} the annotation is missing for the comma. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 15:24:19 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 15:24:19 -0000 Subject: [GHC] #9058: System.IO.openTempFile does not scale In-Reply-To: <045.41fdb1eece4d843bb1a26f72af3a8a36@haskell.org> References: <045.41fdb1eece4d843bb1a26f72af3a8a36@haskell.org> Message-ID: <060.dee6bb3f78c913d9086454f3bf773fd4@haskell.org> #9058: System.IO.openTempFile does not scale -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: closed => new * resolution: fixed => Comment: This does now mean that the sequence of filenames is completely fixed for a given program (since we don't seed the random number generator) which has some obvious downsides. It would be nice to just use `mkstemps`, but maybe that is not portable enough? I wonder what other languages' standard libraries do here? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 15:31:22 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 15:31:22 -0000 Subject: [GHC] #10274: foreign import ccall "rand" in System.IO fails on Android In-Reply-To: <047.c01313c49328bdb7ebd948eb990c1812@haskell.org> References: <047.c01313c49328bdb7ebd948eb990c1812@haskell.org> Message-ID: <062.3dbcb7b6aba3313e3f2623b489a6bd25@haskell.org> #10274: foreign import ccall "rand" in System.IO fails on Android -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Other | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D826 -------------------------------------+------------------------------------- Comment (by Reid Barton ): In [changeset:"f536d89603bb49dea192b47f54416dc88da980af/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f536d89603bb49dea192b47f54416dc88da980af" Import rand using capi Summary: Android has no rand symbol (it's a static inline function there). Test Plan: ghc-android builds Reviewers: trofi, austin, hvr Reviewed By: hvr Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D826 GHC Trac Issues: #10274 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 15:32:14 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 15:32:14 -0000 Subject: [GHC] #10274: foreign import ccall "rand" in System.IO fails on Android In-Reply-To: <047.c01313c49328bdb7ebd948eb990c1812@haskell.org> References: <047.c01313c49328bdb7ebd948eb990c1812@haskell.org> Message-ID: <062.f0c08db8e33725db5b772e56effd42a4@haskell.org> #10274: foreign import ccall "rand" in System.IO fails on Android -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: merge Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Other | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D826 -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 16:27:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 16:27:05 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.1f7790385f9ca2c68c8435d633d8e932@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+----------------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by rwbarton): hvr: So, what is the status of the in-tree GMP tarball now that 7.10.1 uses integer-gmp 1.*? Specifically where does the GMP library come from on OS X? Do we ship it as part of the binary distribution? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 16:50:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 16:50:10 -0000 Subject: [GHC] #10267: Add support for typed holes in Template Haskell In-Reply-To: <048.c1c64a1e465638edb9cc6eb9b5affa9b@haskell.org> References: <048.c1c64a1e465638edb9cc6eb9b5affa9b@haskell.org> Message-ID: <063.34910cdb7a8518e1e4be745065270c7a@haskell.org> #10267: Add support for typed holes in Template Haskell -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jstolarek): Yes, the implementation is actually a matter of ~30 minutes of hacking. There is one catch though: `HsUnboundVar`, used to represent holes, always stores `RdrName`. That becomes a problem in `DsMeta`, where we expect `Name`s. My solution: parametrize `HsUnboundVar` with `id` like all the other constructors in `HsExpr`. I'm not certain if I got the details right - patch will require careful review in several place (I will mark those on Phab with inline comments). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 18:25:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 18:25:45 -0000 Subject: [GHC] #10269: ApiAnnotations : RdrHsSyn.isFunLhs discards parentheses In-Reply-To: <044.c829a8ccbd4a0502d00b1e225b04f036@haskell.org> References: <044.c829a8ccbd4a0502d00b1e225b04f036@haskell.org> Message-ID: <059.d953f0064620e5ce6780337057a1aa1a@haskell.org> #10269: ApiAnnotations : RdrHsSyn.isFunLhs discards parentheses -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D832 -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D832 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 19:44:32 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 19:44:32 -0000 Subject: [GHC] #10281: Type error with Rank-n-types Message-ID: <043.715543d69d09145192a2c9ffe2902dd1@haskell.org> #10281: Type error with Rank-n-types -------------------------------------+------------------------------------- Reporter: rhjl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Peirce_eq_LEM.hs | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- GHC rejects the following program (which is also attached); it accepts it if the product type is replaced by tuples and the ImpredicativeTypes option is added. I am not sure if this is a bug or an expected consequence of the typing rules, which I do not know very well. In the latter case a better error message would be helpful. The error message is: {{{ 54:17: Couldn't match type ?(Not ?0 -> ?0) -> (?0 -> ?0) -> ?0? with ?LEM? Expected type: (((Peirce -> LEM) -> ?) ? ((LEM -> Peirce) -> ?)) -> ? Actual type: (((Peirce -> (Not ?0 -> ?0) -> (?0 -> ?0) -> ?0) -> ?) ? ((LEM -> ((?1 -> ?0) -> ?1) -> ?1) -> ?)) -> ? In the expression: peirce_implies_lem `and` lem_implies_peirce In an equation for ?peirce_eq_lem?: peirce_eq_lem = peirce_implies_lem `and` lem_implies_peirce }}} This is the code: {{{#!hs {-# LANGUAGE NoImplicitPrelude #-} {-# LANGUAGE RankNTypes #-} {-# LANGUAGE TypeOperators #-} {-# LANGUAGE UnicodeSyntax #-} -- truth type True = ? ?. ? ? ? type False = ? ?. ? id ? True id ? = ? (?) ? ? ? ? ?. (? ? ?) ? (? ? ?) ? ? ? ? ? ? ? = \? ? ? (? ?) -- negation type Not ? = ? ? False -- disjunction / coproduct type ? ? ? = ? ?. (? ? ?) ? (? ? ?) ? ? ?? ? ? ? ?. ? ? ? ? ? ?? ? = \? _ ? ? ? ?? ? ? ? ?. ? ? ? ? ? ?? ? = \_ ? ? ? ? -- conjunction / product type ? ? ? = ? ?. (? ? ?) ? (? ? ?) ? ? ?? ? ? ? ?. ? ? ? ? ? ?? ? = ? (?? id) ?? ? ? ? ?. ? ? ? ? ? ?? ? = ? (?? id) and ? ? ? ?. ? ? ? ? ? ? ? ? `and` ? = \? ? ? (\? ? ? ?) (\? ? ? ?) -- equivalence type ? ? ? = (? ? ?) ? (? ? ?) -- peirce ? lem type Peirce = ? ? ?. ((? ? ?) ? ?) ? ? type LEM = ? ?. (Not ?) ? ? peirce_eq_lem ? Peirce ? LEM peirce_eq_lem = peirce_implies_lem `and` lem_implies_peirce peirce_implies_lem ? Peirce ? LEM peirce_implies_lem peirce = peirce (\? ? ?? (? ? ??)) lem_implies_peirce ? LEM ? Peirce lem_implies_peirce lem = \? ? lem (\? ? ? ?) id }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 20:30:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 20:30:45 -0000 Subject: [GHC] #10281: Type error with Rank-n-types In-Reply-To: <043.715543d69d09145192a2c9ffe2902dd1@haskell.org> References: <043.715543d69d09145192a2c9ffe2902dd1@haskell.org> Message-ID: <058.916d58272ccd4f48d86e1fbd41525f14@haskell.org> #10281: Type error with Rank-n-types -------------------------------------+------------------------------------- Reporter: rhjl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Peirce_eq_LEM.hs Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rhjl): * version: 7.8.4 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 20:37:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 20:37:06 -0000 Subject: [GHC] #10281: Type error with Rank-n-types In-Reply-To: <043.715543d69d09145192a2c9ffe2902dd1@haskell.org> References: <043.715543d69d09145192a2c9ffe2902dd1@haskell.org> Message-ID: <058.0b92102e20bf41332b9b0757b8a7a9d1@haskell.org> #10281: Type error with Rank-n-types -------------------------------------+------------------------------------- Reporter: rhjl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Peirce_eq_LEM.hs Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rhjl): I just confirmed that the issue persists in version 7.10.1; additionally, the following code, also part of the attached file, now produces an error. {{{#!hs type DNE = ? ?. Not (Not ?) ? ? peirce_implies_dne ? Peirce ? DNE peirce_implies_dne peirce = \dn ? peirce dn }}} The error is: {{{ 67:42: Couldn't match type ??0? with ??1? because type variable ??1? would escape its scope This (rigid, skolem) type variable is bound by a type expected by the context: ? -> ?1 at Peirce_eq_LEM.hs:67:42-43 Expected type: (? -> ?0) -> ? Actual type: Not ? -> ? In the first argument of ?peirce?, namely ?dn? In the expression: peirce dn }}} This seems less confusing than the error in the original report; nevertheless I found it curious, because it is new in version 7.10.1, and because the expression naively unifies to the correct type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 20:43:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 20:43:53 -0000 Subject: [GHC] #10269: ApiAnnotations : RdrHsSyn.isFunLhs discards parentheses In-Reply-To: <044.c829a8ccbd4a0502d00b1e225b04f036@haskell.org> References: <044.c829a8ccbd4a0502d00b1e225b04f036@haskell.org> Message-ID: <059.cdd6f6fd93fcb2d6493696042cdcf759@haskell.org> #10269: ApiAnnotations : RdrHsSyn.isFunLhs discards parentheses -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D832 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 20:58:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 20:58:38 -0000 Subject: [GHC] #10278: ApiAnnotations : Nested forall loses forall annotation In-Reply-To: <044.1731f429fad7dec49ad689a5b7ccbeb0@haskell.org> References: <044.1731f429fad7dec49ad689a5b7ccbeb0@haskell.org> Message-ID: <059.d7107d5d7f9a020d8e8e102ffd6de1a6@haskell.org> #10278: ApiAnnotations : Nested forall loses forall annotation -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D833 -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D833 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 23:02:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 23:02:44 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.f100f5782ed63f997eca0f42342411c9@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by erikd): Even adding a print immediately after the `hGetContents` calls like this: {{{ err <- hGetContents errh out <- hGetContents outh print (out, err) }}} results in a pair of empty strings : `("","")`. Now diving into `hGetContents`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 9 23:55:07 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 09 Apr 2015 23:55:07 -0000 Subject: [GHC] #9562: Type families + hs-boot files = unsafeCoerce In-Reply-To: <047.0928965f4d9302995273a5c9d11eab3c@haskell.org> References: <047.0928965f4d9302995273a5c9d11eab3c@haskell.org> Message-ID: <062.0d3e6f9075daab055440a68efc01a07b@haskell.org> #9562: Type families + hs-boot files = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #10270 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * owner: => ezyang Comment: Sure, assuming we decide on a resolution. A relaxation on Richard's proposal is to allow ONLY the left-hand side of type families to be specified in the hs-boot file. This is because we don?t really need the type families to reduce, unless people want them to, and reduces burden on hs-boot file writers, because having to pull in identifiers from the RHS could be pretty annoying. We'd need to add a new syntactic form for RHS-less type families. As for normal instance declarations, the situation here is no worse than the classic diamond example, where two conflicting instances can be used without triggering an error, so I'm less inclined to demand that case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 03:42:24 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 03:42:24 -0000 Subject: [GHC] #10282: Segfault when calling show on an Integer of a certain size Message-ID: <046.e5b03f69bd652eea5ea9c8625bed1e13@haskell.org> #10282: Segfault when calling show on an Integer of a certain size -------------------------------------------+------------------------------- Reporter: gelisam | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: GHCi crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------------+------------------------------- You're not going to believe this. {{{ $ ghc -e 'let k = show (10^184000) in k == k' True $ ghc -e 'let k = show (10^187000) in k == k' True $ ghc -e 'let k = show (10^186000) in k == k' Bus error }}} That's right: there is a problem which affects Integer values which are 186000 digits long, but which does not affect values which are 187000 digits long. So {{{10^184000}}} works fine, {{{10^187000}}} works fine, but {{{10^186000}}} doesn't. What about {{{10^185000}}}? Well, it depends on your version of GHC. And on chance. GHC 7.10.0.20150123 is always happy with {{{10^185000}}}, but GHC 7.8.3 crashes about two-thirds of the time: {{{ $ ghc -e 'let k = show (10^185000) in k == k' True Segmentation fault }}} And it's a different kind of crash, too! A segmentation fault instead of a "bus error". I have tried all the lengths in {{{[1000,2000,..,100000]}}}, and some lengths are fine, some lengths have a bus error, and some lengths segfault. The most helpful lengths I've encountered give an error message about malloc: {{{ $ ghc -e 'let k = show (10^264000) in k == k' True ghc(72417,0x107081000) malloc: *** error for object 0x107300000: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Abort trap }}} Sometimes it gives a slightly different error message: {{{ $ ghc -e 'let k = show (10^264000) in k == k' ghc(72453,0x107381000) malloc: *** error for object 0x107200128: incorrect checksum for freed object - object was probably modified after being freed. *** set a breakpoint in malloc_error_break to debug Abort trap }}} Anyway, a lot more people posted their results in the following reddit thread, without realizing that the problem had to do with the length: http://www.reddit.com/r/haskell/comments/31yajd/can_you_explain_this/ So far, only folks on OS X have managed to reproduce the problem. The problem occurs with {{{ghci}}}, {{{runhaskell}}} and {{{ghc -e}}}, but not with compiled binaries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 05:56:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 05:56:58 -0000 Subject: [GHC] #10282: Segfault when calling show on an Integer of a certain size In-Reply-To: <046.e5b03f69bd652eea5ea9c8625bed1e13@haskell.org> References: <046.e5b03f69bd652eea5ea9c8625bed1e13@haskell.org> Message-ID: <061.6e3dbc2a0850c7c168444ebe21d00ba1@haskell.org> #10282: Segfault when calling show on an Integer of a certain size -------------------------------+------------------------------------------- Reporter: gelisam | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: integer-gmp Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+------------------------------------------- Changes (by hvr): * keywords: => integer-gmp Comment: I'm afraid this may require tracing C library calls on OSX in order to find out how this can even go wrong. I'm particularly surprised this happens on both 7.10 and 7.8 which have a rather completely different `integer-gmp` implementation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 08:28:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 08:28:28 -0000 Subject: [GHC] #10280: ApiAnnotations : AnnComma missing in TupleSection In-Reply-To: <044.2fe39b4134d14da15a3ceacceb7456a6@haskell.org> References: <044.2fe39b4134d14da15a3ceacceb7456a6@haskell.org> Message-ID: <059.98205bad67d3b0c64c0b1c86ecd8cbe5@haskell.org> #10280: ApiAnnotations : AnnComma missing in TupleSection -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D834 -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D834 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 08:48:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 08:48:01 -0000 Subject: [GHC] #10267: Add support for typed holes in Template Haskell In-Reply-To: <048.c1c64a1e465638edb9cc6eb9b5affa9b@haskell.org> References: <048.c1c64a1e465638edb9cc6eb9b5affa9b@haskell.org> Message-ID: <063.85c8d22dbe13c78e113c171f39143da3@haskell.org> #10267: Add support for typed holes in Template Haskell -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D835 -------------------------------------+------------------------------------- Changes (by jstolarek): * differential: => Phab:D835 Comment: Looks like underestimated the difficulty of this - there are some issues with name handling. I will post details in a moment on Phab. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 09:06:56 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 09:06:56 -0000 Subject: [GHC] #10282: Segfault when calling show on an Integer of a certain size In-Reply-To: <046.e5b03f69bd652eea5ea9c8625bed1e13@haskell.org> References: <046.e5b03f69bd652eea5ea9c8625bed1e13@haskell.org> Message-ID: <061.76c12b092297a251e1a490d83757d986@haskell.org> #10282: Segfault when calling show on an Integer of a certain size -------------------------------+------------------------------------------- Reporter: gelisam | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: | Keywords: integer-gmp Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+------------------------------------------- Comment (by hsyl20): It seems to be a duplicate of #7655 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 09:14:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 09:14:48 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.f856ebc673320f31c4296d76211cd84d@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by juhpetersen): This also affects building packages like haskell-platform and gtk2hs- buildtools, which have versioned build-tools dependencies (eg on alex and happy, etc) in their .cabal files, when the those build-tools are Haskell dynamically linked. (A workaround is to drop the version/bound from the .cabal file.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 09:36:45 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 09:36:45 -0000 Subject: [GHC] #9562: Type families + hs-boot files = unsafeCoerce In-Reply-To: <047.0928965f4d9302995273a5c9d11eab3c@haskell.org> References: <047.0928965f4d9302995273a5c9d11eab3c@haskell.org> Message-ID: <062.edc210000bd91ae9ae0af7fb40f24105@haskell.org> #9562: Type families + hs-boot files = unsafeCoerce -------------------------------------+------------------------------------- Reporter: goldfire | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: #10270 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): After discussion with Richard * Note that `B` is never imported by anyone! (Although somehow GHC knows to link in `B.o` nevertheless.) * If `B` had been imported by some module, then the aggressive type- function overlap check would have detected the conflict with `D`. (Provided that the optimisation in that check, which avoids checking conflicts that have already been checked in some sub-tree, isn't fooled by `B.hs-boot`.) Possible ways to fix (two variants of the same thing): 1. GHC should not link and run a program in which `B.hs` is never imported (only `B.hs-boot` is). That'd force the programmer to import `B`, and hence the overlap check would fire. 2. Alternatively, when GHC is preparing the list of modules to send to the linker, perform an overlap check on type functions, as if you were compiling `module Top where { import Main; import B }`. Where the "`B`" is the module(s) that are never imported by anyone except via `{-# SOURCE #-}`. Richard likes (2); Simon likes (1). I'd go with whatever is easier to implement. But in (1) the error message should be clear and explicit. Edward: thanks for the offer! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 10:41:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 10:41:28 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.deee81d0e7e455def22bf681f0897c2e@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by erikd): Pretty certain that the problem is caused by a lack of SMP support for AArch64 in `mk/config.mk`. With the attached patch I was able to compile and install from git HEAD. Still need to do a little more testing to be sure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 11:13:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 11:13:08 -0000 Subject: [GHC] #10283: Make it possible to suppress warnings produced by -fdefer-type-errors Message-ID: <049.e826a9f4dc5636b8c6eb248fd99f1fda@haskell.org> #10283: Make it possible to suppress warnings produced by -fdefer-type-errors -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- At the moment, there seems to be no way to suppress warnings generated by `-fdefer-type-errors` (even `-w` doesn't work). It would be nice to be able to silence them, preferably via a new flag `-fno-warn-deferred-type- errors`. The motivation for this comes from using `-fdefer-type-errors` to write tests that certain definitions do not typecheck (which is very useful, and is a cheaper alternative to writing code to invoke GHC on a source file and analyse its output). In this situation, it is annoying to see a large number of warnings when compiling the testsuite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 12:15:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 12:15:09 -0000 Subject: [GHC] #10283: Make it possible to suppress warnings produced by -fdefer-type-errors In-Reply-To: <049.e826a9f4dc5636b8c6eb248fd99f1fda@haskell.org> References: <049.e826a9f4dc5636b8c6eb248fd99f1fda@haskell.org> Message-ID: <064.ec50b4243ce6c29fca15e219a3cb2dd3@haskell.org> #10283: Make it possible to suppress warnings produced by -fdefer-type-errors -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): What a wonderful application of deferred type errors. I've wanted this ability for some time, but never thought of doing it this way. Yes, please, let's have `-fno-warn-deferred-type-errors`! What would be even better is to be able to enable deferred type errors only over certain regions of a program. After all, I wouldn't want a type error in my testing harness code. But that's a story for another day, I suppose. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 12:53:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 12:53:02 -0000 Subject: [GHC] #10280: ApiAnnotations : AnnComma missing in TupleSection In-Reply-To: <044.2fe39b4134d14da15a3ceacceb7456a6@haskell.org> References: <044.2fe39b4134d14da15a3ceacceb7456a6@haskell.org> Message-ID: <059.4065c8cdf07881a6195acd5473e54890@haskell.org> #10280: ApiAnnotations : AnnComma missing in TupleSection -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D834 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 13:01:57 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 13:01:57 -0000 Subject: [GHC] #10094: Template Haskell cannot represent type wildcards In-Reply-To: <049.6629ff791e291b2d66323173df5c56f5@haskell.org> References: <049.6629ff791e291b2d66323173df5c56f5@haskell.org> Message-ID: <064.08411c1d45e1dce1f0d7024fbb7690e3@haskell.org> #10094: Template Haskell cannot represent type wildcards -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: feature request | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.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: #9879 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by adamgundry): * owner: => adamgundry * related: => #9879 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 14:56:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 14:56:22 -0000 Subject: [GHC] #10283: Make it possible to suppress warnings produced by -fdefer-type-errors In-Reply-To: <049.e826a9f4dc5636b8c6eb248fd99f1fda@haskell.org> References: <049.e826a9f4dc5636b8c6eb248fd99f1fda@haskell.org> Message-ID: <064.ad6f556492fbf35e92bad6910f572e14@haskell.org> #10283: Make it possible to suppress warnings produced by -fdefer-type-errors -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by kosmikus): I'm also in support of this. I've used `-fdefer-type-errors` for a similar purpose already, and have been mildly annoyed by the warning that's displayed too. In my case, it was a single test case, but I can imagine this becomes more pronounced if you want to use it regularly and for many things. [I'll open another ticket for a related issue.] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 15:01:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 15:01:17 -0000 Subject: [GHC] #10284: Create a dedicated `TypeError` exception type Message-ID: <047.839fde5ec581c7ee24adc8fc2d4d35b0@haskell.org> #10284: Create a dedicated `TypeError` exception type -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Ticket #10283 discusses using `-fdefer-type-errors` to test that certain programs do not type check. In practice, this involves evaluating certain expressions to WHNF at run- time can checking whether they trigger an exception. Currently, it seems the exception to catch is an `ErrorCall` exception. It would be nice if we could very specifically catch type errors though. It's entirely possible that a critical test case that I want to be a type error mistakenly type- checks and then calls `error`. In such a situation, it's hard to distinguish such a true run-time error from a deferred type error. It would be much nicer if something like `TypeError` would be thrown instead of `ErrorCall`. Yes, it's currently possible to look at the text of the `ErrorCall` and check for certain text fragments in there, but that sounds extremely fragile to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 15:19:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 15:19:33 -0000 Subject: [GHC] #10285: Bug in Coerciible Message-ID: <046.006c15618be24223a545ea3cfa4998d2@haskell.org> #10285: Bug in Coerciible -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Richard and I uncovered this {{{ {-# LANGUAGE RoleAnnotations #-} module Bar( N ) where -- Data constructor not exported type role N representational newtype N a = MkN Int }}} and {{{ {-# LANGUAGE FlexibleContexts #-} module Foo where import Data.Coerce import Data.Type.Coercion import Bar f :: Coercible (N a) (N b) => Coercion a b f = Coercion }}} This compiles but it should not! It wrongly compiles by using `nth (N a ~R N b)`; but (as Fig 4 of [http://research.microsoft.com/en- us/um/people/simonpj/papers/ext-f/ the Corcible paper] says), we can't decompose a newtype at representational role. Easy to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 15:21:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 15:21:04 -0000 Subject: [GHC] #10285: Bug in Coerciible In-Reply-To: <046.006c15618be24223a545ea3cfa4998d2@haskell.org> References: <046.006c15618be24223a545ea3cfa4998d2@haskell.org> Message-ID: <061.ac37cd2258bdfc6cade4d7ef87bd2288@haskell.org> #10285: Bug in Coerciible -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => goldfire -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 15:21:24 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 15:21:24 -0000 Subject: [GHC] #10285: Bug in Coerciible In-Reply-To: <046.006c15618be24223a545ea3cfa4998d2@haskell.org> References: <046.006c15618be24223a545ea3cfa4998d2@haskell.org> Message-ID: <061.3c539cf4011f02cca0d6691df1288114@haskell.org> #10285: Bug in Coerciible -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Also add a check in Lint -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 16:27:56 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 16:27:56 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.db38cbbac853aeec154b0d8709343612@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10226 | -------------------------------------+------------------------------------- Changes (by simonpj): * cc: goldfire (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 16:39:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 16:39:11 -0000 Subject: [GHC] #10283: Make it possible to suppress warnings produced by -fdefer-type-errors In-Reply-To: <049.e826a9f4dc5636b8c6eb248fd99f1fda@haskell.org> References: <049.e826a9f4dc5636b8c6eb248fd99f1fda@haskell.org> Message-ID: <064.243853abaf632acf5c959e774f16d998@haskell.org> #10283: Make it possible to suppress warnings produced by -fdefer-type-errors -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: newcomer Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * keywords: => newcomer -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 16:46:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 16:46:21 -0000 Subject: [GHC] #10218: GHC creates incorrect code which throws <> In-Reply-To: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> References: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> Message-ID: <061.0242f408540b4aeea46477458df72325@haskell.org> #10218: GHC creates incorrect code which throws <> -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: yes Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): OK here is a nice small test case, which does not (unlike the test above) depend on `lens`! {{{ module Main where {-# NOINLINE foo #-} foo :: Bool -> Int -> Int -> Int foo True _ x = 1 foo False _ x = x+1 {-# NOINLINE bar #-} bar :: Int -> (Int,Int) bar x = let y1 = x * 2 y2 = x * 2 in (foo False y1 y2,foo False y2 y1) main = print (fst p + snd p) where p = bar 3 }}} Compile with `-O -feager-blackholing` and you get `<`. Add `-fno- cse` or `-flate-dmd-anal` restores correct behaviour. Points to note * `foo` uses its second argument zero times, and its third argument exactly once. * So the two calls to `foo` in `bar` use `y1` exactly once and `y2` exactly once. * But when `y1` and `y2` are CSE'd, the usage goes up to twice; and that is the problem. I'm validating a simple fix in CSE, which zaps the demand-info on binders which are potentially shared. It's a bit brutal. But another run of the demand analyser (which has other advantages) restores everything again. I'm validating now; will commit next week. Really sorry to have taken two weeks of your time to find this bug. But at least your efforts will be rewarded by a real fix. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 16:51:49 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 16:51:49 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.036470cca3a46426f3cbf2773797336b@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * cc: ezyang (added) Comment: It looks as if somehow `haskell-src-exts-1.16.0.1` isn't in GHC's package database, despite the fact that there's a message saying it has been loaded. Edward might you have some idea? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 17:13:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 17:13:25 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.25491c464e40ed18314f9a216a7a57fc@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by juhpetersen): Thanks Erik, I kicked off a test build with this patch: http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2957099 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 18:31:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 18:31:05 -0000 Subject: [GHC] #10286: native code generator: GHC crash at GHC.Prim SIMD vector Message-ID: <045.2537c47c79c85a06c9641d3e66088575@haskell.org> #10286: native code generator: GHC crash at GHC.Prim SIMD vector -------------------------------------+------------------------------------- Reporter: hkanai | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When compiling attached source file, GHC panics. The following is the error message. {{{ $ ghc -Wall Vec3.hs [1 of 1] Compiling Data.Vector.Vec3 ( Vec3.hs, Vec3.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): Size.intSize W256 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Currently native code generator does not support SIMD operations, and my computer does not support AVX instructions. Therefore ghc cannot compile the source at any case. So I think this bug is not so important. My system environment. {{{ $ uname -a Linux think 3.19.2-1-ARCH #1 SMP PREEMPT Wed Mar 18 16:21:02 CET 2015 x86_64 GNU/Linux $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.1 $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Duo CPU L9300 @ 1.60GHz stepping : 6 microcode : 0x60c cpu MHz : 1601.000 cache size : 6144 KB physical id : 0 siblings : 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm ida dtherm tpr_shadow vnmi flexpriority bugs : bogomips : 3193.86 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Duo CPU L9300 @ 1.60GHz stepping : 6 microcode : 0x60c cpu MHz : 1601.000 cache size : 6144 KB physical id : 0 siblings : 2 core id : 1 cpu cores : 2 apicid : 1 initial apicid : 1 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm ida dtherm tpr_shadow vnmi flexpriority bugs : bogomips : 3193.86 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 18:57:44 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 18:57:44 -0000 Subject: [GHC] #10286: native code generator: GHC crash at GHC.Prim SIMD vector In-Reply-To: <045.2537c47c79c85a06c9641d3e66088575@haskell.org> References: <045.2537c47c79c85a06c9641d3e66088575@haskell.org> Message-ID: <060.c799a44b72b8947e5980b0c81f1fe843@haskell.org> #10286: native code generator: GHC crash at GHC.Prim SIMD vector -------------------------------------+------------------------------------- Reporter: hkanai | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hkanai): LLVM code generator has problem too. {{{ $ ghc -Wall -fllvm -mavx -mavx2 Vec3.hs [1 of 1] Compiling Data.Vector.Vec3 ( Vec3.hs, Vec3.o ) You are using a new version of LLVM that hasn't been tested yet! We will try though... opt: /tmp/ghc2501_0/ghc2501_2.ll:7:6: error: unexpected type in metadata definition !0 = metadata !{metadata !"top", i8* null} }}} My environment is same, and here is the LLVM environment. {{{ $ llvm-as --version LLVM (http://llvm.org/): LLVM version 3.6.0 Optimized build. Built Apr 2 2015 (15:02:32). Default target: x86_64-unknown-linux-gnu Host CPU: penryn }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 20:46:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 20:46:10 -0000 Subject: [GHC] #10234: armhf : Validate fails during bindisttest configure In-Reply-To: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> References: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> Message-ID: <059.6d5c54973162bfb4b54e5e5a121f5509@haskell.org> #10234: armhf : Validate fails during bindisttest configure -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: llvm Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: ?Phab:D828 -------------------------------------+------------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"485dba86d2519cc4855e01db279e127d0221f88a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="485dba86d2519cc4855e01db279e127d0221f88a" configure : LLVM and LD detections improvements (#10234). * distrib/configure.ac.in : Detect correct version of LLVM tools as was done for the top level configure.ac in 42448e3757. * aclocal.m4 : Add a FIND_LD macro that can be used in both configure scripts. * Use new FIND_LD macro in both configure scripts. Signed-off-by: Erik de Castro Lopo Test Plan: validate on amd64-linux and armhf-linux. Reviewers: rwbarton, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D828 GHC Trac Issues: #10234 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 20:53:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 20:53:25 -0000 Subject: [GHC] #10234: armhf : Validate fails during bindisttest configure In-Reply-To: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> References: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> Message-ID: <059.bf4e0e63d0778ab784ec9980476ea118@haskell.org> #10234: armhf : Validate fails during bindisttest configure -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: llvm Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: ?Phab:D828 -------------------------------------+------------------------------------- Comment (by erikd): This exact patch should not be pulled into the 7.10 branch, but it might make sense to pull in a 7.10 specific version of this patch. Specifically, a version of this patch that requires the llvm-3.4 versions of `llc` and `opt`. @rwbarton, is this a good idea? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 10 22:15:29 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 10 Apr 2015 22:15:29 -0000 Subject: [GHC] #10234: armhf : Validate fails during bindisttest configure In-Reply-To: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> References: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> Message-ID: <059.07bfb8ca8e20be1632334b7c3c132d5e@haskell.org> #10234: armhf : Validate fails during bindisttest configure -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: merge Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: llvm Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: ?Phab:D828 -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => merge Comment: I think you mean 3.5, not 3.4. But yes, then the bindist will automatically do the right thing on systems like mine (llc-3.4 and llc-3.5 both installed, with llc being a symlink to llc-3.4). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 11 00:36:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Apr 2015 00:36:22 -0000 Subject: [GHC] #10286: native code generator: GHC crash at GHC.Prim SIMD vector In-Reply-To: <045.2537c47c79c85a06c9641d3e66088575@haskell.org> References: <045.2537c47c79c85a06c9641d3e66088575@haskell.org> Message-ID: <060.e7110c056a3f2dbddaa25d9a10716f09@haskell.org> #10286: native code generator: GHC crash at GHC.Prim SIMD vector -------------------------------------+------------------------------------- Reporter: hkanai | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by carter): Hello! 1) the SIMD primops in GHC are highly experimental, and they're ONLY supported on the -fllvm backend currently, so YOU WILL get a GHC panic when trying to compile them with the normal backend (this is planned to be fixed at some point, but also requires rethinking what the SIMD api SHOULD be, because writing good SIMD isn't portable between even different micro architectures!) 2) your HOST CPU doesn't support AVX style instructions, so `DoubleX4#` sized simd values wont be compiled terribly efficiently, because LLVM will (in some fashion) split those `DoubleX4#` values across two `DoubleX2#` sized registers. 3) that llvm error about `!0 = metadata !{metadata !"top", i8* null}` seems like a real bug! I'm going to rope some other folks in to help track that down. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 11 00:44:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Apr 2015 00:44:45 -0000 Subject: [GHC] #10286: native code generator: GHC crash at GHC.Prim SIMD vector In-Reply-To: <045.2537c47c79c85a06c9641d3e66088575@haskell.org> References: <045.2537c47c79c85a06c9641d3e66088575@haskell.org> Message-ID: <060.cd8b46fa4caba83b4ba6052833b115a6@haskell.org> #10286: native code generator: GHC crash at GHC.Prim SIMD vector -------------------------------------+------------------------------------- Reporter: hkanai | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Replying to [comment:1 hkanai]: > LLVM version 3.6.0 There's you problem! The upstream LLVM developers have changed the LLVM IR (Intermediate Repersentation) in 3.6 so that its not possible to easily support llvm 3.4 and 3.6 (and 3.5 had other issues). Git HEAD currently only supports llvm-3.6 (checked at configure time) and I'm about to propose a version of patch 485dba86d2519c (ticket #10234) for the 7.10 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 11 00:57:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Apr 2015 00:57:15 -0000 Subject: [GHC] #10286: native code generator: GHC crash at GHC.Prim SIMD vector In-Reply-To: <045.2537c47c79c85a06c9641d3e66088575@haskell.org> References: <045.2537c47c79c85a06c9641d3e66088575@haskell.org> Message-ID: <060.e73e7afad16081aac7dd507b8523b07e@haskell.org> #10286: native code generator: GHC crash at GHC.Prim SIMD vector -------------------------------------+------------------------------------- Reporter: hkanai | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 11 01:06:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Apr 2015 01:06:22 -0000 Subject: [GHC] #10234: armhf : Validate fails during bindisttest configure In-Reply-To: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> References: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> Message-ID: <059.846fb948f798c551fed1517ae33adfe5@haskell.org> #10234: armhf : Validate fails during bindisttest configure -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: llvm Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: ?Phab:D828 -------------------------------------+------------------------------------- Changes (by erikd): * owner: erikd => * status: merge => new Comment: @rwbarton Are you sure about 3.5 working? I seem to remember an issue about `def$...` symbols. On the other hand, I know 3.4 works with 7.10. Also this patch alone is insufficient (it also needs 42448e3757f257) and a change to chose a version of llvm other than 3.6. Working on modified versions of these two patches. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 11 01:28:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Apr 2015 01:28:40 -0000 Subject: [GHC] #10282: Segfault when calling show on an Integer of a certain size In-Reply-To: <046.e5b03f69bd652eea5ea9c8625bed1e13@haskell.org> References: <046.e5b03f69bd652eea5ea9c8625bed1e13@haskell.org> Message-ID: <061.70f9ff16164e889845e8813a94428762@haskell.org> #10282: Segfault when calling show on an Integer of a certain size -------------------------------+------------------------------------------- Reporter: gelisam | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 7.10.1 Resolution: duplicate | Keywords: integer-gmp Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: 7655 | Differential Revisions: -------------------------------+------------------------------------------- Changes (by gelisam): * status: new => closed * resolution: => duplicate * related: => 7655 Comment: Indeed, the problem disappeared after I installed the latest version of GMP from https://gmplib.org/repo/gmp-6.0/. Closing as duplicate (should I do that myself?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 11 03:34:53 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Apr 2015 03:34:53 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.fc4d39c8f6ce95bbbaa3b172d8eae621@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by juhpetersen): Replying to [comment:10 juhpetersen]: > I kicked off a test build with this patch: > http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2957099 Unfortunately the build still seems to fail the same way for me unless I am missing something: http://arm.koji.fedoraproject.org//work/tasks/7099/2957099/build.log [7MB] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 11 07:15:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Apr 2015 07:15:36 -0000 Subject: [GHC] #10286: native code generator: GHC crash at GHC.Prim SIMD vector In-Reply-To: <045.2537c47c79c85a06c9641d3e66088575@haskell.org> References: <045.2537c47c79c85a06c9641d3e66088575@haskell.org> Message-ID: <060.67a98542332e494b663a92e0d20f7d74@haskell.org> #10286: native code generator: GHC crash at GHC.Prim SIMD vector -------------------------------------+------------------------------------- Reporter: hkanai | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by erikd): Just to update with a correction to my previous comment, on amd64-linux, there are two llvm backend related validation errors with llvm 3.4 and none with llvm-3.5. My 7.10 patch will therefore only allow llvm-3.5. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 11 07:21:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Apr 2015 07:21:17 -0000 Subject: [GHC] #10234: armhf : Validate fails during bindisttest configure In-Reply-To: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> References: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> Message-ID: <059.f775c1ebe47ca220b52f1998c02cb4c2@haskell.org> #10234: armhf : Validate fails during bindisttest configure -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: llvm Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: ?Phab:D828 -------------------------------------+------------------------------------- Comment (by erikd): On amd64-linux building from the ghc-7.10 git branch, there are two llvm backend related validation errors with llvm 3.4 and none with llvm-3.5. The build on armhf-linux is still in progress. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 11 08:06:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Apr 2015 08:06:22 -0000 Subject: [GHC] #10287: ApiAnnotations : BooleanFormula construction discards original Message-ID: <044.dc10540293e80736094df33a8e676e4d@haskell.org> #10287: ApiAnnotations : BooleanFormula construction discards original -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The MINIMAL pragma is captured in the parser using a `BooleanFormula`. The constructors (`mkBool`,`mkAnd`,`mkOr`) are smart and try to minimise the boolean formula as it is constructed. This discards the original information, making round tripping impossible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 11 18:27:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 11 Apr 2015 18:27:18 -0000 Subject: [GHC] #10286: native code generator: GHC crash at GHC.Prim SIMD vector In-Reply-To: <045.2537c47c79c85a06c9641d3e66088575@haskell.org> References: <045.2537c47c79c85a06c9641d3e66088575@haskell.org> Message-ID: <060.b8812c2e03c09b1a2ef9c81d15958df8@haskell.org> #10286: native code generator: GHC crash at GHC.Prim SIMD vector -------------------------------------+------------------------------------- Reporter: hkanai | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hkanai): Oh, I did not know the SIMD primops and LLVM backend are such unstable. I will use it with checking implementation status carefully. Thanks for letting me know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 12 03:02:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Apr 2015 03:02:18 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.5348a7d7a0fb06fb6cf84a7f84f86b52@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by rwbarton): The behavior in comment:4 is really weird, I would start the investigation there. Maybe try `echo $(strace .../ghc-pkg --version)` and try to figure out why it does not write anything to stdout? Could it be because stdout is not connected to a terminal somehow? (That's about the only explanation I can think of...) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 12 03:27:21 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Apr 2015 03:27:21 -0000 Subject: [GHC] #10286: native code generator: GHC crash at GHC.Prim SIMD vector In-Reply-To: <045.2537c47c79c85a06c9641d3e66088575@haskell.org> References: <045.2537c47c79c85a06c9641d3e66088575@haskell.org> Message-ID: <060.272791579af986f64719570f413dada5@haskell.org> #10286: native code generator: GHC crash at GHC.Prim SIMD vector -------------------------------------+------------------------------------- Reporter: hkanai | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by carter): I personally recommend writing your simd in C and using the FFI, but if you wanna use the current simd operations, tread carefully! Good SIMD code requires using custom use of the instructions available on the cpu micro architectures you care about. The current GHC SIMD primops does not expose those in a way that allows peak throughput SIMD. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 12 07:41:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Apr 2015 07:41:17 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.acb67e6928585313f21a18cf53ee9f4e@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+----------------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by hvr): Replying to [comment:39 rwbarton]: > hvr: So, what is the status of the in-tree GMP tarball now that 7.10.1 uses integer-gmp 1.*? Specifically where does the GMP library come from on OS X? Do we ship it as part of the binary distribution? Well, afaik, the official GHC bindist for OSX is configured to use the in- tree GMP, which for 7.10 is still at GMP 5.0.4 (and we can't upgrade the in-tree GMP till we make the switch to an externally fetched GMP tarball, but sadly Phab:D339 wasn't ready in time for 7.10 and still isn't...) You can btw easily find out which GMP version (and whether it was the intree or the system libgmp) `integer-gmp` was configured against by looking at the installed `` header. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 12 12:18:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Apr 2015 12:18:42 -0000 Subject: [GHC] #10287: ApiAnnotations : BooleanFormula construction discards original In-Reply-To: <044.dc10540293e80736094df33a8e676e4d@haskell.org> References: <044.dc10540293e80736094df33a8e676e4d@haskell.org> Message-ID: <059.5b8ba87d226574dcd417dc3409a92325@haskell.org> #10287: ApiAnnotations : BooleanFormula construction discards original -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D837 -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D837 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 12 12:58:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Apr 2015 12:58:16 -0000 Subject: [GHC] #10288: -flate-dmd-anal triggers "Entered absent arg" Message-ID: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> #10288: -flate-dmd-anal triggers "Entered absent arg" -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime crash Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- If I compile my program with -flate-dmd-anal, it crashes at run-time with {{{Oops! Entered absent arg w_sJ66e M V1 Double}}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 12 13:31:30 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Apr 2015 13:31:30 -0000 Subject: [GHC] #10289: compiling huge HashSet hogs memory Message-ID: <044.7a75381e3cbd52797d1fc50b07f81ee0@haskell.org> #10289: compiling huge HashSet hogs memory -------------------------------------+------------------------------------- Reporter: zudov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Compiling a huge (~2.5k elements) set with GHC-7.10.1 or GHC-head and unordered-containers-0.2.5.1 or unordered-containers-head takes way too much memory. Here is a [https://github.com/zudov/html5-entity/blob/unordered- containers/src/Text/Html/Entity/Data/EntitySet.hs file] which I am trying to compile. I've also set up a [https://travis- ci.org/zudov/html5-entity/builds/58063328 travis build] which demonstrates the behaviour with different versions of GHC and unordered-containers. Further I would be referring to [https://travis- ci.org/zudov/html5-entity/jobs/58063332 this build-job] which uses GHC-7.10.1 and unordered-containers-0.2.5.1. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L397 Compilation] with default optimization options takes around [https ://travis-ci.org/zudov/html5-entity/jobs/58063332#L408 12GB] of memory. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L367 Compilation] with `-O0` takes around [https://travis- ci.org/zudov/html5-entity/jobs/58063332#L378 400MB]. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L457 Compilation] with `-O2` takes around [https://travis- ci.org/zudov/html5-entity/jobs/58063332#L468 12GB] of memory. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L487 Compilation] with `-O2 -fignore-interface-pragmas` takes around [https ://travis-ci.org/zudov/html5-entity/jobs/58063332#L498 500MB] of memory, which solves the problem. When the build uses GHC-7.8.4, neither of this hogging [https://travis- ci.org/zudov/html5-entity/jobs/58063330 occurs]. Another interesting observation is that [https://travis- ci.org/zudov/html5-entity/jobs/58063330#L339 compiling] [https://github.com/zudov/html5-entity/blob/unordered- containers/src/Text/Html/Entity/Data/EntityMap.hs HashMap] of the same size, doesn't cause memory hogging even with `-O2`. This attracted my attention as `HashSet` is implemented in terms of `HashMap`. I reported the issue to `unordered-containers` as well: [https://github.com/tibbe/unordered-containers/issues/100 link]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 12 13:33:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Apr 2015 13:33:33 -0000 Subject: [GHC] #10290: compiling huge HashSet hogs memory Message-ID: <044.ea1e19c9a9ce8049d24c4fc418b0c986@haskell.org> #10290: compiling huge HashSet hogs memory -------------------------------------+------------------------------------- Reporter: zudov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Compiling a huge (~2.5k elements) set with GHC-7.10.1 or GHC-head and unordered-containers-0.2.5.1 or unordered-containers-head takes way too much memory. Here is a [https://github.com/zudov/html5-entity/blob/unordered- containers/src/Text/Html/Entity/Data/EntitySet.hs file] which I am trying to compile. I've also set up a [https://travis- ci.org/zudov/html5-entity/builds/58063328 travis build] which demonstrates the behaviour with different versions of GHC and unordered-containers. Further I would be referring to [https://travis- ci.org/zudov/html5-entity/jobs/58063332 this build-job] which uses GHC-7.10.1 and unordered-containers-0.2.5.1. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L397 Compilation] with default optimization options takes around [https ://travis-ci.org/zudov/html5-entity/jobs/58063332#L408 12GB] of memory. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L367 Compilation] with `-O0` takes around [https://travis- ci.org/zudov/html5-entity/jobs/58063332#L378 400MB]. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L457 Compilation] with `-O2` takes around [https://travis- ci.org/zudov/html5-entity/jobs/58063332#L468 12GB] of memory. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L487 Compilation] with `-O2 -fignore-interface-pragmas` takes around [https ://travis-ci.org/zudov/html5-entity/jobs/58063332#L498 500MB] of memory, which solves the problem. When the build uses GHC-7.8.4, neither of this hogging [https://travis- ci.org/zudov/html5-entity/jobs/58063330 occurs]. Another interesting observation is that [https://travis- ci.org/zudov/html5-entity/jobs/58063330#L339 compiling] [https://github.com/zudov/html5-entity/blob/unordered- containers/src/Text/Html/Entity/Data/EntityMap.hs HashMap] of the same size, doesn't cause memory hogging even with `-O2`. This attracted my attention as `HashSet` is implemented in terms of `HashMap`. I reported the issue to `unordered-containers` as well: [https://github.com/tibbe/unordered-containers/issues/100 link]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 12 13:35:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Apr 2015 13:35:22 -0000 Subject: [GHC] #10291: compiling huge HashSet hogs memory Message-ID: <044.7ae1a7420fa208e82e754a0618131aa1@haskell.org> #10291: compiling huge HashSet hogs memory -------------------------------------+------------------------------------- Reporter: zudov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Compiling a huge (~2.5k elements) set with GHC-7.10.1 or GHC-head and unordered-containers-0.2.5.1 or unordered-containers-head takes way too much memory. Here is a [https://github.com/zudov/html5-entity/blob/unordered- containers/src/Text/Html/Entity/Data/EntitySet.hs file] which I am trying to compile. I've also set up a [https://travis- ci.org/zudov/html5-entity/builds/58063328 travis build] which demonstrates the behaviour with different versions of GHC and unordered-containers. Further I would be referring to [https://travis- ci.org/zudov/html5-entity/jobs/58063332 this build-job] which uses GHC-7.10.1 and unordered-containers-0.2.5.1. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L397 Compilation] with default optimization options takes around [https ://travis-ci.org/zudov/html5-entity/jobs/58063332#L408 12GB] of memory. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L367 Compilation] with `-O0` takes around [https://travis- ci.org/zudov/html5-entity/jobs/58063332#L378 400MB]. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L457 Compilation] with `-O2` takes around [https://travis- ci.org/zudov/html5-entity/jobs/58063332#L468 12GB] of memory. * [https://travis-ci.org/zudov/html5-entity/jobs/58063332#L487 Compilation] with `-O2 -fignore-interface-pragmas` takes around [https ://travis-ci.org/zudov/html5-entity/jobs/58063332#L498 500MB] of memory, which solves the problem. When the build uses GHC-7.8.4, neither of this hogging [https://travis- ci.org/zudov/html5-entity/jobs/58063330 occurs]. Another interesting observation is that [https://travis- ci.org/zudov/html5-entity/jobs/58063330#L339 compiling] [https://github.com/zudov/html5-entity/blob/unordered- containers/src/Text/Html/Entity/Data/EntityMap.hs HashMap] of the same size, doesn't cause memory hogging even with `-O2`. This attracted my attention as `HashSet` is implemented in terms of `HashMap`. I reported the issue to `unordered-containers` as well: [https://github.com/tibbe/unordered-containers/issues/100 link]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 12 18:58:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Apr 2015 18:58:43 -0000 Subject: [GHC] #9297: Packages linked against certain Windows .dll files give warnings at runtime In-Reply-To: <050.15e3ebd6026e8054e922a0058e2d13ac@haskell.org> References: <050.15e3ebd6026e8054e922a0058e2d13ac@haskell.org> Message-ID: <065.8e01e6a4694a638d890e449d97666321@haskell.org> #9297: Packages linked against certain Windows .dll files give warnings at runtime -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.2 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: None/Unknown | (amd64) Blocked By: | Test Case: Related Tickets: #2283, #9218 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Jedai): Same here with Gloss or rather OpenGL : {{{ : warning: wglGetProcAddress from opengl32 is linked instead of __imp_wglGetProcAddress : warning: GetProcAddress from kernel32 is linked instead of __imp_GetProcAddress : warning: LoadLibraryA from kernel32 is linked instead of __imp_LoadLibraryA : warning: GetProcAddress from kernel32 is linked instead of __imp_GetProcAddress : warning: LoadLibraryA from kernel32 is linked instead of __imp_LoadLibraryA : internal error: checkProddableBlock: invalid fixup in runtime linker: 000000000f5c00e8 (GHC version 7.10.1 for x86_64_unknown_mingw32) }}} To reproduce : compile gloss with minghc-7.10.1 then in ghci ask to `display` something. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 12 19:17:37 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Apr 2015 19:17:37 -0000 Subject: [GHC] #2189: hSetBuffering stdin NoBuffering doesn't work on Windows In-Reply-To: <047.b31f95b84e60784da45a33105d44ed84@haskell.org> References: <047.b31f95b84e60784da45a33105d44ed84@haskell.org> Message-ID: <062.28c27a719bb278a008d61605d26701d5@haskell.org> #2189: hSetBuffering stdin NoBuffering doesn't work on Windows -------------------------------------+------------------------------------- Reporter: FalconNL | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 6.8.2 Resolution: | Keywords: Operating System: Windows | hsetbuffering buffering buffer Type of failure: None/Unknown | Architecture: x86 Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Jedai): * cc: Jedai (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 12 19:59:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Apr 2015 19:59:40 -0000 Subject: [GHC] #10276: ApiAnnotations : ITopenExpQuote needs SourceText In-Reply-To: <044.2a289d9c9e324d361db842bc55632f22@haskell.org> References: <044.2a289d9c9e324d361db842bc55632f22@haskell.org> Message-ID: <059.aa6357e5ed7ede81bc7c84df7290b158@haskell.org> #10276: ApiAnnotations : ITopenExpQuote needs SourceText -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by alanz): * milestone: 7.10.2 => 7.12.1 Comment: There are only two options, both of which are well defined. We can deal with this in ghc-exactprint by looking at the length of the annotated SrcSpan, so this ticket is not strictly necessary -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 12 22:03:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Apr 2015 22:03:58 -0000 Subject: [GHC] #10287: ApiAnnotations : BooleanFormula construction discards original In-Reply-To: <044.dc10540293e80736094df33a8e676e4d@haskell.org> References: <044.dc10540293e80736094df33a8e676e4d@haskell.org> Message-ID: <059.7e44b249ec072d7c0774c161876dd8d3@haskell.org> #10287: ApiAnnotations : BooleanFormula construction discards original -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D837 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 12 22:20:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Apr 2015 22:20:07 -0000 Subject: [GHC] #10278: ApiAnnotations : Nested forall loses forall annotation In-Reply-To: <044.1731f429fad7dec49ad689a5b7ccbeb0@haskell.org> References: <044.1731f429fad7dec49ad689a5b7ccbeb0@haskell.org> Message-ID: <059.ece998fe1f7d37f93628d865d063bca4@haskell.org> #10278: ApiAnnotations : Nested forall loses forall annotation -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D833 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch Comment: Although there is a version in development that gets rid of the collapsing, I am not going to have time to chase the last bugs through in the near future, and the Phab:D833 version will get the job done for ghc- exactprint in the interim. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 12 23:44:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Apr 2015 23:44:22 -0000 Subject: [GHC] #10292: Validate fails on armhf-linux Message-ID: <044.8055e40124ced0bf29d2dcf6e0c01c9f@haskell.org> #10292: Validate fails on armhf-linux -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: arm | Type of failure: Building GHC Test Case: | failed Blocking: | Blocked By: Differential Revisions: | Related Tickets: -------------------------------------+------------------------------------- After apply the 'configure : LLVM and LD detection improvements' patch from #10234 validation of the ghc-7.10 branch fails with: {{{ inplace/bin/dll-split compiler/stage2/build/.depend-v-dyn.haskell \ "DynFlags" "Annotations ApiAnnotation Avail Bag BasicTypes Binary \ BooleanFormula BreakArray BufWrite Class CmdLineParser CmmType CoAxiom \ ConLike Coercion Config Constants CoreArity CoreFVs CoreSubst CoreSyn \ CoreTidy CoreUnfold CoreUtils CostCentre DataCon Demand Digraph \ DriverPhases DynFlags Encoding ErrUtils Exception ExtsCompat46 \ FamInstEnv FastFunctions FastMutInt FastString FastTypes Fingerprint \ FiniteMap ForeignCall Hooks HsBinds HsDecls HsDoc HsExpr HsImpExp \ HsLit PlaceHolder HsPat HsSyn HsTypes HsUtils HscTypes IOEnv Id \ IdInfo IfaceSyn IfaceType InstEnv Kind Lexeme ListSetOps Literal \ Maybes MkCore MkId Module MonadUtils Name NameEnv NameSet OccName \ OccurAnal OptCoercion OrdList Outputable PackageConfig Packages Pair \ Panic PatSyn PipelineMonad Platform PlatformConstants PprCore PrelNames \ PrelRules Pretty PrimOp RdrName Rules Serialized SrcLoc StaticFlags \ StringBuffer TcEvidence TcRnTypes TcType 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.ARM64 \ 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" compiler/ghc.mk:653: recipe for target 'compiler/stage2/dll-split.stamp' failed make[1]: *** [compiler/stage2/dll-split.stamp] Segmentation fault }}} There have been a number of tickets related to `dll-split` on armhf. I have verified that the `ld.gold` linker is being invoked. The fixes introduced in #9873 also seem to be present. More investigation needed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 12 23:49:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Apr 2015 23:49:16 -0000 Subject: [GHC] #10234: armhf : Validate fails during bindisttest configure In-Reply-To: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> References: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> Message-ID: <059.ea26e079e719a2a811cbce3f3a613f4f@haskell.org> #10234: armhf : Validate fails during bindisttest configure -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: llvm Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: ?Phab:D828 -------------------------------------+------------------------------------- Changes (by erikd): * status: new => patch Comment: The attached patch: {{{ commit 8a11eec3a6c8d82f4f12a00e6a64f0916cf3575f Author: Erik de Castro Lopo Date: Mon Apr 13 09:16:54 2015 +1000 configure : LLVM and LD detection improvements (#10234). This is the ghc-7.10 branch specific version of commits 42448e3757 and 485dba86d2 in git HEAD. The main difference is that for 7.10 we need llvm version 3.5 whereas git HEAD currently needs version 3.6. Signed-off-by: Erik de Castro Lopo }}} applies to the ghc-7.10 branch. It has been validated on amd64-linux. Validation failed on armhf-linux but I think that is un-related to this patch (see #10292). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 12 23:50:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Apr 2015 23:50:08 -0000 Subject: [GHC] #10292: Validate fails on armhf-linux In-Reply-To: <044.8055e40124ced0bf29d2dcf6e0c01c9f@haskell.org> References: <044.8055e40124ced0bf29d2dcf6e0c01c9f@haskell.org> Message-ID: <059.86a655323539694e9d289bd3aa1782e2@haskell.org> #10292: Validate fails on armhf-linux ----------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+--------------------------------- Comment (by rwbarton): dll-split crashing usually just means the stage2 compiler is broken somehow, it may be good to start by running the test suite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 12 23:51:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Apr 2015 23:51:09 -0000 Subject: [GHC] #10288: -flate-dmd-anal triggers "Entered absent arg" In-Reply-To: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> References: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> Message-ID: <061.f4ea3669d71c29b3754578f05352d22e@haskell.org> #10288: -flate-dmd-anal triggers "Entered absent arg" -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => infoneeded Comment: Could you attach your program (preferably after minimizing it as much as possible)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 12 23:52:09 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Apr 2015 23:52:09 -0000 Subject: [GHC] #10290: compiling huge HashSet hogs memory In-Reply-To: <044.ea1e19c9a9ce8049d24c4fc418b0c986@haskell.org> References: <044.ea1e19c9a9ce8049d24c4fc418b0c986@haskell.org> Message-ID: <059.98ef0a6a868aaf0ae13c615e8fbba714@haskell.org> #10290: compiling huge HashSet hogs memory -------------------------------------+------------------------------------- Reporter: zudov | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10289 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate * related: => #10289 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 12 23:54:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 12 Apr 2015 23:54:08 -0000 Subject: [GHC] #10291: compiling huge HashSet hogs memory In-Reply-To: <044.7ae1a7420fa208e82e754a0618131aa1@haskell.org> References: <044.7ae1a7420fa208e82e754a0618131aa1@haskell.org> Message-ID: <059.786fc223a9a2581090d46360ecb28dbe@haskell.org> #10291: compiling huge HashSet hogs memory -------------------------------------+------------------------------------- Reporter: zudov | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10289 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: new => closed * resolution: => duplicate * related: => #10289 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 13 00:43:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Apr 2015 00:43:20 -0000 Subject: [GHC] #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation In-Reply-To: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> References: <046.e40c84b285c82dadde0ff9ddf8e0c79c@haskell.org> Message-ID: <061.a26bbba860e2414dd3447346caf8a2da@haskell.org> #7655: 7.6.2 Segmentation Fault/Bus Error in large exponentation -------------------------------+----------------------------------------- Reporter: Doug310 | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.12.1 Component: GHCi | Version: 7.8.1-rc1 Resolution: | Keywords: exponentiation Operating System: MacOS X | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by rwbarton): OK, well, for now there's no GMP release with the bug fixed anyways... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 13 07:21:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Apr 2015 07:21:38 -0000 Subject: [GHC] #10288: -flate-dmd-anal triggers "Entered absent arg" In-Reply-To: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> References: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> Message-ID: <061.67bd3c199642059ab3fff1d5d3f106bd@haskell.org> #10288: -flate-dmd-anal triggers "Entered absent arg" -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Yes indeed! You should ''never'' get "Entered absent arg", so there's an outright bug there. But we can't fix it unless we can reproduce it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 13 07:28:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Apr 2015 07:28:52 -0000 Subject: [GHC] #10289: compiling huge HashSet hogs memory In-Reply-To: <044.7a75381e3cbd52797d1fc50b07f81ee0@haskell.org> References: <044.7a75381e3cbd52797d1fc50b07f81ee0@haskell.org> Message-ID: <059.e7f1ffba41f6ba0a4fd84d6681b9f402@haskell.org> #10289: compiling huge HashSet hogs memory -------------------------------------+------------------------------------- Reporter: zudov | Owner: Type: bug | Status: new Priority: normal | Milestone: 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 Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): What happens if you don't have the call to `S.fromList`? So your file looks like {{{ data :: [Text] data = [ pack "foo", pack "bar", ...etc... ] }}} Another thing to try is to cut it down a lot, use `-dshow-passes` and compare `HashSet` with `HashMap`. With luck you'll see that the latter is much larger on small examples too. Then you can use `ddump-simpl` to see what the expanded code looks like. Using `-ddump-inlinings` shows you what is being inlined. The fact that `HashSet` and `HashMap` differ here makes me think that this is to do with over-zealous inlining or rule-rewriting in `HashSet`. (`-ddump-rule-firings` to see which rewrite rules are firing.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 13 07:59:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Apr 2015 07:59:58 -0000 Subject: [GHC] #10293: CallArity taking 20% of compile time Message-ID: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> #10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The `CallArity` analysis can, apparently, take 20% of compile time. That's a lot for one analysis that is on by default with `-O`. Michael Terepeta writes: Out of curiosity I had a look at compiling haskell-src-exts since that takes quite a while. I've used ghc HEAD and 7.8.4 (both built with BuildFlavour=prof & bootstrapped with a standard ghc 7.8.4) and it's interesting -- the current HEAD takes quite a bit longer and allocates way more than 7.8.4. One of the main things that stand out is the CallArity analysis (which IIRC was not there in 7.8.4). So unless I messed something up with measuring, the analysis seem to be pretty expensive. HEAD {{{ Sun Apr 12 15:52 2015 Time and Allocation Profiling Report (Final) ghc +RTS -p -RTS [...] total time = 147.84 secs (147841 ticks @ 1000 us, 1 processor) total alloc = 172,378,600,408 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc SimplTopBinds SimplCore 32.4 28.8 CallArity SimplCore 18.4 25.6 lintAnnots CoreLint 4.5 4.6 CoreTidy HscMain 4.5 5.1 pprNativeCode AsmCodeGen 3.2 3.4 OccAnal SimplCore 3.2 3.1 occAnalBind.assoc OccurAnal 2.6 2.5 StgCmm HscMain 2.3 1.9 Simplify SimplCore 2.1 0.2 RegAlloc AsmCodeGen 2.1 2.4 FloatOutwards SimplCore 2.0 1.6 regLiveness AsmCodeGen 1.9 1.9 tc_rn_src_decls TcRnDriver 1.8 1.3 sink CmmPipeline 1.7 1.5 NewStranal SimplCore 1.3 1.5 genMachCode AsmCodeGen 1.1 1.0 layoutStack CmmPipeline 1.0 1.0 }}} HEAD with `-fno-call-arity` {{{ Sun Apr 12 18:16 2015 Time and Allocation Profiling Report (Final) ghc +RTS -p -RTS [...] -fno-call-arity total time = 113.71 secs (113714 ticks @ 1000 us, 1 processor) total alloc = 121,884,896,720 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc SimplTopBinds SimplCore 37.2 36.6 CoreTidy HscMain 6.0 7.3 lintAnnots CoreLint 5.8 6.5 pprNativeCode AsmCodeGen 4.1 4.8 OccAnal SimplCore 3.6 3.8 occAnalBind.assoc OccurAnal 2.9 3.2 StgCmm HscMain 2.9 2.6 RegAlloc AsmCodeGen 2.6 3.4 FloatOutwards SimplCore 2.6 2.3 regLiveness AsmCodeGen 2.5 2.8 tc_rn_src_decls TcRnDriver 2.4 1.9 Simplify SimplCore 2.4 0.3 sink CmmPipeline 2.1 2.2 NewStranal SimplCore 1.7 2.1 genMachCode AsmCodeGen 1.4 1.4 layoutStack CmmPipeline 1.4 1.4 NativeCodeGen CodeOutput 1.1 1.2 FloatInwards SimplCore 1.1 1.4 do_block Hoopl.Dataflow 1.0 0.6 Digraph.scc Digraph 0.8 1.3 }}} GHC 7.8.4 {{{ Sun Apr 12 15:41 2015 Time and Allocation Profiling Report (Final) ghc +RTS -p -RTS [...] total time = 93.11 secs (93112 ticks @ 1000 us, 1 processor) total alloc = 103,135,975,120 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc SimplTopBinds SimplCore 38.5 37.4 pprNativeCode AsmCodeGen 6.2 7.2 StgCmm HscMain 3.9 4.2 RegAlloc AsmCodeGen 3.7 5.1 occAnalBind.assoc OccurAnal 3.3 3.6 OccAnal SimplCore 3.3 3.6 regLiveness AsmCodeGen 3.1 3.4 FloatOutwards SimplCore 2.9 2.4 sink CmmPipeline 2.8 2.8 Simplify SimplCore 2.6 0.3 tc_rn_src_decls TcRnDriver 2.4 2.1 genMachCode AsmCodeGen 1.9 2.0 NewStranal SimplCore 1.8 2.1 layoutStack CmmPipeline 1.8 1.8 Core2Core HscMain 1.3 1.2 deSugar HscMain 1.1 1.1 do_block Hoopl.Dataflow 1.1 0.7 CoreTidy HscMain 1.0 1.1 CorePrep HscMain 1.0 1.1 Digraph.scc Digraph 0.9 1.5 versioninfo MkIface 0.9 1.0 zonkEvBndr_zonkTcTypeToType TcHsSyn 0.6 1.4 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 13 08:01:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Apr 2015 08:01:09 -0000 Subject: [GHC] #10293: CallArity taking 20% of compile time In-Reply-To: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> References: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> Message-ID: <061.cc347985bdc19d48b5c46a98ad0b5e1e@haskell.org> #10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => nomeata * priority: normal => high * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 13 08:38:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Apr 2015 08:38:33 -0000 Subject: [GHC] #10294: Missing instances if compiling with -fplugin Message-ID: <046.47fd486c7f73b488b5247db11cbe3c48@haskell.org> #10294: Missing instances if compiling with -fplugin -------------------------------------+------------------------------------- Reporter: jscholl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Linux Keywords: | Type of failure: GHC rejects Architecture: x86_64 | valid program (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Using the example from "9.3.3.2. Using Annotations" of the GHC user manual does not work correctly with GHC 7.10. The following fails: $ ghc -c Bug1.hs -fplugin=SayAnnNames.Plugin {{{ Bug1.hs:5:1: No instance for (Data SomeAnn) arising from an annotation In the annotation: {-# ANN foo SomeAnn #-} }}} It does not seem to matter why the type class is required: $ ghc -c Bug2.hs -fplugin=SayAnnNames.Plugin {{{ Bug2.hs:10:7: No instance for (Data SomeAnn) arising from a use of ?bar? In the expression: bar SomeAnn In an equation for ?baz?: baz = bar SomeAnn }}} Compiling without -fplugin works fine, though. If SomeAnn is defined in a different module than SayAnnNames.Plugin and reexported from it, the instances are in scope, too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 13 08:45:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Apr 2015 08:45:49 -0000 Subject: [GHC] #10286: native code generator: GHC crash at GHC.Prim SIMD vector In-Reply-To: <045.2537c47c79c85a06c9641d3e66088575@haskell.org> References: <045.2537c47c79c85a06c9641d3e66088575@haskell.org> Message-ID: <060.961c84a896f4ecd030289277d276cc54@haskell.org> #10286: native code generator: GHC crash at GHC.Prim SIMD vector -------------------------------------+------------------------------------- Reporter: hkanai | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * cc: gmainland (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 13 08:47:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Apr 2015 08:47:47 -0000 Subject: [GHC] #10292: Validate fails on armhf-linux In-Reply-To: <044.8055e40124ced0bf29d2dcf6e0c01c9f@haskell.org> References: <044.8055e40124ced0bf29d2dcf6e0c01c9f@haskell.org> Message-ID: <059.233c689bf622382b989d99f02931a13f@haskell.org> #10292: Validate fails on armhf-linux ----------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+--------------------------------- Comment (by erikd): @rwbarton : With this failure to build `dll-split` the stage2 compiler isn't complete, so how do I run the test suite? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 13 08:59:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Apr 2015 08:59:25 -0000 Subject: [GHC] #10295: Putting SCC in heavily inlined code results in "error: redefinition of global" Message-ID: <046.adbcfa466714e863665bb32dacf6e5dc@haskell.org> #10295: Putting SCC in heavily inlined code results in "error: redefinition of global" -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ /usr/bin/opt: /tmp/ghc27119_0/ghc27119_272.ll:21159722:1: error: redefinition of global named '@c17Kd9_info' @c17Kd9_info = alias internal i8* bitcast (void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @c17Kd9_info$def to i8*) ^ : ghc: phase `LLVM Optimiser' failed (exitcode = 1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 13 09:28:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Apr 2015 09:28:39 -0000 Subject: [GHC] #10293: CallArity taking 20% of compile time In-Reply-To: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> References: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> Message-ID: <061.5c8ea2428fc289a417ef8403f9960af3@haskell.org> #10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Thanks for the report. I did test its impact on GHC and nofib, and ensured that it would run reasonably fast, but it?s not unlikely that there are classes of programs where it goes through the roof. I?ll have a look, but I?ll first have to catch up a post-vaction backlog. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 13 09:38:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Apr 2015 09:38:38 -0000 Subject: [GHC] #10281: Type error with Rank-n-types In-Reply-To: <043.715543d69d09145192a2c9ffe2902dd1@haskell.org> References: <043.715543d69d09145192a2c9ffe2902dd1@haskell.org> Message-ID: <058.05050cdb21342627bb21a50ea1c5e23b@haskell.org> #10281: Type error with Rank-n-types -------------------------------------+------------------------------------- Reporter: rhjl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Peirce_eq_LEM.hs Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): When I copy/paste this into my emacs buffer the foralls show up ok but the a's and b's (and much else besides) do not. Could you do it in ASCII please? Do you think the program needs impredicative polymorphism? If so, GHC just doesn't properly support that, notwithstanding the partially implemented `-XImpredicativeTypes`. I'm not sure what "it accepts it if the product type is replaced by tuples" means. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 13 09:57:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Apr 2015 09:57:27 -0000 Subject: [GHC] #10189: explicit promotions of prefix data constructors can't be parsed naturally In-Reply-To: <048.7a1fa374089d49b55ac4c378c43baf5b@haskell.org> References: <048.7a1fa374089d49b55ac4c378c43baf5b@haskell.org> Message-ID: <063.5303caaaeb4c448a060e131b75c13da3@haskell.org> #10189: explicit promotions of prefix data constructors can't be parsed naturally -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Kinokkory Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10188 | -------------------------------------+------------------------------------- Comment (by simonpj): Would it really be so bad to change it so that the tick goes inside the parens? It'll only affect people using (a) promotion, (b) type operators, and (c) prefix use of same. I'd prefer just to get it right. I think of `':` as the name of the promoted constructor, and if you want it prefix you should wrap it in parens. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 13 10:46:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Apr 2015 10:46:43 -0000 Subject: [GHC] #10260: last uses too much space with optimizations disabled In-Reply-To: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> References: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> Message-ID: <062.7259d11c03ee3200c1bae6eba5bdade4@haskell.org> #10260: last uses too much space with optimizations disabled -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * owner: ekmett => nomeata Comment: When `foldl` started to be a good consumer, we implemented `last` using `foldl`, which is cool, but not helpful without optimization. I?ll take care of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 13 10:57:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Apr 2015 10:57:13 -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.8d31dd0909a6878bfa729f08552d7c8a@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I would love for someone to investigate this: * What exactly is happening? * Is it due to over-aggressive inlining in the `binary`? comment:7 suggests that might be so * Are there underlying issues in GHC itself? comment:10 suggests so. * If so, is the issue only that GHC is specialising too much? Or is it doing so uselessly or redundantly? And is it doing so by itself, or in response to user pragmas? * Even if GHC is behaving precisely as advertised, what should we do to stop this kind of code blow-up happening, or tell the user that it is happening, and give some clue about what to do? We are a bit stuck here until someone has the time and motivation to get some data. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 13 12:55:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Apr 2015 12:55:13 -0000 Subject: [GHC] #10296: Segfaults when using dynamic wrappers and concurrency Message-ID: <046.5415c655699223aa287cb69e9ee1b595@haskell.org> #10296: Segfaults when using dynamic wrappers and concurrency -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I had a largish program that sometimes segfaulted, the segfault seemingly coming from the code that gets a C pointer from an Haskell function. After much sweat I've managed to produce a self-contained program that exhibits the same behavior: {{{ bitonic at clay /tmp/ptr-crash % uname -a Linux clay 3.13.0-48-generic #80-Ubuntu SMP Thu Mar 12 11:16:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux bitonic at clay /tmp/ptr-crash % cabal configure --disable-library-profiling -w ghc-7.11.20150411 Resolving dependencies... Configuring ptr-crash-0... bitonic at clay /tmp/ptr-crash % cabal build Building ptr-crash-0... Preprocessing executable 'ptr-crash' for ptr-crash-0... [1 of 1] Compiling Main ( Main.hs, dist/build/ptr-crash/ptr- crash-tmp/Main.o ) Linking dist/build/ptr-crash/ptr-crash ... bitonic at clay /tmp/ptr-crash % strace -f -r -o strace-out ./dist/build/ptr- crash/ptr-crash +RTS -N2 -RTS [1] 26612 segmentation fault (core dumped) strace -f -r -o strace-out ./dist/build/ptr-crash/ptr-crash +RTS -N2 -RTS }}} I'm running GHC HEAD on a Linux 64bit machine. In the larger program, I'm pretty sure the segfaults happened on GHC 7.8.4 too, but currently I can reproduce it only on 7.10 and later. More details (thanks to Sergei Trofimovich on #ghc for helping me in investigating this): * The segfault only happens when using `-N2` or more. * Curiously, the segfault seems to happen much more often when compiling the program with `-g`. * `strace`ing the program when segfaulting shows that all the threads crash together right after some calls to `mremap`. I've attached the end of the output of `strace`. * `gdb`ing the program and breaking on `mremap` shows that all the calls to `mremap` originate from `getStablePtr`. I've attached a run of `gdb` that shows this pattern. Sergei had a hunch that this had to do with thread-unsafe calls to `mremap`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 13 13:03:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Apr 2015 13:03:01 -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.9998a07fa2e5ad6b21c6d9aa9dfccc89@haskell.org> #10296: Segfaults when using dynamic wrappers and concurrency -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by bitonic: Old description: > I had a largish program that sometimes segfaulted, the segfault seemingly > coming from the code that gets a C pointer from an Haskell function. > > After much sweat I've managed to produce a self-contained program that > exhibits the same behavior: > > {{{ > bitonic at clay /tmp/ptr-crash % uname -a > Linux clay 3.13.0-48-generic #80-Ubuntu SMP Thu Mar 12 11:16:15 UTC 2015 > x86_64 x86_64 x86_64 GNU/Linux > bitonic at clay /tmp/ptr-crash % cabal configure --disable-library-profiling > -w ghc-7.11.20150411 > Resolving dependencies... > Configuring ptr-crash-0... > bitonic at clay /tmp/ptr-crash % cabal build > Building ptr-crash-0... > Preprocessing executable 'ptr-crash' for ptr-crash-0... > [1 of 1] Compiling Main ( Main.hs, dist/build/ptr-crash/ptr- > crash-tmp/Main.o ) > Linking dist/build/ptr-crash/ptr-crash ... > bitonic at clay /tmp/ptr-crash % strace -f -r -o strace-out ./dist/build > /ptr-crash/ptr-crash +RTS -N2 -RTS > [1] 26612 segmentation fault (core dumped) strace -f -r -o strace-out > ./dist/build/ptr-crash/ptr-crash +RTS -N2 -RTS > }}} > > I'm running GHC HEAD on a Linux 64bit machine. In the larger program, > I'm pretty sure the segfaults happened on GHC 7.8.4 too, but currently I > can reproduce it only on 7.10 and later. > > More details (thanks to Sergei Trofimovich on #ghc for helping me in > investigating this): > > * The segfault only happens when using `-N2` or more. > * Curiously, the segfault seems to happen much more often when compiling > the program with `-g`. > * `strace`ing the program when segfaulting shows that all the threads > crash together right after some calls to `mremap`. I've attached the end > of the output of `strace`. > * `gdb`ing the program and breaking on `mremap` shows that all the calls > to `mremap` originate from `getStablePtr`. I've attached a run of `gdb` > that shows this pattern. > > Sergei had a hunch that this had to do with thread-unsafe calls to > `mremap`. New description: I had a largish program that sometimes segfaulted, the segfault seemingly coming from the code that gets a C pointer from an Haskell function. After much sweat I've managed to produce a self-contained program that exhibits the same behavior: {{{ bitonic at clay /tmp/ptr-crash % uname -a Linux clay 3.13.0-48-generic #80-Ubuntu SMP Thu Mar 12 11:16:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux bitonic at clay /tmp/ptr-crash % cabal configure --disable-library-profiling -w ghc-7.11.20150411 Resolving dependencies... Configuring ptr-crash-0... bitonic at clay /tmp/ptr-crash % cabal build Building ptr-crash-0... Preprocessing executable 'ptr-crash' for ptr-crash-0... [1 of 1] Compiling Main ( Main.hs, dist/build/ptr-crash/ptr- crash-tmp/Main.o ) Linking dist/build/ptr-crash/ptr-crash ... bitonic at clay /tmp/ptr-crash % strace -f -r -o strace-out ./dist/build/ptr- crash/ptr-crash +RTS -N2 -RTS [1] 26612 segmentation fault (core dumped) strace -f -r -o strace-out ./dist/build/ptr-crash/ptr-crash +RTS -N2 -RTS }}} I'm running GHC HEAD on a Linux 64bit machine. In the larger program, I'm pretty sure the segfaults happened on GHC 7.8.4 too, but currently I can reproduce it only on 7.10 and later. More details (thanks to Sergei Trofimovich on #ghc for helping me in investigating this): * The segfault only happens when using `-N2` or more. * Curiously, the segfault seems to happen much more often when compiling the program with `-g`. * `strace`ing the program when segfaulting shows that all the threads crash together right after some calls to `mremap`. I've attached the end of the output of `strace`. * `gdb`ing the program and breaking on `mremap` shows that all the calls to `mremap` originate from `getStablePtr`. I've attached a run of `gdb` that shows this pattern. Sergei had a hunch that this had to do with thread-unsafe calls to `stgReallocBytes` in `enlargeStablePtrTable`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 13 13:13:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Apr 2015 13:13:24 -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.76a2fb244ba6efc08a595efff6c67e26@haskell.org> #10296: Segfaults when using dynamic wrappers and concurrency -------------------------------------+------------------------------------- Reporter: bitonic | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by bitonic: Old description: > I had a largish program that sometimes segfaulted, the segfault seemingly > coming from the code that gets a C pointer from an Haskell function. > > After much sweat I've managed to produce a self-contained program that > exhibits the same behavior: > > {{{ > bitonic at clay /tmp/ptr-crash % uname -a > Linux clay 3.13.0-48-generic #80-Ubuntu SMP Thu Mar 12 11:16:15 UTC 2015 > x86_64 x86_64 x86_64 GNU/Linux > bitonic at clay /tmp/ptr-crash % cabal configure --disable-library-profiling > -w ghc-7.11.20150411 > Resolving dependencies... > Configuring ptr-crash-0... > bitonic at clay /tmp/ptr-crash % cabal build > Building ptr-crash-0... > Preprocessing executable 'ptr-crash' for ptr-crash-0... > [1 of 1] Compiling Main ( Main.hs, dist/build/ptr-crash/ptr- > crash-tmp/Main.o ) > Linking dist/build/ptr-crash/ptr-crash ... > bitonic at clay /tmp/ptr-crash % strace -f -r -o strace-out ./dist/build > /ptr-crash/ptr-crash +RTS -N2 -RTS > [1] 26612 segmentation fault (core dumped) strace -f -r -o strace-out > ./dist/build/ptr-crash/ptr-crash +RTS -N2 -RTS > }}} > > I'm running GHC HEAD on a Linux 64bit machine. In the larger program, > I'm pretty sure the segfaults happened on GHC 7.8.4 too, but currently I > can reproduce it only on 7.10 and later. > > More details (thanks to Sergei Trofimovich on #ghc for helping me in > investigating this): > > * The segfault only happens when using `-N2` or more. > * Curiously, the segfault seems to happen much more often when compiling > the program with `-g`. > * `strace`ing the program when segfaulting shows that all the threads > crash together right after some calls to `mremap`. I've attached the end > of the output of `strace`. > * `gdb`ing the program and breaking on `mremap` shows that all the calls > to `mremap` originate from `getStablePtr`. I've attached a run of `gdb` > that shows this pattern. > > Sergei had a hunch that this had to do with thread-unsafe calls to > `stgReallocBytes` in `enlargeStablePtrTable`. New description: I had a largish program that sometimes segfaulted, the segfault seemingly coming from the code that gets a C pointer from an Haskell function. After much sweat I've managed to produce a self-contained program that exhibits the same behavior: {{{ bitonic at clay /tmp/ptr-crash % uname -a Linux clay 3.13.0-48-generic #80-Ubuntu SMP Thu Mar 12 11:16:15 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux bitonic at clay /tmp/ptr-crash % cabal configure --disable-library-profiling -w ghc-7.11.20150411 Resolving dependencies... Configuring ptr-crash-0... bitonic at clay /tmp/ptr-crash % cabal build Building ptr-crash-0... Preprocessing executable 'ptr-crash' for ptr-crash-0... [1 of 1] Compiling Main ( Main.hs, dist/build/ptr-crash/ptr- crash-tmp/Main.o ) Linking dist/build/ptr-crash/ptr-crash ... bitonic at clay /tmp/ptr-crash % strace -f -r -o strace-out ./dist/build/ptr- crash/ptr-crash +RTS -N2 -RTS [1] 26612 segmentation fault (core dumped) strace -f -r -o strace-out ./dist/build/ptr-crash/ptr-crash +RTS -N2 -RTS }}} I'm running GHC HEAD on a Linux 64bit machine. In the larger program, I'm pretty sure the segfaults happened on GHC 7.8.4 too, but currently I can reproduce it only on 7.10 and later. More details (thanks to Sergei Trofimovich on #ghc for helping me in investigating this): * The segfault only happens when using `-N2` or more. * Curiously, the segfault seems to happen much more often when compiling the program with `-g`. * The segfault doesn't happen every time, I get it roughly half of the times on my machine. * `strace`ing the program when segfaulting shows that all the threads crash together right after some calls to `mremap`. I've attached the end of the output of `strace`. * `gdb`ing the program and breaking on `mremap` shows that all the calls to `mremap` originate from `getStablePtr`. I've attached a run of `gdb` that shows this pattern. * The segfault only happens with repeated calls to the dynamic wrapper and with certain timings, which explains the weird nature of the example (I kind of mimicked the behaviour of a C function we were calling from a proprietary C library). Note that the call to `sum_arr` is not really important and it's there just so that some time is spent in the callback -- the example works equally well if we convert the pointer to an Haskell vector and sum it from Haskell. Sergei had a hunch that this had to do with thread-unsafe calls to `stgReallocBytes` in `enlargeStablePtrTable`. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 13 15:06:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Apr 2015 15:06:52 -0000 Subject: [GHC] #10295: Putting SCC in heavily inlined code results in "error: redefinition of global" In-Reply-To: <046.adbcfa466714e863665bb32dacf6e5dc@haskell.org> References: <046.adbcfa466714e863665bb32dacf6e5dc@haskell.org> Message-ID: <061.ee363f2f19e39ee9545a060034663ead@haskell.org> #10295: Putting SCC in heavily inlined code results in "error: redefinition of global" -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by yongqli): Here is another error message: {{{ /usr/bin/opt: /tmp/ghc7745_0/ghc7745_56.ll:20727482:1: error: redefinition of type %iAupe_str_struct = type <{[36 x i8]}> ^ : ghc: phase `LLVM Optimiser' failed (exitcode = 1) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 13 15:11:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Apr 2015 15:11:31 -0000 Subject: [GHC] #10295: Putting SCC in heavily inlined code results in "error: redefinition of global" In-Reply-To: <046.adbcfa466714e863665bb32dacf6e5dc@haskell.org> References: <046.adbcfa466714e863665bb32dacf6e5dc@haskell.org> Message-ID: <061.ec832147a28ffc467e220cce4c309fef@haskell.org> #10295: Putting SCC in heavily inlined code results in "error: redefinition of global" -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Hi, sorry to sound like a broken record, but can you provide a reproducer? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 13 15:56:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Apr 2015 15:56:45 -0000 Subject: [GHC] #10293: CallArity taking 20% of compile time In-Reply-To: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> References: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> Message-ID: <061.88c8352d9fd60de88cb68dbb54e27eb7@haskell.org> #10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * cc: michal.terepeta@? (added) Comment: Michal, with what module of `haskell-src-exts` can this behavior be observed? How exactly did you invoke ghc to get that output? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 13 20:51:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 13 Apr 2015 20:51:29 -0000 Subject: [GHC] #10293: CallArity taking 20% of compile time In-Reply-To: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> References: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> Message-ID: <061.d3a9b185d8a8a0b08774ad33f98b19e4@haskell.org> #10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): The culprit is `callArityRecEnv` , which analyzes recursive groups and calls `calledWith` with quadratic complexity. I might have an idea for way to shortcut this. Or maybe the code should revert to a quick and conservative conversation when analyzing a very large recursive group ? the largest here is has 754 mutually recursive definitions. I?ll need to ponder this some more. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 02:35:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 02:35:19 -0000 Subject: [GHC] #10297: Floating instance for Data.Fixed Message-ID: <047.6d0ff544700b8087a9f68c3a44a1bbc7@haskell.org> #10297: Floating instance for Data.Fixed -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'd like to contribute a Floating instance for Data.Fixed. I'm concerned that it may be undesirable for a reason that is not occurring to me; I'd be pleased to learn of any objections. In concept it's this, although I will investigate if there is an implementation with better performance: {{{ lift :: (HasResolution a) => (Double -> Double) -> Fixed a -> Fixed a lift f = realToFrac . f . realToFrac instance (HasResolution a) => Floating (Fixed a) where pi = realToFrac pi sin = lift sin -- etc, similar lift2 function for (**), logBase }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 06:20:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 06:20:03 -0000 Subject: [GHC] #10232: versionedAppDir ignores projectVersion from DynFlags In-Reply-To: <044.192b03678e7009d8d199d6157ad48aaf@haskell.org> References: <044.192b03678e7009d8d199d6157ad48aaf@haskell.org> Message-ID: <059.9bcad047cf70ca043397513119da1733@haskell.org> #10232: versionedAppDir ignores projectVersion from DynFlags -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D824 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"6109b312cdd9dfe4bdad4030e0185dd67e6ec18d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6109b312cdd9dfe4bdad4030e0185dd67e6ec18d" use projectVersion from DynFlags rather than cProjectVersion for versionedAppDir Reviewed By: edsko, austin Differential Revision: https://phabricator.haskell.org/D824 GHC Trac Issues: #10232 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 06:20:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 06:20:03 -0000 Subject: [GHC] #10209: parser: opt_kind_sig has incorrect SrcSpan In-Reply-To: <044.4df35a96b087f820c01c3c57f4238bf6@haskell.org> References: <044.4df35a96b087f820c01c3c57f4238bf6@haskell.org> Message-ID: <059.c6ed687d1879a3f33246157ef9aa875f@haskell.org> #10209: parser: opt_kind_sig has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D813 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"8aefc9b746512e91891879ad546e850e8a427d23/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8aefc9b746512e91891879ad546e850e8a427d23" parser: opt_kind_sig has incorrect SrcSpan The production for opt_kind_sig is opt_kind_sig :: { Located (Maybe (LHsKind RdrName)) } : { noLoc Nothing } | '::' kind {% ajl (sLL $1 $> (Just $2)) AnnDcolon (gl $1) } The outer Location is used only to get the full span for the enclosing declration, and is then stripped. The inner LHsKind then has a SrcSpan that does not include the '::' Extend the SrcSpan on $2 to include $1 Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D813 GHC Trac Issues: #10209 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 06:20:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 06:20:03 -0000 Subject: [GHC] #10256: parser: API Annotations : guardquals1 does not annotate commas properly In-Reply-To: <044.8484e8ecf97da86fae5e843371f60830@haskell.org> References: <044.8484e8ecf97da86fae5e843371f60830@haskell.org> Message-ID: <059.6715a29cf86258e39db4aa5f119abcb3@haskell.org> #10256: parser: API Annotations : guardquals1 does not annotate commas properly -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D818 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"9eab6feed44ad8beb6703d2e27ce47a8f79d0f49/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9eab6feed44ad8beb6703d2e27ce47a8f79d0f49" parser: API Annotations : guardquals1 does not annotate commas properly The `guardquals1` production includes : guardquals1 ',' qual {% addAnnotation (gl $ last $ unLoc $1) AnnComma (gl $2) >> return (sLL $1 $> ($3 : unLoc $1)) } The AnnComma should be attached to `(gl $ head $ unLoc $1)`, rather than `last`. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D818 GHC Trac Issues: #10256 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 06:20:03 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 06:20:03 -0000 Subject: [GHC] #10254: parser : the API annotation on opt_sig is being discarded In-Reply-To: <044.a5d202689c44d12743acba1f8d07ab48@haskell.org> References: <044.a5d202689c44d12743acba1f8d07ab48@haskell.org> Message-ID: <059.b927fc67e2b274e26d2b5de4de10fe79@haskell.org> #10254: parser : the API annotation on opt_sig is being discarded -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D822 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"919b51174163907d2bc3bb41aadf56aa8bb42e9b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="919b51174163907d2bc3bb41aadf56aa8bb42e9b" parser : the API annotation on opt_sig is being discarded The opt_sig production is defined as opt_sig :: { ([AddAnn],Maybe (LHsType RdrName)) } : {- empty -} { ([],Nothing) } | '::' sigtype { ([mj AnnDcolon $1],Just $2) } It is used in the alt and decl_no_th productions, but neither of them add the returned annotations. This commit captures the annotations in the calling productions. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D822 GHC Trac Issues: #10254 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 08:19:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 08:19:01 -0000 Subject: [GHC] #7782: flag to run the demand analysis a second time In-Reply-To: <046.1ec01ebe7149b378f35843d2bc9ef200@haskell.org> References: <046.1ec01ebe7149b378f35843d2bc9ef200@haskell.org> Message-ID: <061.a04d4baf391d8b9fb4931f47bcfaa3a1@haskell.org> #7782: flag to run the demand analysis a second time -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: task | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #4941, #5302, | Blocking: #6087, #4962 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * owner: nfrisby => * priority: normal => high * status: closed => new * resolution: fixed => * milestone: 7.8.1 => 7.12.1 Comment: I'm re-opening this because we have not yet enabled `-flate-dmd-anal` by default, and I think we should. But there are caveats on [wike:LateDmd the LateDmd wiki page] that need exploring first. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 08:40:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 08:40:30 -0000 Subject: [GHC] #10298: Infinite loop when shared libraries are unavailable Message-ID: <047.ac4f2671f8ae23d583742150fb22d7b0@haskell.org> #10298: Infinite loop when shared libraries are unavailable -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.1 System | Operating System: Linux Keywords: | Type of failure: Runtime crash Architecture: x86_64 | Blocked By: (amd64) | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Originally discussed at: https://groups.google.com/d/msg/haskell- cafe/5ZTv5mCG_HI/hBJ-VkdpxdoJ. Note that this was originally discussed as a static linking and Docker issue, but in fact affects dynamically linked executables without any containerization. I've put together the following script that reproduces my problem: {{{ cat > hello.hs < GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 09:50:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 09:50:00 -0000 Subject: [GHC] #10299: Inconsistent parsing of lifted list constructor Message-ID: <049.6a78eb4929167a3ada10a0a68f52f171@haskell.org> #10299: Inconsistent parsing of lifted list constructor -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The notes for `HsType` explain that `'[]` should parse as a `HsExplicitListTy` but it currently parses as a `HsTyVar`. I think this shift-reduce conflict might be to blame? {{{#!hs state 432 contains 1 shift/reduce conflicts. atype -> SIMPLEQUOTE '[' . comma_types0 ']' (rule 318) sysdcon -> '[' . ']' (rule 613) Conflict: ']' (empty comma_types0 reudes) TODO: Why? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 10:48:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 10:48:52 -0000 Subject: [GHC] #10300: GHC rejects Message-ID: <047.9ca79e7bce130229c5ace8ca6586ad67@haskell.org> #10300: GHC rejects -------------------------------------+------------------------------------- Reporter: mhwombat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: 10020 Differential Revisions: | -------------------------------------+------------------------------------- In GHC 7.8.4, the following code is legal: {{{ {-# LANGUAGE TypeFamilies, FlexibleContexts #-} class FiniteGrid g where type Size s size :: g -> Size g maxPossibleDistance :: g -> Int }}} But with GHC 7.10.1, it no longer compiles. The error message is: {{{ The associated type ?Size? mentions none of the type or kind variables of the class ?FiniteGrid g? In the class declaration for ?FiniteGrid? }}} I didn't see any mention of this in the migration guide, but perhaps there's another pragma I need to enable. I thought this might be related to https://ghc.haskell.org/trac/ghc/ticket/10020, but that bug is apparently fixed in GHC 7.10.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 10:52:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 10:52:48 -0000 Subject: [GHC] #10300: GHC rejects typeclass with associated type (was: GHC rejects) In-Reply-To: <047.9ca79e7bce130229c5ace8ca6586ad67@haskell.org> References: <047.9ca79e7bce130229c5ace8ca6586ad67@haskell.org> Message-ID: <062.d5d04095aa1e1b77fb33f72397e287ba@haskell.org> #10300: GHC rejects typeclass with associated type -------------------------------------+------------------------------------- Reporter: mhwombat | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: 10020 | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 11:15:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 11:15:20 -0000 Subject: [GHC] #10300: GHC rejects typeclass with associated type In-Reply-To: <047.9ca79e7bce130229c5ace8ca6586ad67@haskell.org> References: <047.9ca79e7bce130229c5ace8ca6586ad67@haskell.org> Message-ID: <062.a59dba2cd6deb19b6383480a1e01d9be@haskell.org> #10300: GHC rejects typeclass with associated type -------------------------------------+------------------------------------- Reporter: mhwombat | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: 10020 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid Comment: There's nothing to connect `Size` with `FiniteGrid`; it's not an ''associated'' type at all. You can just define it separately: {{{ type family Size s class FiniteGrid g where size :: g -> Size g maxPossibleDistance :: g -> Int }}} Or, if you want to guarantee you always have an instance of `Size g` whenever you have an instance of `FiniteGrid g`, then use `g` in `Size`'s definition: {{{ class FiniteGrid g where type Size g size :: g -> Size g maxPossibleDistance :: g -> Int }}} This isn't a bug in 7.10; rather it was a bug in 7.8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 11:32:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 11:32:24 -0000 Subject: [GHC] #10299: Inconsistent parsing of lifted list constructor In-Reply-To: <049.6a78eb4929167a3ada10a0a68f52f171@haskell.org> References: <049.6a78eb4929167a3ada10a0a68f52f171@haskell.org> Message-ID: <064.f0d1738bc34fc5cebed7fc7d1bab49d7@haskell.org> #10299: Inconsistent parsing of lifted list constructor -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: D840 -------------------------------------+------------------------------------- Changes (by mpickering): * status: new => patch * differential: => D840 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 12:13:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 12:13:37 -0000 Subject: [GHC] #10218: GHC creates incorrect code which throws <> In-Reply-To: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> References: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> Message-ID: <061.30124fc2de25d762fa2a9c247f3c0adb@haskell.org> #10218: GHC creates incorrect code which throws <> -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: yes Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"d261d4cbcc867405f71d7c9580628f52978e2267/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d261d4cbcc867405f71d7c9580628f52978e2267" Zap usage info in CSE (Trac #10218) Trac #10218 reports a subtle bug that turned out to be: - CSE invalidated the usage information computed by earlier demand analysis, by increasing sharing - that made a single-entry thunk into a multi-entry thunk - and with -feager-blackholing, that led to <> The patch fixes it by making the CSE pass zap usage information for let-bound identifiers. It can be restored by -flate-dmd-anal. (But making -flate-dmd-anal the default needs some careful work; see Trac #7782.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 12:13:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 12:13:37 -0000 Subject: [GHC] #7782: flag to run the demand analysis a second time In-Reply-To: <046.1ec01ebe7149b378f35843d2bc9ef200@haskell.org> References: <046.1ec01ebe7149b378f35843d2bc9ef200@haskell.org> Message-ID: <061.1bb4e9481da81a5e333eeb92b7d8a7d6@haskell.org> #7782: flag to run the demand analysis a second time -------------------------------------+------------------------------------- Reporter: nfrisby | Owner: Type: task | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #4941, #5302, | Blocking: #6087, #4962 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"d261d4cbcc867405f71d7c9580628f52978e2267/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d261d4cbcc867405f71d7c9580628f52978e2267" Zap usage info in CSE (Trac #10218) Trac #10218 reports a subtle bug that turned out to be: - CSE invalidated the usage information computed by earlier demand analysis, by increasing sharing - that made a single-entry thunk into a multi-entry thunk - and with -feager-blackholing, that led to <> The patch fixes it by making the CSE pass zap usage information for let-bound identifiers. It can be restored by -flate-dmd-anal. (But making -flate-dmd-anal the default needs some careful work; see Trac #7782.) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 12:20:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 12:20:50 -0000 Subject: [GHC] #10218: GHC creates incorrect code which throws <> In-Reply-To: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> References: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> Message-ID: <061.3335dcfea77c362fe8b39f35a6a8bed3@haskell.org> #10218: GHC creates incorrect code which throws <> -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | strianal/should_run/T10218 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: yes => strianal/should_run/T10218 Comment: Right I've fixed this. Thank you for identifying it. I'm really sorry it cost you so much to track down. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 12:21:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 12:21:27 -0000 Subject: [GHC] #10218: GHC creates incorrect code which throws <> In-Reply-To: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> References: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> Message-ID: <061.736a8698881f7b3ec4b7e5ff2f85a886@haskell.org> #10218: GHC creates incorrect code which throws <> -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | strianal/should_run/T10218 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * milestone: => 7.10.2 Comment: Merge to 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 12:31:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 12:31:14 -0000 Subject: [GHC] #10299: Inconsistent parsing of lifted list constructor In-Reply-To: <049.6a78eb4929167a3ada10a0a68f52f171@haskell.org> References: <049.6a78eb4929167a3ada10a0a68f52f171@haskell.org> Message-ID: <064.2257a448b5509af35073764ecc3960e5@haskell.org> #10299: Inconsistent parsing of lifted list constructor -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: D840 -------------------------------------+------------------------------------- Changes (by mpickering): * milestone: => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 12:33:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 12:33:18 -0000 Subject: [GHC] #10021: Add "Error:" prefix for compile-time error messages In-Reply-To: <043.cd50774548df3d55e921eb94882437a4@haskell.org> References: <043.cd50774548df3d55e921eb94882437a4@haskell.org> Message-ID: <058.237b1a295be3ed84a79cc0ae2713e27b@haskell.org> #10021: Add "Error:" prefix for compile-time error messages -------------------------------------+------------------------------------- Reporter: k-bx | Owner: k-bx Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"7febc2bb86b238713cfb9f52dff32039464dfe66/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7febc2bb86b238713cfb9f52dff32039464dfe66" Add "error:" prefix to error-messages Add "error:" prefix to error-messages, also lowercase "Warning:" message to match GCC behavior closer. Reviewed By: thomie, austin Differential Revision: https://phabricator.haskell.org/D811 GHC Trac Issues: #10021 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 12:33:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 12:33:18 -0000 Subject: [GHC] #10255: API Annotations : ExprWithTySig processing discards annotated spans In-Reply-To: <044.3995d3b4b19bd7e56b8289f8de527db1@haskell.org> References: <044.3995d3b4b19bd7e56b8289f8de527db1@haskell.org> Message-ID: <059.5b079259d0d8e44e37cb7062b3d019b2@haskell.org> #10255: API Annotations : ExprWithTySig processing discards annotated spans -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D823 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"8dc294487fdaf102349c373c7db4796693573310/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8dc294487fdaf102349c373c7db4796693573310" API Annotations : ExprWithTySig processing discards annotated spans In RdrHsSyn.checkAPat the processing for ExprWithTySig is defined as ExprWithTySig e t _ -> do e <- checkLPat msg e -- Pattern signatures are parsed as sigtypes, -- but they aren't explicit forall points. Hence -- we have to remove the implicit forall here. let t' = case t of L _ (HsForAllTy Implicit _ _ (L _ []) ty) -> ty other -> other return (SigPatIn e (mkHsWithBndrs t')) The t' variable ends up losing its original SrcSpan in the first case branch. This results in annotations becoming detached from the AST. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D823 GHC Trac Issues: #10255 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 12:33:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 12:33:18 -0000 Subject: [GHC] #10277: ApiAnnotations : lexer discards comment close in nested comment In-Reply-To: <044.23b3ff5c4f760c1e4ecc1ce3ba0c35c5@haskell.org> References: <044.23b3ff5c4f760c1e4ecc1ce3ba0c35c5@haskell.org> Message-ID: <059.4204b400bdbae2194d9e4a5ea17bc22f@haskell.org> #10277: ApiAnnotations : lexer discards comment close in nested comment -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D829 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"5fded20c51ae61770f909351c851aaca3d3e331c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5fded20c51ae61770f909351c851aaca3d3e331c" ApiAnnotations : lexer discards comment close in nested comment When parsing a nested comment, such as {- {- nested comment -} {-# nested pragma #-} -} The lexer returns the comment annotation as {- {- nested comment {-# nested pragma # -} Restore the missing comment end markers in the annotation. Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D829 GHC Trac Issues: #10277 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 12:39:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 12:39:45 -0000 Subject: [GHC] #9929: New alias handling not compatible with LLVM 3.4 In-Reply-To: <047.16e0d585b02943379458702a5beede5a@haskell.org> References: <047.16e0d585b02943379458702a5beede5a@haskell.org> Message-ID: <062.fb6a11471c72f4605cabebe3eda6b8a1@haskell.org> #9929: New alias handling not compatible with LLVM 3.4 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler (LLVM) | Version: 7.10.1-rc1 Resolution: worksforme | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => worksforme Comment: Yes, so I think for this one the answer simply is: 7.10 only supports LLVM 3.5. 7.12 will support LLVM 3.6 exclusively. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 12:44:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 12:44:00 -0000 Subject: [GHC] #10301: Plugins/dynamic loading subtly broken (it seems) Message-ID: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> #10301: Plugins/dynamic loading subtly broken (it seems) -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice | Status: new Type: bug | Milestone: 7.10.2 Priority: normal | Version: 7.8.2 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time Architecture: | crash Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #8276 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Imported from #8276, which was originally about a Haddock bug (that was different in nature but appeared similarly): > I still experience this panic on GHC 7.8.2 with Windows x86_64: > > {{{ > $ ghci > GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > ?> import StaticFlags > ?> import Data.IORef > ?> readIORef v_opt_C_ready > Loading package array-0.5.0.0 ... linking ... done. > Loading package deepseq-1.3.0.2 ... linking ... done. > Loading package bytestring-0.10.4.0 ... linking ... done. > Loading package containers-0.5.5.1 ... linking ... done. > Loading package Win32-2.3.0.2 ... linking ... done. > Loading package filepath-1.3.0.2 ... linking ... done. > Loading package old-locale-1.0.0.6 ... linking ... done. > Loading package time-1.4.2 ... linking ... done. > Loading package directory-1.2.1.0 ... linking ... done. > Loading package pretty-1.1.1.1 ... linking ... done. > Loading package process-1.2.0.0 ... linking ... done. > Loading package Cabal-1.18.1.3 ... linking ... done. > Loading package binary-0.7.1.0 ... linking ... done. > Loading package bin-package-db-0.0.0.0 ... linking ... done. > Loading package hoopl-3.10.0.1 ... linking ... done. > Loading package hpc-0.6.0.1 ... linking ... done. > Loading package template-haskell ... linking ... done. > Loading package transformers-0.3.0.0 ... linking ... done. > Loading package ghc-7.8.2 ... linking ... done. > False > ?> staticFlags > ghc.exe: panic! (the 'impossible' happened) > (GHC version 7.8.2 for x86_64-unknown-mingw32): > Static flags have not been initialised! > Please call GHC.parseStaticFlags early enough. > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} > > But not with GHC 7.8.2 on Linux x86_64: > > {{{ > $ ghci > GHCi, version 7.8.2: http://www.haskell.org/ghc/ :? for help > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > ?> import StaticFlags > ?> import Data.IORef > ?> readIORef v_opt_C_ready > Loading package array-0.5.0.0 ... linking ... done. > Loading package deepseq-1.3.0.2 ... linking ... done. > Loading package bytestring-0.10.4.0 ... linking ... done. > Loading package containers-0.5.5.1 ... linking ... done. > Loading package filepath-1.3.0.2 ... linking ... done. > Loading package old-locale-1.0.0.6 ... linking ... done. > Loading package time-1.4.2 ... linking ... done. > Loading package directory-1.2.1.0 ... linking ... done. > Loading package pretty-1.1.1.1 ... linking ... done. > Loading package process-1.2.0.0 ... linking ... done. > Loading package Cabal-1.18.1.3 ... linking ... done. > Loading package binary-0.7.1.0 ... linking ... done. > Loading package bin-package-db-0.0.0.0 ... linking ... done. > Loading package hoopl-3.10.0.1 ... linking ... done. > Loading package hpc-0.6.0.1 ... linking ... done. > Loading package template-haskell ... linking ... done. > Loading package transformers-0.3.0.0 ... linking ... done. > Loading package ghc-7.8.2 ... linking ... done. > True > ?> staticFlags > [] > }}} > > This has caused problems for me when running programs such as [https://github.com/ku-fpg/hermit/ HERMIT] on Windows, since at some point, {{{parseStaticFlagsFull}}} seems to be called during program execution. A workaround is to call {{{initStaticOpts}}} manually somewhere in the program, but I feel like that shouldn't be necessary. The one above was on Windows. Also reported: > Hello, > > A similar panic also happens when running Liquid Haskell [http://goto.ucsd.edu/~rjhala/liquid/haskell/blog/about/] on a file that uses the Units of Measure plugin [https://github.com/adamgundry/uom- plugin] > > > {{{ > liquid: liquid: panic! (the 'impossible' happened) > (GHC version 7.10.1 for x86_64-unknown-linux): > Static flags have not been initialised! > Please call GHC.parseStaticFlags early enough. > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 12:44:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 12:44:36 -0000 Subject: [GHC] #8276: Building Haddock documentation panics with perf build on x86_64 Linux In-Reply-To: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> References: <048.6eaa6527f51982ca38401152cff0124f@haskell.org> Message-ID: <063.52bc0e3e89cc2697c9e5a161c7ec84ff@haskell.org> #8276: Building Haddock documentation panics with perf build on x86_64 Linux -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | thoughtpolice Priority: high | Status: closed Component: Documentation | Milestone: 7.10.2 Resolution: fixed | Version: 7.7 Operating System: Unknown/Multiple | Keywords: Type of failure: Compile-time | Architecture: x86_64 crash | (amd64) Blocked By: | Test Case: Related Tickets: #10301 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed * related: => #10301 Comment: Okay, so I'm closing this ticket and opening a new one in its place for the new plugins failure, which is totally unrelated to the original issue in this ticket: Please see #10301 for further discussion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 12:49:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 12:49:55 -0000 Subject: [GHC] #10218: GHC creates incorrect code which throws <> In-Reply-To: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> References: <046.fb01ac7cee832b0e4580cdada1373801@haskell.org> Message-ID: <061.2567e9c6fffce095c1db59e0c2467eaf@haskell.org> #10218: GHC creates incorrect code which throws <> -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | strianal/should_run/T10218 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10` via 5c10c69849c8029db5b5e7ee540df308d8941957 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 12:50:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 12:50:06 -0000 Subject: [GHC] #10148: Optimization causes repeated computation In-Reply-To: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> References: <043.eb4bcc26d4faf643f86e26d342c2d9f1@haskell.org> Message-ID: <058.2de4b57168c85e377e7e96fd1f16b110@haskell.org> #10148: Optimization causes repeated computation -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | stranal/should_run/T10148 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10` via 37f928aa8bb55f888ca6e22ec9f8605f695d0b44 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 12:52:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 12:52:06 -0000 Subject: [GHC] #10274: foreign import ccall "rand" in System.IO fails on Android In-Reply-To: <047.c01313c49328bdb7ebd948eb990c1812@haskell.org> References: <047.c01313c49328bdb7ebd948eb990c1812@haskell.org> Message-ID: <062.5b95666f9639566ff80cddc762e26016@haskell.org> #10274: foreign import ccall "rand" in System.IO fails on Android -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: merge Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Other | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D826 -------------------------------------+------------------------------------- Comment (by thoughtpolice): Merged to `ghc-7.10`, via cf621d936eea7406bc87daa97346ec15a16c36f9 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 12:52:08 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 12:52:08 -0000 Subject: [GHC] #10232: versionedAppDir ignores projectVersion from DynFlags In-Reply-To: <044.192b03678e7009d8d199d6157ad48aaf@haskell.org> References: <044.192b03678e7009d8d199d6157ad48aaf@haskell.org> Message-ID: <059.1ae032909d13148a49f0bdbbcaef1339@haskell.org> #10232: versionedAppDir ignores projectVersion from DynFlags -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D824 -------------------------------------+------------------------------------- Comment (by thoughtpolice): Merged to `ghc-7.10`, via c46e4b184e0abc158ad8f1eff6b3f0421acaf984 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 12:52:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 12:52:18 -0000 Subject: [GHC] #10232: versionedAppDir ignores projectVersion from DynFlags In-Reply-To: <044.192b03678e7009d8d199d6157ad48aaf@haskell.org> References: <044.192b03678e7009d8d199d6157ad48aaf@haskell.org> Message-ID: <059.f51074c4ffb2dab08f01fb2d385db011@haskell.org> #10232: versionedAppDir ignores projectVersion from DynFlags -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D824 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 12:52:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 12:52:33 -0000 Subject: [GHC] #10274: foreign import ccall "rand" in System.IO fails on Android In-Reply-To: <047.c01313c49328bdb7ebd948eb990c1812@haskell.org> References: <047.c01313c49328bdb7ebd948eb990c1812@haskell.org> Message-ID: <062.fb2bf380d45e6f1e48269a94c0b93977@haskell.org> #10274: foreign import ccall "rand" in System.IO fails on Android -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Other | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D826 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 12:53:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 12:53:58 -0000 Subject: [GHC] #10275: LLVM/cross-compilation fixes to be backported In-Reply-To: <047.198f43801006c337c216b389cb955d85@haskell.org> References: <047.198f43801006c337c216b389cb955d85@haskell.org> Message-ID: <062.f138b52fe6403de68d7eac5ab2dacf19@haskell.org> #10275: LLVM/cross-compilation fixes to be backported -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Build System | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.10.2 Comment: These have all been merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 13:11:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 13:11:27 -0000 Subject: [GHC] #10195: GHC forgets constraints when matching on GADTs In-Reply-To: <047.0020e481c0d5cc2154e7ca7e404b2a9e@haskell.org> References: <047.0020e481c0d5cc2154e7ca7e404b2a9e@haskell.org> Message-ID: <062.d68a4d3bc7015817a275cf2888d555fd@haskell.org> #10195: GHC forgets constraints when matching on GADTs -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | typecheck/should_compile/T10195 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 13:17:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 13:17:58 -0000 Subject: [GHC] #10233: Reexporting GHC.Exts does not export Constraint In-Reply-To: <044.25d86cfd1dd1041b5ff2433b8060fd47@haskell.org> References: <044.25d86cfd1dd1041b5ff2433b8060fd47@haskell.org> Message-ID: <059.05f7c71c4c7add9db8637b64fd0ad097@haskell.org> #10233: Reexporting GHC.Exts does not export Constraint -------------------------------------+------------------------------------- Reporter: int-e | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | module/T10233 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.10.2 Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 13:54:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 13:54:48 -0000 Subject: [GHC] #10177: Typeable solver regression In-Reply-To: <044.31773993d01a9acbca1586a9db429c36@haskell.org> References: <044.31773993d01a9acbca1586a9db429c36@haskell.org> Message-ID: <059.a1ead6915b14e8ceae4ca0fe7fe20d14@haskell.org> #10177: Typeable solver regression -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.10.1-rc3 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | testsuite/tests/typecheck/should_compile/T10177 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.2 => 7.12.1 Comment: Confirmed working on 7.10.1, so we can punt this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 14:11:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 14:11:17 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.e2c8cc6add693a892d0e7aeca63c6627@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D807 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"6dd2765a300bb139b4ab67688dbc6f48de66969b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6dd2765a300bb139b4ab67688dbc6f48de66969b" Implement -f[no-]print-unicode-syntax flag for unicode syntax output (#8959) There is currently no way to separate whether UnicodeSyntax is accepted for input from the corresponding output syntax using unicode symbols. This patch implements a separate flag for affecting ghc(i)'s output. Signed-off-by: Bertram Felgenhauer Reviewed By: nomeata, austin Differential Revision: https://phabricator.haskell.org/D807 GHC Trac Issues: #8959 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 14:39:07 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 14:39:07 -0000 Subject: [GHC] #8959: GHCi should honour UnicodeSyntax In-Reply-To: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> References: <047.a751656a0ddf1c2d9cc985188b248eaa@haskell.org> Message-ID: <062.e3c6e31cc9bdca98ce44a2a1ea344dd1@haskell.org> #8959: GHCi should honour UnicodeSyntax -------------------------------------+------------------------------------- Reporter: Fuuzetsu | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D807 -------------------------------------+------------------------------------- Comment (by int-e): Is there a chance of getting the -fprint-unicode-syntax flag into 7.10.2? Personally I think the chances of breaking anything are slim, but it's not an easy call to make. (I still regret that I didn't find this in the RCs) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 14:40:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 14:40:20 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.fcf22eb1e9080b6e27ec005799394162@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"7b042d5adabdb0fc06286db1a7f9cbf1e9fd1fbf/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7b042d5adabdb0fc06286db1a7f9cbf1e9fd1fbf" Do not allow Typeable on constraints (Trac #9858) The astonishingly-ingenious trio of Shachaf Ben-Kiki, ?rjan Johansen and Nathan van Doorn managed to persuade GHC 7.10.1 to cough up unsafeCoerce. That is very bad. This patch fixes it by no allowing Typable on Constraint-kinded things. And that seems right, since it is, in effect, a form of impredicative polymorphism, which Typeable definitely doesn't support. We may want to creep back in the direction of allowing Typeable on constraints one day, but this is a good fix for now, and closes a terrible hole. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 14:42:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 14:42:27 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.19da44ce7134caa27feca84f74079edd@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => typecheck/should_fail/T9858a, should_run/T9858b Comment: OK I think I have fixed this. Again. Shachaf, Orjan, Nathan: you are very very clever. Merge to 7.10 branch Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 15:10:22 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 15:10:22 -0000 Subject: [GHC] #10045: type holes related ghc panic In-Reply-To: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> References: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> Message-ID: <059.f195dc66e41dd118e683fa59fd4862a2@haskell.org> #10045: type holes related ghc panic -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | thoughtpolice Priority: normal | Status: new Component: Compiler | Milestone: 7.10.2 Resolution: | Version: 7.10.1-rc2 Operating System: Unknown/Multiple | Keywords: Type of failure: Compile-time | Architecture: crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D646 -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => thoughtpolice -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 15:13:12 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 15:13:12 -0000 Subject: [GHC] #10206: Incorrect links are generated for modules in the index of "Haskell Hiearchical Libraries" In-Reply-To: <042.42f9ef42100e34be4ebb160898f1d318@haskell.org> References: <042.42f9ef42100e34be4ebb160898f1d318@haskell.org> Message-ID: <057.08bc0830fabfc802649fe60e76f39b9f@haskell.org> #10206: Incorrect links are generated for modules in the index of "Haskell Hiearchical Libraries" -------------------------------------+------------------------------------- Reporter: pgj | Owner: Type: bug | thoughtpolice Priority: highest | Status: new Component: Documentation | Milestone: 7.10.2 Resolution: | Version: 7.10.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: Documentation | Architecture: bug | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: => thoughtpolice -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 15:21:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 15:21:14 -0000 Subject: [GHC] #10298: Infinite loop when shared libraries are unavailable In-Reply-To: <047.ac4f2671f8ae23d583742150fb22d7b0@haskell.org> References: <047.ac4f2671f8ae23d583742150fb22d7b0@haskell.org> Message-ID: <062.770749fab89ef1a6c24c4994436629ac@haskell.org> #10298: Infinite loop when shared libraries are unavailable -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I was able to reproduce the loop, but rather than copying `/usr/lib/x86_64 -linux-gnu/gconv/` into the chroot, I tried copying in `/usr/lib/locale/` instead, and that was also sufficient to let the program run normally. It's to be expected that a program built with GHC needs those locale files, since String IO is locale-aware. Of course an infinite loop is not so easy to debug, and it'd be nice to have an error message. In fact the error status from `iconv_open` is being correctly checked, and converted to an exception, which is then caught and displayed by the default exception handler. The trouble is that the display of exceptions is also locale-aware... Curiously even an empty `main = return ()` triggers this behavior with 7.8.4, but it runs successfully on 7.10.1. I couldn't figure out why, perhaps some change in the IO manager? I don't have any good ideas about how to improve this situation. Maybe try to set up the locale for IO at some point, catch the exception if it fails and `barf()` rather than using regular IO to display the exception. But when exactly? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 15:29:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 15:29:09 -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.29c769bbfde70ed786f29f0f1a25d5b7@haskell.org> #10196: Regression regarding Unicode subscript characters in identifiers -------------------------------------+------------------------------------- Reporter: thomie | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #5108 | -------------------------------------+------------------------------------- Changes (by hvr): * owner: => hvr Comment: We're planning to allow `Lm` from the 2nd character on in an identifier for 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 15:34:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 15:34:06 -0000 Subject: [GHC] #10297: Floating instance for Data.Fixed In-Reply-To: <047.6d0ff544700b8087a9f68c3a44a1bbc7@haskell.org> References: <047.6d0ff544700b8087a9f68c3a44a1bbc7@haskell.org> Message-ID: <062.d0eed0b342d31195901f37545575f44f@haskell.org> #10297: Floating instance for Data.Fixed -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): This should really go through the libraries@ mailing list as a proposal first. That'll let more eyeballs see it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 15:44:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 15:44:33 -0000 Subject: [GHC] #10297: Floating instance for Data.Fixed In-Reply-To: <047.6d0ff544700b8087a9f68c3a44a1bbc7@haskell.org> References: <047.6d0ff544700b8087a9f68c3a44a1bbc7@haskell.org> Message-ID: <062.64fd7d6a80bab7761cf3b4b8d0842841@haskell.org> #10297: Floating instance for Data.Fixed -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dmcclean): Will do after work. I was unaware of the appropriate procedure. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 18:00:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 18:00:38 -0000 Subject: [GHC] #10301: Plugins/dynamic loading subtly broken (it seems) In-Reply-To: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> References: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> Message-ID: <067.313a9ec1e36ec725915a8e1ce13b5144@haskell.org> #10301: Plugins/dynamic loading subtly broken (it seems) -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #8276 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 20:59:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 20:59:32 -0000 Subject: [GHC] #9929: New alias handling not compatible with LLVM 3.4 In-Reply-To: <047.16e0d585b02943379458702a5beede5a@haskell.org> References: <047.16e0d585b02943379458702a5beede5a@haskell.org> Message-ID: <062.a45ad551104b285b805c31021591fb00@haskell.org> #9929: New alias handling not compatible with LLVM 3.4 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler (LLVM) | Version: 7.10.1-rc1 Resolution: worksforme | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): Agreed. However this needs to be documented as the GHC 7.10.1 User's Guide is not correct with respect to this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 21:05:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 21:05:30 -0000 Subject: [GHC] #10108: Dramatic slowdown with -O2 bytestream and list streams combined. In-Reply-To: <045.a37856fccd2b8ed01ec86f79ac73cd6a@haskell.org> References: <045.a37856fccd2b8ed01ec86f79ac73cd6a@haskell.org> Message-ID: <060.202e85681b5264354eae554716e88a86@haskell.org> #10108: Dramatic slowdown with -O2 bytestream and list streams combined. -------------------------------------+------------------------------------- Reporter: Truman | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | break_in.hs Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Please can you say exactly which versions of which libraries are required? And the exact command line you used to compile `break_ins.hs`? This an awkward one. On the one hand, `ghc -O2` should not produce code 3600 time slower than `ghc -O`. On the the other hand, the example depends on two big libraries, each of which has lots of rewrite rules that may or may not be right. So there may be nothing wrong with GHC. It'd be really helpful if someone (e.g. the library maintainers) could investigate, and characterise more clearly what is going on. The more precisely the problem is identified, the more likely that someone will fix it. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 21:25:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 21:25:18 -0000 Subject: [GHC] #10302: 7.10.1 documenation is incorrect wrt llvm Message-ID: <045.3792f024358b600138037f334f93feb4@haskell.org> #10302: 7.10.1 documenation is incorrect wrt llvm -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: llvm | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- As documented in [#9929] ghc 7.10.1 only supports llvm 3.5. This should be documented in the release notes section of the GHC Users's Guide, Version 7.10.1. In addition, the following in the Known bugs section needs to be changed to mention this also: GHC?s LLVM backend is currently incompatible with LLVM 3.4 (issue #9929). The following in section 4.11.2 should also be changed from: Currently LLVM 2.8 and later are supported. to Only LLVM 3.5 is supported. from Secondly, if you are running Mac OS X with LLVM 3.0 or greater to Secondly, if you are running Mac OS X with LLVM 3.5 from In order to use the LLVM based code generator, you should install the Homebrew package manager for OS X. to In order to use the LLVM based code generator, you should install the Homebrew package manager for OS X and then install LLVM 3.5 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 21:26:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 21:26:20 -0000 Subject: [GHC] #10302: 7.10.1 documenation is incorrect wrt llvm In-Reply-To: <045.3792f024358b600138037f334f93feb4@haskell.org> References: <045.3792f024358b600138037f334f93feb4@haskell.org> Message-ID: <060.148ee91e442e8bf9f9bf63f703d0f1b1@haskell.org> #10302: 7.10.1 documenation is incorrect wrt llvm -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Documentation | Version: 7.10.1 Resolution: | Keywords: llvm Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by George): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 22:37:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 22:37:25 -0000 Subject: [GHC] #10234: armhf : Validate fails during bindisttest configure In-Reply-To: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> References: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> Message-ID: <059.d49fc57305c9001d3796feb37d2c0923@haskell.org> #10234: armhf : Validate fails during bindisttest configure -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: llvm Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: ?Phab:D828 -------------------------------------+------------------------------------- Changes (by erikd): * status: patch => merge Comment: Since commit 42448e3757f257 has already been cherry-picked into the ghc-7.10 branch, commit 485dba86d2519cc from git HEAD should also go in. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 23:35:23 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 23:35:23 -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.2c98aee749acc01a1a343b5277f767c8@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Here is some relevant data (thanks to Michal Terepeta). These numbers were gotten while compiling haskell-src-exts: (I'm choosing the `-fno-call-arity` results here for better comparison against 7.8, which lacked the `-fcall-arity` feature.) {{{ ** HEAD with -fno-call-arity Sun Apr 12 18:16 2015 Time and Allocation Profiling Report (Final) ghc +RTS -p -RTS [...] -fno-call-arity total time = 113.71 secs (113714 ticks @ 1000 us, 1 processor) total alloc = 121,884,896,720 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc SimplTopBinds SimplCore 37.2 36.6 CoreTidy HscMain 6.0 7.3 lintAnnots CoreLint 5.8 6.5 pprNativeCode AsmCodeGen 4.1 4.8 OccAnal SimplCore 3.6 3.8 occAnalBind.assoc OccurAnal 2.9 3.2 StgCmm HscMain 2.9 2.6 RegAlloc AsmCodeGen 2.6 3.4 FloatOutwards SimplCore 2.6 2.3 regLiveness AsmCodeGen 2.5 2.8 tc_rn_src_decls TcRnDriver 2.4 1.9 Simplify SimplCore 2.4 0.3 sink CmmPipeline 2.1 2.2 NewStranal SimplCore 1.7 2.1 genMachCode AsmCodeGen 1.4 1.4 layoutStack CmmPipeline 1.4 1.4 NativeCodeGen CodeOutput 1.1 1.2 FloatInwards SimplCore 1.1 1.4 do_block Hoopl.Dataflow 1.0 0.6 Digraph.scc Digraph 0.8 1.3 }}} {{{ ** 7.8.4 Sun Apr 12 15:41 2015 Time and Allocation Profiling Report (Final) ghc +RTS -p -RTS [...] total time = 93.11 secs (93112 ticks @ 1000 us, 1 processor) total alloc = 103,135,975,120 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc SimplTopBinds SimplCore 38.5 37.4 pprNativeCode AsmCodeGen 6.2 7.2 StgCmm HscMain 3.9 4.2 RegAlloc AsmCodeGen 3.7 5.1 occAnalBind.assoc OccurAnal 3.3 3.6 OccAnal SimplCore 3.3 3.6 regLiveness AsmCodeGen 3.1 3.4 FloatOutwards SimplCore 2.9 2.4 sink CmmPipeline 2.8 2.8 Simplify SimplCore 2.6 0.3 tc_rn_src_decls TcRnDriver 2.4 2.1 genMachCode AsmCodeGen 1.9 2.0 NewStranal SimplCore 1.8 2.1 layoutStack CmmPipeline 1.8 1.8 Core2Core HscMain 1.3 1.2 deSugar HscMain 1.1 1.1 do_block Hoopl.Dataflow 1.1 0.7 CoreTidy HscMain 1.0 1.1 CorePrep HscMain 1.0 1.1 Digraph.scc Digraph 0.9 1.5 versioninfo MkIface 0.9 1.0 zonkEvBndr_zonkTcTypeToType TcHsSyn 0.6 1.4 }}} HEAD with `-fno-specialise` and `-fno-call-arity`: {{{ ghc +RTS -p -RTS [...] -fno-specialise -fno-call-arity total time = 89.93 secs (89928 ticks @ 1000 us, 1 processor) total alloc = 93,495,685,792 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc SimplTopBinds SimplCore 38.7 38.6 pprNativeCode AsmCodeGen 5.1 5.9 StgCmm HscMain 3.7 3.3 occAnalBind.assoc OccurAnal 3.2 3.6 OccAnal SimplCore 3.2 3.6 tc_rn_src_decls TcRnDriver 3.1 2.5 RegAlloc AsmCodeGen 3.1 4.2 regLiveness AsmCodeGen 3.0 3.5 FloatOutwards SimplCore 2.7 2.4 sink CmmPipeline 2.6 2.7 Simplify SimplCore 2.5 0.1 NewStranal SimplCore 1.9 2.3 genMachCode AsmCodeGen 1.8 1.7 layoutStack CmmPipeline 1.6 1.7 NativeCodeGen CodeOutput 1.4 1.5 FloatInwards SimplCore 1.2 1.6 CoreTidy HscMain 1.2 1.2 deSugar HscMain 1.2 1.2 do_block Hoopl.Dataflow 1.1 0.7 CorePrep HscMain 1.0 1.1 versioninfo MkIface 0.9 1.0 Parser HscMain 0.9 1.2 Digraph.scc Digraph 0.9 1.5 canEvVar TcCanonical 0.7 1.0 }}} And now with only `-fno-specialise`: {{{ ghc +RTS -p -RTS [...] -fno-specialise total time = 109.78 secs (109784 ticks @ 1000 us, 1 processor) total alloc = 124,469,615,048 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc SimplTopBinds SimplCore 35.4 32.4 CallArity SimplCore 13.4 20.7 pprNativeCode AsmCodeGen 4.1 4.5 OccAnal SimplCore 3.1 3.1 StgCmm HscMain 3.0 2.5 occAnalBind.assoc OccurAnal 3.0 3.1 RegAlloc AsmCodeGen 2.6 3.2 tc_rn_src_decls TcRnDriver 2.5 1.8 regLiveness AsmCodeGen 2.4 2.6 Simplify SimplCore 2.3 0.1 FloatOutwards SimplCore 2.3 1.8 sink CmmPipeline 2.2 2.0 genMachCode AsmCodeGen 1.5 1.3 NewStranal SimplCore 1.5 1.7 layoutStack CmmPipeline 1.3 1.3 NativeCodeGen CodeOutput 1.2 1.1 FloatInwards SimplCore 1.0 1.2 Digraph.scc Digraph 0.8 1.2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 23:37:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 23:37:56 -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.37dbcdf8da76254c1b3166a52268c040@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * related: #9583 => #9583, #10293 Comment: One thing I see in the (first set of) numbers above is that `lintAnnots` takes up a lot of time! It might be a problem with wrong call-centres, but then at least the call-centres should be sorted out. The call-arity problem is being tracked in #10293. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 23:42:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 23:42:13 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.d9facc1533bec8705b8946f9935cf17e@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by goldfire): Simon, I see how your fix eliminates the problem, but do you know what caused it in the first place? It might be a tad drastic to just forbid `Typeable` instances over constraints. For example, should `Dict (Show Foo)` be `Typeable`? I think it's reasonable to assume so. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 14 23:54:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 14 Apr 2015 23:54:25 -0000 Subject: [GHC] #3397: :step hangs when -fbreak-on-exception is set In-Reply-To: <045.0c0cb085f9bbd1ffc018c8ff9c9523d7@haskell.org> References: <045.0c0cb085f9bbd1ffc018c8ff9c9523d7@haskell.org> Message-ID: <060.ef0c6a6e897757de5563a52beb9f70ac@haskell.org> #3397: :step hangs when -fbreak-on-exception is set -------------------------------------+------------------------------------- Reporter: hamish | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.2.1 Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gelisam): * cc: hvr (added) * status: closed => new * version: 6.10.3 => 7.10.1-rc2 * resolution: worksforme => Comment: I have encountered this very old bug with GHC 7.10.0.20150123, here's a minimal test case: {{{#!hs mapLookup :: () -> () mapLookup = go where go () = () withDummyLookup :: IO a -> IO a withDummyLookup body = do mapLookup () `seq` return () body main :: IO () main = withDummyLookup (return ()) }}} To reproduce: {{{ $ ghci Example.hs *Main> :set -fbreak-on-exception *Main> :steplocal main Stopped at Example.hs:12:8-34 _result :: IO () = _ [Example.hs:12:8-34] *Main> :steplocal (hangs forever) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 00:12:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 00:12:21 -0000 Subject: [GHC] #10189: explicit promotions of prefix data constructors can't be parsed naturally In-Reply-To: <048.7a1fa374089d49b55ac4c378c43baf5b@haskell.org> References: <048.7a1fa374089d49b55ac4c378c43baf5b@haskell.org> Message-ID: <063.439fe17bd72ae611650127c691522c02@haskell.org> #10189: explicit promotions of prefix data constructors can't be parsed naturally -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Kinokkory Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10188 | -------------------------------------+------------------------------------- Comment (by goldfire): If we go with comment:5, that doesn't provide much of a migration path. The change would affect anyone using symbolic constructors prefix ''and'' anyone using alphanumeric constructors infix. I agree that this affects a tiny segment of our users. Part of the reason I don't feel like we need to change this is that I'm foreseeing a future where `'` can scope over a bunch of constructors, like `'(Just (Succ Succ Zero))` and the `'` just signifies a namespace change. Call me ambivalent on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 00:14:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 00:14:41 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.84d114a71dd91d34f2bb2e564f144aae@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by ekmett): Giving up Typeable for Constraint seems very sad. =( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 00:18:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 00:18:33 -0000 Subject: [GHC] #10303: Make it easier to print stack traces when debugging GHC itself Message-ID: <047.fb5dc8e7e9aecf901551c4f1b06d6dc4@haskell.org> #10303: Make it easier to print stack traces when debugging GHC itself -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- As suggested in [http://mail.haskell.org/pipermail/ghc- devs/2015-February/008271.html the mailing list], GHC should have better support for printing its own stack trace when profiling is enabled. This ticket is to track progress toward this goal. There are a few moving parts: * Just having `pprTrace` use `traceStack` is a bad idea, because a profiled compiler will spew lots and lots and lots of output. Instead, I propose a new `pprTraceStack :: String -> SDoc -> a -> a`. * Currently, `ASSERT` will print a stack trace, but it's sometimes the wrong one. `ASSERT` throws an error; if this error is caught and re- thrown, the stack trace is at the re-throw. Instead, it should be at the origin. * Is it worth adding a new mode in `build.mk` that enables profiling, `DEBUG`, and `-fprof-auto`, just to get good stack traces? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 00:19:34 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 00:19:34 -0000 Subject: [GHC] #10303: Make it easier to print stack traces when debugging GHC itself In-Reply-To: <047.fb5dc8e7e9aecf901551c4f1b06d6dc4@haskell.org> References: <047.fb5dc8e7e9aecf901551c4f1b06d6dc4@haskell.org> Message-ID: <062.1c70fd7f74a0545a7d9675fbe6ff1963@haskell.org> #10303: Make it easier to print stack traces when debugging GHC itself -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire Comment: I can take a look at this in due course. But if your itching to do this sooner, by all means take ownership. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 00:31:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 00:31:06 -0000 Subject: [GHC] #10108: Dramatic slowdown with -O2 bytestream and list streams combined. In-Reply-To: <045.a37856fccd2b8ed01ec86f79ac73cd6a@haskell.org> References: <045.a37856fccd2b8ed01ec86f79ac73cd6a@haskell.org> Message-ID: <060.a00e11963a86d7886a1f004655d0a16d@haskell.org> #10108: Dramatic slowdown with -O2 bytestream and list streams combined. -------------------------------------+------------------------------------- Reporter: Truman | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | break_in.hs Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Truman): Sorry about not including the library information. I should have known better. Here is a log showing compiling non-optimized, running, compiling optimized, and running again, that shows the runtime difference. I shortened the input file (described above) to 5000 lines to speed things up, but the problem is still clear. The versions of the two seemingly relevant imports are: bytestring-0.10.4.0 stream-fusion 0.1.2.5 The log files detail lots of other information. I'm running GHC 7.8.4 under Arch Linux 3.19.2-1-ARCH, and I have tested and confirmed this on both 32 and 64 bit machines. I will attach the two verbose compilation log files. CPC~/ghc_prob> touch break_ins.hs CPC~/ghc_prob> ghc -v5 break_ins.hs >ghc_nopt.log 2>&1 CPC~/ghc_prob> time break_ins bi_nopt.out real 0m0.077s user 0m0.077s sys 0m0.003s CPC~/ghc_prob> touch break_ins.hs CPC~/ghc_prob> ghc -v5 -O2 break_ins.hs >ghc_opt.log 2>&1 CPC~/ghc_prob> time break_ins bi_opt.out real 0m3.110s user 0m3.090s sys 0m0.017s CPC~/ghc_prob> -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 00:39:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 00:39:04 -0000 Subject: [GHC] #10303: Make it easier to print stack traces when debugging GHC itself In-Reply-To: <047.fb5dc8e7e9aecf901551c4f1b06d6dc4@haskell.org> References: <047.fb5dc8e7e9aecf901551c4f1b06d6dc4@haskell.org> Message-ID: <062.974b234fd393895678e2c7303d2fc19c@haskell.org> #10303: Make it easier to print stack traces when debugging GHC itself -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [ticket:10303 goldfire]: > * Is it worth adding a new mode in `build.mk` that enables profiling, `DEBUG`, and `-fprof-auto`, just to get good stack traces? Yes. (Maybe in the future we'll be able to use DWARF debugging information to get this information in a standard build, but let's not let that keep us from implementing this now.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 00:44:48 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 00:44:48 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.b791240445782762ba57a1d9d4d4a539@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by oerjan): Looking at that fix, I'm not sure exactly what types trigger `isConstraintKind k` (does it include unapplied `Show`, say?), but wouldn't baking that single `Bool` test result into the `TypeRep` also fix things without making `Constraint`s un`Typeable`? Also, I am guessing you still technically have "`Typeable (=>)`" with identical `TypeRep` as `->`, although since they're different kinds I don't see how to exploit that - but that's what we thought of the `()` thing first. :P -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 00:56:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 00:56:27 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.f4e77ae895c71aac78b3240edfd7e587@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by ekmett): Rather than just say it is sad, let's see if we can tackle this issue head on. A while back, Simon, you posed a sketch of an idea of how to remove the superkinding / existing type hacks by adding another very simple level we can quantify over. It could be adapted to address this situation. Consider a type checker where we've removed `*`, `Constraint` and `#` and made a single unified kind `Sort a b` where `a` and `b` are allowed to range over a binary alphabet, lets consider `{T,F}` as that alphabet. [*] Then {{{ * = Sort T T Constraint = Sort T F # = Sort F T }}} and we can talk about the kinds of existing types: {{{ () :: forall a. Sort T a }}} lets `()` work as both a `Constraint` or `*`. {{{ (,) :: forall a. Sort T a -> Sort T a -> Sort T a }}} lets us tuple up anything as long as both are *'s or both are Constraints. Unboxed tuples fit: {{{ (#,#) :: forall a b. Sort a T -> Sort a T -> Sort F T }}} lets unboxed tuples carry `*`'s and `#`'s. and the existing function overloads fit: {{{ (->) :: forall a b. Sort a T -> Sort b T -> Sort T T }}} All of this then works without the typechecker ever internally lying to itself which then solves this issue in a principled way, as the Typeable instance can know the full choice of kind without subversion. This removes all of the hacks where `(->) :: * -> * -> *` but `a -> b` might have `a` and `b` have kinds other than `*`, etc. in the typechecker, and lets us talk about `(->) Int#`, or `(,) (Eq Int)` which are both types we currently can't write: {{{ ghci> :k (->) Int# :1:6: Expecting a lifted type, but ?Int#? is unlifted In a type in a GHCi command: (->) Int# }}} I already have to work around the lack of the latter by constructing my own product for constraints. {{{ class (p,q) => p & q instance (p,q) => p & q }}} Now I can talk about `(&) (Eq Int) :: Constraint -> Constraint`, but there is no corresponding partial application trick for `(->)`. We've already implemented a related trick in Ermine without appreciable impact, our kinds there are a little different, so the details vary a bit. [*] To prevent weird quantifier abuse, you may want to require each of the arguments of Sort to have different ranges, otherwise `Sort a a` becomes weird. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 02:04:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 02:04:12 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.b300d007fcfea169034e119b45994251@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by oerjan): Shachaf and I experimented a bit, and the fix does *not* prohibit `Typeable` for unapplied type constructors. Together with the polykinded instance for type application, this can be used to construct, albeit awkwardly, `Typeable` instances for actual constraints. Example: {{{ shachaf> ?> let foo :: forall a b. (Typeable a, Typeable b) => Proxy a -> Proxy b -> Proxy (a b) -> TypeRep; foo _ _ _ = typeRep (Proxy :: Proxy (a b)) in foo (Proxy :: Proxy Ord) (Proxy :: Proxy Int) (Proxy :: Proxy (Ord Int)) shachaf> Ord Int }}} It is also possible to tease out constraint tuple constructors with type equalities (OK I'm not sure this was actually tested with HEAD, but I suspect it will work there): {{{ shachaf> > let x :: forall (a :: Constraint -> Constraint -> Constraint) b c. (a b c ~ (Ord Int, Show Int)) => TypeRep; x = typeRep (Proxy :: Proxy a) in x lambdabot> (,) }}} So my theory is that the only thing this fix *strictly* prohibits is `Typeable` for types involving nullary constraint constructors, including `()`. Luckily we don't see a way to get an exploit without `()`, for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 02:04:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 02:04:55 -0000 Subject: [GHC] #10293: CallArity taking 20% of compile time In-Reply-To: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> References: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> Message-ID: <061.6e942a3ad2e7a8708d74baa23a35efdc@haskell.org> #10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): This is good news, any chance we can get it in 7.10.2? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 03:40:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 03:40:11 -0000 Subject: [GHC] #10154: strange closure type 983040 (GHC version 7.8.3 for x86_64_unknown_linux) In-Reply-To: <051.1f31a1cb0292f37075498f4e23d78cf1@haskell.org> References: <051.1f31a1cb0292f37075498f4e23d78cf1@haskell.org> Message-ID: <066.0e90445c5abe68de6351c1d2043a1731@haskell.org> #10154: strange closure type 983040 (GHC version 7.8.3 for x86_64_unknown_linux) -------------------------------------+------------------------------------- Reporter: masterdezign | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: Compiler | Version: 7.8.3 Resolution: invalid | Keywords: strange Operating System: Linux | closure type Type of failure: Runtime crash | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: infoneeded => closed * resolution: => invalid Comment: I tried building with `-debug -rtsopts` and running with `+RTS -DS` under gdb and sure enough, many hours later, I got this: {{{ ... Running epsilon=5.0e-3 delta=1.8e-2 Running epsilon=5.0e-3 delta=1.9e-2 Running epsilon=5.0e-3 delta=2.0e-2 [New Thread 0x7fffa53ff700 (LWP 18847)] epsilon=2.0e-2 delta=1.0e-3 => 0 head(s) (92.3%) Simul: internal error: ASSERTION FAILED: file rts/sm/Storage.c, line 789 (GHC version 7.8.4 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Program received signal SIGABRT, Aborted. [Switching to Thread 0x7fffe5dfc700 (LWP 18737)] 0x00007ffff6798077 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x00007ffff6798077 in __GI_raise (sig=sig at entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff6799458 in __GI_abort () at abort.c:89 #2 0x00000000007e5087 in rtsFatalInternalErrorFn (s=0x854810 "ASSERTION FAILED: file %s, line %u\n", ap=0x7fffe5df7cd8) at rts/RtsMessages.c:170 #3 0x00000000007e4cbf in barf (s=0x854810 "ASSERTION FAILED: file %s, line %u\n") at rts/RtsMessages.c:42 #4 0x00000000007e4d22 in _assertFail (filename=0x85a1c8 "rts/sm/Storage.c", linenum=789) at rts/RtsMessages.c:57 #5 0x0000000000804d69 in allocate (cap=0xacec60, n=8) at rts/sm/Storage.c:789 #6 0x000000000080f522 in stg_newByteArrayzh () #7 0x0000000000000000 in ?? () }}} The failed assertion is at the end of `allocate`: {{{ IF_DEBUG(sanity, ASSERT(*((StgWord8*)p) == 0xaa)); }}} Inspecting the memory before `p` (the pointer that `allocate` has just allocated, and is about to return) I see {{{ (gdb) x/ga p-8 0x7ffff42ec9c0: 0x812e60 (gdb) 0x7ffff42ec9c8: 0x30 (gdb) 0x7ffff42ec9d0: 0x30002e0030002d (gdb) 0x7ffff42ec9d8: 0x30003000300030 (gdb) 0x7ffff42ec9e0: 0x30003200300031 (gdb) 0x7ffff42ec9e8: 0x33003200340038 (gdb) 0x7ffff42ec9f0: 0x31003100340032 (gdb) 0x7ffff42ec9f8: 0x33003500380035 (gdb) 0x7ffff42eca00: 0xaaaaaaaaaaaa0032 (gdb) }}} so, I strongly suspect that something in the C++ code in the `double- conversion` library is writing past the end of an allocated array. It's quite a lot of C++ code though, so I don't particularly want to investigate further. I'll file a bug with `double-conversion`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 06:20:05 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 06:20:05 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.164896842209c3fa4549e2d6813141de@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by oerjan): Although Edward's suggestion is elegant, I am thinking that separating `Typeable (() :: Constraint)` and `Typeable (() :: *)`, in the same way as promoted constructors have been separated from identically named datatypes, is all that is needed to stop this bug without outlawing Typeable constraints. I think it is impossible to construct two types of the same kind with identical `TypeRep`s without using the kind ambiguity of `()`. Although intuitively, `Typeable` for tuple constructors and `->` vs. `=>` should also be separated, just in case. But the former only pass *on* kind ambiguity, while the latter *merge* it. Only `()` can create it in such a way that it can be merged back (by `->`/`=>`) later. Which means `->`/`=>` is also necessary, I guess, so if you wanted to outlaw the most impredicative `Typeable`s, you could outlaw just "`Typeable ((=>) ...)`" instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 06:40:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 06:40:50 -0000 Subject: [GHC] #10304: Bump Cabal submodule Message-ID: <044.a4b102a135e23cf08c42735959b0946a@haskell.org> #10304: Bump Cabal submodule -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: task | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Unfortunately 7.10.1 was released with a Cabal library that has a major bug handling ghcjs-pkg version numbering, introduced after 7.10rc1. Ryan is away for a few more days, but the current 1.22 HEAD should be essentially the same as the `1.22.3.0` release (other than changelog updates). Can the module be bumped to HEAD now so we can start using the fixed Cabal? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 06:53:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 06:53:25 -0000 Subject: [GHC] #10234: armhf : Validate fails during bindisttest configure In-Reply-To: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> References: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> Message-ID: <059.c2018108d957d7bd3a7a67b5e2650a29@haskell.org> #10234: armhf : Validate fails during bindisttest configure -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: llvm Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: ?Phab:D828 -------------------------------------+------------------------------------- Comment (by erikd): Unfortunately, the patch referenced in comment 11 no longer applies. Currently working on a updated version of that patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 07:53:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 07:53:44 -0000 Subject: [GHC] #10189: explicit promotions of prefix data constructors can't be parsed naturally In-Reply-To: <048.7a1fa374089d49b55ac4c378c43baf5b@haskell.org> References: <048.7a1fa374089d49b55ac4c378c43baf5b@haskell.org> Message-ID: <063.7393ce238ec0ca4e9ca056fff8c0ab40@haskell.org> #10189: explicit promotions of prefix data constructors can't be parsed naturally -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Kinokkory Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10188 | -------------------------------------+------------------------------------- Comment (by simonpj): Ah well making `'` scope over a ''term'', not just a ''name'', is a whole new unexplored ball of wax. I'd rather make what we have fit together nicely, otherwise we pay now for a distant and uncertain future benefit. We can jump future bridges when we come to them. I don't think we have enough legacy code to make wibblification on existing packages into a serious problem. I suppose we could allow both forms for a while, but emit deprecation messages for the old one. But I don't think that even that is worth the trouble. Let's just make the change: * `(':)`, not `'(:)` * {{{`'Bar`}}}, not {{{'`Bar`}}}. Can someone do this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 07:56:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 07:56:58 -0000 Subject: [GHC] #10108: Dramatic slowdown with -O2 bytestream and list streams combined. In-Reply-To: <045.a37856fccd2b8ed01ec86f79ac73cd6a@haskell.org> References: <045.a37856fccd2b8ed01ec86f79ac73cd6a@haskell.org> Message-ID: <060.db815af89293b37a8668cb175fb9b1dc@haskell.org> #10108: Dramatic slowdown with -O2 bytestream and list streams combined. -------------------------------------+------------------------------------- Reporter: Truman | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | break_in.hs Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Interesting. The actual code in `Main` never gets very big, which is promising. Could you add `-ddump-rule-firings -ddump-simpl` to your command line and give the log files for that? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 08:11:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 08:11:55 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.5dd8b7dbe036b8273f8cc44343b19ca0@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by juhpetersen): * version: 7.10.1-rc1 => 7.11 Comment: I diffed the straces (with addresses normalized/sanitized to 0x3ffyyyyyyyy). Below is the final significant chunk. The straces are for "./rpmbuild/BUILDROOT/ghc-7.10.1-1.fc23.aarch64/usr/lib64/ghc-7.10.1/bin /ghc-pkg --version". {{{ --- process.strace 2015-04-15 03:11:21.351274400 -0400 +++ subprocess.strace 2015-04-15 03:13:42.167058743 -0400 mprotect(0x3ffyyyyyyyy, 65536, PROT_READ) = 0 mprotect(0x3ffyyyyyyyy, 65536, PROT_READ) = 0 mprotect(0x3ffyyyyyyyy, 65536, PROT_READ) = 0 munmap(0x3ffyyyyyyyy, 48881) = 0 -set_tid_address(0x3ffyyyyyyyy) = 13259 +set_tid_address(0x3ffyyyyyyyy) = 13239 set_robust_list(0x3ffyyyyyyyy, 24) = 0 rt_sigaction(SIGRTMIN, {0x3ffyyyyyyyy, [], SA_SIGINFO}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0x3ffyyyyyyyy, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0 -brk(0) = 0x13010000 -brk(0x13040000) = 0x13040000 +brk(0) = 0x6950000 +brk(0x6980000) = 0x6980000 openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=106374736, ...}) = 0 mmap(NULL, 106374736, PROT_READ, MAP_PRIVATE, 3, 0) = 0x3ffyyyyyyyy close(3) = 0 clock_getres(CLOCK_PROCESS_CPUTIME_ID, {0, 1}) = 0 -clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {0, 37059433}) = 0 +clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {0, 36939847}) = 0 openat(AT_FDCWD, "/proc/meminfo", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0 mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3ffyyyyyyyy read(3, "MemTotal: 16690880 kB\nMemF"..., 1024) = 1024 close(3) = 0 munmap(0x3ffyyyyyyyy, 65536) = 0 mmap(NULL, 2097152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3ffyyyyyyyy -munmap(0x3ffyyyyyyyy, 655360) = 0 munmap(0x3ffyyyyyyyy, 393216) = 0 +munmap(0x3ffyyyyyyyy, 655360) = 0 timer_create(CLOCK_MONOTONIC, {(nil), SIGVTALRM, SIGEV_SIGNAL, {...}}, {0}) = 0 rt_sigaction(SIGVTALRM, {0x3ffyyyyyyyy, [], SA_RESTART}, NULL, 8) = 0 timer_settime(0, 0, {it_interval={0, 10000000}, it_value={0, 10000000}}, NULL) = 0 rt_sigaction(SIGINT, {0x3ffyyyyyyyy, [], 0}, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGINT, NULL, {0x3ffyyyyyyyy, [], 0}, 8) = 0 rt_sigaction(SIGINT, {0x3ffyyyyyyyy, [], 0}, NULL, 8) = 0 rt_sigaction(SIGPIPE, {0x3ffyyyyyyyy, [], 0}, {SIG_DFL, [], 0}, 8) = 0 rt_sigaction(SIGTSTP, {0x3ffyyyyyyyy, [], 0}, NULL, 8) = 0 -clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {0, 37535065}) = 0 +clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {0, 37421445}) = 0 rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0 rt_sigaction(SIGINT, {0x3ffyyyyyyyy, [], SA_RESETHAND|SA_SIGINFO}, NULL, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 -ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 -pselect6(2, [], [1], NULL, {0, 0}, 0) = 1 (out [1], left {0, 0}) -write(1, "GHC package manager version 7.10"..., 35) = 35 -ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 -clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {0, 38040864}) = 0 +ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x3ffyyyyyyyy) = -1 ENOTTY (Inappropriate ioctl for device) +ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x3ffyyyyyyyy) = -1 ENOTTY (Inappropriate ioctl for device) +clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {0, 37847540}) = 0 rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0 -clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {0, 38076223}) = 0 +clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {0, 37882073}) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 rt_sigaction(SIGVTALRM, {SIG_IGN, [], SA_INTERRUPT|SA_NODEFER|SA_RESETHAND}, {0x3ffyyyyyyyy, [], SA_RESTART}, 8) = 0 timer_delete(0) = 0 rt_sigprocmask(SIG_BLOCK, [TTOU], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigaction(SIGINT, {SIG_DFL, [], 0}, NULL, 8) = 0 rt_sigaction(SIGPIPE, {SIG_DFL, [], 0}, NULL, 8) = 0 rt_sigaction(SIGTSTP, {SIG_DFL, [], 0}, NULL, 8) = 0 -clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {0, 38428740}) = 0 +clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {0, 38226330}) = 0 exit_group(0) = ? +++ exited with 0 +++ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 08:23:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 08:23:27 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.a5387e830732ec628fed3f5cf75d95e1@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by juhpetersen): and the subprocess straces diff between x86_64 and aarch64 looks like this (for 7.8.4): {{{ --- subprocess-x86_64.strace 2015-04-15 17:18:07.000000000 +0900 +++ subprocess-arm64.strace 2015-04-15 16:50:06.000000000 +0900 -rt_sigaction(SIGVTALRM, {0x7f149254f650, [], SA_RESTORER|SA_RESTART, 0x7f1496add430}, NULL, 8) = 0 +rt_sigaction(SIGVTALRM, {0x3ff9a226910, [], SA_RESTART}, NULL, 8) = 0 timer_settime(0, 0, {it_interval={0, 10000000}, it_value={0, 10000000}}, NULL) = 0 -rt_sigaction(SIGINT, {0x7f149255b750, [], SA_RESTORER, 0x7f1496add430}, {SIG_DFL, [], 0}, 8) = 0 -rt_sigaction(SIGINT, NULL, {0x7f149255b750, [], SA_RESTORER, 0x7f1496add430}, 8) = 0 -rt_sigaction(SIGINT, {0x7f149255b750, [], SA_RESTORER, 0x7f149219ab20}, NULL, 8) = 0 -rt_sigaction(SIGPIPE, {0x7f149255b6e0, [], SA_RESTORER, 0x7f1496add430}, {SIG_DFL, [], 0}, 8) = 0 -rt_sigaction(SIGTSTP, {0x7f149255b770, [], SA_RESTORER, 0x7f1496add430}, NULL, 8) = 0 -clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {0, 8032580}) = 0 -clock_gettime(CLOCK_MONOTONIC, {1555, 94648060}) = 0 +rt_sigaction(SIGINT, {0x3ff9a237a10, [], 0}, {SIG_DFL, [], 0}, 8) = 0 +rt_sigaction(SIGINT, NULL, {0x3ff9a237a10, [], 0}, 8) = 0 +rt_sigaction(SIGINT, {0x3ff9a237a10, [], 0}, NULL, 8) = 0 +rt_sigaction(SIGPIPE, {0x3ff9a2379ac, [], 0}, {SIG_DFL, [], 0}, 8) = 0 +rt_sigaction(SIGTSTP, {0x3ff9a237a38, [], 0}, NULL, 8) = 0 +clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {0, 34154801}) = 0 rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0 -rt_sigaction(SIGINT, {0x7f149255b7f0, [], SA_RESTORER|SA_RESETHAND|SA_SIGINFO, 0x7f1496add430}, NULL, 8) = 0 +rt_sigaction(SIGINT, {0x3ff9a237ac4, [], SA_RESETHAND|SA_SIGINFO}, NULL, 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 -ioctl(1, TCGETS, 0x7ffe2a9b0e70) = -1 ENOTTY (Inappropriate ioctl for device) -select(2, [], [1], NULL, {0, 0}) = 1 (out [1], left {0, 0}) -write(1, "GHC package manager version 7.8."..., 34) = 34 -clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {0, 8190648}) = 0 -clock_gettime(CLOCK_MONOTONIC, {1555, 94885797}) = 0 +ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x3fff519c9e8) = -1 ENOTTY (Inappropriate ioctl for device) +ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 0x3fff519c9e8) = -1 ENOTTY (Inappropriate ioctl for device) +clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {0, 34575324}) = 0 rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0 -clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {0, 8203047}) = 0 -clock_gettime(CLOCK_MONOTONIC, {1555, 94922279}) = 0 -clock_gettime(CLOCK_THREAD_CPUTIME_ID, {0, 8206804}) = 0 +clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {0, 34608930}) = 0 +clock_getres(CLOCK_THREAD_CPUTIME_ID, {0, 1}) = 0 +clock_gettime(CLOCK_THREAD_CPUTIME_ID, {0, 34623282}) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 timer_settime(0, 0, {it_interval={0, 0}, it_value={0, 0}}, NULL) = 0 -rt_sigaction(SIGVTALRM, {SIG_IGN, [], SA_RESTORER|SA_INTERRUPT|SA_NODEFER|SA_RESETHAND, 0x7f149219ab20}, {0x7f149254f650, [], SA_RESTORER|SA_RESTART, 0x7f1496add430}, 8) = 0 +rt_sigaction(SIGVTALRM, {SIG_IGN, [], SA_INTERRUPT|SA_NODEFER|SA_RESETHAND}, {0x3ff9a226910, [], SA_RESTART}, 8) = 0 timer_delete(0) = 0 rt_sigprocmask(SIG_BLOCK, [TTOU], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 -rt_sigaction(SIGINT, {SIG_DFL, [], SA_RESTORER, 0x7f1496add430}, NULL, 8) = 0 -rt_sigaction(SIGPIPE, {SIG_DFL, [], SA_RESTORER, 0x7f1496add430}, NULL, 8) = 0 -rt_sigaction(SIGTSTP, {SIG_DFL, [], SA_RESTORER, 0x7f1496add430}, NULL, 8) = 0 -clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {0, 8337035}) = 0 -clock_gettime(CLOCK_MONOTONIC, {1555, 95152954}) = 0 +rt_sigaction(SIGINT, {SIG_DFL, [], 0}, NULL, 8) = 0 +rt_sigaction(SIGPIPE, {SIG_DFL, [], 0}, NULL, 8) = 0 +rt_sigaction(SIGTSTP, {SIG_DFL, [], 0}, NULL, 8) = 0 +clock_gettime(CLOCK_PROCESS_CPUTIME_ID, {0, 34949910}) = 0 exit_group(0) = ? +++ exited with 0 +++ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 09:21:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 09:21:39 -0000 Subject: [GHC] #10305: Windows validate failures Message-ID: <046.6f027390a175b610e7a005fd1512d5c4@haskell.org> #10305: Windows validate failures -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Running `sh validate --fast` on Windows gives the error log below. There seem to be at least three problems * Some unexpected failures. Let's ignore those for now, since they are probably all different * Some Python traceback stuff; this must be a bug. * Tons of warnings about `haddock-interfaces` Could someone help with these. Yes, I can just ignore all this output, but it seems wrong. Thanks Simon {{{ OVERALL SUMMARY for test run started at 04/14/15 22:37:45 GMT Daylight Time 0:53:23 spent to go through 4437 total tests, which gave rise to 13186 test cases, of which 9122 were skipped 53 had missing libraries 3915 expected passes 79 expected failures 4 caused framework failures 2 unexpected passes 7 unexpected failures 5 unexpected stat failures Unexpected passes: rts T5250 (normal) rts linker_unload (normal) Unexpected failures: ../../libraries/base/tests/System Timeout001 [bad exit code] (normal) codeGen/should_compile debug [bad exit code] (normal) ghc-e/should_fail T9930fail [bad exit code] (normal) ghci/linking T1407 [bad stderr] (ghci) ghci/scripts T5975a [bad stderr] (ghci) ghci/scripts T9878b [bad exit code] (ghci) stranal/should_run T10148 [bad stderr] (optasm) Unexpected stat failures: perf/compiler T5030 [stat too good] (normal) perf/compiler T5837 [stat too good] (normal) perf/compiler T783 [stat not good enough] (normal) perf/compiler T9872d [stat not good enough] (normal) perf/should_run T9203 [stat not good enough] (normal) Traceback (most recent call last): File "C:\code\HEAD\testsuite\driver\testlib.py", line 806, in do_test result = func(*[name,way] + args) File "C:\code\HEAD\testsuite\driver\testlib.py", line 1121, in stats return checkStats(name, way, stats_file, opts.stats_range_fields) File "C:\code\HEAD\testsuite\driver\testlib.py", line 1131, in checkStats f = open(in_testdir(stats_file)) IOError: [Errno 2] No such file or directory: './perf/haddock/../../../../libraries/base/dist- install/doc/html/base/base.haddock.t' Traceback (most recent call last): File "C:\code\HEAD\testsuite\driver\testlib.py", line 806, in do_test result = func(*[name,way] + args) File "C:\code\HEAD\testsuite\driver\testlib.py", line 1121, in stats return checkStats(name, way, stats_file, opts.stats_range_fields) File "C:\code\HEAD\testsuite\driver\testlib.py", line 1131, in checkStats f = open(in_testdir(stats_file)) IOError: [Errno 2] No such file or directory: './perf/haddock/../../../../libraries/Cabal/Cabal/dist- install/doc/html/Cabal/Cabal.haddock.t' Traceback (most recent call last): File "C:\code\HEAD\testsuite\driver\testlib.py", line 806, in do_test result = func(*[name,way] + args) File "C:\code\HEAD\testsuite\driver\testlib.py", line 1121, in stats return checkStats(name, way, stats_file, opts.stats_range_fields) File "C:\code\HEAD\testsuite\driver\testlib.py", line 1131, in checkStats f = open(in_testdir(stats_file)) IOError: [Errno 2] No such file or directory: './perf/haddock/../../../../compiler/stage2/doc/html/ghc/ghc.haddock.t' make[2]: Leaving directory '/cygdrive/c/code/HEAD/testsuite/tests' make[1]: Leaving directory '/cygdrive/c/code/HEAD/testsuite/tests' == Start post-testsuite package check Timestamp 2015-04-07 22:25:31 UTC for C:\Users\simonpj\AppData\Roaming\ghc\i386-mingw32-7.11.20150407\package.conf.d\package.cache Timestamp 2015-04-07 22:25:31 UTC for C:\Users\simonpj\AppData\Roaming\ghc\i386-mingw32-7.11.20150407\package.conf.d (same as cache) using cache: C:\Users\simonpj\AppData\Roaming\ghc\i386-mingw32-7.11.20150407\package.conf.d\package.cache Timestamp 2015-04-14 21:31:48 UTC for C:/code/HEAD/inplace\lib\package.conf.d\package.cache Timestamp 2015-04-14 21:31:48 UTC for C:/code/HEAD/inplace\lib\package.conf.d (same as cache) using cache: C:/code/HEAD/inplace\lib\package.conf.d\package.cache db stack: ["C:\\Users\\simonpj\\AppData\\Roaming\\ghc\\i386-mingw32-7.11.20150407\\package.conf.d","C:/code/HEAD/inplace\\lib\\package.conf.d"] modifying: Nothing flag db stack: ["C:\\Users\\simonpj\\AppData\\Roaming\\ghc\\i386-mingw32-7.11.20150407\\package.conf.d","C:/code/HEAD/inplace\\lib\\package.conf.d"] Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows- ghc-7.11.20150407\linear-1.18.0.1\html\linear.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\linear-1.18.0.1\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows- ghc-7.11.20150407\lens-4.9\html\lens.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\lens-4.9\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows-ghc-7.11.20150407 \kan-extensions-4.2.1\html\kan-extensions.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\kan-extensions-4.2.1\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows- ghc-7.11.20150407\adjunctions-4.2\html\adjunctions.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\adjunctions-4.2\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows- ghc-7.11.20150407\free-4.11\html\free.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\free-4.11\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows- ghc-7.11.20150407\profunctors-4.4.1\html\profunctors.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\profunctors-4.4.1\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows- ghc-7.11.20150407\bifunctors-4.2.1\html\bifunctors.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\bifunctors-4.2.1\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows- ghc-7.11.20150407\semigroupoids-4.3\html\semigroupoids.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\semigroupoids-4.3\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows- ghc-7.11.20150407\comonad-4.2.5\html\comonad.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\comonad-4.2.5\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows- ghc-7.11.20150407\contravariant-1.3.1\html\contravariant.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\contravariant-1.3.1\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows- ghc-7.11.20150407\bytes-0.15\html\bytes.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\bytes-0.15\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows- ghc-7.11.20150407\void-0.7\html\void.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\void-0.7\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows- ghc-7.11.20150407\semigroups-0.16.2.2\html\semigroups.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\semigroups-0.16.2.2\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows-ghc-7.11.20150407 \unordered-containers-0.2.5.1\html\unordered-containers.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\unordered-containers-0.2.5.1\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows- ghc-7.11.20150407\exceptions-0.8.0.2\html\exceptions.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\exceptions-0.8.0.2\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows- ghc-7.11.20150407\distributive-0.4.4\html\distributive.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\distributive-0.4.4\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows- ghc-7.11.20150407\hashable-1.2.3.2\html\hashable.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\hashable-1.2.3.2\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows- ghc-7.11.20150407\vector-0.10.12.3\html\vector.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\vector-0.10.12.3\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows-ghc-7.11.20150407 \transformers-compat-0.4.0.4\html\transformers-compat.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\transformers-compat-0.4.0.4\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows- ghc-7.11.20150407\text-1.2.0.4\html\text.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\text-1.2.0.4\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows- ghc-7.11.20150407\tagged-0.8.0.1\html\tagged.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\tagged-0.8.0.1\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows- ghc-7.11.20150407\reflection-1.5.1.2\html\reflection.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\reflection-1.5.1.2\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows- ghc-7.11.20150407\primitive-0.6\html\primitive.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\primitive-0.6\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows-ghc-7.11.20150407 \prelude-extras-0.4\html\prelude-extras.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\prelude-extras-0.4\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows- ghc-7.11.20150407\nats-1\html\nats.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\nats-1\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows- ghc-7.11.20150407\mtl-2.2.1\html\mtl.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\mtl-2.2.1\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows- ghc-7.11.20150407\cereal-0.4.1.1\html\cereal.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\cereal-0.4.1.1\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386-windows- ghc-7.11.20150407\StateVar-1.1.0.0\html\StateVar.haddock doesn't exist or isn't a file Warning: haddock-html: C:\Users\simonpj\AppData\Roaming\cabal\doc\i386 -windows-ghc-7.11.20150407\StateVar-1.1.0.0\html doesn't exist or isn't a directory Warning: haddock-interfaces: C:\code\HEAD\libraries\stm\dist- install\doc\html\stm\stm.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\parallel\dist- install\doc\html\parallel\parallel.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\compiler\stage2\doc\html\ghc\ghc.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\haskeline\dist- install\doc\html\haskeline\haskeline.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\transformers\dist- install\doc\html\transformers\transformers.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\hoopl\dist- install\doc\html\hoopl\hoopl.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\bin-package-db\dist- install\doc\html\bin-package-db\bin-package-db.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\Cabal\Cabal\dist- install\doc\html\Cabal\Cabal.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\binary\dist- install\doc\html\binary\binary.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\template-haskell\dist- install\doc\html\template-haskell\template-haskell.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\pretty\dist- install\doc\html\pretty\pretty.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\hpc\dist- install\doc\html\hpc\hpc.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\process\dist- install\doc\html\process\process.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\directory\dist- install\doc\html\directory\directory.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\time\dist- install\doc\html\time\time.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\Win32\dist- install\doc\html\Win32\Win32.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\containers\dist- install\doc\html\containers\containers.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\bytestring\dist- install\doc\html\bytestring\bytestring.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\deepseq\dist- install\doc\html\deepseq\deepseq.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\array\dist- install\doc\html\array\array.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\filepath\dist- install\doc\html\filepath\filepath.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\base\dist- install\doc\html\base\base.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\integer-gmp\dist- install\doc\html\integer-gmp\integer-gmp.haddock doesn't exist or isn't a file Warning: haddock-interfaces: C:\code\HEAD\libraries\ghc-prim\dist- install\doc\html\ghc-prim\ghc-prim.haddock doesn't exist or isn't a file == End post-testsuite package check ------------------------------------------------------------------- Oops! Looks like you have some unexpected test results or framework failures. Please fix them before pushing/sending patches. ------------------------------------------------------------------- HEAD $ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 09:25:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 09:25:10 -0000 Subject: [GHC] #9840: Permit empty closed type families In-Reply-To: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> References: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> Message-ID: <064.78167ba990391d1471d79216342c0a44@haskell.org> #9840: Permit empty closed type families -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8028 | Differential Revisions: Phab:D841 -------------------------------------+------------------------------------- Changes (by adamgundry): * status: new => patch * differential: => Phab:D841 * related: => #8028 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 09:28:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 09:28:43 -0000 Subject: [GHC] #10109: Kinds aren't checked in the coverage condition In-Reply-To: <047.7d30c524ce4f4e21643984d566efbd48@haskell.org> References: <047.7d30c524ce4f4e21643984d566efbd48@haskell.org> Message-ID: <062.742b1bffe16b1ab5c48f92066cdd49b1@haskell.org> #10109: Kinds aren't checked in the coverage condition -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"49d9b009a2affb6015b8f6e2f15e4660a53c0d9a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="49d9b009a2affb6015b8f6e2f15e4660a53c0d9a" Fix fundep coverage-condition check for poly-kinds See Note [Closing over kinds in coverage] in FunDeps. I'd already fixed this bug once, for Trac #8391, but I put the call to closeOverKinds in the wrong place, so Trac #10109 failed. (It checks the /liberal/ coverage condition, which The fix was easy: move the call to the right place! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 09:28:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 09:28:43 -0000 Subject: [GHC] #8391: FunDeps coverage condition check failure with PolyKinds In-Reply-To: <047.b2bf3b0730ed8141c814d71a4a379642@haskell.org> References: <047.b2bf3b0730ed8141c814d71a4a379642@haskell.org> Message-ID: <062.800d2dd81fe85430c1d092d5befbfe91@haskell.org> #8391: FunDeps coverage condition check failure with PolyKinds ----------------------------------------------+---------------------------- Reporter: sbarclay | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8356 | polykinds/T8391 | Blocking: ----------------------------------------------+---------------------------- Comment (by Simon Peyton Jones ): In [changeset:"49d9b009a2affb6015b8f6e2f15e4660a53c0d9a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="49d9b009a2affb6015b8f6e2f15e4660a53c0d9a" Fix fundep coverage-condition check for poly-kinds See Note [Closing over kinds in coverage] in FunDeps. I'd already fixed this bug once, for Trac #8391, but I put the call to closeOverKinds in the wrong place, so Trac #10109 failed. (It checks the /liberal/ coverage condition, which The fix was easy: move the call to the right place! }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 09:32:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 09:32:22 -0000 Subject: [GHC] #10109: Kinds aren't checked in the coverage condition In-Reply-To: <047.7d30c524ce4f4e21643984d566efbd48@haskell.org> References: <047.7d30c524ce4f4e21643984d566efbd48@haskell.org> Message-ID: <062.d4dda931ebc053ba7c70e7485594d41b@haskell.org> #10109: Kinds aren't checked in the coverage condition -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_compile/T10109 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => typecheck/should_compile/T10109 Comment: Sorry for the slightly garbled commit message, but the main payload is right! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 09:33:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 09:33:23 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.b8bd9af53380fc8f70e0c8635d28b9b4@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10226 | -------------------------------------+------------------------------------- Changes (by adamgundry): * milestone: 7.12.1 => 7.10.2 Comment: Any chance we can get this addressed for 7.10.2? It's a definite failure of completeness in the constraint solver that is a regression from 7.8 and is affecting code in the wild. It is possible to rewrite affected code using proxies, but only with fairly invasive changes. As Edsko noted, adding type signatures is not necessarily enough. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 09:39:20 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 09:39:20 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.ab1a951a419dafa69f69b93777b40bf4@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10226 | -------------------------------------+------------------------------------- Comment (by simonpj): Thanks for re-highlighting this. I've just been looking at this again, as it happens. The sad story is that it's an unexpected consequence of some refactoring I did to the type-family solver. I can't undo that on the branch; it's quite pervasive. But it showed up a shortcoming in the way we do type inference generally. That is, I exposed an existing bug which happened not to show up before. Fixing that bug is quite non-trivial. I do intend to fix it, probably in the next couple of weeks. Let's see how invasive the fix is. Meanwhile you say "it is affecting code in the wild". Can you be more specific? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 10:00:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 10:00:00 -0000 Subject: [GHC] #10281: Type error with Rank-n-types In-Reply-To: <043.715543d69d09145192a2c9ffe2902dd1@haskell.org> References: <043.715543d69d09145192a2c9ffe2902dd1@haskell.org> Message-ID: <058.3df8e45b0a2a359da68afee89c8d0838@haskell.org> #10281: Type error with Rank-n-types -------------------------------------+------------------------------------- Reporter: rhjl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Peirce_eq_LEM.hs Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rhjl): I will attach an ASCII version of the test case. What I mean by replacing the product type with tuples is to change the definition of `? ? ?` to `(?,?)` and to make the appropriate adjustments in the functions associated to that type. With those changes and `ImpredicativeTypes` GHC accepts the module. My undoubtedly wrong idea of impredicative polymorphism is that it (recursively) allows polymorphic types as any arguments to any type constructor, whereas arbitrary rank polymorphism (recursively) allows polymorphic types in the arguments to `(?)` only. Using these definitions I do not think that the module should need impredicative polymorphism, because ? after resolving all aliases ? it uses no type constructors other than `(?)`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 12:14:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 12:14:04 -0000 Subject: [GHC] #10306: Calling reify on Any or built-in type families causes panic Message-ID: <049.6556ac4af659c7bd1966731677057666@haskell.org> #10306: Calling reify on Any or built-in type families causes panic -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: #9840 Differential Revisions: Phab:D841 | -------------------------------------+------------------------------------- Both `reify ''Any` and `reify ''(+)` (where `(+)` is the built-in operation on type-level naturals) result in a panic `TcSplice.reifyFamFlavour: not a type family`. I came across this while working on #9840 and have a fix as part of Phab:D841. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 12:50:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 12:50:28 -0000 Subject: [GHC] #10307: Api Annotations: RdrHsSyn.mkAtDefault causes annotations to be disconnected. Message-ID: <044.a92aa56f1812e43ed7dcf62c77358ffd@haskell.org> #10307: Api Annotations: RdrHsSyn.mkAtDefault causes annotations to be disconnected. -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The code for `mkAtDefault` is as follows. {{{#!hs mkATDefault (L loc (TyFamInstDecl { tfid_eqn = L _ e })) | TyFamEqn { tfe_tycon = tc, tfe_pats = pats, tfe_rhs = rhs } <- e = do { tvs <- checkTyVars (ptext (sLit "default")) equalsDots tc (hswb_cts pats) ; return (L loc (TyFamEqn { tfe_tycon = tc , tfe_pats = tvs , tfe_rhs = rhs })) } }}} An associated type in a class of the form {{{#!hs type FoldableConstraint t x = () }}} has an `AnnEqual` attached to the location in `tfid_eqn`. Since the location is discarded, this annotation is then disconnected from the AST. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 13:09:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 13:09:55 -0000 Subject: [GHC] #10292: Validate fails on armhf-linux In-Reply-To: <044.8055e40124ced0bf29d2dcf6e0c01c9f@haskell.org> References: <044.8055e40124ced0bf29d2dcf6e0c01c9f@haskell.org> Message-ID: <059.1c7fce086f493afc07e5c5d87801ed4f@haskell.org> #10292: Validate fails on armhf-linux ----------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+--------------------------------- Comment (by rwbarton): If `dll-split` was built then the stage2 compiler has also been built, since `dll-split` is built with the stage2 compiler. It's just the `dll- split` check and perhaps some libraries that did not get built yet, but you can run the test suite without those. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 13:17:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 13:17:47 -0000 Subject: [GHC] #9929: New alias handling not compatible with LLVM 3.4 In-Reply-To: <047.16e0d585b02943379458702a5beede5a@haskell.org> References: <047.16e0d585b02943379458702a5beede5a@haskell.org> Message-ID: <062.4b7859d7c30178c0190df5055533b11f@haskell.org> #9929: New alias handling not compatible with LLVM 3.4 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler (LLVM) | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * status: closed => new * resolution: worksforme => Old description: > As reported by Joachim here: https://www.haskell.org/pipermail/ghc- > devs/2014-November/007480.html, and it happens for me too. It seems to > affect every program compiled with `-fllvm`; T5681 just happens to be the > only such program in the normal test suite. > > Faced with the definitions > {{{ > @Main_zdwwork_info_itable$def = internal constant > %Main_zdwwork_entry_struct<{ > i64 add (i64 sub (i64 ptrtoint (i8* @S2ZH_srt to i64),i64 ptrtoint ( > void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* > @Main_zdwwork_info$def to i64)),i64 8), > i64 4294967299, i64 0, i64 4294967311}>, > section "X98A__STRIP,__me3", align 8 > @Main_zdwwork_info_itable = alias i8* bitcast > (%Main_zdwwork_entry_struct* @Main_zdwwork_info_itable$def to i8*) > }}} > LLVM 3.4 produced the assembly > {{{ > .type Main_zdwwork_info_itable, at object # > @Main_zdwwork_info_itable > .section .rodata,"a", at progbits ; note .rodata, not > X98A__STRIP,__me3! > .globl Main_zdwwork_info_itable > .align 16 > Main_zdwwork_info_itable: > .quad (S2ZH_srt$def-Main_zdwwork_info$def)+8 > .quad 4294967299 # 0x100000003 > .quad 0 # 0x0 > .quad 4294967311 # 0x10000000f > .size Main_zdwwork_info_itable, 32 > }}} > At first I thought this was an LLVM bug, but after reading > http://llvm.org/docs/LangRef.html#linkage-types I'm not sure; maybe the > `internal` linkage type means that `@Main_zdwwork_info_itable$def` is > just a constant value without any "identity", so the LLVM optimizer is > free to drop it, merge it with another constant, or move it to another > section? > > One workaround would be to use external linkage for these > `foo_info_itable$def` symbols, and then if desired (to reduce symbol > table size), strip out any `.global bar$def` statements in the LLVM > mangler...? New description: '''Edit''': we're going to leave GHC 7.10 broken with LLVM 3.4 as described below, but then we should at least update GHC's information about which versions of LLVM it can use. ---- As reported by Joachim here: https://www.haskell.org/pipermail/ghc- devs/2014-November/007480.html, and it happens for me too. It seems to affect every program compiled with `-fllvm`; T5681 just happens to be the only such program in the normal test suite. Faced with the definitions {{{ @Main_zdwwork_info_itable$def = internal constant %Main_zdwwork_entry_struct<{ i64 add (i64 sub (i64 ptrtoint (i8* @S2ZH_srt to i64),i64 ptrtoint ( void (i64*, i64*, i64*, i64, i64, i64, i64, i64, i64, i64)* @Main_zdwwork_info$def to i64)),i64 8), i64 4294967299, i64 0, i64 4294967311}>, section "X98A__STRIP,__me3", align 8 @Main_zdwwork_info_itable = alias i8* bitcast (%Main_zdwwork_entry_struct* @Main_zdwwork_info_itable$def to i8*) }}} LLVM 3.4 produced the assembly {{{ .type Main_zdwwork_info_itable, at object # @Main_zdwwork_info_itable .section .rodata,"a", at progbits ; note .rodata, not X98A__STRIP,__me3! .globl Main_zdwwork_info_itable .align 16 Main_zdwwork_info_itable: .quad (S2ZH_srt$def-Main_zdwwork_info$def)+8 .quad 4294967299 # 0x100000003 .quad 0 # 0x0 .quad 4294967311 # 0x10000000f .size Main_zdwwork_info_itable, 32 }}} At first I thought this was an LLVM bug, but after reading http://llvm.org/docs/LangRef.html#linkage-types I'm not sure; maybe the `internal` linkage type means that `@Main_zdwwork_info_itable$def` is just a constant value without any "identity", so the LLVM optimizer is free to drop it, merge it with another constant, or move it to another section? One workaround would be to use external linkage for these `foo_info_itable$def` symbols, and then if desired (to reduce symbol table size), strip out any `.global bar$def` statements in the LLVM mangler...? -- Comment: We should also add a warning telling people to use LLVM 3.5 since we know that that is the version that we need. (I actually thought the existing warning for a too old LLVM version would trigger, but it doesn't.) I've already seen at least one person confused about this thinking that 7.10 has no support for LLVM at all. I'll repurpose this ticket to track that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 13:39:26 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 13:39:26 -0000 Subject: [GHC] #10308: GHC 7.10 does not export GHC.Event.Lifetime Message-ID: <046.e0a310ea46a004864a1735177af6822e@haskell.org> #10308: GHC 7.10 does not export GHC.Event.Lifetime -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: D838 | -------------------------------------+------------------------------------- The `base` release shipped with GHC 7.10 does not export the `Lifetime` type, rendering many of the event manager interfaces useless. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 14:25:05 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 14:25:05 -0000 Subject: [GHC] #10302: 7.10.1 documenation is incorrect wrt supported llvm version (was: 7.10.1 documenation is incorrect wrt llvm) In-Reply-To: <045.3792f024358b600138037f334f93feb4@haskell.org> References: <045.3792f024358b600138037f334f93feb4@haskell.org> Message-ID: <060.40d4dbcf32cd325c1d94a3cc55959084@haskell.org> #10302: 7.10.1 documenation is incorrect wrt supported llvm version -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Documentation | Version: 7.10.1 Resolution: | Keywords: llvm Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 14:27:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 14:27:23 -0000 Subject: [GHC] #10307: Api Annotations: RdrHsSyn.mkAtDefault causes annotations to be disconnected. In-Reply-To: <044.a92aa56f1812e43ed7dcf62c77358ffd@haskell.org> References: <044.a92aa56f1812e43ed7dcf62c77358ffd@haskell.org> Message-ID: <059.41288592931d88317302e6dd43ff1cac@haskell.org> #10307: Api Annotations: RdrHsSyn.mkAtDefault causes annotations to be disconnected. -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D842 -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D842 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 14:31:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 14:31:54 -0000 Subject: [GHC] #10293: CallArity taking 20% of compile time In-Reply-To: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> References: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> Message-ID: <061.25e486cc3e2e6cd225b79e8ae2275ed7@haskell.org> #10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Possibly, if it validates without problems... current state on Phab:D843. I yet have to run nofib and see if I broke something. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 14:49:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 14:49:31 -0000 Subject: [GHC] #10260: last uses too much space with optimizations disabled In-Reply-To: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> References: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> Message-ID: <062.ad094f6543b9f3c765c1c852cc3646d8@haskell.org> #10260: last uses too much space with optimizations disabled -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D844 -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => patch * differential: => Phab:D844 Comment: Put this up at Phab:D844 and will push this once it validated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 18:09:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 18:09:41 -0000 Subject: [GHC] #10309: ApiAnnotations : mkGadtDecl discards annotations for HsFunTy Message-ID: <044.791eb2a4ed7ab1e518108e5118a46c0b@haskell.org> #10309: ApiAnnotations : mkGadtDecl discards annotations for HsFunTy -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When `mkGadtDecl` is presented wih a `HsFunTy` it discards the SrcSpan, thus disconnecting any annotations on the `HsFunTy`. {{{#!hs mkGadtDecl names (L ls (HsForAllTy imp Nothing qvars cxt tau)) = return $ mk_gadt_con names where (details, res_ty) -- See Note [Sorting out the result type] = case tau of L _ (HsFunTy (L l (HsRecTy flds)) res_ty) -> (RecCon (L l flds), res_ty) _other -> (PrefixCon [], tau) ... }}} This can be triggered by the following {{{#!hs {-# LANGUAGE GADTs #-} module GADTRecords2 (H1(..)) where -- | h1 data H1 a b where C3 :: (Num a) => { field :: a -- ^ hello docs } -> H1 Int Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 18:38:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 18:38:38 -0000 Subject: [GHC] #10309: ApiAnnotations : mkGadtDecl discards annotations for HsFunTy In-Reply-To: <044.791eb2a4ed7ab1e518108e5118a46c0b@haskell.org> References: <044.791eb2a4ed7ab1e518108e5118a46c0b@haskell.org> Message-ID: <059.6bab915148f8ea6d8d3ff0fb32e71228@haskell.org> #10309: ApiAnnotations : mkGadtDecl discards annotations for HsFunTy -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by alanz): This occurs for the `HsFunTy` which loses its SrcSpan. The only annotation at this level is an `AnnRarrow`. {{{ | btype '->' ctype {% ams (sLL $1 $> $ HsFunTy $1 $3) [mj AnnRarrow $2] } }}} One potential solution is the keep the annotation where it is, but also add it to `$1`, which will then only be used in tooling for the GADT case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 18:50:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 18:50:16 -0000 Subject: [GHC] #5539: GHC panic - Simplifier ticks exhausted In-Reply-To: <042.6c9e0d5ccc72cfd48edcd6c26bf7a923@haskell.org> References: <042.6c9e0d5ccc72cfd48edcd6c26bf7a923@haskell.org> Message-ID: <057.fde998a1fa40b8abd601d85ee85b1d1c@haskell.org> #5539: GHC panic - Simplifier ticks exhausted -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: #8613, #9070, | Differential Revisions: #8319 | -------------------------------------+------------------------------------- Comment (by George): The preceding compiles for me on 7.10.1 on the Mac. Are there any options I need to give to ghc to make it fail? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 20:59:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 20:59:00 -0000 Subject: [GHC] #10052: Panic (something to do with floatExpr?) In-Reply-To: <044.712619dfc86074dec5613c292886ee1f@haskell.org> References: <044.712619dfc86074dec5613c292886ee1f@haskell.org> Message-ID: <059.64cd2fecde874fb53b49da36a4107d9c@haskell.org> #10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D727 -------------------------------------+------------------------------------- Changes (by George): * failure: None/Unknown => Compile-time crash -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 21:00:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 21:00:27 -0000 Subject: [GHC] #10052: Panic (something to do with floatExpr?) In-Reply-To: <044.712619dfc86074dec5613c292886ee1f@haskell.org> References: <044.712619dfc86074dec5613c292886ee1f@haskell.org> Message-ID: <059.5badaf8b686781d0da5bb7082717b0e1@haskell.org> #10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: simonmar Type: bug | Status: patch Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHCi crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D727 -------------------------------------+------------------------------------- Changes (by George): * failure: Compile-time crash => GHCi crash -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 15 23:23:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 15 Apr 2015 23:23:41 -0000 Subject: [GHC] #10310: MakingReleases outdated or build system problems Message-ID: <042.d2b90211853dfb2585ae68e348e1e1af@haskell.org> #10310: MakingReleases outdated or build system problems -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hey, I have some problems following https://ghc.haskell.org/trac/ghc/wiki/MakingReleases with HEAD. I'll collect them here, maybe we can update the Wiki page together, or fix the corresponding problems in the build system if they are problems. 1) `make sdist` fails with the problem that `ghc-tarballs` doesn't exist. I've heard that's only needed on Windows, and that some people seem to get it by cloning a submodule when they are on Windows. A `mkdir ghc-tarballs` fixed it. Maybe that directory should be created by the build system? 2) When I `make` in the unpacked sdist tarball, I get {{{ "" -P 'filename.as.url=0' utils/haddock/doc/haddock.xml --ps -o utils/haddock/doc/haddock.ps "" -P 'filename.as.url=0' utils/haddock/doc/haddock.xml --pdf -o utils/haddock/doc/haddock.pdf /bin/bash: : command not found /bin/bash: : command not found make[1]: *** [utils/haddock/doc/haddock.ps] Error 127 make[1]: *** Waiting for unfinished jobs.... make[1]: *** [utils/haddock/doc/haddock.pdf] Error 127 }}} Looks like some program was set to the empty string here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 00:01:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 00:01:27 -0000 Subject: [GHC] #10311: package name returned from tyConPackage is garbled Message-ID: <049.befe981d27d5c4c24d07557f283ecb8b@haskell.org> #10311: package name returned from tyConPackage is garbled -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I am using tyConPackage (etc.) to programmatically generate links to haddock documentation (e.g., from a typed edit widget). This is now broken: {{{ import Data.Map import Data.Typeable tyConPackage $ typeRepTyCon $ typeOf $ fromList [(1,2)] in ghc-7.8.4: "containers-0.5.5.1" in ghc-7.10.1: "conta_47ajk3tbda43DFWyeF3oHQ" }}} and I don't see how to get the actual package name. Cf. http://stackoverflow.com/questions/29638177/tyconpackage-changed-from- ghc-7-8-to-ghc-7-10 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 02:52:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 02:52:54 -0000 Subject: [GHC] #10292: Validate fails on armhf-linux In-Reply-To: <044.8055e40124ced0bf29d2dcf6e0c01c9f@haskell.org> References: <044.8055e40124ced0bf29d2dcf6e0c01c9f@haskell.org> Message-ID: <059.c255c006db0c5f33ea6507aa83ac10c5@haskell.org> #10292: Validate fails on armhf-linux ----------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+--------------------------------- Changes (by bgamari): * cc: bgamari (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 03:37:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 03:37:44 -0000 Subject: [GHC] #10292: Validate fails on armhf-linux In-Reply-To: <044.8055e40124ced0bf29d2dcf6e0c01c9f@haskell.org> References: <044.8055e40124ced0bf29d2dcf6e0c01c9f@haskell.org> Message-ID: <059.cd36421eb0c562873d5a5ef4b9b046eb@haskell.org> #10292: Validate fails on armhf-linux ----------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+--------------------------------- Comment (by erikd): A checkout of the ghc-7.10 branch (commit f6c690ba64) with these cherry- picked commits: {{{ 5d5abdca31 llvmGen: move to LLVM 3.6 exclusively 56fbc18e13 Commit missing T10148 files and ignore the built executable. }}} and commit that fixes some `configure.ac`, `aclocal.m4` and `distrib/configure.ac.in` issues does not suffer from this `ddl-split` issue. This is also reminiscent of #9920 where the fix was to either patch the llvm-3.5 sources or move to llvm-3.6. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 03:52:19 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 03:52:19 -0000 Subject: [GHC] #10292: Validate fails on armhf-linux In-Reply-To: <044.8055e40124ced0bf29d2dcf6e0c01c9f@haskell.org> References: <044.8055e40124ced0bf29d2dcf6e0c01c9f@haskell.org> Message-ID: <059.58b420dde0450ef9fec7ba3e7d853899@haskell.org> #10292: Validate fails on armhf-linux ----------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+--------------------------------- Comment (by erikd): Its seems to that @bgamari is is using llvm-3.5.1 where I have been using the llvm-3.5 package from Debian (which seems to be llvm-3.5.0 with about 30 patches applied). Since ticket #9920 actually has the `arm-lower-tail- calls.patch` patch as an attachment, that patch could probably be added the Debian's llvm package, but that doesn't solve the problem on non- Debian systems. What we need now is a way to detect this llvm bug at configure time. I'm working on that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 04:40:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 04:40:05 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.30347d4fced1910d1b20134aca450405@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by oerjan): Let me elaborate on my previous comment, especially the first suggestion, since my hunch is that it requires the smallest changes to implement to get back constraint `Typeable`s: * Instead of prohibiting constraint `Typeable`s, ''detect'' the specific case of `Typeable (() :: Constraint)` and give it a different instance from `Typeable (() :: *)`. == Why is this not less secure than the current fix? == As shown in comment [comment:90], the current fix only effectively prohibits `Typeable` constraints for ''nullary'' constraint constructors. For other constraints, while ordinary users are greatly inconvenienced, an attacker can instead get the instances for all the constructors used (only the ''exact'' kind of `Constraint` is disallowed, not e.g. `* -> Constraint`) and put them together with type application, whose `Typeable` instance needs to be polymorphic and therefore cannot reasonably check for `Constraint` kinds. All nullary constructors ''other'' than `()` are either kind monomorphic or have kind parameters to distinguish the `TypeRep`s, so they are useless to an attacker. == How is it better? == It allows `Typeable` for constraints, which some people think are useful. My feeling is that constraints, especially used as type parameters, shouldn't be considered impredicative except ''possibly'' if they contain `=>`. Prohibiting this case was the 3rd suggestion, but my hunch is that this is a more complicated change, and might, if desired, be better done with an overall overhaul disallowing `=>` more uniformly in the same contexts as quantified types, including disallowing splitting `a => b` into a type application. == How does it still seem a bit awkward? == It still allows some types to have identical `TypeRep`s, like `(,) :: * -> * -> *` and `(,) :: Constraint -> Constraint -> Constraint`. This is no change from the current fix, though. Fixing this entirely was the 2nd suggestion. It might perhaps be implemented directly, although my hunch is that it requires more work, because it needs checking for partial applications and thus more complicated kinds. I assume Edward's suggestion automatically implies this. == How is it sufficient? == With either my suggestion or the currently implemented fix, although some types still have identical `TypeRep`s, I believe they can never have identical ''kinds'' as well, and all cast operations require the actual kinds of the compared `Typeable`s to be equal. '''Proposition''': If two types `t` and `u` have the property: * `t` and `u` are distinct as Haskell types, but have the same `TypeRep` under the pre-fix system, and ''either'' both have the same kind or one has kind `*` and the other has kind `Constraint`; then one of the following holds: * They have two corresponding type arguments with the same property. * They are, in some order, `() :: *` and `() :: Constraint`. '''Proof''': If at least one of `t` and `u` does ''not'' have as its tycon one of the kind-ambiguous types `(), (,), ..., (->), (=>)`, then to have equal `TypeRep`s, their tycons and lists of kindreps must be identical, and the types themselves and all their arguments must have corresponding kinds. Thus to be different as types two of their corresponding arguments must have the property. If the tycons ''are'' kind-ambiguous then any arguments must have kind either `*` or `Constraint`. With no arguments, with the ''exception'' of `()`, the types must have different kinds that are not `*` or `Constraint`, a contradiction. Otherwise, the kinds of the tycons are determined by the kinds of the first arguments, and for `t` and `u` to be distinct, there must be two corresponding arguments with the property. ---- To justify the possibility of the 3rd alternative suggestion as well, the above proof can be adjusted to show that if the kinds of `t` and `u` are ''equal'', then types of the form `a -> c` and `b => c` must appear as corresponding arguments at some step. This is because all the other options preserve whether the kinds of the arguments are equal or different. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 07:29:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 07:29:00 -0000 Subject: [GHC] #10311: package name returned from tyConPackage is garbled In-Reply-To: <049.befe981d27d5c4c24d07557f283ecb8b@haskell.org> References: <049.befe981d27d5c4c24d07557f283ecb8b@haskell.org> Message-ID: <064.fa027969f54b50fe5e799b01a7a742e3@haskell.org> #10311: package name returned from tyConPackage is garbled -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): The reason for this is that the internal representation of TyCons has changed from packagename-version to package keys, which is the garbled output you're seeing. The GHC approved way of getting the original name is to consult the package database. A bit unfortunately, you're not using the GHC API, so I'm not actually sure there is a simple simple way to manage this in your case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 08:43:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 08:43:06 -0000 Subject: [GHC] #10288: -flate-dmd-anal triggers "Entered absent arg" In-Reply-To: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> References: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> Message-ID: <061.128ac68e7d3525f1dcc6d965fb4dbece@haskell.org> #10288: -flate-dmd-anal triggers "Entered absent arg" -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by yongqli): See Main.hs here: https://gist.github.com/yongqli/5dc94aeaeda2e24c6637 You need the following packages: {{{ linear, lens, vector, vector-th- unbox, strict }}} Running with {{{ ghc Main.hs -O2 -flate-dmd-anal -fforce-recomp; ./Main }}} will give {{{ Main: Oops! Entered absent arg w_sGY6 MVN V1 Double }}} It takes about 3 days's worth of work to produce a test case like this. Is there a better option than deleting a piece of code and then recompiling? I essentially have to "unwrite" my whole program. Is there a fuzzer-like tool that could conceivably be used? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 08:54:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 08:54:24 -0000 Subject: [GHC] #10281: Type error with Rank-n-types In-Reply-To: <043.715543d69d09145192a2c9ffe2902dd1@haskell.org> References: <043.715543d69d09145192a2c9ffe2902dd1@haskell.org> Message-ID: <058.01880887bc88dcf58ee6b9519340df00@haskell.org> #10281: Type error with Rank-n-types -------------------------------------+------------------------------------- Reporter: rhjl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Peirce_eq_LEM.hs Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) Comment: Thanks for the report! I think that both errors are genuine, because both definitions require impredicative instantiations to typecheck, not just `RankNTypes`. An impredicative instantiation is where a type variable needs to be filled in with a polymorphic type. For example, in `peirce_eq_lem`, the use of `and` needs `a = Peirce -> LEM, b = LEM -> Peirce` and both `LEM` and `Peirce` expand to polytypes. If you inline `and` then the definition is accepted by 7.10.1 with just `RankNTypes`. In general, you will probably find such definitions easier to work with if you use `newtype` wrappers instead of polymorphic `type` synonyms. That will give you more control over exactly where polymorphism is introduced and eliminated. I agree that the error messages could be better, but it's hard to see how to improve them in general. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 08:56:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 08:56:25 -0000 Subject: [GHC] #10311: package name returned from tyConPackage is garbled In-Reply-To: <049.befe981d27d5c4c24d07557f283ecb8b@haskell.org> References: <049.befe981d27d5c4c24d07557f283ecb8b@haskell.org> Message-ID: <064.548f25bb66da4294207f4bde37ec6ea4@haskell.org> #10311: package name returned from tyConPackage is garbled -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Moreover there is a reason for the change. The `Map` type exposed by `containers-0.5.5.1` compiled against one set of dependencies is not the same as the `Map` type exposed by `containers-0.5.5.1` compiled against a different set of dependencies. The new package keys encode this difference. One mitigation path could be this: perhaps GHC could make it possible to get the package ''name'' from a `TyCon` as well as a package ''key''. See #10068. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 08:57:57 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 08:57:57 -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.fd3732c26010b10f641aec9b615495bc@haskell.org> #10068: Make the runtime reflection API for names, modules, locations more systematic -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): See #10311 for why we might want to give further structure to the `Package` type too. Thus: * `Module` = `ModuleName` + `Package` * `Package` lets you get the package ''name'' (e.g. `containers-0.5.5.1`), and the package ''key'' (e.g. `conta_47ajk3tbda43DFWyeF3oHQ`) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 09:30:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 09:30:53 -0000 Subject: [GHC] #10260: last uses too much space with optimizations disabled In-Reply-To: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> References: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> Message-ID: <062.f8ae4878cda9ca5e47f70670cc5586c5@haskell.org> #10260: last uses too much space with optimizations disabled -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D844 -------------------------------------+------------------------------------- Comment (by nomeata): @rwbarton, just to make sure I don?t get you wrong: Are you talking about compiling a "normal" program using last, using a normally build compiler, or are you talking about compiling the base libraries without optimization, e.g. during GHC development? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 10:57:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 10:57:58 -0000 Subject: [GHC] #10312: ApiAnnotations: misplaced AnnComma for squals production Message-ID: <044.7a2c40e552765c1f4f92f1873968df8c@haskell.org> #10312: ApiAnnotations: misplaced AnnComma for squals production -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The parser production for `squals` has {{{ : squals ',' transformqual {% addAnnotation (gl $ last $ unLoc $1) AnnComma (gl $2) >> ams (sLL $1 $> ()) (fst $ unLoc $3) >> return (sLL $1 $> [sLL $1 $> ((snd $ unLoc $3) (reverse (unLoc $1)))]) } }}} This attaches the comma to the wrong part of the `squals`, as it is generated in reverse order. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 10:59:14 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 10:59:14 -0000 Subject: [GHC] #10260: last uses too much space with optimizations disabled In-Reply-To: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> References: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> Message-ID: <062.1b32cb799fe987df2dfb2f24b2813d2a@haskell.org> #10260: last uses too much space with optimizations disabled -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D844 -------------------------------------+------------------------------------- Comment (by nomeata): I had a closer look, and the problem is the following: When we added the implementation {{{ last = foldl (\_ x -> x) (error "...")) }}} to `GHC.List` in #9339, we assumed (and I thought we checked, but maybe that not true) that GHC would optimize the core will look something like this: {{{ last :: forall a_ask. [a_ask] -> a_ask [GblId, Arity=1, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 60} Tmpl=\ (@ a_aTE) -> foldl @ a_aTE @ a_aTE (GHC.List.last2 @ a_aTE) (GHC.List.last1 @ a_aTE)] last = .. efficient implementation derived from foldl ... .. }}} This way, when using `last` in code compiled without `-O`, the efficient variant would be called, while with `-O` the unfolding would be used and optimized on the spot, possibly fusing, and producing good code if Call Arity kicks in. Unfortunately, this is what we see: {{{ last :: forall a_ask. [a_ask] -> a_ask [GblId, Arity=1, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [] 30 60}] last = \ (@ a_aTE) -> foldl @ a_aTE @ a_aTE (GHC.List.last2 @ a_aTE) (GHC.List.last1 @ a_aTE) }}} Now the question is: Why is the code not optimized in `GHC.List`? My guess is that we should have written {{{ last xs = foldl (\_ x -> x) (error "...")) xs }}} And indeed, this way, we get: {{{ Rec { GHC.List.last2 [Occ=LoopBreaker] :: forall a_aTF. [a_aTF] -> a_aTF -> a_aTF [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType ] GHC.List.last2 = \ (@ a_aTF) (ds_a1Es :: [a_aTF]) (eta_B1 :: a_aTF) -> case ds_a1Es of _ [Occ=Dead] { [] -> eta_B1; : y_a1Ex ys_a1Ey -> GHC.List.last2 @ a_aTF ys_a1Ey y_a1Ex } end Rec } last :: forall a_ask. [a_ask] -> a_ask [GblId, Arity=1, Str=DmdType , Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 30 0}] last = \ (@ a_aTF) (xs_ast :: [a_aTF]) -> GHC.List.last2 @ a_aTF xs_ast (GHC.List.last1 @ a_aTF) }}} which his nice, but now we lost the original definition. Next try, also adding `{-# INLINEABLE last #-}`, which yields. {{{ Rec { poly_go_r2F3 :: forall a_aTF. [a_aTF] -> a_aTF -> a_aTF [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType ] poly_go_r2F3 = \ (@ a_aTF) (ds_a1Es :: [a_aTF]) (eta_B1 :: a_aTF) -> case ds_a1Es of _ [Occ=Dead] { [] -> eta_B1; : y_a1Ex ys_a1Ey -> poly_go_r2F3 @ a_aTF ys_a1Ey y_a1Ex } end Rec } last [InlPrag=INLINABLE[ALWAYS]] :: forall a_ask. [a_ask] -> a_ask [GblId, Arity=1, Str=DmdType , Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=IF_ARGS [0] 160 0 Tmpl= \ (@ a_aTF) (xs_ast [Occ=Once] :: [a_aTF]) -> foldr @ a_aTF @ (a_aTF -> a_aTF) (\ (ds_d1DA [Occ=Once] :: a_aTF) (ds1_d1DB [Occ=Once!, OS=OneShot] :: a_aTF -> a_aTF) _ [Occ=Dead, OS=OneShot] -> ds1_d1DB ds_d1DA) (id @ a_aTF) xs_ast (errorEmptyList @ a_aTF (build @ Char (\ (@ b_a1Fd) -> unpackFoldrCString# @ b_a1Fd "last"#)))}] last = \ (@ a_aTF) (xs_ast :: [a_aTF]) -> poly_go_r2F3 @ a_aTF xs_ast (lvl8_r2F2 @ a_aTF) }}} That looks better. The unfolding is a bit more complicated, as `foldl` is being lined, but that is presumably ok. I?ll create a pull request with this in a small while, for review and discussion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 11:39:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 11:39:03 -0000 Subject: [GHC] #10310: MakingReleases outdated or build system problems In-Reply-To: <042.d2b90211853dfb2585ae68e348e1e1af@haskell.org> References: <042.d2b90211853dfb2585ae68e348e1e1af@haskell.org> Message-ID: <057.283fa48e49d0a8a9f4cd0d4075fcf80d@haskell.org> #10310: MakingReleases outdated or build system problems -------------------------------------+------------------------------------- Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nh2): I think the problem for 2) is that if `dblatex` is not found in the `PATH`, but the instructions {{{ $ cat > mk/build.mk < GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 11:49:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 11:49:29 -0000 Subject: [GHC] #10281: Type error with Rank-n-types In-Reply-To: <043.715543d69d09145192a2c9ffe2902dd1@haskell.org> References: <043.715543d69d09145192a2c9ffe2902dd1@haskell.org> Message-ID: <058.7765fa2b5713ad4dd4363443429493d0@haskell.org> #10281: Type error with Rank-n-types -------------------------------------+------------------------------------- Reporter: rhjl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Peirce_eq_LEM.hs Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rhjl): Thank you for your explanations! I think that I now understand the issue. I find your explanation of impredicative polymorphism better than the one given in the GHC manual: This means that you can call a polymorphic function at a polymorphic type, and parameterise data structures over polymorphic types. The hint about `newtype` wrappers also helped me to adjust the module to work with `RankNTypes`. I did not realise that `newtype` wrappers hide the polymorphism of the type they wrap. I think that a remark of this sort in the section on rank-n-types of the GHC manual would also help. By the way: this issue with impredicative instantiations precludes the use of `($)` and `(.)` to get rid of excessive parenthesis in certain situations. Is there a workaround? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 12:06:55 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 12:06:55 -0000 Subject: [GHC] #10293: CallArity taking 20% of compile time In-Reply-To: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> References: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> Message-ID: <061.1a3a6748d8a4a740f43bfc60ed9c1afd@haskell.org> #10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"9654a7cf8580bc3a027bf8b39c06d916050c446d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9654a7cf8580bc3a027bf8b39c06d916050c446d" Call Arity: Trade precision for performance in large mutually recursive groups Sometimes (especial with derived Data instances, it seems), one can have very large mutually recursive bindings. Calculating the Call Arity analysis result with full precision is an expensive operation in these case. So above a certain threshold (25, for no good reason besides intuition), skip this calculation and assume the recursion is not linear, which is a conservative result. With this, the Call Arity analysis accounts for 3.7% of the compile time of haskell-src-exts. Fixes #10293 Differential Revision: https://phabricator.haskell.org/D843 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 12:07:45 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 12:07:45 -0000 Subject: [GHC] #10293: CallArity taking 20% of compile time In-Reply-To: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> References: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> Message-ID: <061.0a9b5f87f96af391f177b2617ef01afb@haskell.org> #10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: closed Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: I pushed a fix. Michael Terepeta, can yon confirm that it fixes the problem for you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 12:28:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 12:28:56 -0000 Subject: [GHC] #10293: CallArity taking 20% of compile time In-Reply-To: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> References: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> Message-ID: <061.bb71943e14e7ded495cd40668e03b0ad@haskell.org> #10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: merge Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * status: closed => merge Comment: Oh, someone said that this might be something we want in 7.10.2. Marking as merge, deferring this decision to the release manager. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 12:35:58 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 12:35:58 -0000 Subject: [GHC] #10293: CallArity taking 20% of compile time In-Reply-To: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> References: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> Message-ID: <061.30e5cbdf1163219aaad59223eb5f0ed7@haskell.org> #10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: merge Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gidyn): Has there been any testing to determine the effect on the speed of compiled code whose compilation was significantly speeded up? The Phab only mentions nofib times, whose compile times aren't effected anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 12:37:49 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 12:37:49 -0000 Subject: [GHC] #10293: CallArity taking 20% of compile time In-Reply-To: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> References: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> Message-ID: <061.ce06c8e6dad1176203a1fcfa16ba09a0@haskell.org> #10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: merge Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gidyn): Hard-coding the limit of 25 seems rash when there's only one data point (haskell-src-exts). This should probably be configurable at run-time until its had a lot more use out in the wild to see if this really is the best value in practice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 12:38:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 12:38:10 -0000 Subject: [GHC] #10260: last uses too much space with optimizations disabled In-Reply-To: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> References: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> Message-ID: <062.a177d642aa4b63676fe679e996d20e94@haskell.org> #10260: last uses too much space with optimizations disabled -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D844 -------------------------------------+------------------------------------- Comment (by nomeata): `INLINEABLE` does not work; probably because the unfolding looks too large. But `INLINE` seems to work. So with this patch {{{ -last = foldl (\_ x -> x) (errorEmptyList "last") +last xs = foldl (\_ x -> x) lastError xs +{-# INLINE last #-} +lastError = errorEmptyList "last" }}} we have * that `GHC.List.last` is used without `-O`, with the desired memory behaviour, * with `-O`, `last` gets inlined and fusion can happen. (`lastError` pulled out to not copy that wherever `last` is used). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 12:44:04 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 12:44:04 -0000 Subject: [GHC] #10293: CallArity taking 20% of compile time In-Reply-To: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> References: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> Message-ID: <061.ceca82f3454e111cf73ffbfd8800e907@haskell.org> #10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: merge Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): > Has there been any testing to determine the effect on the speed of compiled code whose compilation was significantly speeded up? The Phab only mentions nofib times, whose compile times aren't effected anyway. No, unfortunately we lack good benchmarks for this. `haskell-src-exts` does not define any, and even if it would, there is little infrastructure to run and compare such benchmarks easily. Again intuition, but: Those cases that blew up tend to be large and complex, so the chances that everything fits together in a way for Call Arity to succeed are small. > Hard-coding the limit of 25 seems rash when there's only one data point (haskell-src-exts). This should probably be configurable at run-time until its had a lot more use out in the wild to see if this really is the best value in practice. People were asking for a fix that can go into 7.10.2, so this is a rash move. I believe the limit is still higher than the lowest reasonable limit, so we should be fine ? but again without evidence. Also, it?s always annoying to add flags-dependent values to pure code with no `DynFlags` around, as it is the case here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 12:51:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 12:51:51 -0000 Subject: [GHC] #10260: last uses too much space with optimizations disabled In-Reply-To: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> References: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> Message-ID: <062.bd79492110f3c9dd2a36c9e2ca61aa30@haskell.org> #10260: last uses too much space with optimizations disabled -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D846 -------------------------------------+------------------------------------- Changes (by nomeata): * differential: Phab:D844 => Phab:D846 Comment: Second try: Phab:D846 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 12:52:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 12:52:27 -0000 Subject: [GHC] #10260: last uses too much space with optimizations disabled In-Reply-To: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> References: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> Message-ID: <062.59984989f5dc8146c7d5bd807e2309ff@haskell.org> #10260: last uses too much space with optimizations disabled -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D847 -------------------------------------+------------------------------------- Changes (by nomeata): * differential: Phab:D846 => Phab:D847 Comment: I mean Phab:D847 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 12:53:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 12:53:56 -0000 Subject: [GHC] #10293: CallArity taking 20% of compile time In-Reply-To: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> References: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> Message-ID: <061.1173a587937a57dc81c34babe4db8202@haskell.org> #10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: merge Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 12:55:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 12:55:08 -0000 Subject: [GHC] #10293: CallArity taking 20% of compile time In-Reply-To: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> References: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> Message-ID: <061.3995313cff4fe7a04cf1f94303834c65@haskell.org> #10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: merge Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gidyn): Compile-time setting (i.e. when building GHC)? At least that way they'll be some option for folks to play around with it if they think it's too high/low without actually changing the source code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 13:03:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 13:03:15 -0000 Subject: [GHC] #10293: CallArity taking 20% of compile time In-Reply-To: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> References: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> Message-ID: <061.99d4d1cc5d5ba8246f9b8a524cd25bd5@haskell.org> #10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: merge Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): > Compile-time setting (i.e. when building GHC)? At least that way they'll be some option for folks to play around with it if they think it's too high/low without actually changing the source code. That doesn?t gain you much over changing a number in the source file. Also, so far the existence of such folk is just hypothetical. Much more likely is that someone will fine data points for one or the other side of the limit (?this code compiles too slowly?, ?Call Arity did not fire even though it could?) and report that. Until there are such reports, it is safe to assume that it simply doesn?t matter. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 13:52:49 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 13:52:49 -0000 Subject: [GHC] #10288: -flate-dmd-anal triggers "Entered absent arg" In-Reply-To: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> References: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> Message-ID: <061.0ab4d872c48331648e0869c79e7a7502@haskell.org> #10288: -flate-dmd-anal triggers "Entered absent arg" -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Good news. I think this is fixed. At least I can't reproduce your crash with HEAD. I think that one of these two fixes has solved it: * #10218 * #10148 Both are merged to the 7.10 branch and so will appear in 7.10.2. It would be good if you were able to test that the 7.10 branch is indeed fixed in your case. I will try to do the same. Simon PS: for "entered absent arg w_sJ66e" bugs, compile with "-ddump-simpl" and grep for that string. That will show exactly which thunk in which function is being entered, and might save time compared to delete/recompile. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 13:53:59 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 13:53:59 -0000 Subject: [GHC] #10313: ApiAnnotations : strings in warnings do not return SourceText Message-ID: <044.808d3812fac81928344a0fd1bb2faa89@haskell.org> #10313: ApiAnnotations : strings in warnings do not return SourceText -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The `strings` used in a `WARNING` pragma are captured via {{{ strings :: { Located ([AddAnn],[Located FastString]) } : STRING { sL1 $1 ([],[L (gl $1) (getSTRING $1)]) } .. }}} The `STRING` token has a method `getSTRINGs` that returns the original source text for a string. A warning of the form {{{#!hs {-# WARNING Logic , mkSolver , mkSimpleSolver , mkSolverForLogic , solverSetParams , solverPush , solverPop , solverReset , solverGetNumScopes , solverAssertCnstr , solverAssertAndTrack , solverCheck , solverCheckAndGetModel , solverGetReasonUnknown "New Z3 API support is still incomplete and fragile: \ \you may experience segmentation faults!" #-} }}} returns the concatenated warning string rather than the original source. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 13:59:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 13:59:51 -0000 Subject: [GHC] #10260: last uses too much space with optimizations disabled In-Reply-To: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> References: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> Message-ID: <062.c40b9e0e1b17f4c8d3e5e3b17cbece08@haskell.org> #10260: last uses too much space with optimizations disabled -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D847 -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:5 nomeata]: > @rwbarton, just to make sure I don?t get you wrong: Are you talking about compiling a "normal" program using last, using a normally build compiler, or are you talking about compiling the base libraries without optimization, e.g. during GHC development? I mean using a compiler built with "perf", e.g. the 7.10.1 release, and compiling the user program without optimization. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 14:34:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 14:34:05 -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.0f174741e0d9d8075b69a7088a16acda@haskell.org> #9637: Type level programming needs an error function -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9180, #9636 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * related: => #9180, #9636 Comment: #9180 proposes a similar mechanism at the term level. #9636 is a nice application of the feature proposed in this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 14:34:46 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 14:34:46 -0000 Subject: [GHC] #9180: New magic function `staticError` In-Reply-To: <046.f02a1097d6c172420c24668297fdcea7@haskell.org> References: <046.f02a1097d6c172420c24668297fdcea7@haskell.org> Message-ID: <061.465bccacabeaca289a16952d29fa2162@haskell.org> #9180: New magic function `staticError` -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9637 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * related: => #9637 Comment: See also #9637 for a type-level variant of this idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 14:57:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 14:57:56 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.05a6acc85de4451987d7757a61ab77d3@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by osa1): I think I also discovered this bug, here's my program to reproduce it: https://gist.github.com/osa1/4fe6a09a473dcb72798e (you can see also the error message in that link) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 15:27:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 15:27:24 -0000 Subject: [GHC] #10314: ApiAnnotations: mkHsForAllTy discards parens Message-ID: <044.18ffc9f2fee6881fa8a916d0ec16833c@haskell.org> #10314: ApiAnnotations: mkHsForAllTy discards parens -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The code for `HsForAllTy` is {{{#!hs mkHsForAllTy exp tvs ctxt ty = HsForAllTy exp extra (mkHsQTvs tvs) cleanCtxt ty where -- Separate the extra-constraints wildcard when present (cleanCtxt, extra) | (L l HsWildcardTy) <- ignoreParens (last (unLoc ctxt)) = (init `fmap` ctxt, Just l) | otherwise = (ctxt, Nothing) ignoreParens (L _ (HsParTy ty)) = ty ignoreParens ty = ty }}} The process of cleaning the context calls `ignoreParens` which strips out the `HsParTy`. In the process the `AnnOpenP` and `AnnCloseP` attached to this are discarded. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 15:29:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 15:29:29 -0000 Subject: [GHC] #10314: ApiAnnotations: mkHsForAllTy discards parens In-Reply-To: <044.18ffc9f2fee6881fa8a916d0ec16833c@haskell.org> References: <044.18ffc9f2fee6881fa8a916d0ec16833c@haskell.org> Message-ID: <059.b741bf22f0d255e153aef7fb9f463cc0@haskell.org> #10314: ApiAnnotations: mkHsForAllTy discards parens -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by alanz): This process may also be taking place for {{{#!hs HsPArrTy HsParTy ParPat PArrPat HsPar ExplicitPArr HsCmdPar }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 17:44:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 17:44:24 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.a00742a3cd24a0f91b13085e933b9097@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by goldfire): After some discussion, we propose the following: * Restore `Typeable` for constraints. * Forbid `Typeable` for types with `=>`, as those types are higher-rank- ish. * Ensure that the `TypeRep`s for `() :: *` and `() :: Constraint` are distinct, and similarly for higher arities. This seems to solve the problems stated here. For what it's worth, I agree the statements in comment:92, but we can do the trick for all arities, not just 0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 17:54:01 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 17:54:01 -0000 Subject: [GHC] #10311: package name returned from tyConPackage is garbled In-Reply-To: <049.befe981d27d5c4c24d07557f283ecb8b@haskell.org> References: <049.befe981d27d5c4c24d07557f283ecb8b@haskell.org> Message-ID: <064.6828411f74e1c5c5d990c210bc853651@haskell.org> #10311: package name returned from tyConPackage is garbled -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by j.waldmann): > ... could make it possible to get the package name from a TyCon as well as a package key That would be very much welcome. Thanks for considering this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 17:56:43 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 17:56: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.13ca4e014679611468b474e66c087246@haskell.org> #10068: Make the runtime reflection API for names, modules, locations more systematic -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by j.waldmann): * cc: j.waldmann (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 18:19:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 18:19:06 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.23ee9d2279f1f2e8dde3fdc1efd9a9d9@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by diatchki): This should be fixed in HEAD now. Please give it a whirl, and let me know if you run into any more problems. The implementation should be what Richard discribed: * Constraints are OK * Impredicative types are not OK (not even things like `Eq Int => Int`) * Constraint and normal tuples should have different representations at all arities. A side-note: I couldn't figure out how to write the type constructor `(,) :: Constraint -> Constraint -> Constraint`, so I had to get creative with the testing. Is that intentional? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 19:36:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 19:36:05 -0000 Subject: [GHC] #10315: ApiAnnotations : Empty context loses annotations Message-ID: <044.a3ae6affd9ae60617b8ad158a443dbf2@haskell.org> #10315: ApiAnnotations : Empty context loses annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- A type signature of the form {{{#!hs bar :: ( ) => a-> Bool }}} generates annotations for the `( ) =>` but the SrcSpan they are attached to is discarded so the annotations are not attached to the AST. The discarding process happens in {{{#!hs mkHsForAllTy exp tvs (L _ []) ty = mk_forall_ty exp tvs ty }}} where the empty located context is discarded. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 19:55:22 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 19:55:22 -0000 Subject: [GHC] #10293: CallArity taking 20% of compile time In-Reply-To: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> References: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> Message-ID: <061.768296ffdee92b246dc76cdeb6b1f06f@haskell.org> #10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: merge Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by michalt): Thanks for CCing me and sorry for the delay (unfortunately the email landed in spam). Anyway, I've rebuilt ghc (build flavor prof) and I can confirm that your changes improve the performance significantly: {{{ Thu Apr 16 21:48 2015 Time and Allocation Profiling Report (Final) ghc +RTS -p -RTS [...] total time = 121.66 secs (121660 ticks @ 1000 us, 1 processor) total alloc = 132,375,235,176 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc SimplTopBinds SimplCore 38.8 37.5 lintAnnots CoreLint 5.5 6.0 CoreTidy HscMain 5.2 6.7 pprNativeCode AsmCodeGen 3.8 4.4 OccAnal SimplCore 3.8 4.0 occAnalBind.assoc OccurAnal 3.1 3.3 StgCmm HscMain 2.8 2.4 Simplify SimplCore 2.5 0.3 RegAlloc AsmCodeGen 2.5 3.1 FloatOutwards SimplCore 2.4 2.1 regLiveness AsmCodeGen 2.3 2.5 tc_rn_src_decls TcRnDriver 2.3 1.7 sink CmmPipeline 2.1 2.0 CallArity SimplCore 1.7 3.1 NewStranal SimplCore 1.6 1.9 genMachCode AsmCodeGen 1.4 1.3 layoutStack CmmPipeline 1.2 1.3 NativeCodeGen CodeOutput 1.1 1.1 FloatInwards SimplCore 1.0 1.2 Digraph.scc Digraph 0.7 1.2 }}} So it's still slower than GHC 7.8.4, but now `CallArity` is pretty low in the list. :-) (For the record, steps to reproduce: build GHC with build flavor prof and add +RTS -p -RTS to the cabal file of haskell-src-exts, then compile it. The ghc.prof file contains the information.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 19:59:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 19:59:48 -0000 Subject: [GHC] #10293: CallArity taking 20% of compile time In-Reply-To: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> References: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> Message-ID: <061.5303e8811cb87d50d650a869cfc2e168@haskell.org> #10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: merge Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): A hint for further investigation: There might more code in GHC that does not handle a mutually recursive group with 700-elements well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 20:19:18 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 20:19:18 -0000 Subject: [GHC] #10293: CallArity taking 20% of compile time In-Reply-To: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> References: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> Message-ID: <061.d372e80a617b739a3f2d3ed3372c3454@haskell.org> #10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: merge Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * cc: scpmw@? (added) Comment: I really want to know why `lintAnnots` is so high. Peter can you investigate? Or someone? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 20:35:04 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 20:35:04 -0000 Subject: [GHC] #10281: Type error with Rank-n-types In-Reply-To: <043.715543d69d09145192a2c9ffe2902dd1@haskell.org> References: <043.715543d69d09145192a2c9ffe2902dd1@haskell.org> Message-ID: <058.4fee470dbb9579d7afbaebdc3057cc33@haskell.org> #10281: Type error with Rank-n-types -------------------------------------+------------------------------------- Reporter: rhjl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Peirce_eq_LEM.hs Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:6 rhjl]: > I find your explanation of impredicative polymorphism better than the one given in the GHC manual: ... > I think that a remark of this sort in the section on rank-n-types of the GHC manual would also help. Could you propose some actual, concrete sentences to add or change in user manual? Then I'll just make the change. As a bona fide user you are in a far better position to draft the words than me. > By the way: this issue with impredicative instantiations precludes the use of `($)` and `(.)` to get rid of excessive parenthesis in certain situations. Is there a workaround? Becuase of this `($)` has its own special typing rule in GHC. But `(.)` does not (yet). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 21:00:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 21:00:33 -0000 Subject: [GHC] #10316: Move Typeable type-rep generation from use site to definition site Message-ID: <046.706fb26d1689686d9c617262ebfd6cc9@haskell.org> #10316: Move Typeable type-rep generation from use site to definition site -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This ticket is a continuation of #9858. The interim solution for 7.10 was to generate `Typeable` data structures on the fly, as needed in client modules. This ticket is about moving the generation of the runtime representation of type constructors to their definition sites. (#9858 already has too much going on in it, so I started a fresh ticket for this refactoring.) The branch is `wip/T9858-typeable-spj`. In favour of (A) code at use site (as in 7.10): * Pay as you go. No code at all is generated unless you use `Typeable` In favour of (B) code at definition site: * More sharing. We make a `TyCon` (see `Data.Typeable.Internal`) for `T` (say) just once, in the module that defines `T`. * We may ultimately want the `TyCon` for `T` to include its source location, and perhaps more besides. If it is defined in `T` it becomes easier to do that. General observation: (B) is like `Typeable` was before, when it was an ordinary class. The difference now is that all types are `Typeable`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 21:07:37 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 21:07:37 -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.c4e086cb599b0e3a154bb05c950015c9@haskell.org> #10316: Move Typeable type-rep generation from use site to definition site -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:757 -------------------------------------+------------------------------------- Changes (by simonpj): * differential: => Phab:757 Comment: I tried to reduce the per-tycon overheads as far as possible. For a data type {{{ data Foo = Foo1 | Foo2 }}} in module `M`, you get {{{ $moduleM :: Module $moduleM = Module "mypackage-2.3"# "M"# $tcFoo :: TyCon $tcFoo = TyCon xxx yyy "Foo"# $moduleM $tcFoo1 :: TyCon $tcFoo1 = TyCon xxx yyy "Foo1"# $moduleM ..similarly Foo2... }}} That is, a sharted record for the module, plus a `TyCon` for each type constructor and data constructor. All C strings, all static data, no thunks, no code. At the moment these definitions are injected at the beginning of the optimisation pipeline, but since they are so static they could equally well go at the end, and that woudl save fruitless attempts to optimise them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 21:15:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 21:15:27 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.494ecda693e677914e4e753a6e93a260@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by simonpj): In conversation we had the staggeringly lovely idea of writing a bunch of classes thus: {{{ class (c1,c2) => (,) c1 c2 class (c1,c2,c3) => (,,) c1 c2 c3 }}} etc. I have written the class constructors prefix to stress that we are defining a ''class'' `(,)` etc, but we could equally well say {{{ class (c1,c2) => (c1,c2) -- Ha ha ha }}} Now the point is this: * `c1` and `c2` are simply superclasses of the class `(c1,c2)`. * The defined class `(,)`, of course, has kind `Constraint -> Constraint -> Constraint`. * This class is distinct from the data type `(,)`. It is just spelled the same way (confusingly perhaps, but that ship has sailed). * All the usual rules for superclasses apply. If you have the class `(c1,c2)` then you can extract the superclasses `(c1,c2)`. * If you grep for `TuplePred` in GHC you'll find quite a bit of code. All of this can be deleted; the existing superclass machinery will do the job just fine. I like this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 21:18:57 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 21:18:57 -0000 Subject: [GHC] #10309: ApiAnnotations : mkGadtDecl discards annotations for HsFunTy In-Reply-To: <044.791eb2a4ed7ab1e518108e5118a46c0b@haskell.org> References: <044.791eb2a4ed7ab1e518108e5118a46c0b@haskell.org> Message-ID: <059.0f6143cfe9db6c6ccb1e3270261393e4@haskell.org> #10309: ApiAnnotations : mkGadtDecl discards annotations for HsFunTy -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D848 -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D848 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 22:00:59 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 22:00:59 -0000 Subject: [GHC] #10293: CallArity taking 20% of compile time In-Reply-To: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> References: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> Message-ID: <061.979500a7bec4945fcf3f11f9a7b76ec3@haskell.org> #10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: merge Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 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 Revisions: -------------------------------------+------------------------------------- Changes (by George): * failure: None/Unknown => Compile-time performance bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 22:14:35 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 22:14:35 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.6fdcf64771eae7b2543176f94264524e@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by simonpj): Comment for comment:94. Merge to stable branch {{{ commit d8d541d85defcf3bbbddaeee8cfac70b74f47ffc Author: Iavor S. Diatchki Date: Thu Apr 16 11:13:24 2015 -0700 Fixes (hopefully!) T9858 The changes are: 1. No impredicative types in `Typeable` 2. Distinguish normal tuples, from tuples of constraints. >--------------------------------------------------------------- d8d541d85defcf3bbbddaeee8cfac70b74f47ffc compiler/deSugar/DsBinds.hs | 6 +++- compiler/typecheck/TcInteract.hs | 34 +++++++++------------- testsuite/tests/typecheck/should_fail/T9858b.hs | 10 +++++++ .../tests/typecheck/should_fail/T9858b.stderr | 8 +++++ testsuite/tests/typecheck/should_fail/all.T | 1 + testsuite/tests/typecheck/should_run/T9858c.hs | 19 ++++++++++++ testsuite/tests/typecheck/should_run/T9858c.stdout | 1 + testsuite/tests/typecheck/should_run/all.T | 1 + 8 files changed, 58 insertions(+), 22 deletions(-) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 22:17:36 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 22:17:36 -0000 Subject: [GHC] #10293: CallArity taking 20% of compile time In-Reply-To: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> References: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> Message-ID: <061.7c90e13ffeb355fc5ff14dc9d6f9fca1@haskell.org> #10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: merge Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 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 Revisions: -------------------------------------+------------------------------------- Comment (by scpmw): Okay, I'll have a look at it. Might be another misattribution along the lines of #10007. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 16 22:31:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 16 Apr 2015 22:31:56 -0000 Subject: [GHC] #10260: last uses too much space with optimizations disabled In-Reply-To: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> References: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> Message-ID: <062.47e569b79451cc4b23b2dd12a80d8e0b@haskell.org> #10260: last uses too much space with optimizations disabled -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D847 -------------------------------------+------------------------------------- Comment (by simonpj): Re comment:6 I too was surprised that `last` was not eta-expanded. But see this note in `SimplUtils`: {{{ Note [Do not eta-expand PAPs] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We used to have old_arity = manifestArity rhs, which meant that we would eta-expand even PAPs. But this gives no particular advantage, and can lead to a massive blow-up in code size, exhibited by Trac #9020. Suppose we have a PAP foo :: IO () foo = returnIO () Then we can eta-expand do foo = (\eta. (returnIO () |> sym g) eta) |> g where g :: IO () ~ State# RealWorld -> (# State# RealWorld, () #) But there is really no point in doing this, and it generates masses of coercions and whatnot that eventually disappear again. For T9020, GHC allocated 6.6G beore, and 0.8G afterwards; and residency dropped from 1.8G to 45M. But note that this won't eta-expand, say f = \g -> map g Does it matter not eta-expanding such functions? I'm not sure. Perhaps strictness analysis will have less to bite on? }}} The worse code for the un-eta-expanded code for `last` is perhaps an example of the last paragraph! And yet the comment is reasonably convincing. I'm not sure what to do here. Joachim, one thing that might be worth trying is to eta-expand as far as poss without bumping into a coercion. That would expand `last` but not `foo`. Want to try that? We may fix `last` but there are sure to be other cases, and the more robust the optimisations the better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 00:17:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 00:17:33 -0000 Subject: [GHC] #10317: Event manager: Multishot registrations only fire once Message-ID: <046.366b04e6c61d4f194d732df66f1a8423@haskell.org> #10317: Event manager: Multishot registrations only fire once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Since D347 the event manager has had support for multishot event registration semantics, allowing the user to receive multiple events on an fd without requiring re-registration. Unfortunately the implementation drops the registration after it fires, resulting in only one callback invocation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 01:10:45 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 01:10:45 -0000 Subject: [GHC] #10317: Event manager: Multishot registrations only fire once In-Reply-To: <046.366b04e6c61d4f194d732df66f1a8423@haskell.org> References: <046.366b04e6c61d4f194d732df66f1a8423@haskell.org> Message-ID: <061.794571e70d16d4d023c1cdeb51f18a36@haskell.org> #10317: Event manager: Multishot registrations only fire once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by AndreasVoellmy): * cc: AndreasVoellmy (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 01:56:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 01:56:48 -0000 Subject: [GHC] #10318: Cycles in class declaration (via superclasses) sometimes make sense. Message-ID: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> #10318: Cycles in class declaration (via superclasses) sometimes make sense. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple (Type checker) | Type of failure: GHC rejects Keywords: | valid program Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'd like to be able to say the following, to describe the notion of an integral domain in Haskell: {{{ -- | Product of non-zero elements always non-zero. -- Every integral domain has a field of fractions. -- The field of fractions of any field is itself. class (Frac (Frac a) ~ Frac a, Fractional (Frac a), IntegralDomain (Frac a)) => IntegralDomain a where type Frac a :: * embed :: a -> Frac a instance IntegralDomain Integer where type Frac Integer = Rational embed = fromInteger instance IntegralDomain Rational where type Frac Rational = Rational embed = id }}} But GHC gets scared when it sees the cyclic reference that `IntegralDomain` instances depend on an IntegralDomain superclass, which really is cyclic in the (Frac a) case here, and that is kind of the point. =) Right now the best approximation of the correct answer that I have for this situation is to lie and claim the constraint is weaker: {{{ -- | Product of non-zero elements always non-zero class (Frac (Frac a) ~ Frac a, Fractional (Frac a)) => AlmostIntegralDomain a where type Frac a :: * embed :: a -> Frac a class (AlmostIntegralDomain a, AlmostIntegralDomain (Frac a)) => IntegralDomain a instance (AlmostIntegralDomain a, AlmostIntegralDomain (Frac a)) => IntegralDomain a instance AlmostIntegralDomain Integer where type Frac Integer = Rational embed = fromInteger instance AlmostIntegralDomain Rational where type Frac Rational = Rational embed = id }}} Now the user is stuck defining a different class than the one they consume. Alternately, with `ConstraintKinds`, I can encode: {{{ data Dict p where Dict :: p => Dict p class (Frac (Frac a) ~ Frac a, Fractional (Frac a)) => IntegralDomain a where type Frac a :: * embed :: a -> Frac a proofFracIsIntegral :: p a -> Dict (IntegralDomain (Frac a)) default proofFracIsIntegral :: IntegralDomain (Frac a) => p a -> Dict (IntegralDomain (Frac a)) proofFracIsIntegral _ = Dict }}} but now whenever I need to get from `IntegralDomain a` to `IntegralDomain (Frac a)` I need to explicitly open the `proofFracIsIntegral` with a rats' nest of `ScopedTypeVariables`. It would be really really nice if I could get GHC to deal with this for me as I currently have a few thousand lines of code hacking around this limitation. =/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 01:58:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 01:58:31 -0000 Subject: [GHC] #10273: haskeline : Cross-compile from Linux to Windows fails due to In-Reply-To: <044.16994f6a5932b910b77581b817b33330@haskell.org> References: <044.16994f6a5932b910b77581b817b33330@haskell.org> Message-ID: <059.bd10e76c3269453fe584b1e0cf19729a@haskell.org> #10273: haskeline : Cross-compile from Linux to Windows fails due to -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: libraries | Version: 7.11 (other) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10070 | -------------------------------------+------------------------------------- Comment (by erikd): Ran up a Windows 8.1 VM in virtual box, applied this patch and configured and built the Haskeline library without any problem. I'll be commiting/pushing this patch later today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 02:02:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 02:02:21 -0000 Subject: [GHC] #10090: Building ghc with "make -jN" gives different base ABI hashes for N<=8 and N>8 In-Reply-To: <050.68347d138b008970a7ef1ef2a95d5317@haskell.org> References: <050.68347d138b008970a7ef1ef2a95d5317@haskell.org> Message-ID: <065.38d03c500a11f4f1c6ce421005c0b074@haskell.org> #10090: Building ghc with "make -jN" gives different base ABI hashes for N<=8 and N>8 -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 7.8.4 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #4012 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by juhpetersen): Okay thanks. Just for the record s390 seems to be ABI unstable on -j4. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 02:07:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 02:07:08 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.abed8e419c367dc97fd1fb40a8df511e@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by oerjan): Looking at [https://git.haskell.org/ghc.git/commitdiff/d8d541d85defcf3bbbddaeee8cfac70b74f47ffc the fix], I suspect it still does not disallow constructing `Typeable (Eq Int => Int)` by roundabout means - the test seems to be only for the fully applied form, not the lone `=>` constructor. However, with all the tuple constructors properly disambiguated, I don't think there's an exploit any more. I just realized my proof above doesn't handle kinds of `->` variants like `* -> # -> *`. But I'm not aware of any way to create an ambiguous `TypeRep` of possible kind `#`, so it should hopefully be fine. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 02:50:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 02:50:51 -0000 Subject: [GHC] #9579: Runtime suggests using +RTS when that's not possible In-Reply-To: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> References: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> Message-ID: <060.c7a977852899271fb903e88fe5173d31@haskell.org> #9579: Runtime suggests using +RTS when that's not possible -------------------------------------+------------------------------------- Reporter: gintas | Owner: javran Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D767 -------------------------------------+------------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"51af102e5c6c56e0987432aa5a21fe10e24090e9/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="51af102e5c6c56e0987432aa5a21fe10e24090e9" Better hints when RTS options not available (Trac #9579) This patch provides user with a better hint when most RTS options are not available (not compiled with `-rtsopts`). A new field "rtsOptsEnabled" is added into RtsFlags.MiscFlags to tell the availablity of RTS options. Some concerns: * Unlike other flag fields in "libraries/base/GHC/RTS/Flags.hsc", "RtsOptsEnabled" is defined in "includes/RtsAPI.h" and lacks constant macros. Therefore In "GHC.RTS", "RtsOptsEnabled" simply derives Enum instance and reads as of type "CInt". * There are other ways to change RTS options (e.g. `-with-rtsopts`), but it might be too verbose to mention. Test Plan: validate Reviewers: austin, hvr, thomie, simonmar Reviewed By: thomie Subscribers: thomie, rwbarton Differential Revision: https://phabricator.haskell.org/D767 GHC Trac Issues: #9579 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 02:55:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 02:55:58 -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.b933dff1f4ab33f7dcb66c1ee044d36c@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Michal describes how he got the numbers pasted in comment:12: build GHC HEAD/7.8.4 with build flavor `prof` then get the haskell-src- exts sources, install the dependencies and finally add `+RTS -p -RTS` to the cabal file and compile it, the resulting `ghc.prof` contains the profiling information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 03:05:24 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 03:05:24 -0000 Subject: [GHC] #10293: CallArity taking 20% of compile time In-Reply-To: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> References: <046.60f0f8fc0a66159c6e294d303929de7c@haskell.org> Message-ID: <061.d4f15a507ef882a5cd719cbc70f9b328@haskell.org> #10293: CallArity taking 20% of compile time -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: merge Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 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 Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): The `lintAnnots` thing may more properly belong in #9630, or perhaps a new ticket... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 03:07:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 03:07:27 -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.1c4e2576cc4d00bf67205530de220ad1@haskell.org> #10316: Move Typeable type-rep generation from use site to definition site -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D757 -------------------------------------+------------------------------------- Changes (by goldfire): * differential: Phab:757 => Phab:D757 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 03:28:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 03:28:01 -0000 Subject: [GHC] #10273: haskeline : Cross-compile from Linux to Windows fails due to In-Reply-To: <044.16994f6a5932b910b77581b817b33330@haskell.org> References: <044.16994f6a5932b910b77581b817b33330@haskell.org> Message-ID: <059.2c7ea9694b633dee69d47ec190578af1@haskell.org> #10273: haskeline : Cross-compile from Linux to Windows fails due to -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: libraries | Version: 7.11 (other) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Building GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10070 | -------------------------------------+------------------------------------- Changes (by erikd): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 03:38:14 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 03:38:14 -0000 Subject: [GHC] #10189: explicit promotions of prefix data constructors can't be parsed naturally In-Reply-To: <048.7a1fa374089d49b55ac4c378c43baf5b@haskell.org> References: <048.7a1fa374089d49b55ac4c378c43baf5b@haskell.org> Message-ID: <063.db798fa94141f58fe63fc5766aefa10a@haskell.org> #10189: explicit promotions of prefix data constructors can't be parsed naturally -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Kinokkory Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10188 | -------------------------------------+------------------------------------- Comment (by goldfire): Yes, that would be a new unexplored ball of wax, and I don't intend to explore it tonight. But, how about this: allow all four forms mentioned above. I have two reasons: * No breakage of existing code. * It's conceivable that the quote-on-the-outside form (that is, the existing, stupid form) will make decent sense some day. But please don't do this if it's hard. I fully agree on not paying now for something that might not happen later. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 06:30:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 06:30:51 -0000 Subject: [GHC] #4012: Compilation results are not deterministic In-Reply-To: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> References: <043.9c3dc141e8901acb12e4d7c1e6038096@haskell.org> Message-ID: <058.ec33a3c41e0997196ad0c14754ac1059@haskell.org> #4012: Compilation results are not deterministic -------------------------------------+------------------------------------- Reporter: kili | Owner: Fuuzetsu Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 6.12.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Fuuzetsu): Got the below in mail few days ago but I don't have time to investigate myself for next few weeks. Just putting it out there. Seems like a pretty big issue. -- Hi, trac seems to be down currently so I'm sending this directly to you. Using GHC 7.10, I reduced the code to this: {{{ {-# LANGUAGE GeneralizedNewtypeDeriving #-} module Test where import Control.Monad.Trans.Reader newtype EventM a = EventM { unEventM :: ReaderT () IO a } deriving (Functor, Applicative, Monad) }}} Compiling with: {{{ ghc -i../.. test.hs -O ghc --show-iface test.hi > 1.hi ghc -i../.. test.hs -O -fforce-recomp ghc --show-iface test.hi > 2.hi }}} Now {{{1.hi}}} and {{{2.hi}}} differ, including in their ABI hash. I'm not sure if there are any other examples of nondeterminism in this module, since I continued reducing as long as GHC gave different interface hashes, I did not check whether the cause was actually the same. In this case, this seems to be the most significant difference: {{{ 512a513,517 "SPEC/Test $fApplicativeReaderT_$cpure @ () @ IO" [ALWAYS] forall $dFunctor :: Functor (ReaderT () IO) $dApplicative :: Applicative IO $fApplicativeReaderT_$cpure @ () @ IO $dFunctor $dApplicative = $fMonadEventM_$s$fApplicativeReaderT_$cpure 521,525d525 "SPEC/Test $fMonadReaderT_$creturn @ () @ IO" [ALWAYS] forall $dApplicative :: Applicative (ReaderT () IO) $dMonad :: Monad IO $fMonadReaderT_$creturn @ () @ IO $dApplicative $dMonad = $fMonadEventM_$s$fMonadReaderT_$creturn }}} If I read this correctly, it means that in one case, a specialization rule is generated for return, will in the other case, GHC generates one for pure. Looking further, there is also the following difference: {{{ $fMonadEventM_$s$fApplicativeReaderT :: Applicative (ReaderT () IO) {- HasNoCafRefs, Strictness: m, Inline: [ALWAYS] CONLIKE, Unfolding: DFun:. @ (ReaderT () IO) $fMonadEventM3 $fMonadEventM_$s$fMonadReaderT_$creturn ($fApplicativeReaderT_$c<*> @ () @ IO $fMonadEventM3 $fApplicativeIO) $fMonadEventM_$s$fApplicativeReaderT_$c*> $fMonadEventM_$s$fApplicativeReaderT_$c<* -} vs $fMonadEventM_$s$fApplicativeReaderT :: Applicative (ReaderT () IO) {- HasNoCafRefs, Strictness: m, Inline: [ALWAYS] CONLIKE, Unfolding: DFun:. @ (ReaderT () IO) $fMonadEventM3 $fMonadEventM_$s$fApplicativeReaderT_$cpure ($fApplicativeReaderT_$c<*> @ () @ IO $fMonadEventM3 $fApplicativeIO) $fMonadEventM_$s$fApplicativeReaderT_$c*> $fMonadEventM_$s$fApplicativeReaderT_$c<* -} }}} (Notice the pure vs return again) Regards, Benno -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 06:42:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 06:42:48 -0000 Subject: [GHC] #10317: Event manager: Multishot registrations only fire once In-Reply-To: <046.366b04e6c61d4f194d732df66f1a8423@haskell.org> References: <046.366b04e6c61d4f194d732df66f1a8423@haskell.org> Message-ID: <061.5c716b542816f0488d857911b2dd97bd@haskell.org> #10317: Event manager: Multishot registrations only fire once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by basvandijk): * cc: basvandijk (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 07:38:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 07:38:39 -0000 Subject: [GHC] #10309: ApiAnnotations : mkGadtDecl discards annotations for HsFunTy In-Reply-To: <044.791eb2a4ed7ab1e518108e5118a46c0b@haskell.org> References: <044.791eb2a4ed7ab1e518108e5118a46c0b@haskell.org> Message-ID: <059.a72da8f0354e2866448b41252479b343@haskell.org> #10309: ApiAnnotations : mkGadtDecl discards annotations for HsFunTy -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D848 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 07:54:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 07:54:50 -0000 Subject: [GHC] #10260: last uses too much space with optimizations disabled In-Reply-To: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> References: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> Message-ID: <062.9f3f368cdf2bb82cf73266e886331e04@haskell.org> #10260: last uses too much space with optimizations disabled -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D847 -------------------------------------+------------------------------------- Comment (by nomeata): > And yet the comment is reasonably convincing. I'm not sure what to do here. I think we are doing the right thing here. As far as I know, we also take the number of arguments given by the user as an indication when things should inline or not; if we eta-expand PAPs, we take this possibility of control away from the user. In this particular case: What if I had written `last` this way intentional, so that the rule for `foldl` would _not_ fire here, but only after `last` was inlined at a position where it is passed an argument? (Or am I talking non-sense if we are talking about PAPs, in contrast to functions that might be eta-expanded more.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 08:01:20 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 08:01:20 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.cdd84af89940a67a49636e94e400fee9@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * owner: => ezyang Comment: Hello all, if you could, could you try GHC with this patch: https://phabricator.haskell.org/D817 ? I think this will at least make it -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 08:02:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 08:02:09 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.757b283ab62f9d7cbfaf0a91228625eb@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by adamgundry): I like idea of using an `Error` type family, but I don't think this should be automatic for all closed type families, or at least there should be some way to switch it off (see Phab:D481). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 08:04:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 08:04:30 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.5dfdf7bc7fcf608ca90f559d5becca81@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): I can fix the proximal error fairly easily; just remove the unconditional lookup from `mkQualPackage`. I'm less clear why haskell-src-exts is not in the database. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 08:19:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 08:19:28 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.7d221ea26ec1f1eadf040324b04b494d@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Replying to [comment:4 ezyang]: > I can fix the proximal error fairly easily; just remove the unconditional lookup from `mkQualPackage`. I'm less clear why haskell-src- exts is not in the database. It'd be great to find out! It's very mysterious (to me). S -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 08:21:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 08:21:34 -0000 Subject: [GHC] #10260: last uses too much space with optimizations disabled In-Reply-To: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> References: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> Message-ID: <062.a557e78d673d610c711b39b9496b5929@haskell.org> #10260: last uses too much space with optimizations disabled -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D847 -------------------------------------+------------------------------------- Comment (by simonpj): Well ''all'' eta-expansion risks what you say. If the user wants hat kind of control s/he can use INLINE/INLINEABLE. The eta expansion doesn't happen for the template that is inlined; only in the RHS that is compiled. Which is good. So I do think we should eta-expand here. The only reason not to is described in the comment. I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 08:28:45 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 08:28:45 -0000 Subject: [GHC] #10260: last uses too much space with optimizations disabled In-Reply-To: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> References: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> Message-ID: <062.39c74582adc6e7d446179315d55f1153@haskell.org> #10260: last uses too much space with optimizations disabled -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D847 -------------------------------------+------------------------------------- Comment (by nomeata): Ah, right, the template is stored before this happens; good. What is our motivation to eta-expand PAPs? In this case, it is to allow for RULES to fire. Is it not likely that in order for RULES to fire, we might have to eta-expand beyond a coercion? So it does not gain a lot in robustness. I?m inclined to wait for more than just this example to give this a shot, after all, implementing the heuristics (?if it is a PAP, and there is a chance to eta-expand, but only up to the next coercion...?) does not really make the code simpler... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 09:17:16 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 09:17:16 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.7a16ba61ad0cb90cfaf156894df82094@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jstolarek): Adam, you meant Phab:D841, not Phab:D481. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 09:52:13 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 09:52:13 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.5480e50373dd282a25e252b23027d6be@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): OK, did some reading of haskell-src-exts-qq and it's the same problem as https://github.com/ekmett/lens/issues/496 and #9745: {{{ -- | The generic functions in 'Language.Haskell.TH.Quote' don't use global -- names for syntax constructors. This has the unfortunate effect of breaking -- quotation when the haskell-src-exts syntax module is imported qualified. -- The solution is to set the flavour of all names to 'NameG'. qualify :: Name -> Name -- Need special cases for constructors used in string literals. Assume nearly -- all else is a datatype defined in Syntax module of haskell-src-exts. qualify n | ":" <- nameBase n = '(:) | "[]" <- nameBase n = '[] | "(,)" <- nameBase n = '(,) | "Nothing" <- nameBase n = 'Nothing | "Just" <- nameBase n = 'Just | "SrcLoc" <- nameBase n = 'Hs.SrcLoc | "Boxed" <- nameBase n = 'Hs.Boxed | otherwise = Name (mkOccName (nameBase n)) flavour where pkg = "haskell-src-exts-" ++ VERSION_haskell_src_exts flavour = NameG VarName (mkPkgName pkg) (mkModName "Language.Haskell.Exts.Syntax") }}} This is not going to work with package keys. It seems pretty clear to me that we should improve the error message in this case, though it's not altogether clear where it should live (probably the TH code?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 09:53:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 09:53:15 -0000 Subject: [GHC] #10301: Plugins/dynamic loading subtly broken (it seems) In-Reply-To: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> References: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> Message-ID: <067.05bb912329900bf2ca6ada299dd12ea5@haskell.org> #10301: Plugins/dynamic loading subtly broken (it seems) -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #8276 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by darchon): A similar panic also happens when you run doctest http://hackage.haskell.org/package/doctest on a file that uses a type- checker plugin https://github.com/christiaanb/ghc-typelits- natnormalise/blob/master/tests/Tests.hs {{{ doctest: doctest: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-apple-darwin): Static flags have not been initialised! Please call GHC.parseStaticFlags early enough. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 10:20:44 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 10:20:44 -0000 Subject: [GHC] #10301: Plugins/dynamic loading subtly broken (it seems) In-Reply-To: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> References: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> Message-ID: <067.b896da9f1a6ea4e0bba54f5e491b98be@haskell.org> #10301: Plugins/dynamic loading subtly broken (it seems) -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #8276 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): I'd be much appreciative if you could try these examples with a recent GHC HEAD that includes `ad6d6a76eeeb9e33a96054f18c1306e9ebafa652`. I have also noticed that calling the static flags initializing functions sometimes doesn't fix this sort of issue, especially in GHCi-style situations. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 10:37:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 10:37:32 -0000 Subject: [GHC] #10260: last uses too much space with optimizations disabled In-Reply-To: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> References: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> Message-ID: <062.aa3a7dc4f3b07c53758b9199b5ac7954@haskell.org> #10260: last uses too much space with optimizations disabled -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D847 -------------------------------------+------------------------------------- Comment (by simonpj): Maybe. But eta expansion is in general a tremendously good thing. I'd love just to try it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 10:39:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 10:39:07 -0000 Subject: [GHC] #10319: Eta expand PAPs Message-ID: <046.b3c3c7cd138df67521682745f755e763@haskell.org> #10319: Eta expand PAPs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- SPJ writes in ticket:10260#comment:11: But see this note in SimplUtils: {{{ Note [Do not eta-expand PAPs] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We used to have old_arity = manifestArity rhs, which meant that we would eta-expand even PAPs. But this gives no particular advantage, and can lead to a massive blow-up in code size, exhibited by Trac #9020. Suppose we have a PAP foo :: IO () foo = returnIO () Then we can eta-expand do foo = (\eta. (returnIO () |> sym g) eta) |> g where g :: IO () ~ State# RealWorld -> (# State# RealWorld, () #) But there is really no point in doing this, and it generates masses of coercions and whatnot that eventually disappear again. For T9020, GHC allocated 6.6G beore, and 0.8G afterwards; and residency dropped from 1.8G to 45M. But note that this won't eta-expand, say f = \g -> map g Does it matter not eta-expanding such functions? I'm not sure. Perhaps strictness analysis will have less to bite on? }}} The worse code for the un-eta-expanded code for last is perhaps an example of the last paragraph! And yet the comment is reasonably convincing. I'm not sure what to do here. One thing that might be worth trying is to eta-expand as far as poss without bumping into a coercion. That would expand last but not foo. Want to try that? We may fix last but there are sure to be other cases, and the more robust the optimisations the better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 11:44:49 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 11:44:49 -0000 Subject: [GHC] #10307: Api Annotations: RdrHsSyn.mkAtDefault causes annotations to be disconnected. In-Reply-To: <044.a92aa56f1812e43ed7dcf62c77358ffd@haskell.org> References: <044.a92aa56f1812e43ed7dcf62c77358ffd@haskell.org> Message-ID: <059.c0ecf08c248d0422a57a8c204024e5fe@haskell.org> #10307: Api Annotations: RdrHsSyn.mkAtDefault causes annotations to be disconnected. -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D842 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 12:21:37 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 12:21:37 -0000 Subject: [GHC] #10281: Type error with Rank-n-types In-Reply-To: <043.715543d69d09145192a2c9ffe2902dd1@haskell.org> References: <043.715543d69d09145192a2c9ffe2902dd1@haskell.org> Message-ID: <058.caf6fbb43bcdd57c0ed07df88f903fad@haskell.org> #10281: Type error with Rank-n-types -------------------------------------+------------------------------------- Reporter: rhjl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Peirce_eq_LEM.hs Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rhjl): Replying to [comment:7 simonpj]: > Could you propose some actual, concrete sentences to add or change in user manual? Then I'll just make the change. As a bona fide user you are in a far better position to draft the words than me. In 7.13.6 [Arbitrary-rank polymorphism], before two paragraphs ?The `-XRankNTypes` option is also [?]? and ?The obselete [sic] language options [?]? add: In particular, in `data` and `newtype` declarations the constructor arguments may be polymorphic types of any rank. Note that the declared types are nevertheless always monomorphic. This is important because by default GHC will not instantiate type variables to a polymorphic type (cf. 7.13.7 [Impredicative Polymorphism]). The examples below demonstrate some uses. In 7.13.6.1 [Examples] replace the first two sentences with These are examples of `data` and `newtype` declarations with polymorphic constructor arguments: After the code that shows the types of the constructors add the following: By default GHC will not instantiate type variables to a polymorphic type: given {{{#!hs f :: (forall a. a -> a) -> (forall a. a -> a) }}} the term `f id` has type `forall a. a -> a`, but the term `id f` cannot be assigned a type because that would require an instantiation of `forall a. a -> a` with the polymorphic type of `f` in place of the type variable `a`. This does not present a problem when typing the term `id id`; the typing in that case proceeds as follows: 1. the top-level quantifiers in the types of the two occurrences of `id` are removed, and their bound variables are renamed to make them unique. This gives types `a -> a` and `b -> b`; 2. the type variable `a` is instantiated to the ? now monomorphic ?? type `b -> b`; 3. the free variable `b` in the result-type `b -> b` of the function application is universally quantified; The same procedure for `id f` gives `f` the type `(forall a. a -> a) -> b -> b` for some unique type variable `b` in step 1, by removing the effectively top level quantifier to the right of the arrow. The resulting type is nevertheless still polymorphic, and so step 2 fails. [I hope that I got this whole explanation remotely correct. Please feel free to improve it: I am sure that it can be expressed both briefer and more accurately. What I say here also does not explain why the definition `f = id` works, and in fact I am somewhat confused by that.] The next example illustrates how one can use `newtype` declarations to work around this issue. {{{#!hs type Poly = (forall a. a -> a) -> (forall a. a -> a) newtype Wrap = Wrap { unwrap :: Poly } f :: Poly f = id ok :: Poly ok = unwrap (id (Wrap f)) }}} In 7.13.7 [Impredicative Polymorphism] replace the sentence ?This means that you can call a polymorphic [?]? with Impredicative polymorphism allows type variables to be instantiated to polymorphic types (cf. 7.13.6 [Arbitrary-rank polymorphism]). For example the following is valid with `-XImpredicativeTypes`: {{{#!hs type Poly = (forall a. a -> a) -> (forall a. a -> a) f :: Poly f = id ok :: Poly ok = id f }}} In this example the type variable `a` in the type `forall a. a -> a` of `id` needs to be instantiated to a polymorphic type. Contrast this with the discussion in 7.13.6.1 [Examples] for more details. In particular impredicative polymorphism also allows the application of type constructors to polymorphic types, and of various term constructors to terms of polymorphic types. For example, given the above definitions, the following makes sense: {{{#!hs ok2 :: [Poly] ok2 = [f] }}} Here is a more elaborate example: [continue with the current example] > > By the way: this issue with impredicative instantiations precludes the use of `($)` and `(.)` to get rid of excessive parenthesis in certain situations. Is there a workaround? > > Becuase of this `($)` has its own special typing rule in GHC. But `(.)` does not (yet). Is the special type of `($)` only available when using the Prelude? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 12:39:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 12:39:51 -0000 Subject: [GHC] #9020: Massive blowup of code size on trivial program In-Reply-To: <046.bab0bc7fbd776024468f95f75c63d364@haskell.org> References: <046.bab0bc7fbd776024468f95f75c63d364@haskell.org> Message-ID: <061.65c7530d3dc6be265c927790434596cc@haskell.org> #9020: Massive blowup of code size on trivial program -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | perf/compiler/T9020 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): I might have a different fix for this, that would also avoid implementing the strange heuristics in #10319: In T9020, the problem is not really that `return ()` is eta-expanded, but that it is eta-expaned in a phase where no inlining happens, namely in the gentle phase. If we do not eta-expand in this phase (by changing `simpl_gently` in `SimplCore`), we can revert to `old_arity = manifestArity` and this program still compiles quickly. Doesn?t that look like the cleaner solution? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 12:52:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 12:52:53 -0000 Subject: [GHC] #9840: Permit empty closed type families In-Reply-To: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> References: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> Message-ID: <064.e2ea3c0000a7c6bcdf0290a0a7473ce2@haskell.org> #9840: Permit empty closed type families -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8028 | Differential Revisions: Phab:D841 -------------------------------------+------------------------------------- Comment (by goldfire): I'm afraid something smells a little off here. I agree that we should permit empty closed type families -- that's not a problem. But I'm not convinced that empty CTFs are the solution to Adam's problem. What Adam really wants here is the ability to create new type-level constants at arbitrary kind. An empty CTF fits the bill, but there's something strange about it. Despite my early objections, I've come to agree with Lennart's viewpoint in #9636 that a CTF that is known to be unable to reduce is a strange beast that should probably be disallowed. Here is a simple proposal: {{{ type constant Unit :: * -- kind annotation required; types of kind * are promoted to kinds -- this is essentially indistinguishable from `data Unit` type constant Meter :: Unit -- Here, we can define a new constant of a non-* kind. This is very useful! type constant Second :: Unit -- We can even pattern-match on these constants: type family UnitToString (x :: Unit) :: Symbol where UnitToString Meter = "m" UnitToString Second = "m" type constant Weird :: Nat -> Bool -- This is OK to declare. But we *cannot* pattern-match on it, because the return -- kind is closed. }}} This last example may be controversial, but I think it's OK. The others are less controversial in my opinion. What this essentially does is allow for ''open'' datakinds. Once these constants are declared, then a plugin can define an equational theory over them. Unfortunately, this is a much bigger change than just allowing empty CTFs. But it somehow smells better to me. Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 12:53:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 12:53:10 -0000 Subject: [GHC] #10319: Eta expand PAPs In-Reply-To: <046.b3c3c7cd138df67521682745f755e763@haskell.org> References: <046.b3c3c7cd138df67521682745f755e763@haskell.org> Message-ID: <061.7148da40f8e21bdd6ff069f7a789fb32@haskell.org> #10319: Eta expand PAPs -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): I?ll defer this until the idea in ticket:9020#comment:4 has been evaluated, as it would make this task moot. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 12:58:16 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 12:58:16 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.8da6e26a67e693d4e2179233a69c1f60@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): OK, it looks like at some point between 7.10 and HEAD the error message got better. But I don't know what the proximal commit was: {{{ [ezyang at hs01 th]$ /home/hs01/ezyang/ghc-quick/inplace/bin/ghc-stage2 --interactive T10279.hs -XTemplateHaskell GHCi, version 7.11.20150417: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling T10279 ( T10279.hs, interpreted ) T10279.hs:5:10: error: Failed to load interface for ?A? no package matching ?base-4.8.1.0? was found In the expression: (base-4.8.1.0:A.Foo) In an equation for ?blah?: blah = (base-4.8.1.0:A.Foo) [ezyang at hs01 th]$ /home/hs01/ezyang/ghc-7.10/inplace/bin/ghc-stage2 --interactive T10279.hs -XTemplateHaskell GHCi, version 7.10.0.20150317: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling T10279 ( T10279.hs, interpreted ) T10279.hs:5:8:ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.10.0.20150317 for x86_64-unknown-linux): qual_pkg base-4.8.1.0 Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} The error message is still pretty confusing but at least it is not a panic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 13:21:57 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 13:21:57 -0000 Subject: [GHC] #9020: Massive blowup of code size on trivial program In-Reply-To: <046.bab0bc7fbd776024468f95f75c63d364@haskell.org> References: <046.bab0bc7fbd776024468f95f75c63d364@haskell.org> Message-ID: <061.140b9b977dd47e5a172e323ed34a51b0@haskell.org> #9020: Massive blowup of code size on trivial program -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | perf/compiler/T9020 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): > In T9020, the problem is not really that `return ()` is eta-expanded, but that it is eta-expanded in a phase where no inlining happens, namely in the gentle phase. If we do not eta-expand in this phase (by changing `simpl_gently` in `SimplCore`), we can revert to `old_arity = manifestArity` and this program still compiles quickly. Aha. That sounds cool. I buy. * NB that I am (separately) wanting to make some inlining happen in the gentle phase too...So the no-eta thing should depend on sm_inline rather than on the phase. That makes the reasoning clearer too. * Rather than muttering about PAPs, perhaps e can simply switch off eta- expansion ''altogether'' under these conditions? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 13:27:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 13:27:25 -0000 Subject: [GHC] #9020: Massive blowup of code size on trivial program In-Reply-To: <046.bab0bc7fbd776024468f95f75c63d364@haskell.org> References: <046.bab0bc7fbd776024468f95f75c63d364@haskell.org> Message-ID: <061.0d144a0d728b6888749aec96a74e3e4e@haskell.org> #9020: Massive blowup of code size on trivial program -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | perf/compiler/T9020 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): > Rather than muttering about PAPs, perhaps we can simply switch off eta- expansion altogether under these conditions? With "these conditions", do you mean "gentle phase" a.k.a. "sm_inline = False"? If so, then that is precisely what I am proposing: {{{ -- initial simplify: mk specialiser happy: minimum effort please simpl_gently = CoreDoSimplify max_iter (base_mode { sm_phase = InitialPhase , sm_names = ["Gentle"] , sm_rules = rules_on -- Note [RULEs enabled in SimplGently] , sm_inline = False , sm_case_case = False , sm_eta_expand = False}) -- This line was added -- Don't do case-of-case transformations. -- This makes full laziness work better }}} We still need to distinguish between `sm_inline` and `sm_eta_expand`, as the former is always on in the `base_mode`, while the second one depends on `Opt_DoLambdaEtaExpansion`. (Which means that this flag isn?t correctly named, as it affects all eta- expansion, not just lambda-eta-expansion.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 13:42:49 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 13:42:49 -0000 Subject: [GHC] #10312: ApiAnnotations: misplaced AnnComma for squals production In-Reply-To: <044.7a2c40e552765c1f4f92f1873968df8c@haskell.org> References: <044.7a2c40e552765c1f4f92f1873968df8c@haskell.org> Message-ID: <059.7db7e7afcf5361271ff4f71995d5312f@haskell.org> #10312: ApiAnnotations: misplaced AnnComma for squals production -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 13:52:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 13:52:35 -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.10d6bf34157cec6c442bfa490eb7fb2b@haskell.org> #10068: Make the runtime reflection API for names, modules, locations more systematic -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): See #10279 for another consequence of not having centralized `Package` structure: users keep using package names when they should use package keys, and the API naming (`mkPkgName`) doesn't help either! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 13:53:16 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 13:53:16 -0000 Subject: [GHC] #10317: Event manager: Multishot registrations only fire once In-Reply-To: <046.366b04e6c61d4f194d732df66f1a8423@haskell.org> References: <046.366b04e6c61d4f194d732df66f1a8423@haskell.org> Message-ID: <061.d89224f9d8b93751f1aa328e07d38c04@haskell.org> #10317: Event manager: Multishot registrations only fire once -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: D849 -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => D849 Comment: I've written a pair of tests exercising both failure modes, https://github.com/bgamari/event-manager-tests -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 13:57:49 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 13:57:49 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.a9dac5281eb33353502473421cb6aad4@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Here is an easy new error message we can do: {{{ testsuite/tests/th/T10279.hs:5:10: error: Failed to load interface for ?A? no package key matching ?base-4.8.1.0? was found (This package key looks like the source package ID; the real package key is ?base?) In the expression: (base-4.8.1.0:A.Foo) In an equation for ?blah?: blah = (base-4.8.1.0:A.Foo) }}} but I think a better plan is to update `cvtName` in `hsSyn/Convert.hs` to validate modules in `flavour`. (But maybe we want to update the error message here anyway.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 14:10:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 14:10:28 -0000 Subject: [GHC] #9020: Massive blowup of code size on trivial program In-Reply-To: <046.bab0bc7fbd776024468f95f75c63d364@haskell.org> References: <046.bab0bc7fbd776024468f95f75c63d364@haskell.org> Message-ID: <061.a118bd822f027914692f75ae5d995d5c@haskell.org> #9020: Massive blowup of code size on trivial program -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | perf/compiler/T9020 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): Here is some concrete code to talk about: Phab:D851 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 14:55:52 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 14:55:52 -0000 Subject: [GHC] #10250: API Annotations : add Locations in hsSyn were layout occurs In-Reply-To: <044.e9f7429502526fbd11c0a38b5739b89e@haskell.org> References: <044.e9f7429502526fbd11c0a38b5739b89e@haskell.org> Message-ID: <059.85a3eb5dae908670148466efe500fd74@haskell.org> #10250: API Annotations : add Locations in hsSyn were layout occurs -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D815 -------------------------------------+------------------------------------- Changes (by alanz): * milestone: 7.10.2 => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 14:56:28 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 14:56:28 -0000 Subject: [GHC] #9840: Permit empty closed type families In-Reply-To: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> References: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> Message-ID: <064.ec045e60c44c0ff0b4d0e8002a40038e@haskell.org> #9840: Permit empty closed type families -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8028 | Differential Revisions: Phab:D841 -------------------------------------+------------------------------------- Comment (by adamgundry): > What Adam really wants here is the ability to create new type-level constants at arbitrary kind. Is it? Open datakinds would be nice, but `Symbol` and `*` already give us quite a lot of wriggle room. My real problem is more in creating type-level function symbols without any equational theory, which (with Phab:D841 at least) goes like this: {{{ data Unit type family Mul (u :: Unit) (v :: Unit) :: Unit where }}} In particular, to avoid conflict with plugin-generated axioms, `Mul` * must be saturated; * is not injective, so `Mul u v ~ Mul v u` does not imply `u ~ v`; * cannot be used in patterns; * cannot be given any instances by the user (this is the only condition not satisfied by an open type family). I don't quite understand how your proposal would work for this case. What does it mean to declare `Weird` as a constant in a closed kind? Note that giving `Mul` kind `Unit -> Unit -> Unit` is no good, because that means it is injective (at least unless we add another flavour of type-level function space). In any case, adding a whole new declaration form feels like rather more work than my needs justify. Phab:D841 is a relatively simple change (deleting 7 lines of code, in its original incarnation before distinguishing abstract/empty CTFs) that is consistent with the way type families currently work. No matter how much we might wish it otherwise, type families are very different from term- level functions. I'm happy to see a fix for #9636, but preferably in a backwards-compatible way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 15:01:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 15:01:35 -0000 Subject: [GHC] #9636: Function with type error accepted In-Reply-To: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> References: <047.40d618ba556abcff453b3e145ac728eb@haskell.org> Message-ID: <062.27bbef9f3f85d9649c1a8db851c31831@haskell.org> #9636: Function with type error accepted -------------------------------------+------------------------------------- Reporter: augustss | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by adamgundry): Thanks, Janek, I did. See also the related discussion on #9840. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 15:38:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 15:38:07 -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.280da39607b6fb6ae569a487b100a8b0@haskell.org> #10068: Make the runtime reflection API for names, modules, locations more systematic -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Are you sure? This ticket refers to the '''runtime reflection API''' of `Typeable`, `Data` etc. Is that what #10279 is about? If so could you give a small example? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 15:43:29 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 15:43:29 -0000 Subject: [GHC] #10288: -flate-dmd-anal triggers "Entered absent arg" In-Reply-To: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> References: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> Message-ID: <061.766accfa7f4de86598294ac4334c5c18@haskell.org> #10288: -flate-dmd-anal triggers "Entered absent arg" -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Oh VERY interesting! I have reproduced the problem with 7.10, and it is YET ANOTHER bug in the demand analyser. Here is the offending code {{{ dmdAnal' sigs dmd (App fun (Coercion co)) = (fun_ty, App fun' (Coercion co)) where (fun_ty, fun') = dmdAnal sigs dmd fun }}} The incoming demand `dmd` is not modified before passing it on to `fun`. But that is wrong wrong wrong. That gets the demands from the function out of step, so the wrong demand goes to the wrong argument. It's a miracle that this has not been causing chaos for ages. Horror. Coercions are ''value'' arguments and so they must be treated as such. I think the solution is simply to delete these lines so that coercion arguments are handled uniformly; but I want to tread carefully. Thank you for extracting this example. More anon. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 16:12:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 16:12:48 -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.1c3746a5063148c895ac492017ab62a4@haskell.org> #10068: Make the runtime reflection API for names, modules, locations more systematic -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): I suppose not; it is only related. An example is the `NameG` constructor: {{{ Prelude Language.Haskell.TH Language.Haskell.TH.Syntax> :t NameG NameG :: NameSpace -> PkgName -> ModName -> NameFlavour Prelude Language.Haskell.TH Language.Haskell.TH.Syntax> :info PkgName newtype PkgName = PkgName String -- Defined in `Language.Haskell.TH.Syntax' instance Eq PkgName -- Defined in `Language.Haskell.TH.Syntax' instance Ord PkgName -- Defined in `Language.Haskell.TH.Syntax' Prelude Language.Haskell.TH Language.Haskell.TH.Syntax> :info ModName newtype ModName = ModName String -- Defined in `Language.Haskell.TH.Syntax' instance Eq ModName -- Defined in `Language.Haskell.TH.Syntax' instance Ord ModName -- Defined in `Language.Haskell.TH.Syntax' }}} So, the suggestion is that with a unified reflection API, it would make sense to make TH also accept this information. But maybe this is just a separate concern! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 16:14:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 16:14:11 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.803a67f0babf87dc58d2fa39e816eeba@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by diatchki): Well, `=>` is not really a type-constructor, but rather a syntactic form. So I don't think it should ever appear alone, or partially applied, in a Haskell program. If we ever promoted it to an actual type-constructor status---which is an interesting idea---I think that we should assign it its own type- constructor and stop reusing the function-space constructor. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 16:57:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 16:57:46 -0000 Subject: [GHC] #10180: Lint check: Empty alternatives imply bottoming scrutinee In-Reply-To: <046.44e015288991066cebe38e4a3f60f704@haskell.org> References: <046.44e015288991066cebe38e4a3f60f704@haskell.org> Message-ID: <061.1ced0bc5b3a44ad613de5d97d6613f7f@haskell.org> #10180: Lint check: Empty alternatives imply bottoming scrutinee -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): A small change in the simplifier settings showed a False Positive of the new lint check: https://phabricator.haskell.org/D851#23033 Given that the check is known to be not complete, I suggest to turn it into a lint warning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 18:09:56 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 18:09:56 -0000 Subject: [GHC] #10180: Lint check: Empty alternatives imply bottoming scrutinee In-Reply-To: <046.44e015288991066cebe38e4a3f60f704@haskell.org> References: <046.44e015288991066cebe38e4a3f60f704@haskell.org> Message-ID: <061.43e153e97d6a7ba10ed243655d57ef61@haskell.org> #10180: Lint check: Empty alternatives imply bottoming scrutinee -------------------------------------+------------------------------------- Reporter: nomeata | Owner: nomeata Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Let's not move too fast See my comments on Phab:D851. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 18:24:54 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 18:24:54 -0000 Subject: [GHC] #9809: Overwhelming the TimerManager In-Reply-To: <048.e280f99ffe1a31fd40597b99a9aab09a@haskell.org> References: <048.e280f99ffe1a31fd40597b99a9aab09a@haskell.org> Message-ID: <063.f94ff462d90f9a885737368d87ef4590@haskell.org> #9809: Overwhelming the TimerManager -------------------------------------+------------------------------------- Reporter: fryguybob | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.9 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by davean): Confirming this still occurs on 7.10.1. {{{ $ ./Main -f +RTS -s 3,260,792,712 bytes allocated in the heap 3,797,542,040 bytes copied during GC 103,056,944 bytes maximum residency (88 sample(s)) 11,062,480 bytes maximum slop 309 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 5589 colls, 0 par 0.164s 0.160s 0.0000s 0.0004s Gen 1 88 colls, 0 par 1.844s 1.909s 0.0217s 0.0656s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.000s ( 0.000s elapsed) MUT time 0.220s ( 0.266s elapsed) GC time 2.008s ( 2.069s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 2.228s ( 2.335s elapsed) Alloc rate 14,821,785,054 bytes per MUT second Productivity 9.9% of total user, 9.4% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 }}} {{{ ./Main +RTS -s 182,472,160 bytes allocated in the heap 35,704,856 bytes copied during GC 3,270,336 bytes maximum residency (7 sample(s)) 89,368 bytes maximum slop 8 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 349 colls, 0 par 0.020s 0.016s 0.0000s 0.0002s Gen 1 7 colls, 0 par 0.000s 0.008s 0.0011s 0.0020s TASKS: 4 (1 bound, 3 peak workers (3 total), using -N1) SPARKS: 0 (0 converted, 0 overflowed, 0 dud, 0 GC'd, 0 fizzled) INIT time 0.000s ( 0.000s elapsed) MUT time 0.112s ( 0.152s elapsed) GC time 0.020s ( 0.024s elapsed) EXIT time 0.000s ( 0.000s elapsed) Total time 0.132s ( 0.177s elapsed) Alloc rate 1,629,215,714 bytes per MUT second Productivity 84.8% of total user, 63.4% of total elapsed gc_alloc_block_sync: 0 whitehole_spin: 0 gen[0].sync: 0 gen[1].sync: 0 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 18:30:57 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 18:30:57 -0000 Subject: [GHC] #9809: Overwhelming the TimerManager In-Reply-To: <048.e280f99ffe1a31fd40597b99a9aab09a@haskell.org> References: <048.e280f99ffe1a31fd40597b99a9aab09a@haskell.org> Message-ID: <063.98803e079ed900c1c08600403b53fa6f@haskell.org> #9809: Overwhelming the TimerManager -------------------------------------+------------------------------------- Reporter: fryguybob | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by davean): * version: 7.9 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 17 20:17:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 17 Apr 2015 20:17:04 -0000 Subject: [GHC] #9840: Permit empty closed type families In-Reply-To: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> References: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> Message-ID: <064.aabe8f3398d20d59ddeea2e08cff6388@haskell.org> #9840: Permit empty closed type families -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8028 | Differential Revisions: Phab:D841 -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:5 adamgundry]: > > What Adam really wants here is the ability to create new type-level constants at arbitrary kind. > > Is it? Yes. :) But you don't know it yet. After posting this morning, I thought more about this. The more I thought about it, the more I liked it. The key idea (for me) is that currently Haskell has many different forms of type-level symbol declaration (`data`, `newtype`, `type family`, `data family`, `type`, `class`, maybe more?), but perhaps these can all be rolled into one, more flexible type of declaration. (I'm not necessarily proposing to expose this to users as such, but to think of it this way.) At the moment, I'm concerned only with how these type-level symbol declarations behave in types, completely forgetting about any term-level behavior. I'm also forgetting about FC for the moment, concentrating only on Haskell. * `data`: Declares generative, injective constants whose result kind must be `*`. Can be pattern-matched. When considered as a kind, the set of inhabitants is closed and always known. * `newtype`: Identical to `data`, except that `newtype`s are neither generative nor injective under representational equality. * `type family`: Not generative, not injective. Accordingly, must appear always saturated. (GHC's type variable application operation in types -- that is, `a b` where `a` and `b` are type variables -- assumes that the function is generative & injective. Anything that isn't must always be saturated.) These have a limited reduction behavior known to GHC. Closed type families have a fixed reduction behavior; open type families' reduction behavior can be extended. Cannot be pattern-matched against. * `data family`: Generative & injective. When considered as a kind (in the future with kind equalities) the set of inhabitants is open, but each extension of this set requires parameters to be apart from previous sets. Can be pattern-matched against. * `type`: Like a `type family`, but with even more limited behavior. * `class`: Like `data`, but the result kind must be `Constraint`. Phab:D202 extends this collection with injective type families, which are like type families, but allow injectivity in some subset of its parameters. I have wanted the following: * A generative, injective type constant, whose result kind is `*`. When considered as a kind, the set of inhabitants is open. Can be pattern- matched against. This is like `*`, but still distinguished from `*`. One may argue that this is like `Symbol`, but I want to be able to hook into GHC's module system to disambiguate identically-named inhabitants. I wanted this for `units`, where I settle for declaring my extensible set of units in kind `*`. This leads to worse error messages than would be possible if I could declare a new, open kind. * A generative, injective type constant that can '''not''' be pattern- matched against. This is the right place for `Any`. Adam seems to want: * A non-generative, non-injective type-level symbol with reduction behavior unknown to GHC. This cannot be pattern-matched against. The reduction behavior is implemented in a plugin. This type of declaration is also the correct characterization of the type-lits operators. So it seems that there are several characteristics each type-level declaration varies in: * Generativity (possibly different choices for nominal vs. representational equality) * Injectivity (possibly different choice for nominal vs. representational equality, and per argument) * Matchability (if something is matchable, it had better be generative and injective, too!) * Open/closed In addition, GHC blesses type families (and type synonyms) with a limited form of reduction. ------------------- I'm not totally sure where all of this goes, but somehow classifying this menagerie seems meaningful. It also helps to identify missing spots and to understand what is going on better. Perhaps using empty closed type families for Adam's needs and for type-lits is OK, but it isn't really what we want, according to these classifications: these type-level symbols have an unknown reduction behavior, in contrast to empty closed type families, which have a known (vacuous) reduction behavior. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 18 00:55:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Apr 2015 00:55:20 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.46eb857865eb1b36a818decdd3955f67@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:98 diatchki]: > Well, `=>` is not really a type-constructor, but rather a syntactic form. So I don't think it should ever appear alone, or partially applied, in a Haskell program. It doesn't have to appear literally alone. You can already extract a partially applied form, although seemingly not the "constructor" itself. {{{ {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE FlexibleContexts #-} import Data.Typeable f :: Proxy (a b) -> Proxy a f _ = Proxy g = f (Proxy :: Proxy (Eq Int => Int)) h :: Proxy a -> Proxy (a Bool) h _ = Proxy i = h g }}} {{{ *Main> :t g g :: Proxy (* -> *) ((->) (Eq Int)) *Main> :t i i :: Proxy * (Eq Int => Bool) }}} Once you have a partially applied form, you can get `Typeable` instances for the parts, and then compose them, as shown in [comment:90 comment 90]. Interestingly, GHC internally ensures (and I don't know whether this is a bug or an intended feature) that if you try to extract the `(=>)` *itself*, you get `(->) :: * -> * -> *` instead, and a kind matching error. The same applies to `->` if you try to pattern match away an unlifted argument type. But in both cases, you can pattern match away a final *lifted* argument type to get a partially applied `(->)` with an argument of strange kind. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 18 12:30:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Apr 2015 12:30:23 -0000 Subject: [GHC] #10301: Plugins/dynamic loading subtly broken (it seems) In-Reply-To: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> References: <052.1efd9612b96733295747c4ea13bc0951@haskell.org> Message-ID: <067.ffb106a5d5b88d477a28010671386f8b@haskell.org> #10301: Plugins/dynamic loading subtly broken (it seems) -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #8276 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by darchon): Replying to [comment:3 ezyang]: > I'd be much appreciative if you could try these examples with a recent GHC HEAD that includes `ad6d6a76eeeb9e33a96054f18c1306e9ebafa652`. > > I have also noticed that calling the static flags initializing functions sometimes doesn't fix this sort of issue, especially in GHCi-style situations. I tried, but I'm still getting the same error. In the end, I had to add this workaround in my own code: https://github.com/christiaanb/ghc-typelits- natnormalise/commit/afc4f2538081b46439e26e1a2bc6b7a5c3751781 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 18 15:00:16 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Apr 2015 15:00:16 -0000 Subject: [GHC] #10320: -ddump-to-file should create empty dump files when there was nothing to dump Message-ID: <047.561f277130457f34a85813c7ce1004aa@haskell.org> #10320: -ddump-to-file should create empty dump files when there was nothing to dump -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1 Keywords: newcomer | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- For example, I ran with -ddump-rule-firings -ddump-to-file when there were no rule firings. GHC should have created an empty foo.dump-rule-firings file. (Instead it left the existing foo.dump-rule-firings from a previous run intact, which could have been misleading if I didn't already know that the most recent run had no rule firings.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 18 15:30:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Apr 2015 15:30:04 -0000 Subject: [GHC] #10321: GHC.TypeLits.Nat types no longer fully simplified. Message-ID: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> #10321: GHC.TypeLits.Nat types no longer fully simplified. -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Unknown/Multiple Keywords: TypeLits | Type of failure: Other Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following code: {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeOperators #-} import GHC.TypeLits data Vec :: Nat -> * -> * where Nil :: Vec 0 a (:>) :: a -> Vec n a -> Vec (n + 1) a infixr 5 :> }}} when loaded in GHCi 7.8.3, and asking for the type of `(1 :> 2 :> 3 :> Nil)`, gives: {{{ $ ghci example/vec.hs GHCi, version 7.8.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( example/vec.hs, interpreted ) Ok, modules loaded: Main. *Main> :t (3:>4:>5:>Nil) (3:>4:>5:>Nil) :: Num a => Vec 3 a }}} while in GHCi 7.10.1 it gives: {{{ $ ghci example/vec.hs GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( example/vec.hs, interpreted ) Ok, modules loaded: Main. *Main> :t (3:>4:>5:>Nil) (3:>4:>5:>Nil) :: Num a => Vec (2 + 1) a }}} That is, the type-level computation, `((0 + 1) + 1) + 1` is only simplified to `2 + 1` in GHC 7.10.1, whereas in 7.8.3 `2+1` was further simplified to `3`. The same still happens in HEAD (20150417) {{{ $ ghci example/vec.hs GHCi, version 7.11.20150417: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Main ( example/vec.hs, interpreted ) Ok, modules loaded: Main. *Main> :t (3:>4:>5:>Nil) (3:>4:>5:>Nil) :: Num a => Vec (2 + 1) a }}} I strongly feel that the behaviour in ghc 7.8.3 is the desired behaviour. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 18 15:31:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Apr 2015 15:31:38 -0000 Subject: [GHC] #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X Message-ID: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: MacOS X Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- joelteon encountered this issue in a rather complicated program, and we worked out the cause over IRC. Suppose that ghci needs to sequentially load three modules A, B and C, where B refers to symbols from A and C refers to symbols from both A and B. (For example modules B, C and another module D all contain Template Haskell that refers to the previous module(s).) The object code linker currently works like this: - Link the module `A.o` into a dylib `ghc_1.dylib` - Link the module `B.o` against `ghc_1.dylib` into a new dylib `ghc_2.dylib` - Link the module `C.o` against `ghc_2.dylib` into a new dylib `ghc_3.dylib` As a result, `ghc_2.dylib` ends up with a NEEDED (or whatever it's called in Mach-O) entry for `ghc_1.dylib`, and `ghc_3.dylib` ends up with a NEEDED entry for `ghc_2.dylib`. However, this apparently does not satisfy the OS X `dlopen` implementation, which complains about a missing symbol `_A_foo` referenced by `ghc_3.dylib` and which is defined in `ghc_1.dylib`. Apparently the dynamic loader only checks the direct dependencies when trying to resolve undefined symbols. (The Linux dynamic loader seems to be perfectly happy to use an indirect dependency to resolve an undefined symbol. But I found out that the linker [https://sourceware.org/bugzilla/show_bug.cgi?id=10238 gold] has the same sort of behavior as the OS X dynamic loader. I don't know whether there is any standard here, but it seems that we cannot rely on the Linux dynamic loader's behavior.) Presumably the fix is to keep track of all the previous temporary dylibs (rather than just one in `last_temp_so`) and link against all of them when building a new temporary dylib. I'm slightly worried about quadratic behavior here, but I think it's unlikely to be an issue in practice. I have a reproducer at http://lpaste.net/808723564239781888 (which I'll add to the test suite next) and oherrala ran the test on an OS X system with the following results: {{{ =====> Last(ghci) 1167 of 4480 [0, 0, 0] cd ./ghci/scripts && HC="/Users/oherrala/gits/ghc/inplace/bin/ghc-stage2" HC_OPTS="-dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci-history " "/Users/oherrala/gits/ghc/inplace/bin/ghc-stage2" -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci- history --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS Last.run.stdout 2> Last.run.stderr Actual stderr output differs from expected: --- /dev/null 2015-04-18 17:23:26.000000000 +0300 +++ ./ghci/scripts/Last.run.stderr 2015-04-18 17:23:34.000000000 +0300 @@ -0,0 +1,9 @@ +ghc-stage2: panic! (the 'impossible' happened) + (GHC version 7.11.20150418 for x86_64-apple-darwin): + Loading temp shared object failed: dlopen(/var/folders/64/90jfy8lj65bcm1k02syxz_l80000gn/T/ghc18812_0/libghc18812_12.dylib, 5): Symbol not found: _LastA_a_closure + Referenced from: /var/folders/64/90jfy8lj65bcm1k02syxz_l80000gn/T/ghc18812_0/libghc18812_12.dylib + Expected in: flat namespace + in /var/folders/64/90jfy8lj65bcm1k02syxz_l80000gn/T/ghc18812_0/libghc18812_12.dylib + +Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug + Actual stdout output differs from expected: --- ./ghci/scripts/Last.stdout 2015-04-18 16:26:55.000000000 +0300 +++ ./ghci/scripts/Last.run.stdout 2015-04-18 17:23:34.000000000 +0300 @@ -1,3 +1,2 @@ 3 4 -7 *** unexpected failure for Last(ghci) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 18 15:41:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Apr 2015 15:41:07 -0000 Subject: [GHC] #10323: Add Android and iOS Operating Systems in Trac Message-ID: <047.f0e8ed2b242d053a71552d342705050c@haskell.org> #10323: Add Android and iOS Operating Systems in Trac -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: hvr Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Trac & Git | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- These are sufficiently different from Linux/MacOS X to be distinguished from those Operating System values, and sufficiently mainstream to not fall under Other. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 18 16:20:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Apr 2015 16:20:41 -0000 Subject: [GHC] #10324: our rts/ghc-prim/base shared library tricks don't work on Android Message-ID: <047.e2cf4a26e9b91cdd687dbdd933aadeb3@haskell.org> #10324: our rts/ghc-prim/base shared library tricks don't work on Android -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.10.1 Component: Compiler | Operating System: Other Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I experimented with building dynamically linked executables on Android, and figured I should record my findings somewhere. (I'm interested in dynamic Haskell libraries because I'd like to eventually get ghci on Android, though obviously that would also require a bunch of packaging work!) Building a GHC with dynamic library support was no major problem, and I could build a dynamically linked "Hello, world" executable too. The problem arose when trying to actually run the executable: I got a message to the effect that there were unresolved symbols (that live in libHSrts) when loading libHSbase. I tried relinking the executable to put libHSrts before libHSbase in the list of NEEDED shared libraries, and now I instead got an error about missing symbols (that live in libHSbase) when loading libHSrts. I then tried rebuilding libHSrts against libHSbase... and then I got the first error again, about missing symbols (that live in libHSrts) when loading libHSbase, while loading libHSrts. I didn't try also rebuilding libHSbase against libHSrts, because at that point the base library would be dependent on the RTS flavor, which we don't really want. It appears based on these tests that the Android dynamic loader only looks for missing symbols in a shared library in the dependencies of that library in a depth-first fashion, while the Linux ld.so seems to do something more like loading every (direct and indirect) dependency of the executable first and then resolving symbol references between them all at once. I didn't fully characterize the Android loader behavior though, and it's possible that if we could remove the references from libHSrts to libHSbase and libHSghc-prim, then we could list libHSrts first among the dependencies of an executable, and hopefully once libHSrts has been loaded, the loader would then use its symbols to resolve references when loading the libHSghc-prim and libHSbase libraries, even without those libraries having NEEDED entries for libHSrts. Removing the references from libHSrts to libHSbase/libHSghc-prim should be fairly mechanical if we can use constructors in the latter libraries (basically emulate dynamic linking by adding a global variable to libHSrts which is a struct holding the addresses of the base/ghc-prim symbols it needs, and have constructors in those libraries fill in those addresses on load). If that doesn't work, another possibility may be to statically link libHSrts (or whatever part of it we need) into the executable and export libHSrts's dynamic symbols so that they can be used by libHSghc-prim (or other Haskell libraries). I also haven't tested whether this kind of mutual recursion between an executable and its shared library dependencies works on Android. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 18 16:26:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Apr 2015 16:26:49 -0000 Subject: [GHC] #10321: GHC.TypeLits.Nat types no longer fully simplified. In-Reply-To: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> References: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> Message-ID: <061.516df920104a4126c57c07c36992315c@haskell.org> #10321: GHC.TypeLits.Nat types no longer fully simplified. -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: TypeLits Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I think the behavior of when to expand/simplify type families may have changed intentionally in 7.10, but simplifying the type only as far as `Num a => Vec (2 + 1) a` certainly looks weird. I also note that the behavior is different if the value is first bound to a variable: {{{ *Main> let x = (3:>4:>5:>Nil) *Main> :t x x :: Num a => Vec 3 a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 18 17:12:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Apr 2015 17:12:35 -0000 Subject: [GHC] #7478: setSessionDynFlags does not always work In-Reply-To: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> References: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> Message-ID: <059.ce73ad406dc25bb046799646d6f5ded6@haskell.org> #7478: setSessionDynFlags does not always work -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: ghc- Related Tickets: | api/T7478 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bherzog): I observe the same problem as [comment:8 thoughtpolice], also on a 32 bit Linux system (debian Wheezy), but with ghc master 7b042d5adabdb0fc06286db1a7f9cbf1e9fd1fbf. I have analysed it a bit and I think I have a solution or a least a work-around. On my system, the flags returned by `getSessionDynFlags` in `T7478.hs` are inconsistent with regard to dynamic vs. static linking. The `ways` list is empty, so in particular does not contain `WayDyn`, but at the same time, `Opt_Static` is not in `generalFlags`. This state of the flags is a bit contradictory, because AFAICT, there's some code that only looks at the presence of `WayDyn` when deciding whether a static or dynamic build has been requested while some other code only looks at `Opt_Static`. A missing `WayDyn` means to link statically, whereas a missing `Opt_Static` means linking dynamically. So the code expects this to be more consistent, which is also apparent from the fact that the `updateWays` function sets/unsets `Opt_Static` depending on the absence/presence of `WayDyn`. A workaround that works for me is to extend `defaultDynFlags` so that it applies `updateWays` to the `DynFlags` value it creates. I'm not sure that's the correct solution, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 18 18:05:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Apr 2015 18:05:20 -0000 Subject: [GHC] #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X In-Reply-To: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> References: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> Message-ID: <062.8e1ad24d0ec2f8c30cd2b70e1a7b4bb3@haskell.org> #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Reid Barton ): In [changeset:"88b84063c11a48820011805a8341d95f7fcd59db/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="88b84063c11a48820011805a8341d95f7fcd59db" Test case for indirect dependencies in ghci linker (#10322) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 18 21:08:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 18 Apr 2015 21:08:10 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.92b3402a7729251cce50f36d5f649dac@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): OK, fixing this requires a bit of refactoring, but it's not clear which one is best: 1. One possibility is to fix the code in Language.Haskell.TH to check if a module is valid when it is being created. Unfortunately, this means `Module` has to be created in the `Q` monad, and currently it is not. 2. Another possibility is to check when we are converting the modules, in `cvtName`. Unfortunately, currently the `CvtM` monad is a simple error monad, and does not live in `TcM`, so I can't actually load interface files during the conversion. So doing this conversion would mean `CvtM` turns into yet another `TcRnM` alias, and I'm less than keen to monadify code just for this one use case. 3. Finally, we can add a final "lint" pass on the generated code which, among other things, makes sure the error messages make sense. Since this is done at the splice site, we still have the location information of the splice available. 4. Augment generated TC splices with splice location, so if we run into an error in spliced code, we properly report where the splice was generated from. Maybe we should just do this anyway? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 04:11:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 04:11:55 -0000 Subject: [GHC] #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X In-Reply-To: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> References: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> Message-ID: <062.fa894532869c3eac6e4e1eb5fd4cc180@haskell.org> #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D852 -------------------------------------+------------------------------------- Changes (by rwbarton): * differential: => Phab:D852 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 05:40:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 05:40:51 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.80b3e853655b744f4aef5f386fc38ab8@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by rwbarton): Interesting results. This seems to confirm that the issue is whether stdout is a tty. When stdout is redirected to a file (and thus not a tty), the stdout Handle will have BlockBuffering (see `GHC.IO.Handle.Internals.getCharBuffer`). Perhaps the output is being written to that buffer, but never flushed. (Whereas when stdout is a tty, the stdout Handle has LineBuffering so the output is flushed immediately.) `ghc-pkg --version` calls `exitWith ExitSuccess`, so I think stdout is supposed to be flushed by `GHC.TopHandler.flushStdHandles`. I'm very suspicious of the two `ioctl` syscalls, where there is only one on x86_64. It looks as though the stdout Handle CAF (which is a `unsafePerformIO $ do { ... ; mkHandle ... }`) has been copied by the dynamic loader and the version referred to by the executable has a separate identity from the version referred to internally by libHSbase in `GHC.TopHandler.flushStdHandles`. On Linux x86_64 I see these references to the stdout Handle in ghc-pkg: {{{ rwbarton at morphism:/tmp$ objdump -DR ~/lib/ghc-7.8.4/bin/ghc-pkg | grep stdout 6407a0: R_X86_64_GLOB_DAT base_GHCziIOziHandleziFD_stdout_closure 6493a0: R_X86_64_64 base_GHCziIOziHandleziFD_stdout_closure 6495b8: R_X86_64_64 base_GHCziIOziHandleziFD_stdout_closure 649968: R_X86_64_64 base_GHCziIOziHandleziFD_stdout_closure 649ce0: R_X86_64_64 base_GHCziIOziHandleziFD_stdout_closure 649e30: R_X86_64_64 base_GHCziIOziHandleziFD_stdout_closure }}} What is the corresponding output on your ARM system? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 07:35:52 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 07:35:52 -0000 Subject: [GHC] #10260: last uses too much space with optimizations disabled In-Reply-To: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> References: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> Message-ID: <062.d4ace81fe899bd71e1c94f998771722d@haskell.org> #10260: last uses too much space with optimizations disabled -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D847 -------------------------------------+------------------------------------- Comment (by nomeata): > Maybe. But eta expansion is in general a tremendously good thing. I'd love just to try it. Looks like I forgot to cross-reference the ticket where I started working on this: #10319 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 08:06:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 08:06:45 -0000 Subject: [GHC] #10021: Add "Error:" prefix for compile-time error messages In-Reply-To: <043.cd50774548df3d55e921eb94882437a4@haskell.org> References: <043.cd50774548df3d55e921eb94882437a4@haskell.org> Message-ID: <058.c03b7f5d8eab5c236756d55d783f97c7@haskell.org> #10021: Add "Error:" prefix for compile-time error messages -------------------------------------+------------------------------------- Reporter: k-bx | Owner: k-bx Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by k-bx): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 08:41:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 08:41:20 -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.35789b5b3493a8196fbd1a0183abca33@haskell.org> #9920: Segfault in arm binary with llvm 3.5 -------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Changes (by erikd): * status: closed => new * version: 7.11 => 7.10.1 * resolution: fixed => * milestone: => 7.10.2 Comment: Re-opening this because it affects the 7.10 branch when used with upstream llvm-3.5.0 (llvm-3.5.1 works correctly). Debian Testing and Unstable currently ship upstream llvm-3.5.0 with some patches as Debian version 1:3.5-10. This Debian version is is not capable to compiling GHC code to run on Arm. A bug has been raised against Debian's llvm-3.5 as https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=782868 along with a request to roll a new version with the `arm-lower-tail-calls.patch` patch applied. I am also working on a configure time test to detect this problem in the `llc` command. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 09:34:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 09:34:39 -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.7048e7674bd1b818d5b7c9710ee6f518@haskell.org> #9920: Segfault in arm binary with llvm 3.5 -------------------------------------+--------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+--------------------------------- Changes (by erikd): * cc: erikd (added) * owner: => erikd -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 11:51:23 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 11:51:23 -0000 Subject: [GHC] #10303: Make it easier to print stack traces when debugging GHC itself In-Reply-To: <047.fb5dc8e7e9aecf901551c4f1b06d6dc4@haskell.org> References: <047.fb5dc8e7e9aecf901551c4f1b06d6dc4@haskell.org> Message-ID: <062.a5528047572b8af2cdf187d9544479d4@haskell.org> #10303: Make it easier to print stack traces when debugging GHC itself -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * cc: simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 12:14:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 12:14:29 -0000 Subject: [GHC] #10325: Clearify status of ImpredicativeTypes Extension Message-ID: <054.6d8491b4851bda6a5760a822edfce5be@haskell.org> #10325: Clearify status of ImpredicativeTypes Extension -------------------------------------+------------------------------------- Reporter: | Owner: j80JjBjVNRMajmA | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: | Operating System: Unknown/Multiple Documentation | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- There seem to be many statements about this extension and its problems floating around in the internet. But a user of GHC will first fall into a possibly large number of traps and problems before he finds them. I think it would help, if the GHC manual [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/other- type-extensions.html#impredicative-polymorphism] and the compiler warned about this extension (instead of suggesting it!). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 12:25:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 12:25:42 -0000 Subject: [GHC] #10326: ImpredicativeTypes: Unable to use in Functor etc.. Message-ID: <054.8163c02f78c4fb3c1e62c01843545e8c@haskell.org> #10326: ImpredicativeTypes: Unable to use in Functor etc.. -------------------------------------+------------------------------------- Reporter: | Owner: j80JjBjVNRMajmA | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I want to use values of RankNTypes within Functors/Monads/... just like normal values. The following code shows, that I cannot lift a function `ReturnNull -> ReturnNull` into a functor the way I would like to (e.g. `liftId2`). However, using another version that seems equivalent and that is allowed by GHC, `liftId3`, does not allow me to pipe the result to `override`. How can I do this? {{{#!hs {-# LANGUAGE ImpredicativeTypes #-} type ReturnNull = forall m. Monad m => m () id2 :: ReturnNull -> ReturnNull id2 = id testId2 :: ReturnNull testId2 = id2 $ return () liftId :: Functor f => f ReturnNull -> f ReturnNull liftId = fmap id -- rejected liftId2 :: Functor f => f ReturnNull -> f ReturnNull liftId2 = fmap id2 liftId3 :: (Monad m,Functor f) => f ReturnNull -> f (m ()) liftId3 = fmap id2 override :: Functor f => f ReturnNull -> f () override = fmap $ const () testLift :: Functor f => f ReturnNull -> f () testLift = override . liftId --rejected testLift3 :: Functor f => f ReturnNull -> f () testLift3 = override . liftId3 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 15:15:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 15:15:18 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.fd0a047fbd5e71720fd42dd205bd76ea@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: D854 -------------------------------------+------------------------------------- Changes (by bgamari): * differential: => D854 Comment: Jan, this is a good point. The work is on hold at the moment while I finish up my thesis and move to Germany but regardless I've put up the current state of the patch on Phabricator. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 16:02:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 16:02:19 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.ebe4508d507bf1e09b0441411dc080ba@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: D854 -------------------------------------+------------------------------------- Comment (by rwbarton): Did anyone ever come up with actual benchmarks that show a potential performance improvement from non-branching code? I must say I'm still rather skeptical of this whole project. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 16:11:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 16:11:29 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.2668783125a44276876ede762a7af43f@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: D854 -------------------------------------+------------------------------------- Comment (by bgamari): Replying to [comment:21 rwbarton]: > Did anyone ever come up with actual benchmarks that show a potential performance improvement from non-branching code? I must say I'm still rather skeptical of this whole project. You raise some fair points and perhaps Joachim's findings suggest that it it's not worth bending over backwards to accommodate branch-free code. Looking further into the performance implications of these branches is high on my to-do list. Regardless, there may be value in allowing rules to examine the application context even beyond this particular optimization (although at the risk of making RULEs a bit less predictable than they are currently). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 16:34:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 16:34:57 -0000 Subject: [GHC] #10124: Simple case analyses generate too many branches In-Reply-To: <046.a2efb21732640768a877c0ce17a28486@haskell.org> References: <046.a2efb21732640768a877c0ce17a28486@haskell.org> Message-ID: <061.cc62097327369cfd11a1eaf25bffccf7@haskell.org> #10124: Simple case analyses generate too many branches -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6135, | Differential Revisions: #9661,#10137 | -------------------------------------+------------------------------------- Comment (by rwbarton): That branchless assembly is certainly not the greatest though it doesn't look too terrible to me either. What happens if you use the LLVM backend? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 16:35:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 16:35:38 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.8d634a3a330e58b197ecec0a15aefb0a@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: D854 -------------------------------------+------------------------------------- Comment (by rwbarton): Sorry, my previous comment was poorly worded at best. I'm sure there are cases where the best non-branching code has better performance than the best branching code. However, I'm not at all convinced that it makes sense to try to give the user control over whether to generate branching or non- branching code. It's at odds with the notion of an optimizing compiler, and as I mentioned earlier even C compilers do not give you that kind of control once optimizations are enabled. GHC should just generate whatever it thinks is best, and if the user really needs to generate particular assembly, they can write that assembly manually. I would need to see some ''very'' dramatic numbers to change this point of view; and currently we have no numbers at all. I do think that expanding GHC's bag of tricks for post-Stg code generation (as in #10124 for example) is practical and worthwhile, though it will probably need more work in the native code generator as well for best results. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 16:54:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 16:54:42 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.216b46baffed4a03113949e17c39f427@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: D854 -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:21 rwbarton]: > Did anyone ever come up with actual benchmarks that show a potential performance improvement from non-branching code? https://ghc.haskell.org/trac/ghc/wiki/PrimBool#Benchmarks I know these numbers are not much, but they give some hope that branchless operations can improve performance. I recall that Gregory Collins saw a potential use for branchless primops in his `hastables` library. When I worked on implementing #6135 I did some measurements on hastbales but saw now improvement in performance - now I realize that this might have been because `==#` was compiled to branchy code but I didn't realize that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 17:10:54 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 17:10:54 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.9f7a94f9ee1d2ec162805eae095dda4d@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: D854 -------------------------------------+------------------------------------- Comment (by rwbarton): Again there is a distinction between the compiler being able to generate branchless code and the compiler giving the user control over whether to generate branchless code. For example in that benchmark, it would be even better if the user could simply write {{{ let inc = if v >= 0 then 1 else 0 }}} rather than {{{ let !(I# v) = x inc = I# (v >=$# 0#) }}} Any optimizing C compiler would avoid a branch in a function like {{{ int g(int a, int b) { if (a >= 0) return b + 1; else return b; } }}} So, this isn't an example of the kind that I am talking about. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 18:06:40 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 18:06:40 -0000 Subject: [GHC] #9056: --make paths are not deduplicated In-Reply-To: <054.6d9311fc6ac4a797c0df6e46e05c1bcb@haskell.org> References: <054.6d9311fc6ac4a797c0df6e46e05c1bcb@haskell.org> Message-ID: <069.3e93f48f8c4259ebacb4896de64c0d56@haskell.org> #9056: --make paths are not deduplicated -------------------------------------+------------------------------------- Reporter: evincarofautumn | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Driver | Version: 7.8.2 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I generally agree with thomie here, but I think there is some room for interpretation since ghc's make mode already is a bit "do what I mean". For example, if module A imports module B, then `ghc A.hs B.hs` does the same as `ghc A.hs`, so there seems to be some kind of deduplication happening already. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 18:14:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 18:14:00 -0000 Subject: [GHC] #10325: Clearify status of ImpredicativeTypes Extension In-Reply-To: <054.6d8491b4851bda6a5760a822edfce5be@haskell.org> References: <054.6d8491b4851bda6a5760a822edfce5be@haskell.org> Message-ID: <069.3997345e54571dcf190e78f702528cfd@haskell.org> #10325: Clearify status of ImpredicativeTypes Extension -------------------------------------+------------------------------------- Reporter: j80JjBjVNRMajmA | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9618, #10281 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by rwbarton): * related: => #9618, #10281 Comment: I agree with j80JjBjVNRMajmA, and see also #9618. Meanwhile #10281 is in part about expanding the documentation of ImpredicativeTypes slightly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 18:25:11 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 18:25:11 -0000 Subject: [GHC] #10160: GHCi :sprint has odd/unhelpful behavior for values defined within the REPL In-Reply-To: <048.55a9661044b934d281580d4eba633a8a@haskell.org> References: <048.55a9661044b934d281580d4eba633a8a@haskell.org> Message-ID: <063.38a549b72e672652a63b176e0a334d36@haskell.org> #10160: GHCi :sprint has odd/unhelpful behavior for values defined within the REPL -------------------------------------+------------------------------------- Reporter: bitemyapp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: | Keywords: :sprint Operating System: Unknown/Multiple | thunk evaluation non-strictness Type of failure: Incorrect result | laziness runtime ghci repl at runtime | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): How about adding a sentence like this to the documentation of `:print`: > Note that literals and data constructor applications may appear as values rather than thunks even if nothing has yet forced their evaluation, since GHCi constructs these values directly in weak head normal form. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 19:55:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 19:55:01 -0000 Subject: [GHC] #7695: Hang when locale-archive and gconv-modules are not there In-Reply-To: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> References: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> Message-ID: <057.0a80fd41b11d73dcb468c2d81a3a3001@haskell.org> #7695: Hang when locale-archive and gconv-modules are not there -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: None | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8977 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * priority: normal => highest * milestone: 7.12.1 => 7.10.2 Comment: Let's get this one fixed, Michael Snoyman recently ran into an issue that sounds like the same thing when working with Docker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 20:26:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 20:26:24 -0000 Subject: [GHC] #7695: Hang when locale-archive and gconv-modules are not there In-Reply-To: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> References: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> Message-ID: <057.7172edcd81d025786db64a8cff555cd4@haskell.org> #7695: Hang when locale-archive and gconv-modules are not there -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: None | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8977 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Oh, do you mean #10298? Indeed it looks the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 20:40:02 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 20:40:02 -0000 Subject: [GHC] #7430: GHC API reports CPP errors in confusing ways In-Reply-To: <054.b42c4bcfb151eb512103f6c292b13b85@haskell.org> References: <054.b42c4bcfb151eb512103f6c292b13b85@haskell.org> Message-ID: <069.23333917b524f0e2fc0f9867dd6369d7@haskell.org> #7430: GHC API reports CPP errors in confusing ways -------------------------------------+------------------------------------- Reporter: MikolajKonarski | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: GHC API | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Should be possible to construct a small example? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 20:40:47 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 20:40:47 -0000 Subject: [GHC] #10209: parser: opt_kind_sig has incorrect SrcSpan In-Reply-To: <044.4df35a96b087f820c01c3c57f4238bf6@haskell.org> References: <044.4df35a96b087f820c01c3c57f4238bf6@haskell.org> Message-ID: <059.fb61a7bf566c4835536d4414b75fcc41@haskell.org> #10209: parser: opt_kind_sig has incorrect SrcSpan -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: fixed | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D813 -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 20:41:50 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 20:41:50 -0000 Subject: [GHC] #10255: API Annotations : ExprWithTySig processing discards annotated spans In-Reply-To: <044.3995d3b4b19bd7e56b8289f8de527db1@haskell.org> References: <044.3995d3b4b19bd7e56b8289f8de527db1@haskell.org> Message-ID: <059.ab26017a8ad5aaacb7e7dfb55fd8df57@haskell.org> #10255: API Annotations : ExprWithTySig processing discards annotated spans -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: fixed | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D823 -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => closed * resolution: => fixed Comment: Thank you for submitting useful patches fixing subtle mistakes that were made in location handling code! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 21:29:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 21:29:44 -0000 Subject: [GHC] #2041: Allow splicing in concrete syntax In-Reply-To: <044.42309534ba1bde34757106bdf2d7d6ae@haskell.org> References: <044.42309534ba1bde34757106bdf2d7d6ae@haskell.org> Message-ID: <059.2a9a83e2713f4de71880c4f081740e6a@haskell.org> #2041: Allow splicing in concrete syntax -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): The feature as stated here is rather conservatively stated, but in a more generalized form it could greatly improve the usability of Template Haskell. Basically, you are asking for proper quote/antiquote (antiquotes are nested splices.) There's a few ways this could be implemented: 1. (Original String) As this ticket suggests, a new constructor is defined which contains bits of concrete syntax. When, converting from the TH representation to GHC representation, the GHC parser is invoked to convert syntax into concrete representation. 2. (Monadic String) Alternately, some new methods could be added to the Quasi monad, which is the "hook" interface that allows template-haskell to call into GHC's code. These methods would like in the Q monad. This has the benefit of letting us error out early if syntax is not well-formed. 3. (ghc-api) We could make splices accept proper `ghc` AST returns, in which case we skip the TH conversion pass. In this case, a user could just directly call out to the ghc-api to parse syntax, and then that could be inserted into the TH splcie. 4. (Parser) Introduce a new syntactic form for quotation (something like quasi-quote syntax? quasi-quote with a special sigil?); contents of the quotation are parsed by the parser. Some tricky stuff happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 21:35:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 21:35:06 -0000 Subject: [GHC] #4372: Accept expressions in left-hand side of quasiquotations (was: Extending quasiquotation support) In-Reply-To: <046.070081740d53fd2b18d950319658559f@haskell.org> References: <046.070081740d53fd2b18d950319658559f@haskell.org> Message-ID: <061.8aad90af8c7a607a324f78dc74b1cb15@haskell.org> #4372: Accept expressions in left-hand side of quasiquotations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Renamed to something more descriptive. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 22:10:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 22:10:46 -0000 Subject: [GHC] #2041: Allow splicing in concrete syntax In-Reply-To: <044.42309534ba1bde34757106bdf2d7d6ae@haskell.org> References: <044.42309534ba1bde34757106bdf2d7d6ae@haskell.org> Message-ID: <059.3ab2a65a671481518d99ea2d7361ce7a@haskell.org> #2041: Allow splicing in concrete syntax -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): This ticket was discussed here: https://ghc.haskell.org/trac/ghc/blog/Template%20Haskell%20Proposal#PartD:quasiquotation -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 22:17:33 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 22:17:33 -0000 Subject: [GHC] #6089: Allow declaration splices inside declaration brackets In-Reply-To: <044.85bbefd435d2792cc792b502a5ebe47e@haskell.org> References: <044.85bbefd435d2792cc792b502a5ebe47e@haskell.org> Message-ID: <059.9a171230004f5c280d9acd8554ada65f@haskell.org> #6089: Allow declaration splices inside declaration brackets -------------------------------------+------------------------------------- Reporter: igloo | Owner: simonpj Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Template Haskell | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): The renamer splices and then typechecks now, so we should be able to do this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 23:50:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 23:50:00 -0000 Subject: [GHC] #10326: ImpredicativeTypes: Unable to use in Functor etc.. In-Reply-To: <054.8163c02f78c4fb3c1e62c01843545e8c@haskell.org> References: <054.8163c02f78c4fb3c1e62c01843545e8c@haskell.org> Message-ID: <069.b835836763da1e796aec8132efb1257b@haskell.org> #10326: ImpredicativeTypes: Unable to use in Functor etc.. -------------------------------------+------------------------------------- Reporter: j80JjBjVNRMajmA | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => wontfix Comment: `ImpredicativeTypes` is thoroughly broken and is unsupported. In the past, this extension was more properly implemented, but caused more grief than help even then. If you want this kind of thing, use a `newtype` instead of a `type`. It's surely more annoying, but it's better to have an annoying option instead of a totally-broken one. There are a number of Very Clever People working on integrating impredicativity with GHC-style type inference. (I'm not one of them, however.) In GHC's view, there has not yet been the right solution. We all look forward to when the right solution is found! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 19 23:54:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 19 Apr 2015 23:54:49 -0000 Subject: [GHC] #10298: Infinite loop when shared libraries are unavailable In-Reply-To: <047.ac4f2671f8ae23d583742150fb22d7b0@haskell.org> References: <047.ac4f2671f8ae23d583742150fb22d7b0@haskell.org> Message-ID: <062.66fb9cb3e1c447643fe6f23a5d90e7d3@haskell.org> #10298: Infinite loop when shared libraries are unavailable -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Actually there are more hidden traps. The `IOError` that is raised from the failure of `iconv_open` is produced by `errnoToIOError`, which is defined as {{{ errnoToIOError loc errno maybeHdl maybeName = unsafePerformIO $ do str <- strerror errno >>= peekCString return (IOError maybeHdl errType loc str (Just errno') maybeName) where -- ... }}} This means that matching on the `IOError` constructor will recursively raise another exception, since `peekCString` uses the user's locale. In `GHC.TopHandler`, `real_handler` matches on the `IOError` constructor to decide how to exit. So a possible fix is {{{ diff --git a/libraries/base/GHC/TopHandler.hs b/libraries/base/GHC/TopHandler.hs index d7c0038..5d4094a 100644 --- a/libraries/base/GHC/TopHandler.hs +++ b/libraries/base/GHC/TopHandler.hs @@ -157,14 +157,25 @@ real_handler exit se = do Just (ExitFailure n) -> exit n -- EPIPE errors received for stdout are ignored (#2699) - _ -> case fromException se of + _ -> catch (case fromException se of Just IOError{ ioe_type = ResourceVanished, ioe_errno = Just ioe, ioe_handle = Just hdl } | Errno ioe == ePIPE, hdl == stdout -> exit 0 _ -> do reportError se exit 1 - + ) (disasterHandler exit) + +-- don't use errorBelch() directly, because we cannot call varargs functions +-- using the FFI. +foreign import ccall unsafe "HsBase.h errorBelch2" + errorBelch :: CString -> CString -> IO () + +disasterHandler :: (Int -> IO a) -> IOError -> IO a +disasterHandler exit _ = + withCAString "%s" $ \fmt -> + withCAString "encountered an exception while trying to report an exception" $ \msg -> + errorBelch fmt msg >> exit 1 -- try to flush stdout/stderr, but don't worry if we fail -- (these handles might have errors, and we don't want to go into }}} though it feels a bit artificial. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 00:51:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 00:51:57 -0000 Subject: [GHC] #10327: Devise workaround for how infinite types prevent closed type family reduction Message-ID: <047.447eab1371483fe9f60b21fe4d71b714@haskell.org> #10327: Devise workaround for how infinite types prevent closed type family reduction -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Suppose we have {{{ data a :+: b type family Inj x y where Inj a a = True Inj b (b :+: c) = False }}} When we try to reduce `Inj f (f :+: g)`, it looks like we should just use the second equation. Instead, we fail to reduce. This is because GHC is worried about the possibility of the first equation firing, in the event that `f ~ (f :+: g)`. This fact can happen only if `f` is infinitely large. On the surface, this seems impossible, but shenanigans in this area can cause `unsafeCoerce`. See #8162. I don't see an easy way to fix this, but the fact that GHC can't cope (well) with this example tells me something is wrong. Here is one idea of how to proceed: If we somehow ensure at reduction time that `f` is finite, we're OK. If we need finiteness in terms, we use `deepseq`. Can we do this in types? I tentatively say "yes". Imagine the following type family: {{{ type family Seq (x :: a) (y :: b) :: b type instance Seq True y = y type instance Seq False y = y }}} To reduce, say, {{{b `Seq` 5}}}, we'd need to know concretely what `b` is. We can then build `Deepseq` similarly to how `deepseq` at the term level works. The closed type family mechanism could then detect cases like `Inj`, where the whole infinite-type thing is causing trouble. (I conjecture that detecting this is not hard, as there's a specific line in the `Unify` module that triggers in the worry-about-infinite-types case.) In the case of `Inj`, something like `Inj f (f :+: g)` would reduce to {{{f `Deepseq` False}}}. Note that the call to `Seq` wouldn't be written in the closed type family definition, but would be inserted during reduction as appropriate. This solution is ugly. And it requires magic to define `Seq` in types (we need an instance for every type!) and weird magic in closed type family reduction. The definition of `Deepseq` might also benefit from being magical. It would be annoying to explain to users, but no more so than the current crazy story. In general, I don't like this idea much, but I do think it would work. In any case, this ticket is mainly to serve as a placeholder for any future thoughts in this direction. It's quite annoying to have the specter of infinite types cripple otherwise-sensible closed type families. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 01:08:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 01:08:22 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.8ec1acd6b321bdc40f89e032f45d1bc0@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by erikd): On my Aarch64 system, for `ghc-pkg` from the Debian version of ghc-7.6.4 I get: {{{ $ objdump -DR /usr/lib/ghc/lib/ghc-pkg | grep stdout 0000000001035d20 : 1035d20: R_AARCH64_COPY stdout }}} where as for the newly compiled but broken 7.10 version I get: {{{ $ objdump -DR /home/erikd/GHC/7.10/lib/ghc-7.10.1.20150414/bin/ghc-pkg | grep stdout 47bd60: R_AARCH64_GLOB_DAT base_GHCziIOziHandleziFD_stdout_closure 000000000049a2e8 : 49a2e8: R_AARCH64_COPY base_GHCziIOziHandleziFD_stdout_closure }}} GHC 7.6.3 and 7.10 are different and so are Amd64 vs AArch64. It could well be a linker bug. The big difference between 7.6 and 7.10 is `DYNAMIC_GHC_PROGRAMS` is `YES` and as @juhp points out, this works when `DYNAMIC_GHC_PROGRAMS` is switched off. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 01:27:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 01:27:49 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.3669a6aa91ab617addbf6b8ccd8a793c@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by rwbarton): * cc: bgamari (added) Comment: Replying to [comment:16 erikd]: > {{{ > 000000000049a2e8 : > 49a2e8: R_AARCH64_COPY base_GHCziIOziHandleziFD_stdout_closure > }}} I'm not very familiar with dynamic linking on ARM but isn't this wrong? `base_GHCziIOziHandleziFD_stdout_closure` needs to point to the same address in the executable and in the shared library since it is a closure that will get overwritten with a new Handle object the first time it is entered. bgamari, you know about these ARM relocation types right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 02:22:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 02:22:07 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.bec3581095310b1ccf244d5b2958dac6@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by erikd): Using the test program from comment 6 and a basic "Hello world" program, I can reproduce this problem by compiling the "Hello world" program with `-O2 -dynamic` and running it with the above test program runner. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 02:25:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 02:25:41 -0000 Subject: [GHC] #10328: Control.Monad exports lead to weird Haddocks Message-ID: <045.44a1bb94a3277e92b37fe4a986cde3c0@haskell.org> #10328: Control.Monad exports lead to weird Haddocks -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Core | Operating System: Unknown/Multiple Libraries | Type of failure: Documentation Keywords: | bug Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- `Control.Monad` exports, and therefore documents, the `Functor` class (but only the `fmap` member) and the `Monad` class. It does not export, and therefore does not document, the `Applicative` class. This is all pretty weird. Since `Functor` is in the prelude (and probably most/all alternate preludes), is there actually a reason to export it from `Control.Monad`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 02:26:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 02:26:02 -0000 Subject: [GHC] #10328: Control.Monad exports lead to weird Haddocks In-Reply-To: <045.44a1bb94a3277e92b37fe4a986cde3c0@haskell.org> References: <045.44a1bb94a3277e92b37fe4a986cde3c0@haskell.org> Message-ID: <060.a7bd45bc2dd74ceab70f4a7eebd9fb33@haskell.org> #10328: Control.Monad exports lead to weird Haddocks -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 Revisions: -------------------------------------+------------------------------------- Changes (by dfeuer): * type: feature request => bug -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 02:34:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 02:34:14 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.7aa5320a3032fd491502046e5c91c6f6@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by erikd): Simple test program compiled with the stage2 compiler (with `-O2 -dyanmic`): {{{ import System.Environment import System.IO main :: IO () main = do args <- getArgs putStrLn "GHC package manager version 1.2.3" if null args then return () else hFlush stdout }}} Running as `./testprog > a.txt ; cat a.txt` produces the expected and correct output whereas `./testprog X > a.txt ; cat a.txt` produces nothing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 02:43:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 02:43:32 -0000 Subject: [GHC] #10329: ghc-7.10 is configured to use llvm-3.6 but only compiles with llvm-3.5 Message-ID: <044.7bb160d7a31f6091fc12e2d6f3a346bc@haskell.org> #10329: ghc-7.10 is configured to use llvm-3.6 but only compiles with llvm-3.5 -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Commit 07da52ce2db1 on the ghc-7.10 branch cherry picks commit 42448e3757f2 from the git master branch, but that commit checks for and insists on using llvm version 3.6. However, the code in the ghc-7.10 branch is not compatible with llvm-3.6. The attatched patch changes the requirement to be for llvm-3.5 and is the ghc-7.10 version of commit 485dba86d2519c in the master branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 02:44:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 02:44:53 -0000 Subject: [GHC] #10329: ghc-7.10 is configured to use llvm-3.6 but only compiles with llvm-3.5 In-Reply-To: <044.7bb160d7a31f6091fc12e2d6f3a346bc@haskell.org> References: <044.7bb160d7a31f6091fc12e2d6f3a346bc@haskell.org> Message-ID: <059.d6303730adedfe2fa52e3292335347a2@haskell.org> #10329: ghc-7.10 is configured to use llvm-3.6 but only compiles with llvm-3.5 -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by erikd): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 02:58:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 02:58:47 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.65a16bce87229d46ef2453374986c9b1@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by rwbarton): It seems that the R_AARCH64_COPY relocation is not necessarily wrong; either the executable can go through a GOT to access a symbol with fixed offset from the dynamic library, or the dynamic library can go through a GOT to access a symbol with fixed offset from the executable which has been copied from the dynamic library with a copy relocation. Definitely worth checking that the linker took care of this properly though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 03:19:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 03:19:48 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.ee9798ed31fd914294b9c4ffcef28fd5@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by bgamari): Erikd, are you using gold? There is a bug in the arm bfd LD wherein the linker will use a `COPY` relocation where we wouldn't expect it. As you suggest chaos ensues as the object's info table is not preserved by the linker when the symbol definition is copied. This is one of the reasons why we require gold on arm. I'll try to pit together a more complete reply in the morning. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 05:24:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 05:24:12 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.0e488672e680f1c9733d7ffbe76480a8@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by juhpetersen): Replying to [comment:15 rwbarton]: Thanks for the analysis and comments. > On Linux x86_64 I see these references to the stdout Handle in ghc-pkg: : > What is the corresponding output on your ARM system? For the static 7.8.4 build (ie with DYNAMIC_GHC_PROGRAMS=NO) I get: {{{ $ objdump -DR /usr/lib64/ghc-7.8.4/bin/ghc-pkg | grep stdout 00000000013290b0 : 13290b0: R_AARCH64_COPY stdout }}} Whereas the dynamic builds for 7.8.4 and 7.10.1 give: {{{ $ objdump -DR /home/petersen/rpmbuild/BUILDROOT/ghc-7.8.4-42.2.fc22.aarch64/usr/lib64/ghc-7.8.4/bin /ghc-pkg | grep stdout 470af8: R_AARCH64_GLOB_DAT base_GHCziIOziHandleziFD_stdout_closure 000000000048b908 : 48b908: R_AARCH64_COPY base_GHCziIOziHandleziFD_stdout_closure }}} I think this 7.8.4 build was with ld.gold but it didn't seem to help. It would be good if someone else could also confirm that. If it should help I can regenerate the diffs with real addresses. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 05:29:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 05:29:55 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.87be2ebe4b811b2de87434fd53bd3cd4@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by juhpetersen): Replying to [comment:18 erikd]: > Using the test program from comment 6 and a basic "Hello world" program, I can reproduce this problem by compiling the "Hello world" program with `-O2 -dynamic` and running it with the above test program runner. I can reproduce with dynamic helloworld too with -O1 and above: {{{ $ cat > test.hs main = putStrLn "hi" $ rm -f test.o test.hi; ghc -dynamic -O1 test.hs ; echo $(./test) [1 of 1] Compiling Main ( test.hs, test.o ) Linking test ... $ }}} It doesn't happen with -O0. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 06:13:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 06:13:16 -0000 Subject: [GHC] #9661: Branchless ==# is compiled to branchy code In-Reply-To: <045.71f979b880084609920e19d23d40fbfe@haskell.org> References: <045.71f979b880084609920e19d23d40fbfe@haskell.org> Message-ID: <060.4fcd944cecf50d796f322f681db77e67@haskell.org> #9661: Branchless ==# is compiled to branchy code -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: D854 -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:25 rwbarton]: > Again there is a distinction between the compiler being able to generate branchless code and the compiler giving the user control over whether to generate branchless code. For example in that benchmark, it would be even better if the user could simply write > > {{{ > let inc = if v >= 0 then 1 else 0 > }}} > > rather than > > {{{ > let !(I# v) = x > inc = I# (v >=$# 0#) > }}} I wholeheartedly agree - it would be better if the compiler could generate optimized branchless code from higher level abstract code. That said, we expose low-level primops and it would be a real shame if the users couldn't get branchless behaviour from them. Besides, if we want GHC to optimize high-level code to branchless code then I suspect it will be much easier to implement if primops compiled to branchless code. > So, this isn't an example of the kind that I am talking about. I don't follow. Why not? Surely, this is an ugly piece of code written by hand but at the moment GHC can't produce such code from high-level code - it had to be written by hand. So, I don't claim that compiling `==#` to branchless code is the final word on this topic. It's just fixing a bug that I didn't notice when originally implementing #6135 - `>=#`, `>#`, `<=#` and `<#` already compile to branchless code as they were intended to. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 06:31:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 06:31:36 -0000 Subject: [GHC] #10328: Control.Monad exports lead to weird Haddocks In-Reply-To: <045.44a1bb94a3277e92b37fe4a986cde3c0@haskell.org> References: <045.44a1bb94a3277e92b37fe4a986cde3c0@haskell.org> Message-ID: <060.e6f1802138c1642c26389deec3361944@haskell.org> #10328: Control.Monad exports lead to weird Haddocks -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 Revisions: -------------------------------------+------------------------------------- Comment (by hvr): For one, it's demanded by H2010 (see https://www.haskell.org/onlinereport/haskell2010/haskellch13.html). The question is rather, why H2010 doesn't have any `Data.Functor` module (which I guess is related to the fact that it ended up in `Control.Monad`...) Btw, this could be yet another use-case for #4879 (if we decide to slowly phase out the re-export from Control.Monad) :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 07:38:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 07:38:44 -0000 Subject: [GHC] #8403: Pretty-printing of long types In-Reply-To: <047.792ac96369079bc46b579fe906221406@haskell.org> References: <047.792ac96369079bc46b579fe906221406@haskell.org> Message-ID: <062.0029c468d0b071e7c7a2f69b765d9b7f@haskell.org> #8403: Pretty-printing of long types -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9428 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by phadej): With the test program: {{{ import Text.PrettyPrint -- mocking how compiler/types/TypeRep.hs would print the type pairUntil :: Char -> Doc pairUntil c = pprArrowChain (varDocs ++ [resultPair]) where varDocs = map char ['a'..c] resultPair = parens (sep (punctuate comma varDocs)) arrow :: Doc arrow = text "->" pprArrowChain :: [Doc] -> Doc -- pprArrowChain [a,b,c] generates a -> b -> c pprArrowChain [] = empty pprArrowChain (arg:args) = sep [arg, sep (map (arrow <+>) args)] }}} {{{ ?> Test.pairUntil 'd' a -> b -> c -> d -> (a, b, c, d) ?> Test.pairUntil 'k' a -> b -> c -> d -> e -> f -> g -> h -> i -> j -> k -> (a, b, c, d, e, f, g, h, i, j, k) }}} I have no good ideas how to define "more packed", yet so output is still understandable. E.g. will this "less area" method work for all types: {{{ a -> b -> c -> d -> e -> f -> g -> h -> i -> j -> k -> l -> m -> n -> o -> p -> q -> r -> s -> t -> u -> v -> w -> x -> (a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p, q, r, s, t, u, v, w, x) }}} My gut feelings that the layout algorithm won't be linear anymore, don't know if that is the problem though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 07:59:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 07:59:07 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.883aa718d50e384c05d9466338cbb18d@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by juhpetersen): (Naively statically linking Setup.hs does not seem to help though (cf comment 8).) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 08:48:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 08:48:47 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.071cd1394d09de542829469755eb3d1b@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by erikd): @bgamari This is not Arm, this is AArch64/Arm64. I seem to remember that @juhp tried the gold linker on AArch64, but ran into other problems. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 09:37:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 09:37:02 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.6c9cf6912594c9086e21ba601389aaee@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by juhpetersen): Replying to [comment:25 erikd]: > I seem to remember that @juhp tried the gold linker on AArch64, but ran into other problems. Well I tried build 7.8.4 with ld.gold but it didn't seem to make a difference for me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 12:54:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 12:54:19 -0000 Subject: [GHC] #10124: Simple case analyses generate too many branches In-Reply-To: <046.a2efb21732640768a877c0ce17a28486@haskell.org> References: <046.a2efb21732640768a877c0ce17a28486@haskell.org> Message-ID: <061.70d92d10f1b9b82ac805015846a70c2c@haskell.org> #10124: Simple case analyses generate too many branches -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6135, | Differential Revisions: #9661,#10137 | -------------------------------------+------------------------------------- Comment (by nomeata): > It might be a different matter with concat (replicate 100000000 ['\001'..'z']). Eh, that?s of course the code I intended, thanks for noticing! ... unfortunately, not even that code gets faster: {{{ $ python -m timeit -s 'import os' 'os.system("./IsSpace-before")' 10 loops, best of 3: 4.9 sec per loop $ python -m timeit -s 'import os' 'os.system("./IsSpace-after")' 10 loops, best of 3: 4.9 sec per loop }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 13:09:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 13:09:59 -0000 Subject: [GHC] #10315: ApiAnnotations : Empty context loses annotations In-Reply-To: <044.a3ae6affd9ae60617b8ad158a443dbf2@haskell.org> References: <044.a3ae6affd9ae60617b8ad158a443dbf2@haskell.org> Message-ID: <059.0bea5de9703bccd330ad38baa274d08b@haskell.org> #10315: ApiAnnotations : Empty context loses annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:855 -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:855 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 13:34:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 13:34:20 -0000 Subject: [GHC] #10330: Better Template Haskell error message locations Message-ID: <046.b93f0aedf54fe46703caa64d72521f0f@haskell.org> #10330: Better Template Haskell error message locations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.1 Haskell | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider this TH splice {{{ f x = $( [| let g x = (True && 'x', x) in g True |] ) }}} or more generally {{{ f x = $( g [| x |]) }}} Two problems 1. If there is a type error in the spliced-in code, there is no record of the splice in the error message: {{{ TH.hs:5:10: Couldn't match expected type ?Bool? with actual type ?Char? In the second argument of ?(&&)?, namely ?'x'? In the expression: (True && 'x') In the expression: ((True && 'x'), x_a2qf) }}} I'd like to see {{{ TH.hs:5:10: Couldn't match expected type ?Bool? with actual type ?Char? In the second argument of ?(&&)?, namely ?'x'? In the expression: (True && 'x') In the splice: $( [| let g x = ... in g True |] ) <------- NB }}} 2. (Less important, and harder to fix.) The error location (column 10) is that of the splice (column 10), not where the reported error really is (column 31). Fixing this would mean round-tripping source location info through TH syntax. Moreover, since the constructed code may be combined from quoted snippets spread over some TH libraries, it's far from clear that the location info would help. Thoughts about fixing (1). This can only arise for untyped splices. (For typed splices we can't get type errors in spliced code.) So the renamer should produce a syntax tree with a variant of `HsPar` saying "here is where I spliced in an expression". Same think for patterns and types; for declarations it would be a bit more fiddly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 13:37:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 13:37:31 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.310c892fee4b5acb2b34df2566f476c6@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Te basic problem here, which also happened in #, is that `"haskell-src- exts-1.16.0.1"` is not the '''key''' of any package; it's the '''name/version''' of the package. Reminder * The name/version of a package is something like `haskell-src- exts-1.16.0.1`. It represents the source code of a particular released package. * The key of a package is something like `haske_7Ftlz85Zj6I3uisdzq1Sbd`; it represents a compiled instance of the package. Global names (built with `NameG`) contain package keys. Edward Y and I talked. Here's our proposal. 1. Add a new function {{{ reifyPackage :: String -- Package name -> String -- Version -> Q [Package] }}} which, given a package name/version returns all the installed packages with that name and version. The auxiliary types are {{{ data Package = Pkg PkgKey -- Abstract; may grow more fields newtype PkgKey = PkgKey String -- Abstract; packageKey :: Package -> PkgKey -- Accessor packageKey (Pkg p) = p mkPackageKey :: String -> PkgKey mkPackageKey = PkgKey -- Use with caution; these strings are not easy to come up with -- eg "haske_7Ftlz85Zj6I3uisdzq1Sbd" }}} 2. Improve the error message when splicing code that mentions a bad `PkgKey` in a `NameG`, as in comment:8 Notes * A TH `NameG` currently contains a `PkgName`, defined thus: {{{ newtype PkgName = PkgName String -- package name }}} This is badly misleading; we propose to rename it to `PkgKey`, defined above. You can get a `PkgKey` from `reifyPackage` plus `packageKey`; or in some other out-of-band-way plus `mkPkgKey`. * `reifyPackage` returns a list of `Packages`. There can be more than one if the sane package name/version is installed wrt different dependencies; but this is atypical. At some point we may need to support bigger API for `Package`, which lets you get its dependencies. See also #10330. None of this is for 7.10; it's a proposal for 7.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 13:42:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 13:42:42 -0000 Subject: [GHC] #10314: ApiAnnotations: mkHsForAllTy discards parens In-Reply-To: <044.18ffc9f2fee6881fa8a916d0ec16833c@haskell.org> References: <044.18ffc9f2fee6881fa8a916d0ec16833c@haskell.org> Message-ID: <059.34534631dd1838cf7bbbe987953d1c94@haskell.org> #10314: ApiAnnotations: mkHsForAllTy discards parens -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by alanz): The `mkHsForAllTy` case is safe, as `ignoreParens` is only used in the conditional part. But, {{{#!hs mk_forall_ty exp tvs (L _ (HsParTy ty)) = mk_forall_ty exp tvs ty }}} does strip parens. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 13:43:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 13:43:26 -0000 Subject: [GHC] #10315: ApiAnnotations : Empty context loses annotations In-Reply-To: <044.a3ae6affd9ae60617b8ad158a443dbf2@haskell.org> References: <044.a3ae6affd9ae60617b8ad158a443dbf2@haskell.org> Message-ID: <059.03155894e73a9277701efe536cbd6f1e@haskell.org> #10315: ApiAnnotations : Empty context loses annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:855 -------------------------------------+------------------------------------- Changes (by alanz): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 13:54:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 13:54:43 -0000 Subject: [GHC] #10330: Better Template Haskell error message locations In-Reply-To: <046.b93f0aedf54fe46703caa64d72521f0f@haskell.org> References: <046.b93f0aedf54fe46703caa64d72521f0f@haskell.org> Message-ID: <061.a21644da5ab5b9d1326f80e4d956dd09@haskell.org> #10330: Better Template Haskell error message locations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): In my opinion, (2) above is more important than (1). The `singletons` package encourages wrapping up lots of code in one big splice and quote. (`$(singletons [d| data Foo = ... ; bar :: ...; bar = ...; ... |])`) Because of the bug reported here, users get no location information attached to often-baroque errors. Agreed that (2) is quite a bit harder to fix than (1), though. (2) would seem to require a full overhaul of the TH AST and would break many clients of TH. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 14:22:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 14:22:24 -0000 Subject: [GHC] #10304: Bump Cabal submodule In-Reply-To: <044.a4b102a135e23cf08c42735959b0946a@haskell.org> References: <044.a4b102a135e23cf08c42735959b0946a@haskell.org> Message-ID: <059.400cb3f4f9b38ad31a4304ab0916ec8e@haskell.org> #10304: Bump Cabal submodule -------------------------------------+------------------------------------- Reporter: luite | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * owner: => hvr -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 14:44:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 14:44:36 -0000 Subject: [GHC] #10124: Simple case analyses generate too many branches In-Reply-To: <046.a2efb21732640768a877c0ce17a28486@haskell.org> References: <046.a2efb21732640768a877c0ce17a28486@haskell.org> Message-ID: <061.bc1913b2d27e367fb6cb317c44b0933a@haskell.org> #10124: Simple case analyses generate too many branches -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #6135, | Differential Revisions: #9661,#10137 | -------------------------------------+------------------------------------- Comment (by nomeata): I think these numbers might be wrong due to mistakes on my side. Now I get {{{ 1 loops, best of 10: 27.1 sec per loop 1 loops, best of 10: 41.5 sec per loop }}} so the branchless code is actually much more expensive. (This is testing `length $ filter myIsSpace $ concatMap (const ['\001'..'z']) $ [0..50000000::Int]` which produces better code than `replicate`.) Also in light of Sven Pannes?s valuable comments (https://mail.haskell.org/pipermail/ghc-devs/2015-April/008858.html) I?m inclined to abandon this idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 14:51:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 14:51:55 -0000 Subject: [GHC] #10328: Control.Monad exports lead to weird Haddocks In-Reply-To: <045.44a1bb94a3277e92b37fe4a986cde3c0@haskell.org> References: <045.44a1bb94a3277e92b37fe4a986cde3c0@haskell.org> Message-ID: <060.7b2666e542b49e52ba0623fe8f3cab14@haskell.org> #10328: Control.Monad exports lead to weird Haddocks -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): Currently it is demanded by the report and backwards compatibility. It is worth evaluating whether we can eliminate such re-exports from Control.Monad in the future, but such would require a good deal of community buy-in. I for one would support ultimately removing the redundant re-exports from Control.Monad and all over the `mtl` should such a thing be put to a poll / proposal. They were a repeated thorn in our side when we were trying to figure out if we even _could_ do something like offer alternate Preludes, etc. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 15:00:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 15:00:27 -0000 Subject: [GHC] #10304: Bump Cabal submodule In-Reply-To: <044.a4b102a135e23cf08c42735959b0946a@haskell.org> References: <044.a4b102a135e23cf08c42735959b0946a@haskell.org> Message-ID: <059.a801c1838e77f196b5f3a4746bab5d48@haskell.org> #10304: Bump Cabal submodule -------------------------------------+------------------------------------- Reporter: luite | Owner: hvr Type: task | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"4bc925a67285a71ddd14642e218d85de83bc214a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4bc925a67285a71ddd14642e218d85de83bc214a" Update Cabal submodule to 1.22.3.0 release Highlights since 1.22.2.0: - cabal check will fail on -fprof-auto passed as a ghc-option - filterConfigureFlags: filter more flags. - fix ghcjs-pkg version number handling Addresses #10304 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 15:03:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 15:03:21 -0000 Subject: [GHC] #10327: Devise workaround for how infinite types prevent closed type family reduction In-Reply-To: <047.447eab1371483fe9f60b21fe4d71b714@haskell.org> References: <047.447eab1371483fe9f60b21fe4d71b714@haskell.org> Message-ID: <062.8a9c559ae2bb38582dc247d4faa29471@haskell.org> #10327: Devise workaround for how infinite types prevent closed type family reduction -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by garrett): * cc: garrett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 15:06:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 15:06:19 -0000 Subject: [GHC] #9334: Implement "instance chains" In-Reply-To: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> References: <047.4ee93c8536fe403cb27c42a096a1269b@haskell.org> Message-ID: <062.05e1a32242226de2e6af00145758bab7@haskell.org> #9334: Implement "instance chains" -------------------------------------+------------------------------------- Reporter: diatchki | Owner: diatchki Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by garrett): * cc: garrett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 15:07:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 15:07:57 -0000 Subject: [GHC] #10271: Typed Template Haskell splice difficulty when resolving overloading In-Reply-To: <046.badc08a7987a9ad09aee9fd76d6b2f30@haskell.org> References: <046.badc08a7987a9ad09aee9fd76d6b2f30@haskell.org> Message-ID: <061.f51ed6951e1c514f0eb8b070919847e5@haskell.org> #10271: Typed Template Haskell splice difficulty when resolving overloading -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by garrett): * cc: garrett (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 15:11:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 15:11:50 -0000 Subject: [GHC] #10331: Accept HsSyn in splices and generate it in quotes (ghc-api) Message-ID: <045.80e6e2d3d25618817aeece40a368c0e4@haskell.org> #10331: Accept HsSyn in splices and generate it in quotes (ghc-api) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.11 Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I propose a language pragma `GhcTemplateHaskell`, which, when enabled, causes Template Haskell splices to accept `HsSyn` return values, and causes TH quotes to return `HsSyn` trees. Users of `GhcTemplateHaskell` would stop using the `template-haskell` library and just directly manipulate the frontend ASTs using the `ghc-api`. Given our ghc-api track record, you would probably not be able to write code using this without having it break every GHC release. However, clients who are willing to track GHC development would reap the following benefits: 1. All syntax in Haskell would be supported in quotes; the AST would never lag behind. Additionally, you could use the ghc-api parser to parse Haskell code to be returned in a splice. (#2041) 2. Locations from quoting would be preserved. (Problem 2 of #10330) I don't think this would be difficult to implement, but it definitely could be a ball of wax. I broke this proposal off from #2041. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 15:12:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 15:12:37 -0000 Subject: [GHC] #10330: Better Template Haskell error message locations In-Reply-To: <046.b93f0aedf54fe46703caa64d72521f0f@haskell.org> References: <046.b93f0aedf54fe46703caa64d72521f0f@haskell.org> Message-ID: <061.0bf74c296a1f3174a98964d674b153ef@haskell.org> #10330: Better Template Haskell error message locations -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template Haskell | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): In that case, let me record one possible workaround for problem (2), which is #10331; however, this doesn't help users of the old TH API. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 15:12:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 15:12:55 -0000 Subject: [GHC] #2041: Allow splicing in concrete syntax In-Reply-To: <044.42309534ba1bde34757106bdf2d7d6ae@haskell.org> References: <044.42309534ba1bde34757106bdf2d7d6ae@haskell.org> Message-ID: <059.6541e4edcf58595916e9d51eb09d35e8@haskell.org> #2041: Allow splicing in concrete syntax -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: new Priority: normal | Milestone: ? Component: Template Haskell | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): I decided to record this alternate proposal here: #10331 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 15:14:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 15:14:45 -0000 Subject: [GHC] #9745: qual_pkg panic with template haskell In-Reply-To: <044.2b54bb6a9f621182bb355b4ed5efcb8f@haskell.org> References: <044.2b54bb6a9f621182bb355b4ed5efcb8f@haskell.org> Message-ID: <059.b771bced396538990a064466a5a09314@haskell.org> #9745: qual_pkg panic with template haskell -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * owner: ezyang => * status: closed => new * resolution: invalid => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 15:15:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 15:15:19 -0000 Subject: [GHC] #10304: Bump Cabal submodule In-Reply-To: <044.a4b102a135e23cf08c42735959b0946a@haskell.org> References: <044.a4b102a135e23cf08c42735959b0946a@haskell.org> Message-ID: <059.9af1cb8d3d7d48988346c83ea2165cae@haskell.org> #10304: Bump Cabal submodule -------------------------------------+------------------------------------- Reporter: luite | Owner: hvr Type: task | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 15:15:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 15:15:46 -0000 Subject: [GHC] #10304: Bump Cabal submodule In-Reply-To: <044.a4b102a135e23cf08c42735959b0946a@haskell.org> References: <044.a4b102a135e23cf08c42735959b0946a@haskell.org> Message-ID: <059.4dc183822d4a330ff3e94a4785899c16@haskell.org> #10304: Bump Cabal submodule -------------------------------------+------------------------------------- Reporter: luite | Owner: hvr Type: task | Status: merge Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * priority: normal => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 15:15:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 15:15:55 -0000 Subject: [GHC] #9745: qual_pkg panic with template haskell In-Reply-To: <044.2b54bb6a9f621182bb355b4ed5efcb8f@haskell.org> References: <044.2b54bb6a9f621182bb355b4ed5efcb8f@haskell.org> Message-ID: <059.1917f8cb13448d346c3745dd073cef4c@haskell.org> #9745: qual_pkg panic with template haskell -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.9 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #10279 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => closed * resolution: => duplicate * related: => #10279 Comment: We decided that there are some fixes we should do here, see #10279 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 15:50:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 15:50:15 -0000 Subject: [GHC] #7695: Hang when locale-archive and gconv-modules are not there In-Reply-To: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> References: <042.96ea14c731f7f52fd1ea0cef77ce2267@haskell.org> Message-ID: <057.2865e4754d803d2582f735da90bc69eb@haskell.org> #7695: Hang when locale-archive and gconv-modules are not there -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: None | Version: 7.8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8977 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): See other dups (beyond #10298): #8977, #8928 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 15:59:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 15:59:56 -0000 Subject: [GHC] #9929: New alias handling not compatible with LLVM 3.4 In-Reply-To: <047.16e0d585b02943379458702a5beede5a@haskell.org> References: <047.16e0d585b02943379458702a5beede5a@haskell.org> Message-ID: <062.8a150526f636b436abed6f19f262305a@haskell.org> #9929: New alias handling not compatible with LLVM 3.4 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | thoughtpolice Priority: high | Status: new Component: Compiler (LLVM) | Milestone: 7.10.2 Resolution: | Version: 7.10.1-rc1 Operating System: Linux | Keywords: Type of failure: Compile-time | Architecture: x86_64 crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: => thoughtpolice Comment: Right, I'll take care of docs and a ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 16:00:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 16:00:08 -0000 Subject: [GHC] #10302: 7.10.1 documenation is incorrect wrt supported llvm version In-Reply-To: <045.3792f024358b600138037f334f93feb4@haskell.org> References: <045.3792f024358b600138037f334f93feb4@haskell.org> Message-ID: <060.278ca701d1dff74db01180d507171f8d@haskell.org> #10302: 7.10.1 documenation is incorrect wrt supported llvm version -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | thoughtpolice Priority: high | Status: new Component: Documentation | Milestone: 7.10.2 Resolution: | Version: 7.10.1 Operating System: Unknown/Multiple | Keywords: llvm Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: => thoughtpolice -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 16:04:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 16:04:28 -0000 Subject: [GHC] #10288: -flate-dmd-anal triggers "Entered absent arg" In-Reply-To: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> References: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> Message-ID: <061.698678b6a279ac1f67d698b7d208867e@haskell.org> #10288: -flate-dmd-anal triggers "Entered absent arg" -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 16:05:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 16:05:11 -0000 Subject: [GHC] #10288: -flate-dmd-anal triggers "Entered absent arg" In-Reply-To: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> References: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> Message-ID: <061.5eb75ca81351d2be2f92cfd1adb3ab60@haskell.org> #10288: -flate-dmd-anal triggers "Entered absent arg" -------------------------------------+------------------------------------- Reporter: yongqli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: infoneeded => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 16:05:19 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 16:05:19 -0000 Subject: [GHC] #10288: -flate-dmd-anal triggers "Entered absent arg" In-Reply-To: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> References: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> Message-ID: <061.1445bb9c60c9b40d11c650dd4bacb378@haskell.org> #10288: -flate-dmd-anal triggers "Entered absent arg" -------------------------------------+------------------------------------- Reporter: yongqli | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: => simonpj -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 16:11:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 16:11:38 -0000 Subject: [GHC] #10314: ApiAnnotations: mkHsForAllTy discards parens In-Reply-To: <044.18ffc9f2fee6881fa8a916d0ec16833c@haskell.org> References: <044.18ffc9f2fee6881fa8a916d0ec16833c@haskell.org> Message-ID: <059.f3a9f8d20b464a60e1d6d8e54ece74f3@haskell.org> #10314: ApiAnnotations: mkHsForAllTy discards parens -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by alanz): * status: new => closed * resolution: => invalid Comment: Nope, these cases are all handled already. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 16:11:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 16:11:44 -0000 Subject: [GHC] #10331: Accept HsSyn in splices and generate it in quotes (ghc-api) In-Reply-To: <045.80e6e2d3d25618817aeece40a368c0e4@haskell.org> References: <045.80e6e2d3d25618817aeece40a368c0e4@haskell.org> Message-ID: <060.268ad4ae3b739789b0c303335216f517@haskell.org> #10331: Accept HsSyn in splices and generate it in quotes (ghc-api) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): I propose a slightly different direction: parameterize TH over the choice of AST. Something like {{{ class ExpAST e where repExp :: LHsExpr Name -> DsM (Core (TH.Q e)) cvExp :: e -> CvtM (LHsExpr RdrName) }}} Then, we define instances `ExpAST (LHsExpr Name)` and `ExpAST TH.Exp`. Perhaps the haskell-src-exts folks can define their own instance, too, if they so choose. I haven't thought this through, so apologies if this is a terrible idea. While we're moving in this direction, it might be nice to expose `TcM` to clients of TH. I know various terrible things could be done with the power of `TcM`, but nice things can, too. (In particular, I've wanted to be able to expand closed type families from TH code. I've implemented that functionality once [in GHC], and I dearly don't want to do it again! Exposing `TcM` would allow me to start thinking about how to do this.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 16:35:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 16:35:09 -0000 Subject: [GHC] #9020: Massive blowup of code size on trivial program In-Reply-To: <046.bab0bc7fbd776024468f95f75c63d364@haskell.org> References: <046.bab0bc7fbd776024468f95f75c63d364@haskell.org> Message-ID: <061.7b00d34e705e6578ca38e23e600fac91@haskell.org> #9020: Massive blowup of code size on trivial program -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | perf/compiler/T9020 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: closed => new * resolution: fixed => Comment: Re-opening. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 16:40:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 16:40:51 -0000 Subject: [GHC] #10298: Infinite loop when shared libraries are unavailable In-Reply-To: <047.ac4f2671f8ae23d583742150fb22d7b0@haskell.org> References: <047.ac4f2671f8ae23d583742150fb22d7b0@haskell.org> Message-ID: <062.c7ab6737cc145afc4aae5d8b9ae955f2@haskell.org> #10298: Infinite loop when shared libraries are unavailable -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by trommler): * cc: trommler (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 16:45:32 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 16:45:32 -0000 Subject: [GHC] #10331: Accept HsSyn in splices and generate it in quotes (ghc-api) In-Reply-To: <045.80e6e2d3d25618817aeece40a368c0e4@haskell.org> References: <045.80e6e2d3d25618817aeece40a368c0e4@haskell.org> Message-ID: <060.bd860996191b5a5885bb8022f10fbb4c@haskell.org> #10331: Accept HsSyn in splices and generate it in quotes (ghc-api) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I'm utterly lost. To understand what is proposed here I need a lot more specifics and examples. For example * I think (though you do not say) that clients of the language extension would abandon all use of the `template-haskell` library. Instead they would depend on the `ghc` library. * I think that `[| e |]` would have type `Q (HsExpr RdrName)`. Etc etc. But it needs fleshing out or we'll all just talk at cross purposes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 20:03:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 20:03:40 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.f3392cbb3f4a77bc66104fa71621fa02@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by erikd): I just tested with the gold linker and that seems to fix it. Patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 20:22:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 20:22:34 -0000 Subject: [GHC] #8928: 64-bit statically linked binary consumes all memory while spinning on 'SIGVTALRM's In-Reply-To: <046.37d614ce33da563e3a3fd91811396fde@haskell.org> References: <046.37d614ce33da563e3a3fd91811396fde@haskell.org> Message-ID: <061.0e0b31f262b269b10ddfee185526ef9b@haskell.org> #8928: 64-bit statically linked binary consumes all memory while spinning on 'SIGVTALRM's -------------------------------------+------------------------------------- Reporter: cswarth | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: 7695,7344 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: Likely the same as #10298 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 20:30:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 20:30:17 -0000 Subject: [GHC] #10298: Infinite loop when shared libraries are unavailable In-Reply-To: <047.ac4f2671f8ae23d583742150fb22d7b0@haskell.org> References: <047.ac4f2671f8ae23d583742150fb22d7b0@haskell.org> Message-ID: <062.168bdd89028af0558379205fc62819f0@haskell.org> #10298: Infinite loop when shared libraries are unavailable -------------------------------------+------------------------------------- Reporter: snoyberg | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I suppose another approach would be to store the result of `strerror` in a new field the IOError as a ByteString, and display it using non-locale- aware IO (currently we do a round-trip through String, which should be the identity). Then put the field with the String version behind its own unsafePerformIO. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 20:45:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 20:45:09 -0000 Subject: [GHC] #10262: Improve documentation of module signatures In-Reply-To: <047.d5f9e11a25bfdcf531f13050a898429b@haskell.org> References: <047.d5f9e11a25bfdcf531f13050a898429b@haskell.org> Message-ID: <062.bce0d30ae54cccf6be4ec32a7d5d46e6@haskell.org> #10262: Improve documentation of module signatures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * owner: => ezyang -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 20:48:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 20:48:57 -0000 Subject: [GHC] #10182: lookupIfaceGlobal crash with SOURCE import In-Reply-To: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> References: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> Message-ID: <061.9221828c09be01568f386ecf2fb82fae@haskell.org> #10182: lookupIfaceGlobal crash with SOURCE import -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): (Note: it has to be a self boot-import; indirecting it through another module eliminates the error.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 21:08:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 21:08:55 -0000 Subject: [GHC] #10327: Devise workaround for how infinite types prevent closed type family reduction In-Reply-To: <047.447eab1371483fe9f60b21fe4d71b714@haskell.org> References: <047.447eab1371483fe9f60b21fe4d71b714@haskell.org> Message-ID: <062.f8463ae1cacaa6a142e084aaeecb34b9@haskell.org> #10327: Devise workaround for how infinite types prevent closed type family reduction -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I must be missing something. `Inf f (f :+: g)` will certainly reduce for any ground `f` (such as `True` or `False`) because then the call will be apart from the first equation so the second can fire. If `f` is not ground, then it'll still reduce, if `f` is anything other than `f2 :+: g`, for the same reason. If `f` is a variable then yes the reduction is stuck, but that seems fair enough. Reducing it to {{{f `Seq` rhs}}} doesn't get us any further forward (e.g. if we want to unify this with another type) but it does add real new complication. Very unconvinced. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 21:27:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 21:27:48 -0000 Subject: [GHC] #10182: lookupIfaceGlobal crash with SOURCE import In-Reply-To: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> References: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> Message-ID: <061.4619f5b7876b645d91d73a26675f1ce2@haskell.org> #10182: lookupIfaceGlobal crash with SOURCE import -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): I can reproduce with an even more minimized test-case, on a stage 2 quick build: {{{ module T8743 where class ToRow a instance ToRow () }}} {{{ module T8743 where import {-# SOURCE #-} T8743 () class ToRow a instance ToRow () where }}} With some more tracing you can get a clue: `tcIfaceGlobal` is being called because GHC is trying to report a duplicate instance error. That certainly should not happen! So in one-shot compilation, GHC is seeing an instance in its environment that is NOT supposed to be there. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 22:25:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 22:25:45 -0000 Subject: [GHC] #9020: Massive blowup of code size on trivial program In-Reply-To: <046.bab0bc7fbd776024468f95f75c63d364@haskell.org> References: <046.bab0bc7fbd776024468f95f75c63d364@haskell.org> Message-ID: <061.cb1e06da3e87367df0e76ed8c3ebdb8e@haskell.org> #9020: Massive blowup of code size on trivial program -------------------------------------+------------------------------------- Reporter: simonpj | Owner: nomeata Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | perf/compiler/T9020 | Blocking: | Differential Revisions: Phab:D851 -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => nomeata * differential: => Phab:D851 * milestone: => 7.12.1 Comment: Thanks for working on this, Joachim. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 22:29:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 22:29:18 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.7e28382febc63ef3d397e83fb963579c@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by simonpj): Under the fix of comment:96, the line {{{ g = f (Proxy :: Proxy (Eq Int => Int)) }}} would be rejected because there is no `Typeable (Eq Int => Int)`. So I think it looks fine as-is, don't you? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 23:47:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 23:47:17 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.73a5e23f3a1a537a1055205d681d9de2@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:100 simonpj]: > Under the fix of comment:96, the line > {{{ > g = f (Proxy :: Proxy (Eq Int => Int)) > }}} > would be rejected because there is no `Typeable (Eq Int => Int)`. So I think it looks fine as-is, don't you? That example wasn't using `Typeable`, it was just to demonstrate decomposing and rebuilding, which then can be used to ''circumvent'' the lack of literal `Typeable (Eq Int => Int)` (Thanks to int-e for help in testing this with HEAD): {{{ {-# LANGUAGE ImpredicativeTypes #-} {-# LANGUAGE PolyKinds #-} {-# LANGUAGE FlexibleContexts #-} module ConTyp where import Data.Typeable f :: Proxy (a b) -> Proxy a f _ = Proxy g = f (Proxy :: Proxy (Eq Int => Int)) h :: Proxy a -> Proxy (a Bool) h _ = Proxy i :: (Typeable a, Typeable b) => Proxy (a b) -> TypeRep i p = typeRep p j = i (h g) }}} Which in GHCi gives: {{{ > j Eq Int -> Bool }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 20 23:56:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 20 Apr 2015 23:56:46 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.9594d6d577f61b4f53471d289339e6e4@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by oerjan): We just realized you don't need much more than `i` there: {{{ > i (Proxy :: Proxy (Eq Int => Int)) Eq Int -> Int }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 00:59:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 00:59:47 -0000 Subject: [GHC] #10327: Devise workaround for how infinite types prevent closed type family reduction In-Reply-To: <047.447eab1371483fe9f60b21fe4d71b714@haskell.org> References: <047.447eab1371483fe9f60b21fe4d71b714@haskell.org> Message-ID: <062.d838b1509be106db6db79e32c4918225@haskell.org> #10327: Devise workaround for how infinite types prevent closed type family reduction -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:2 simonpj]: > Very unconvinced. As, rest assured, am I. I think to get this to work we would also need a constraint `Finite f` that means (via magic) that {{{f `Seq` x}}} reduces to `x`. (Without magic, this would be spelled {{{forall x. f `Seq` x ~ x}}}, but that's a higher-order constraint!) But to really get it to work, we need a totally different idea, as this one is terrible. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 02:17:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 02:17:04 -0000 Subject: [GHC] #10331: Accept HsSyn in splices and generate it in quotes (ghc-api) In-Reply-To: <045.80e6e2d3d25618817aeece40a368c0e4@haskell.org> References: <045.80e6e2d3d25618817aeece40a368c0e4@haskell.org> Message-ID: <060.e552d7aaf420a724aea6c7b98cd1eb86@haskell.org> #10331: Accept HsSyn in splices and generate it in quotes (ghc-api) -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Template Haskell | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Yes, agreed about the fleshing out... but I don't have the bandwidth to get deeply involved in this upgrade to TH at the moment. I was just offering the idea of parameterizing via classes instead of making a monolithic change. I think the `ExpAST` thing would be no more work than the monolithic change originally proposed, but would be more flexible with little cost. That said, someone who actually wants to devote time into this is quite welcome to ignore my suggestion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 03:34:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 03:34:47 -0000 Subject: [GHC] #10332: AArch64 : divbyzero test fails Message-ID: <044.44096dba01a163cc10e492eb20ba8e74@haskell.org> #10332: AArch64 : divbyzero test fails -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: aarch64 | Type of failure: Incorrect result Test Case: | at runtime testsuite/tests/rts/divbyzero.hs | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- On AArch64/Linux the test in `testsuite/tests/rts/divbyzero.hs` which is: {{{ main :: IO () main = print (5 `divInt` 0) }}} just prints "0" and exits with a zero status code. From the "ARMv8 Instriction Set Overview" document I found (wasn't able to find anything more recent): https://www.element14.com/community/servlet/JiveServlet/downloadBody/41836-102-1-229511/ARM.Reference_Manual.pdf Section 3.6 says "There is no hardware check for ?divide by zero?, but this check can be performed in the shadow of a long latency division. A divide by zero writes zero to the destination register." Looks like we need extra code to check for this, but not sure how to report it. Should probably look at what GCC and Clang do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 04:16:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 04:16:27 -0000 Subject: [GHC] #10332: AArch64 : divbyzero test fails In-Reply-To: <044.44096dba01a163cc10e492eb20ba8e74@haskell.org> References: <044.44096dba01a163cc10e492eb20ba8e74@haskell.org> Message-ID: <059.7caca467ae4ac64b35cc0dcb6c90781e@haskell.org> #10332: AArch64 : divbyzero test fails -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: aarch64 Type of failure: Incorrect result | Test Case: at runtime | testsuite/tests/rts/divbyzero.hs Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I think it's okay for `divInt` by 0 to be undefined behavior, it's an undocumented, internal function used to define `div`, which does check whether the divisor is 0. I would suggest disabling the test when the LLVM backend is in use, like in the test above it `derefnull`. In fact I think even on x86_64 Linux with LLVM it works only due to the luck that `divInt#` is too large to inline; if I call `quotInt#` directly from the test, it prints some large number instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 08:18:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 08:18:15 -0000 Subject: [GHC] #10288: -flate-dmd-anal triggers "Entered absent arg" In-Reply-To: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> References: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> Message-ID: <061.edcea36a9a17f202aa24fe6e23b4732c@haskell.org> #10288: -flate-dmd-anal triggers "Entered absent arg" -------------------------------------+------------------------------------- Reporter: yongqli | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"d5773a4939b1feea51ec0db6624c9462751e948a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d5773a4939b1feea51ec0db6624c9462751e948a" Teach DmdAnal that coercions are value arguments! The demand analyser was treating coercion args like type args, which meant that the arguments in a strictness signature got out of step with the arguments of a call. Result chaos and disaster. Trac #10288 showed it up. It's hard to get this bug to show up in practice because - functions abstracted over coercions are usually abstracted over *boxed* coercions - we don't currently unbox a boxed-coercion arg because it's GADT (I see how to fix this too) But after floating, optimisation, and so on, Trac #10288 did get a function abstracted over an unboxed coercion, and then the -flate-dmd-anal pass went wrong. I don't think I can come up with a test case, but I don't think it matters too much. Still to come - Fix a second bug, namely that coercion variables are wrongly marked as absent because DmdAnal doesn't check the the free variables of casts. I think this never bites in practice (see the follow-up commit) - Make GADT products work with strictness analysis }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 08:28:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 08:28:46 -0000 Subject: [GHC] #10288: -flate-dmd-anal triggers "Entered absent arg" In-Reply-To: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> References: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> Message-ID: <061.9d545787119b73af8b694e68406c7acf@haskell.org> #10288: -flate-dmd-anal triggers "Entered absent arg" -------------------------------------+------------------------------------- Reporter: yongqli | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"5c7e4db5ce84395eb0d727eb3b0f505a00191164/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5c7e4db5ce84395eb0d727eb3b0f505a00191164" Wibble to DmdAnal This fixes a typo in d5773a4939b1feea51ec0db6624c9462751e948a Teach DmdAnal that coercions are value arguments! (Trac #10288) Sorry about that; I'm not sure how it slipped through. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 08:35:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 08:35:44 -0000 Subject: [GHC] #10288: -flate-dmd-anal triggers "Entered absent arg" In-Reply-To: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> References: <046.dd75cfab02ea5fc146125be5e30228f6@haskell.org> Message-ID: <061.2444b603d6283f6ee321945dd881bd05@haskell.org> #10288: -flate-dmd-anal triggers "Entered absent arg" -------------------------------------+------------------------------------- Reporter: yongqli | Owner: simonpj Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => highest * status: new => merge Comment: yongqli, your test case nailed it -- thank you! It was so helpful to be able to reproduce it, and it's not an easy case to make happen, so I might well have failed to find it, or assumed it was already fixed, without your help. Austin: please merge the above two to 7.10. I'm not adding a regression test because it's hard to provoke; and the fix (which consisted only of deleting code) is pretty robust. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 08:37:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 08:37:55 -0000 Subject: [GHC] #10333: hs-boot modification doesn't induce recompilation Message-ID: <045.b2a6545e2380bf06a403c64b9db0df81@haskell.org> #10333: hs-boot modification doesn't induce recompilation -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHC accepts Unknown/Multiple | invalid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Consider these modules: X.hs-boot {{{ module X where }}} Y.hs {{{ module Y where import {-# SOURCE #-} X data T = T data S = S T }}} X.hs {{{ module X where import Y }}} `ghc --make Y.hs` will compile fine. Now, modify `X.hs-boot` to add a `data T` (which will cause an ambiguous identifier error in Y.hx`. Run `ghc --make Y.hs` and nothing happens! (You might also notice something else a bit funny, which is that `X.hs` gets compiled, even though it's not directly in the import chain of Y. I think this might be intentional but I'm not sure.) Discovered this while poking around #10182. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 08:38:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 08:38:13 -0000 Subject: [GHC] #10333: hs-boot modification doesn't induce recompilation In-Reply-To: <045.b2a6545e2380bf06a403c64b9db0df81@haskell.org> References: <045.b2a6545e2380bf06a403c64b9db0df81@haskell.org> Message-ID: <060.362be6e5f471c7ae2d7236c7d273fc40@haskell.org> #10333: hs-boot modification doesn't induce recompilation -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC accepts | Unknown/Multiple invalid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by ezyang: Old description: > Consider these modules: > > X.hs-boot > {{{ > module X where > }}} > > Y.hs > {{{ > module Y where > import {-# SOURCE #-} X > data T = T > data S = S T > }}} > > X.hs > {{{ > module X where > import Y > }}} > > `ghc --make Y.hs` will compile fine. Now, modify `X.hs-boot` to add a > `data T` (which will cause an ambiguous identifier error in Y.hx`. Run > `ghc --make Y.hs` and nothing happens! > > (You might also notice something else a bit funny, which is that `X.hs` > gets compiled, even though it's not directly in the import chain of Y. I > think this might be intentional but I'm not sure.) > > Discovered this while poking around #10182. New description: Consider these modules: X.hs-boot {{{ module X where }}} Y.hs {{{ module Y where import {-# SOURCE #-} X data T = T data S = S T }}} X.hs {{{ module X where import Y }}} `ghc --make Y.hs` will compile fine. Now, modify `X.hs-boot` to add a `data T` (which will cause an ambiguous identifier error in `Y.hx`. Run `ghc --make Y.hs` and nothing happens! (You might also notice something else a bit funny, which is that `X.hs` gets compiled, even though it's not directly in the import chain of Y. I think this might be intentional but I'm not sure.) Discovered this while poking around #10182. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 09:20:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 09:20:24 -0000 Subject: [GHC] #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module In-Reply-To: <046.ebf20f155e05760df4b4c62188044473@haskell.org> References: <046.ebf20f155e05760df4b4c62188044473@haskell.org> Message-ID: <061.cb08feb1ade2738b02fe2d2ac55c6843@haskell.org> #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module -------------------------------------+------------------------------------- Reporter: skilpat | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.4.2 checker) | Keywords: backpack Resolution: | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by ezyang): The reason this occurs is when we process imports in `rnImportDecl`, we filter out any identifiers which come from a self-boot: {{{ let gbl_env = mkGlobalRdrEnv (filterOut from_this_mod gres) }}} So these identifiers never get added to the GlobalRdrEnv, and thus aren't brought into scope. I don't know what happens if you remove that `filterOut`. It comes from some very old code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 09:28:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 09:28:11 -0000 Subject: [GHC] #10182: lookupIfaceGlobal crash with SOURCE import In-Reply-To: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> References: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> Message-ID: <061.a4ada08c6e5fc15cb920c35bc51f690a@haskell.org> #10182: lookupIfaceGlobal crash with SOURCE import -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Here is what's going on: when a self-import occurs, the hi-boot for the current module is being loaded into the EPS by `loadInterface`. **This should never happen.** However, in the absence of type class instances, this is relatively harmless, as we won't actually look in the EPS to find names for locally defined identifiers. However, there is one case where we always consult the EPS: instance lookup! An orphan instance also causes an EPS-updating load of the hi-boot, even absent a direct import, as the boot file will be recorded as an orphan and thus we'll try to load it. One thing that is a bit tiresome is that on a direct `{-# SOURCE #-}` import, we really do need to read in the boot interface (just not add it to the EPS), since we might be some identifiers in another namespace: {{{ -- A.hs-boot module A(Bool) where -- A.hs module A(Bool) where import {-# SOURCE #-} qualified A as A2 data X = X A2.Bool }}} But this has never actually worked with declarations in the hs-boot itself, see #7672. (I spent some time being confused at the interface trace, which claimed `Reading [boot] interface for T8743` even in non buggy cases. This is because we always load the `hi-boot` interface to compare against the "Real Thing"; however, THIS goes through `tcHiBootIface`, which DOES NOT update the EPS.) I suspect simonpj's original test case was not fully reduced due to #10333. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 10:56:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 10:56:38 -0000 Subject: [GHC] #9579: Runtime suggests using +RTS when that's not possible In-Reply-To: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> References: <045.b27628d41e7cac02ba3f0a6438a4f9eb@haskell.org> Message-ID: <060.683e6bc33a8590ecb298848c97e7188b@haskell.org> #9579: Runtime suggests using +RTS when that's not possible -------------------------------------+------------------------------------- Reporter: gintas | Owner: javran Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Runtime System | Version: 7.9 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D767 -------------------------------------+------------------------------------- Comment (by bherzog): The test-cases are a bit too fragile. All three of the `T9579_stackoverflow_*` tests fail for me because of differences in the reported stack size: {{{ @@ -1,2 +1,2 @@ -Stack space overflow: current size 99136 bytes. +Stack space overflow: current size 99208 bytes. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 11:54:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 11:54:34 -0000 Subject: [GHC] #10334: __ctzdi2/si2/__clzdi2/si2 unknown symbols in ghc-prim on non-shared libs platform Message-ID: <046.e3ef261ac65799c1bb5faa4b0f1fb891@haskell.org> #10334: __ctzdi2/si2/__clzdi2/si2 unknown symbols in ghc-prim on non-shared libs platform -------------------------------------+------------------------------------- Reporter: kgardas | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.11 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hello, ghc-prim is using GCC's {{{__builtin_ctz(ll)/clz(ll)}}} functions to implement functionality to count leading or trailing zeros in provided integer type variable. The problem with those GCC's builtins is that on platform which does not implement either of the operation in ISA, such function call can't be replaced by simple ISN, but needs to be replaced by the call to the libgcc library which then implements the missing operation in generic C. In ghc- prim you can already see a workaround for missing *ll functions on i386. The problem is that generic SPARC (v9) does not provide ISNs in its ISA to implement those builtins effectively so any call to builtins above is replaced by the call to the libgcc. The inserted functions calls are {{{__ctzsi2/__ctzdi2/__clzsi2/__clzdi2}}} in this case. Unfortunately this makes a lot of GHCi testcases (if not all!) failing with the error: {{{ ghc-stage2: /home/karel/src/obj-ghc-sparc-reg_ncg- head-2015-04-07-debug/libraries/ghc-prim/dist-install/build/HSghc- prim-0.4.0.0-8TmvWUcS1U1IKHT0levwg3.o: unknown symbol `__clzdi2' ghc-stage2: unable to load package `ghc-prim-0.4.0.0' }}} Please note, this happens only on platforms which does not support shared libs for GHC. On platforms with GHC shared libs support, ghc-prim is shared library which is correctly linked against the libgcc shared library and such error does not happen. (example Solaris/i386). Unfortunately we can't link ghc-prim*.o with libgcc -- it does effectively nothing so there are two solution for this issue IMHO: 1) on problematic platform implement hs_ctz*/hs_clz* functions in pure C without usage of GNU C builtin functions. or 2) enforce linking of shared libgcc with produced application binary. Such linking needs to be enforced with -shared-libgcc parameter passed to the GNU C in linking step and also by usage of either builtins in the application C code (not library code). My experimental code below shows that this is possible (tested on Solaris/SPARC). Please note that by default on static platform, the static version of libgcc is used and this does not help here. Also please note that usage of builtin in let say RTS library does not help either. I've tested RtsMain.c. The reason is the same like why it's not working in ghc-prim. We can't link *.o or *.a against shared libgcc. {{{ diff --git a/compiler/main/DriverPipeline.hs b/compiler/main/DriverPipeline.hs index c86667c..7c615d1 100644 --- a/compiler/main/DriverPipeline.hs +++ b/compiler/main/DriverPipeline.hs @@ -1651,6 +1651,7 @@ mkExtraObjToLinkIntoBinary dflags = do | gopt Opt_NoHsMain dflags = Outputable.empty | otherwise = vcat [ text "#include \"Rts.h\"", + text "#include ", text "extern StgClosure ZCMain_main_closure;", text "int main(int argc, char *argv[])", char '{', @@ -1662,6 +1663,10 @@ mkExtraObjToLinkIntoBinary dflags = do Just opts -> ptext (sLit " __conf.rts_opts= ") <> text (show opts) <> semi, text " __conf.rts_hs_main = rtsTrue;", + text " printf(\"ctz(argc): %d\\n\", __builtin_ctz(argc));", text " return hs_main(argc,argv,&ZCMain_main_closure,__conf);", char '}', char '\n' -- final newline, to keep gcc happy }}} of course this is just a proof of concept. For real code we would need some place to save the result of the called builtin to prevent GCC from removing the call as an unused value. I guess one added value in {{{__conf}}} just for this case should do the job here. I'm free to implement either of those two solutions or even completely different one, I just need to know your preference in this case. BTW: I'm ccing people from #9340 which looks really related to this issue. If you are not interested in this issue discussion, please un-cc yourself. Thanks! Karel PS: as this is IMHO general issue, I'm not setting SPARC/Solaris as Architecture/OS here... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 12:16:42 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 12:16:42 -0000 Subject: [GHC] #10182: lookupIfaceGlobal crash with SOURCE import In-Reply-To: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> References: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> Message-ID: <061.fd1531a9da98d94f217bb76150a06d43@haskell.org> #10182: lookupIfaceGlobal crash with SOURCE import -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => ezyang Comment: We agreed to fix this by make a self SOURCE import simply an error. (With a Note in the code to explain why it's awkward to allow it.) Edward will do this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 12:17:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 12:17:38 -0000 Subject: [GHC] #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module In-Reply-To: <046.ebf20f155e05760df4b4c62188044473@haskell.org> References: <046.ebf20f155e05760df4b4c62188044473@haskell.org> Message-ID: <061.87375b6b026c57ce3be0c7dcc897c7dd@haskell.org> #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module -------------------------------------+------------------------------------- Reporter: skilpat | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.4.2 checker) | Keywords: backpack Resolution: | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => ezyang Comment: I agree. Just remove it and see. It looks outright wrong to me. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 12:32:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 12:32:20 -0000 Subject: [GHC] #10335: Failure to construct superclasses in instance Message-ID: <046.2ff0631e8c296e4b1559cc95f6a8eb9e@haskell.org> #10335: Failure to construct superclasses in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider {{{ {-# LANGUAGE MultiParamTypeClasses, FlexibleInstances, ConstraintKinds #-} module Foo where class Eq a => C a b type X a = (Eq a, Show a) instance X a => C a [b] }}} HEAD gives {{{ Foo.hs:8:10: Could not deduce (Eq a) arising from the superclasses of an instance declaration from the context: X a bound by the instance declaration at Foo.hs:8:10-23 Possible fix: add (Eq a) to the context of the instance declaration In the instance declaration for ?C a [b]? }}} This is fall-out from refactoring the silent-superclass story. Patch coming. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 13:02:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 13:02:45 -0000 Subject: [GHC] #10336: Support qualified self {-# SOURCE #-} import Message-ID: <045.e4521d2ed9990a69119569a9c3002eed@haskell.org> #10336: Support qualified self {-# SOURCE #-} import -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: feature | Status: new request | Milestone: ? Priority: lowest | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: 7672 Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The source import in this module is a no-op and has no legitimate use: {{{ module A where import {-# SOURCE #-} A }}} It's also tricky to support properly, see #10182. So we will disable it. However, there is one mode of use which cannot be legitimately done in normal Haskell: a qualified source import: {{{ module A where import {-# SOURCE #-} qualified A as MyA }}} The intended semantics is that the boot entities defined in A.hs-boot are available under the qualification MyA. Fixing #7672 would get us most of the way here, but there is one more step to avoid regressing #10182. So this just seems not worth fixing, unless someone really wants it. (Note: regular self imports could also be supported this way, but it would be even more complicated to do, since we don't even know what OccNames to add provenances for.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 13:10:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 13:10:31 -0000 Subject: [GHC] #10077: Providing type checker plugin on command line results in false cyclic import error In-Reply-To: <047.782b0d33638d12045ffab180b13fe3e7@haskell.org> References: <047.782b0d33638d12045ffab180b13fe3e7@haskell.org> Message-ID: <062.df35ad84bc077a28f44899653f331b36@haskell.org> #10077: Providing type checker plugin on command line results in false cyclic import error -------------------------------------+------------------------------------- Reporter: jbracker | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | typechecker plugin cycle imports Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): adamgundry: I don't think your diagnosis of the problem is correct. Isn't the case here that, when GHC attempts to compile a plugin, it shouldn't use the `-fplugin` arguments for the compilation? Simple stage restriction: you can't use a plugin on itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 13:16:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 13:16:31 -0000 Subject: [GHC] #10337: One-shot module loops have hard to understand messages Message-ID: <045.38e47b01e257bb3e34f7bb0cb6f9d348@haskell.org> #10337: One-shot module loops have hard to understand messages -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider these two modules: {{{ -- A.hs module A where -- B.hs module B where import A }}} `ghc --make B.hs` will compile this fine. Now edit `A.hs` to be circular: {{{ -- A.hs module A where import B }}} and attempt to one-shot compile it with `ghc -c A.hs`. You will now get an uninformative error message: {{{ A.hs:1:1: Circular imports: module `A' depends on itself }}} You can get a more informative message with `--make`: {{{ Module imports form a cycle: module `A' (A.hs) imports `B' (./B.hs) which imports `A' (A.hs) }}} We should either suggest users try again with `--make`, or try harder to give a useful message in one-shot mode. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 13:47:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 13:47:26 -0000 Subject: [GHC] #8743: The impossible happened : Prelude.(!!): index too large In-Reply-To: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> References: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> Message-ID: <059.a98535995f548ac1fda5750091dda047@haskell.org> #8743: The impossible happened : Prelude.(!!): index too large -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * owner: nomeata => * status: closed => new * resolution: fixed => Comment: After adjusting the test-case to not do a direct import of the hs-boot file, I now get this Core Lint error: {{{ Compile failed (status 256) errors were: *** Core Lint errors : in result of Simplifier *** T8743.hs-boot:3:10: warning: [RHS of $fxToRowMaybe :: forall a_anp. ToRow (Maybe a_anp)] idArity 1 exceeds typeArity 0: $fxToRowMaybe *** Offending Program *** $ctoRow_awT :: forall a_awR. Maybe a_awR -> [()] [LclId, Arity=1, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=1,unsat_ok=True,boring_ok=True)}] $ctoRow_awT = \ (@ a_awR) (ds_dx0 :: Maybe a_awR) -> case ds_dx0 of _ [Occ=Dead] { __DEFAULT -> : @ () () ([] @ ()) } $fToRowMaybe [InlPrag=INLINE (sat-args=0)] :: forall a_awP. ToRow (Maybe a_awP) [LclIdX[DFunId(nt)], Arity=1, Str=DmdType, Unf=Unf{Src=InlineStable, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=False,boring_ok=True) Tmpl= $ctoRow_awT `cast` (forall a_awR. Sym (NTCo:ToRow[0] _N) :: (forall a_awR. Maybe a_awR -> [()]) ~R# (forall a_awR. ToRow (Maybe a_awR)))}] $fToRowMaybe = $ctoRow_awT `cast` (forall a_awR. Sym (NTCo:ToRow[0] _N) :: (forall a_awR. Maybe a_awR -> [()]) ~R# (forall a_awR. ToRow (Maybe a_awR))) $fxToRowMaybe :: forall a_anp. ToRow (Maybe a_anp) [LclIdX, Arity=1, Str=DmdType, Unf=Unf{Src=, TopLvl=True, Value=True, ConLike=True, WorkFree=True, Expandable=True, Guidance=ALWAYS_IF(arity=0,unsat_ok=True,boring_ok=True)}] $fxToRowMaybe = $fToRowMaybe *** End of Offense *** }}} Do not know enough to investigate further. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 13:49:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 13:49:49 -0000 Subject: [GHC] #10338: GHC Forgets Constraints Message-ID: <047.e9cb1bcfe02024f21718f3ccf843982b@haskell.org> #10338: GHC Forgets Constraints -------------------------------------+------------------------------------- Reporter: crockeea | 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 | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This is possibly fixed by #10195, but I don't have a convenient means of testing it. At any rate, this testcase is considerably simpler than the one in #10195. {{{#!hs {-# LANGUAGE TypeFamilies, FlexibleContexts, GADTs, MultiParamTypeClasses #-} type family F r class (Functor t) => T t r where fromScalar :: r -> t r data Foo t r where Foo :: t (F r) -> Foo t r Scalar :: r -> Foo t r toF :: r -> F r toF = undefined convert :: (T t (F r)) => Foo t r -> Foo t r convert (Scalar c) = let fromScalar' = fromScalar in Foo $ fromScalar' $ toF c }}} This code compiles with GHC 7.8.4. When I add a generic instance for `T` (which requires `FlexibleInstances`): `instance (Functor t, Num r) => T t r` GHC complains: {{{#!hs Could not deduce (Num (F r)) arising from a use of ?fromScalar? from the context (T t (F r)) bound by the type signature for convert :: (T t (F r)) => Foo t r -> Foo t r at Main.hs:(17,12)-(18,23) In the expression: fromScalar In an equation for ?fromScalar'?: fromScalar' = fromScalar In the expression: let fromScalar' = fromScalar in Foo $ fromScalar' $ toF c }}} Of course the problem can be fixed by adding a type signature to `fromScalar` and adding `ScopedTypeVariables`: {{{#!hs convert :: forall t r . (T t (F r)) => Foo t r -> Foo t r convert (Scalar c) = let fromScalar' = fromScalar :: F r -> t (F r) in Foo $ fromScalar' $ toF c }}} Like #10195, this is triggered when a generic instance is in scope. The (main) problem of course is that GHC tries to match the generic instance instead of using the `T (F r)` constraint supplied by `convert`. A secondary issue is that I think the example should have the same behavior pre- and post-instance, i.e either both should compile or both should not compile. I'm not sure if a monomorphism restriction is actually being triggered here or if that's just a red herring. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 13:51:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 13:51:26 -0000 Subject: [GHC] #8743: The impossible happened : Prelude.(!!): index too large In-Reply-To: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> References: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> Message-ID: <059.62af0476b808e440ac9d44ec4e925d33@haskell.org> #8743: The impossible happened : Prelude.(!!): index too large -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): You can get the new test-case by applying https://phabricator.haskell.org/D860 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 13:52:36 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 13:52:36 -0000 Subject: [GHC] #10182: lookupIfaceGlobal crash with SOURCE import In-Reply-To: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> References: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> Message-ID: <061.9232a273c796ec9c3ec0111972d06a7b@haskell.org> #10182: lookupIfaceGlobal crash with SOURCE import -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: | https://phabricator.haskell.org/D860 -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => https://phabricator.haskell.org/D860 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 13:56:14 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 13:56:14 -0000 Subject: [GHC] #8743: The impossible happened : Prelude.(!!): index too large In-Reply-To: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> References: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> Message-ID: <059.19e61c1355ad53f03063b99a2b5bf0e9@haskell.org> #8743: The impossible happened : Prelude.(!!): index too large -------------------------------------+------------------------------------- Reporter: erikd | Owner: nomeata Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * owner: => nomeata -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 14:08:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 14:08:38 -0000 Subject: [GHC] #10339: PatternSynonyms confuse exhaustiveness check Message-ID: <042.a1c90776a4d0c26d5af0fe09a172c987@haskell.org> #10339: PatternSynonyms confuse exhaustiveness check -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 Revisions: | -------------------------------------+------------------------------------- I just noticed some odd behaviour when (ab)using pattern synonyms in the following code (whose style I don't really endorse): {{{#!hs {-# LANGUAGE PatternSynonyms, LambdaCase #-} module PatSyn1 where import System.Directory (doesFileExist) pattern Found = True pattern NotFound = False readConfigFile :: FilePath -> IO () readConfigFile filePath = doesFileExist filePath >>= \case Found -> putStrLn =<< readFile filePath NotFound -> putStrLn "File does not exist." pattern Void = () foo :: () -> () foo Void = () }}} Results in {{{ /home/hvr/Haskell/PatSyn1.hs:(11,54)-(13,47): Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: _ /home/hvr/Haskell/PatSyn1.hs:19:1-13: Warning: Pattern match(es) are non-exhaustive In an equation for ?foo?: Patterns not matched: _ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 14:10:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 14:10:34 -0000 Subject: [GHC] #10339: PatternSynonyms confuse exhaustiveness check In-Reply-To: <042.a1c90776a4d0c26d5af0fe09a172c987@haskell.org> References: <042.a1c90776a4d0c26d5af0fe09a172c987@haskell.org> Message-ID: <057.753993dde0fa0a63ae4ad631c1398ff7@haskell.org> #10339: PatternSynonyms confuse exhaustiveness check -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1 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 Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * version: 7.10.1 => 7.8.1 Comment: This occurs since GHC 7.8 (when pattern synonyms were introduced), up to GHC HEAD -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 16:09:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 16:09:37 -0000 Subject: [GHC] #10334: __ctzdi2/si2/__clzdi2/si2 unknown symbols in ghc-prim on non-shared libs platform In-Reply-To: <046.e3ef261ac65799c1bb5faa4b0f1fb891@haskell.org> References: <046.e3ef261ac65799c1bb5faa4b0f1fb891@haskell.org> Message-ID: <061.ab02b2456b8f46200c407703c049df77@haskell.org> #10334: __ctzdi2/si2/__clzdi2/si2 unknown symbols in ghc-prim on non-shared libs platform -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * owner: ekmett => Comment: I'd encourage a fix, but I'm going to relinquish control of the ticket as it is more about how the linker/RTS works than the structure of the core libraries per se. If we need a good `ctz` and `clz`, I have implementations in various libraries we could adapt back into C/C-- and contribute from various projects. e.g. https://github.com/ekmett/bits/blob/ded1403737ce26e819c1d1c1facb41a9e776eb46/cbits/debruijn.c#L2 gives usable De Bruijn multiplication tables and https://github.com/ekmett/bits/blob/ded1403737ce26e819c1d1c1facb41a9e776eb46/src/Data/Bits/Extras.hs#L56 provides a working portable `ctz`. Right below it is a decent `clz` that uses our existing `popCount` primitive. You may need to adjust the answers by 1 to comply with the `__builtin_clz` and `__builtin_ctz` primitives, I forget. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 17:09:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 17:09:33 -0000 Subject: [GHC] #10182: lookupIfaceGlobal crash with SOURCE import In-Reply-To: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> References: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> Message-ID: <061.29e56daca3d4adf72b7322fe39595b4c@haskell.org> #10182: lookupIfaceGlobal crash with SOURCE import -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: | https://phabricator.haskell.org/D860 -------------------------------------+------------------------------------- Comment (by ezyang): Patch doesn't validate; there are about 11 test-cases that use a self boot import to tickle the hs-boot mechanism. I'm converting them to have an intermediate module (bleh!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 21:36:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 21:36:55 -0000 Subject: [GHC] #10338: GHC Forgets Constraints In-Reply-To: <047.e9cb1bcfe02024f21718f3ccf843982b@haskell.org> References: <047.e9cb1bcfe02024f21718f3ccf843982b@haskell.org> Message-ID: <062.77cc346a192866f31a159c23bfd2ab25@haskell.org> #10338: GHC Forgets Constraints -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Yes this is confusing. No it's not #10195. Here's what happens. When GHC comes across the local binding `let fromScalar' = fromScalar`, it tries to find its most general type. To do so it instantiates the call to `fromScalar` with fresh unification variables `t0` and `r0`, and generates the constraint `T t0 r0`. Now it tries to simplify that constraint, and succeeds with the top level instance declaration; and that is where things go wrong; we get the inferred type {{{ fromScalar' :: forall t r. (Functor t, Num r) => r -> t r }}} Why doesn't it refrain from simplifying `T t0 r0` because of the in-scope constraint `T t (F r)`? Answer: the most general type of a local binding is computed by calling the constraint simplifer during constraint generation. It's a break with the general plan to first do constraint generation and only then simplify constraints. If we didn't attempt to generalise the binding for `fromScalar'` we would not do this early call to the constraint solver, and all would be well (at this point the "given overlap" fix in #10195 would kick in). You might think that `MonoLocalBinds` would make this happen, but actually `MonoLocalBinds` attempts to generalise even local bindings that have no non-top-level type variables, such as this one. And indeed usually generalising is a good thing. Maybe there should be a way to turn off local generalisation altogether. Congratulations on dicovering this. I had previously thought that `MonoLocalBinds` would make the constraint solver completely well behaved, but this example shows that I wasn't quite right. I don't see an easy fix, and it seems very much a corner case so probably doesn't justify the work (and code complexity) for a non-easy fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 21:58:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 21:58:57 -0000 Subject: [GHC] #3919: Or-patterns as GHC extension In-Reply-To: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> References: <051.27f4dc97a096cc6bd656d7691ce3afb5@haskell.org> Message-ID: <066.32238d68144e51e66e61c256c5c36b3e@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: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by sergv): * cc: sergv (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 22:02:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 22:02:40 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.d3f3fe9bb9a89c782db02b18c91ce2f5@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by simonpj): Sigh. `ImpredicativeTypes` certainly causes a lot of pain given that it's a feature that doesn't work and is unsupported. The problem here is that we should never unify `(c => t)` with `a b`, as happens in the call `i (Proxy :: Proxy (Eq Int => Int))`. Here what happens when I fix this: {{{ T9858.hs:24:8: error: Couldn't match type `Eq Int => Int' with `a0 b0' Expected type: Proxy (a0 b0) Actual type: Proxy (Eq Int => Int) In the first argument of `i', namely `(Proxy :: Proxy (Eq Int => Int))' In the expression: i (Proxy :: Proxy (Eq Int => Int)) In an equation for `j': j = i (Proxy :: Proxy (Eq Int => Int)) }}} And that seems entirely reasonable. Thank you - you are amazingly good at exposing my inadequate thinking. Keep it up! (Meanwhile I'll plug this hole tomorrow.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 22:17:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 22:17:21 -0000 Subject: [GHC] #10318: Cycles in class declaration (via superclasses) sometimes make sense. In-Reply-To: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> References: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> Message-ID: <060.cc0ef2acdebdff89ec3555f1917bed97@haskell.org> #10318: Cycles in class declaration (via superclasses) sometimes make sense. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): What you are asking for looks jolly hard to me. On the other hand, your middle solution looks pretty easy, perhaps with {{{ type ID a = (AID a, AID (Frac a)) }}} I find it hard to believe that using this would cause a "few thousand lines of code hacking around the limitation". Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 22:57:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 22:57:35 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.89452688f415ff2bff865f3ec8cb676b@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by ekmett): Removing the ability to unify `(c => t)` works for me. I have no uses of that in the constraints package, and it doesn't make a whole lot of sense anyways, as it really is a syntactic form. On the other hand, I have plenty of uses now of `Typeable` for `Constraint` kinded things. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 23:12:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 23:12:53 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.8cce715f535109b6373d77af131bf85b@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"0bbc2ac6dae9ce2838f23a75a6a989826c06f3f5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0bbc2ac6dae9ce2838f23a75a6a989826c06f3f5" Use the gold linker for aarch64/linux (#9673) Like 32 bit Arm, Aarch64 requires use of the gold linker. Signed-off-by: Erik de Castro Lopo Test Plan: 'make install' on aarch64, validate elsewhere Reviewers: rwbarton, bgamari, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D858 GHC Trac Issues: #9673 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 21 23:58:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 21 Apr 2015 23:58:49 -0000 Subject: [GHC] #10340: Type inference regression with Any Message-ID: <043.6973fe6949fc7fde77cc0902c496af6e@haskell.org> #10340: Type inference regression with Any -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following module typechecks with GHC 7.8.3, but GHC 7.10.1 gives an error: {{{#!hs {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances #-} module Foo where import GHC.Exts (Any) class MonadState s m where get :: m s newtype State s a = State (s -> (s, a)) instance MonadState s (State s) where get = State $ \s -> (s, s) foo :: State Any Any foo = get }}} {{{ [1 of 1] Compiling Foo ( any.hs, any.o ) any.hs:15:7: No instance for (MonadState Any (State Any)) arising from a use of ?get? In the expression: get In an equation for ?foo?: foo = get }}} If I replace the uses of `Any` with `Int`, the problem goes away. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 00:00:19 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 00:00:19 -0000 Subject: [GHC] #10318: Cycles in class declaration (via superclasses) sometimes make sense. In-Reply-To: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> References: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> Message-ID: <060.65f00d5d37e75fe9d510c7ef91de17f4@haskell.org> #10318: Cycles in class declaration (via superclasses) sometimes make sense. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by ekmett): I can provide much larger examples. =) The problem with the middle solution is it doesn't scale out when the cycles get much harder and doesn't work at all when reasoning becomes inductive and doesn't self-terminate like this. When I have things like (simplified): * the field of fractions for an integral domain is a field. * every field is an integral domain. * the field of fractions of any field is itself. * polynomial over an integral domain are an integral domain * polynomials over a field form a field * the field of rational functions over a field is the same as the field of fractions of the ring of polynomials over that field So if we take "Rat" to be the field of rational functions over a field and you take Poly to be the ring of polynomials over a type, and Frac to be the field of fractions over an integral domain, these all get a very incestuous relationship. Frac (Frac a) ~ Frac a For every field Frac a ~ a but we need to know that integral domain implies integral domain for the field of fractions, this one is nice because it terminates. Frac (Frac a) ~ Frac a is given to us, so GHC is happy, and we can stop with the middle technique I mentioned. But the field of rational functions over a given field is a new field, and the field of rational functions over that is also a new field, so I can't use a finite version of the middle trick to supply this information. I have to instead turn to the second trick. So here I only get a few hundred lines of code. For a few thousand, we need to turn to category theory. =) https://github.com/ekmett/hask/blob/d945e09779bd0b63af05e649b142cde6477856f0/src/Hask/Category.hs#L68 defines a sufficiently nice version of a category that we can do some real category theory, well, most of a category, because of these sort of circular definitions. {{{ class Category' (p :: i -> i -> *) }}} Now I can define functors between categories with something that includes: {{{ class (Category' (Dom f), Category' (Cod f)) => Functor (f :: i -> j) where type Dom f :: i -> i -> * type Cod f :: j -> j -> * }}} Then I have to iterate the middle trick twice to get to the real definition I want. Given the convenience alias {{{ class (Functor p, Cod p ~ Nat (Dom2 p) (Cod2 p), Category' (Dom2 p), Category' (Cod2 p)) => Bifunctor (p :: i -> j -> k) instance (Functor p, Cod p ~ Nat (Dom2 p) (Cod2 p), Category' (Dom2 p), Category' (Cod2 p)) => Bifunctor (p :: i -> j -> k) }}} we can step one step further to tying off the notion of a Category {{{ class (Category' p, Bifunctor p, Dom p ~ Op p, p ~ Op (Dom p), Cod p ~ Nat p (->), Dom2 p ~ p, Cod2 p ~ (->)) => Category'' p instance (Category' p, Bifunctor p, Dom p ~ Op p, p ~ Op (Dom p), Cod p ~ Nat p (->), Dom2 p ~ p, Cod2 p ~ (->)) => Category'' p }}} and then finally give: {{{ -- | The full definition for a (locally-small) category. class (Category'' p, Category'' (Op p), p ~ Op (Op p), Ob p ~ Ob (Op p)) => Category p instance (Category'' p, Category'' (Op p), p ~ Op (Op p), Ob p ~ Ob (Op p)) => Category p }}} Here what we really want is: {{{ data Nat (p :: i -> i -> *) (q :: j -> j -> *) (f :: i -> j) (g :: i -> j) where Nat :: ( FunctorOf p q f , FunctorOf p q g ) => { runNat :: forall a. Ob p a => q (f a) (g a) } -> Nat p q f g class (Functor p, Dom p ~ Op p, Cod p ~ Nat p (->), p ~ Op (Op p), Ob p ~ Ob (Op p)) => Category (p :: i -> i -> *) where type Ob p :: i -> Constraint class (Category (Dom p), Category (Cod p)) => Functor (p :: i -> j) type Dom f :: i -> i -> * type Cod f :: j -> j -> * class (Functor f, Dom f ~ p, Cod f ~ q) => FunctorOf p q f instance (Functor f, Dom f ~ p, Cod f ~ q) => FunctorOf p q f newtype Yoneda (p :: i -> i -> *) (a :: i) (b :: i) = Op { getOp :: p b a } type family Op (p :: i -> i -> *) :: i -> i -> * where Op (Yoneda p) = p Op p = Yoneda p }}} but this small definition is (deliberately) circular in several ways. These are needed to express that every category can be used itself as a functor from its opposite category to the category of natural transformations from it to "Hask", which is the definition of the Yoneda lemma. It expresses the fact that we can do all of category theory in Haskell "curried" because everything is sufficiently locally small. This is critical to avoid the need to define bifunctors explicitly, but rather let us view a bifunctor as a functor to a functor category. Even once I have that machinery in place it is indeed a "few thousand lines of code hacking around limitations" til I get to https://github.com/ekmett/hask/blob/d945e09779bd0b63af05e649b142cde6477856f0/src/Hask/Tensor/Compose.hs#L134 wherein the well known claim that "a monad is a monoid in the category of endofunctors, what is the problem" gets used as code. Much of it is spent opening up data constructors in local scope to get at instances, many of which must exist canonically, but I have to carry them around here because I can't make these sorts of circular claims more directly. Consider: https://github.com/ekmett/hask/blob/d945e09779bd0b63af05e649b142cde6477856f0/src/Hask/Tensor/Compose.hs#L104 Those lines are mostly opening dictionaries. the line I want is the one at the end. What I have to write is 4 lines of preamble to state the real theorem. This project choked on its own complexity after this theorem: https://github.com/ekmett/hask/blob/d945e09779bd0b63af05e649b142cde6477856f0/src/Hask/Tensor/Day.hs#L46 caused everyone involve to have a collective aneurysm. ;) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 00:28:32 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 00:28:32 -0000 Subject: [GHC] #10318: Cycles in class declaration (via superclasses) sometimes make sense. In-Reply-To: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> References: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> Message-ID: <060.713ab91a7ad65b0e90b3dff9231f0cfb@haskell.org> #10318: Cycles in class declaration (via superclasses) sometimes make sense. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by ekmett): Things like {{{ instance Show (f (Fix f)) => Show (Fix f) }}} already work, we can ask for "undecidable instances", but not "undecidable superclasses". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 05:30:11 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 05:30:11 -0000 Subject: [GHC] #10283: Make it possible to suppress warnings produced by -fdefer-type-errors In-Reply-To: <049.e826a9f4dc5636b8c6eb248fd99f1fda@haskell.org> References: <049.e826a9f4dc5636b8c6eb248fd99f1fda@haskell.org> Message-ID: <064.bc4346298b600b4a04ba2780c9384a95@haskell.org> #10283: Make it possible to suppress warnings produced by -fdefer-type-errors -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: newcomer Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: D864 -------------------------------------+------------------------------------- Changes (by erikd): * differential: => D864 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 05:32:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 05:32:59 -0000 Subject: [GHC] #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess In-Reply-To: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> References: <050.d22df58ab2677433292de3e3cacb5585@haskell.org> Message-ID: <065.42df4b94ab87746c3c60442739e4500f@haskell.org> #9673: aarch64 7.8.4, 7.10, 7.11: lib/ghc/bin/ghc-pkg --version does not output from subprocess -------------------------------------+------------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Installing GHC | Test Case: failed | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by erikd): * status: new => merge * milestone: => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 05:46:40 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 05:46:40 -0000 Subject: [GHC] #10283: Make it possible to suppress warnings produced by -fdefer-type-errors In-Reply-To: <049.e826a9f4dc5636b8c6eb248fd99f1fda@haskell.org> References: <049.e826a9f4dc5636b8c6eb248fd99f1fda@haskell.org> Message-ID: <064.84bad8b30948bed6987443341d0830aa@haskell.org> #10283: Make it possible to suppress warnings produced by -fdefer-type-errors -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: newcomer Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D864 -------------------------------------+------------------------------------- Changes (by rwbarton): * differential: D864 => Phab:D864 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 06:08:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 06:08:44 -0000 Subject: [GHC] #10283: Make it possible to suppress warnings produced by -fdefer-type-errors In-Reply-To: <049.e826a9f4dc5636b8c6eb248fd99f1fda@haskell.org> References: <049.e826a9f4dc5636b8c6eb248fd99f1fda@haskell.org> Message-ID: <064.07b577e34ecfb3113c0b89d092ec8b3e@haskell.org> #10283: Make it possible to suppress warnings produced by -fdefer-type-errors -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: kanetw Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: newcomer Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D864 -------------------------------------+------------------------------------- Changes (by kanetw): * owner: => kanetw -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 06:08:54 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 06:08:54 -0000 Subject: [GHC] #10283: Make it possible to suppress warnings produced by -fdefer-type-errors In-Reply-To: <049.e826a9f4dc5636b8c6eb248fd99f1fda@haskell.org> References: <049.e826a9f4dc5636b8c6eb248fd99f1fda@haskell.org> Message-ID: <064.6a8449dffbe776ce12488b93a992896b@haskell.org> #10283: Make it possible to suppress warnings produced by -fdefer-type-errors -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: kanetw Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: newcomer Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D864 -------------------------------------+------------------------------------- Changes (by kanetw): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 08:07:05 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 08:07:05 -0000 Subject: [GHC] #8743: The impossible happened : Prelude.(!!): index too large In-Reply-To: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> References: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> Message-ID: <059.35f42f941dac270881a9982f20b569b7@haskell.org> #8743: The impossible happened : Prelude.(!!): index too large -------------------------------------+------------------------------------- Reporter: erikd | Owner: nomeata Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): I?m confused. The harbormaster build for Phab:D860 at https://phabricator.haskell.org/harbormaster/build/3863/ does not list 8743 as failing. Also, this looks like a different bug, unrelated to the demand analyzer, and related to the lint check introduced in #10181. I suggest to discuss this in a separate ticket. Also feel free to go ahead with your patches, marking the test case as `expect_broken`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 08:42:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 08:42:55 -0000 Subject: [GHC] #8743: The impossible happened : Prelude.(!!): index too large In-Reply-To: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> References: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> Message-ID: <059.149497d795dd3563d34186cc2301e2e5@haskell.org> #8743: The impossible happened : Prelude.(!!): index too large -------------------------------------+------------------------------------- Reporter: erikd | Owner: nomeata Type: bug | Status: new Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): I indeed was confused. The test is already marked as `expect_broken`, and you are trying to fix the breakage... But it still is unrelated to the demand analyzer. I?ll continue the discussion in #10182, where it belongs. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 08:49:26 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 08:49:26 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.63e471162d80bec562a2386542d11006@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c0b5adbd1a04dd1c7916c1240e50a936e826136d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c0b5adbd1a04dd1c7916c1240e50a936e826136d" Do not decompose => (Trac #9858) We really don't want to unify (a b) with (Eq a => ty). The ever-ingenious Oerjan discovered this problem; see comment:101 in Trac #9858. See Note [Decomposing fat arrow c=>t] in Type.hs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 08:59:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 08:59:02 -0000 Subject: [GHC] #10182: lookupIfaceGlobal crash with SOURCE import In-Reply-To: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> References: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> Message-ID: <061.61dae032801fe5b7865b1f96592e6532@haskell.org> #10182: lookupIfaceGlobal crash with SOURCE import -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: | https://phabricator.haskell.org/D860 -------------------------------------+------------------------------------- Comment (by nomeata): With Edwards?s change to the test case to not do a self-SOURCE-import, but rather indirected through another module, we get: {{{ *** Core Lint errors : in result of Simplifier *** T8743.hs-boot:3:10: warning: [RHS of $fxToRowMaybe :: forall a_anp. ToRow (Maybe a_anp)] idArity 1 exceeds typeArity 0: $fxToRowMaybe }}} The error message is misleading: It occurs when compiling `T8743.hs` proper. The desugared code before optimization is fine, after it occurs. My guess is that still from compiling `T8740.hs-boot`, GHC has `ToRow` in its environment as an abstract data type, without the information that it is just a newtype around `a -> [()]`. This is used by the renamer when parsing `T8740.hs`, so `typeArity`, which looks at the `DataTypCon`, returns `0` instead of `1`. Rough guess: The renamer should use the `T8743.hs`?s definition of `ToRow`, even if a (less useful) definition is already known from a boot file. Edward, does this explanation help you hunt down the problem? I know little about the plumbing of the various environments and such. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 09:01:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 09:01:58 -0000 Subject: [GHC] #10182: lookupIfaceGlobal crash with SOURCE import In-Reply-To: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> References: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> Message-ID: <061.644cda3aa8610b251261cd0e320f8569@haskell.org> #10182: lookupIfaceGlobal crash with SOURCE import -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: | https://phabricator.haskell.org/D860 -------------------------------------+------------------------------------- Comment (by nomeata): Looks like SPJ fixed this as I was talking: changeset:9b9fc4c732baab126b057b4031bebcbd67d6e348 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 09:03:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 09:03:16 -0000 Subject: [GHC] #8743: The impossible happened : Prelude.(!!): index too large In-Reply-To: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> References: <044.14fb3000cd396f6cc931d2897a1bb357@haskell.org> Message-ID: <059.a6509072b4487ecb0201fae269cee33a@haskell.org> #8743: The impossible happened : Prelude.(!!): index too large -------------------------------------+------------------------------------- Reporter: erikd | Owner: nomeata Type: bug | Status: closed Priority: highest | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => closed * resolution: => fixed Comment: Fixed by SPJ in changeset:9b9fc4c732baab126b057b4031bebcbd67d6e348 as talked. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 10:33:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 10:33:44 -0000 Subject: [GHC] #10341: hs-boot files can have bogus declarations if they're not exported Message-ID: <045.94f3a0fb535e74d4890448b88f6d6d7e@haskell.org> #10341: hs-boot files can have bogus declarations if they're not exported -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC accepts Architecture: | invalid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider: {{{ -- A.hs-boot module A(foo) where data A = AC { bar :: Int } | CC -- B.hs module B where import {-# SOURCE #-} A -- A.hs module A(foo) where import B data A = AC { foo :: Int } | BC }}} GHC won't complain that `A` is incompatibly defined, since it's not exported. Seems relatively harmless though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 11:04:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 11:04:35 -0000 Subject: [GHC] #10182: lookupIfaceGlobal crash with SOURCE import In-Reply-To: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> References: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> Message-ID: <061.0285bb3147d9f1704a251925353100a3@haskell.org> #10182: lookupIfaceGlobal crash with SOURCE import -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: | https://phabricator.haskell.org/D860 -------------------------------------+------------------------------------- Comment (by simonpj): Current status is confusing: * This ticket is about self-SOURCE import, and will be fixed by Phab:D860. * When Phab:D860 is applied, it reveals yet another bug: symptoms in comment:9. Simon fixed this new bug comment:10. * Independently, the test for #8473 was marked as failing because of the Lint arity error, even with `--make`, but Simon's fix fixed that. Conclusion: just commit Phab:D862 (remove self-SOURCE imports from test suite) and Phab:D860 (fix this ticket) and everything will be fine. Edward will do this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 11:07:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 11:07:03 -0000 Subject: [GHC] #10341: hs-boot files can have bogus declarations if they're not exported In-Reply-To: <045.94f3a0fb535e74d4890448b88f6d6d7e@haskell.org> References: <045.94f3a0fb535e74d4890448b88f6d6d7e@haskell.org> Message-ID: <060.25fb20300c8bd770c363b933cc7b383a@haskell.org> #10341: hs-boot files can have bogus declarations if they're not exported -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC accepts | Test Case: invalid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Consider: > > {{{ > -- A.hs-boot > module A(foo) where > data A = AC { bar :: Int } | CC > -- B.hs > module B where > import {-# SOURCE #-} A > -- A.hs > module A(foo) where > import B > data A = AC { foo :: Int } | BC > }}} > > GHC won't complain that `A` is incompatibly defined, since it's not > exported. > > Seems relatively harmless though. New description: Consider: {{{ -- A.hs-boot module A(foo) where foo :: A -> Int data A = AC { bar :: Int } | CC -- NB: A is not exported -- B.hs module B where import {-# SOURCE #-} A -- A.hs module A(foo) where import B data A = AC { foo :: Int } | BC }}} GHC won't complain that `A` is incompatibly defined, since it's not exported. Seems relatively harmless though. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 12:39:29 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 12:39:29 -0000 Subject: [GHC] #10182: lookupIfaceGlobal crash with SOURCE import In-Reply-To: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> References: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> Message-ID: <061.2cf503aa9e6c98548837a0d1e0ea36ff@haskell.org> #10182: lookupIfaceGlobal crash with SOURCE import -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: | https://phabricator.haskell.org/D860 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"1bd1ceffce7f3027ae632086844f95976ed600c8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1bd1ceffce7f3027ae632086844f95976ed600c8" Don't use self {-# SOURCE #-} import in test-cases. Summary: It's kind of buggy, c.f. #10182, and isn't motivated by any real world programs, so we're going to get rid of it (despite it being handy for GHC test cases.) Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D862 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 12:39:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 12:39:30 -0000 Subject: [GHC] #10182: lookupIfaceGlobal crash with SOURCE import In-Reply-To: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> References: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> Message-ID: <061.3848dce37e81acdf7e591479f7a09c71@haskell.org> #10182: lookupIfaceGlobal crash with SOURCE import -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: | https://phabricator.haskell.org/D860 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"a2f9fef1d90c073ad9c2a727c5ee617057ca6c1d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a2f9fef1d90c073ad9c2a727c5ee617057ca6c1d" Fix #10182 by disallowing/avoiding self {-# SOURCE #-} imports Summary: hs-boot declarations were leaking into the EPS due to self {-# SOURCE #-} imports, and interface loading induced by orphan instances. For the former, we simply disallow self {-# SOURCE #-} imports; for the latter, we simply just don't load an interface if it would be ourself. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D860 GHC Trac Issues: #10182 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 12:40:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 12:40:28 -0000 Subject: [GHC] #10182: lookupIfaceGlobal crash with SOURCE import In-Reply-To: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> References: <046.550b4f24a3d0ad98afcdf7a911ae1ef7@haskell.org> Message-ID: <061.9487b474ea8fbb554956443e51754c74@haskell.org> #10182: lookupIfaceGlobal crash with SOURCE import -------------------------------------+------------------------------------- Reporter: simonpj | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: | https://phabricator.haskell.org/D860 -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 13:04:53 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 13:04:53 -0000 Subject: [GHC] #10335: Failure to construct superclasses in instance In-Reply-To: <046.2ff0631e8c296e4b1559cc95f6a8eb9e@haskell.org> References: <046.2ff0631e8c296e4b1559cc95f6a8eb9e@haskell.org> Message-ID: <061.b0b149b5c9d537473b58dbc2915b0bcd@haskell.org> #10335: Failure to construct superclasses in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"646866ff318d6eb8beeed98032644182dd9d997b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="646866ff318d6eb8beeed98032644182dd9d997b" Fix superclass generation in an instance More fallout from the silent-superclass refactoring; nothing drastic. Fixes Trac #10335. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 13:04:53 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 13:04:53 -0000 Subject: [GHC] #10325: Clearify status of ImpredicativeTypes Extension In-Reply-To: <054.6d8491b4851bda6a5760a822edfce5be@haskell.org> References: <054.6d8491b4851bda6a5760a822edfce5be@haskell.org> Message-ID: <069.451774d248db2c1156fc68a39b13ab4c@haskell.org> #10325: Clearify status of ImpredicativeTypes Extension -------------------------------------+------------------------------------- Reporter: j80JjBjVNRMajmA | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9618, #10281 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c715166f9860635d84e4beaa76bf4e23ab764342/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c715166f9860635d84e4beaa76bf4e23ab764342" Improve error reporting for impredicative types Don't suggest -XImpredicativeTypes; and document its flakiness Fixes Trac #10325 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 13:04:53 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 13:04:53 -0000 Subject: [GHC] #10281: Type error with Rank-n-types In-Reply-To: <043.715543d69d09145192a2c9ffe2902dd1@haskell.org> References: <043.715543d69d09145192a2c9ffe2902dd1@haskell.org> Message-ID: <058.5006ebdb60e59b494c34d6aff0b8e2fd@haskell.org> #10281: Type error with Rank-n-types -------------------------------------+------------------------------------- Reporter: rhjl | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Peirce_eq_LEM.hs Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"746f086eae9e54ef9e02cf06b71c4f39e27617d5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="746f086eae9e54ef9e02cf06b71c4f39e27617d5" Better documetation of higher rank types In response to suggestions on Trac #10281 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 13:06:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 13:06:17 -0000 Subject: [GHC] #10281: Type error with Rank-n-types In-Reply-To: <043.715543d69d09145192a2c9ffe2902dd1@haskell.org> References: <043.715543d69d09145192a2c9ffe2902dd1@haskell.org> Message-ID: <058.0ac0be74ec71f4bdc121834a46c50c72@haskell.org> #10281: Type error with Rank-n-types -------------------------------------+------------------------------------- Reporter: rhjl | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Peirce_eq_LEM.hs Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: I've followed your suggestions more or less. Thank you! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 13:06:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 13:06:47 -0000 Subject: [GHC] #10325: Clearify status of ImpredicativeTypes Extension In-Reply-To: <054.6d8491b4851bda6a5760a822edfce5be@haskell.org> References: <054.6d8491b4851bda6a5760a822edfce5be@haskell.org> Message-ID: <069.6037807f7737635e56d65186fcd4139f@haskell.org> #10325: Clearify status of ImpredicativeTypes Extension -------------------------------------+------------------------------------- Reporter: j80JjBjVNRMajmA | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9618, #10281 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Done! Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 13:09:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 13:09:38 -0000 Subject: [GHC] #10335: Failure to construct superclasses in instance In-Reply-To: <046.2ff0631e8c296e4b1559cc95f6a8eb9e@haskell.org> References: <046.2ff0631e8c296e4b1559cc95f6a8eb9e@haskell.org> Message-ID: <061.947a2820544dbe723473435a6f35cd01@haskell.org> #10335: Failure to construct superclasses in instance -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_compile/T10335 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => typecheck/should_compile/T10335 Comment: Fixed, although the patch probably won't apply very nicely to 7.10.2, because it meddles with `TcEvidence` which has changed since 7.10. But this patch effectively reverts one of the changes to `TcEvidence` so while it won't apply automatically, it won't be hard either. I'm inclined to think it's worth merging. I can help. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 13:18:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 13:18:25 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.ccba6604b42d427f1a94cd634067251e@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a, | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"932f08677ca07f1793398e4c3456b81359728483/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="932f08677ca07f1793398e4c3456b81359728483" Test Trac #9858 comment:101 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 13:19:56 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 13:19:56 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.9c0dca12c7086b90d05c3dc5f1f0583f@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a,b,c; | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: typecheck/should_fail/T9858a, should_run/T9858b => typecheck/should_fail/T9858a,b,c; should_run/T9858b -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 13:20:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 13:20:42 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.a4382acff4437facd02c6a5b9d2a0cfd@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a,b,c; | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by simonpj): Are we finally done with this ticket? Can we close it? oerjan?! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 13:58:45 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 13:58:45 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.542a687386a319a47035f5da1f16ff8b@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a,b,c; | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by oerjan): Well I ''could'' continue to quibble about the current design's intrinsic lack of support for my strange test cases in the discussion of comments [comment:43] - [comment:47] and the IMO more reasonable one in comment [comment:79]. Of course I was trying to imagine maximal backwards compatibility there. However, I realize the current design is much less complicated, and apparently works for what people actually do. I don't see any further actual exploits at this time. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 14:24:19 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 14:24:19 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.bd684c77b69fc9e8d7170bfb5ef13682@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a,b,c; | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by simonpj): I think these examples will start to work when we get polykinded typeable, which is a consequence of what Richard is doing on his branch. What ''would'' be useful is if you produce a fresh set of test cases that you think should work, but don't. You can probably extract them from the 100 comments above, but I'd like to know what your short-list is! In fact make them into a new ticket, then we won't lose track. This one is too long and digressive now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 15:57:20 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 15:57:20 -0000 Subject: [GHC] #10342: Convert User Guide from DocBook to AsciiDoc Message-ID: <047.a035ea91c12271763d1f9dbbec183a42@haskell.org> #10342: Convert User Guide from DocBook to AsciiDoc -------------------------------------+------------------------------------- Reporter: dmbergey | Owner: dmbergey Type: task | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- See initial proposal and discussion on the mailing list: https://mail.haskell.org/pipermail/ghc-devs/2014-October/006599.html and the more recent call for volunteers: https://ghc.haskell.org/trac/ghc/blog/weekly20150414 Quoting the latter: the idea [is] that it will A) make life easier for people who frequently modify the users guide, and B) make life easier for people who add things irregularly, as a lower barrier to entry. I expect that asciidoc & DocBook can coexist while I work on this. After the initial changes to the build system, the docbook-to-HTML phase should read both the asciidoc-generated XML and the not-yet-converted XML files. This ticket will track progress on the task, as I plan to submit multiple patches, perhaps as many as one per file converted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 18:48:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 18:48:47 -0000 Subject: [GHC] #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module In-Reply-To: <046.ebf20f155e05760df4b4c62188044473@haskell.org> References: <046.ebf20f155e05760df4b4c62188044473@haskell.org> Message-ID: <061.097256562799fd4b88fe3c8280e434d9@haskell.org> #7672: boot file entities are sometimes invisible and are not (semantically) unified with corresponding entities in implementing module -------------------------------------+------------------------------------- Reporter: skilpat | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.4.2 checker) | Keywords: backpack Resolution: | Architecture: x86_64 Operating System: Linux | (amd64) Type of failure: GHC rejects | Test Case: valid program | Blocking: 10336 Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by ezyang): Removing the `filterOut` does not work. (insert more info here) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 18:50:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 18:50:23 -0000 Subject: [GHC] #10262: Improve documentation of module signatures In-Reply-To: <047.d5f9e11a25bfdcf531f13050a898429b@haskell.org> References: <047.d5f9e11a25bfdcf531f13050a898429b@haskell.org> Message-ID: <062.9d833f1fa3ca7a4f8377781a0550b755@haskell.org> #10262: Improve documentation of module signatures -------------------------------------+------------------------------------- Reporter: goldfire | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.11 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Thanks for the read-through. I think, eventually, the low level interface currently described in the manual will be completely subsumed by the new package language, so when we describe that language, it will probably answer many of your questions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 19:52:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 19:52:42 -0000 Subject: [GHC] #10334: __ctzdi2/si2/__clzdi2/si2 unknown symbols in ghc-prim on non-shared libs platform In-Reply-To: <046.e3ef261ac65799c1bb5faa4b0f1fb891@haskell.org> References: <046.e3ef261ac65799c1bb5faa4b0f1fb891@haskell.org> Message-ID: <061.c30b312c500befc69f3dbf84337b82c2@haskell.org> #10334: __ctzdi2/si2/__clzdi2/si2 unknown symbols in ghc-prim on non-shared libs platform -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by kgardas): Edward, thanks a lot for your reference to haskell/C ctz/clz implementations. This is good to have for reference and also for the comparison. I'm attaching my hack to enforce -shared-libgcc linking so both approaches may be compared and the best chosen. Thanks, Karel -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 22 22:58:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 22 Apr 2015 22:58:51 -0000 Subject: [GHC] #10297: Floating instance for Data.Fixed In-Reply-To: <047.6d0ff544700b8087a9f68c3a44a1bbc7@haskell.org> References: <047.6d0ff544700b8087a9f68c3a44a1bbc7@haskell.org> Message-ID: <062.8561a873da637bcee87763d740eace5e@haskell.org> #10297: Floating instance for Data.Fixed -------------------------------------+------------------------------------- Reporter: dmcclean | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1 Resolution: wontfix | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by dmcclean): * status: new => closed * resolution: => wontfix Comment: There are actually a few problems with this idea. Sorry for not discovering them before creating this ticket. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 00:48:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 00:48:03 -0000 Subject: [GHC] #10343: Make Typeable track kind information better Message-ID: <045.85e9bb0ccd5b9cbce8f9c98e97306bc2@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: 9858 Test Case: typeOf :: | Typeable (a::k) => Proxy a -> | TypeRep | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- With all the apparent exploitable bugs now fixed, #9858 seems to be settling down. Simon P.J. asked me to make a new ticket for some quibbles I still have with limitations of the new design. These started with some examples that I discussed there pre-implementation with Richard Eisenberg, and which he concluded could be supported by a "sufficently smart solver". In the new (current) design, a `TypeRep` ''does'' contain kind information, which as I understand it is a list of `KindRep`s for the explicit kind parameters applied to the type constructor after type inference. This is sufficient to prevent confusing the same type constructor used at different kinds, and also easily supports type application ''provided'' the `TypeRep`s of the parts are known. For this, the internal `Typeable` constraint solver only ever needs to combine `TypeRep`s, never decompose them. Since no one else complained in #9858, I assume this is enough for what people are currently using `Typeable` for. However: I think the current `TypeRep` representation for `Typeable (a :: k)` doesn't contain enough information to generally extract the `KindRep` for `k` itself, much less to decompose it, even if the internal `Typeable` solver were to try. This prevents some polykinded code that is intuitively sound, and which "worked" in the old system, although if only because it didn't try to track kinds at all. For example, the following expression, with `PolyKinds` enabled: {{{#!hs typeOf :: Typeable a => Proxy a -> TypeRep }}} In the old system, this worked simply by combining the `TypeRep` for `Proxy` with the `TypeRep` for `a`. But in the new system, it fails, because the `TypeRep` for `Proxy` needs to know the kind of `a`, which is neither statically known nor available from the `TypeRep` of `a`. You would need to have compile-time information about the type constructor of `a` to even know how to build the `KindRep` from the kind arguments. This problem with constructing `TypeRep`s would arise whenever a polykinded type constructor is applied to a type whose kind is not a known monomorphic one. The second similar one I can think of is {{{#!hs typeRep :: Typeable a => Proxy (Typeable a) -> TypeRep }}} In an ideal system, we can also find use cases that require not just extracting the `KindRep` for a type, but also decomposing it. Here is my very hypothetical kitchen sink example from [comment:46:ticket:9858] (this example was made up as a test case before I knew what the new solver would support): {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE AutoDeriveTypeable #-} import Data.Typeable newtype C a b = C () step :: Proxy (a :: [k] -> *) -> Proxy (C a :: [k -> *] -> *) step Proxy = Proxy nest :: Typeable (a :: [k] -> *) => Int -> Proxy a -> TypeRep nest 0 x = typeRep x nest n x = nest (n-1) (step x) main = print $ nest 10 (Proxy :: Proxy (C () :: [()] -> *)) }}} Here, to make this compile, the solver would need to derive `Typeable (C a :: [k -> *] -> *]` from `Typeable (a :: [k] -> *)`, which at runtime requires first extracting the `KindRep` of `k` from the `TypeRep` of `a`, and then building the `TypeRep` for the correctly kinded `C`. At least the former part seems essentially impossible with the current `TypeRep` representation, even with a more clever solver. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 00:53:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 00:53:10 -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.a92dda551eeed54afd073d77b400fdfa@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: typeOf :: Related Tickets: #9858 | Typeable (a::k) => Proxy a -> | TypeRep | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by oerjan): * related: 9858 => #9858 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 00:54:47 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 00:54:47 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.5df57881a288509b7f08d3e5878f6460@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T9858a,b,c; | should_run/T9858b | Blocking: | Differential Revisions: Phab:D652 -------------------------------------+------------------------------------- Comment (by oerjan): I made a new ticket #10343 for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 01:33:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 01:33:08 -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.eb884b05ea0b4c772dc454742a81724e@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: typeOf :: Related Tickets: #9858 | Typeable (a::k) => Proxy a -> | TypeRep | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by shachaf): * cc: shachaf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 02:19:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 02:19:06 -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.ea3faedc9f8ec9606a3a6f046e40c3e4@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: typeOf :: Related Tickets: #9858 | Typeable (a::k) => Proxy a -> | TypeRep | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): I agree that a `kindRep :: TypeRep -> TypeRep` or perhaps `kindRep :: Typeable a => proxy a -> TypeRep` is in order. It seems this is useful independent of kind equalities, though it will likely become more useful (and conspicuously missing if unimplemented) with kind equalities. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 02:22:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 02:22:11 -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.22a7207c30af966a7171f639d037be81@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: typeOf :: Related Tickets: #9858 | Typeable (a::k) => Proxy a -> | TypeRep | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Here's a strange thought: once we have `* :: *`, does `Typeable k a` imply `Typeable * k`? It probably should. But then we would have {{{ class Typeable k => Typeable (a :: k) where ... }}} which has a superclass cycle. The cycle is benign because we know that all kinds have type `*`, but it still is a curious beast. Of course, this isn't necessary, but it would be nice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 02:29:56 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 02:29:56 -0000 Subject: [GHC] #10344: Make BranchList simpler Message-ID: <047.38d0a43513b53be4914a5abdcd2c6771@haskell.org> #10344: Make BranchList simpler -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- As Adam Gundry suggested, `BranchList` could be made much simpler by actually storing a list in the `Branched` case. Though, as I'm thinking about it, what's better about a real list over a `BranchList`? We're more familiar with it... but perhaps adding a `Foldable` instance for `BranchList` would solve the problem. In any case, this ticket is to record the desire for improvement. If Adam is up to it, he may fix this with Phab:D841. Otherwise, I'll get to it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 05:48:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 05:48:24 -0000 Subject: [GHC] #10334: __ctzdi2/si2/__clzdi2/si2 unknown symbols in ghc-prim on non-shared libs platform In-Reply-To: <046.e3ef261ac65799c1bb5faa4b0f1fb891@haskell.org> References: <046.e3ef261ac65799c1bb5faa4b0f1fb891@haskell.org> Message-ID: <061.a91f70a9d93d5911bd1bfc1253682e8b@haskell.org> #10334: __ctzdi2/si2/__clzdi2/si2 unknown symbols in ghc-prim on non-shared libs platform -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by kgardas): * cc: kgardas (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 07:33:41 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 07:33:41 -0000 Subject: [GHC] #10329: ghc-7.10 is configured to use llvm-3.6 but only compiles with llvm-3.5 In-Reply-To: <044.7bb160d7a31f6091fc12e2d6f3a346bc@haskell.org> References: <044.7bb160d7a31f6091fc12e2d6f3a346bc@haskell.org> Message-ID: <059.2472c38cfc0534709154c4bd5e6f95e3@haskell.org> #10329: ghc-7.10 is configured to use llvm-3.6 but only compiles with llvm-3.5 -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D856 -------------------------------------+------------------------------------- Changes (by erikd): * differential: => Phab:D856 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 07:34:52 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 07:34:52 -0000 Subject: [GHC] #10292: Validate fails on armhf-linux In-Reply-To: <044.8055e40124ced0bf29d2dcf6e0c01c9f@haskell.org> References: <044.8055e40124ced0bf29d2dcf6e0c01c9f@haskell.org> Message-ID: <059.329cbba54c799f55171c065fe81127dc@haskell.org> #10292: Validate fails on armhf-linux ----------------------------------------+--------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+--------------------------------- Changes (by erikd): * status: new => closed * resolution: => duplicate Comment: The patch to detect this at configure time is in #10329 and Phab:D856 . -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 08:09:36 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 08:09:36 -0000 Subject: [GHC] #10345: Testsuite timeout_multiplier setting does not work as expected Message-ID: <048.e0092338ecde0e0050123f85c2695d0b@haskell.org> #10345: Testsuite timeout_multiplier setting does not work as expected -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Other Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I have a test case that - if failed - sends GHC into an infinite loop. The test case is small so I don't want to wait for default timeout (currently that's 5 minutes). The testsuite provides `timeout_multiplier` function to modify the default timeout but that setting seems to be ignored and the test is killed only after the default timeout time. I added my test to `all.T` file like this: {{{ test('tc265', timeout_multiplier(0.01), compile, ['']) }}} I also tried putting timeout setting into an array (`[timeout_multiplier(0.01)]`) but with no result. Merijn reports having same problems and bypassing them by writing a test that forks itself and kills the child process after a given timeout - see [[GhcFile(libraries/base/tests/T8089.hs)]]. I am adding a note on [[wiki:Building/RunningTests/Adding#Thesetupfield]] that this field does not work currently. Once this bug is fixed we need to remove that note. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 08:14:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 08:14:38 -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.f2a13d4efb3a5c9609342198931cf464@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: typeOf :: Related Tickets: #9858 | Typeable (a::k) => Proxy a -> | TypeRep | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I'm assuming that much of what Oerjan wants will "just work" once we have Richard's kind equalities. Right Richard? But not, perhaps, `kindRep` which I do not fully understand. I wonder if we might address `kindRep` as part of the overhaul sketched in [wiki:Typeable this wiki page about Typeable]? The plan there is to move to type-indexed type representations. * What would `kindRep` look in that context? * How would you use `kindRep`? A new subsection on that page might be useful. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 09:41:13 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 09:41:13 -0000 Subject: [GHC] #10346: Cross-module SpecConstr Message-ID: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> #10346: Cross-module SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Type-class specialisation now happens flawlessly across modules. That is, if I define {{{ module DefineF where f :: Num a => a -> a {-# INLINEABLE f #-} f x = ...f x'.... }}} then modules that import `DefineF` and call `f` at some particular type (say `Int`) will generate a specialised copy of `f`'s code. But this does not happen for `SpecConstr`; we only specialise a function for calls made in the same module. All the infrastructure is in place to allow cross-module `SpecConstr`; it just hasn't been done yet. This ticket is to record the idea. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 13:09:16 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 13:09:16 -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.5489c885e7cf41c93eda08e30247213f@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: typeOf :: Related Tickets: #9858 | Typeable (a::k) => Proxy a -> | TypeRep | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:5 simonpj]: > I'm assuming that much of what Oerjan wants will "just work" once we have Richard's kind equalities. Right Richard? > > But not, perhaps, `kindRep` which I do not fully understand. I'm not sure exactly what "much of what Oerjan wants" refers to, so I can't make a claim one way or the other. I can say that the feature requested in this ticket will ''not'' just work in my branch. The problem is that if we have a `TypeRep` for some time `a` of kind `k`, there is no way, at runtime, to extract a `TypeRep` for `k`. `TypeRep`s simply don't store enough information to do this. Fixing this should be straightforward, and I believe is totally orthogonal to anything dealing with my branch. (Well, not ''totally'' orthogonal, because in my branch `kindRep (kindRep <>)` is a `TypeRep` for `*`, and today it would be a `TypeRep` for `BOX`. But this matters little.) Coming up with an API design is a touch harder, but I don't think it should be too bad, and it remains independent from the `TTypeRep a` story. Oerjan, you're a (the?) client of all this. Propose an API design. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 13:52:30 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 13:52:30 -0000 Subject: [GHC] #10347: Spurious "unused constructor" warning with Coercible Message-ID: <047.95d70bb35e967b5051d311b602ee2dc7@haskell.org> #10347: Spurious "unused constructor" warning with Coercible -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect Unknown/Multiple | warning at compile-time Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE RoleAnnotations #-} module Bug (N, twiddle) where import Data.Coerce newtype N a = MkN Int type role N representational twiddle :: N a -> N b twiddle = coerce }}} I get {{{ Bug.hs:7:15: warning: Defined but not used: data constructor ?MkN? }}} But the constructor ''is'' used, in order to do the coercion. The role annotation is to force GHC to use the constructor to do the coercion -- otherwise, it might not have. This bug exists in 7.10 and in HEAD. I will fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 14:40:47 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 14:40:47 -0000 Subject: [GHC] #10347: Spurious "unused constructor" warning with Coercible In-Reply-To: <047.95d70bb35e967b5051d311b602ee2dc7@haskell.org> References: <047.95d70bb35e967b5051d311b602ee2dc7@haskell.org> Message-ID: <062.b641499ca4cc93e24df1d51d99894228@haskell.org> #10347: Spurious "unused constructor" warning with Coercible -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Turns out this is harder to fix than I thought. The problem is that usage information for locally defined things is in `tcg_dus :: [DefUse]` in the `TcGblEnv`. Deep within the solver, there is no way to change this field, and threading the information back up to the top seems horrendous. It seems the only way forward is to change `tcg_dus` to be a `TcRef [DefUse]`, but that makes me a bit sad. Any ideas? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 14:43:41 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 14:43:41 -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.977454f2bc7534a2440c15a6ab9d774e@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: typeOf :: Related Tickets: #9858 | Typeable (a::k) => Proxy a -> | TypeRep | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by oerjan): I am not sure I can be called a client, I don't have actual useful code hinging on this. As a hobbyist, I spend more time ''thinking'' about Haskell than actually programming in it. I think that simply adding `kindRep :: TypeRep -> TypeRep` as a field of `TypeRep` would make the necessary information available at runtime. This ought to fit just as well into the current design as into the proposed `TTypeRep` on the wiki. I also have a hunch this might make the already existing list of `KindRep`s redundant. The question of how to make the `Typeable` solver make use of that information for building kind evidence seems to me like the more complicated part of this. Just to prove it is possible in principle, I'll restate my mock representation from back in [comment:48:ticket:9858]: {{{ class (KindableParts a, a ~ Proxy) => Kindable (a :: k -> *) where type KindableParts a :: Constraint kindRep :: KindRep a class Kindable (Proxy :: k -> *) => Typeable (a :: k) where typeRep :: proxy a -> TypeRep }}} This worked well enough to be a basis for [http://oerjan.nvg.org/haskell/TypeableDesign/ running my kitchen sink test case] in 7.8.3. However, it doesn't support Richard's ideas for avoiding exposing "`Kindable`" constraints when doing type inference. And of course the representation's made for reusing already existing type features rather than for efficiency. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 14:44:23 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 14:44:23 -0000 Subject: [GHC] #10347: Spurious "unused constructor" warning with Coercible In-Reply-To: <047.95d70bb35e967b5051d311b602ee2dc7@haskell.org> References: <047.95d70bb35e967b5051d311b602ee2dc7@haskell.org> Message-ID: <062.3f350aa3b8746b6eba6750f6cca044bf@haskell.org> #10347: Spurious "unused constructor" warning with Coercible -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): In the example how could you ever construct a value of type `N a` (other than bottom)? You might add: {{{ makeN :: Int -> N a makeN = N }}} and bingo you've used `N`. So actually the error message seems somewhat reasonable to me. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 14:47:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 14:47:53 -0000 Subject: [GHC] #10347: Spurious "unused constructor" warning with Coercible In-Reply-To: <047.95d70bb35e967b5051d311b602ee2dc7@haskell.org> References: <047.95d70bb35e967b5051d311b602ee2dc7@haskell.org> Message-ID: <062.08ece040637a37774f56e45a6530b1a4@haskell.org> #10347: Spurious "unused constructor" warning with Coercible -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Good point. Here's a revised test case: {{{ module T10347 (N, mkN) where import Data.Coerce newtype N a = MkN Int mkN :: Int -> N a mkN = coerce }}} Now you ''can'' make an `N a`, but the warning still appears. This is actually much simpler than the original test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 14:48:35 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 14:48:35 -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.b77c719872732d786f42440440600b14@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: typeOf :: Related Tickets: #9858 | Typeable (a::k) => Proxy a -> | TypeRep | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I was using "what Oerjan wants" as shorthand for the Description of this ticket. For exmaple, he wants the expression {{{ typeRep :: Typeable a => Proxy a -> TypeRep }}} to typecheck. And it think it will when Richard is done. Similarly perhaps other items on his wish list above. Perhaps it would help to edit the description to enumerate "Wish 1", "Wish 2" etc? In "Wish n" he is asking for `kindRep`, for reasons I do not understand. Maybe you can give a use-case? And better still, what would it look like in the context of type-indexed type representations described in wiki:Typeable? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 15:50:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 15:50:12 -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.770a1f9ac3daccc37fb780a830b567a8@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: typeOf :: Related Tickets: #9858 | Typeable (a::k) => Proxy a -> | TypeRep | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by oerjan): I knew I shouldn't have rambled on so much in my post... the mention of extracting `KindRep` was not a direct wish, more my explanation of why the current design ''doesn't'' handle my test cases. As in, it would be needed to implement a solution to them. So I guess a shorter summary of what I want is in order: I want that the type inference and runtime representation should support constructing `Typeable (T :: k)`, even when `k` contains kind variables that are only mentioned in other `Typeable` constraints ''not'' necessarily involving the type constructor `T`. (This assumes that type application keeps working as well as it does. Type constructors are the base case which now sometimes doesn't work.) This is, as far as I can see, precisely what is needed to get things like `typeOf :: Typeable a => Proxy a -> TypeRep` or `typeRep :: Typeable a => Proxy (Typeable a) -> TypeRep` to work, but it would also enable much more contrived things like my kitchen sink example. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 15:59:23 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 15:59:23 -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.dfd56be480aab54d7061a367dab96d81@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: typeOf :: Related Tickets: #9858 | Typeable (a::k) => Proxy a -> | TypeRep | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by oerjan: Old description: > With all the apparent exploitable bugs now fixed, #9858 seems to be > settling down. Simon P.J. asked me to make a new ticket for some > quibbles I still have with limitations of the new design. These started > with some examples that I discussed there pre-implementation with Richard > Eisenberg, and which he concluded could be supported by a "sufficently > smart solver". > > In the new (current) design, a `TypeRep` ''does'' contain kind > information, which as I understand it is a list of `KindRep`s for the > explicit kind parameters applied to the type constructor after type > inference. This is sufficient to prevent confusing the same type > constructor used at different kinds, and also easily supports type > application ''provided'' the `TypeRep`s of the parts are known. For this, > the internal `Typeable` constraint solver only ever needs to combine > `TypeRep`s, never decompose them. > > Since no one else complained in #9858, I assume this is enough for what > people are currently using `Typeable` for. However: > > I think the current `TypeRep` representation for `Typeable (a :: k)` > doesn't contain enough information to generally extract the `KindRep` for > `k` itself, much less to decompose it, even if the internal `Typeable` > solver were to try. This prevents some polykinded code that is > intuitively sound, and which "worked" in the old system, although if only > because it didn't try to track kinds at all. > > For example, the following expression, with `PolyKinds` enabled: > > {{{#!hs > typeOf :: Typeable a => Proxy a -> TypeRep > }}} > > In the old system, this worked simply by combining the `TypeRep` for > `Proxy` with the `TypeRep` for `a`. But in the new system, it fails, > because the `TypeRep` for `Proxy` needs to know the kind of `a`, which is > neither statically known nor available from the `TypeRep` of `a`. You > would need to have compile-time information about the type constructor of > `a` to even know how to build the `KindRep` from the kind arguments. > > This problem with constructing `TypeRep`s would arise whenever a > polykinded type constructor is applied to a type whose kind is not a > known monomorphic one. The second similar one I can think of is > > {{{#!hs > typeRep :: Typeable a => Proxy (Typeable a) -> TypeRep > }}} > > In an ideal system, we can also find use cases that require not just > extracting the `KindRep` for a type, but also decomposing it. Here is my > very hypothetical kitchen sink example from [comment:46:ticket:9858] > (this example was made up as a test case before I knew what the new > solver would support): > > {{{#!hs > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE KindSignatures #-} > {-# LANGUAGE AutoDeriveTypeable #-} > > import Data.Typeable > > newtype C a b = C () > > step :: Proxy (a :: [k] -> *) -> Proxy (C a :: [k -> *] -> *) > step Proxy = Proxy > > nest :: Typeable (a :: [k] -> *) => Int -> Proxy a -> TypeRep > nest 0 x = typeRep x > nest n x = nest (n-1) (step x) > > main = print $ nest 10 (Proxy :: Proxy (C () :: [()] -> *)) > }}} > > Here, to make this compile, the solver would need to derive `Typeable (C > a :: [k -> *] -> *]` from `Typeable (a :: [k] -> *)`, which at runtime > requires first extracting the `KindRep` of `k` from the `TypeRep` of `a`, > and then building the `TypeRep` for the correctly kinded `C`. At least > the former part seems essentially impossible with the current `TypeRep` > representation, even with a more clever solver. New description: (EDIT: My long rambling seems to have been confusing, so a summary: I want that the type inference and runtime representation should support constructing Typeable (T :: k), even when k contains kind variables that are only mentioned in other Typeable constraints not necessarily involving the type constructor T. This will allow simple composition with polymorphic type constructors like `Proxy` and `Typeable` to work more naturally, but also more complicated things.) With all the apparent exploitable bugs now fixed, #9858 seems to be settling down. Simon P.J. asked me to make a new ticket for some quibbles I still have with limitations of the new design. These started with some examples that I discussed there pre-implementation with Richard Eisenberg, and which he concluded could be supported by a "sufficently smart solver". In the new (current) design, a `TypeRep` ''does'' contain kind information, which as I understand it is a list of `KindRep`s for the explicit kind parameters applied to the type constructor after type inference. This is sufficient to prevent confusing the same type constructor used at different kinds, and also easily supports type application ''provided'' the `TypeRep`s of the parts are known. For this, the internal `Typeable` constraint solver only ever needs to combine `TypeRep`s, never decompose them. Since no one else complained in #9858, I assume this is enough for what people are currently using `Typeable` for. However: I think the current `TypeRep` representation for `Typeable (a :: k)` doesn't contain enough information to generally extract the `KindRep` for `k` itself, much less to decompose it, even if the internal `Typeable` solver were to try. This prevents some polykinded code that is intuitively sound, and which "worked" in the old system, although if only because it didn't try to track kinds at all. For example, the following expression, with `PolyKinds` enabled: {{{#!hs typeOf :: Typeable a => Proxy a -> TypeRep }}} In the old system, this worked simply by combining the `TypeRep` for `Proxy` with the `TypeRep` for `a`. But in the new system, it fails, because the `TypeRep` for `Proxy` needs to know the kind of `a`, which is neither statically known nor available from the `TypeRep` of `a`. You would need to have compile-time information about the type constructor of `a` to even know how to build the `KindRep` from the kind arguments. This problem with constructing `TypeRep`s would arise whenever a polykinded type constructor is applied to a type whose kind is not a known monomorphic one. The second similar one I can think of is {{{#!hs typeRep :: Typeable a => Proxy (Typeable a) -> TypeRep }}} In an ideal system, we can also find use cases that require not just extracting the `KindRep` for a type, but also decomposing it. Here is my very hypothetical kitchen sink example from [comment:46:ticket:9858] (this example was made up as a test case before I knew what the new solver would support): {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE AutoDeriveTypeable #-} import Data.Typeable newtype C a b = C () step :: Proxy (a :: [k] -> *) -> Proxy (C a :: [k -> *] -> *) step Proxy = Proxy nest :: Typeable (a :: [k] -> *) => Int -> Proxy a -> TypeRep nest 0 x = typeRep x nest n x = nest (n-1) (step x) main = print $ nest 10 (Proxy :: Proxy (C () :: [()] -> *)) }}} Here, to make this compile, the solver would need to derive `Typeable (C a :: [k -> *] -> *]` from `Typeable (a :: [k] -> *)`, which at runtime requires first extracting the `KindRep` of `k` from the `TypeRep` of `a`, and then building the `TypeRep` for the correctly kinded `C`. At least the former part seems essentially impossible with the current `TypeRep` representation, even with a more clever solver. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 16:02:37 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 16:02:37 -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.e16045006ea38509c737a8daefca0604@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: typeOf :: Related Tickets: #9858 | Typeable (a::k) => Proxy a -> | TypeRep | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by oerjan: Old description: > (EDIT: My long rambling seems to have been confusing, so a summary: > > I want that the type inference and runtime representation should support > constructing Typeable (T :: k), even when k contains kind variables that > are only mentioned in other Typeable constraints not necessarily > involving the type constructor T. This will allow simple composition > with polymorphic type constructors like `Proxy` and `Typeable` to work > more naturally, but also more complicated things.) > > With all the apparent exploitable bugs now fixed, #9858 seems to be > settling down. Simon P.J. asked me to make a new ticket for some > quibbles I still have with limitations of the new design. These started > with some examples that I discussed there pre-implementation with Richard > Eisenberg, and which he concluded could be supported by a "sufficently > smart solver". > > In the new (current) design, a `TypeRep` ''does'' contain kind > information, which as I understand it is a list of `KindRep`s for the > explicit kind parameters applied to the type constructor after type > inference. This is sufficient to prevent confusing the same type > constructor used at different kinds, and also easily supports type > application ''provided'' the `TypeRep`s of the parts are known. For this, > the internal `Typeable` constraint solver only ever needs to combine > `TypeRep`s, never decompose them. > > Since no one else complained in #9858, I assume this is enough for what > people are currently using `Typeable` for. However: > > I think the current `TypeRep` representation for `Typeable (a :: k)` > doesn't contain enough information to generally extract the `KindRep` for > `k` itself, much less to decompose it, even if the internal `Typeable` > solver were to try. This prevents some polykinded code that is > intuitively sound, and which "worked" in the old system, although if only > because it didn't try to track kinds at all. > > For example, the following expression, with `PolyKinds` enabled: > > {{{#!hs > typeOf :: Typeable a => Proxy a -> TypeRep > }}} > > In the old system, this worked simply by combining the `TypeRep` for > `Proxy` with the `TypeRep` for `a`. But in the new system, it fails, > because the `TypeRep` for `Proxy` needs to know the kind of `a`, which is > neither statically known nor available from the `TypeRep` of `a`. You > would need to have compile-time information about the type constructor of > `a` to even know how to build the `KindRep` from the kind arguments. > > This problem with constructing `TypeRep`s would arise whenever a > polykinded type constructor is applied to a type whose kind is not a > known monomorphic one. The second similar one I can think of is > > {{{#!hs > typeRep :: Typeable a => Proxy (Typeable a) -> TypeRep > }}} > > In an ideal system, we can also find use cases that require not just > extracting the `KindRep` for a type, but also decomposing it. Here is my > very hypothetical kitchen sink example from [comment:46:ticket:9858] > (this example was made up as a test case before I knew what the new > solver would support): > > {{{#!hs > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE KindSignatures #-} > {-# LANGUAGE AutoDeriveTypeable #-} > > import Data.Typeable > > newtype C a b = C () > > step :: Proxy (a :: [k] -> *) -> Proxy (C a :: [k -> *] -> *) > step Proxy = Proxy > > nest :: Typeable (a :: [k] -> *) => Int -> Proxy a -> TypeRep > nest 0 x = typeRep x > nest n x = nest (n-1) (step x) > > main = print $ nest 10 (Proxy :: Proxy (C () :: [()] -> *)) > }}} > > Here, to make this compile, the solver would need to derive `Typeable (C > a :: [k -> *] -> *]` from `Typeable (a :: [k] -> *)`, which at runtime > requires first extracting the `KindRep` of `k` from the `TypeRep` of `a`, > and then building the `TypeRep` for the correctly kinded `C`. At least > the former part seems essentially impossible with the current `TypeRep` > representation, even with a more clever solver. New description: (EDIT: My long rambling seems to have been confusing, so a summary: I think that the type inference and runtime representation should support constructing `Typeable (T :: k)`, even when `k` contains kind variables that are only mentioned in other `Typeable` constraints not necessarily involving the type constructor `T`. This will allow simple composition with polymorphic type constructors like `Proxy` and `Typeable` to work more naturally, but also more complicated things.) With all the apparent exploitable bugs now fixed, #9858 seems to be settling down. Simon P.J. asked me to make a new ticket for some quibbles I still have with limitations of the new design. These started with some examples that I discussed there pre-implementation with Richard Eisenberg, and which he concluded could be supported by a "sufficently smart solver". In the new (current) design, a `TypeRep` ''does'' contain kind information, which as I understand it is a list of `KindRep`s for the explicit kind parameters applied to the type constructor after type inference. This is sufficient to prevent confusing the same type constructor used at different kinds, and also easily supports type application ''provided'' the `TypeRep`s of the parts are known. For this, the internal `Typeable` constraint solver only ever needs to combine `TypeRep`s, never decompose them. Since no one else complained in #9858, I assume this is enough for what people are currently using `Typeable` for. However: I think the current `TypeRep` representation for `Typeable (a :: k)` doesn't contain enough information to generally extract the `KindRep` for `k` itself, much less to decompose it, even if the internal `Typeable` solver were to try. This prevents some polykinded code that is intuitively sound, and which "worked" in the old system, although if only because it didn't try to track kinds at all. For example, the following expression, with `PolyKinds` enabled: {{{#!hs typeOf :: Typeable a => Proxy a -> TypeRep }}} In the old system, this worked simply by combining the `TypeRep` for `Proxy` with the `TypeRep` for `a`. But in the new system, it fails, because the `TypeRep` for `Proxy` needs to know the kind of `a`, which is neither statically known nor available from the `TypeRep` of `a`. You would need to have compile-time information about the type constructor of `a` to even know how to build the `KindRep` from the kind arguments. This problem with constructing `TypeRep`s would arise whenever a polykinded type constructor is applied to a type whose kind is not a known monomorphic one. The second similar one I can think of is {{{#!hs typeRep :: Typeable a => Proxy (Typeable a) -> TypeRep }}} In an ideal system, we can also find use cases that require not just extracting the `KindRep` for a type, but also decomposing it. Here is my very hypothetical kitchen sink example from [comment:46:ticket:9858] (this example was made up as a test case before I knew what the new solver would support): {{{#!hs {-# LANGUAGE PolyKinds #-} {-# LANGUAGE DataKinds #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE AutoDeriveTypeable #-} import Data.Typeable newtype C a b = C () step :: Proxy (a :: [k] -> *) -> Proxy (C a :: [k -> *] -> *) step Proxy = Proxy nest :: Typeable (a :: [k] -> *) => Int -> Proxy a -> TypeRep nest 0 x = typeRep x nest n x = nest (n-1) (step x) main = print $ nest 10 (Proxy :: Proxy (C () :: [()] -> *)) }}} Here, to make this compile, the solver would need to derive `Typeable (C a :: [k -> *] -> *]` from `Typeable (a :: [k] -> *)`, which at runtime requires first extracting the `KindRep` of `k` from the `TypeRep` of `a`, and then building the `TypeRep` for the correctly kinded `C`. At least the former part seems essentially impossible with the current `TypeRep` representation, even with a more clever solver. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 17:10:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 17:10:48 -0000 Subject: [GHC] #10304: Bump Cabal submodule In-Reply-To: <044.a4b102a135e23cf08c42735959b0946a@haskell.org> References: <044.a4b102a135e23cf08c42735959b0946a@haskell.org> Message-ID: <059.b7fce1f78d9a325ef8319ce58493191c@haskell.org> #10304: Bump Cabal submodule -------------------------------------+------------------------------------- Reporter: luite | Owner: hvr Type: task | Status: closed Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * status: merge => closed * resolution: => fixed Comment: merged via c09f4f8015b29e723f057d0e1abb4bde611a55f6 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 17:17:04 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 17:17:04 -0000 Subject: [GHC] #10348: HEAD: `KnownNat` does not imply `Typeable` any more Message-ID: <048.ff1a869a9f49b350fedd8659480a4b6d@haskell.org> #10348: HEAD: `KnownNat` does not imply `Typeable` any more -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- As Iavor confirmed (https://mail.haskell.org/pipermail/ghc- devs/2015-April/008885.html) there is a regression on HEAD relative to `ghc-7.11.20150215`. Here is a reproduction snippet: {{{#!hs {-# LANGUAGE AutoDeriveTypeable, GADTs, DataKinds, KindSignatures, StandaloneDeriving #-} import GHC.TypeLits import Data.Typeable data Foo (n :: Nat) where Hey :: KnownNat n => Foo n deriving instance Show (Foo n) data T t where T :: (Show t, Typeable t) => t -> T t deriving instance Show (T n) }}} With ghci-7.11.20150407 I now see more constraints {{{ *Main> :t T Hey T Hey :: (Typeable n, KnownNat n) => T (Foo n) }}} OTOH ghci-7.11.20150215 only wanted `KnownNat`: {{{ *Main> :t T Hey T Hey :: KnownNat n => T (Foo n) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 18:21:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 18:21:44 -0000 Subject: [GHC] #10338: GHC Forgets Constraints In-Reply-To: <047.e9cb1bcfe02024f21718f3ccf843982b@haskell.org> References: <047.e9cb1bcfe02024f21718f3ccf843982b@haskell.org> Message-ID: <062.033249a7e246118fd0944151ee332b56@haskell.org> #10338: GHC Forgets Constraints -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): The fact that the binding of `fromScalar'` is a local one is not actually important here: the program with {{{ instance (Functor t, Num r) => T t r fromScalar' a = fromScalar a -- or turn on NoMonomorphismRestriction convert :: (T t (F r)) => Foo t r -> Foo t r convert (Scalar c) = Foo $ fromScalar' $ toF c }}} also gives the error about "Could not deduce (Num (F r)) arising from a use of ?fromScalar'?". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 18:48:04 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 18:48:04 -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.fc68dde87c5ea748eb190250f57ea10b@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: typeOf :: Related Tickets: #9858 | Typeable (a::k) => Proxy a -> | TypeRep | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * owner: => goldfire * milestone: => 7.12.1 Comment: This all continues to seem straightforward to me, but I maintain (in contrast to Simon's claim in comment:8) that this is separate from kind equalities. My implementation approach would be, as oerjan suggests, adding a `kindRep` field in `TypeRep`. This can be done today. Then, define {{{ class Typeable k => Typeable (a :: k) where ... -- probably not possible until I merge }}} This appears to be a superclass cycle, but we know it doesn't induce infinite regress because the kind of a kind is always `*`. So, we arrange to have this definition accepted. Then, the solver will just do the right thing. When we have a given `Typeable (a :: k)` constraint, the solver will spit off a `Typeable (k :: *)` constraint. We may have to arrange for the solver not to then spit off a (harmless, but potentially confusing) `Typeable (* :: *)` constraint. To work with `typeOf :: Typeable a => Proxy a -> TypeRep`... well it will all just work. Typechecking this expression leads to {{{ [G] Typeable (a :: k) [W] Typeable (Proxy (a :: k)) }}} After a little work, the solver arrives at {{{ [G] Typeable (a :: k) [G] Typeable (k :: *) [W] Typeable (Proxy :: k -> *) -- the Typeable solver doesn't decompose kind applications [W] Typeable (a :: k) }}} The wanteds are easily solved from the givens. Since I'm the one with the plan, sounds like I should be the one to execute the plan. But probably only after I merge, since this isn't something we need today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 19:31:04 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 19:31:04 -0000 Subject: [GHC] #10348: HEAD: `KnownNat` does not imply `Typeable` any more In-Reply-To: <048.ff1a869a9f49b350fedd8659480a4b6d@haskell.org> References: <048.ff1a869a9f49b350fedd8659480a4b6d@haskell.org> Message-ID: <063.47cdfa2f86b38a3d3197fb854302800e@haskell.org> #10348: HEAD: `KnownNat` does not imply `Typeable` any more -------------------------------------+------------------------------------- Reporter: heisenbug | Owner: diatchki Type: bug | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => diatchki * priority: normal => highest * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 19:34:52 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 19:34:52 -0000 Subject: [GHC] #10338: GHC Forgets Constraints In-Reply-To: <047.e9cb1bcfe02024f21718f3ccf843982b@haskell.org> References: <047.e9cb1bcfe02024f21718f3ccf843982b@haskell.org> Message-ID: <062.d255ad7d4cf7f94ce40ab1e9107c62da@haskell.org> #10338: GHC Forgets Constraints -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): But that's very reasonable isn't it? What type do you expect to be inferred for `fromScalar'`? Well, you get a constraint `T t r` arising from the call to `fromScalar` in its RHS, and GHC solves that constraint using the instance declaration, so we get the inferred type {{{ fromScalar' :: (Functor t, Num r) => r -> t r }}} And now you can see why you get the complaint when it's called in `convert`. What did you think would happen? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 20:17:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 20:17:06 -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.72a15973b5db6293ade61921ec83612e@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: typeOf :: Related Tickets: #9858 | Typeable (a::k) => Proxy a -> | TypeRep | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Can I make two pleas? 1. Could we cast this discussion in the language of type-indexed type representations `TTypeRep`, in [wiki:Typeable]? A `TTypeRep a` is very like `Typeable a`, but has the very great merit of being an ordinary data value. `Typeable a` is just the implicit version of it. You can get from one to the other via `tTypeRep`: {{{ class Typeable a where tTypeRep :: TTypeRep a }}} By using an ordinary data value we get away from talking about classes or superclasses or solvers or whatnot. Once we know, with forensic precision, what `TTypeable a` should do, then we can think about how the solver might generate `Typeable a` dictionaries, which are simply containers for a `TTypeable a` value. 2. Can we keep `TTypeRep` abstract, so instead of talking about what it "contains" we speak entirely in terms of what functions are available over it? `decomposeFun` is one such function. Now, for `kindRep` I think you are asking for a function {{{ kindRep :: forall (a::k). TTypeRep a -> TTypeRep k }}} And indeed it seems plausible that we should provide such a function, although I have seen no examples whatsoever of why it might be useful. (Producing a `TypeRep` only to print it does not count; there are easier ways of producing that sequence of characters.) I'm afraid I found the summary entirely opaque "The type inference and runtime representation should support constructing `Typeable (T :: k)`, even when ``k contains kind variables that are only mentioned in other `Typeable` constraints not necessarily involving the type constructor `T`. This will allow simple composition with polymorphic type constructors like `Proxy` and `Typeable` to work more naturally, but also more complicated things." What do you mean by "simple composition"? What do you mean by "more complicated things"? Don't answer directly: rather, just give a sequence of examples that you think should work. That will ''show'' me what "simple composition" means, rather than ''telling'' me! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 20:32:11 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 20:32:11 -0000 Subject: [GHC] #10347: Spurious "unused constructor" warning with Coercible In-Reply-To: <047.95d70bb35e967b5051d311b602ee2dc7@haskell.org> References: <047.95d70bb35e967b5051d311b602ee2dc7@haskell.org> Message-ID: <062.966d29fbdd262c95792da145488e0c74@haskell.org> #10347: Spurious "unused constructor" warning with Coercible -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Meh. Good point. I think this might signal a re-evaluation of the whole `DefUse` thing, which is quite complicated to manage, and isn't paying its way. For top-level-bound things, something more like `tcg_used_rdrnames` (but for `Name`s) might work better. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 20:34:44 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 20:34:44 -0000 Subject: [GHC] #10321: GHC.TypeLits.Nat types no longer fully simplified. In-Reply-To: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> References: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> Message-ID: <061.06e9be75ced257b34b49b0825b13665a@haskell.org> #10321: GHC.TypeLits.Nat types no longer fully simplified. -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: TypeLits Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => infoneeded Comment: It's hard to get this right. Consider this example: {{{ type LotsOf a = (a,a,a,a,a,a,a,a,a,a) data Foo a where MkFoo :: a -> Foo (LotsOf a) }}} If I say `:t MkFoo True`, I get `MkFoo True :: Foo (LotsOf Bool)`. That's better than if `LotsOf` had gotten expanded out. This is the same behavior as what you're seeing. GHC sees that the return type of `:>` is `Vec (n + 1) a`, so it figures out what `n` is and reports the type in the way it does. What it sounds like you want is for GHC to then normalize the type. I'm not saying that normalizing the type here is wrong, just that it's not always right. GHC, in general, tries not to evaluate types any more than it has to. In fact, upon further inspection, I'm surprised that GHC does what you want in the bound-variable case, or that it worked previously. Bottom line: can you propose a mechanism to sort this out? Simplify only type-lits operators? Simplify type families but not type synonyms? Simplify everything (this would be a big change from current behavior)? When printing, simplify, and print out the either the simplified type or the original type, depending on what has fewer nodes in its AST? Perhaps we can do what you want, but we need a specification of what you want first. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 21:12:26 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 21:12:26 -0000 Subject: [GHC] #9539: TQueue can lead to thread starvation In-Reply-To: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> References: <045.f4dc0af39dea75bc36dee0474a4ea69f@haskell.org> Message-ID: <060.c264b566a67dfee8f03770271cf31d37@haskell.org> #9539: TQueue can lead to thread starvation -------------------------------------+------------------------------------- Reporter: jwlato | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.8.2 Resolution: | Keywords: stm Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jonsterling): Is there any update on this ticket? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 21:35:21 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 21:35:21 -0000 Subject: [GHC] #10321: GHC.TypeLits.Nat types no longer fully simplified. In-Reply-To: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> References: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> Message-ID: <061.473c928111a23e152371c4a8caf9fc24@haskell.org> #10321: GHC.TypeLits.Nat types no longer fully simplified. -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: TypeLits Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I looked at this too. Turns out that we do normalise types for inferred let-bindings; see line 661 of `TcBinds`, the call to `normaliseType` in `mkInferredPolyId`. The explanation there is "to make the type as simple as possible". See commit `a6e7654b`. It doesn't mention a Trac ticket. So I think our guess is that normalising is usually the Right Thing. It seems inconsistent not to do it here too. If we want to, the spot is in `TcRnDriver.tcRnExpr` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 22:23:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 22:23:08 -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.916db63587f00a696d0b40afa3c880a2@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: typeOf :: Related Tickets: #9858 | Typeable (a::k) => Proxy a -> | TypeRep | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by int-e): * cc: int-e (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 23 22:55:49 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 23 Apr 2015 22:55:49 -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.406046d6027ced82b7a241770cf3cf3c@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: typeOf :: Related Tickets: #9858 | Typeable (a::k) => Proxy a -> | TypeRep | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:12 goldfire]: > This all continues to seem straightforward to me, but I maintain (in contrast to Simon's claim in comment:8) that this is separate from kind equalities. Whew, I was starting to worry. > {{{ > [G] Typeable (a :: k) > [G] Typeable (k :: *) > [W] Typeable (Proxy :: k -> *) -- the Typeable solver doesn't decompose kind applications > [W] Typeable (a :: k) > }}} > > The wanteds are easily solved from the givens. Looks good, although note that as we discussed in #9858, the kitchen sink example ''would'' require actually decomposing `Typeable` kinds. In principle so does normal type application, once you include `kindRep`: {{{ (Typeable (a :: k1 -> k2), Typeable (b :: k1)) => Typeable (a b :: k2) }}} The only plausible source for the `kindRep` of `a b` is to decompose the kind information in `Typeable a`. Although I guess type application can still be a special case. > Since I'm the one with the plan, sounds like I should be the one to execute the plan. But probably only after I merge, since this isn't something we need today. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 00:10:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 00:10:22 -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.83b4a6b20651b111bd582399ee1fd626@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: typeOf :: Related Tickets: #9858 | Typeable (a::k) => Proxy a -> | TypeRep | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:13 simonpj]: I made a long reply, forgot to copy to clipboard before submitting, and had trac give me an error message involving TLS, forgetting everything. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 00:40:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 00:40:17 -0000 Subject: [GHC] #10289: compiling huge HashSet hogs memory In-Reply-To: <044.7a75381e3cbd52797d1fc50b07f81ee0@haskell.org> References: <044.7a75381e3cbd52797d1fc50b07f81ee0@haskell.org> Message-ID: <059.be1712fafd4d5c70065c6fc337520a5e@haskell.org> #10289: compiling huge HashSet hogs memory -------------------------------------+------------------------------------- Reporter: zudov | Owner: Type: bug | Status: new Priority: normal | Milestone: 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 Revisions: -------------------------------------+------------------------------------- Comment (by zudov): > What happens if you don't have the call to `S.fromList`? This compiles fine with `-O2`. However if I use `-O0 -fno-ignore- interface-pragmas` then memory consumption goes high again. That seems a little strange to me. How do you think, is it a right way to reproduce the problem without depending on unordered-containers (if it is, then we probably can just experiment with list and come back to `HashSet` later)? I tried to observe the behaviour of a smaller list compilation with `-ddump-inlinings`: - Compilation with `-O2 -ddump-inlinings` reports inlining of `Data.Text.pack` and `GHC.Base.build` on each element - Compilation with `-O0 -ddump-inlinings` reports inlining of: - `Data.Text.pack` - `Data.Text.Internal.Fusion.unstream` - `Data.Text.Internal.Fusion.Common.map` - `Data.Text.Internal.Fusion.Common.streamList` - `Data.Text.Internal.safe` - `Data.Text.Internal.Fusion.Types.$WYield` Please suggest if it makes sense to dig into that direction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 01:22:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 01:22:41 -0000 Subject: [GHC] #10189: explicit promotions of prefix data constructors can't be parsed naturally In-Reply-To: <048.7a1fa374089d49b55ac4c378c43baf5b@haskell.org> References: <048.7a1fa374089d49b55ac4c378c43baf5b@haskell.org> Message-ID: <063.4e84ce1e7ba0e731d9ea20c9ace9c1b1@haskell.org> #10189: explicit promotions of prefix data constructors can't be parsed naturally -------------------------------------+------------------------------------- Reporter: Kinokkory | Owner: Kinokkory Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10188 | -------------------------------------+------------------------------------- Old description: > When used as an infix operator, a data constructor is explicitly promoted > simply with `'` prefixed, but when used as a prefix operator enclosed > between `(` and `)`, it is explicitly promoted only with `'` put before > `(`, not before the constructor. > > On the other hand, messages of GHC and GHCi indicate that a data > constructor operator in a prefix form is promoted by putting `'` before > the constructor! (as in `forall (k :: BOX) (k :: BOX). (':*)` below.) > > I believe that this is a matter of parsing. The parser should admit > `(':*)` as well as `'(:*)` for the naturalness of the syntax. > > In a GHCi: > > {{{#!hs > > :set -XDataKinds -XTypeOperators > > data a :* b = a :* b > > :kind! Int :* Int > Int :* Int :: * > = Int :* Int > > :kind! Int ':* Int > Int ':* Int :: * :* * > = Int ':* Int > > :kind! (:*) > (:*) :: * -> * -> * > = (:*) > > :kind! '(:*) > '(:*) :: k -> k1 -> k :* k1 > = forall (k :: BOX) (k :: BOX). (':*) > > :kind! (':*) > > :1:3: parse error on input ?:*? > }}} > > (By the way I assume that Template Haskell quotes (`'function` and > `''Type`) are parsed by the same mechanism as the one for the explicit > promotion syntax. I hope both styles of quotes for prefix operators will > be admitted because currently only the `'(` `''(` style is admitted.) New description: When used as an infix operator, a data constructor is explicitly promoted simply with `'` prefixed, but when used as a prefix operator enclosed between `(` and `)`, it is explicitly promoted only with `'` put before `(`, not before the constructor. On the other hand, messages of GHC and GHCi indicate that a data constructor operator in a prefix form is promoted by putting `'` before the constructor! (as in `forall (k :: BOX) (k :: BOX). (':*)` below.) I believe that this is a matter of parsing. The parser should admit `(':*)` as well as `'(:*)` for the naturalness of the syntax. In a GHCi: {{{#!hs > :set -XDataKinds -XTypeOperators > data a :* b = a :* b > :kind! Int :* Int Int :* Int :: * = Int :* Int > :kind! Int ':* Int Int ':* Int :: * :* * = Int ':* Int > :kind! (:*) (:*) :: * -> * -> * = (:*) > :kind! '(:*) '(:*) :: k -> k1 -> k :* k1 = forall (k :: BOX) (k :: BOX). (':*) > :kind! (':*) :1:3: parse error on input ?:*? }}} -- Comment (by Kinokkory): (Removed the mention about Template Haskell syntax.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 01:27:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 01:27:08 -0000 Subject: [GHC] #10347: Spurious "unused constructor" warning with Coercible In-Reply-To: <047.95d70bb35e967b5051d311b602ee2dc7@haskell.org> References: <047.95d70bb35e967b5051d311b602ee2dc7@haskell.org> Message-ID: <062.5a92fdd35e7e2491cd458e95569c1c35@haskell.org> #10347: Spurious "unused constructor" warning with Coercible -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * owner: goldfire => Comment: In that case, I'm forgoing ownership of the ticket. Perhaps once my branch is merged, I'll have the energy to look at a redesign of the whole `DefUse` thing, but not now. In any case, this only happened while building a test case -- not in "real code" -- so I don't think it's too important. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 01:32:54 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 01:32:54 -0000 Subject: [GHC] #10321: GHC.TypeLits.Nat types no longer fully simplified. In-Reply-To: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> References: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> Message-ID: <061.0509ca65e6697879edf7f140c09d4d20@haskell.org> #10321: GHC.TypeLits.Nat types no longer fully simplified. -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: TypeLits Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): But yet we take (significant) pains not to look through type synonyms when reporting errors... we even avoid looking through type synonyms when normalizing! So, is the general idea that vanilla type synonyms are preferred over their RHSs, but reducing type families is better than leaving them unreduced? Perhaps. I have no objection to this. It is a little odd that changing a vanilla type synonym to a closed type family with one (universal) equation would change behavior, but this is all pretty- printing and heuristic anyway, so that's not too bad. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 02:14:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 02:14:46 -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.46ff8240fe472fb89e19c839b9e8bd0f@haskell.org> #10284: Create a dedicated `TypeError` exception type -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: kanetw Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by kanetw): * owner: => kanetw -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 02:16:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 02:16:48 -0000 Subject: [GHC] #10141: Kind inference regression in closed type families In-Reply-To: <047.0645604fc6dcb528cffc10034076546d@haskell.org> References: <047.0645604fc6dcb528cffc10034076546d@haskell.org> Message-ID: <062.acca2bf52ded0356a4a7124b91e65dd0@haskell.org> #10141: Kind inference regression in closed type families -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): I've added a (not-yet-pushed) test case, but it's hard to see how to improve error messages. The problem is that the place that generates the kind errors is far from where we know whether or not we have a CUSK. I attempted to use `addErrCtxt` to include a note about CUSKs before kind- checking, but this note got appended to lots of errors that are clearly unrelated to CUSKs -- this is the wrong approach. I think the right approach is to somehow record in `TcM` that we're kind-checking a declaration which could potentially have a CUSK but in fact does not and then look there before reporting certain errors. But this is terribly heavy. Perhaps after my branch is merged, a way forward will present itself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 07:33:43 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 07:33:43 -0000 Subject: [GHC] #10321: GHC.TypeLits.Nat types no longer fully simplified. In-Reply-To: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> References: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> Message-ID: <061.ec8337b3bfd17ce05d28d5c4b21df879@haskell.org> #10321: GHC.TypeLits.Nat types no longer fully simplified. -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: TypeLits Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by darchon): Replying to [comment:2 goldfire]: > This is the same behavior as what you're seeing. GHC sees that the return type of `:>` is `Vec (n + 1) a`, so it figures out what `n` is and reports the type in the way it does. What it sounds like you want is for GHC to then normalize the type. > > I'm not saying that normalizing the type here is wrong, just that it's not always right. GHC, in general, tries not to evaluate types any more than it has to. In fact, upon further inspection, I'm surprised that GHC does what you want in the bound-variable case, or that it worked previously. I would've found it more understandable if the reported type was `Vec (((0 + 1) + 1) + 1) a`, why is the `n` part normalised to `2`? in stead of being left `((0+1)+1)`? That was the behaviour in GHC 7.6.1: {{{ ~/devel/test$ ghci example/vec.hs GHCi, version 7.6.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Main ( vec.hs, interpreted ) Ok, modules loaded: Main. *Main> :t (1:>2:>3:>Nil) (1:>2:>3:>Nil) :: Num a => Vec (((0 + 1) + 1) + 1) a }}} I was mostly confused that we started fully normalising type families in 7.8, but now suddenly in 7.10 only normalise until we reach the outermost applied type family. > Bottom line: can you propose a mechanism to sort this out? Simplify only type-lits operators? Simplify type families but not type synonyms? Simplify everything (this would be a big change from current behavior)? When printing, simplify, and print out the either the simplified type or the original type, depending on what has fewer nodes in its AST? I think we should have: either the behaviour of 7.6.1: don't normalise, or of 7.8.3: fully normalise. I personally prefer the 7.8 behaviour (the reported type in case of using the typelits operators is smaller and more readable), especially as that already seems what we do for bound variables. Replying to [comment:3 simonpj]: > So I think our guess is that normalising is usually the Right Thing. It seems inconsistent not to do it here too. If we want to, the spot is in `TcRnDriver.tcRnExpr`. I'll have a look and see if normalising type families in `tcRnExpr` breaks anything, and then submit a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 07:57:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 07:57:18 -0000 Subject: [GHC] #10349: ghc-7.10.1.20150414 fails to configure on aarch64 with ld.gold: cannot compute sizeof (long long) Message-ID: <050.b2bda73e05f137b74a9fce82204befb8@haskell.org> #10349: ghc-7.10.1.20150414 fails to configure on aarch64 with ld.gold: cannot compute sizeof (long long) -------------------------------------+------------------------------------- Reporter: | Owner: juhpetersen | Status: new Type: bug | Milestone: 7.10.2 Priority: normal | Version: 7.10.1 Component: Build | Operating System: Linux System | Type of failure: Building GHC Keywords: | failed Architecture: aarch64 | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- On Fedora at least, the ghc-7.10 branch (as of yesterday) fails to configure on aarch64 when using ld.gold: {{{ checking size of long long... configure: error: in `/builddir/build/BUILD/ghc-7.10.1.20150414': configure: error: cannot compute sizeof (long long) }}} Gdb says: {{{ (gdb) r Starting program: /home/petersen/conftest During startup program terminated with signal SIGKILL, Killed. }}} Compiling the conftest.c attached with -fuse-ld=gold causes it to crash when run. {{{ $ gcc -o conftest conftest.c $ ./conftest $ gcc -o conftest -fuse-ld=gold conftest.c $ ./conftest Killed $ }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 08:03:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 08:03:51 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.811bc58d534d5835e6e100f91126f5a4@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Still to push as interim measure: an improvement to the error message. Edward has a patch or this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 08:05:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 08:05:08 -0000 Subject: [GHC] #10349: ghc-7.10.1.20150414 fails to configure on aarch64 with ld.gold: cannot compute sizeof (long long) In-Reply-To: <050.b2bda73e05f137b74a9fce82204befb8@haskell.org> References: <050.b2bda73e05f137b74a9fce82204befb8@haskell.org> Message-ID: <065.2ec0a7ed8f98994244a99b6bb9e01240@haskell.org> #10349: ghc-7.10.1.20150414 fails to configure on aarch64 with ld.gold: cannot compute sizeof (long long) ----------------------------------------+---------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Build System | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by juhpetersen): ld.gold supports on aarch64 needs the patches from D856 and D858. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 09:13:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 09:13:38 -0000 Subject: [GHC] #10077: Providing type checker plugin on command line results in false cyclic import error In-Reply-To: <047.782b0d33638d12045ffab180b13fe3e7@haskell.org> References: <047.782b0d33638d12045ffab180b13fe3e7@haskell.org> Message-ID: <062.3d787a2f30fa8f81daf1adc62c9f18c6@haskell.org> #10077: Providing type checker plugin on command line results in false cyclic import error -------------------------------------+------------------------------------- Reporter: jbracker | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | typechecker plugin cycle imports Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect | (amd64) warning at compile-time | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by adamgundry): Replying to [comment:7 ezyang]: > Isn't the case here that, when GHC attempts to compile a plugin, it shouldn't use the `-fplugin` arguments for the compilation? Simple stage restriction: you can't use a plugin on itself. That's true, but I'm not quite sure what you're suggesting: do you mean that GHC should silently ignore the `-fplugin` argument when compiling the plugin itself (and its dependencies)? I guess that would be more convenient in this case, although I imagine it would be counterintuitive in other cases (e.g. if you were trying to use a plugin on a module without realising the plugin depended on that module). Perhaps those other cases are sufficiently obscure that it is worth doing, and could perhaps be combined with turning on `-dynamic` automatically. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 09:15:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 09:15:04 -0000 Subject: [GHC] #10260: last uses too much space with optimizations disabled In-Reply-To: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> References: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> Message-ID: <062.daaa35e2132d409b5a6ca15035e1f9d3@haskell.org> #10260: last uses too much space with optimizations disabled -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D847 -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"524ddbdad5816f77b7b719cac0671eebd3473616/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="524ddbdad5816f77b7b719cac0671eebd3473616" Make sure GHC.List.last is memory-efficient by eta-expanding its definition so that GHC optmizes the foldl here. Also make sure that other uses of last go via foldl as well, to allow list fusion (tested in T9339). Fixes #10260. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 09:17:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 09:17:01 -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.f9020ddaecb37b6720caa0d24371145b@haskell.org> #10284: Create a dedicated `TypeError` exception type -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: kanetw Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) Comment: I think this is a good idea. kanetw, thanks very much for working on this and #10283! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 09:20:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 09:20:27 -0000 Subject: [GHC] #10260: last uses too much space with optimizations disabled In-Reply-To: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> References: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> Message-ID: <062.d53373e80c70af368928d2ef95e844ea@haskell.org> #10260: last uses too much space with optimizations disabled -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: closed Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D847 -------------------------------------+------------------------------------- Changes (by nomeata): * status: patch => closed * resolution: => fixed Comment: Fixing this, as `last` works as intended now. Further discussion about a more general solution can happen at #10319. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 09:20:54 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 09:20:54 -0000 Subject: [GHC] #10321: GHC.TypeLits.Nat types no longer fully simplified. In-Reply-To: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> References: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> Message-ID: <061.349dd73de7ff4e3559f03726fe3831de@haskell.org> #10321: GHC.TypeLits.Nat types no longer fully simplified. -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: TypeLits Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 09:26:47 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 09:26:47 -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.78096487a9304c29197bfbf7d9a1f797@haskell.org> #10284: Create a dedicated `TypeError` exception type -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: kanetw Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: phab:D866 -------------------------------------+------------------------------------- Changes (by kanetw): * status: new => patch * differential: => phab:D866 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 10:03:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 10:03:04 -0000 Subject: [GHC] #10349: ghc-7.10 fails to configure on aarch64 with ld.gold: cannot compute sizeof (long long) (was: ghc-7.10.1.20150414 fails to configure on aarch64 with ld.gold: cannot compute sizeof (long long)) In-Reply-To: <050.b2bda73e05f137b74a9fce82204befb8@haskell.org> References: <050.b2bda73e05f137b74a9fce82204befb8@haskell.org> Message-ID: <065.28b574416a831358173ffc2be33e9e34@haskell.org> #10349: ghc-7.10 fails to configure on aarch64 with ld.gold: cannot compute sizeof (long long) ----------------------------------------+---------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Build System | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Comment (by juhpetersen): (Also happens with 7.10.1 patched for ld.gold.) As Erikd pointed out this is really a toolchain bug. Patched 7.8.4 seems unaffected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 10:42:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 10:42:48 -0000 Subject: [GHC] #9840: Permit empty closed type families In-Reply-To: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> References: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> Message-ID: <064.7ad3932f7ca02e00443ae666e122f301@haskell.org> #9840: Permit empty closed type families -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8028 | Differential Revisions: Phab:D841 -------------------------------------+------------------------------------- Comment (by adamgundry): Thanks, Richard, it's good to try to simplify and bring order to these; I hadn't realised what a can of worms I was opening with this feature request! In the interests of simplicity, is it actually necessary to distinguish "matchability" from generativity+injectivity? In particular, if `Any` remains non-generative (as at present) then I think the distinction collapses. The only case this matters is if we needed to conclude `f ~ Any : forall k . k` from `f @k0 ~ Any @k0 : k0`; but do we? I think it's perhaps also helpful to divide things up along the lines of where their equational theory comes from (considering only nominal roles for now): * trivial equational theory (`data`, `newtype`, `class`) * equational theory specified at declaration site (`type`, closed `type family`) * special equational theory either built-in or provided via plugin (type lits operators, what I want) * open equational theory that can be extended anywhere (open `type family`, `data family`) (The `data family` case is slightly strange, because the equational theory can be extended anywhere, but only in a very limited way.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 10:46:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 10:46:38 -0000 Subject: [GHC] #10350: Should be able to specify path for eventlog output. Message-ID: <046.5c9ba8e32681deff5b385781c81731cc@haskell.org> #10350: Should be able to specify path for eventlog output. -------------------------------------+------------------------------------- Reporter: literon | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.1 System | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Currently it is a fixed path, but the binary might run in an env where write access is restricted. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 10:48:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 10:48:00 -0000 Subject: [GHC] #10351: Inferred type is rejected Message-ID: <046.86ef5a0fea428f7b5f5c596d5fa38be9@haskell.org> #10351: Inferred type is rejected -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider {{{ class C a where op :: a -> () f x = op [x] }}} we get {{{ Foo.hs:14:1: error: Non type-variable argument in the constraint: C [t] (Use FlexibleContexts to permit this) When checking that ?f? has the inferred type f :: forall t. C [t] => t -> () }}} Arguably, if `FlexibleContexts` is not on, we should not infer a type that will immediately be rejected. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 10:55:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 10:55:04 -0000 Subject: [GHC] #10344: Make BranchList simpler In-Reply-To: <047.38d0a43513b53be4914a5abdcd2c6771@haskell.org> References: <047.38d0a43513b53be4914a5abdcd2c6771@haskell.org> Message-ID: <062.241057beb2584372dd05885cd1cad32c@haskell.org> #10344: Make BranchList simpler -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by adamgundry): * cc: adamgundry (added) Comment: A `Foldable` instance for `BranchList` might well simplify things, but I feel it would be simpler still for `BranchList` to be non-recursive, something like {{{ data BranchList a br where UnbranchedList :: a -> BranchList a Unbranched BranchedList :: [a] -> BranchList a Branched }}} You are welcome to disagree, though. :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 10:57:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 10:57:11 -0000 Subject: [GHC] #10344: Make BranchList simpler In-Reply-To: <047.38d0a43513b53be4914a5abdcd2c6771@haskell.org> References: <047.38d0a43513b53be4914a5abdcd2c6771@haskell.org> Message-ID: <062.b4393afe68d2536d22b7921c18b9179e@haskell.org> #10344: Make BranchList simpler -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Yes yes! Simple is good! Needs a comment to stress that in the `BranchedList` case the list may legitimately be empty. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 12:34:14 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 12:34:14 -0000 Subject: [GHC] #9840: Permit empty closed type families In-Reply-To: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> References: <049.f6cb0287f38c1240334c026f83ab01f9@haskell.org> Message-ID: <064.e626fdc9199dfc0e8f793c0d98380e6b@haskell.org> #9840: Permit empty closed type families -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #8028 | Differential Revisions: Phab:D841 -------------------------------------+------------------------------------- Comment (by goldfire): You're right that in the current state of affairs, generativity+injectivity imply matchability. But (until Phab:D202 lands) generativity also implies injectivity and vice versa. What characteristics to track separately is one of the challenges here... Suppose units-of-measure annotations were represented by a type headed `UnitExp`. `UnitExp` would not be injective, because it would take as arguments information about the different units and their powers, and this information has a non-trivial equational theory. However, `UnitExp` would, assumedly, be generative, in that no non-`UnitExp`s would ever be the same as a `UnitExp`. I don't know exactly what this means to the issue above, but it's an example of something that's generative but not injective. Yes, I completely agree about distinguishing based on equational theory. And the `data family` case is quite interesting, I think, because it shows how these concepts can be combined in unusual ways: data families are generative+injective, but yet have a non-trivial and extensible equational theory. If they didn't already exist, I would probably say this point in the space didn't exist! So there's something to be learned from them. Also, in case I haven't made this clear: these musings probably don't belong in this ticket, as I don't think these ideas should hold anything up about empty closed type families. But I'm hoping this leads to a slightly cleaner solution down the road. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 12:38:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 12:38:02 -0000 Subject: [GHC] #10352: Properly link Haskell shared libs on ELF systems Message-ID: <045.f54c0b53e462b1ea305eb5f3c38d7688@haskell.org> #10352: Properly link Haskell shared libs on ELF systems -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Package | Version: 7.11 system | Operating System: Linux Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Since the early days of building Haskell shared libs on Linux we have been using a scheme that is really a bit of a hack. We should do it properly. In my blog post on this from 2009 (http://www.well-typed.com/blog/30/) I said: > If we use ldd again to look at the libfoo.so that we've made we will notice that it is missing a dependency on the rts library. This is problem that we've yet to sort out, so for the moment we can just add the dependency ourselves: > > $ ghc --make -dynamic -shared -fPIC Foo.hs -o libfoo.so \ > -lHSrts-ghc6.11 -optl-Wl,-rpath,/opt/ghc/lib/ghc-6.11/ > > The reason it's not linked in yet is because we need to be able to switch which version of the rts we're using without having to relink every library. For example we want to be able to switch between the debug, threaded and normal rts versions. It's quite possible to do this and it just needs a bit more rearranging in the build system to sort it out. Once it's done you'll even be able to switch rts at runtime, eg: > > $ LD_PRELOAD=/opt/ghc/lib/ghc-6.11/libHSrts_debug-ghc6.11.so > $ ./Hello So in general, if a shared lib requires symbols from another shared lib then it should depend on it. In ELF terminology that means a NEEDED entry to say this lib needs that other lib. This is important to be able to link and load these shared libraries, otherwise they can have dangling dependencies. But we don't do this. For the specific case of the RTS we do not link Haskell shared libs against the RTS. So they have lots of dangling symbols. These libraries cannot be loaded on their own, e.g. with `dlopen()`. This is bad, and has other knock-on consequences. Why don't we link to the RTS? It's because historically (with static linking) GHC had had the ability to select the flavour of the RTS when final executables are linked, not when intermediate libraries are created. This works because the RTS flavours share a common ABI. This is a useful feature as it lets us select the SMP or debug or other RTS at final link time. So when we made up the first shared lib scheme on ELF we had to support this. Our initial scheme was like this: don't link Haskell library DSOs against the RTS, only like the final exe against the RTS. Each RTS flavour has a separate SONAME, e.g. `libHSrts_thr-ghc7.8.4.so` or `libHSrts_debug- ghc7.8.4.so`. This works because the runtime linker looks at the final exe first and loads the RTS, and then when other libs are loaded the symbols all resolve. Why can't we link all the libraries against the RTS? Currently each RTS flavour has a different SONAME, which is the key that the dynamic linker uses to identify each library. So if we did link all the Haskell libs against "the" RTS we would have to pick which one at the point at which we create the library, and that'd stop us from being able to choose later. So, can we use a better scheme? We want one that doesn't leave dangling undefined references in intermediate Haskell libs, and is also compatible with the ability to select the flavour of the RTS at final exe link time (or even override it at load time). Yes we can! The first thing to note is that to be interchangeable, all the RTS flavours (that share a compatible ABI) need to have the same SONAME. So for example, all the (non-profiling) RTS DSO files have to have the internal SONAME of `libHSrts-ghc7.8.4.so`. Once they all have the same SONAME, then it's ok for all the Haskell libs to specify a NEEDED dependency on that rts SONAME. But if they have the same SONAME, what do the files get called, where do they live and how are they found? The trick is to make use of the search path. Put each RTS flavour in a different directory, but otherwise with the same filename, e.g. `lib/rts-1.0/thr/libHSrts-ghc7.8.4.so`, `lib/rts-1.0/debug/libHSrts-ghc7.8.4.so` etc. Each library DSO and exe has its list of NEEDED entries, and it has an RPATH entry used to find those libraries if they're not loaded yet. The key is the "if they're not loaded yet" bit. Remember that the linker uses the SONAME as the key to decide if the lib is loaded yet or not. So the libraries could all have an RPATH entry to say to look for the RTS in the directory containing the default RTS flavour. But then the top level exe (or foreign/export shared lib) can also link to the RTS directly (ie an NEEDED entry) and can specify an RPATH which can be for any of the rts flavours. When the linker loads the top level exe, it will loads the selected RTS using the exe's RPATH, and then when the linker sees other Haskell libs that have a NEEDED entry on the RTS it will ignore them because the RTS's SONAME is already loaded. So concretely, instead of: lib/ghc-${ver}/rts-1.0/libHSrts-ghc${ver}.so lib/ghc-${ver}/rts-1.0/libHSrts_thr-ghc${ver}.so lib/ghc-${ver}/rts-1.0/libHSrts_debug-ghc${ver}.so lib/ghc-${ver}/rts-1.0/libHSrts_l-ghc${ver}.so lib/ghc-${ver}/rts-1.0/libHSrts_thr_l-ghc${ver}.so lib/ghc-${ver}/rts-1.0/libHSrts_thr_debug-ghc${ver}.so each with a different SONAME we'd have lib/ghc-${ver}/rts-1.0/libHSrts-ghc${ver}.so lib/ghc-${ver}/rts-1.0/thr/libHSrts-ghc${ver}.so lib/ghc-${ver}/rts-1.0/debug/libHSrts-ghc${ver}.so lib/ghc-${ver}/rts-1.0/l/libHSrts-ghc${ver}.so lib/ghc-${ver}/rts-1.0/thr_l/libHSrts-ghc${ver}.so lib/ghc-${ver}/rts-1.0/thr_debug/libHSrts-ghc${ver}.so each with the same SONAME When linking libs we would always use `-lHSrts -rpath lib/ghc-${ver}/rts-1.0` When linking exes (or shared libs for external consumption) we would use both `-lHSrts` and `-rpath lib/ghc-${ver}/${rtsflavour}/rts-1.0`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 12:50:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 12:50:15 -0000 Subject: [GHC] #10353: Haddock for Data.List should list instances Message-ID: <047.1cc6b80fad871b5f70060a95f0b113c7@haskell.org> #10353: Haddock for Data.List should list instances -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'd like to know the set of classes for which there are instances for `[]`. So, I naturally looked in the documentation for `Data.List`. However, because `Data.List` doesn't export `[]`, this list isn't there. Can this be fixed? (It's an honest question -- because of `[]`'s special syntax, I could see this fix being non-trivial.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 13:03:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 13:03:03 -0000 Subject: [GHC] #10344: Make BranchList simpler In-Reply-To: <047.38d0a43513b53be4914a5abdcd2c6771@haskell.org> References: <047.38d0a43513b53be4914a5abdcd2c6771@haskell.org> Message-ID: <062.35be23d62a74f8001ff1cc83f48bbfe2@haskell.org> #10344: Make BranchList simpler -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:2 simonpj]: > Yes yes! Simple is good! Needs a comment to stress that in the `BranchedList` case the list may legitimately be empty. But a `BranchList Branched` currently still can't be empty -- Adam's empty CTF patch uses the `Maybe (CoAxiom Branched)` approach to deal with empty CTFs. Consumers of `fromBranchList` assume they're getting a non-empty list. So, we could do {{{ data BranchList a br where OneBranch :: a -> BranchList a Unbranched ManyBranches :: a -> [a] -> BranchList a Branched -- requires at least one element }}} This is certainly simpler than the current story. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 13:33:16 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 13:33:16 -0000 Subject: [GHC] #10344: Make BranchList simpler In-Reply-To: <047.38d0a43513b53be4914a5abdcd2c6771@haskell.org> References: <047.38d0a43513b53be4914a5abdcd2c6771@haskell.org> Message-ID: <062.d43f309928c31d6629bc69bc82df4948@haskell.org> #10344: Make BranchList simpler -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): But he uses `Maybe (CoAxiom Branched)` because branch-lists could not previously represent empty lists. Once they can we can get rid of the `Maybe`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 14:10:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 14:10:18 -0000 Subject: [GHC] #10344: Make BranchList simpler In-Reply-To: <047.38d0a43513b53be4914a5abdcd2c6771@haskell.org> References: <047.38d0a43513b53be4914a5abdcd2c6771@haskell.org> Message-ID: <062.7f607b71f613d7e0a6c83f1b328b610e@haskell.org> #10344: Make BranchList simpler -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): But looking at Adam's code, I think changing it from using `Maybe` would make it more complex, not less. (I agreed with you about avoiding `Maybe` here originally, but inspection of the code encouraged me to change my mind.) In any case, I don't feel too strongly here. Ask once more, and I'll agree with you. :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 15:02:19 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 15:02:19 -0000 Subject: [GHC] #10260: last uses too much space with optimizations disabled In-Reply-To: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> References: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> Message-ID: <062.f322250c60f884525eadff1a6237cc14@haskell.org> #10260: last uses too much space with optimizations disabled -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: merge Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D847 -------------------------------------+------------------------------------- Changes (by rwbarton): * status: closed => merge Comment: This should be merged to 7.10 right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 15:47:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 15:47:05 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.b8d025218fa2028dd1e0d3f03d559df9@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): Replying to [comment:10 simonpj]: > 1. Add a new function > {{{ > reifyPackage :: String -- Package name > -> String -- Version > -> Q [Package] > }}} > which, given a package name/version returns all the installed packages with that name and version. I'm a little worried that this will encourage the people who previously wrote things like {{{ pkg = "haskell-src-exts-" ++ VERSION_haskell_src_exts }}} to instead call {{{ [pkg] <- reifyPackage "haskell-src-exts" VERSION_haskell_src_exts }}} just hoping that the result is a single package version. I'm not up to speed on the context here, but would it be possible to also provide {{{ thisPackage :: Q Package -- or maybe just :: Package }}} that refers to the package currently being built? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 16:19:08 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 16:19:08 -0000 Subject: [GHC] #10352: Properly link Haskell shared libs on ELF systems In-Reply-To: <045.f54c0b53e462b1ea305eb5f3c38d7688@haskell.org> References: <045.f54c0b53e462b1ea305eb5f3c38d7688@haskell.org> Message-ID: <060.a33153d57b51714171efe139dca6db1b@haskell.org> #10352: Properly link Haskell shared libs on ELF systems -------------------------------------+------------------------------------- Reporter: duncan | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): This might solve part of the problem with dynamic libraries on Android too (#10324). Is it necessary to put any rpath in the Haskell libraries? It might be better not to have one. If our assumption that the dynamic linker will prefer the rpath from the executable is correct, then it won't matter, but if it's wrong, then better to get a runtime error than silently use an RTS flavor other than the one the user specified. It does mean that a program that wants to `dlopen()` a Haskell library has to load the RTS first, or somehow set the runtime library path; but that's just one more hoop to jump through in addition to initializing the RTS, etc. If it really does matter for a specific Haskell library to have an rpath for the RTS then that can be added when linking the library, and again it seems better not to have "wrong" rpaths floating around in its dependencies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 17:19:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 17:19:17 -0000 Subject: [GHC] #10260: last uses too much space with optimizations disabled In-Reply-To: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> References: <047.8032d8ea0f7f5ebcbbd7cacd838ed4e3@haskell.org> Message-ID: <062.07d08fe988028cd6c9359934875b15d3@haskell.org> #10260: last uses too much space with optimizations disabled -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: nomeata Type: bug | Status: merge Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D847 -------------------------------------+------------------------------------- Comment (by nomeata): Probably. I?m always unsure about the policy here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 17:33:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 17:33:39 -0000 Subject: [GHC] #10338: GHC Forgets Constraints In-Reply-To: <047.e9cb1bcfe02024f21718f3ccf843982b@haskell.org> References: <047.e9cb1bcfe02024f21718f3ccf843982b@haskell.org> Message-ID: <062.7183ace7b0feaacf42900a74f5c7fdc0@haskell.org> #10338: GHC Forgets Constraints -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by crockeea): I've got a new test case for what I assume is this bug. Unfortunately, I can't find a workaround in this case. {{{#!hs {-# LANGUAGE MultiParamTypeClasses, ScopedTypeVariables, ConstraintKinds, KindSignatures, TypeFamilies, FlexibleInstances #-} import GHC.Prim import Control.Monad class Unsat (a :: * -> *) c class Qux (t :: * -> *) where type QCtx t q :: Constraint qux :: (QCtx t q, Monad rnd) => v -> rnd (t q) instance Qux t where type QCtx t q = (Unsat t q) class (Qux c) => C (c :: * -> *) r mymap :: c Double -> c i mymap = undefined foo :: forall c z v rnd . (C c z, Monad rnd, Num z) => v -> rnd (c z) foo svar = liftM mymap $ qux svar I've tried a wide array of explicit type sigs on `foo`, but nothing seems to make it find the dictionary for `Qux` inherited from `C`. I really need a fix for this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 19:48:42 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 19:48:42 -0000 Subject: [GHC] #10338: GHC Forgets Constraints In-Reply-To: <047.e9cb1bcfe02024f21718f3ccf843982b@haskell.org> References: <047.e9cb1bcfe02024f21718f3ccf843982b@haskell.org> Message-ID: <062.ef32a8239ee4d44e83137934ee01a020@haskell.org> #10338: GHC Forgets Constraints -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Well all the GHCs I have say {{{ T10338a.hs:27:26: Could not deduce (Unsat c Double) arising from a use of `qux' from the context (C c z, Monad rnd, Num z) bound by the type signature for foo :: (C c z, Monad rnd, Num z) => v -> rnd (c z) at T10338a.hs:26:8-69 }}} And that is totally correct. Every call to `qux` gives rise to a constraint `QCtx t q`. Nothing provides that constraint, certainly not `C c z`. But in fact the instance for `Qux t` says that `QCtx t q` simplifies to `Unsat t q`. And we are stuck. (The call to `qux` also gives rise to a `Qux c` constraint, and that is indeed satisfied from the `C c z` superclass.) I'm at a loss for why you think this program should typecheck. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 19:53:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 19:53:31 -0000 Subject: [GHC] #10279: panic on haskell-src-exts In-Reply-To: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> References: <051.feca8a66e38ca7539521db86affa1ea8@haskell.org> Message-ID: <066.0c38d51195e5ec95aedcd981f95de529@haskell.org> #10279: panic on haskell-src-exts -------------------------------------+------------------------------------- Reporter: throwaway123 | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Yes, we could certainly provide a way to get the current package. I don't know if that would serve this current use-case, but it's a good idea anyway. The best way to do that would be to elaborate `qReifyModule`, which currently returns a `ModuleInfo`. The latter is just {{{ data ModuleInfo = -- | Contains the import list of the module. ModuleInfo [Module] }}} but it should really contain the current `Module` to: {{{ data ModuleInfo = -- | Contains the import list of the module. ModuleInfo { mi_this_mod :: Module , mi_imports :: [Module] }}} }}} Remember that `Module` is {{{ data Module = Module PkgName ModName }}} so you can get the current `PkgKey` from the `Module`. Someone just needs to work carefully through the new API. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 21:02:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 21:02:02 -0000 Subject: [GHC] #10263: Role annotation should never be ambiguous In-Reply-To: <045.9af8436dde3df6d4df68ec603758d4b7@haskell.org> References: <045.9af8436dde3df6d4df68ec603758d4b7@haskell.org> Message-ID: <060.250321e0367f273f0050c73fb9337764@haskell.org> #10263: Role annotation should never be ambiguous -------------------------------------+------------------------------------- Reporter: ezyang | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"6ab5da9913e4f8a8dcc8bda3c77d4e896fd67352/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6ab5da9913e4f8a8dcc8bda3c77d4e896fd67352" Rename role annotations w.r.t only local decls. Fix #10263. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 21:02:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 21:02:03 -0000 Subject: [GHC] #10285: Bug in Coerciible In-Reply-To: <046.006c15618be24223a545ea3cfa4998d2@haskell.org> References: <046.006c15618be24223a545ea3cfa4998d2@haskell.org> Message-ID: <061.b910c057b6da1767c6b5f6d5a3202001@haskell.org> #10285: Bug in Coerciible -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: new Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"a8d39a7255df187b742fecc049f0de6528b9acad/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a8d39a7255df187b742fecc049f0de6528b9acad" Fix #10285 by refusing to use NthCo on a newtype. During this commit, I tested to make sure that CoreLint actually catches the Core error if the typechecker doesn't. Test case: typecheck/should_fail/T10285 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 21:02:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 21:02:03 -0000 Subject: [GHC] #10121: operational semantics is incomplete? In-Reply-To: <045.efa85bab9e541979e9544e7b6204f8b8@haskell.org> References: <045.efa85bab9e541979e9544e7b6204f8b8@haskell.org> Message-ID: <060.826e48f9d0bdd82fde45f9770e51f676@haskell.org> #10121: operational semantics is incomplete? -------------------------------------+------------------------------------- Reporter: javran | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Documentation | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"414e20bc7f5166d020ace3d92cd605e121d5eb3c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="414e20bc7f5166d020ace3d92cd605e121d5eb3c" Fix the formal operational semantics (#10121) This adapts the work of Christiaan Baaij to present a sensible operational semantics for FC with mutual recursion. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 21:02:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 21:02:03 -0000 Subject: [GHC] #10141: Kind inference regression in closed type families In-Reply-To: <047.0645604fc6dcb528cffc10034076546d@haskell.org> References: <047.0645604fc6dcb528cffc10034076546d@haskell.org> Message-ID: <062.15ecbebee3e6e2f3099e6acc94738c76@haskell.org> #10141: Kind inference regression in closed type families -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"dc587fe7f27e2bc762d8a6cae3687ca2ebbbdb9b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="dc587fe7f27e2bc762d8a6cae3687ca2ebbbdb9b" Test case for #10141 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 21:02:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 21:02:03 -0000 Subject: [GHC] #10321: GHC.TypeLits.Nat types no longer fully simplified. In-Reply-To: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> References: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> Message-ID: <061.9aae2e0ecfaf3930de525853286b3155@haskell.org> #10321: GHC.TypeLits.Nat types no longer fully simplified. -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: TypeLits Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"d4cf5591e51e2b91b3877a05f8153db1f5328994/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d4cf5591e51e2b91b3877a05f8153db1f5328994" Test #10321 in ghci/scripts/T10321 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 21:02:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 21:02:03 -0000 Subject: [GHC] #9204: Conflicting definition in hs-boot file In-Reply-To: <048.b808de9c3a89b697c417598cdf99dbcd@haskell.org> References: <048.b808de9c3a89b697c417598cdf99dbcd@haskell.org> Message-ID: <063.2f3310edfee5f8a10ff3c3a4ac2ec107@haskell.org> #9204: Conflicting definition in hs-boot file -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: goldfire Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Documentation | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | roles/should_fail/T9204 | Blocking: | Differential Revisions: Phab:D458 -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"72a927267d9c658a2e5d226a855702d348472516/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="72a927267d9c658a2e5d226a855702d348472516" Change default roles in hs-boot files. (#9204) Test case: roles/should_compile/T9204b }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 21:03:19 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 21:03:19 -0000 Subject: [GHC] #10285: Bug in Coerciible In-Reply-To: <046.006c15618be24223a545ea3cfa4998d2@haskell.org> References: <046.006c15618be24223a545ea3cfa4998d2@haskell.org> Message-ID: <061.9f3ab37b1493af9d2f19beca9cd3a4a5@haskell.org> #10285: Bug in Coerciible -------------------------------------+------------------------------------- Reporter: simonpj | Owner: goldfire Type: bug | Status: merge Priority: highest | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T10285 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => typecheck/should_fail/T10285 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 21:04:51 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 21:04:51 -0000 Subject: [GHC] #9204: Conflicting definition in hs-boot file In-Reply-To: <048.b808de9c3a89b697c417598cdf99dbcd@haskell.org> References: <048.b808de9c3a89b697c417598cdf99dbcd@haskell.org> Message-ID: <063.af355a7df7894b446e4dcc33c9fed3f5@haskell.org> #9204: Conflicting definition in hs-boot file -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: goldfire Type: bug | Status: closed Priority: low | Milestone: 7.12.1 Component: Documentation | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | roles/should_fail/T9204 | roles/should_compile/T9204b | Blocking: | Differential Revisions: Phab:D458 -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * testcase: roles/should_fail/T9204 => roles/should_fail/T9204 roles/should_compile/T9204b * resolution: => fixed Comment: This is a user-facing change, so wait until 7.12. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 21:06:17 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 21:06:17 -0000 Subject: [GHC] #10263: Role annotation should never be ambiguous In-Reply-To: <045.9af8436dde3df6d4df68ec603758d4b7@haskell.org> References: <045.9af8436dde3df6d4df68ec603758d4b7@haskell.org> Message-ID: <060.1046ad2d9cf0c92cb87d21ee1b50730a@haskell.org> #10263: Role annotation should never be ambiguous -------------------------------------+------------------------------------- Reporter: ezyang | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | roles/should_compile/T10263 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => roles/should_compile/T10263 * milestone: => 7.10.2 Comment: Merge if convenient. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 21:09:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 21:09:34 -0000 Subject: [GHC] #10321: GHC.TypeLits.Nat types no longer fully simplified. In-Reply-To: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> References: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> Message-ID: <061.fa26c402b6ac0322118207919ada083f@haskell.org> #10321: GHC.TypeLits.Nat types no longer fully simplified. -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: TypeLits Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | ghci/scripts/T10321 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => ghci/scripts/T10321 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 21:11:44 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 21:11:44 -0000 Subject: [GHC] #10141: Kind inference regression in closed type families In-Reply-To: <047.0645604fc6dcb528cffc10034076546d@haskell.org> References: <047.0645604fc6dcb528cffc10034076546d@haskell.org> Message-ID: <062.cbd6daf6da302b965b3425043e3f4322@haskell.org> #10141: Kind inference regression in closed type families -------------------------------------+------------------------------------- Reporter: goldfire | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: indexed- Related Tickets: | types/should_fail/T10141 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: => indexed-types/should_fail/T10141 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 21:11:57 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 21:11:57 -0000 Subject: [GHC] #10338: GHC Forgets Constraints In-Reply-To: <047.e9cb1bcfe02024f21718f3ccf843982b@haskell.org> References: <047.e9cb1bcfe02024f21718f3ccf843982b@haskell.org> Message-ID: <062.a60b4753e7982e2d18a0e3b89707a02f@haskell.org> #10338: GHC Forgets Constraints -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by crockeea): Ah, I see. I saw "could not deduce Unsat" and thought it was the same bug. My mistake. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Apr 24 21:39:44 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 24 Apr 2015 21:39:44 -0000 Subject: [GHC] #10263: Role annotation should never be ambiguous In-Reply-To: <045.9af8436dde3df6d4df68ec603758d4b7@haskell.org> References: <045.9af8436dde3df6d4df68ec603758d4b7@haskell.org> Message-ID: <060.043202012f86cd0c179af5e70082a0ce@haskell.org> #10263: Role annotation should never be ambiguous -------------------------------------+------------------------------------- Reporter: ezyang | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.11 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | roles/should_compile/T10263 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): Woohoo, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 25 01:23:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Apr 2015 01:23:49 -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.d1570aa7dd01d0fa6578bb94da5bc61e@haskell.org> #10284: Create a dedicated `TypeError` exception type -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: kanetw Type: feature request | Status: patch Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: phab:D866 -------------------------------------+------------------------------------- Comment (by kanetw): adamgundy, no problem! It's quite fun to do this stuff. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 25 01:38:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Apr 2015 01:38:51 -0000 Subject: [GHC] #10121: operational semantics is incomplete? In-Reply-To: <045.efa85bab9e541979e9544e7b6204f8b8@haskell.org> References: <045.efa85bab9e541979e9544e7b6204f8b8@haskell.org> Message-ID: <060.be205f294cfdeb2ad421a1de99d307e9@haskell.org> #10121: operational semantics is incomplete? -------------------------------------+------------------------------------- Reporter: javran | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: Component: Documentation | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => closed * resolution: => fixed Comment: This seems all set now. Reopen if you think otherwise. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 25 01:47:08 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Apr 2015 01:47:08 -0000 Subject: [GHC] #10329: ghc-7.10 is configured to use llvm-3.6 but only compiles with llvm-3.5 In-Reply-To: <044.7bb160d7a31f6091fc12e2d6f3a346bc@haskell.org> References: <044.7bb160d7a31f6091fc12e2d6f3a346bc@haskell.org> Message-ID: <059.8eda62eca4ed57238d2328fad06313c8@haskell.org> #10329: ghc-7.10 is configured to use llvm-3.6 but only compiles with llvm-3.5 -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D856 -------------------------------------+------------------------------------- Comment (by erikd): The current `ghc-7.10` branch fails to build with `BuldFlavour = perf- llvm` due to: {{{ !0 = metadata !{metadata !"top", i8* null} }}} which is a direct result of the issue in this ticket and which the patch in Phab:D856 fixes. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 25 06:37:36 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Apr 2015 06:37:36 -0000 Subject: [GHC] #10329: ghc-7.10 is configured to use llvm-3.6 but only compiles with llvm-3.5 In-Reply-To: <044.7bb160d7a31f6091fc12e2d6f3a346bc@haskell.org> References: <044.7bb160d7a31f6091fc12e2d6f3a346bc@haskell.org> Message-ID: <059.2cc77d0ec72e7685ba3484ad8aff110b@haskell.org> #10329: ghc-7.10 is configured to use llvm-3.6 but only compiles with llvm-3.5 -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D856 -------------------------------------+------------------------------------- Changes (by erikd): * status: patch => closed * resolution: => fixed Comment: This was fixed in commit: {{{ commit 99e4e26a2672f7697cf1f76306c3dfb63125e035 Author: Erik de Castro Lopo Date: Sat Apr 25 08:14:48 2015 +0200 configure: LLVM and LD detection improvements (#10329) The ghc-7.10 branch *only* works with llvm-3.5. This commit is basically the ghc-7.10 branch version of 485dba86d2 in the master branch. Signed-off-by: Erik de Castro Lopo Differential Revision: https://phabricator.haskell.org/D856 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 25 06:39:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Apr 2015 06:39:24 -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.884815cbe9eaed91788007d5dc22a9cb@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 Revisions: -------------------------------------+--------------------------------- Changes (by erikd): * status: new => closed * resolution: => fixed Comment: Detection of this probelms was added to the ghc-7.10 branch in: {{{ commit b856f3f3d7850ca0456dd80aaa59241b3d297ab9 Author: Erik de Castro Lopo Date: Sat Apr 25 08:27:49 2015 +0200 configure: Test for #9920 when compiling for arm The ghc-7.10 branch requires use of llvm-3.5, but the llvm-3.5.0 release had a bug that was fixed in llvm-3.5.1. When we are targeting arm, test for this bug in the llvm program `llc` during confgure and if present, abort configuration with an informative error message. Signed-off-by: Erik de Castro Lopo Differential Revision: https://phabricator.haskell.org/D857 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 25 07:49:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Apr 2015 07:49:14 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.a9e582aeb4b65899525c71f5a367e95f@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D578 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"75adc352549a43d4c37bd3bdade55cecf3d75bb1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="75adc352549a43d4c37bd3bdade55cecf3d75bb1" Add missing since-annotations for c024af131b9e2538 See also #9049 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 25 07:49:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Apr 2015 07:49:14 -0000 Subject: [GHC] #10308: GHC 7.10 does not export GHC.Event.Lifetime In-Reply-To: <046.e0a310ea46a004864a1735177af6822e@haskell.org> References: <046.e0a310ea46a004864a1735177af6822e@haskell.org> Message-ID: <061.f3d97458ffc41545dd2614111c75fd61@haskell.org> #10308: GHC 7.10 does not export GHC.Event.Lifetime -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: D838 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"9a0c17950fdfd0c89c672da9d8b25a419f66c1f8/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="9a0c17950fdfd0c89c672da9d8b25a419f66c1f8" base: Export GHC.Event(.Internal).Lifetime This was an unfortunate oversight in the original event manager rework patch. Fixes #10308 Differential Revision: https://phabricator.haskell.org/D845 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 25 07:50:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Apr 2015 07:50:19 -0000 Subject: [GHC] #10308: GHC 7.10 does not export GHC.Event.Lifetime In-Reply-To: <046.e0a310ea46a004864a1735177af6822e@haskell.org> References: <046.e0a310ea46a004864a1735177af6822e@haskell.org> Message-ID: <061.75052cef575fcd2f9af654e63fb37f53@haskell.org> #10308: GHC 7.10 does not export GHC.Event.Lifetime -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D845 -------------------------------------+------------------------------------- Changes (by hvr): * status: new => merge * differential: D838 => Phab:D845 * milestone: => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 25 08:25:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Apr 2015 08:25:13 -0000 Subject: [GHC] #8403: Pretty-printing of long types In-Reply-To: <047.792ac96369079bc46b579fe906221406@haskell.org> References: <047.792ac96369079bc46b579fe906221406@haskell.org> Message-ID: <062.f367b9797b754d734458ba95041f276f@haskell.org> #8403: Pretty-printing of long types -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9428 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by joehillen): [https://gist.github.com/joehillen/bc115c8e5d6a7587777c Just to be clear.] What exactly is the problem with the current formatting? It seems to make perfect sense and is reasonable to break at every '->' or ','. To me, the current behavior is more readable than the proposed alternative. Even if it does take up more vertical space. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 25 09:26:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Apr 2015 09:26:14 -0000 Subject: [GHC] #10308: GHC 7.10 does not export GHC.Event.Lifetime In-Reply-To: <046.e0a310ea46a004864a1735177af6822e@haskell.org> References: <046.e0a310ea46a004864a1735177af6822e@haskell.org> Message-ID: <061.d8dedff22c9856b4482efd7646538bf6@haskell.org> #10308: GHC 7.10 does not export GHC.Event.Lifetime -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.2 Component: libraries/base | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D845 -------------------------------------+------------------------------------- Changes (by hvr): * cc: hvr, ekmett (added) * resolution: => fixed * status: merge => closed * component: Compiler => libraries/base Comment: Merged to 7.10 via b324fac4e9769c963620ccfc645e0ee2890da5b7 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 25 10:31:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Apr 2015 10:31:35 -0000 Subject: [GHC] #10354: ApiAnnotations : parens around a context with wildcard loses annotations Message-ID: <044.e85841686cec42396381accb0db3e1e2@haskell.org> #10354: ApiAnnotations : parens around a context with wildcard loses annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In the following code, the extra set of parens around the context end up with detached annotations. {{{#!hs {-# LANGUAGE PartialTypeSignatures #-} module ParensAroundContext where f :: ((Eq a, _)) => a -> a -> Bool f x y = x == y }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 25 11:03:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Apr 2015 11:03:35 -0000 Subject: [GHC] #10354: ApiAnnotations : parens around a context with wildcard loses annotations In-Reply-To: <044.e85841686cec42396381accb0db3e1e2@haskell.org> References: <044.e85841686cec42396381accb0db3e1e2@haskell.org> Message-ID: <059.0a186bd729724b0558ee77d0429545ec@haskell.org> #10354: ApiAnnotations : parens around a context with wildcard loses annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by alanz): It seems `RdrHsSyn.checkContext` is the culprit {{{#!hs ... check (HsParTy ty) -- to be sure HsParTy doesn't get into the way = check (unLoc ty) ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 25 12:09:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Apr 2015 12:09:51 -0000 Subject: [GHC] #9929: New alias handling not compatible with LLVM 3.4 In-Reply-To: <047.16e0d585b02943379458702a5beede5a@haskell.org> References: <047.16e0d585b02943379458702a5beede5a@haskell.org> Message-ID: <062.58f3a02f6f47c4961fc52be792382dca@haskell.org> #9929: New alias handling not compatible with LLVM 3.4 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | thoughtpolice Priority: high | Status: new Component: Compiler (LLVM) | Milestone: 7.10.2 Resolution: | Version: 7.10.1-rc1 Operating System: Linux | Keywords: Type of failure: Compile-time | Architecture: x86_64 crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): #10302 is a doc ticket that tells people to use llvm 3.5. Do we want to close this and just track 10302? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 25 12:22:21 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Apr 2015 12:22:21 -0000 Subject: [GHC] #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X In-Reply-To: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> References: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> Message-ID: <062.731ae7f2f3de8b792e8c014f691d33a3@haskell.org> #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D852 -------------------------------------+------------------------------------- Comment (by George): Not sure but the -flat_namespace option might be what you are looking for. Following is from the Mac man page for ld. I wonder if ghc has always had this bug or if this is a regression. == Two-level namespace == By default all references resolved to a dynamic library record the library to which they were resolved. At runtime, dyld uses that information to directly resolve symbols. The alternative is to use the -flat_namespace option. With flat namespace, the library is not recorded. At runtime, dyld will search each dynamic library in load order when resolving symbols. This is slower, but more like how other operating systems resolve symbols. == Indirect dynamic libraries == If the command line specifies to link against dylib A, and when dylib A was built it linked against dylib B, then B is considered an indirect dylib. When linking for two-level namespace, ld does not look at indirect dylibs, except when re-exported by a direct dylibs. On the other hand when linking for flat namespace, ld does load all indirect dylibs and uses them to resolve references. Even though indirect dylibs are specified via a full path, ld first uses the specified search paths to locate each indirect dylib. If one cannot be found using the search paths, the full path is used. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 25 12:34:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Apr 2015 12:34:15 -0000 Subject: [GHC] #10053: Too late for parseStaticFlags, error in ghci calling main after loading compiled code, regression In-Reply-To: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> References: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> Message-ID: <060.3bbfbaecae66b21e53a45a7af780f36c@haskell.org> #10053: Too late for parseStaticFlags, error in ghci calling main after loading compiled code, regression -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by George): * milestone: => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Apr 25 21:12:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 25 Apr 2015 21:12:26 -0000 Subject: [GHC] #10355: Dynamic linker not initialised Message-ID: <046.b020405a0b5eb69acc1047433b42d151@haskell.org> #10355: Dynamic linker not initialised -------------------------------------+------------------------------------- Reporter: dpiponi | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I get this message: [ 3 of 24] Compiling Cable ( src/Cable.hs, dist/build/ui/ui- tmp/Cable.o ) : ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-apple-darwin): Dynamic linker not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug when building my code here: https://github.com/dpiponi/Moodler/tree/master/Moodler/src under Yosemite 10.10.2 So I'm reporting it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 26 00:29:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Apr 2015 00:29:00 -0000 Subject: =?utf-8?b?W0dIQ10gIzEwMzU2OiBDb3VsZG4ndCBtYXRjaCB0eXBlIOKAmGE=?= =?utf-8?b?4oCZIHdpdGgg4oCYSW504oCZIC8g4oCYYeKAmSBpcyB1bnRvdWNo?= =?utf-8?q?able_/_inside_the_constraints_=28=29?= Message-ID: <044.b92caf5bd3909ef5b1c4a1f89f293fe1@haskell.org> #10356: Couldn't match type ?a? with ?Int? / ?a? is untouchable / inside the constraints () -------------------------------------+------------------------------------- Reporter: radix | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Sadly I'm a Haskell newbie, so this won't be a very good bug report, but I am working on a codebase and I triggered a GHC bug (at least according to GHC itself). {{{ Building json-log-viewer-0.0.1... Preprocessing executable 'json-log-viewer' for json-log-viewer-0.0.1... [3 of 3] Compiling Main ( src/Main.hs, dist/build/json-log- viewer/json-log-viewer-tmp/Main.o ) src/Main.hs:316:41: Couldn't match type ?a? with ?Int? ?a? is untouchable inside the constraints () bound by the inferred type of refreshMessages :: IO () at src/Main.hs:(300,7)-(324,48)ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-apple-darwin): No skolem info: a_al2w[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I saved the state of the code in a git branch and put it here: https://github.com/radix/json-log-viewer/tree/ghc-bug I'll also attach my list of cabal dependencies installed. The only tricky one is that I'm working off of an unreleased version of `vty-ui`, at this revision: https://github.com/jtdaugherty/vty- ui/commit/c3a0c4b660119a4d5862a6f549a98739a3fc5fa7 I also don't know if the program is "valid" -- I'm in the middle of a refactor, and it's a big cluttered program that I know is very poorly written. Sorry about that. I would not usually report a bug in such a situation but the compiler implored me to, so I am. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 26 00:32:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Apr 2015 00:32:38 -0000 Subject: [GHC] #10159: cabal build/ghc compiler causes sudden hard reboot of my computer! In-Reply-To: <046.f6a8819131c1ac525f6581f5be865c05@haskell.org> References: <046.f6a8819131c1ac525f6581f5be865c05@haskell.org> Message-ID: <061.c43de6f7cf0f872dfc20504d01664bc6@haskell.org> #10159: cabal build/ghc compiler causes sudden hard reboot of my computer! ---------------------------------+----------------------------------------- Reporter: jamshid | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by jamshid): OK, I've learned more, and have a better idea of what is going on. So, I started monitoring CPU usage during builds, and noticed that when I type in "cabal build", the CPU would go to about 400%, whereas when I type in "cabal install", it tops out at about 99%.... For some reason "cabal install" only uses one core of my CPU, "cabal build" tried to use more. I was able to fix this problem by adding a "ghc-options: -j8" in my cabal file (well, the full line was "ghc-options: -Wall -O2 -j8". As soon as I did this, "cabal install" started crashing my machine also. So, now I am more convinced that I have faulty hardware.... A CPU that overheats when I use multiple cores. There still are some open questions though. First, why doesn't anything else trigger this, even when I rev up all my cores with processes running an empty loop.... and second, why does "cabal install" use 1 core, while "cabal build" uses many (by default). BTW- I did film the build with -v3, but the last comments were pretty nondescript, a bunch of *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: *** CPSZ: I have the full video if you want it, although at this point it seems less important. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 26 00:50:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Apr 2015 00:50:32 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2310356=3A_Couldn=27t_match_type_?= =?utf-8?b?4oCYYeKAmSB3aXRoIOKAmEludOKAmSAvIOKAmGHigJkgaXMgdW50?= =?utf-8?q?ouchable_/_inside_the_constraints_=28=29?= In-Reply-To: <044.b92caf5bd3909ef5b1c4a1f89f293fe1@haskell.org> References: <044.b92caf5bd3909ef5b1c4a1f89f293fe1@haskell.org> Message-ID: <059.8b40611d095cc792df106dfff0acf122@haskell.org> #10356: Couldn't match type ?a? with ?Int? / ?a? is untouchable / inside the constraints () -------------------------------------+------------------------------------- Reporter: radix | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by radix): Oh, I just found https://ghc.haskell.org/trac/ghc/ticket/10045 I'm pretty sure this is a duplicate of that (fixed) bug. I'll close this one, in hopes that nobody looks at my horrible reproducer code :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 26 00:50:35 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Apr 2015 00:50:35 -0000 Subject: [GHC] #10234: armhf : Validate fails during bindisttest configure In-Reply-To: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> References: <044.1b13feff73dae97527614e1f8c08b2cf@haskell.org> Message-ID: <059.a2eafc35ab4b42dba612cd7d7edd9cb4@haskell.org> #10234: armhf : Validate fails during bindisttest configure -------------------------------------+------------------------------------- Reporter: erikd | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: llvm Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: ?Phab:D828 -------------------------------------+------------------------------------- Changes (by erikd): * status: merge => closed * resolution: => fixed Comment: This was fixed for the `ghc-7.10` branch in commit: {{{ commit 99e4e26a2672f7697cf1f76306c3dfb63125e035 Author: Erik de Castro Lopo Date: Sat Apr 25 08:14:48 2015 +0200 configure: LLVM and LD detection improvements (#10329) The ghc-7.10 branch *only* works with llvm-3.5. This commit is basically the ghc-7.10 branch version of 485dba86d2 in the master branch. Signed-off-by: Erik de Castro Lopo Differential Revision: https://phabricator.haskell.org/D856 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 26 00:50:46 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Apr 2015 00:50:46 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2310356=3A_Couldn=27t_match_type_?= =?utf-8?b?4oCYYeKAmSB3aXRoIOKAmEludOKAmSAvIOKAmGHigJkgaXMgdW50?= =?utf-8?q?ouchable_/_inside_the_constraints_=28=29?= In-Reply-To: <044.b92caf5bd3909ef5b1c4a1f89f293fe1@haskell.org> References: <044.b92caf5bd3909ef5b1c4a1f89f293fe1@haskell.org> Message-ID: <059.0840f90d00b575b15272bf983c7a103f@haskell.org> #10356: Couldn't match type ?a? with ?Int? / ?a? is untouchable / inside the constraints () -------------------------------------+------------------------------------- Reporter: radix | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by radix): * status: new => closed * resolution: => duplicate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 26 05:03:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Apr 2015 05:03:22 -0000 Subject: [GHC] #9049: Expose srcLoc from the assertion architecture to allow better error messages In-Reply-To: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> References: <042.a0d4c757be085a0284ebca147547b4f3@haskell.org> Message-ID: <057.604525c5138e6335a36abd9c23812fa9@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature request | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D578 -------------------------------------+------------------------------------- Comment (by nh2): Related: [https://phabricator.haskell.org/D861 D861 - Use IP based CallStack in error and undefined] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 26 08:36:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Apr 2015 08:36:29 -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.5b001a7c6bfb3ad0e68f98a8d4ac14da@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gidyn): CoreTidy seems to be another culprit for investigation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 26 08:37:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Apr 2015 08:37:55 -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.3ca43ec23b2d54489cf1988ada8b9fd9@haskell.org> #9630: compile-time performance regression (probably due to Generics) -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #9583, #10293 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 26 08:45:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Apr 2015 08:45:31 -0000 Subject: [GHC] #10315: ApiAnnotations : Empty context loses annotations In-Reply-To: <044.a3ae6affd9ae60617b8ad158a443dbf2@haskell.org> References: <044.a3ae6affd9ae60617b8ad158a443dbf2@haskell.org> Message-ID: <059.7014e2caa67d4c95071e01b032ed25bf@haskell.org> #10315: ApiAnnotations : Empty context loses annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: patch Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #10354 | Test Case: | Blocking: | Differential Revisions: Phab:855 -------------------------------------+------------------------------------- Changes (by alanz): * related: => #10354 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 26 08:46:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Apr 2015 08:46:14 -0000 Subject: [GHC] #10315: ApiAnnotations : Empty context loses annotations In-Reply-To: <044.a3ae6affd9ae60617b8ad158a443dbf2@haskell.org> References: <044.a3ae6affd9ae60617b8ad158a443dbf2@haskell.org> Message-ID: <059.ece58599082522ed495931732881a343@haskell.org> #10315: ApiAnnotations : Empty context loses annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #10354 | Test Case: | Blocking: | Differential Revisions: | Phab:855,Phab:868 -------------------------------------+------------------------------------- Changes (by alanz): * owner: alanz => * status: patch => new * differential: Phab:855 => Phab:855,Phab:868 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 26 08:46:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Apr 2015 08:46:31 -0000 Subject: [GHC] #10315: ApiAnnotations : Empty context loses annotations In-Reply-To: <044.a3ae6affd9ae60617b8ad158a443dbf2@haskell.org> References: <044.a3ae6affd9ae60617b8ad158a443dbf2@haskell.org> Message-ID: <059.20c8df24a50ee64d7b485b56da5ac4e6@haskell.org> #10315: ApiAnnotations : Empty context loses annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #10354 | Test Case: | Blocking: | Differential Revisions: | Phab:855,Phab:868 -------------------------------------+------------------------------------- Changes (by alanz): * owner: => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 26 11:20:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Apr 2015 11:20:57 -0000 Subject: [GHC] #10354: ApiAnnotations : parens around a context with wildcard loses annotations In-Reply-To: <044.e85841686cec42396381accb0db3e1e2@haskell.org> References: <044.e85841686cec42396381accb0db3e1e2@haskell.org> Message-ID: <059.2f0dc136b645cb7dd57122be8e27a726@haskell.org> #10354: ApiAnnotations : parens around a context with wildcard loses annotations -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | ApiAnnotations Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #10315 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by alanz): * related: => #10315 * milestone: => 7.10.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 26 15:37:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Apr 2015 15:37:20 -0000 Subject: [GHC] #7478: setSessionDynFlags does not always work In-Reply-To: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> References: <044.a3899b7bd6c11925eee15996dee68777@haskell.org> Message-ID: <059.c1977dd4ec8a53b7df9a525b91503898@haskell.org> #7478: setSessionDynFlags does not always work -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: ghc- Related Tickets: | api/T7478 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bherzog): A better solution is the following, I think: Have `defaultFlags` include `Opt_Static` in its result if `pc_DYNAMIC_BY_DEFAULT` is False. Reasoning: comment:17 shows that `ways` and `generalFlags` need to be coordinated wrt. dynamic/static linking: `generalFlags` needs to contain `Opt_Static` exactly when `ways` does not contain `WayDyn`. The values of both fields are derived from the settings passed to `defaultDynFlags`. In particular, `ways` will either be `[WayDyn]` or `[]`, depending on whether `pc_DYNAMIC_BY_DEFAULT` is True or False respectively. Therefore, `defaultFlags` should include `Opt_Static` in its result if `pc_DYNAMIC_BY_DEFAULT` is False. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 26 16:10:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Apr 2015 16:10:04 -0000 Subject: [GHC] #10206: Incorrect links are generated for modules in the index of "Haskell Hiearchical Libraries" In-Reply-To: <042.42f9ef42100e34be4ebb160898f1d318@haskell.org> References: <042.42f9ef42100e34be4ebb160898f1d318@haskell.org> Message-ID: <057.00c877488808ccfacbdf5f9f998c3a21@haskell.org> #10206: Incorrect links are generated for modules in the index of "Haskell Hiearchical Libraries" -------------------------------------+------------------------------------- Reporter: pgj | Owner: Type: bug | thoughtpolice Priority: highest | Status: upstream Component: Documentation | Milestone: 7.10.2 Resolution: | Version: 7.10.1-rc1 Operating System: Unknown/Multiple | Keywords: Type of failure: Documentation | Architecture: bug | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * status: new => upstream Comment: Upstream-tracked at https://github.com/haskell/haddock/issues/385 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 26 18:47:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Apr 2015 18:47:22 -0000 Subject: [GHC] #10357: ApiAnnotations : pquals production adds AnnVbar in the wrong place Message-ID: <044.ef89cccb5e96536f53dd8893bde9d74e@haskell.org> #10357: ApiAnnotations : pquals production adds AnnVbar in the wrong place -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The `Parser.y` production for `pquals` is {{{ pquals :: { Located [[LStmt RdrName (LHsExpr RdrName)]] } : squals '|' pquals {% addAnnotation (gl $ last $ unLoc $1) AnnVbar (gl $2) >> return (sLL $1 $> (reverse (unLoc $1) : unLoc $3)) } | squals { L (getLoc $1) [reverse (unLoc $1)] } }}} The `squals` are returned in reverse order, so the `AnnVbar` should be attached to the `head` of the list, not the `last`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Apr 26 19:30:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 26 Apr 2015 19:30:49 -0000 Subject: [GHC] #10357: ApiAnnotations : pquals production adds AnnVbar in the wrong place In-Reply-To: <044.ef89cccb5e96536f53dd8893bde9d74e@haskell.org> References: <044.ef89cccb5e96536f53dd8893bde9d74e@haskell.org> Message-ID: <059.122f08eb3669aceefbdc0d51d5884c08@haskell.org> #10357: ApiAnnotations : pquals production adds AnnVbar in the wrong place -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D869 -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D869 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 27 08:21:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Apr 2015 08:21:14 -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.a69a9489d921c5bbb6843d3015f4900c@haskell.org> #10284: Create a dedicated `TypeError` exception type -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: kanetw Type: feature request | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: phab:D866 -------------------------------------+------------------------------------- Changes (by simonpj): * cc: core-libraries-committee@? (added) * component: Compiler => Core Libraries Comment: Core Libraries folk: are you happy with this change? See Phab:D866 Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 27 08:56:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Apr 2015 08:56:31 -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.6cde377dc9ffc02dffbae85cf7e49575@haskell.org> #10284: Create a dedicated `TypeError` exception type -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: kanetw Type: feature request | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: phab:D866 -------------------------------------+------------------------------------- Comment (by ekmett): Makes sense to me. Erring on the side of improving the granularity of what you can catch is pretty much what we've done all along. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 27 10:28:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Apr 2015 10:28:48 -0000 Subject: [GHC] #10321: GHC.TypeLits.Nat types no longer fully simplified. In-Reply-To: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> References: <046.457ce0b7cb6c719b83e783929af0156c@haskell.org> Message-ID: <061.9734fb111dc596c29e37962bb061252d@haskell.org> #10321: GHC.TypeLits.Nat types no longer fully simplified. -------------------------------------+------------------------------------- Reporter: darchon | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: TypeLits Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | ghci/scripts/T10321 Related Tickets: | Blocking: | Differential Revisions: ?phab:D870 -------------------------------------+------------------------------------- Changes (by darchon): * differential: => ?phab:D870 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 27 10:58:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Apr 2015 10:58:58 -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.28aab0a8b77de63202e3ea1469934b52@haskell.org> #10284: Create a dedicated `TypeError` exception type -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: kanetw Type: feature request | Status: patch Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: phab:D866 -------------------------------------+------------------------------------- Comment (by snoyberg): +1 from me as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 27 14:01:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Apr 2015 14:01:08 -0000 Subject: [GHC] #10053: Too late for parseStaticFlags, error in ghci calling main after loading compiled code, regression on MacOS platform (was: Too late for parseStaticFlags, error in ghci calling main after loading compiled code, regression) In-Reply-To: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> References: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> Message-ID: <060.0230fe0610bf472de722c98c5a83101f@haskell.org> #10053: Too late for parseStaticFlags, error in ghci calling main after loading compiled code, regression on MacOS platform -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: GHCi | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 27 14:09:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Apr 2015 14:09:43 -0000 Subject: [GHC] #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X In-Reply-To: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> References: <047.c6bea83aa569e3bec4fd1baee10c298e@haskell.org> Message-ID: <062.0623605a20c234e350150aa11a804b9e@haskell.org> #10322: In ghci object code loader, linking against the previous temp dylib is not enough on OS X -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D852 -------------------------------------+------------------------------------- Changes (by George): * cc: George (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 27 15:27:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Apr 2015 15:27:49 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2310356=3A_Couldn=27t_match_type_?= =?utf-8?b?4oCYYeKAmSB3aXRoIOKAmEludOKAmSAvIOKAmGHigJkgaXMgdW50?= =?utf-8?q?ouchable_/_inside_the_constraints_=28=29?= In-Reply-To: <044.b92caf5bd3909ef5b1c4a1f89f293fe1@haskell.org> References: <044.b92caf5bd3909ef5b1c4a1f89f293fe1@haskell.org> Message-ID: <059.cf4f7d8a483e2be1900af5d37c394f6f@haskell.org> #10356: Couldn't match type ?a? with ?Int? / ?a? is untouchable / inside the constraints () -------------------------------------+------------------------------------- Reporter: radix | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Without looking too deeply, yes, this does look like a dup of #10045. Many thanks for reporting! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 27 18:04:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Apr 2015 18:04:17 -0000 Subject: [GHC] #10306: Calling reify on Any or built-in type families causes panic In-Reply-To: <049.6556ac4af659c7bd1966731677057666@haskell.org> References: <049.6556ac4af659c7bd1966731677057666@haskell.org> Message-ID: <064.7d20387165f74178a5cfb60f391d331e@haskell.org> #10306: Calling reify on Any or built-in type families causes panic -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: adamgundry Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: #9840 | Differential Revisions: Phab:D841 -------------------------------------+------------------------------------- Changes (by RyanGlScott): * cc: ryan.gl.scott@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 27 20:06:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Apr 2015 20:06:11 -0000 Subject: [GHC] #10358: ApiAnnotations : PatBind gives wrong SrcSpan for the pattern. Message-ID: <044.967c76ac07c70fa9b3a7a6f8836f8f70@haskell.org> #10358: ApiAnnotations : PatBind gives wrong SrcSpan for the pattern. -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown ApiAnnotations | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The production for `decl_no_th` starts {{{ decl_no_th :: { Located (OrdList (LHsDecl RdrName)) } : sigdecl { $1 } | '!' aexp rhs {% do { let { e = sLL $1 $> (SectionR (sL1 $1 (HsVar bang_RDR)) $2) }; pat <- checkPattern empty e; ... }}} The `e` value should be just the pattern, excluding the `rhs`, but the span created includes the `rhs`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 27 20:58:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Apr 2015 20:58:29 -0000 Subject: [GHC] #10289: compiling huge HashSet hogs memory In-Reply-To: <044.7a75381e3cbd52797d1fc50b07f81ee0@haskell.org> References: <044.7a75381e3cbd52797d1fc50b07f81ee0@haskell.org> Message-ID: <059.d13ef4a4806c32a83913792ef38f4516@haskell.org> #10289: compiling huge HashSet hogs memory -------------------------------------+------------------------------------- Reporter: zudov | Owner: Type: bug | Status: new Priority: normal | Milestone: 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 Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Well `-O0 -fno-ignore-interface-pragmas` is a bit of a funny combination. I can't say why memory use should be high then, but it's probably better to focus on `-O0` or `-O` or `-O2`, which are what people actually use. The difficulty here is it's hard to tell whether GHC is at fault, or the INLINE pragmas and/or RULEs in the libraries. I just don't have time to investigate at the moment. Maybe someone else does? I made a couple of suggestions in my previous comment. If I was investigating, those are the things I'd try first. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 27 21:09:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Apr 2015 21:09:43 -0000 Subject: [GHC] #10358: ApiAnnotations : PatBind gives wrong SrcSpan for the pattern. In-Reply-To: <044.967c76ac07c70fa9b3a7a6f8836f8f70@haskell.org> References: <044.967c76ac07c70fa9b3a7a6f8836f8f70@haskell.org> Message-ID: <059.b17729f5ca25ec63acf440e6df592bba@haskell.org> #10358: ApiAnnotations : PatBind gives wrong SrcSpan for the pattern. -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 (Parser) | Keywords: Resolution: | ApiAnnotations Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D873 -------------------------------------+------------------------------------- Changes (by alanz): * differential: => Phab:D873 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 27 22:34:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Apr 2015 22:34:11 -0000 Subject: [GHC] #10318: Cycles in class declaration (via superclasses) sometimes make sense. In-Reply-To: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> References: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> Message-ID: <060.9f85f8d9fa5c0a4c15e4d48b9b704448@haskell.org> #10318: Cycles in class declaration (via superclasses) sometimes make sense. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): OK, well I don't understand much of comment:2, but I'll take it on trust. What is difficult about recursive superclasses? I'll use the example in the Description. * '''"Given" superclasses'''. Suppose we have {{{ f :: C a => .... }}} and on f's RHS we have the constraint `(D a)`. GHC treats `(C a)` as a "given", and then adds all of `C`'s superclasses as "givens" too, and their superclasses, and so on; in case they are useful to prove the constraints arising from f's RHS. For example, `(D a)` might be a distant superclass of `(C a)`. If there are an infinite number of superclasses, this "add all superclasses" idea isn't going to work. I expect you'll say "well, in my case `Frac (Frac a) ~ Frac a`, so the second-level superclass is the same as the first". That may be true, but it requires somewhat-sophisticated reasoning; a kind of fixpoint calculation. I can see it might be possible, but the penalty for (the programmer) getting it wrong is severe; the type checker goes into a loop. * '''"Wanted" superclasses'''.Similarly, for "wanted" constraints we fluff up the superclases in case one of them has a functional dependency that will help us make progress. * '''Instance declarations'''. In an instance declaration we must cough up a witness for the superclass. This part might not be too hard. At lesat in the monomorphic cases you give, like `instance IntegralDomain Integer`, we seek an instance for `IntegralDomain (Frac Integer)`, which is just `IntegralDomain Rational`, and we have that. Again things could go badly wrong, but I think the existing superclass code might "just work". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Apr 27 23:57:49 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 27 Apr 2015 23:57:49 -0000 Subject: [GHC] #10318: Cycles in class declaration (via superclasses) sometimes make sense. In-Reply-To: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> References: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> Message-ID: <060.c7085aac18d8bea96b5f748d76cf3a87@haskell.org> #10318: Cycles in class declaration (via superclasses) sometimes make sense. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by ekmett): I definitely completely buy that it is a difficult request! I'd be happy if I had to utter all sorts of UndecidableSuperclasses incantations to get the compiler to let me even try it. Another example of where this goes wrong would be trying to define the notion of a module over a ring or rig. Every monoid forms a module over the naturals as a rig, every group forms a module over the integers, every ring forms a module over itself, etc. If you go to bake these requirements into your definition of a module or ring then you get into this same sort of cyclic definition. {{{ class Module g Integer => Group g class (Group g, Ring r) => Module g r class Module r r => Ring r }}} Right now about half the time I can fake this with newtype noise, and the other half of the time I can get away with hacks like the explicit dictionary passing through a member, but it's hard to sell that in an API to users. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 28 00:15:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Apr 2015 00:15:30 -0000 Subject: [GHC] #10359: Tuple constraint synonym led to asymptotic performance lossage Message-ID: <043.3166b2711c97df0e7fbae7668554bb97@haskell.org> #10359: Tuple constraint synonym led to asymptotic performance lossage -------------------------------------+------------------------------------- Reporter: axch | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Runtime (amd64) | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I encountered a situation where using a tuple constraint synonym produced an asymptotic runtime performance degradation, from linear to quadratic time. The enclosed Bug.hs reproduces the potentially relevant features of the problem. The function `test` there is quadratic, but should be linear. The file also contains a definition of `test2`, which differs only in eschewing the constraint synonym, and is linear, as it should be. In more detail: the program tries to count to 20,000 in a rather contrived way. It maintains a Box, which holds the current count and a function that can accept an increment and a count to produce a new count (namely, `(+)`). The function `do_step` lifts incrementation to Boxes, using their contained function to update their stored count. The first tricky thing is that the incrementing function stored in the Box is polymorphic in both arguments separately: it can accept increments that are not the same type as the stored count (and converts them). The second tricky thing is that I don't want to expose the type variable for the increment type (as opposed to the count type) to clients of the Box, so the Box's incrementing function is stored polymorphic (with an explicit forall). Finally, I want to impose the constraint `(Fractional num, Real num)` on allowable increments (even though this example only needs `Real num`). This constellation of desiderata conspires to produce quadratic performance: doubling the parameter to `test` (but not `test2`) multiplies its runtime by 4. Inspecting the heap profile indicates a growing accumulation of closures when running `test` (but not `test2`). Inspecting the generated stg (enclosed) locates a potential culprit: apparently when `do_step` (but not `do_step2`) reconstructs the Box, it changes the `func` stored there to be a fresh closure that destructures the `Numerical` constraint tuple, constructs a fresh one, and calls the function that was in that slot previously with it. I hypothesize that this accumulates as a chain that performs a linear number of such destructurings and restructurings at each increment, leading to the observed quadratic runtime and linear memory growth. Incidentally, I checked whether record wildcards were the issue (no: `test4`) and whether updating just the `obj` field solves it (yes: `test3`). Sadly, the latter solution is not directly usable in my actual application because of "Record update for insufficiently polymorphic field". -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 28 00:20:22 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Apr 2015 00:20:22 -0000 Subject: [GHC] #10359: Tuple constraint synonym led to asymptotic performance lossage In-Reply-To: <043.3166b2711c97df0e7fbae7668554bb97@haskell.org> References: <043.3166b2711c97df0e7fbae7668554bb97@haskell.org> Message-ID: <058.eb291b36bde6541d18b71d56d43f6926@haskell.org> #10359: Tuple constraint synonym led to asymptotic performance lossage -------------------------------------+------------------------------------- Reporter: axch | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by axch: Old description: > I encountered a situation where using a tuple constraint synonym > produced an asymptotic runtime performance degradation, from linear to > quadratic time. The enclosed Bug.hs reproduces the potentially > relevant features of the problem. The function `test` there is > quadratic, but should be linear. The file also contains a definition > of `test2`, which differs only in eschewing the constraint synonym, > and is linear, as it should be. > > In more detail: the program tries to count to 20,000 in a rather > contrived way. It maintains a Box, which holds the current count and > a function that can accept an increment and a count to produce a new > count (namely, `(+)`). The function `do_step` lifts incrementation to > Boxes, using their contained function to update their stored count. > > The first tricky thing is that the incrementing function stored in the > Box is polymorphic in both arguments separately: it can accept > increments that are not the same type as the stored count (and > converts them). The second tricky thing is that I don't want to > expose the type variable for the increment type (as opposed to the > count type) to clients of the Box, so the Box's incrementing function > is stored polymorphic (with an explicit forall). Finally, I want to > impose the constraint `(Fractional num, Real num)` on allowable > increments (even though this example only needs `Real num`). > > This constellation of desiderata conspires to produce quadratic > performance: doubling the parameter to `test` (but not `test2`) > multiplies its runtime by 4. Inspecting the heap profile indicates a > growing accumulation of closures when running `test` (but not > `test2`). Inspecting the generated stg (enclosed) locates a potential > culprit: apparently when `do_step` (but not `do_step2`) reconstructs > the Box, it changes the `func` stored there to be a fresh closure that > destructures the `Numerical` constraint tuple, constructs a fresh one, > and calls the function that was in that slot previously with it. I > hypothesize that this accumulates as a chain that performs a linear > number of such destructurings and restructurings at each increment, > leading to the observed quadratic runtime and linear memory growth. > > Incidentally, I checked whether record wildcards were the issue (no: > `test4`) and whether updating just the `obj` field solves it (yes: > `test3`). Sadly, the latter solution is not directly usable in my > actual application because of "Record update for insufficiently > polymorphic field". New description: I encountered a situation where using a tuple constraint synonym produced an asymptotic runtime performance degradation, from linear to quadratic time. The enclosed Bug.hs reproduces the potentially relevant features of the problem. The function `test` there is quadratic, but should be linear. The file also contains a definition of `test2`, which differs only in eschewing the constraint synonym, and is linear, as it should be. In more detail: the program tries to count to 20,000 in a rather contrived way. It maintains a Box, which holds the current count and a function that can accept an increment and a count to produce a new count (namely, `(+)`). The function `do_step` lifts incrementation to Boxes, using their contained function to update their stored count. The first tricky thing is that the incrementing function stored in the Box is polymorphic in both arguments separately: it can accept increments that are not the same type as the stored count (and converts them). The second tricky thing is that I don't want to expose the type variable for the increment type (as opposed to the count type) to clients of the Box, so the Box's incrementing function is stored polymorphic (with an explicit forall). Finally, I want to impose the constraint `(Fractional num, Real num)` on allowable increments (even though this example only needs `Real num`). This constellation of desiderata conspires to produce quadratic performance: doubling the parameter to `test` (but not `test2`) multiplies its runtime by 4. Inspecting the heap profile indicates a growing accumulation of closures when running `test` (but not `test2`). Inspecting the generated stg (enclosed) locates a potential culprit: apparently when `do_step` (but not `do_step2`) reconstructs the Box, it changes the `func` stored there to be a fresh closure that destructures the `Numerical` constraint tuple, constructs a fresh one, and calls the function that was in that slot previously with it. I hypothesize that this accumulates as a chain that performs a linear number of such destructurings and restructurings at each increment, leading to the observed quadratic runtime and linear memory growth. Incidentally, I checked whether record wildcards were the issue (no: `test4`) and whether updating just the `obj` field solves it (yes: `test3`). Sadly, the latter solution is not directly usable in my actual application because of "Record update for insufficiently polymorphic field". For reference: I compiled with `ghc -O2 Bug.hs -fprof-auto -rtsopts -ddump-to-file -ddump-simpl -ddump-st` -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 28 04:39:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Apr 2015 04:39:28 -0000 Subject: [GHC] #10360: GHC ignores command-line options if *.o and *.hi files exist Message-ID: <042.ae3687818472d7abb63ad2bd58a2abb9@haskell.org> #10360: GHC ignores command-line options if *.o and *.hi files exist -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- For example, given the module {{{#!hs module Test where foo = putStrLn "Hello World" }}} if I compile using the command {{{ ghc -c Test.hs }}} and then I compile adding the `-Wall` flag {{{ ghc -c -Wall Test.hs }}} I would expect the warning {{{ Test.hs:3:1: Warning: Top-level binding with no type signature: foo :: IO () }}} but GHC produces the message {{{ compilation IS NOT required }}} That is, the `-Wall` flag was ignored because the `Test.o` and `Test.hi` exist. (I couldn't reproduce this behaviour using gcc version 4.6.3.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 28 04:40:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Apr 2015 04:40:39 -0000 Subject: [GHC] #10360: GHC ignores command-line options if *.o and *.hi files exist In-Reply-To: <042.ae3687818472d7abb63ad2bd58a2abb9@haskell.org> References: <042.ae3687818472d7abb63ad2bd58a2abb9@haskell.org> Message-ID: <057.10f9e27d914a5714f28c42da86a508c4@haskell.org> #10360: GHC ignores command-line options if *.o and *.hi files exist -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by asr: Old description: > For example, given the module > > {{{#!hs > module Test where > > foo = putStrLn "Hello World" > }}} > > if I compile using the command > > {{{ > ghc -c Test.hs > }}} > > and then I compile adding the `-Wall` flag > > {{{ > ghc -c -Wall Test.hs > }}} > > I would expect the warning > > {{{ > Test.hs:3:1: Warning: > Top-level binding with no type signature: foo :: IO () > }}} > > but GHC produces the message > > {{{ > compilation IS NOT required > }}} > > That is, the `-Wall` flag was ignored because the `Test.o` and `Test.hi` > exist. > > (I couldn't reproduce this behaviour using gcc version 4.6.3.) New description: For example, given the module {{{#!hs module Test where foo = putStrLn "Hello World" }}} if I compile using the command {{{ ghc -c Test.hs }}} and then I compile adding the `-Wall` flag {{{ ghc -c -Wall Test.hs }}} I would expect the warning {{{ Test.hs:3:1: Warning: Top-level binding with no type signature: foo :: IO () }}} but GHC produces the message {{{ compilation IS NOT required }}} That is, the `-Wall` flag was ignored because the `Test.o` and `Test.hi` exist. (I couldn't reproduce this behaviour using GCC version 4.6.3.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 28 04:41:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Apr 2015 04:41:56 -0000 Subject: [GHC] #10360: GHC ignores command-line options if *.o and *.hi files exist In-Reply-To: <042.ae3687818472d7abb63ad2bd58a2abb9@haskell.org> References: <042.ae3687818472d7abb63ad2bd58a2abb9@haskell.org> Message-ID: <057.1bb87ee1835ea08983106415e8c728e2@haskell.org> #10360: GHC ignores command-line options if *.o and *.hi files exist -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by asr: Old description: > For example, given the module > > {{{#!hs > module Test where > > foo = putStrLn "Hello World" > }}} > > if I compile using the command > > {{{ > ghc -c Test.hs > }}} > > and then I compile adding the `-Wall` flag > > {{{ > ghc -c -Wall Test.hs > }}} > > I would expect the warning > > {{{ > Test.hs:3:1: Warning: > Top-level binding with no type signature: foo :: IO () > }}} > > but GHC produces the message > > {{{ > compilation IS NOT required > }}} > > That is, the `-Wall` flag was ignored because the `Test.o` and `Test.hi` > exist. > > (I couldn't reproduce this behaviour using GCC version 4.6.3.) New description: For example, given the module {{{#!hs module Test where foo = putStrLn "Hello World" }}} if I compile using the command {{{ ghc -c Test.hs }}} and then I compile adding the `-Wall` flag {{{ ghc -c -Wall Test.hs }}} I would expect the warning {{{ Test.hs:3:1: Warning: Top-level binding with no type signature: foo :: IO () }}} but GHC produces the message {{{ compilation IS NOT required }}} That is, the `-Wall` flag was ignored because the `Test.o` and `Test.hi` exist. (I couldn't reproduce this behaviour using GCC (the GNU Compiler Collection) version 4.6.3.) -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 28 11:28:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Apr 2015 11:28:57 -0000 Subject: [GHC] #10361: DeriveAnyClass does not fill in associated type defaults Message-ID: <047.18f32bb2aaf0fd43551e26193c9cadf9@haskell.org> #10361: DeriveAnyClass does not fill in associated type defaults -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I would expect `test1` and `test2` below to typecheck. This is a reduced test case from trying to use `DeriveAnyClass` on the `Generic` class of the `generics-sop` package, which unfortunately fails due to this bug. {{{ {-# LANGUAGE DeriveAnyClass, StandaloneDeriving, TypeFamilies #-} module Test where class C1 a where type T1 a type instance T1 a = Char class C2 a where -- equivalent to C1 type T2 a type instance T2 a = Char class C3 a where -- equivalent to C1, C2 type T3 a type instance T3 a = Char data A = B deriving C1 deriving instance C2 A instance C3 A -- fails -- test1 :: T1 A -- test1 = 'x' -- fails -- test2 :: T2 A -- test2 = 'x' -- succeeds test3 :: T3 A test3 = 'x' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 28 11:29:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Apr 2015 11:29:53 -0000 Subject: [GHC] #10361: DeriveAnyClass does not fill in associated type defaults In-Reply-To: <047.18f32bb2aaf0fd43551e26193c9cadf9@haskell.org> References: <047.18f32bb2aaf0fd43551e26193c9cadf9@haskell.org> Message-ID: <062.90c5809fc6486cd1bc7335960858e758@haskell.org> #10361: DeriveAnyClass does not fill in associated type defaults -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by kosmikus): * failure: None/Unknown => GHC rejects valid program * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 28 13:02:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Apr 2015 13:02:56 -0000 Subject: [GHC] #10318: Cycles in class declaration (via superclasses) sometimes make sense. In-Reply-To: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> References: <045.d1ea23f42aeb71ba3ba0dcf3c978cb36@haskell.org> Message-ID: <060.073fd817c26b76488cafd8aaf75a29fe@haskell.org> #10318: Cycles in class declaration (via superclasses) sometimes make sense. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): Hmm. In all the examples you give, one can statically enumerate the transitive superclasses. Fro example in comment:5 we have {{{ Ring r ==> Module r r ==> Group r ==> Module r Integer ==> Group r -- STOP Ring Integer ==> Module Integer Integer ==> Group Integer ==> Module Integer -- STOP Ring Integer -- STOP Ring r -- STOP }}} Here I am writing {{{ Class a b ==> Superclass1 a b Superclass2 a b }}} with nesting to describe nested superclasses. `STOP` means that we've seen this before, so going on generating superclasses will reveal nothing new. Notice that I reach a fixpoint for every instantiation of `r`. Indeed I can precompute all these transitive superclasses, once and for all, at the class declaration. Similarly for `IntegralDomain`, but I have to use the equalities: class (Frac (Frac a) ~ Frac a, Fractional (Frac a), IntegralDomain (Frac a)) => IntegralDomain a where {{{ ID a ==> Frac (Frac a) ~ Frac a -- (1) Fractional (Frac a) ==> superclasses of Fractional ID (Frac a) ==> Frac (Frac (Frac a)) ~ Frac (Frac a) -- STOP; a consequence of (1) ID (Frac (Frac a) -- rewrite with (1) = ID (Frac a) -- STOP Fractional (Frac (Frac a)) -- rewrite with (1) = Fractional (Frac a) -- STOP }}} In the examples you care about, does the collection of superclasses always statically terminate in this way? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 28 14:11:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Apr 2015 14:11:26 -0000 Subject: [GHC] #10361: DeriveAnyClass does not fill in associated type defaults In-Reply-To: <047.18f32bb2aaf0fd43551e26193c9cadf9@haskell.org> References: <047.18f32bb2aaf0fd43551e26193c9cadf9@haskell.org> Message-ID: <062.e269b2e662a14e6904eb21dda30299da@haskell.org> #10361: DeriveAnyClass does not fill in associated type defaults -------------------------------------+------------------------------------- Reporter: kosmikus | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => dreixel Comment: Pedro, this is your bag, right? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 28 14:27:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Apr 2015 14:27:34 -0000 Subject: [GHC] #10362: Make tuple constraints into a class Message-ID: <046.37ffd03861c08e5d28fe4001f4a37725@haskell.org> #10362: Make tuple constraints into a class -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- At the moment GHC treats tuple constraints specially. If you grep for `TuplePred` you'll see this. But the special treatment is strange; see the confusion between constraint tuples and ordinary tuples in #9858. But I now realise that we can sweep away all this nonsense. Suppose we declare {{{ module GHC.Classes where class (c1, c2) => (,) c1 c2 instance (c1, c2) => (,) c1 c2 class (c1, c2, c3) => (,) c1 c2 c3 instance (c1, c2, c3) => (,) c1 c2 c3 }}} and so on. (This is analogous the tuple data type declarations in `GHC.Tuple`.) Notice that: * `GHC.Classes,(,)` is a class, of kind `Constraint -> Constraint -> Constraint`. quite distinct from `GHC.Tuple.(,)`, whose kind is `* -> * -> *`. * `GHC.Classes.(,)` is a perfectly ordinary class, with no methods and two superclasses. * So all the usual superclass stuff applies. * If you have a given `Ord a` then you have a given `Eq a` (its superclass). Similarly if you have a given `(,) c1 c2` then you also have given `c1` and `given `c2`. * If you want to construct a dictionary of type `Ord a` (a "wanted"), you must supply a dictionary of type `Eq a`. Similarly, if you want to construct a dictionary of type `(,) c1 c2` then you must supply `c1` and `c2`. * I have written `(,) c1 c2` to stress that there is a class `GHC.Classes.(,)`, but we'll also allow the concrete syntax `(c1,c2)` instead. * Nevertheless the syntactic form `(c1, c2) => blah` is just sugar for `c1 => c2 => blah` (a type with two, curried constraints); it does not stand a type with a single constraint. Otherwise the instance {{{ instance (c1,c2) => (c1,c2) }}} would be the identity function! The key thing is that, aside from special syntax, `(,)` is a perfectly ordinary class, so we can simply delete all the special treatment of `TuplePred`. (Implicit parameters are also treated as a special class, incidentally.) There should be no user-visible effects. But I think it would cure the worst aspects of #10359, as well as cleaning up `TypeRep` confusion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 28 16:20:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Apr 2015 16:20:45 -0000 Subject: [GHC] #10359: Tuple constraint synonym led to asymptotic performance lossage In-Reply-To: <043.3166b2711c97df0e7fbae7668554bb97@haskell.org> References: <043.3166b2711c97df0e7fbae7668554bb97@haskell.org> Message-ID: <058.cbda108442cae36eeef591f457f278f1@haskell.org> #10359: Tuple constraint synonym led to asymptotic performance lossage -------------------------------------+------------------------------------- Reporter: axch | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): First of all, very nice example. Thank you for making it so small and easy to work with. I can see what's happening. The key part is what happens here: {{{ do_step4 :: (Numerical num) => num -> Box a -> Box a do_step4 number Box{ func = f, obj = x} = Box{ func = f, obj = f number x } }}} After elaboration (ie making dictionaries explicit) we get this: {{{ do_step4 dn1 number (Box {func = f, obj = x }) = Box { func = \dn2 -> f ( case dn2 of (f,r) -> f , case dn2 of (f,r) -> r) , obj = f dn1 number x } }}} That's odd! We expected this: {{{ do_step4 dn1 number (Box {func = f, obj = x }) = Box { func = f , obj = f dn1 number x } }}} And indeed, the allocation of all those `\dn2` closures is what is causing the problem. So we are missing this optimisation: {{{ (case dn2 of (f,r) -> f, case dn2 of (f,r) -> r) ===> dn2 }}} If we did this, then the lambda would look like `\dn2 -> f dn2` which could eta-reduce to `f`. But there are at least three problems: * The tuple transformation above is hard to spot * The tuple transformation is not quite semantically right; if `dn2` was bottom, the LHS and RHS are different * The eta-reduction isn't quite semantically right: if `f` ws bottom, the LHS and RHS are different. You might argue that the latter two can be ignored because dictionary arguments are special; indeed we often toy with making them strict. But perhaps a better way to avoid the tuple-transformation issue would be not to construct that strange expression in the first place. Where is it coming from? It comes from the call to `f` (admittedly applied to no arguments) in `Box { ..., func = f }`. GHC needs a dictionary for `(Numerical dum)` (I changed the name of the type variable in `func`'s type in the definition of `Box`). Since it's just a pair GHC says "fine, I'll build a pair, out of `Fractional dum` and `Real dum`. How does it get those dictionaries? By selecting the components of the `Franctional dum` passed to `f`. If GHC said instead "I need `Numerical dum` and behold I have one in hand, it'd be much better. It doesn't because tuple constraints are treated specially. But if we adopted the idea in #10362, we would (automatically) get to re-use the `Numerical dum` constraint. That would leave us with eta reduction, which is easier. As to what will get you rolling, a good solution is `test3`, which saves instantiating and re-generalising `f`. The key thing is to update all the fields ''except'' the polymorphic `func` field. I'm surprised you say that it doesn't work. Can you give a (presumably more complicated) example to demonstrate? Maybe there's a separate bug! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Apr 28 18:47:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 28 Apr 2015 18:47:05 -0000 Subject: [GHC] #10363: ApiAnnotations : HsForAllTy discards parens Message-ID: <044.e0d8e18d8eab38aa60d91f2451cce8b6@haskell.org> #10363: ApiAnnotations : HsForAllTy discards parens -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: bug | Status: new Priority: normal | Milestone: 7.10.2 Component: Compiler | Version: 7.10.1 Keywords: | Operating System: Unknown/Multiple ApiAnnotations | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The annotations for the following code {{{#!hs pTokenCostStr :: forall a .((Show a) => [a] -> Int -> String) }}} have detached annotations for the parens around `(Show a)... String`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 01:28:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 01:28:17 -0000 Subject: [GHC] #10364: Feature request: Add support for FMA Message-ID: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> #10364: Feature request: Add support for FMA -------------------------------------+------------------------------------- Reporter: lerkok | Owner: ekmett Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.11 Component: Core | Operating System: Unknown/Multiple Libraries | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- FMA (fused-multiply-add) has been around for quite some-time, and is natively supported by many of the newer processors. It's an operation that is heavily used in HPC applications. I think it's time for Haskell to have native support for it as well. Ideally, it should be added to the `Num` class as a method. Assuming that is a possibility, we would have the following signature and default definition: {{{#!hs class Num a where ... fma :: a -> a -> a -> a fma x y z = x * y + z }}} Except of course the `Float` and `Double` instances would ensure that the rounding is done only once. If adding it to the `Num` class is not an option, then `RealFloat` class would be the next best place; and perhaps that's arguably also a better place because those types are the ones one usually have in mind when using FMA. I think either `Num` or `RealFloat` would be fine choices. Implementation: * If the underlying architecture supports it (which is very common), directly emit FMA instruction * Otherwise, FFI out to C and use `fma` and `fmaf` from the math library A direct software implementation might also be possible for platforms where neither choice above is an option, but that bridge can be crossed when we get there. As a final note; while supporting these functions might seem going-out-of- our-way; it is indeed a big selling point in HPC applications. Furthermore, hardware manufacturers are putting big resources to make these supported naively in the instruction sets. Supporting FMA right out of the box would be a very good step in wider adaptation of Haskell in the HPC community. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 01:29:14 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 01:29:14 -0000 Subject: [GHC] #10364: Feature request: Add support for FMA In-Reply-To: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> References: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> Message-ID: <060.4f5c8500635b4c6faf73bc3e6a58fce0@haskell.org> #10364: Feature request: Add support for FMA -------------------------------------+------------------------------------- Reporter: lerkok | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by lerkok): * cc: erkokl@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 01:30:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 01:30:24 -0000 Subject: [GHC] #10364: Feature request: Add support for FMA In-Reply-To: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> References: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> Message-ID: <060.3e677916ba6a1be5a955bac71a699db4@haskell.org> #10364: Feature request: Add support for FMA -------------------------------------+------------------------------------- Reporter: lerkok | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by lerkok: Old description: > FMA (fused-multiply-add) has been around for quite some-time, and is > natively supported by many of the newer processors. It's an operation > that is heavily used in HPC applications. I think it's time for Haskell > to have native support for it as well. > > Ideally, it should be added to the `Num` class as a method. Assuming that > is a possibility, we would have the following signature and default > definition: > > {{{#!hs > class Num a where > ... > fma :: a -> a -> a -> a > fma x y z = x * y + z > }}} > > Except of course the `Float` and `Double` instances would ensure that the > rounding is done only once. > > If adding it to the `Num` class is not an option, then `RealFloat` class > would be the next best place; and perhaps that's arguably also a better > place because those types are the ones one usually have in mind when > using FMA. > > I think either `Num` or `RealFloat` would be fine choices. > > Implementation: > > * If the underlying architecture supports it (which is very common), > directly emit FMA instruction > * Otherwise, FFI out to C and use `fma` and `fmaf` from the math > library > > A direct software implementation might also be possible for platforms > where neither choice above is an option, but that bridge can be crossed > when we get there. > > As a final note; while supporting these functions might seem going-out- > of-our-way; it is indeed a big selling point in HPC applications. > Furthermore, hardware manufacturers are putting big resources to make > these supported naively in the instruction sets. Supporting FMA right out > of the box would be a very good step in wider adaptation of Haskell in > the HPC community. New description: FMA (fused-multiply-add) has been around for quite some-time, and is natively supported by many of the newer processors. It's an operation that is heavily used in HPC applications. I think it's time for Haskell to have native support for it as well. Ideally, it should be added to the `Num` class as a method. Assuming that is a possibility, we would have the following signature and default definition: {{{#!hs class Num a where ... fma :: a -> a -> a -> a fma x y z = x * y + z }}} Except of course the `Float` and `Double` instances would ensure that the rounding is done only once. If adding it to the `Num` class is not an option, then `RealFloat` class would be the next best place; and perhaps that's arguably also a better place because those types are the ones one usually has in mind when using FMA. I think either `Num` or `RealFloat` would be fine choices. Implementation: * If the underlying architecture supports it (which is very common), directly emit FMA instruction * Otherwise, FFI out to C and use `fma` and `fmaf` from the math library A direct software implementation might also be possible for platforms where neither choice above is an option, but that bridge can be crossed when we get there. As a final note; while supporting these functions might seem going-out-of- our-way; it is indeed a big selling point in HPC applications. Furthermore, hardware manufacturers are putting big resources to make these supported naively in the instruction sets. Supporting FMA right out of the box would be a very good step in wider adaptation of Haskell in the HPC community. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 01:31:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 01:31:17 -0000 Subject: [GHC] #10364: Feature request: Add support for FMA In-Reply-To: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> References: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> Message-ID: <060.7d28aece7099a3ed96b43de442eae95d@haskell.org> #10364: Feature request: Add support for FMA -------------------------------------+------------------------------------- Reporter: lerkok | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by lerkok: Old description: > FMA (fused-multiply-add) has been around for quite some-time, and is > natively supported by many of the newer processors. It's an operation > that is heavily used in HPC applications. I think it's time for Haskell > to have native support for it as well. > > Ideally, it should be added to the `Num` class as a method. Assuming that > is a possibility, we would have the following signature and default > definition: > > {{{#!hs > class Num a where > ... > fma :: a -> a -> a -> a > fma x y z = x * y + z > }}} > > Except of course the `Float` and `Double` instances would ensure that the > rounding is done only once. > > If adding it to the `Num` class is not an option, then `RealFloat` class > would be the next best place; and perhaps that's arguably also a better > place because those types are the ones one usually has in mind when using > FMA. > > I think either `Num` or `RealFloat` would be fine choices. > > Implementation: > > * If the underlying architecture supports it (which is very common), > directly emit FMA instruction > * Otherwise, FFI out to C and use `fma` and `fmaf` from the math > library > > A direct software implementation might also be possible for platforms > where neither choice above is an option, but that bridge can be crossed > when we get there. > > As a final note; while supporting these functions might seem going-out- > of-our-way; it is indeed a big selling point in HPC applications. > Furthermore, hardware manufacturers are putting big resources to make > these supported naively in the instruction sets. Supporting FMA right out > of the box would be a very good step in wider adaptation of Haskell in > the HPC community. New description: FMA (fused-multiply-add) has been around for quite some-time, and is natively supported by many of the newer processors. It's an operation that is heavily used in HPC applications. I think it's time for Haskell to have native support for it as well. Ideally, it should be added to the `Num` class as a method. Assuming that is a possibility, we would have the following signature and default definition: {{{#!hs class Num a where ... fma :: a -> a -> a -> a fma x y z = x * y + z }}} Except of course the `Float` and `Double` instances would ensure that the rounding is done only once. If adding it to the `Num` class is not an option, then `RealFloat` class would be the next best place; and perhaps that's arguably also a better place because those types are the ones one usually has in mind when using FMA. I think either `Num` or `RealFloat` would be fine choices. Implementation: * If the underlying architecture supports it (which is very common), directly emit FMA instruction * Otherwise, FFI out to C and use `fma` and `fmaf` from the math library A direct software implementation might also be possible for platforms where neither choice above is an option, but that bridge can be crossed when we get there. As a final note; while supporting these functions might seem going-out-of- our-way; it is indeed a big selling point in HPC applications. Furthermore, hardware manufacturers are putting big resources to make these supported natively in the instruction sets. Supporting FMA right out of the box would be a very good step in wider adaptation of Haskell in the HPC community. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 02:00:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 02:00:51 -0000 Subject: [GHC] #10364: Feature request: Add support for FMA In-Reply-To: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> References: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> Message-ID: <060.bb011306dbccb5355d7b0249c29a0d23@haskell.org> #10364: Feature request: Add support for FMA -------------------------------------+------------------------------------- Reporter: lerkok | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): This probably should go out through a standard libraries@ proposal process first, to get a sense of how willing the community would be to accept a change that far up the chain. You may get some horribly long `fusedMultiplyAdd` name though. =) I could definitely see putting it in RealFloat. We had a proposal last year for adding things like `expm1` and `log1p`, etc. which passed, which will involve adding members nearby. Warning though: when we lobbied for `expm1` the comunity pushed back against having sensible defaults like the one you mention here and preferred leaving it undefined, to prompt people to fill them in proactively. I'm not sure that is/was a good idea, but some folks fought pretty hard against defaults that might lose precision favoring bottoms instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 03:21:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 03:21:08 -0000 Subject: [GHC] #10235: Get profiling info without stopping program In-Reply-To: <046.6c9d95866bf21a8a5f1fe2d9c5fba073@haskell.org> References: <046.6c9d95866bf21a8a5f1fe2d9c5fba073@haskell.org> Message-ID: <061.8ba564316c8ea13fafd2c6c272e8b2b5@haskell.org> #10235: Get profiling info without stopping program -------------------------------------+------------------------------------- Reporter: mwotton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by maoe): * cc: maoe@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 04:22:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 04:22:00 -0000 Subject: [GHC] #8206: Add support for Portable Native Client In-Reply-To: <044.0e9301156a0eb3e01f0cb8995b726d63@haskell.org> References: <044.0e9301156a0eb3e01f0cb8995b726d63@haskell.org> Message-ID: <059.8848044bb97dedf3d4a00b2ba8e44466@haskell.org> #8206: Add support for Portable Native Client -------------------------------------+------------------------------------- Reporter: guest | Owner: Alex Type: feature request | Sayers Priority: normal | Status: new Component: Compiler | Milestone: Resolution: | Version: Operating System: Unknown/Multiple | Keywords: NaCl PNaCl Type of failure: None/Unknown | Portable Native Client pexe Blocked By: | Architecture: Related Tickets: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by tomberek): * cc: tomberek@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 04:28:05 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 04:28:05 -0000 Subject: [GHC] #10364: Feature request: Add support for FMA In-Reply-To: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> References: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> Message-ID: <060.49c29669d34476548de525560650e643@haskell.org> #10364: Feature request: Add support for FMA -------------------------------------+------------------------------------- Reporter: lerkok | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by lerkok): Ah, excellent. Perhaps fma can be tacked on to that proposal. I was reading through https://wiki.haskell.org/Library_submissions and it actually suggests proposals should now be filed as tickets; unless I'm misreading it. There used to be an e-mail to the libraries@ mailing list I think; is that still the way to go? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 05:10:53 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 05:10:53 -0000 Subject: [GHC] #10364: Feature request: Add support for FMA In-Reply-To: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> References: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> Message-ID: <060.8c689f253e8744b557a063f4dcd8b206@haskell.org> #10364: Feature request: Add support for FMA -------------------------------------+------------------------------------- Reporter: lerkok | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): The libraries@ list is still here. We typically escalate anything to it that seems remotely controversial to get a sense of community feedback, buy-in, counter-proposals, etc. That is especially true for things that affect the types and classes in the Haskell Report, like this. https://wiki.haskell.org/Library_submissions mentions it in section 7. If the CLC decides that the discussion must be discussed with the libraries@ mailing list, the original proposer may be asked to moderate the libraries@ mailing list discussion. The general format for this is: * Send your proposal by email to the libraries at haskell.org mailing list (which you need to subscribe to before posting). * Set a deadline for discussion (no less than two weeks), and act as chair/moderator for the discussion. * Following discussion, it's the responsibility of the core libraries committee to determine if the proposal should be accepted. Send an email to the core libraries committee requesting a decision, optionally including your own summary of the mailing list discussion. * From that point forward, the CLC and maintainer will again be responsible for making a decision on how to proceed, and will inform the proposer and the mailing list. Possible decisions include acceptance, rejection, and requesting a patch be provided. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 05:11:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 05:11:17 -0000 Subject: [GHC] #10364: Feature request: Add support for FMA In-Reply-To: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> References: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> Message-ID: <060.6b6516b3ef4445e4e220895a14ff96c4@haskell.org> #10364: Feature request: Add support for FMA -------------------------------------+------------------------------------- Reporter: lerkok | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.11 Resolution: | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ekmett): * keywords: => report-impact -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 05:12:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 05:12:35 -0000 Subject: [GHC] #10364: Feature request: Add support for FMA In-Reply-To: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> References: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> Message-ID: <060.e26b5a60b3c55b7326768280840d12a1@haskell.org> #10364: Feature request: Add support for FMA -------------------------------------+------------------------------------- Reporter: lerkok | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.11 Resolution: | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): That said, creating a ticket like this is likely very much the right place to start. It ensures it can't fall off our radar forever. =) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 07:23:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 07:23:58 -0000 Subject: [GHC] #10364: Feature request: Add support for FMA In-Reply-To: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> References: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> Message-ID: <060.488d0943d1c9fdfde0637d1eb62a2782@haskell.org> #10364: Feature request: Add support for FMA -------------------------------------+------------------------------------- Reporter: lerkok | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.11 Resolution: | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by lerkok): Just sent a proposal to the mailing list: https://mail.haskell.org/pipermail/libraries/2015-April/025574.html Hopefully fma can make it in together with expm1 and friends.. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 08:58:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 08:58:00 -0000 Subject: [GHC] #10364: Feature request: Add support for FMA In-Reply-To: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> References: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> Message-ID: <060.9d7903612414d3b458c9a358b874603e@haskell.org> #10364: Feature request: Add support for FMA -------------------------------------+------------------------------------- Reporter: lerkok | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.11 Resolution: | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Lemming): `RealFloat` would exclude an `instance Complex`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 12:17:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 12:17:42 -0000 Subject: [GHC] #10340: Type inference regression with Any In-Reply-To: <043.6973fe6949fc7fde77cc0902c496af6e@haskell.org> References: <043.6973fe6949fc7fde77cc0902c496af6e@haskell.org> Message-ID: <058.a440c0285f99ee71b560024581fcfd10@haskell.org> #10340: Type inference regression with Any -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by goldfire): I just took a look, and the problem here is fairly simple. I'm not sure what the right solution is, though. Here are the constraints that get to the solver: {{{ [W] $dMonadState_a1UB :: MonadState s_a1Uy[tau:1] m_a1Uz[tau:1] (CNonCanonical) [W] cobox_a1UD :: m_a1Uz[tau:1] ~ State Any (CNonCanonical) [W] cobox_a1UE :: s_a1Uy[tau:1] ~ Any (CNonCanonical) }}} In short order, we get a fuv for `Any` {{{ [W] cobox_a1UT :: Any ~ s_a1US[fuv:0] (CFunEqCan) }}} and a unification for `m_a1Uz`. {{{ setWantedTyBind m_a1Uz[tau:1] := State s_a1US[fuv:0] }}} The solver then attacks `cobox_a1UE`, which canonicalizes to {{{ [W] cobox_a1UW :: s_a1US[fuv:0] ~ s_a1Uy[tau:1] (CTyEqCan) }}} Because an fuv is on the left, no unification takes place. See `Note [Orient equalities with flatten-meta-vars on the left]` in !TcFlatten. When we then canonicalize the `MonadState` constraint, we get {{{ [W] $dMonadState_a1UB :: MonadState s_a1Uy[tau:1] (State s_a1US[fuv:0]) (CDictCan) }}} which can't get solved and is reported to the user. The "obvious" solution to me is to re-orient the `CTyEqCan` above (`cobox_a1UW`) so that unification gets the job done for us. But that `Note [Orient equalities with flatten-meta-vars on the left]` in !TcFlatten tells me not to. Another solution is to allow a Wanted to rewrite a Wanted here, but we've previously been convinced that this is a bad idea. Incidentally, I don't think this problem is at all restricted to `Any`. I haven't tested any other code, but I imagine this will bite whenever we want an instance with repeated pattern variables to match a type with irreducible type families. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 12:22:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 12:22:16 -0000 Subject: [GHC] #10340: Type inference regression with Any In-Reply-To: <043.6973fe6949fc7fde77cc0902c496af6e@haskell.org> References: <043.6973fe6949fc7fde77cc0902c496af6e@haskell.org> Message-ID: <058.60b0c176844c965e448b045dcac5b94c@haskell.org> #10340: Type inference regression with Any -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): Exactly. I have a big patch in-flight to fix this and #10009. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 13:00:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 13:00:28 -0000 Subject: [GHC] #10365: Make Semigroup as a superclass of Monoid Message-ID: <044.91d55a6870e3dd391fca3990f924a9d5@haskell.org> #10365: Make Semigroup as a superclass of Monoid -------------------------------------+------------------------------------- Reporter: gidyn | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.10.1 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- See http://haskell.1045720.n5.nabble.com/Proposal-Make-Semigroup-as-a -superclass-of-Monoid-td5767835.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 13:29:30 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 13:29:30 -0000 Subject: [GHC] #10359: Tuple constraint synonym led to asymptotic performance lossage In-Reply-To: <043.3166b2711c97df0e7fbae7668554bb97@haskell.org> References: <043.3166b2711c97df0e7fbae7668554bb97@haskell.org> Message-ID: <058.bd6c6f40398224fd737a5e3df2671c3a@haskell.org> #10359: Tuple constraint synonym led to asymptotic performance lossage -------------------------------------+------------------------------------- Reporter: axch | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by axch): In my actual use case, `test3` doesn't compile. The difference is that `Box` is also existentially quantified over the type of `obj`, because I want a heterogeneous collection of `Box`es. Translated to this context, the compilation error is {{{ Bug2.hs:51:29: Record update for insufficiently polymorphic field: obj :: a In the expression: b {obj = func number obj} In an equation for `do_step3': do_step3 number b@(Box {..}) = b {obj = func number obj} }}} Offending source file enclosed. I reproduce `test` and `test4`, just to confirm that they still execute but with bad asymptotics; I elide `test2`, which is what I ended up doing to get rolling. Is this compilation error also a bug? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 13:55:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 13:55:22 -0000 Subject: [GHC] #10366: Post link to MacOS binary of 7.10 Message-ID: <047.96813fefee3197627308f4e0ad81012c@haskell.org> #10366: Post link to MacOS binary of 7.10 -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: task | Status: new Priority: highest | Milestone: 7.10.2 Component: | Version: 7.10.1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- More than a month after GHC 7.10 is released, there still isn't a binary linked for MacOS at https://www.haskell.org/ghc/download_ghc_7_10_1#binaries. I see that the binary exists in https://downloads.haskell.org/~ghc/7.10.1/, but that link is critical to finding it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 14:05:07 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 14:05:07 -0000 Subject: [GHC] #10346: Cross-module SpecConstr In-Reply-To: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> References: <046.b576f13f2450fed85380ce289fdfae5b@haskell.org> Message-ID: <061.bff264a64f064f78b6587e766c9ccbbb@haskell.org> #10346: Cross-module SpecConstr -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b61562feb87689a202118ca08ef270422c69dcc2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b61562feb87689a202118ca08ef270422c69dcc2" Seed SpecConstr from local calls Seed SpecConstr based on *local* calls as well as *RHS* calls. See Note [Seeding top-level recursive groups]. The change here is mentioned here: NB: before Apr 15 we used (a) only, but Dimitrios had an example where (b) was crucial, so I added that. This is a pretty small change, requested by Dimitrios, that adds SpecConstr call patterns from the rest of the module, as well as ones from the RHS. Still to come: #10346. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 14:05:07 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 14:05:07 -0000 Subject: [GHC] #10340: Type inference regression with Any In-Reply-To: <043.6973fe6949fc7fde77cc0902c496af6e@haskell.org> References: <043.6973fe6949fc7fde77cc0902c496af6e@haskell.org> Message-ID: <058.a9703fe598d0b9d3e97c0de73e3999d2@haskell.org> #10340: Type inference regression with Any -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a1275a762ec04c1159ae37199b1c8f998a5c5499/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a1275a762ec04c1159ae37199b1c8f998a5c5499" Improve improvement in the constraint solver This regrettably-big patch substantially improves the way in which "improvement" happens in the constraint solver. It was triggered by trying to crack Trac #10009, but it turned out to solve #10340 as well. The big picture, with several of the trickiest examples, is described in Note [The improvement story] in TcInteract. The major change is this: * After solving we explicitly try "improvement", by - making the unsolved Wanteds into Deriveds - allowing Deriveds to rewrite Deriveds This more aggressive rewriting "unlocks" some extra guess-free unifications. * The main loop is in TcInteract.solveSimpleWanteds, but I also ended up refactoring TcSimplify.simpl_loop, and its surrounding code. Notably, any insolubles from the Givens are pulled out and treated separately, rather than staying in the inert set during the solveSimpleWanteds loop. There are a lot of follow-on changes * Do not emit generate Derived improvements from Wanteds. This saves work in the common case where they aren't needed. * For improvement we should really do type-class reduction on Derived constraints in doTopReactDict. That entailed changing the GenInst constructor a bit; a local and minor change * Some annoying faffing about with dropping derived constraints; see dropDerivedWC, dropDerivedSimples, dropDerivedInsols, and their Notes. * Some substantial refactoring in TcErrors.reportWanteds. This work wasn't strictly forced, but I got sucked into it. All the changes are in TcErrors. * Use TcS.unifyTyVar consistently, rather than setWantedTyBind, so that unifications are properly tracked. * Refactoring around solveWantedsTcM, solveWantedsAndDrop. They previously guaranteed a zonked result, but it's more straightforward for clients to zonk. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 14:05:07 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 14:05:07 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.432999bc85c2d2f1e53f427ba96f7060@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10226 | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"a1275a762ec04c1159ae37199b1c8f998a5c5499/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="a1275a762ec04c1159ae37199b1c8f998a5c5499" Improve improvement in the constraint solver This regrettably-big patch substantially improves the way in which "improvement" happens in the constraint solver. It was triggered by trying to crack Trac #10009, but it turned out to solve #10340 as well. The big picture, with several of the trickiest examples, is described in Note [The improvement story] in TcInteract. The major change is this: * After solving we explicitly try "improvement", by - making the unsolved Wanteds into Deriveds - allowing Deriveds to rewrite Deriveds This more aggressive rewriting "unlocks" some extra guess-free unifications. * The main loop is in TcInteract.solveSimpleWanteds, but I also ended up refactoring TcSimplify.simpl_loop, and its surrounding code. Notably, any insolubles from the Givens are pulled out and treated separately, rather than staying in the inert set during the solveSimpleWanteds loop. There are a lot of follow-on changes * Do not emit generate Derived improvements from Wanteds. This saves work in the common case where they aren't needed. * For improvement we should really do type-class reduction on Derived constraints in doTopReactDict. That entailed changing the GenInst constructor a bit; a local and minor change * Some annoying faffing about with dropping derived constraints; see dropDerivedWC, dropDerivedSimples, dropDerivedInsols, and their Notes. * Some substantial refactoring in TcErrors.reportWanteds. This work wasn't strictly forced, but I got sucked into it. All the changes are in TcErrors. * Use TcS.unifyTyVar consistently, rather than setWantedTyBind, so that unifications are properly tracked. * Refactoring around solveWantedsTcM, solveWantedsAndDrop. They previously guaranteed a zonked result, but it's more straightforward for clients to zonk. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 14:06:37 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 14:06:37 -0000 Subject: [GHC] #10340: Type inference regression with Any In-Reply-To: <043.6973fe6949fc7fde77cc0902c496af6e@haskell.org> References: <043.6973fe6949fc7fde77cc0902c496af6e@haskell.org> Message-ID: <058.10c3d116ba7e0f819d57b51a7359321d@haskell.org> #10340: Type inference regression with Any -------------------------------------+------------------------------------- Reporter: akio | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by simonpj): Not clear whether to merge this to 7.10. It's a big patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 14:10:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 14:10:35 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.8d3d1dd01c7ff9dccea0a1966fa9f044@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10226 | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"d4a926ba52fbbbdeaadfff7c86e7175c8cc1b97c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d4a926ba52fbbbdeaadfff7c86e7175c8cc1b97c" Test Trac #10226 Fixed by the patch for #10009 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 14:10:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 14:10:35 -0000 Subject: [GHC] #10226: Regression in constraint solver from 7.8 to 7.10 In-Reply-To: <044.82bc8202e2a2f838b899ceb019365912@haskell.org> References: <044.82bc8202e2a2f838b899ceb019365912@haskell.org> Message-ID: <059.7bfafbde0150a8a704f7e61024f0a748@haskell.org> #10226: Regression in constraint solver from 7.8 to 7.10 -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: 7.10.1 checker) | Keywords: Resolution: duplicate | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #10009 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"d4a926ba52fbbbdeaadfff7c86e7175c8cc1b97c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d4a926ba52fbbbdeaadfff7c86e7175c8cc1b97c" Test Trac #10226 Fixed by the patch for #10009 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 14:15:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 14:15:01 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.faa69d1ada8ac20ca4a4f6b1c5b89214@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10226 | -------------------------------------+------------------------------------- Comment (by simonpj): Phew! That was ''far'' more work than I expected. It's not clear whether to merge this to 7.10 * It probably won't merge cleanly; but we can probably deal with that if necessary * It's a big patch, so there's always a risk of messing something else up It fixes: #10009, #10226, #10340. Opinions? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 14:18:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 14:18:02 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.1317be485b2975bf45cdcb89d0558d6f@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10226 | -------------------------------------+------------------------------------- Comment (by simonpj): I tried to test `hlist-0.3.4.1`, but stalled on {{{ Data/HList/HList.hs:55:1: The associated type ?UnPrime? mentions none of the type or kind variables of the class ?ConvHList a? In the class declaration for ?ConvHList? }}} which is an absolutely correct error message. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 14:20:26 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 14:20:26 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.ce7d74f945740c8c189f144dc83e9e1c@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10226 | -------------------------------------+------------------------------------- Comment (by kosmikus): First of all, thanks a lot, Simon. I'll try to build HEAD soon and see if I can test this. I would obviously like this to be merged into 7.10, because the bugs triggered by this, while seemingly exotic, are still regressions. And 7.12 is probably a long time away ... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 14:22:40 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 14:22:40 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.627522dbe3068863acedf3fe283e22bf@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10226 | -------------------------------------+------------------------------------- Comment (by kosmikus): Re `hlist`: I'm surprised this ever worked. What I usually do is to define the `UnPrime`-equivalent outside of the class (as a type family), and `Prime` within. I hadn't considered that there may have been GHC versions that would have allowed both to be defined within the class. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 14:23:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 14:23:59 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families In-Reply-To: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> References: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> Message-ID: <060.690f1141c7e86c9a83e0d005c75cfe94@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.2 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: GHC rejects | Test Case: valid program | Blocking: Blocked By: | Differential Revisions: Related Tickets: #10226 | -------------------------------------+------------------------------------- Comment (by simonpj): I'm surprised too; presumably a bug in earlier GHC's let it sneak through -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 15:48:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 15:48:51 -0000 Subject: [GHC] #10364: Feature request: Add support for FMA In-Reply-To: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> References: <045.fa1e3beab5c1d47ea5c2dd5a3c6fca19@haskell.org> Message-ID: <060.9ab812991a0709b73867b4fa9c4bbed1@haskell.org> #10364: Feature request: Add support for FMA -------------------------------------+------------------------------------- Reporter: lerkok | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.11 Resolution: | Keywords: report- Operating System: Unknown/Multiple | impact Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): Good point. That probably pushes it up to Floating or Num then. In Num you could use it for accelerated modular arithmetic as well, which has nothing to do with floating point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 16:12:48 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 16:12:48 -0000 Subject: [GHC] #10359: Tuple constraint synonym led to asymptotic performance lossage In-Reply-To: <043.3166b2711c97df0e7fbae7668554bb97@haskell.org> References: <043.3166b2711c97df0e7fbae7668554bb97@haskell.org> Message-ID: <058.898305122b007b4c740ab83a101f3e76@haskell.org> #10359: Tuple constraint synonym led to asymptotic performance lossage -------------------------------------+------------------------------------- Reporter: axch | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Runtime | (amd64) performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Ah I see. Well that rules out using record update. What happens if you simulate tuple predicates, thus: {{{ class (Fractional a, Real a) => Numerical a instance (Fractional a, Real a) => Numerical a }}} I think that'll work. You need `FlexibleInstances`, `UndecidableInstances`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Apr 29 19:31:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 29 Apr 2015 19:31:43 -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.cee669d43d1d9d2f27d58230b0bef8e6@haskell.org> #10343: Make Typeable track kind information better -------------------------------------+------------------------------------- Reporter: oerjan | Owner: goldfire Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: typeOf :: Related Tickets: #9858 | Typeable (a::k) => Proxy a -> | TypeRep | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): I've updated [wiki:Typeable]. See the new Proposed API section, and the new Step 3. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 30 07:11:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Apr 2015 07:11:06 -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.90ab555fdc7792b7fb987cdf5b5abb8e@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 Revisions: -------------------------------------+--------------------------------- Comment (by erikd): Version 3.5.2 of llvm went into Debian Unstable on 2015/04/30 and will likely hit Debian Testing in 2-3 weeks. If anyone hits this in Debian Stable they shold reopen https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782868 asking for a Debian Stable backport of the bug fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 30 08:22:01 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Apr 2015 08:22:01 -0000 Subject: [GHC] #10351: Inferred type is rejected In-Reply-To: <046.86ef5a0fea428f7b5f5c596d5fa38be9@haskell.org> References: <046.86ef5a0fea428f7b5f5c596d5fa38be9@haskell.org> Message-ID: <061.4833ab722223f0aa74fda3ecbbb0e140@haskell.org> #10351: Inferred type is rejected -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"b83160d07e626bee685f329a9a73e90a4a6074ae/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b83160d07e626bee685f329a9a73e90a4a6074ae" Tidy up treatment of FlexibleContexts Previously (Trac #10351) we could get Non type-variable argument in the constraint: C [t] (Use FlexibleContexts to permit this) When checking that `f' has the inferred type f :: forall t. C [t] => t -> () which is a bit stupid: we have *inferred* a type that we immediately *reject*. This patch arranges that that the generalisation mechanism (TcSimplify.decideQuantification) doesn't pick a predicate that will be rejected by the subsequent validity check. This forced some minor refactoring, as usual. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 30 08:26:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Apr 2015 08:26:06 -0000 Subject: [GHC] #10351: Inferred type is rejected In-Reply-To: <046.86ef5a0fea428f7b5f5c596d5fa38be9@haskell.org> References: <046.86ef5a0fea428f7b5f5c596d5fa38be9@haskell.org> Message-ID: <061.b40613228e068e5de91b7238555470ae@haskell.org> #10351: Inferred type is rejected -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_fail/T10351 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_fail/T10351 * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Apr 30 09:18:37 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 30 Apr 2015 09:18:37 -0000 Subject: [GHC] #10367: "ghc: panic! (the 'impossible' happened)" Message-ID: <046.238a760b2e418cfdcf3889e9cb306409@haskell.org> #10367: "ghc: panic! (the 'impossible' happened)" -------------------------------------+------------------------------------- Reporter: bgwines | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1 Keywords: panic | Operating System: MacOS X Architecture: | Type of failure: Runtime crash Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When running tasty-hunit tests through `cabal repl`, I get the following error: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/l6/v2vhn_3j6bb1yvp6k5sh2hv80000gp/T/ghc80357_0/ghc80357_61.dylib, 9): Symbol not found: __hpc_tickboxes_horsezmcontrolzm0zi1zi0zi0_HorseziCommands_hpc Referenced from: /var/folders/l6/v2vhn_3j6bb1yvp6k5sh2hv80000gp/T/ghc80357_0/ghc80357_61.dylib Expected in: flat namespace in /var/folders/l6/v2vhn_3j6bb1yvp6k5sh2hv80000gp/T/ghc80357_0/ghc80357_61.dylib Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} I have a hunch that it's because I enabled the following flags in my .cabal file, since I didn't get the exception before adding them: {{{ Test-Suite test-horse ... GHC-Options: -fhpc -hpcdir dist/hpc/horse-control-1.0 }}} When I run the tests via `cabal test`, I don't get the exception. I've created a branch that showcases the crash: https://github.com/bgwines /horse-control/tree/ghc-panic Repro steps: * clone repo * cd to repo * run `cabal repl` * run `:l Tests/test-horse.hs` * run `main` Reproducability: 100% Please feel free to contact me if there's information lacking, here! :) -- Ticket URL: GHC The Glasgow Haskell Compiler