From ghc-devs at haskell.org Thu Jan 1 05:54:40 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Jan 2015 05:54:40 -0000 Subject: [GHC] #1480: Template Haskell should allow reification of modules In-Reply-To: <044.1d7c36a6a18e7423441eb962e1e87f76@haskell.org> References: <044.1d7c36a6a18e7423441eb962e1e87f76@haskell.org> Message-ID: <059.a1deeb8f8de61f7cde623d9790bef700@haskell.org> #1480: Template Haskell should allow reification of modules -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: feature request | Status: closed Priority: highest | Milestone: 7.8.1 Component: Template Haskell | Version: 7.7 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: 1444 | Blocking: 8398 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by SamB): * related: => 1444 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 1 10:17:33 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Jan 2015 10:17:33 -0000 Subject: [GHC] #9886: Undefined reference to `__sync_fetch_and_xor_8' In-Reply-To: <044.594e65ad21717924722ced76afd26d12@haskell.org> References: <044.594e65ad21717924722ced76afd26d12@haskell.org> Message-ID: <059.a941cf6ee6fe0ac401ef37c5287b0f41@haskell.org> #9886: Undefined reference to `__sync_fetch_and_xor_8' ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (CodeGen) | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+---------------------------------- Changes (by slyfox): * cc: slyfox (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 1 12:23:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Jan 2015 12:23:54 -0000 Subject: [GHC] #9945: export list for System.Posix.Internals breaking the build on Windows In-Reply-To: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> References: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> Message-ID: <061.16d41b3c7b776f1c3600abcf96eb2d2f@haskell.org> #9945: export list for System.Posix.Internals breaking the build on Windows -------------------------------------+------------------------------------- Reporter: MartinF | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #9852 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by MartinF): So apparently I just can't tear myself away - this morning I figured I might as well take another look at this. It turns out (after much `git grep -w`) that almost all of those conditional definitions are module-internal anyway. After dropping those from the export list, this is my diff (to be composed with the one I pasted above): {{{ diff --git a/libraries/base/System/Posix/Internals.hs b/libraries/base/System/Posix/Internals.hs index d316826..ea24ec3 100644 --- a/libraries/base/System/Posix/Internals.hs +++ b/libraries/base/System/Posix/Internals.hs @@ -39,17 +39,12 @@ module System.Posix.Internals s_issock, setCooked, setEcho, setNonBlockingFD, sizeof_stat, st_dev, st_ino, st_mode, st_mtime, st_size, statGetType, withFilePath, #if !defined(mingw32_HOST_OS) && !defined(__MINGW32__) - c_fcntl_lock, c_fcntl_read, c_fcntl_write, c_fork, c_link, c_mkfifo, - c_pipe, c_s_issock, c_sigaddset, c_sigemptyset, c_sigprocmask, - c_tcgetattr, c_tcsetattr, c_utime, c_waitpid, setCloseOnExec, + c_pipe, setCloseOnExec, #endif #if !defined(mingw32_HOST_OS) peekFilePathLen, #endif -#if defined(HTYPE_TCFLAG_T) - c_lflag, get_saved_termios, poke_c_lflag, ptr_c_cc, set_saved_termios, - sizeof_sigset_t, sizeof_termios, tcSetAttr, -#else +#if !defined(HTYPE_TCFLAG_T) is_console, #endif ) where }}} That compiles for me. As for the remaining conditional exports... `c_pipe`:: Only used in `GHC.Event.Control.newControl`. I node that module imports it unconditionally - but it seems all of `GHC.Event` is only used in non-Windows environments (if I'm reading `libraries/base/base.cabal` correctly), so that's fine. `setCloseOnExec`:: Also used in `GHC.Event.Control.newControl`, but additionally in `GHC.Event.EPoll.epollCreate`. `peekFilePathLen`:: Only used in `System.Environment.ExecutablePath.readSymbolicLink`, and only `#if defined(linux_HOST_OS)`. `is_console`:: As above, only used in `GHC.IO.FD.isTerminal`, and only `#if defined(mingw32_HOST_OS)`. So am I right in thinking, for the ones that are only used in one place, the solution would be to just move the `foreign import` to the point-of- use? That'd just leave `setCloseOnExec` (used in two places) - would `GHC.Event.Internal` be a good place for that one? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 1 13:26:40 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Jan 2015 13:26:40 -0000 Subject: [GHC] #9945: export list for System.Posix.Internals breaking the build on Windows In-Reply-To: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> References: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> Message-ID: <061.6d1e6e0d1572428d2b29ef1aaaf5d767@haskell.org> #9945: export list for System.Posix.Internals breaking the build on Windows -------------------------------------+------------------------------------- Reporter: MartinF | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #9852 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): btw this reminds me of a trick I sometimes use to find out which symbols are used where within `base` by compiling `base` w/ `-ddump-minimal- imports` and use the result as a first approximation; another trick (if you are only interested in a few symbol's use sites) is to attach `WARNING` pragmas to symbols and see where the warnings get triggered -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 1 18:09:30 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Jan 2015 18:09:30 -0000 Subject: =?utf-8?b?W0dIQ10gIzk5NDc6IFVuaWNvZGUgwqtvdGhlciBudW1iZXLCuyBj?= =?utf-8?q?haracters_not_consistently_accepted_in_identifiers?= Message-ID: <045.361e5fa432ad2a6e4cd46ab590186633@haskell.org> #9947: Unicode ?other number? characters not consistently accepted in identifiers -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I?ve noticed that some characters classified as numeric by the Unicode standard will currently generate a lexical error. E.g., characters from the ?enclosed alphanumerics? block don?t work, such as ? (circled digit one, U+2460), despite having being of the general Unicode category ?other number?. Usually, ?other number? characters are accepted in identifiers. E.g., superscripts like ??? work fine. This is related to https://ghc.haskell.org/trac/ghc/ticket/5108 , where modifier letters (which are also alphanumeric in Unicode) also throw a lexical error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 1 21:00:34 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 01 Jan 2015 21:00:34 -0000 Subject: [GHC] #9948: Recommend class constraint instead of instance constraint Message-ID: <047.c66907ef09dd5fcc438f73ae7f72ae2e@haskell.org> #9948: Recommend class constraint instead of instance constraint -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider the following example: {{{#!hs {-# LANGUAGE FlexibleInstances, UndecidableInstances #-} module Foo where class Foo a where foo :: Int -> a instance (Num a) => Foo a where foo x = error "" f :: Int -> a f = foo }}} GHC says {{{ No instance for (Num a) arising from a use of ?foo? Possible fix: add (Num a) to the context of the type signature for f :: Int -> a In the expression: foo In an equation for ?f?: f = foo }}} A better error, in my opinion, would be: {{{ No instance for (Foo a) arising from a use of ?foo? Possible fix: add (Foo a) to the context of the type signature for f :: Int -> a In the expression: foo In an equation for ?f?: f = foo }}} That is, I think GHC should recommend the superclass constraint arising from the use of `foo` rather than trying to match an instance and then recommending constraints from the instance. Here are several reasons a superclass constraint is preferable: 1. If the matching instance has several constraints, GHC will recommend putting *all* of those constraints on the function instead of a single superclass constraint. This (naively) results in unnecessarily long constraints on functions that call methods. 2. If the constraints on the instance change, GHC will recommend the corresponding change on the function constraints. This means the instance constraints are not isolated, but instead propagate through the code. 3. The instance constraints might not make sense on the function itself. For example, `f` might not use any methods from the `Num` class, but GHC recommends the `Num` constraint anyway. Recommending the direct superclass constraint should be **less** work for GHC than the current implementation: instead of trying to find a matching instance, it simply stops when it finds that `foo` is a method. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 2 10:21:57 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Jan 2015 10:21:57 -0000 Subject: [GHC] #9949: zipWith too strict in second argument in GHC-7.10.0 Message-ID: <046.a512e03368163c43178326fd94163813@haskell.org> #9949: zipWith too strict in second argument in GHC-7.10.0 -------------------------------------+------------------------------------- Reporter: Lemming | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.1-rc1 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- correct: {{{ $ ghci-7.8.4 -Wall Prelude> zipWith (==) "" undefined [] }}} incorrect: {{{ $ ghci-7.10.0.20141227 -Wall Prelude> zipWith (==) "" undefined *** Exception: Prelude.undefined }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 2 10:24:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Jan 2015 10:24:02 -0000 Subject: [GHC] #9949: zipWith too strict in second argument in GHC-7.10.0 In-Reply-To: <046.a512e03368163c43178326fd94163813@haskell.org> References: <046.a512e03368163c43178326fd94163813@haskell.org> Message-ID: <061.9804feaac060e2f85c112a76476c5fa3@haskell.org> #9949: zipWith too strict in second argument in GHC-7.10.0 -------------------------------------+------------------------------------- Reporter: Lemming | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1-rc1 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 Lemming): * cc: hvr, ekmett (added) * component: Core Libraries => libraries/base -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 2 10:56:20 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Jan 2015 10:56:20 -0000 Subject: [GHC] #9949: zipWith too strict in second argument in GHC-7.10.0 In-Reply-To: <046.a512e03368163c43178326fd94163813@haskell.org> References: <046.a512e03368163c43178326fd94163813@haskell.org> Message-ID: <061.14746b824dbc4cbc72c25e9472c638f3@haskell.org> #9949: zipWith too strict in second argument in GHC-7.10.0 -------------------------------------+------------------------------------- Reporter: Lemming | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1-rc1 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): This was a deliberate choice in #9495, implemented in changeset:488e95b433d4f7568aa89622c729e64aa3b6520d/ghc, and is a documented difference to the standard. Is this causing practical problems for you? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 2 10:56:45 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Jan 2015 10:56:45 -0000 Subject: [GHC] #9949: zipWith too strict in second argument in GHC-7.10.0 In-Reply-To: <046.a512e03368163c43178326fd94163813@haskell.org> References: <046.a512e03368163c43178326fd94163813@haskell.org> Message-ID: <061.898ebd17a827a23e7e416ee8ee7c6ae2@haskell.org> #9949: zipWith too strict in second argument in GHC-7.10.0 -------------------------------------+------------------------------------- Reporter: Lemming | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1-rc1 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: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 2 11:02:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Jan 2015 11:02:33 -0000 Subject: [GHC] #9949: zipWith too strict in second argument in GHC-7.10.0 In-Reply-To: <046.a512e03368163c43178326fd94163813@haskell.org> References: <046.a512e03368163c43178326fd94163813@haskell.org> Message-ID: <061.cceedc775029186e1e10e58a9601e1b8@haskell.org> #9949: zipWith too strict in second argument in GHC-7.10.0 -------------------------------------+------------------------------------- Reporter: Lemming | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1-rc1 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 Lemming): I found the difference because my `mapAdjacent` function uses `tail` in the second argument of `zipWith`: {{{ mapAdjacent :: (a -> a -> b) -> [a] -> [b] mapAdjacent f xs = zipWith f xs (tail xs) }}} I get: {{{ $ ghci-7.10.0.20141227 *Prelude> Data.List.HT.mapAdjacent (==) ([] :: [Int]) *** Exception: Prelude.tail: empty list }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 2 11:05:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Jan 2015 11:05:25 -0000 Subject: [GHC] #9949: zipWith too strict in second argument in GHC-7.10.0 In-Reply-To: <046.a512e03368163c43178326fd94163813@haskell.org> References: <046.a512e03368163c43178326fd94163813@haskell.org> Message-ID: <061.5251cb98fd9a0d01a88fc5f1a5c2b523@haskell.org> #9949: zipWith too strict in second argument in GHC-7.10.0 -------------------------------------+------------------------------------- Reporter: Lemming | Owner: ekmett Type: bug | Status: new Priority: highest | Milestone: Component: libraries/base | Version: 7.10.1-rc1 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): * priority: normal => highest Comment: Hmm, that?s indeed a problem; `zip`?ing with the tail is a very common idiom. We shouldn?t release with that unsolved. @dfeuer, what is your take on this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 2 11:38:40 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Jan 2015 11:38:40 -0000 Subject: [GHC] #9495: Do What I Mean RULES for foldr2 look shady In-Reply-To: <045.dad9eb25171d374e00692e50b8da050c@haskell.org> References: <045.dad9eb25171d374e00692e50b8da050c@haskell.org> Message-ID: <060.8d565f3db27f1889ac859f591a9f47dd@haskell.org> #9495: Do What I Mean RULES for foldr2 look shady -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: libraries/base | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9949 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * related: => #9949 Comment: as noted in #9949, the change in strictness breaks the common `zipWith f xs (tail xs)` idiom -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 2 11:40:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Jan 2015 11:40:05 -0000 Subject: [GHC] #9949: zipWith too strict in second argument in GHC-7.10.0 In-Reply-To: <046.a512e03368163c43178326fd94163813@haskell.org> References: <046.a512e03368163c43178326fd94163813@haskell.org> Message-ID: <061.cf14e667f3db7c7814b6de1d32884316@haskell.org> #9949: zipWith too strict in second argument in GHC-7.10.0 -------------------------------------+------------------------------------- Reporter: Lemming | Owner: ekmett Type: bug | Status: new Priority: highest | Milestone: Component: libraries/base | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9495 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * related: => #9495 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 2 14:09:19 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Jan 2015 14:09:19 -0000 Subject: [GHC] #9949: zipWith too strict in second argument in GHC-7.10.0 In-Reply-To: <046.a512e03368163c43178326fd94163813@haskell.org> References: <046.a512e03368163c43178326fd94163813@haskell.org> Message-ID: <061.7ce9f6732f658e91914cacb5fd600ad2@haskell.org> #9949: zipWith too strict in second argument in GHC-7.10.0 -------------------------------------+------------------------------------- Reporter: Lemming | Owner: ekmett Type: bug | Status: new Priority: highest | Milestone: Component: libraries/base | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9495 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dfeuer): My take is that if we revert this change, then we should get rid of the `foldr2` rule that prompted it. I do not want to go back to the situation where semantics depended on which if either of the rules fired. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 2 14:41:04 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Jan 2015 14:41:04 -0000 Subject: [GHC] #9950: Documentation for InterruptibleFFI contains broken example Message-ID: <042.b24f679a8fb00dc39264bd6cef598d87@haskell.org> #9950: Documentation for InterruptibleFFI contains broken example -------------------------------------+------------------------------------- Reporter: hpd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.4 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In Section "8.1.4. Interruptible foreign calls" the example {{{#!hs foreign import ccall interruptible "sleep" :: CUint -> IO CUint }}} misses the haskell function name. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 2 15:19:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Jan 2015 15:19:31 -0000 Subject: [GHC] #9949: zipWith too strict in second argument in GHC-7.10.0 In-Reply-To: <046.a512e03368163c43178326fd94163813@haskell.org> References: <046.a512e03368163c43178326fd94163813@haskell.org> Message-ID: <061.a408e26a648ff04a0e8a15435c9894d9@haskell.org> #9949: zipWith too strict in second argument in GHC-7.10.0 -------------------------------------+------------------------------------- Reporter: Lemming | Owner: ekmett Type: bug | Status: new Priority: highest | Milestone: Component: libraries/base | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9495 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by tibbe): I think we should * revert the change, * remove the rule, and * document the intended strictness. The lack of the latter has proved to be problematic elsewhere (e.g. `findWithDefault` in containers.) Without documenting the strictness properties users can't really assume anything about the strictness of functions. Not even a "lazy unless otherwise specified" assumption is warranted, as functions are rarely maximally lazy unless particular care is taken (see e.g. https://www.haskell.org/haskellwiki/Maintaining_laziness). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 2 19:41:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Jan 2015 19:41:09 -0000 Subject: [GHC] #9951: OverloadedLists breaks exhaustiveness check Message-ID: <048.8197b1daa9c7ccdc6beab4f061e20643@haskell.org> #9951: OverloadedLists breaks exhaustiveness check -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE OverloadedLists #-} module Bug where f :: [a] -> () f x = case x of [] -> () (_:_) -> () }}} GHC reports: {{{ bug.hs:6:7: Warning: Pattern match(es) are non-exhaustive In a case alternative: Patterns not matched: [] }}} This is reproducible with 7.8 and 7.10rc1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 2 22:45:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Jan 2015 22:45:32 -0000 Subject: [GHC] #9949: zipWith too strict in second argument in GHC-7.10.0 In-Reply-To: <046.a512e03368163c43178326fd94163813@haskell.org> References: <046.a512e03368163c43178326fd94163813@haskell.org> Message-ID: <061.f57aaa149adf625bf043e43cfcbdeb7e@haskell.org> #9949: zipWith too strict in second argument in GHC-7.10.0 -------------------------------------+------------------------------------- Reporter: Lemming | Owner: ekmett Type: bug | Status: new Priority: highest | Milestone: Component: libraries/base | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9495 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): I agree with tibbe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 2 22:49:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Jan 2015 22:49:26 -0000 Subject: [GHC] #9949: zipWith too strict in second argument in GHC-7.10.0 In-Reply-To: <046.a512e03368163c43178326fd94163813@haskell.org> References: <046.a512e03368163c43178326fd94163813@haskell.org> Message-ID: <061.5d2e35402eaed71d77f503ff37e54f38@haskell.org> #9949: zipWith too strict in second argument in GHC-7.10.0 -------------------------------------+------------------------------------- Reporter: Lemming | Owner: ekmett Type: bug | Status: new Priority: highest | Milestone: Component: libraries/base | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9495 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dfeuer): I also agree with tibbe. nomeata, you expressed the opposite view in the original discussion: https://ghc.haskell.org/trac/ghc/ticket/9495#comment:3 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 2 22:50:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Jan 2015 22:50:27 -0000 Subject: [GHC] #9949: zipWith too strict in second argument in GHC-7.10.0 In-Reply-To: <046.a512e03368163c43178326fd94163813@haskell.org> References: <046.a512e03368163c43178326fd94163813@haskell.org> Message-ID: <061.8c8829eb1601474da2cb40fbcc9ea5e6@haskell.org> #9949: zipWith too strict in second argument in GHC-7.10.0 -------------------------------------+------------------------------------- Reporter: Lemming | Owner: ekmett Type: bug | Status: new Priority: highest | Milestone: Component: libraries/base | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9495 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dfeuer): Note that if we make this change, we will need to delete the note I added to the user's manual about the deviation from the standard. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 2 23:02:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Jan 2015 23:02:01 -0000 Subject: [GHC] #9952: Add -g Message-ID: <044.a085a7953895812fe30c00d78189f6a3@haskell.org> #9952: Add -g -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- We should add debug info levels, just like GCC and LLVM has. In particular, I'd like to have -g1 which has (from https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html) > minimal information, enough for making backtraces in parts of the program that you don't plan to debug. This includes descriptions of functions and external variables, and line number tables, but no information about local variables. This should let us have -g1 turned on even in production code, as it should grow binary sizes by much. This in turn should be a boon for debugability of programs. It should also allow us to offer some for of stack traces without any runtime cost (except when an exception with a stack trace is actually raised.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 2 23:02:29 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Jan 2015 23:02:29 -0000 Subject: [GHC] #9952: Add -g In-Reply-To: <044.a085a7953895812fe30c00d78189f6a3@haskell.org> References: <044.a085a7953895812fe30c00d78189f6a3@haskell.org> Message-ID: <059.09955d00ccc6391e013c5728b6c5eca7@haskell.org> #9952: Add -g -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by tibbe): * type: bug => feature request -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 2 23:58:50 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Jan 2015 23:58:50 -0000 Subject: [GHC] #9953: Pattern synonyms don't work with GADTs Message-ID: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> #9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider this variant of test `T8968-1`: {{{ {-# LANGUAGE GADTs, KindSignatures, PatternSynonyms #-} module ShouldCompile where data X :: * -> * where Y :: a -> X (Maybe a) pattern C :: a -> X (Maybe a) pattern C x = Y x foo :: X t -> t foo (C x) = Just x }}} * If we had `(Y x)` instead of `(C x)` in the LHS of `foo`, then this is an ordinary GADT program and typechecks fine. * If we omit the pattern signature, it typechecks fine, and `:info C` says {{{ pattern C :: t ~ Maybe a => a -> X t -- Defined in ?ShouldCompile? }}} * But as written, it fails with {{{ Foo.hs:11:6: Couldn't match type ?t? with ?Maybe a0? ?t? is a rigid type variable bound by the type signature for: foo :: X t -> t at Foo.hs:10:8 Expected type: X t Actual type: X (Maybe a0) Relevant bindings include foo :: X t -> t (bound at Foo.hs:11:1) In the pattern: C x In an equation for ?foo?: foo (C x) = Just x }}} Moreover, `:info C` says {{{ pattern C :: a -> X (Maybe a) -- Defined at Foo.hs:8:9 }}} Do you see the difference? In the former, the "prov_theta" equality constraint is explicit, but in the latter it's implicit. The exact thing happens for `DataCons`. It's handled via the `dcEqSpec` field. Essentially `PatSyn` should have a new field for the implicit equality constraints. And, just as for data consructors, we need to generate the equality constraints, and the existentials that are needed, when we process the signature. Use the code in `TcTyClsDecls.rejigConRes` (perhaps needs a better name). This is all pretty serious. Without fixing it, GADT-style pattern signatures are all but useless. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 2 23:59:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 02 Jan 2015 23:59:15 -0000 Subject: [GHC] #9953: Pattern synonyms don't work with GADTs In-Reply-To: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> References: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> Message-ID: <061.fe8d96d45ac5f43373dd986518f7c123@haskell.org> #9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: 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: => cactus -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 3 03:01:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Jan 2015 03:01:03 -0000 Subject: [GHC] #9891: Fixity declarations for pattern synonyms not persisted In-Reply-To: <047.aacdfa42ce012caca1b8aa09b153b9ab@haskell.org> References: <047.aacdfa42ce012caca1b8aa09b153b9ab@haskell.org> Message-ID: <062.c6c82beb6f91576f4d2c753fece61d4b@haskell.org> #9891: Fixity declarations for pattern synonyms not persisted -------------------------------------+------------------------------------- Reporter: klkblake | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: worksforme | Keywords: Operating System: Unknown/Multiple | PatternSynonyms Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by cactus): * status: infoneeded => closed * resolution: => worksforme -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 3 03:01:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Jan 2015 03:01:45 -0000 Subject: [GHC] #9953: Pattern synonyms don't work with GADTs In-Reply-To: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> References: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> Message-ID: <061.34ede2dd943c708b1a527c72af91e06d@haskell.org> #9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by cactus): * keywords: => PatternSynonyms * component: Compiler => Compiler (Type checker) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 3 05:52:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Jan 2015 05:52:27 -0000 Subject: [GHC] #9953: Pattern synonyms don't work with GADTs In-Reply-To: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> References: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> Message-ID: <061.24fca540d820184fad53283cf795d709@haskell.org> #9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by carter): ... should this be remilestoned for 7.10.1 or will we need to do 7.8.5? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 3 06:01:06 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Jan 2015 06:01:06 -0000 Subject: [GHC] #9953: Pattern synonyms don't work with GADTs In-Reply-To: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> References: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> Message-ID: <061.3ca053c24b7dc9bd3ec9f920f03f9f8c@haskell.org> #9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.8.4 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by cactus): * milestone: => 7.10.1 Comment: 7.8 doesn't have pattern synonym type signatures. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 3 06:04:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Jan 2015 06:04:22 -0000 Subject: [GHC] #9953: Pattern synonyms don't work with GADTs In-Reply-To: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> References: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> Message-ID: <061.9229346d0bd1f4d5962f6426a409225c@haskell.org> #9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by cactus): * version: 7.8.4 => 7.10.1-rc1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 3 10:09:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Jan 2015 10:09:38 -0000 Subject: [GHC] #9949: zipWith too strict in second argument in GHC-7.10.0 In-Reply-To: <046.a512e03368163c43178326fd94163813@haskell.org> References: <046.a512e03368163c43178326fd94163813@haskell.org> Message-ID: <061.4ff4c362dc0175f3185fea15ede97a00@haskell.org> #9949: zipWith too strict in second argument in GHC-7.10.0 -------------------------------------+------------------------------------- Reporter: Lemming | Owner: ekmett Type: bug | Status: new Priority: highest | Milestone: Component: libraries/base | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9495 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): > nomeata, you expressed the opposite view in the original discussion: I know,but I change my opinion in light of new facts, such as breakage of idiomatic code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 3 11:39:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Jan 2015 11:39:28 -0000 Subject: [GHC] #9954: Required constraints are not inferred for pattern synonyms involving GADTs Message-ID: <045.f2f297b00cb2d9f6e8341729f454847e@haskell.org> #9954: Required constraints are not inferred for pattern synonyms involving GADTs -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: (Type checker) | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects PatternSynonyms | valid program Architecture: | Blocked By: Unknown/Multiple | Related Tickets: #9953 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Let's say we have the following setup: {{{#!hs {-# LANGUAGE GADTs, PatternSynonyms, ViewPatterns #-} data T a where MkT1 :: a -> T a MkT2 :: a -> T (Maybe a) f :: (Eq a) => a -> a f = id }}} Then the following definition works as expected: {{{#!hs pattern P1 x <- MkT1 (f -> x) }}} with the following inferred type: {{{ ?? :i P1 pattern P1 :: () => Eq t => t -> T t }}} However, trying to do the same with {{MkT2}} doesn't work: {{{#!hs pattern P2 x <- MkT2 (f -> x) }}} this results in {{{ Could not deduce (Eq a1) arising from a use of ?f? from the context (t ~ Maybe a1) bound by a pattern with constructor MkT2 :: forall a. a -> T (Maybe a), in a pattern synonym declaration }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 3 13:21:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Jan 2015 13:21:05 -0000 Subject: [GHC] #9953: Pattern synonyms don't work with GADTs In-Reply-To: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> References: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> Message-ID: <061.cdc3e05ee3bf049e0753d1a41ed30078@haskell.org> #9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by cactus): I almost have this working in the `wip/T9953` branch. However, there is one tricky question, very much related to #9954: what do we do with required constraints that mention some GADT indices? For example, if `pattern C` also happened to have a required constraint, e.g. `Eq a`, where would we put that, if `a` is no longer a universally- quantified type argument of `C`? What would be the type of `C`'s matcher? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 3 13:39:38 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Jan 2015 13:39:38 -0000 Subject: [GHC] #9938: GHC's link step needs to be told which packages to link In-Reply-To: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> References: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> Message-ID: <061.2ffab4dbda722551917126341026527e@haskell.org> #9938: GHC's link step needs to be told which packages to link -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Joachim Breitner ): In [changeset:"633814f5664f135b3648e2a0a6f37e41e2b54ea0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="633814f5664f135b3648e2a0a6f37e41e2b54ea0" Mark T9938 as not broken either one of the two recent commits (d8d0031, fd97d2a) fixed it, or there is some nondeterminism here. See #9938. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 3 14:26:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Jan 2015 14:26:55 -0000 Subject: [GHC] #9949: zipWith too strict in second argument in GHC-7.10.0 In-Reply-To: <046.a512e03368163c43178326fd94163813@haskell.org> References: <046.a512e03368163c43178326fd94163813@haskell.org> Message-ID: <061.1ee077c008cdcf57ef7aabb3a8cec890@haskell.org> #9949: zipWith too strict in second argument in GHC-7.10.0 -------------------------------------+------------------------------------- Reporter: Lemming | Owner: ekmett Type: bug | Status: new Priority: highest | Milestone: Component: libraries/base | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9495 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): I think we are all in full accord that this needs to be reverted and documented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 3 16:45:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Jan 2015 16:45:01 -0000 Subject: [GHC] #9949: zipWith too strict in second argument in GHC-7.10.0 In-Reply-To: <046.a512e03368163c43178326fd94163813@haskell.org> References: <046.a512e03368163c43178326fd94163813@haskell.org> Message-ID: <061.eca75d4e468e6922fa1510098b5041cb@haskell.org> #9949: zipWith too strict in second argument in GHC-7.10.0 -------------------------------------+------------------------------------- Reporter: Lemming | Owner: ekmett Type: bug | Status: new Priority: highest | Milestone: Component: libraries/base | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9495 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dfeuer): Never let facts get in the way of a good opinion! I'll put together a code review today. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 3 18:40:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Jan 2015 18:40:27 -0000 Subject: [GHC] #8909: ppc dyn executable compiled with ghc-7.8.1 RC2 segfaults In-Reply-To: <050.3909a9b5b308161cfebc22d2e86541c4@haskell.org> References: <050.3909a9b5b308161cfebc22d2e86541c4@haskell.org> Message-ID: <065.5658d3e67636805ac69af0aacedcb960@haskell.org> #8909: ppc dyn executable compiled with ghc-7.8.1 RC2 segfaults -------------------------------------+------------------------------------ Reporter: juhpetersen | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: powerpc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: 8024 | Differential Revisions: -------------------------------------+------------------------------------ Changes (by slyfox): * status: infoneeded => closed * resolution: => fixed * related: => 8024 Comment: Mark as duplicate of #8024 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 3 20:31:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Jan 2015 20:31:32 -0000 Subject: [GHC] #481: Recompilation check fails for TH In-Reply-To: <046.9f65722c20d1ed8e256febe14e8bd5d1@haskell.org> References: <046.9f65722c20d1ed8e256febe14e8bd5d1@haskell.org> Message-ID: <061.8e88d2d107bb92c7a6e01d51b9e6ec9e@haskell.org> #481: Recompilation check fails for TH ------------------------------------------------+-------------------------- Reporter: simonpj | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.2.1 Component: Template Haskell | Version: 6.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result at runtime | Unknown/Multiple Blocked By: | Test Case: | TH_recompile | Blocking: ------------------------------------------------+-------------------------- Comment (by Edward Z. Yang ): In [changeset:"af4d99803ea7676f88f250ad56a8c31c1c8cd5bc/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="af4d99803ea7676f88f250ad56a8c31c1c8cd5bc" Don't do a half-hearted recompilation check in compileOne Summary: The isNothing maybe_old_linkable check predates 48bc81ad466edfc80237015dbe5d78ba70eb5095, which fixed #481 by requiring recompilation information to be passed in as an argument to compileOne. As a result, the check here is redundant: the client has already taken a look at the object file to see if it is available or not. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonmar, austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D594 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 3 20:31:32 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Jan 2015 20:31:32 -0000 Subject: [GHC] #9243: Recompilation avoidance doesn't work for -fno-code/-fwrite-interface In-Reply-To: <045.eb0d37b8e28f9b0d21ba7b721e124a6b@haskell.org> References: <045.eb0d37b8e28f9b0d21ba7b721e124a6b@haskell.org> Message-ID: <060.28c80e42d3ca52d6599c340d96dfec45@haskell.org> #9243: Recompilation avoidance doesn't work for -fno-code/-fwrite-interface -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D596 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"2223e196b2dc5340d70e58be011c279d381b4319/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2223e196b2dc5340d70e58be011c279d381b4319" Fix #9243 so recompilation avoidance works with -fno-code Summary: Where we track timestamps of object files, also track timestamps for interface files. When -fno-code -fwrite-interface is enabled, use the interface file timestamp as an extra check to see if the files are up-to-date. We had to apply this logic to one-shot and make modes. This fix would be good to merge into 7.10; it makes using -fno-code -fwrite-interface for flywheel type checking usable. Signed-off-by: Edward Z. Yang Test Plan: validate and new test cases Reviewers: austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D596 GHC Trac Issues: #9243 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 3 20:33:51 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Jan 2015 20:33:51 -0000 Subject: [GHC] #9243: Recompilation avoidance doesn't work for -fno-code/-fwrite-interface In-Reply-To: <045.eb0d37b8e28f9b0d21ba7b721e124a6b@haskell.org> References: <045.eb0d37b8e28f9b0d21ba7b721e124a6b@haskell.org> Message-ID: <060.cd801c990cd869d8aa190400186c65c0@haskell.org> #9243: Recompilation avoidance doesn't work for -fno-code/-fwrite-interface -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: merge Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D596 -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 3 21:13:57 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Jan 2015 21:13:57 -0000 Subject: [GHC] #9951: OverloadedLists breaks exhaustiveness check In-Reply-To: <048.8197b1daa9c7ccdc6beab4f061e20643@haskell.org> References: <048.8197b1daa9c7ccdc6beab4f061e20643@haskell.org> Message-ID: <063.3e05b34ee4fff18274d4c01129f921e6@haskell.org> #9951: OverloadedLists breaks exhaustiveness check -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: 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 MartinF): I note patterns using OverloadedLists desugar to view patterns - from that wiki page: > {{{#!haskell > f [] = ... > g [x,y,z] = ... > }}} > > will be treated as > > {{{#!haskell > f (toList -> []) = ... > g (toList -> [x,y,z]) = ... > }}} So I'd guess this has the same underlying cause as the known problem with exhaustiveness checking of view patterns - see #5762. For instance, this: {{{ $ ghci -Wall -XOverloadedLists GHCi, ... Prelude> let f [] = (); f (_:_) = () :2:5: Warning: Pattern match(es) are non-exhaustive In an equation for `f': Patterns not matched: [] }}} and its one-step-desugared equivalent: {{{ $ ghci -Wall -XViewPatterns GHCi, ... Prelude> :module +GHC.Exts Prelude GHC.Exts> let f (fromList -> []) = (); f (fromList -> _:_) = () :3:5: Warning: Pattern match(es) are non-exhaustive In an equation for `f': Patterns not matched: _ }}} ... both produce spurious exhaustiveness warnings. Slightly different ones, though. How curious. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 3 21:38:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Jan 2015 21:38:24 -0000 Subject: [GHC] #9945: export list for System.Posix.Internals breaking the build on Windows In-Reply-To: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> References: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> Message-ID: <061.d6efeede665658493077bd9a6f45e7ef@haskell.org> #9945: export list for System.Posix.Internals breaking the build on Windows -------------------------------------+------------------------------------- Reporter: MartinF | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #9852 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by MartinF): I've noticed something strange while looking into `peekFilePathLen` - this is where it's defined: {{{#!hs #ifdef mingw32_HOST_OS withFilePath :: FilePath -> (CWString -> IO a) -> IO a withFilePath = withCWString newFilePath :: FilePath -> IO CWString newFilePath = newCWString peekFilePath :: CWString -> IO FilePath peekFilePath = peekCWString #else withFilePath :: FilePath -> (CString -> IO a) -> IO a newFilePath :: FilePath -> IO CString peekFilePath :: CString -> IO FilePath peekFilePathLen :: CStringLen -> IO FilePath withFilePath fp f = getFileSystemEncoding >>= \enc -> GHC.withCString enc fp f newFilePath fp = getFileSystemEncoding >>= \enc -> GHC.newCString enc fp peekFilePath fp = getFileSystemEncoding >>= \enc -> GHC.peekCString enc fp peekFilePathLen fp = getFileSystemEncoding >>= \enc -> GHC.peekCStringLen enc fp #endif }}} So, `#ifdef mingw32_HOST_OS`, those three related functions all have types involving `CWString` - but if not, their types have `CString` instead. If CPP-conditional exports are generally wrong, would the same be true for exports with CPP-conditional types? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 3 21:48:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Jan 2015 21:48:04 -0000 Subject: [GHC] #9945: export list for System.Posix.Internals breaking the build on Windows In-Reply-To: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> References: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> Message-ID: <061.b561c87621ba944d967e51e6c2fbd4c9@haskell.org> #9945: export list for System.Posix.Internals breaking the build on Windows -------------------------------------+------------------------------------- Reporter: MartinF | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #9852 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dfeuer): Yuck! It doesn't get much nastier than that, I don't think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 3 21:53:58 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Jan 2015 21:53:58 -0000 Subject: [GHC] #9938: GHC's link step needs to be told which packages to link In-Reply-To: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> References: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> Message-ID: <061.3dd461520a1e117010bf275c4948c1d6@haskell.org> #9938: GHC's link step needs to be told which packages to link -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): It fails on my laptop. I don't understand why it (now) passes on the regression suite but fail on on my laptop. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 3 21:55:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Jan 2015 21:55:14 -0000 Subject: [GHC] #9955: ghc-stage1 compiles with bootstrapping ghc package, not the built one Message-ID: <045.2e2f0948ac1cf3246cb798d3962e4df0@haskell.org> #9955: ghc-stage1 compiles with bootstrapping ghc package, not the built one -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Build | Version: 7.11 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Steps to reproduce: Build GHC using 7.10 as the bootstrapping compiler. Now check which GHC package stage 1 Main.hi was linked against, e.g. using `--show-iface`: {{{ [ezyang at hs01 ghc-validate2]$ ../ghc-7.10/inplace/bin/ghc-stage2 --show- iface ghc/stage1/build/Main.hi ... package dependencies: array-0.5.0.1 base-4.8.0.0 binary-0.7.2.3 bin-package-db-0.0.0.0 bytestring-0.10.6.0 containers-0.5.6.2 deepseq-1.4.0.0 directory-1.2.1.1 filepath-1.3.1.0 ghc-7.10.0.20141223 ghc-prim-0.3.1.0 hoopl-3.10.0.2 hpc-0.6.0.2 integer-gmp-1.0.0.0 process-1.2.1.0 time-1.5.0.1 transformers-0.4.2.0 unix-2.7.1.0 }}} Bad news! I think I introduced bug when I made GHC a wired in package: consequently when we ask GHC to link against a specific version of the GHC package, this flag is ignored. I don't actually know what the right way to fix this is, but we'll have to figure something out here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 3 22:21:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Jan 2015 22:21:10 -0000 Subject: [GHC] #9955: ghc-stage1 compiles with bootstrapping ghc package, not the built one In-Reply-To: <045.2e2f0948ac1cf3246cb798d3962e4df0@haskell.org> References: <045.2e2f0948ac1cf3246cb798d3962e4df0@haskell.org> Message-ID: <060.0729c425f5152b4271df061347fa10e9@haskell.org> #9955: ghc-stage1 compiles with bootstrapping ghc package, not the built one -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Build System | Version: 7.11 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 ezyang): Strangely, though, the ghc-stage1 executable does seem to be running the most recently built code... (Hypothesis: we are type-checking against the bootstrapping copy, but linking against the correct copy.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 3 22:31:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Jan 2015 22:31:27 -0000 Subject: [GHC] #9954: Required constraints are not inferred for pattern synonyms involving GADTs In-Reply-To: <045.f2f297b00cb2d9f6e8341729f454847e@haskell.org> References: <045.f2f297b00cb2d9f6e8341729f454847e@haskell.org> Message-ID: <060.9c26ec8f3a7167048517e7b52543cdaf@haskell.org> #9954: Required constraints are not inferred for pattern synonyms involving GADTs -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9953 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): This looks absolutely correct to me. Try it with an ordinary function, without the synonym: {{{ boo :: T a -> Bool boo (MkT2 (f -> x)) = True }}} and you get {{{ T9954.hs:12:12: Could not deduce (Eq a1) arising from a use of `f' from the context a ~ Maybe a1 bound by a pattern with constructor: MkT2 :: forall a. a -> T (Maybe a), in an equation for `boo' at T9954.hs:12:6-18 Possible fix: add (Eq a1) to the context of the data constructor `MkT2' In the expression: f In the pattern: f -> x In the pattern: MkT2 (f -> x) }}} And indeed, from where can we conjure up equality on the existentially- bound type? So to me this looks like precisely the correct behaviour. Siimon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 3 22:32:03 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Jan 2015 22:32:03 -0000 Subject: [GHC] #9954: Required constraints are not inferred for pattern synonyms involving GADTs In-Reply-To: <045.f2f297b00cb2d9f6e8341729f454847e@haskell.org> References: <045.f2f297b00cb2d9f6e8341729f454847e@haskell.org> Message-ID: <060.bbc97661d907e85eebf1b804b7a15bc0@haskell.org> #9954: Required constraints are not inferred for pattern synonyms involving GADTs -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler (Type | Version: checker) | Keywords: Resolution: invalid | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: #9953 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => invalid -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 3 22:41:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Jan 2015 22:41:27 -0000 Subject: [GHC] #9938: GHC's link step needs to be told which packages to link In-Reply-To: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> References: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> Message-ID: <061.a6f68e990bbc8f6d34816047bb0ebe5c@haskell.org> #9938: GHC's link step needs to be told which packages to link -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): That?s strange. T9938 passes on Travis reliable now (four builds since that commit). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 3 23:01:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 03 Jan 2015 23:01:41 -0000 Subject: [GHC] #9951: OverloadedLists breaks exhaustiveness check In-Reply-To: <048.8197b1daa9c7ccdc6beab4f061e20643@haskell.org> References: <048.8197b1daa9c7ccdc6beab4f061e20643@haskell.org> Message-ID: <063.fac8d04c9a4597735d48de3c8e404b9e@haskell.org> #9951: OverloadedLists breaks exhaustiveness check -------------------------------------+------------------------------------- Reporter: Feuerbach | Owner: Type: bug | Status: new Priority: normal | Milestone: 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 Feuerbach): Thanks Martin, that desugaring explains everything. I didn't know it was so simple. The cause of the difference you point is that the cons pattern, `_:_`, is not overloaded. The question then becomes, should there be some way to write the non- overloaded empty list constructor even when OverloadedLists is on? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 4 02:21:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Jan 2015 02:21:22 -0000 Subject: [GHC] #9508: Rename package key In-Reply-To: <045.9321326ff6fd1cf354acf4ce2c70bc86@haskell.org> References: <045.9321326ff6fd1cf354acf4ce2c70bc86@haskell.org> Message-ID: <060.745e5d74fdaf49b0182facbea0557d7b@haskell.org> #9508: Rename package key -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: wontfix | 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): * status: new => closed * resolution: => wontfix Comment: OK, closing this as WONTFIX. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 4 02:24:44 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Jan 2015 02:24:44 -0000 Subject: [GHC] #9955: ghc-stage1 compiles with bootstrapping ghc package, not the built one In-Reply-To: <045.2e2f0948ac1cf3246cb798d3962e4df0@haskell.org> References: <045.2e2f0948ac1cf3246cb798d3962e4df0@haskell.org> Message-ID: <060.eb7d67f85998815219bba2714d2bed22@haskell.org> #9955: ghc-stage1 compiles with bootstrapping ghc package, not the built one -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Build System | Version: 7.11 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 ezyang): * priority: highest => high Comment: Falsified previous hypothesis. In fact, building GHC HEAD 7.10 works just fine; it's just the other way around that is a problem. Here's what's going on: When there are multiple wired in packages, we seem to ignore the hide-all- packages directive, and instead simply take all instances of the wired in package and *select the newest version*. Thus, when we compile GHC HEAD with GHC 7.10, the ghc package from GHC HEAD has a newer version than the system ghc package from 7.10, and we use that when compiling. However, when we build 7.10 with GHC HEAD, we always select the system GHC HEAD library, which works about as well as you'd expect. What is going on with the `--show-iface`? The key is that package dependency description is done by a lookup in the package database. The package key for 'ghc' is always ghc, no matter what the version is (since it's wired in), but I notably have NOT told ghc about the inplace package database in my show-iface command. So we lookup the package keyed 'ghc' in the default database, which is 7.10's, voila. This behavior sort of makes sense. In particular, it does make sense for GHC to try to output something besides a package key when referring to packages in debug output, because in general you don't necessarily care about the key in question, and the output is a lot more readable if you just get package name-version. The downside is it's easy to mess up wired in packages. It's possible #9652 is caused by the same underlying mechanism. My proposed fix for the wired in problem is to properly teach GHC to respect `-hide-all-packages -package wired-in-0.1.2`: we really SHOULD pick 0.1.2, even if there is a newer version. Of course, if we don't mention the wired in package, it probably makes sense to default back to the newest version. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 4 03:58:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Jan 2015 03:58:28 -0000 Subject: [GHC] #9949: zipWith too strict in second argument in GHC-7.10.0 In-Reply-To: <046.a512e03368163c43178326fd94163813@haskell.org> References: <046.a512e03368163c43178326fd94163813@haskell.org> Message-ID: <061.37ed8ebcfd1a1e3198a43606f66bab4b@haskell.org> #9949: zipWith too strict in second argument in GHC-7.10.0 -------------------------------------+------------------------------------- Reporter: Lemming | Owner: ekmett Type: bug | Status: patch Priority: highest | Milestone: 7.10.1 Component: Core Libraries | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9495 | Blocking: | Differential Revisions: Phab:D602 -------------------------------------+------------------------------------- Changes (by dfeuer): * status: new => patch * failure: None/Unknown => Runtime crash * differential: => Phab:D602 * component: libraries/base => Core Libraries * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 4 04:46:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Jan 2015 04:46:43 -0000 Subject: [GHC] #9953: Pattern synonyms don't work with GADTs In-Reply-To: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> References: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> Message-ID: <061.88c6bba212f42c03ccd98d289e520e78@haskell.org> #9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by cactus): Here's a hopefully more enlightening description of the problem in ticket:9953#comment:6. Suppose we have this setup: {{{#!hs {-# LANGUAGE GADTs, PatternSynonyms, ViewPatterns #-} data X t where Y :: a -> X (Maybe a) f :: (Eq a) => a -> a f = id -- inferred type: -- pattern C1 :: t ~ Maybe a => a -> X t pattern C1 x = Y x pattern C2 :: a -> X (Maybe a) pattern C2 x = Y x pattern C3 :: () => (Eq a) => a -> X (Maybe a) pattern C3 x = Y (f -> x) }}} The difference between `C1`'s inferred type and `C2`'s type is the subject of this ticket; with the point being that we should be reconstructing `C1`'s type from the signature given for `C2`. The types of the matchers generated are as follows: {{{#!hs $mC1 :: forall r t. X t -> (forall a. (t ~ Maybe a) => a -> r) -> (Void# -> r) -> r $mC2 :: forall r a. X (Maybe a) -> ( a -> r) -> (Void# -> r) -> r $mC3 :: forall r a. (Eq a) => X (Maybe a) -> ( a -> r) -> (Void# -> r) -> r }}} If `C2` got the same type as `C1`, what would be the analogous type for `C3`? What would be `$mC3`'s type in that case? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 4 05:35:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Jan 2015 05:35:14 -0000 Subject: [GHC] #9243: Recompilation avoidance doesn't work for -fno-code/-fwrite-interface In-Reply-To: <045.eb0d37b8e28f9b0d21ba7b721e124a6b@haskell.org> References: <045.eb0d37b8e28f9b0d21ba7b721e124a6b@haskell.org> Message-ID: <060.ea499f693f3cc105f16426e6dcd6421a@haskell.org> #9243: Recompilation avoidance doesn't work for -fno-code/-fwrite-interface -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: merge Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D596 -------------------------------------+------------------------------------- Comment (by ezyang): Oh, to be clear to whoever merges: you probably need the parent commit https://git.haskell.org/ghc.git/commit/af4d99803ea7676f88f250ad56a8c31c1c8cd5bc -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 4 06:30:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Jan 2015 06:30:41 -0000 Subject: [GHC] #9805: Use TrieMaps to speed up type class instance lookup In-Reply-To: <045.621217884d547d5010b211251c8e4ea4@haskell.org> References: <045.621217884d547d5010b211251c8e4ea4@haskell.org> Message-ID: <060.3f466a22ab8c57cc1bcf86e0f5cc6532@haskell.org> #9805: Use TrieMaps to speed up type class instance lookup -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | 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: -------------------------------------+------------------------------------- Comment (by ezyang): Simon, here is my proposal: we make a new type class TrieKeyMap whose parent is TrieMap and defines just the new foldWithKeyTM method. Most data types will be instances of both, but not, for example, UniqFM. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 4 08:26:05 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Jan 2015 08:26:05 -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.797c18a2f567fecde99be5aa0a2b5459@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature request | Status: patch 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: | Blocking: | Differential Revisions: Phab:D578 -------------------------------------+------------------------------------- Comment (by gridaphobe): Replying to [comment:23 simonpj]: > * Could you modify [wiki:ExplicitCallStack/ImplicitLocations] to describe the exact specification of what you propose? For example, the design means that there are two new types in the `base` library, defined in `GHC.Location`: > * `SrcLoc` (for a source location) > * `Location` (for a stack of source locations) > Both are abstract, so you can't make a new `SrcLoc` or `Location`; only GHC can do that. Is that what we want? > > * You can add a section on open questions too, for things you aren't sure about. Done. It's not an open question per se, but folks following this ticket may want to look at the second bullet point under Implementation Details. I'm a bit uneasy about veering that far away from the standard behavior of ImplicitParams, but I think it's worth considering at least. > * I'm very keen that `SrcLoc` is used also by the `Typeable` library (and any other reflection libraries too). Currently `Data.Typeable.Internals` defines `TyCon` which contains package/module/name information, but it should just use a `SrcLoc`. We are proposing to redesign `Typeable` anyway (see [wiki:Typeable]) so we can do this `SrcLoc` stuff at the same time > > * Given this broader use, is `Location` the right name? It's really more like a `SrcLocStack`. > > * The stack would be even better if it said something like "foo called at " rather than just "". That would be easy enough to implement (the information is in the `CtOrigin` of the constraint), but again the data type would need to be elaborated a bit, something like > {{{ > data Location = Location [(String, SrcLoc)] > }}} In anticipation of this I've renamed `Location` to `CallStack`, but it looks like the `CtOrigin` that we get may not provide enough info. In my test-case at least, I'm getting a `TypeEqOrigin`, which isn't particularly helpful. > * At a grungy level, I wonder about all the copies of the same module- name and file-name strings. Maybe the desugarer should just generate one copy and use it? Or maybe CSE should gather them up (I don't think it does so at the moment.) Hmm, if this is an issue my instinct would be that CSE should be responsible for cleaning up the duplicate strings. It seems to fit with the Core philosophy of having the simplifier clean up after the various other passes, and may provide benefits outside of these IP CallStacks too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 4 11:17:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Jan 2015 11:17:34 -0000 Subject: [GHC] #9221: (super!) linear slowdown of parallel builds on 40 core machine In-Reply-To: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> References: <045.6b727a84a1bea97c8d082954a0b9425e@haskell.org> Message-ID: <060.239d1ce6ad3da6cf612f8797a9817493@haskell.org> #9221: (super!) linear slowdown of parallel builds on 40 core machine -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #910 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by kolmodin): * cc: kolmodin (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 4 17:57:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Jan 2015 17:57:45 -0000 Subject: [GHC] #9945: export list for System.Posix.Internals breaking the build on Windows In-Reply-To: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> References: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> Message-ID: <061.9ca39d91b1394f10191e74cc6736112b@haskell.org> #9945: export list for System.Posix.Internals breaking the build on Windows -------------------------------------+------------------------------------- Reporter: MartinF | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #9852 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dfeuer): I believe the correct way to do this is probably to change `CFilePath` from a type synonym to a `newtype`, and hide the details from users. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 4 18:05:47 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Jan 2015 18:05:47 -0000 Subject: [GHC] #9955: ghc-stage1 compiles with bootstrapping ghc package, not the built one In-Reply-To: <045.2e2f0948ac1cf3246cb798d3962e4df0@haskell.org> References: <045.2e2f0948ac1cf3246cb798d3962e4df0@haskell.org> Message-ID: <060.70f7a7228b76c0c78500d3f6936cfced@haskell.org> #9955: ghc-stage1 compiles with bootstrapping ghc package, not the built one -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Build System | Version: 7.11 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: Phab:D603 -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch * differential: => Phab:D603 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 4 18:52:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Jan 2015 18:52:18 -0000 Subject: [GHC] #9956: Command line flag deprecated warning could be annoying for -Werror users Message-ID: <045.317bce8cdeb509002f292d6fe74865f2@haskell.org> #9956: Command line flag deprecated warning could be annoying for -Werror users -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: 7.10.1 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: | -------------------------------------+------------------------------------- In 7.10 we deprecated the poorly named `-package-name` for `-this-package- key`. However, I was working with GHC's validate script and I noticed that this behavior actually might be pretty annoying, because it causes GHC to fail on `-Werror`, and there doesn't seem to be any way of turning off this behavior. So maybe we should add a -fno-warn flag which controls flag warnings. But old GHCs wouldn't accept that flag, so it doesn't make it any more convenient for people to keep their old build scripts running while squelching the warning. Or we could drop the deprecation warning for now and start bleating about it next release. Setting priority high because whatever we decide to do, we need to decide it before 7.10 release. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 4 21:51:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Jan 2015 21:51:20 -0000 Subject: [GHC] #4150: CPP+QuasiQuotes confuses compilation errors' line numbers In-Reply-To: <046.62742d3f271c0ad2ad5ce838979c1b17@haskell.org> References: <046.62742d3f271c0ad2ad5ce838979c1b17@haskell.org> Message-ID: <061.078ef3f95aab8d1ffa8a33ccb2e14eff@haskell.org> #4150: CPP+QuasiQuotes confuses compilation errors' line numbers -------------------------------------+------------------------------------- Reporter: yairchu | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 6.12.3 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | quasiquotation/T4150 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by crobbins): Is there any way we could move this back to 7.10.1? This makes integration with tools very error-prone. For instance, error highlighting in your editor will be in the wrong place. Any feature that requires an accurate line/column position will work inconsistently for end users as a result. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 4 23:05:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Jan 2015 23:05:15 -0000 Subject: [GHC] #4150: CPP+QuasiQuotes confuses compilation errors' line numbers In-Reply-To: <046.62742d3f271c0ad2ad5ce838979c1b17@haskell.org> References: <046.62742d3f271c0ad2ad5ce838979c1b17@haskell.org> Message-ID: <061.da167500aebaae08c776324541b5cd98@haskell.org> #4150: CPP+QuasiQuotes confuses compilation errors' line numbers -------------------------------------+------------------------------------- Reporter: yairchu | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 6.12.3 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | quasiquotation/T4150 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ezyang): So, to fix this, we need to augment the multi-line comment and quasi-quote lexing in `Lexer.x` to look for and handle the CPP produced line pragmas (as handled currently by the `` state). It should be possible, though a bit delicate since both of these lexers are hand-rolled. While I was reading how this code worked, I realized there is a workaround: if you force the line-state to resynchronize, e.g. by include'ing a blank file outside of the quasiquote/multiline comment, you'll get right light numbers for anything afterwards. If you want this in 7.10 (there's not much time left) you can help out by cooking up a self-contained, minimal example for quasiquoters which we can put in the test suite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 4 23:10:31 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 04 Jan 2015 23:10:31 -0000 Subject: [GHC] #4150: CPP+QuasiQuotes confuses compilation errors' line numbers In-Reply-To: <046.62742d3f271c0ad2ad5ce838979c1b17@haskell.org> References: <046.62742d3f271c0ad2ad5ce838979c1b17@haskell.org> Message-ID: <061.8d7627271a5770b90fb2742e42538bb9@haskell.org> #4150: CPP+QuasiQuotes confuses compilation errors' line numbers -------------------------------------+------------------------------------- Reporter: yairchu | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 6.12.3 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | quasiquotation/T4150 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by crobbins): Thanks ezyang! I'll work on getting a test case together. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 04:42:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 04:42:52 -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.d4472bd8a0c4b14d5cac7cdc375363ee@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature request | Status: patch 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: | Blocking: | Differential Revisions: Phab:D578 -------------------------------------+------------------------------------- Comment (by gridaphobe): Replying to [comment:21 rodlogic]: > Replying to [comment:19 gridaphobe]: > > I've sent a patch that implements [wiki:ExplicitCallStack/ImplicitLocations] to Phab (https://phabricator.haskell.org/D578). > This is great. I would have taken me quite a while to get there. > > In your patch you mention that you didn't change base at this point, could we at least change GHC.Base to use it and add a new assertMsg? I'd rather keep that patch feature-only, to focus discussion around the design/implementation. But I'm happy to put together another patch, once D578 is merged, to discuss using it in base. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 10:14:44 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 10:14:44 -0000 Subject: [GHC] #8308: Resurrect ticky code for counting constructor arity In-Reply-To: <048.881ed81a50f663ce5516d17888eb822c@haskell.org> References: <048.881ed81a50f663ce5516d17888eb822c@haskell.org> Message-ID: <063.f7779b76542050a1701bb49857c6a443@haskell.org> #8308: Resurrect ticky code for counting constructor arity -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: mlen Type: task | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.7 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by mlen): jstolarek: I made some progress recently: relevant constants (`TICKY_BIN_COUNT`) are defined only in `includes/stg/Ticky.h` and then made available to Haskell code via `utils/deriveConstants`. The last thing that's left is making sure counting functions are used where they are needed and refactoring `rts/Ticky.c` a bit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 10:36:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 10:36:29 -0000 Subject: [GHC] #8244: Removing the Cabal dependency In-Reply-To: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> References: <042.0abf6671cf9f454d43129463a06c827d@haskell.org> Message-ID: <057.a9025bacbaef8169a9623dbfa525f39d@haskell.org> #8244: Removing the Cabal dependency -------------------------------------+------------------------------------- Reporter: nh2 | Owner: duncan Type: bug | 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: D172 -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 10:59:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 10:59:48 -0000 Subject: [GHC] #9957: Document -fwarn-unticked-promoted-constructors in release notes Message-ID: <049.140c9348cb257489c7a06e29a9d4d013@haskell.org> #9957: Document -fwarn-unticked-promoted-constructors in release notes -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.10.1-rc1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: Documentation Architecture: | bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The new flag `-fwarn-unticked-promoted-constructors` should be documented in the release notes, as users upgrading to 7.10 may need to update their code or flags to continue compiling with `-Wall -Werror`. Perhaps it should even be removed from `-Wall` (c.f. [https://www.haskell.org/pipermail/ghc-devs/2014-December/007738.html discussion here])? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 12:20:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 12:20:51 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.50aa39c98ea48794523e5c696cd29e26@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9621 | Blocking: | Differential Revisions: Phab:D209 -------------------------------------+------------------------------------- Changes (by hvr): * cc: core-libraries-committee@? (added) * status: new => closed * resolution: => fixed Comment: Let's close this; everything that was planned for milestone:7.10.1 has been implemented -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 14:17:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 14:17:30 -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.01e3763bc6b372c84d11cd14a00acdf1@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature request | Status: patch 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: | Blocking: | Differential Revisions: Phab:D578 -------------------------------------+------------------------------------- Comment (by simonpj): Re "the second bullet point under Implementation Details", I now understand. Good point. The issue is this: {{{ f :: (?loc :: CallStack) => IO () f = print (?location :: CallStack) }}} There are two alternatives for what to pass to `print`: * Pass the call site of `print`, pushed onto the passed-in call stack * Pass a singleton stack, just the call site of `print`, reflecting the change in name. You have implemented the first, but I think the latter would perhaps be more intuitive. Does anyone else have opinions? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 14:19:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 14:19:34 -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.f902cde648774be7c3c3f5714384e986@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature request | Status: patch 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: | Blocking: | Differential Revisions: Phab:D578 -------------------------------------+------------------------------------- Comment (by simonpj): You did not respond to bullet 5 of comment:24. I'd like to see displayed stacks looking like: {{{ foo, called at Bar.hs line 5 wim, called as Wobble.hs line 9 ...etc... }}} Currently we can get the call sites but not the function being called. I think it'd make the stacks a lot more informative. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 14:46:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 14:46:48 -0000 Subject: [GHC] #4150: CPP+QuasiQuotes confuses compilation errors' line numbers In-Reply-To: <046.62742d3f271c0ad2ad5ce838979c1b17@haskell.org> References: <046.62742d3f271c0ad2ad5ce838979c1b17@haskell.org> Message-ID: <061.4c1ef97fa0f48879339ba82d2d7c78ba@haskell.org> #4150: CPP+QuasiQuotes confuses compilation errors' line numbers -------------------------------------+------------------------------------- Reporter: yairchu | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 6.12.3 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | quasiquotation/T4150 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): We can certainly fix bugs in 7.10, yes. So if you can make a patch to fix it, and it's not too invasive or destablising, we can apply it to the 7.10 release candidate. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 15:10:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 15:10:51 -0000 Subject: [GHC] #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family In-Reply-To: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> References: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> Message-ID: <060.dd3e3b929b46c6233dbca808e52a854c@haskell.org> #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family -------------------------------------+------------------------------------- Reporter: qnikst | 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 goldfire): Replying to [comment:15 simonpj]: > The straw-man proposal is that with `{-# UNDECIDABLE #-}` (or some other pragma name) on a closed type family, the surely-apart check is strengthened, allowing more reductions to fire. This seems to be precisely my {-# UNSAFE_STRONGER_APARTNESS_CHECK #-}` pragma. Declaring this property of a type function seems orthogonal to whether or not evaluating the function terminates -- I could see both `{-# UNDECIDABLE #-}` and `{-# UNSAFE_STRONGER_APARTNESS_CHECK #-}` as separate pragmas, where neither implies the other. The first means that GHC might not terminate; the second means your program might not be type-safe. > > Richard, you rightly point out that if you put that on `Equal`, then `Equal x [x]` would return `False`, as you'd expect if all types were finite. But you also claim that if you can define an infinite type, then you can get `unsafeCoerce`. I believe you (c.f Section 6 of the [http://research.microsoft.com/en-us/um/people/simonpj/papers/ext-f/ Closed Type Families paper]). But can you exhibit an example? See #8162. That example uses open type families, and will compile and seg- fault with 7.6.3. The improved checking in 7.8.x stops compilation. However, an open type family with all of its instances in one module (such as `F` in #8162) is fully equivalent to a closed type family (with equations in any order). Why? Because all open type family instances must be ''compatible'', and a closed type family where all the equations are compatible skips the apartness check during reduction. (See the closed type families paper for details.) Thus, if we did the wrong apartness check (that is, ignored the possibility of infinite types) in 7.8.x, then an example along the lines of #8162 would cause a seg-fault. > > And if you can, can you translate it back into an example using overlapping classes, probably with equality superclasses? If so, perhaps our existing compiler is unsound! I tried and failed at this, and I've decided it's impossible. Without using type families, classes introduce no new type axioms -- even with equality superclasses. Without any axioms, the proof of progress of FC is quite straightforward and has no surprises. Thus, any program with an implementation of `unsafeCoerce` must fail to be well-typed in FC. So, barring Core Lint errors, this trick shouldn't be possible. So, I maintain my earlier position: what we have now is sound, but perhaps unpredictable in extreme cases. I ''do'' think we should make the class overlap check echo the type family overlap check, but I don't think there's a soundness issue here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 15:24:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 15:24:14 -0000 Subject: [GHC] #9948: Recommend class constraint instead of instance constraint In-Reply-To: <047.c66907ef09dd5fcc438f73ae7f72ae2e@haskell.org> References: <047.c66907ef09dd5fcc438f73ae7f72ae2e@haskell.org> Message-ID: <062.5cbd50af6bee923f1a2e5b682d15e7ac@haskell.org> #9948: Recommend class constraint instead of instance constraint -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): I'm -1 on this change. * `Num a` is the minimal constraint (in a logic sense) needed on `f`, as it implies all other constraints necessary. * Point (2) above talks about robustness in the presence of refactoring. While that case is true, other refactorings (say, splitting up the `Foo` class) prefer the `Num a` constraint. * Implementing this would be ''more'' work for GHC, I believe. When GHC is trying to satisfy the `Foo a` constraint that arises from the use of `foo`, it then naturally looks for `Foo` instances. It finds a matching one, and then proceeds to try to satisfy the instance's constraints. This process can continue arbitrarily deeply. To report the error requested would require, at the end, looking at the set of unsolved constraints and then trying to find some instance that covers them all. There might be more efficient/effective ways to do this (say, remember precisely the constraints that arise directly from constrained function usages), but it would be more work for GHC, regardless. As a smaller point (but which confused me at first), the original post uses the term "superclass" in a way different to the way I use it: I've always understood "superclass" to refer to constraints on a class definition, such as the `Bar a` in `class Bar a => Fuggle a`. Above, it seems the term "superclass" refers to an instance head. Please correct if I'm wrong. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 15:39:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 15:39:12 -0000 Subject: [GHC] #9945: export list for System.Posix.Internals breaking the build on Windows In-Reply-To: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> References: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> Message-ID: <061.76b63b250e33e48bbd72e5c5182be4e5@haskell.org> #9945: export list for System.Posix.Internals breaking the build on Windows -------------------------------------+------------------------------------- Reporter: MartinF | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #9852 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Simon M says: we don't need `__MINGW32__` any more, ever since we abandoned support for Cygwin. Replace with `mingw32_HOST_OS`. Maybe it is only used in this one file! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 15:41:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 15:41:05 -0000 Subject: [GHC] #9945: export list for System.Posix.Internals breaking the build on Windows In-Reply-To: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> References: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> Message-ID: <061.912fb9cb4f5ae873c8cd08d53931aaa5@haskell.org> #9945: export list for System.Posix.Internals breaking the build on Windows -------------------------------------+------------------------------------- Reporter: MartinF | Owner: Type: bug | thoughtpolice Priority: normal | Status: new Component: Build System | Milestone: 7.12.1 Resolution: | Version: 7.11 Operating System: Windows | Keywords: Type of failure: Building GHC | Architecture: failed | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9852 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: => thoughtpolice * component: Compiler => Build System * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 15:53:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 15:53:23 -0000 Subject: [GHC] #9958: System.IO.Error: Fix a documentation link to Control.Exception.Exception Message-ID: <044.f8406cf4d09c8eb4152860b58e11bb5f@haskell.org> #9958: System.IO.Error: Fix a documentation link to Control.Exception.Exception -------------------------------------+------------------------------------- Reporter: mineo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.8.4 libraries/base | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- On http://hackage.haskell.org/package/base-4.7.0.2/docs/System-IO- Error.html, the link to Control.Exception.Exception in the sentence "For a more general type of exception, including also those that arise in pure code, see Control.Exception.Exception." is broken because (in the source) it's a link to a module, but C.E.E is a type. Changing the double to single quotes fixes that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 16:04:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 16:04:13 -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.acb3fd949e2c2e7f7a6f59ea5dfccc47@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature request | Status: patch 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: | Blocking: | Differential Revisions: Phab:D578 -------------------------------------+------------------------------------- Comment (by gridaphobe): Replying to [comment:27 simonpj]: > You did not respond to bullet 5 of comment:24. I'd like to see displayed stacks looking like: > {{{ > foo, called at Bar.hs line 5 > wim, called as Wobble.hs line 9 > ...etc... > }}} > Currently we can get the call sites but not the function being called. I think it'd make the stacks a lot more informative. Sorry, my response was jumbled in with the rename to `CallStack` > ... but it looks like the `CtOrigin` that we get may not provide enough info. In my test-case at least, I'm getting a `TypeEqOrigin`, which isn't particularly helpful. The `TypeEqOrigin` appears to come from call-sites; I also get an `IPOccOrigin` when the IP is used. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 16:07:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 16:07:24 -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.df22ae8bf568acfd857822e18071e928@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature request | Status: patch 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: | Blocking: | Differential Revisions: Phab:D578 -------------------------------------+------------------------------------- Comment (by simonpj): Just ignore `CtOrigin` for now. Just think about getting a more informative stack. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 16:16:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 16:16:16 -0000 Subject: [GHC] #9946: Expose the source location of template-haskell Names In-Reply-To: <049.db4709f25d3264deb5da9ff8a9867c2f@haskell.org> References: <049.db4709f25d3264deb5da9ff8a9867c2f@haskell.org> Message-ID: <064.17bfb6b9084e96739c557816f44a3924@haskell.org> #9946: Expose the source location of template-haskell Names -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature request | Status: new Priority: low | 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): What is the specification? Exactly what location would you expect to get? Examples would be a good start. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 16:34:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 16:34:31 -0000 Subject: [GHC] #9923: Offer copy-on-GC sliced arrays In-Reply-To: <045.bfe02837f0b70bc36ccad815cc301a05@haskell.org> References: <045.bfe02837f0b70bc36ccad815cc301a05@haskell.org> Message-ID: <060.51e9ba552f79954c705b1605177aaa0c@haskell.org> #9923: Offer copy-on-GC sliced arrays -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | 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 svenpanne): Hmmm, I doubt that this would work: The proposal means that the garbage collector must allocate memory during collections, which is quite the opposite what it is supposed to do. Put another way: If somebody (SimonM?) thinks that this is possible, I would be very interested in the details. Even if this somehow works, there are several pathological cases like having lots of 999999-element slices of a 1000000-element array. Short-circuiting projection functions is OK (IIRC nhc did that first) because one doesn't have to allocate, but slicing is not really projecting. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 16:38:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 16:38:12 -0000 Subject: [GHC] #9923: Offer copy-on-GC sliced arrays In-Reply-To: <045.bfe02837f0b70bc36ccad815cc301a05@haskell.org> References: <045.bfe02837f0b70bc36ccad815cc301a05@haskell.org> Message-ID: <060.53fec9385324695e0905617dc892379b@haskell.org> #9923: Offer copy-on-GC sliced arrays -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | 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 dfeuer): Replying to [comment:1 svenpanne]: > Hmmm, I doubt that this would work: The proposal means that the garbage collector must allocate memory during collections, which is quite the opposite what it is supposed to do. Put another way: If somebody (SimonM?) thinks that this is possible, I would be very interested in the details. Even if this somehow works, there are several pathological cases like having lots of 999999-element slices of a 1000000-element array. > > Short-circuiting projection functions is OK (IIRC nhc did that first) because one doesn't have to allocate, but slicing is not really projecting. Yes, it would have to allocate while collecting, but I think this happens anyway. As for pathological cases, "Doctor! It hurts when I do ''this''! Don't do that." The suggested mechanism would not replace the usual sort of array slicing in general; it would be an alternative mechanism for situations where it was useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 21:37:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 21:37:05 -0000 Subject: [GHC] #9953: Pattern synonyms don't work with GADTs In-Reply-To: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> References: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> Message-ID: <061.77d69b366656a5e9bf9fa875efb5071c@haskell.org> #9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): The inferred type of `C1` should be isomoprhic to the declared type of `C2`. That is you should be able to declare `C2`'s type as {{{ pattern C2 :: (t ~ Maybe a) => a -> X t }}} if you want. Just as you can in a GADT declaration: the data constructor decl {{{ C :: arg1 -> arg2 -> T (Maybe a) }}} is precisely equivalent to (i.e. indistinguishable from) {{{ C :: (t ~ Maybe a) => arg1 -> arg2 -> T t }}} In the same way, you should be able to declare `C3`'s type as {{{ pattern C3 :: (t ~ Maybe a) => (Eq a) => a -> X t }}} if you want. As discussed in #9954, `C3` is simply ill typed. Does that resolve it? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 22:02:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 22:02:23 -0000 Subject: [GHC] #7485: Tuple constraints not properly kinded In-Reply-To: <047.eeebaeeddbb62123bab9dc0c17cad81f@haskell.org> References: <047.eeebaeeddbb62123bab9dc0c17cad81f@haskell.org> Message-ID: <062.191ad583ff2a501b258c5ae5d7b870ef@haskell.org> #7485: Tuple constraints not properly kinded -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | ConstraintKinds Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by crockeea): Is @simonpj 's comment > `(,)` has to have a particular kind still true with advent of `-XPolyKinds`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 22:02:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 22:02:33 -0000 Subject: [GHC] #7485: Tuple constraints not properly kinded In-Reply-To: <047.eeebaeeddbb62123bab9dc0c17cad81f@haskell.org> References: <047.eeebaeeddbb62123bab9dc0c17cad81f@haskell.org> Message-ID: <062.7e6021da84ada6cfa2381cd3fdb46ecb@haskell.org> #7485: Tuple constraints not properly kinded -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | ConstraintKinds Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by crockeea): * cc: ecrockett0@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 22:20:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 22:20:50 -0000 Subject: [GHC] #9959: removeDirectoryRecursive should not follow symlinks Message-ID: <045.bc668a211256e76b58f6ce62e4042a84@haskell.org> #9959: removeDirectoryRecursive should not follow symlinks -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.11 libraries/directory | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It's just, like, a really bad idea. And almost never what you want. (Also, it differs from the behavior of `rm -rf`). Can we just change the behavior? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 22:54:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 22:54:09 -0000 Subject: [GHC] #9960: Performance problem with TrieMap Message-ID: <046.1187d3cef9f049417e374209ab74c339@haskell.org> #9960: Performance problem with TrieMap -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Looking at #9805 reminded me. When investigating the performance of #9872 I found a major performance hole in `TrieMap`. Suppose we have a handful H of entries in a `TrieMap`, each with a very large key, size K. If you fold over such a `TrieMap` you'd expect time O(H). That would certainly be true of an association list! But with `TrieMap` we actually have to navigate down a long singleton structure to get to the elements, so it takes time O(K*H). This is pretty bad. In test `T9872` I found that 90% of compile time was spent in `TrieMap` as we repeatedly built, folded, and then rebuilt `TrieMap`s. I fixed that by keeping smaller `TrieMap`s, but the underlying problem remains. The point of a `TrieMap` is that you need to navigate to the point where only one key remains, and then things should be fast. So I think that `TypeMap`, say, should look like {{{ data TypeMap a = EmptyTM | SingletonTM Type a | TM { tm_var :: VarMap a , tm_app :: TypeMap (TypeMap a) , tm_fun :: TypeMap (TypeMap a) , tm_tc_app :: NameEnv (ListMap TypeMap a) , tm_forall :: TypeMap (BndrMap a) , tm_tylit :: TyLitMap a } }}} The `SingletonTM` means that, once you are down to a single (key,value) pair, you stop and just use `SingletonTM`. Tiresomely, because of the deBruijn thing, it'd need to be {{{ ... | SingletonTM (CMEnv, Type) a ... }}} and we'd need an auxiliary function for equality: {{{ eqTypeModuloDeBruijn :: (CMEnv, Type) -> (CEnv, Type) -> Bool }}} But that's not hard. Very similar to the way `RnEnv2` works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 22:54:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 22:54:57 -0000 Subject: [GHC] #9805: Use TrieMaps to speed up type class instance lookup In-Reply-To: <045.621217884d547d5010b211251c8e4ea4@haskell.org> References: <045.621217884d547d5010b211251c8e4ea4@haskell.org> Message-ID: <060.793eeae979f448aff68f9721e22d1734@haskell.org> #9805: Use TrieMaps to speed up type class instance lookup -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | 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: -------------------------------------+------------------------------------- Comment (by simonpj): If we need the keys, then yes, class `TrieKeyMap` looks good. But I'm not yet certain that we do. I need to look at your straw-man `TrieMap.hs`. See #9960 for an orthogonal issue that also concerns `TrieMap`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 22:58:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 22:58:51 -0000 Subject: [GHC] #9961: compile-time performance regression compiling genprimcode Message-ID: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> #9961: compile-time performance regression compiling genprimcode -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- compiling `utils/genprimopcode` (where compiling the Alex-generated Lexer takes up the most amount of time) with GHC 7.8.4: ``` $ time /opt/ghc/7.8.4/bin/ghc -Rghc-timing --make -O Main.hs [1 of 5] Compiling ParserM ( ParserM.hs, ParserM.o ) [2 of 5] Compiling Lexer ( Lexer.hs, Lexer.o ) [3 of 5] Compiling Syntax ( Syntax.hs, Syntax.o ) [4 of 5] Compiling Parser ( Parser.hs, Parser.o ) [5 of 5] Compiling Main ( Main.hs, Main.o ) Linking Main ... <> real 0m15.331s user 0m15.173s sys 0m0.172s ``` (btw, is it ok that GC takes up so much?) the same with a GHC 7.10 snapshot takes *alot* longer: ``` $ time /opt/ghc/7.10.1/bin/ghc -Rghc-timing --make -O Main.hs [1 of 5] Compiling ParserM ( ParserM.hs, ParserM.o ) [2 of 5] Compiling Lexer ( Lexer.hs, Lexer.o ) [3 of 5] Compiling Syntax ( Syntax.hs, Syntax.o ) [4 of 5] Compiling Parser ( Parser.hs, Parser.o ) [5 of 5] Compiling Main ( Main.hs, Main.o ) Linking Main ... <> real 5m17.061s user 5m16.702s sys 0m0.499s ``` ...and here the GC/MUT ratio is even more off. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 22:59:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 22:59:22 -0000 Subject: [GHC] #9961: compile-time performance regression compiling genprimcode In-Reply-To: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> References: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> Message-ID: <057.f84d8ea6075db946eb2c2c0f9d0370b6@haskell.org> #9961: compile-time performance regression compiling genprimcode -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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: -------------------------------------+------------------------------------- Description changed by hvr: Old description: > compiling `utils/genprimopcode` (where compiling the Alex-generated Lexer > takes up the most amount of time) with GHC 7.8.4: > > ``` > $ time /opt/ghc/7.8.4/bin/ghc -Rghc-timing --make -O Main.hs > [1 of 5] Compiling ParserM ( ParserM.hs, ParserM.o ) > [2 of 5] Compiling Lexer ( Lexer.hs, Lexer.o ) > [3 of 5] Compiling Syntax ( Syntax.hs, Syntax.o ) > [4 of 5] Compiling Parser ( Parser.hs, Parser.o ) > [5 of 5] Compiling Main ( Main.hs, Main.o ) > Linking Main ... > < residency (33 samples), 332M in use, 0.00 INIT (0.00 elapsed), 7.84 MUT > (8.35 elapsed), 6.93 GC (6.93 elapsed) :ghc>> > > real 0m15.331s > user 0m15.173s > sys 0m0.172s > ``` > > (btw, is it ok that GC takes up so much?) > > the same with a GHC 7.10 snapshot takes *alot* longer: > > ``` > $ time /opt/ghc/7.10.1/bin/ghc -Rghc-timing --make -O Main.hs > [1 of 5] Compiling ParserM ( ParserM.hs, ParserM.o ) > [2 of 5] Compiling Lexer ( Lexer.hs, Lexer.o ) > [3 of 5] Compiling Syntax ( Syntax.hs, Syntax.o ) > [4 of 5] Compiling Parser ( Parser.hs, Parser.o ) > [5 of 5] Compiling Main ( Main.hs, Main.o ) > Linking Main ... > < residency (538 samples), 876M in use, 0.001 INIT (0.001 elapsed), 81.374 > MUT (81.888 elapsed), 235.240 GC (235.136 elapsed) :ghc>> > > real 5m17.061s > user 5m16.702s > sys 0m0.499s > ``` > > ...and here the GC/MUT ratio is even more off. New description: compiling `utils/genprimopcode` (where compiling the Alex-generated Lexer takes up the most amount of time) with GHC 7.8.4: {{{ $ time /opt/ghc/7.8.4/bin/ghc -Rghc-timing --make -O Main.hs [1 of 5] Compiling ParserM ( ParserM.hs, ParserM.o ) [2 of 5] Compiling Lexer ( Lexer.hs, Lexer.o ) [3 of 5] Compiling Syntax ( Syntax.hs, Syntax.o ) [4 of 5] Compiling Parser ( Parser.hs, Parser.o ) [5 of 5] Compiling Main ( Main.hs, Main.o ) Linking Main ... <> real 0m15.331s user 0m15.173s sys 0m0.172s }}} (btw, is it ok that GC takes up so much?) the same with a GHC 7.10 snapshot takes *alot* longer: {{{ $ time /opt/ghc/7.10.1/bin/ghc -Rghc-timing --make -O Main.hs [1 of 5] Compiling ParserM ( ParserM.hs, ParserM.o ) [2 of 5] Compiling Lexer ( Lexer.hs, Lexer.o ) [3 of 5] Compiling Syntax ( Syntax.hs, Syntax.o ) [4 of 5] Compiling Parser ( Parser.hs, Parser.o ) [5 of 5] Compiling Main ( Main.hs, Main.o ) Linking Main ... <> real 5m17.061s user 5m16.702s sys 0m0.499s }}} ...and here the GC/MUT ratio is even more off. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 23:08:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 23:08:20 -0000 Subject: [GHC] #9389: Full Test Suite Failures In-Reply-To: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> References: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> Message-ID: <057.b87b9efef5f4ebb7113eed4e58a46d56@haskell.org> #9389: Full Test Suite Failures -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: #9286,#8756,#7876,#7877 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jrp): An unadorned {{{validate}}} gives {{{ Unexpected results from: TEST="sigcabal01" OVERALL SUMMARY for test run started at Mon Jan 5 22:57:44 2015 GMT 0:05:44 spent to go through 4388 total tests, which gave rise to 14199 test cases, of which 10157 were skipped 52 had missing libraries 3919 expected passes 70 expected failures 0 caused framework failures 0 unexpected passes 1 unexpected failures 0 unexpected stat failures Unexpected failures: cabal/sigcabal01 sigcabal01 [bad stderr] (normal) }}} Cool. I'll out up full results tomorrow. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 23:14:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 23:14:48 -0000 Subject: [GHC] #9805: Use TrieMaps to speed up type class instance lookup In-Reply-To: <045.621217884d547d5010b211251c8e4ea4@haskell.org> References: <045.621217884d547d5010b211251c8e4ea4@haskell.org> Message-ID: <060.9322744ea8d872df9ee5bc28b8eee0ee@haskell.org> #9805: Use TrieMaps to speed up type class instance lookup -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | 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: -------------------------------------+------------------------------------- Comment (by ezyang): simonpj: The key (ahem) part where we need the keys is we compute substitutions. In the prototype, it's line 696. Essentially, you have a sub-trie, and want to extract all the expressions corresponding to entries in the sub-trie, since those are your substitutions. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 23:16:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 23:16:46 -0000 Subject: [GHC] #9805: Use TrieMaps to speed up type class instance lookup In-Reply-To: <045.621217884d547d5010b211251c8e4ea4@haskell.org> References: <045.621217884d547d5010b211251c8e4ea4@haskell.org> Message-ID: <060.e94ff5c60168b48e2b65d87a137b8ba5@haskell.org> #9805: Use TrieMaps to speed up type class instance lookup -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | 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: -------------------------------------+------------------------------------- Comment (by simonpj): I've taken a look at your straw man. I really don't understand it. What is `TyBox`?? Standing back, I'm sure that the template variables should be deBruijn- ised. And a `VarMap` should look like {{{ data VarMap a = VM { vm_bvar :: BoundVarMap a -- Bound variable , vm_fvar :: VarEnv a -- Free variable , vm_tvar :: TmplVarMap a } -- Template variable type TmplVar = Int -- Like BoundVar but a different namespace type TmplVarMap = IntMap }}} That is, in a key, a variable could be bound by a forall (`vm_bvar`), or free (`bm_fvar`), or a template variable (`vm_tvar`). So a key `(T (forall a. a -> b -> c))`, where b is a template variable and c is free will effectively be treated as {{{ T (forall. bv1 -> tv1 -> c) }}} where I used `bv1` for `BoundVar` 1 and `tv1` for `TmplVar` 1. When doing a `matchT` we must maintain a * `CmEnv`, for deBruijn of the foralls * `TmplVarMap (CmEnv,Type)` for the substitution so far, mapping template variables to types. Well, actually to a kind of lexical closure of `(CmEnv, Type)` (c.f. #9960). When matching, if the key is say (tv1,tv1), then the second time we encounter `tv1` it'll already be bound in the substitution, so we must check for equality with the equality function mentioned in #9960. I don't think an occurs-check can happen when ''matching''. Does that make sense? Happy to talk more, or Skype. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 23:19:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 23:19:18 -0000 Subject: [GHC] #9960: Performance problem with TrieMap In-Reply-To: <046.1187d3cef9f049417e374209ab74c339@haskell.org> References: <046.1187d3cef9f049417e374209ab74c339@haskell.org> Message-ID: <061.7fe32964694b559a4732c301116cacfb@haskell.org> #9960: Performance problem with TrieMap -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: this is basically just trie compression, although the specific scheme doesn't compress long intermediate nodes (and it would be tiresome to do so, since unlike strings we don't have a handy representation of an expression with a hole). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 5 23:24:01 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 05 Jan 2015 23:24:01 -0000 Subject: [GHC] #9960: Performance problem with TrieMap In-Reply-To: <046.1187d3cef9f049417e374209ab74c339@haskell.org> References: <046.1187d3cef9f049417e374209ab74c339@haskell.org> Message-ID: <061.83d791529e83e34c105ccab3043f63b2@haskell.org> #9960: Performance problem with TrieMap -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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): True. If you had just two big keys, say {{{ T A A A A A A A A A A A A A A B T A A A A A A A A A A A A A A C }}} then even with `SingletonTM` performance of a fold would be 2*10, not just 2 as it would with an association list. But I'm guessing that trees tend to diverge early in practice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 03:09:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 03:09:34 -0000 Subject: [GHC] #9948: Recommend class constraint instead of instance constraint In-Reply-To: <047.c66907ef09dd5fcc438f73ae7f72ae2e@haskell.org> References: <047.c66907ef09dd5fcc438f73ae7f72ae2e@haskell.org> Message-ID: <062.4eb28718fc5cd15d1f5bf6aa80f33335@haskell.org> #9948: Recommend class constraint instead of instance constraint -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by crockeea: Old description: > Consider the following example: > > {{{#!hs > {-# LANGUAGE FlexibleInstances, UndecidableInstances #-} > > module Foo where > > class Foo a where > foo :: Int -> a > > instance (Num a) => Foo a where > foo x = error "" > > f :: Int -> a > f = foo > }}} > > GHC says > > {{{ > No instance for (Num a) arising from a use of ?foo? > Possible fix: > add (Num a) to the context of the type signature for f :: Int -> a > In the expression: foo > In an equation for ?f?: f = foo > }}} > > A better error, in my opinion, would be: > > {{{ > No instance for (Foo a) arising from a use of ?foo? > Possible fix: > add (Foo a) to the context of the type signature for f :: Int -> a > In the expression: foo > In an equation for ?f?: f = foo > }}} > > That is, I think GHC should recommend the superclass constraint arising > from the use of `foo` rather than trying to match an instance and then > recommending constraints from the instance. > > Here are several reasons a superclass constraint is preferable: > > 1. If the matching instance has several constraints, GHC will recommend > putting *all* of those constraints on the function instead of a single > superclass constraint. This (naively) results in unnecessarily long > constraints on functions that call methods. > > 2. If the constraints on the instance change, GHC will recommend the > corresponding change on the function constraints. This means the instance > constraints are not isolated, but instead propagate through the code. > > 3. The instance constraints might not make sense on the function itself. > For example, `f` might not use any methods from the `Num` class, but GHC > recommends the `Num` constraint anyway. > > Recommending the direct superclass constraint should be **less** work for > GHC than the current implementation: instead of trying to find a matching > instance, it simply stops when it finds that `foo` is a method. New description: Consider the following example: {{{#!hs {-# LANGUAGE FlexibleInstances, UndecidableInstances #-} module Foo where class Foo a where foo :: Int -> a instance (Num a) => Foo a where foo x = error "" f :: Int -> a f = foo }}} GHC says {{{ No instance for (Num a) arising from a use of ?foo? Possible fix: add (Num a) to the context of the type signature for f :: Int -> a In the expression: foo In an equation for ?f?: f = foo }}} A better error, in my opinion, would be: {{{ No instance for (Foo a) arising from a use of ?foo? Possible fix: add (Foo a) to the context of the type signature for f :: Int -> a In the expression: foo In an equation for ?f?: f = foo }}} That is, I think GHC should recommend the ~~super~~class constraint arising from the use of `foo` rather than trying to match an instance and then recommending constraints from the instance head. Here are several reasons a ~~super~~class constraint is preferable: 1. If the matching instance has several constraints, GHC will recommend putting *all* of those constraints on the function instead of a single ~~super~~class constraint. This (naively) results in unnecessarily long constraints on functions that call methods. 2. If the constraints on the instance change, GHC will recommend the corresponding change on the function constraints. This means the instance constraints are not isolated, but instead propagate through the code. 3. The instance constraints might not make sense on the function itself. For example, `f` might not use any methods from the `Num` class, but GHC recommends the `Num` constraint anyway. Recommending the direct ~~super~~class constraint should be **less** work for GHC than the current implementation: instead of trying to find a matching instance, it simply stops when it finds that `foo` is a method. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 06:55:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 06:55:44 -0000 Subject: [GHC] #4150: CPP+QuasiQuotes confuses compilation errors' line numbers In-Reply-To: <046.62742d3f271c0ad2ad5ce838979c1b17@haskell.org> References: <046.62742d3f271c0ad2ad5ce838979c1b17@haskell.org> Message-ID: <061.fb025b9c9fd6bb1565adb922a7a5115f@haskell.org> #4150: CPP+QuasiQuotes confuses compilation errors' line numbers -------------------------------------+------------------------------------- Reporter: yairchu | Owner: Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Compiler | Version: 6.12.3 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect | Test Case: warning at compile-time | quasiquotation/T4150 Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by crobbins): I've been able to reproduce the issue; see the gist below. Hopefully this should be simple to incorporate into a test case. https://gist.github.com/carymrobbins/8345cdcf7830fd6b1a6e Thanks again for your help! I doubt I could be much help in the implementation department, but if there's anything else I can do let me know. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 07:53:17 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 07:53:17 -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.6999a409c7637c97667426ab21b1c2f9@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature request | Status: patch 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: | Blocking: | Differential Revisions: Phab:D578 -------------------------------------+------------------------------------- Comment (by gridaphobe): Replying to [comment:26 simonpj]: > Re "the second bullet point under Implementation Details", I now understand. Good point. The issue is this: > {{{ > f :: (?loc :: CallStack) => IO () > f = print (?location :: CallStack) > }}} > There are two alternatives for what to pass to `print`: > * Pass the call site of `print`, pushed onto the passed-in call stack > * Pass a singleton stack, just the call site of `print`, reflecting the change in name. > You have implemented the first, but I think the latter would perhaps be more intuitive. Does anyone else have opinions? The more I think about this, the more inclined I am to go with the latter behavior as well. The former, while useful, is just a bit strange. Also, from a maintainability perspective, it would probably be easier to switch from the 2nd to the 1st behavior, if needed, than vice-versa (since the 1st should allow strictly more programs to type-check). But I'd also like to hear from others. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 10:26:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 10:26:35 -0000 Subject: [GHC] #9962: time: Show instance for UTCTime is orphan Message-ID: <050.e9740b749b32fc8ba700af3893db63f0@haskell.org> #9962: time: Show instance for UTCTime is orphan -------------------------------------+------------------------------------- Reporter: | Owner: SimonHengel | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: libraries | Operating System: Unknown/Multiple (other) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 11:23:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 11:23:49 -0000 Subject: [GHC] #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family In-Reply-To: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> References: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> Message-ID: <060.0f3749d06b9000dd1559b3099736488f@haskell.org> #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family -------------------------------------+------------------------------------- Reporter: qnikst | 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): I feel stuck on this. I can see Oleg's goal, but I don't want to require him to use a potentially-unsound route to gain it. It's tantalising that overlapping type classes achieve the same end without risking unsoundness. Surely we must be able to replicate this in type families, somehow? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 11:40:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 11:40:50 -0000 Subject: [GHC] #9961: compile-time performance regression compiling genprimcode In-Reply-To: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> References: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> Message-ID: <057.642a8323987dc440fc3f9c68e5c8cd5d@haskell.org> #9961: compile-time performance regression compiling genprimcode -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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): Can anyone build a profiled GHC and see where the time is going? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 12:21:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 12:21:15 -0000 Subject: [GHC] #9948: Recommend class constraint instead of instance constraint In-Reply-To: <047.c66907ef09dd5fcc438f73ae7f72ae2e@haskell.org> References: <047.c66907ef09dd5fcc438f73ae7f72ae2e@haskell.org> Message-ID: <062.ba485546508effb2ae3d463e86b1d4b2@haskell.org> #9948: Recommend class constraint instead of instance constraint -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by adamgundry): I think the message ought to keep saying `No instance for (Num a)` because that is exactly what is logically missing, as Richard says. There is an instance for `Foo a`, and it would be very confusing if GHC claimed there wasn't. I'd be open to the `Possible fix` line saying `(Num a) or (Foo a)`, but I suspect the work required to change it may outweigh the benefit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 14:02:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 14:02:30 -0000 Subject: [GHC] #9961: compile-time performance regression compiling genprimcode In-Reply-To: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> References: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> Message-ID: <057.7a9c7a6e2cce3daea558187bbfd30ff1@haskell.org> #9961: compile-time performance regression compiling genprimcode -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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): I can't reproduce this with HEAD. I used this command line, from the root directory, which I took from a build log {{{ ghc -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Werror -Wall -H64m -i -iutils/genprimopcode/. -iutils/genprimopcode/dist/build -iutils/genprimopcode/dist/build/autogen -Iutils/genprimopcode/dist/build -Iutils/genprimopcode/dist/build/autogen -package array -no-user- package-db -rtsopts -odir utils/genprimopcode/dist/build -hidir utils/genprimopcode/dist/build -stubdir utils/genprimopcode/dist/build --make utils/genprimopcode/Main.hs -fforce-recomp +RTS -s }}} With HEAD I get {{{ 4,189,727,416 bytes allocated in the heap 525,871,120 bytes copied during GC 43,253,816 bytes maximum residency (12 sample(s)) 1,758,368 bytes maximum slop 116 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 600 colls, 0 par 1.824s 1.823s 0.0030s 0.0271s Gen 1 12 colls, 0 par 0.811s 0.811s 0.0676s 0.1351s 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.002s ( 0.001s elapsed) MUT time 6.997s ( 7.946s elapsed) GC time 2.635s ( 2.635s elapsed) EXIT time 0.038s ( 0.037s elapsed) Total time 9.711s ( 10.619s elapsed) }}} With ghc 7.8 I get {{{ 3,874,936,096 bytes allocated in the heap 416,943,272 bytes copied during GC 44,518,152 bytes maximum residency (10 sample(s)) 1,549,168 bytes maximum slop 115 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 396 colls, 0 par 1.21s 1.25s 0.0032s 0.0207s Gen 1 10 colls, 0 par 0.57s 0.65s 0.0654s 0.1421s 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.00s ( 0.00s elapsed) MUT time 5.63s ( 6.59s elapsed) GC time 1.78s ( 1.91s elapsed) EXIT time 0.03s ( 0.04s elapsed) Total time 7.46s ( 8.54s elapsed) }}} They may not be quite comparable (e.g. my HEAD libraries are built with -O, but I think my installed GHC probably has libraries built with -O2). But HEAD is not way out of line. I suppose I can now try building the 7.10 branch. Meanwhile, would someone try with `-dshow-passes` (which displays intermediate sizes)? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 15:10:01 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 15:10:01 -0000 Subject: [GHC] #9939: Warn for duplicate superclass constraints In-Reply-To: <047.cbb3a535ba98b12eaa610d54289e6f43@haskell.org> References: <047.cbb3a535ba98b12eaa610d54289e6f43@haskell.org> Message-ID: <062.1b5e38ca776a2dcc3bba6455662ce808@haskell.org> #9939: Warn for duplicate superclass constraints -------------------------------------+------------------------------------- Reporter: crockeea | 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: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"32973bf3c2f6fe00e01b44a63ac1904080466938/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="32973bf3c2f6fe00e01b44a63ac1904080466938" Major patch to add -fwarn-redundant-constraints The idea was promted by Trac #9939, but it was Christmas, so I did some recreational programming that went much further. The idea is to warn when a constraint in a user-supplied context is redundant. Everything is described in detail in Note [Tracking redundant constraints] in TcSimplify. Main changes: * The new ic_status field in an implication, of type ImplicStatus. It replaces ic_insol, and includes information about redundant constraints. * New function TcSimplify.setImplicationStatus sets the ic_status. * TcSigInfo has sig_report_redundant field to say whenther a redundant constraint should be reported; and similarly the FunSigCtxt constructor of UserTypeCtxt * EvBinds has a field eb_is_given, to record whether it is a given or wanted binding. Some consequential chagnes to creating an evidence binding (so that we record whether it is given or wanted). * AbsBinds field abs_ev_binds is now a *list* of TcEvBiinds; see Note [Typechecking plan for instance declarations] in TcInstDcls * Some significant changes to the type checking of instance declarations; Note [Typechecking plan for instance declarations] in TcInstDcls. * I found that TcErrors.relevantBindings was failing to zonk the origin of the constraint it was looking at, and hence failing to find some relevant bindings. Easy to fix, and orthogonal to everything else, but hard to disentangle. Some minor refactorig: * TcMType.newSimpleWanteds moves to Inst, renamed as newWanteds * TcClassDcl and TcInstDcls now have their own code for typechecking a method body, rather than sharing a single function. The shared function (ws TcClassDcl.tcInstanceMethodBody) didn't have much code and the differences were growing confusing. * Add new function TcRnMonad.pushLevelAndCaptureConstraints, and use it * Add new function Bag.catBagMaybes, and use it in TcSimplify }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 15:29:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 15:29:02 -0000 Subject: [GHC] #9939: Warn for duplicate superclass constraints In-Reply-To: <047.cbb3a535ba98b12eaa610d54289e6f43@haskell.org> References: <047.cbb3a535ba98b12eaa610d54289e6f43@haskell.org> Message-ID: <062.54ee6bafe5bc108808fac58f2050bd78@haskell.org> #9939: Warn for duplicate superclass constraints -------------------------------------+------------------------------------- Reporter: crockeea | 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: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c790fe87be648f420c63099934852013a4e8a8f7/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c790fe87be648f420c63099934852013a4e8a8f7" Test Trac #9939 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 15:33:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 15:33:27 -0000 Subject: [GHC] #9939: Warn for duplicate superclass constraints In-Reply-To: <047.cbb3a535ba98b12eaa610d54289e6f43@haskell.org> References: <047.cbb3a535ba98b12eaa610d54289e6f43@haskell.org> Message-ID: <062.9be77b5202b9332c347e3bfc94c9c5ba@haskell.org> #9939: Warn for duplicate superclass constraints -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | typecheck/should_compile/T9939 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => typecheck/should_compile/T9939 * resolution: => fixed Comment: Well, I went ''way'' overboard on this, but it was fun! Thanks for the suggestion. It showed up masses of unnecessary constraints in the compiler itself, and in many libraries, as you can see from {{{ commit c409b6f30373535b6eed92e55d4695688d32be9e Author: Simon Peyton Jones Date: Tue Jan 6 13:46:35 2015 +0000 Remove redundant constraints from libraries, discovered by -fwarn- redundant-constraints libraries/array | 2 +- libraries/base/Data/Data.hs | 8 +++---- libraries/base/Data/Foldable.hs | 4 ++-- libraries/base/GHC/Arr.hs | 46 ++++++++++++++++++------------------- libraries/base/GHC/Event/Array.hs | 4 ++-- libraries/base/GHC/IOArray.hs | 4 ++-- libraries/base/GHC/Real.hs | 6 ++--- libraries/base/Text/Printf.hs | 2 +- libraries/deepseq | 2 +- libraries/hoopl | 2 +- libraries/parallel | 2 +- mk/validate-settings.mk | 3 +++ }}} and {{{ commit 39337a6d97c853a88fa61d6b12a04eb8c2e5984f Author: Simon Peyton Jones Date: Mon Jan 5 16:57:01 2015 +0000 Remove redundant constraints in the compiler itself, found by -fwarn- redundant-constraints compiler/basicTypes/Name.hs | 3 ++- compiler/cmm/CmmExpr.hs | 8 ++++---- compiler/cmm/Hoopl/Dataflow.hs | 2 +- compiler/coreSyn/TrieMap.hs | 4 ++-- compiler/deSugar/MatchLit.hs | 2 +- compiler/ghci/ByteCodeItbls.hs | 6 ++++-- compiler/ghci/Linker.hs | 2 +- compiler/hsSyn/HsDecls.hs | 8 +++----- compiler/hsSyn/HsExpr.hs | 8 ++++---- compiler/main/CmdLineParser.hs | 2 +- compiler/main/GHC.hs | 10 +++++++--- compiler/main/GhcMonad.hs | 17 ++++++++++++---- compiler/main/InteractiveEval.hs | 3 +-- compiler/nativeGen/RegAlloc/Graph/SpillClean.hs | 11 ++++------- compiler/nativeGen/RegAlloc/Linear/Main.hs | 4 ++-- compiler/nativeGen/SPARC/Base.hs | 2 +- compiler/typecheck/TcRnMonad.hs | 3 ++- compiler/types/CoAxiom.hs | 2 +- compiler/utils/Binary.hs | 2 +- compiler/utils/GraphColor.hs | 6 +++--- compiler/utils/GraphOps.hs | 24 ++++++++++------------- compiler/utils/GraphPpr.hs | 9 ++++----- compiler/utils/Maybes.hs | 4 ++++ compiler/utils/Serialized.hs | 4 ++-- compiler/utils/UniqSet.hs | 2 +- }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 16:25:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 16:25:20 -0000 Subject: [GHC] #7485: Tuple constraints not properly kinded In-Reply-To: <047.eeebaeeddbb62123bab9dc0c17cad81f@haskell.org> References: <047.eeebaeeddbb62123bab9dc0c17cad81f@haskell.org> Message-ID: <062.8fd10ef9e5e3486ec9a0a9d8957f97dd@haskell.org> #7485: Tuple constraints not properly kinded -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | ConstraintKinds Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:3 crockeea]: > Is @simonpj 's comment > > `(,)` has to have a particular kind > still true with advent of `-XPolyKinds`? Yes. The problem is that `(,)` isn't really poly-kinded. It's not, for example, `k -> k -> k`. It's either `* -> * -> *` or `Constraint -> Constraint -> Constraint`, and there's no way of saying this in normal Haskell. So, we have the hack Simon describes above. One possible way forward is to follow the NoSubKinds route: introduce a new type `ValueKind` parameterized by elements of `data StarOrConstraint = Star | Ct`. Then `*` would be a synonym for `ValueKind Star` and `Constraint` would be `ValueKind Ct`. We would then have `(,) :: forall (x :: StarOrConstraint). ValueKind x -> ValueKind x -> ValueKind x`. This would be very hard to implement before merging my DependentHaskell branch though, because it requires kind synonyms and other funny business. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 16:31:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 16:31:30 -0000 Subject: [GHC] #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family In-Reply-To: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> References: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> Message-ID: <060.da4677dc066d03e6a8ee244fdacf341a@haskell.org> #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family -------------------------------------+------------------------------------- Reporter: qnikst | 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 goldfire): Replying to [comment:17 simonpj]: > It's tantalising that overlapping type classes achieve the same end without risking unsoundness. Surely we must be able to replicate this in type families, somehow? However, a mistake with type family reduction is unsound. A mistake with class instance selection is unpredictable/incoherent, but not unsound. I posit that we have such a mistake lurking here -- a loophole that, if we closed it, would prevent Oleg's working case from working. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 17:08:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 17:08:44 -0000 Subject: [GHC] #9961: compile-time performance regression compiling genprimcode In-Reply-To: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> References: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> Message-ID: <057.812bc8762393ab5a7247c9a814e19c04@haskell.org> #9961: compile-time performance regression compiling genprimcode -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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): I tried with the 7.10 branch, and got {{{ 4,187,629,104 bytes allocated in the heap 476,423,296 bytes copied during GC 42,531,768 bytes maximum residency (11 sample(s)) 1,561,840 bytes maximum slop 96 MB total memory in use (0 MB lost due to fragmentation) Tot time (elapsed) Avg pause Max pause Gen 0 619 colls, 0 par 1.937s 1.936s 0.0031s 0.0290s Gen 1 11 colls, 0 par 0.710s 0.710s 0.0645s 0.1338s 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.002s ( 0.001s elapsed) MUT time 6.782s ( 7.641s elapsed) GC time 2.647s ( 2.646s elapsed) EXIT time 0.035s ( 0.034s elapsed) Total time 9.497s ( 10.323s elapsed) }}} So I can't reproduce the slow compile time. Alas. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 17:41:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 17:41:46 -0000 Subject: [GHC] #9946: Expose the source location of template-haskell Names In-Reply-To: <049.db4709f25d3264deb5da9ff8a9867c2f@haskell.org> References: <049.db4709f25d3264deb5da9ff8a9867c2f@haskell.org> Message-ID: <064.40f22bc9584e92b2c6c009771ca7d5d5@haskell.org> #9946: Expose the source location of template-haskell Names -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature request | Status: new Priority: low | 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 gridaphobe): Spec: Add a single function {{{ nameSrcLoc :: TH.Name -> GHC.SrcLoc.SrcLoc }}} using the upcoming `SrcLoc` type from [https://phabricator.haskell.org/D578 D578], which returns the span of the whole definition, e.g. {{{ module A where head :: [a] -> a head [] = undefined head (x:_) = x }}} {{{ module B where loc = nameLoc 'A.head -- loc == A.hs:3:1-5:15 }}} This provides maximal information, and my intuition is that it might be easier for clients to narrow the span (e.g. to the first equation) if needed than to widen it. But, as above, I've only ever needed the filepath in practice, so I'm very open to convincing that a different span would be more useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 17:49:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 17:49:49 -0000 Subject: [GHC] #9961: compile-time performance regression compiling genprimcode In-Reply-To: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> References: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> Message-ID: <057.69a6316e377b30a5f5b2bd66a1e54097@haskell.org> #9961: compile-time performance regression compiling genprimcode -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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 hvr): That's weird... I just tried with today's GHC HEAD (at 696f2cfdea4ab87cc457b141323bb25ab4afe795), and a `BuildFlavour="quick"` build. The exact steps I took now were: {{{#!sh cd utils/genprimopcode/ rm *.o *.hi alex Lexer.x ../inplace/bin/ghc-stage2 -Rghc-timing -O -c ParserM.hs # <> ../inplace/bin/ghc-stage2 -Rghc-timing -O -c Lexer.hs # ...runs for over 15 minutes... }}} So I can actually reproduce this with GHC HEAD -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 18:24:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 18:24:25 -0000 Subject: [GHC] #9961: compile-time performance regression compiling genprimcode In-Reply-To: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> References: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> Message-ID: <057.9bfd5b44c5820993a2e59b819649561e@haskell.org> #9961: compile-time performance regression compiling genprimcode -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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 hvr): Here's the output of {{{#!sh time /opt/ghc/7.10.1/bin/ghc -O -dshow-passes -c Lexer.hs |& ts -s "%.s" }}} Each output line is prepended by a timestamp expressed in seconds: {{{ 0.000012 Glasgow Haskell Compiler, Version 7.10.0.20141227, stage 2 booted by GHC version 7.8.4 0.000080 Using binary package database: /opt/ghc/7.10.1/lib/ghc-7.10.0.20141227/package.conf.d/package.cache 0.001052 Using binary package database: /home/hvr/.ghc/x86_64-linux-7.10.0.20141227/package.conf.d/package.cache 0.020922 wired-in package ghc-prim mapped to ghc- prim-0.3.1.0-000208e3187fe823e04e0c88352da107 0.020997 wired-in package integer-gmp mapped to integer- gmp-1.0.0.0-bb665344376cc98555dad190d849a337 0.021545 wired-in package base mapped to base-4.8.0.0-7f94b08ebb75c6cfab2660fb04137780 0.021578 wired-in package rts mapped to builtin_rts 0.021650 wired-in package template-haskell mapped to template- haskell-2.10.0.0-ab6ca4770f90f6f44262138da6877395 0.021676 wired-in package ghc mapped to ghc-7.10.0.20141227-217cbe8ba9c57a128065806ea73c39b4 0.021689 wired-in package dph-seq not found. 0.021758 wired-in package dph-par not found. 0.022632 Created temporary directory: /tmp/ghc16466_0 0.022703 *** C pre-processor: 0.028039 *** Checking old interface for Lexer: 0.028103 *** Parser: 0.214401 *** Renamer/typechecker: 1.362793 *** Desugar: 1.841327 Result size of Desugar (after optimization) 1.841402 = {terms: 97,708, types: 6,414, coercions: 7} 1.841418 *** Simplifier: 2.113916 Result size of Simplifier iteration=1 2.113977 = {terms: 92,764, types: 1,443, coercions: 16} 2.369659 Result size of Simplifier 2.369721 = {terms: 92,764, types: 1,443, coercions: 16} 2.369732 *** Specialise: 2.432081 Result size of Specialise 2.432143 = {terms: 92,928, types: 1,649, coercions: 34} 2.432154 *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}): 2.432163 Result size of Float out(FOS {Lam = Just 0, 2.432174 Consts = True, 2.761993 OverSatApps = False}) 2.762059 = {terms: 161,836, types: 37,472, coercions: 34} 2.762070 *** Simplifier: 7.394822 Result size of Simplifier iteration=1 7.394887 = {terms: 233,709, types: 119,483, coercions: 965} 8.202722 Result size of Simplifier iteration=2 8.202785 = {terms: 233,373, types: 119,022, coercions: 774} 8.873386 Result size of Simplifier iteration=3 8.873447 = {terms: 233,369, types: 119,019, coercions: 771} 9.562065 Result size of Simplifier 9.562127 = {terms: 233,369, types: 119,019, coercions: 771} 9.562142 *** Simplifier: 10.462517 Result size of Simplifier iteration=1 10.462582 = {terms: 233,348, types: 118,990, coercions: 771} 11.290064 Result size of Simplifier 11.290130 = {terms: 233,340, types: 118,978, coercions: 771} 11.290146 *** Simplifier: 12.081775 Result size of Simplifier iteration=1 12.081839 = {terms: 233,381, types: 119,015, coercions: 771} 13.042842 Result size of Simplifier iteration=2 13.042906 = {terms: 233,356, types: 118,973, coercions: 771} 13.916546 Result size of Simplifier 13.916613 = {terms: 233,356, types: 118,973, coercions: 771} 13.916629 *** Float inwards: 14.237678 Result size of Float inwards 14.237740 = {terms: 233,356, types: 118,973, coercions: 771} 14.237755 *** Called arity analysis: 14.602005 Result size of Called arity analysis 14.602069 = {terms: 233,356, types: 118,973, coercions: 771} 14.602085 *** Simplifier: 15.475958 Result size of Simplifier iteration=1 15.476022 = {terms: 233,350, types: 118,967, coercions: 771} 16.353738 Result size of Simplifier 16.353807 = {terms: 233,350, types: 118,967, coercions: 771} 16.353824 *** Demand analysis: 17.733968 Result size of Demand analysis 17.734033 = {terms: 233,350, types: 118,967, coercions: 771} 17.734050 *** Worker Wrapper binds: 17.862780 Result size of Worker Wrapper binds 17.862858 = {terms: 233,515, types: 119,216, coercions: 771} 17.862873 *** Simplifier: 18.758890 Result size of Simplifier iteration=1 18.758955 = {terms: 233,463, types: 119,172, coercions: 771} 19.651759 Result size of Simplifier iteration=2 19.651822 = {terms: 233,394, types: 119,034, coercions: 771} 20.558257 Result size of Simplifier 20.558318 = {terms: 233,394, types: 119,034, coercions: 771} 20.558329 *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}): 20.558337 Result size of Float out(FOS {Lam = Just 0, 20.558347 Consts = True, 21.488077 OverSatApps = True}) 21.488144 = {terms: 292,556, types: 150,261, coercions: 771} 21.488160 *** Common sub-expression: 314.182413 Result size of Common sub-expression 314.182475 = {terms: 263,668, types: 149,641, coercions: 219} 314.182488 *** Float inwards: 314.655439 Result size of Float inwards 314.655503 = {terms: 263,668, types: 149,641, coercions: 219} 314.655518 *** Simplifier: 315.557057 Result size of Simplifier iteration=1 315.557125 = {terms: 206,235, types: 120,272, coercions: 219} 316.231673 Result size of Simplifier iteration=2 316.231735 = {terms: 206,236, types: 120,271, coercions: 219} 317.062088 Result size of Simplifier 317.062153 = {terms: 206,236, types: 120,271, coercions: 219} 317.062169 *** Tidy Core: 317.468495 Result size of Tidy Core 317.468565 = {terms: 206,104, types: 120,130, coercions: 219} 317.473975 *** CorePrep: 318.294956 Result size of CorePrep 318.295026 = {terms: 206,396, types: 120,491, coercions: 219} 318.295038 *** Stg2Stg: 318.295050 *** CodeGen: 323.746799 *** Assembler: 323.934329 *** Deleting temp files: 323.934396 Warning: deleting non-existent /tmp/ghc16466_0/ghc16466_3.c 323.934873 *** Deleting temp dirs: real 5m24.015s user 5m23.707s sys 0m0.489s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 19:02:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 19:02:20 -0000 Subject: [GHC] #7485: Tuple constraints not properly kinded In-Reply-To: <047.eeebaeeddbb62123bab9dc0c17cad81f@haskell.org> References: <047.eeebaeeddbb62123bab9dc0c17cad81f@haskell.org> Message-ID: <062.a0dd31c4a0ea3f7fb77aed508310caf7@haskell.org> #7485: Tuple constraints not properly kinded -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | ConstraintKinds Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): FWIW- After Simon posted the original suggestion for how to do this, Dan Doel and I implemented it without problem in Ermine in an afternoon. It is a rather nice fix for this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 19:17:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 19:17:41 -0000 Subject: [GHC] #9946: Expose the source location of template-haskell Names In-Reply-To: <049.db4709f25d3264deb5da9ff8a9867c2f@haskell.org> References: <049.db4709f25d3264deb5da9ff8a9867c2f@haskell.org> Message-ID: <064.969017a8e1aa47c038a5dc05dacebcc9@haskell.org> #9946: Expose the source location of template-haskell Names -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature request | Status: new Priority: low | 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 gridaphobe): Actually, including the type signature doesn't seem feasible (or at least useful), given that {{{ foo :: Int -> Int bar :: Int -> Int foo = ... bar = ... }}} is perfectly valid. So let me amend my example [comment:2 above] to {{{ loc = nameLoc 'A.head -- loc == A.hs:4:1-5:15 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 20:37:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 20:37:00 -0000 Subject: [GHC] #9805: Use TrieMaps to speed up type class instance lookup In-Reply-To: <045.621217884d547d5010b211251c8e4ea4@haskell.org> References: <045.621217884d547d5010b211251c8e4ea4@haskell.org> Message-ID: <060.9028dab330fc4550ca27ec1d3240b826@haskell.org> #9805: Use TrieMaps to speed up type class instance lookup -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | 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: -------------------------------------+------------------------------------- Comment (by ezyang): Some clarifying comments from the Skype conversation: 1. The reason why the first prototype doesn't make sense was because I accidentally thought the template variables were in the expression I was matching with, rather than in the *keys* of the TrieMap. This was also why I believed a key was necessary. 2. TyBox in the prototype is a hack to avoid having circularity when specifying the kind of box. We don't really need kinds for the prototype but I was trying to keep the data structures as close as possible to GHC proper. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 20:51:29 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 20:51:29 -0000 Subject: [GHC] #9389: Full Test Suite Failures In-Reply-To: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> References: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> Message-ID: <057.e2b2ee1f283733b4352b5146fc9013bd@haskell.org> #9389: Full Test Suite Failures -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: #9286,#8756,#7876,#7877 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jrp): The result of {{{make fulltest THREADS=8}}} with {{{BuildFlavour = quick}}} {{{ OVERALL SUMMARY for test run started at Tue Jan 6 20:00:16 2015 GMT 0:45:55 spent to go through 4389 total tests, which gave rise to 14206 test cases, of which 2703 were skipped 267 had missing libraries 10980 expected passes 148 expected failures 3 caused framework failures 0 unexpected passes 86 unexpected failures 19 unexpected stat failures Unexpected failures: ../../libraries/base/tests enum01 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) ../../libraries/base/tests enum01 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum02 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) ../../libraries/base/tests enum02 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum03 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) ../../libraries/base/tests enum03 [bad stdout or stderr] (ghci) ../../libraries/base/tests topHandler01 [bad exit code] (threaded1,threaded2) ../../libraries/base/tests topHandler01 [bad stdout or stderr] (ghci) ../../libraries/base/tests topHandler03 [bad exit code] (ghci) ../../libraries/hpc/tests/simple/tixs hpc_markup_001 [bad stdout] (normal) ../../libraries/hpc/tests/simple/tixs hpc_markup_002 [bad stdout] (normal) ../../libraries/process/tests process011 [bad exit code] (threaded1,threaded2) ../../libraries/process/tests process011 [bad stdout or stderr] (ghci) ../../libraries/unix/tests signals002 [bad stdout] (threaded1,threaded2) ../../libraries/unix/tests signals002 [bad stdout or stderr] (ghci) cabal/sigcabal01 sigcabal01 [bad stderr] (normal) codeGen/should_run CgStaticPointers [bad stdout or stderr] (ghci) concurrent/should_run allocLimit4 [bad exit code] (ghci) concurrent/should_run conc012 [bad exit code] (ghci) concurrent/should_run conc059 [bad stderr] (threaded1,threaded2) deSugar/should_run DsStaticPointers [bad stdout or stderr] (ghci) deSugar/should_run dsrun014 [bad exit code] (ghci) driver T9938 [bad exit code] (normal) driver/retc001 retc001 [bad stderr] (normal) ghci/scripts ghci024 [bad stdout] (normal) numeric/should_run add2 [bad exit code] (ghci) numeric/should_run mul2 [bad exit code] (ghci) numeric/should_run quotRem2 [bad exit code] (ghci) parser/should_run readRun004 [bad exit code] (ghci) rts GcStaticPointers [bad stdout or stderr] (ghci) rts ListStaticPointers [bad stdout or stderr] (ghci) rts T7919 [bad exit code] (optasm,threaded2,dyn) th TH_StaticPointers [bad stdout or stderr] (ghci) typecheck/should_compile T9939 [stderr mismatch] (normal,hpc,optasm) typecheck/should_run T3500a [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run T3500a [bad stdout or stderr] (ghci) typecheck/should_run T5751 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run T5751 [bad stdout or stderr] (ghci) typecheck/should_run T7126 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run T7126 [bad stdout or stderr] (ghci) typecheck/should_run T7861 [bad exit code] (normal,hpc,optasm,ghci,threaded1,threaded2,dyn) typecheck/should_run tcrun045 [stderr mismatch] (normal) Unexpected stat failures: perf/compiler T1969 [stat not good enough] (normal) perf/compiler T3064 [stat not good enough] (normal) perf/compiler T3294 [stat not good enough] (normal) perf/compiler T4801 [stat not good enough] (normal) perf/compiler T5030 [stat not good enough] (normal) perf/compiler T5321FD [stat not good enough] (normal) perf/compiler T5321Fun [stat not good enough] (normal) perf/compiler T5631 [stat not good enough] (normal) perf/compiler T5642 [stat not good enough] (normal) perf/compiler T5837 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) perf/compiler T783 [stat not good enough] (normal) perf/compiler T9020 [stat not good enough] (optasm) perf/compiler T9675 [stat not good enough] (optasm) perf/compiler T9872a [stat not good enough] (normal) perf/compiler T9872b [stat not good enough] (normal) perf/compiler T9872c [stat not good enough] (normal) perf/compiler T9872d [stat not good enough] (normal) perf/compiler parsing001 [stat not good enough] (normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 21:11:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 21:11:18 -0000 Subject: [GHC] #9923: Offer copy-on-GC sliced arrays In-Reply-To: <045.bfe02837f0b70bc36ccad815cc301a05@haskell.org> References: <045.bfe02837f0b70bc36ccad815cc301a05@haskell.org> Message-ID: <060.8ea8095e62a74ae5c49dea3080f6107d@haskell.org> #9923: Offer copy-on-GC sliced arrays -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | 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 simonmar): The problem occurs if you have both a slice and a reference to the original array. The GC can't know until the end of GC whether it should just copy the slice or keep the whole array, and neither can it copy both the slice and the array (GC would require more memory than the original heap). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 21:35:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 21:35:48 -0000 Subject: [GHC] #9960: Performance problem with TrieMap In-Reply-To: <046.1187d3cef9f049417e374209ab74c339@haskell.org> References: <046.1187d3cef9f049417e374209ab74c339@haskell.org> Message-ID: <061.12a55ef2836dc161650dfb46a447bae9@haskell.org> #9960: Performance problem with TrieMap -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: Phab:D606 -------------------------------------+------------------------------------- Changes (by ezyang): * differential: => Phab:D606 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 22:01:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 22:01:34 -0000 Subject: [GHC] #7485: Tuple constraints not properly kinded In-Reply-To: <047.eeebaeeddbb62123bab9dc0c17cad81f@haskell.org> References: <047.eeebaeeddbb62123bab9dc0c17cad81f@haskell.org> Message-ID: <062.1dbcc76d35d90bffd736507e9ebd9774@haskell.org> #7485: Tuple constraints not properly kinded -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.7 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | ConstraintKinds Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): What was my "original suggestion"? (!) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 22:02:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 22:02:39 -0000 Subject: [GHC] #9923: Offer copy-on-GC sliced arrays In-Reply-To: <045.bfe02837f0b70bc36ccad815cc301a05@haskell.org> References: <045.bfe02837f0b70bc36ccad815cc301a05@haskell.org> Message-ID: <060.804b8d6127632b97b0d9d943e56a8f65@haskell.org> #9923: Offer copy-on-GC sliced arrays -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: Component: Runtime System | 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 dfeuer): Replying to [comment:3 simonmar]: > The problem occurs if you have both a slice and a reference to the original array. The GC can't know until the end of GC whether it should just copy the slice or keep the whole array, and neither can it copy both the slice and the array (GC would require more memory than the original heap). Why is that a problem, per se? The application I was thinking about when I came up with this idea was a function for converting an `Array` to a `Seq`. Currently, there are two ways to do this: 1. You can lazily build a sequence "view" of the array. This is very fast, and only allocates subtrees of the finger tree as they are needed. But the entire underlying array is live until the last leaf of the tree is forced. 2. You can build the sequence monadically, copying each element out of the array (using a nice little function from `Data.Primitive.Array`). This is sure to release the array, at the expense, of course, of actually building the whole sequence (a good bit larger than the array it represents) before using any of it. The copy-on-GC concept would, I believe, offer a middle ground between these options, with performance close to (1) with the leak safety of (2). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 22:18:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 22:18:37 -0000 Subject: [GHC] #9960: Performance problem with TrieMap In-Reply-To: <046.1187d3cef9f049417e374209ab74c339@haskell.org> References: <046.1187d3cef9f049417e374209ab74c339@haskell.org> Message-ID: <061.36354211641ee227655628738b17992e@haskell.org> #9960: Performance problem with TrieMap -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: Phab:D606 -------------------------------------+------------------------------------- Comment (by ezyang): One subtlety: `eqTypeModuloDeBruijn` needs to respect equivalence by `coreView`, because that's how TrieMaps work too. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 22:28:22 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 22:28:22 -0000 Subject: [GHC] #9389: Full Test Suite Failures In-Reply-To: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> References: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> Message-ID: <057.59707509da79947605f5a596e9df3748@haskell.org> #9389: Full Test Suite Failures -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: #9286,#8756,#7876,#7877 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jrp): ... and here with {{{BuildFlavour = perf }}} {{{ OVERALL SUMMARY for test run started at Tue Jan 6 21:42:54 2015 GMT 0:39:46 spent to go through 4389 total tests, which gave rise to 17976 test cases, of which 3602 were skipped 328 had missing libraries 13767 expected passes 139 expected failures 0 caused framework failures 0 unexpected passes 134 unexpected failures 6 unexpected stat failures Unexpected failures: ../../libraries/base/tests enum01 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) ../../libraries/base/tests enum01 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum02 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) ../../libraries/base/tests enum02 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum03 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) ../../libraries/base/tests enum03 [bad stdout or stderr] (ghci) ../../libraries/base/tests topHandler01 [bad exit code] (threaded1,threaded2,profthreaded) ../../libraries/base/tests topHandler01 [bad stdout or stderr] (ghci) ../../libraries/base/tests topHandler03 [bad exit code] (ghci) ../../libraries/hpc/tests/simple/tixs hpc_markup_001 [bad stdout] (normal) ../../libraries/process/tests process011 [bad exit code] (threaded1,threaded2,profthreaded) ../../libraries/process/tests process011 [bad stdout or stderr] (ghci) ../../libraries/unix/tests signals002 [bad stdout] (threaded2,profthreaded) ../../libraries/unix/tests signals002 [bad stdout or stderr] (ghci) ../../libraries/unix/tests signals004 [bad stderr] (threaded2) cabal/sigcabal01 sigcabal01 [bad stderr] (normal) codeGen/should_run CgStaticPointers [bad stdout or stderr] (ghci) concurrent/should_run T5611 [bad stderr] (normal) concurrent/should_run allocLimit4 [bad exit code] (ghci) concurrent/should_run conc012 [bad exit code] (ghci) concurrent/should_run conc059 [bad stderr] (threaded1,threaded2) deSugar/should_run DsStaticPointers [bad stdout or stderr] (ghci) deSugar/should_run dsrun014 [bad exit code] (ghci) driver T9938 [bad exit code] (normal) driver/objc objc-hi [bad profile] (profthreaded) driver/objc objc-hi [bad heap profile] (profasm) driver/objc objcpp-hi [bad profile] (profthreaded) driver/objc objcpp-hi [bad heap profile] (profasm) driver/recomp001 recomp001 [bad stderr] (normal) driver/retc001 retc001 [bad stderr] (normal) ghci/scripts ghci024 [bad stdout] (normal) numeric/should_run add2 [bad exit code] (ghci) numeric/should_run mul2 [bad exit code] (ghci) numeric/should_run quotRem2 [bad exit code] (ghci) parser/should_run readRun004 [bad exit code] (ghci) profiling/should_run T2552 [bad profile] (profasm,profthreaded) profiling/should_run callstack001 [bad stdout] (prof) profiling/should_run ioprof [bad profile] (profasm,profthreaded) profiling/should_run prof-doc-fib [bad profile] (profasm,profthreaded,prof) profiling/should_run scc001 [bad profile] (prof) quasiquotation/qq007 qq007 [exit code non-0] (profasm) quasiquotation/qq008 qq008 [exit code non-0] (profasm) rts GcStaticPointers [bad stdout or stderr] (ghci) rts ListStaticPointers [bad stdout or stderr] (ghci) rts T7919 [bad exit code] (optasm,threaded2,dyn) rts T7919 [exit code non-0] (profasm,profthreaded) rts T9078 [exit code non-0] (profasm) rts derefnull [bad profile] (profasm,profthreaded) rts divbyzero [bad profile] (profasm,profthreaded) rts overflow1 [bad profile] (profasm,profthreaded) rts overflow2 [bad profile] (profasm,profthreaded) rts overflow3 [bad profile] (profasm,profthreaded) simplCore/should_compile T5550 [exit code non-0] (profasm) th TH_StaticPointers [bad stdout or stderr] (ghci) typecheck/should_compile T9939 [stderr mismatch] (normal,hpc,optasm,profasm) typecheck/should_run T3500a [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) typecheck/should_run T3500a [bad stdout or stderr] (ghci) typecheck/should_run T5751 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) typecheck/should_run T5751 [bad stdout or stderr] (ghci) typecheck/should_run T7126 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) typecheck/should_run T7126 [bad stdout or stderr] (ghci) typecheck/should_run T7861 [bad exit code] (normal,hpc,optasm,profasm,ghci,threaded1,threaded2,dyn,profthreaded) typecheck/should_run tcrun045 [stderr mismatch] (normal) Unexpected stat failures: perf/compiler T1969 [stat not good enough] (normal) perf/compiler T5642 [stat not good enough] (normal) perf/compiler T6048 [stat not good enough] (optasm) perf/compiler T783 [stat not good enough] (normal) perf/should_run T9203 [stat too good] (normal) simplCore/should_compile T7702 [stat too good] (profasm) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 22:34:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 22:34:11 -0000 Subject: [GHC] #9389: Full Test Suite Failures In-Reply-To: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> References: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> Message-ID: <057.ee9a764578468945caabb739ca19dd8f@haskell.org> #9389: Full Test Suite Failures -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: #9286,#8756,#7876,#7877 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Very helpful, thank you. It would be great if someone could look through these, case by case, and figure out what is going wrong. Maybe GHC is fine, and the test need adjusting. Maybe there's a bug. Maybe it's a test-harness issue. etc. Open tickets for bugs! Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 22:35:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 22:35:56 -0000 Subject: [GHC] #9961: compile-time performance regression compiling genprimcode In-Reply-To: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> References: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> Message-ID: <057.6a92d052f32d16b45843420eb63c1d1d@haskell.org> #9961: compile-time performance regression compiling genprimcode -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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): great. Do you have the equivalent output with 7.8. (I'm still puzzled why my compilation is fast and yours is slow.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 22:42:42 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 22:42:42 -0000 Subject: [GHC] #9946: Expose the source location of template-haskell Names In-Reply-To: <049.db4709f25d3264deb5da9ff8a9867c2f@haskell.org> References: <049.db4709f25d3264deb5da9ff8a9867c2f@haskell.org> Message-ID: <064.f770cf597ffd838d53ab68e71a272fbe@haskell.org> #9946: Expose the source location of template-haskell Names -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature request | Status: new Priority: low | 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): An example is good, and I encouraged you to start with examples. But ultimately we need a complete specification that says what happens for every `Name`. There are lots of ways to generate a `Name` in TH, and you only give one. How about {{{ f :: Q Exp -> Q Exp f qe = do { Var x <- qe ; print (nameLoc x) ; [| blah |] } }}} For example I might call f with `f [| x |]`, or `f [| \x -> x |]`. Or you can use `newName` or `mkName` to create a `Name`. What locations would they have? Look at `data Name` and `NameFlavour` in `Language.Haskell.TH`. I guess that you ''might'' reasonably expect a location for a `NameG` and perhaps a `NameL`. But it's not clear that `nameLoc :: Name -> Maybe SrcLoc` will be useful to you. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 22:47:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 22:47:09 -0000 Subject: [GHC] #9961: compile-time performance regression compiling genprimcode In-Reply-To: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> References: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> Message-ID: <057.cf1344e68af6ca8500e7cafb4247c536@haskell.org> #9961: compile-time performance regression compiling genprimcode -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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 hvr): Have you tried my exact same steps? Btw, tomorrow I can throw a `prof`-compiled GHC at `Lexer.hs`, if you tell me exactly what kind of output you're interested in... Here's the equivalent output to comment:6 for GHC 7.8.4: {{{ 0.003879 Glasgow Haskell Compiler, Version 7.8.4, stage 2 booted by GHC version 7.6.3 0.003990 Using binary package database: /opt/ghc/7.8.4/lib/ghc-7.8.4/package.conf.d/package.cache 0.013057 Using binary package database: /home/hvr/.ghc/x86_64-linux-7.8.4/package.conf.d/package.cache 0.022682 hiding package shelly-1.5.6 to avoid conflict with later version shelly-1.6.0 0.022748 wired-in package ghc-prim mapped to ghc- prim-0.3.1.0-a24f9c14c632d75b683d0f93283aea37 0.022836 wired-in package integer-gmp mapped to integer- gmp-0.5.1.0-26579559b3647acf4f01d5edd9491a46 0.022874 wired-in package base mapped to base-4.7.0.2-bfd89587617e381ae01b8dd7b6c7f1c1 0.022938 wired-in package rts mapped to builtin_rts 0.022964 wired-in package template-haskell mapped to template- haskell-2.9.0.0-6d27c2b362b15abb1822f2f34b9ae7f9 0.022982 wired-in package dph-seq not found. 0.023020 wired-in package dph-par not found. 0.023869 Created temporary directory: /tmp/ghc12579_0 0.023918 *** C pre-processor: 0.029089 *** Checking old interface for main:Lexer: 0.029165 *** Parser: 0.103668 *** Renamer/typechecker: 0.901522 *** Desugar: 1.507213 Result size of Desugar (after optimization) 1.507273 = {terms: 97,707, types: 6,407, coercions: 4} 1.507283 *** Simplifier: 1.722230 Result size of Simplifier iteration=1 1.722290 = {terms: 92,782, types: 1,457, coercions: 31} 2.014619 Result size of Simplifier iteration=2 2.014680 = {terms: 92,784, types: 1,469, coercions: 40} 2.251739 Result size of Simplifier 2.251799 = {terms: 92,784, types: 1,469, coercions: 40} 2.251808 *** Specialise: 2.308621 Result size of Specialise 2.308682 = {terms: 92,784, types: 1,469, coercions: 40} 2.308692 *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = False}): 2.308699 Result size of Float out(FOS {Lam = Just 0, 2.308715 Consts = True, 2.721925 PAPs = False}) 2.721984 = {terms: 161,685, types: 37,280, coercions: 40} 2.721993 *** Float inwards: 2.806740 Result size of Float inwards 2.806800 = {terms: 161,685, types: 37,280, coercions: 40} 2.806810 *** Simplifier: 4.854193 Result size of Simplifier iteration=1 4.854254 = {terms: 89,091, types: 2,930, coercions: 1,043} 5.037276 Result size of Simplifier iteration=2 5.037336 = {terms: 88,743, types: 2,545, coercions: 770} 5.299382 Result size of Simplifier iteration=3 5.299442 = {terms: 88,739, types: 2,542, coercions: 767} 5.557920 Result size of Simplifier 5.557980 = {terms: 88,739, types: 2,542, coercions: 767} 5.557989 *** Simplifier: 5.828540 Result size of Simplifier iteration=1 5.828599 = {terms: 88,694, types: 32,129, coercions: 767} 6.148168 Result size of Simplifier 6.148227 = {terms: 88,686, types: 32,117, coercions: 767} 6.148237 *** Simplifier: 6.428055 Result size of Simplifier iteration=1 6.428115 = {terms: 88,707, types: 32,132, coercions: 781} 6.708043 Result size of Simplifier iteration=2 6.708103 = {terms: 88,707, types: 32,132, coercions: 767} 6.996411 Result size of Simplifier 6.996470 = {terms: 88,707, types: 32,132, coercions: 767} 6.996480 *** Demand analysis: 7.259522 Result size of Demand analysis 7.259587 = {terms: 88,707, types: 32,132, coercions: 767} 7.259599 *** Worker Wrapper binds: 7.309554 Result size of Worker Wrapper binds 7.309618 = {terms: 88,872, types: 32,381, coercions: 767} 7.309631 *** Simplifier: 7.583439 Result size of Simplifier iteration=1 7.583499 = {terms: 88,820, types: 32,337, coercions: 767} 7.867272 Result size of Simplifier iteration=2 7.867333 = {terms: 88,751, types: 32,199, coercions: 767} 8.146394 Result size of Simplifier 8.146453 = {terms: 88,751, types: 32,199, coercions: 767} 8.146462 *** Float out(FOS {Lam = Just 0, Consts = True, PAPs = True}): 8.146469 Result size of Float out(FOS {Lam = Just 0, 8.146486 Consts = True, 8.732691 PAPs = True}) 8.732752 = {terms: 205,891, types: 122,523, coercions: 767} 8.732761 *** Common sub-expression: 9.101395 Result size of Common sub-expression 9.101457 = {terms: 177,032, types: 121,927, coercions: 217} 9.101466 *** Float inwards: 9.207068 Result size of Float inwards 9.207128 = {terms: 177,032, types: 121,927, coercions: 217} 9.207137 *** Simplifier: 9.811384 Result size of Simplifier iteration=1 9.811444 = {terms: 119,608, types: 92,568, coercions: 217} 10.273151 Result size of Simplifier iteration=2 10.273205 = {terms: 119,609, types: 92,567, coercions: 217} 10.829669 Result size of Simplifier 10.829729 = {terms: 119,609, types: 92,567, coercions: 217} 10.829739 *** Tidy Core: 11.177167 Result size of Tidy Core 11.177231 = {terms: 119,673, types: 92,627, coercions: 217} 11.207078 *** CorePrep: 11.549034 Result size of CorePrep 11.549100 = {terms: 119,974, types: 92,991, coercions: 217} 11.549129 *** Stg2Stg: 11.549139 *** CodeOutput: 11.549306 *** New CodeGen: 11.549336 *** CPSZ: 11.549480 *** CPSZ: 11.550487 *** CPSZ: (...almost 30000 lines of uninteresting "*** CPSZ:" removed...) 13.468961 *** CPSZ: 13.469193 *** CPSZ: 13.469423 *** CPSZ: 13.473052 *** Assembler: 13.611920 *** Deleting temp files: 13.612006 Warning: deleting non-existent /tmp/ghc12579_0/ghc12579_3.c 13.612314 *** Deleting temp dirs: }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 23:04:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 23:04:06 -0000 Subject: [GHC] #9961: compile-time performance regression compiling genprimcode In-Reply-To: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> References: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> Message-ID: <057.35cde567650f97d0f6b20210412ef52e@haskell.org> #9961: compile-time performance regression compiling genprimcode -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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 hvr): I just realised I had already build a `prof` GHC earlier, so I just ran it with {{{ $ time ../inplace/bin/ghc-stage2 +RTS -p -RTS -O -fforce-recomp -c Lexer.hs real 6m23.129s user 6m22.575s sys 0m0.723s }}} and attached the resulting attachment:ghc-stage2.prof -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 23:09:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 23:09:32 -0000 Subject: [GHC] #9961: compile-time performance regression compiling genprimcode In-Reply-To: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> References: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> Message-ID: <057.5520085425c63fc3ba229cb80cf23922@haskell.org> #9961: compile-time performance regression compiling genprimcode -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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 simonpj): * cc: scpmw@? (added) Comment: '''Peter''', could you look at this please? `lintAnnots` (whatever that is, but it's yours) is taking more than 80% of GHC's allocation!!! One thought might be to make it flag-enabled. (And not `-dcore-lint`, because we have that on a lot.) But another question is: does it ''have'' to be so expensive? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 23:44:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 23:44:13 -0000 Subject: [GHC] #9960: Performance problem with TrieMap In-Reply-To: <046.1187d3cef9f049417e374209ab74c339@haskell.org> References: <046.1187d3cef9f049417e374209ab74c339@haskell.org> Message-ID: <061.531950f3dbbb24751677cdbaff948272@haskell.org> #9960: Performance problem with TrieMap -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: Phab:D606 -------------------------------------+------------------------------------- Comment (by ezyang): Nice improvement on T9872d {{{ =====> T9872d(normal) 1507 of 4389 [0, 0, 0] cd ./perf/compiler && '/home/hs01/ezyang/ghc-tries-validate/inplace/bin /ghc-stage2' -fforce-recomp -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci-history -c T9872d.hs +RTS -V0 -tT9872d.comp.stats --machine-readable -RTS >T9872d.comp.stderr 2>&1 bytes allocated value is too low: (If this is because you have improved GHC, please update the test so that GHC doesn't regress again) Expected T9872d(normal) bytes allocated: 739189056 +/-5% Lower bound T9872d(normal) bytes allocated: 702229603 Upper bound T9872d(normal) bytes allocated: 776148509 Actual T9872d(normal) bytes allocated: 687562440 Deviation T9872d(normal) bytes allocated: -7.0 % }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 6 23:51:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 06 Jan 2015 23:51:31 -0000 Subject: [GHC] #9872: Runing type functions is too slow In-Reply-To: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> References: <046.39f8cd7bfe0ce27cb6afb75f2059ad40@haskell.org> Message-ID: <061.2270ec815a48b76882a0966e9ea0706f@haskell.org> #9872: Runing type functions is too slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 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 ezyang): See also #9960 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 7 00:36:53 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Jan 2015 00:36:53 -0000 Subject: [GHC] #9946: Expose the source location of template-haskell Names In-Reply-To: <049.db4709f25d3264deb5da9ff8a9867c2f@haskell.org> References: <049.db4709f25d3264deb5da9ff8a9867c2f@haskell.org> Message-ID: <064.c530c67787bde531b7337e9e78e62fdc@haskell.org> #9946: Expose the source location of template-haskell Names -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature request | Status: new Priority: low | 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 gridaphobe): Oh of course, I forgot about binding `Name`s inside the `Q` Monad.. That goes to show how much I actually use TH. I think we can break the `Name`s into three categories: 1. Bound outside of TH (`NameL` and `NameS`): These are probably the easiest to handle, following my example [comment:3 above]. 2. Bound inside TH, uncapturable (`NameU`): This one also seems pretty straightforward since we know precisely where the `Name` was created, the call-site of `newName` (or `qNewName`). At the moment it's not easy to reflect that location to the running TH code, but the upcoming implicit-params call-stacks would work nicely here (I think). We'd change the types of `newName` and `qNewName` to {{{ newName :: ?loc :: CallStack => String -> Q Name qNewName :: (?loc :: CallStack, Quasi m) => String -> m Name }}} I'm not convinced this location would ever actually be //useful//, but it's a sensible answer and I think we can generate it. 3. Bound inside TH, capturable (`NameS` and `NameQ`): The desired behavior here would be to produce the `SrcLoc` corresponding to the definition of whatever `GHC.Name` the `TH.Name` resolves to, but I'm not sure how to do that yet. Somewhere inside GHC (I suspect wherever the splices are compiled and run) this dynamic resolution must be performed already. So //ideally//, we would just hook into that resolution process. This one seems by far the most difficult though. I'd also be open to returning a `Maybe SrcLoc`, which would only be defined in case (1), as that's good enough for my personal use. But it would sure be nicer to always return a sensible `SrcLoc`. EDIT: I just remembered that there's a function `CoreMonad.thNameToGhcName` that might be useful, though it might also attach an `UnhelpfulSrcSpan` to the `GHC.Name`. I'll experiment with it a bit and report back. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 7 03:51:53 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Jan 2015 03:51:53 -0000 Subject: [GHC] #9946: Expose the source location of template-haskell Names In-Reply-To: <049.db4709f25d3264deb5da9ff8a9867c2f@haskell.org> References: <049.db4709f25d3264deb5da9ff8a9867c2f@haskell.org> Message-ID: <064.5d8a1246dd4715135bfa3f6899d72326@haskell.org> #9946: Expose the source location of template-haskell Names -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature request | Status: new Priority: low | 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 gridaphobe): There is, unfortunately, a subcase in (1) that I forgot above, namely wired-in `Name`s. We can't ever hope to produce a useful `SrcLoc` from `nameSrcLoc '[]`. This alone is a pretty strong argument to return a `Maybe SrcLoc`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 7 04:59:36 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Jan 2015 04:59:36 -0000 Subject: [GHC] #9858: Typeable instance for datatype and its promoted constructor is the same In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.b1e8823d0533a6d1efb8f468cc9f6c70@haskell.org> #9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel 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: -------------------------------------+------------------------------------- Changes (by crockeea): * cc: ecrockett0@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 7 05:00:37 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Jan 2015 05:00:37 -0000 Subject: [GHC] #9111: base should export Typeable instances of its promoted data constructors In-Reply-To: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> References: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> Message-ID: <062.779989f40d34818226e04039df07d969@haskell.org> #9111: base should export Typeable instances of its promoted data constructors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | libraries/base/tests/T9111 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by crockeea): Is this going to make 7.10? I don't see #9111 or #8486 in the [https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-7.10.1 plans for 7.10]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 7 08:26:29 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Jan 2015 08:26:29 -0000 Subject: [GHC] #1851: "make install-strip" should work In-Reply-To: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> References: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> Message-ID: <059.f779d46ee281a369711d4f064068c4a0@haskell.org> #1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.4-rc1 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): * status: closed => new * failure: => None/Unknown * version: 6.8.1 => 7.8.4-rc1 * milestone: 6.8.2 => * owner: igloo => * resolution: fixed => Comment: This is fixed in bindist, but still doesn't work in the source distribution. {{{ # make install-strip ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for `phase_0_builds'. ===--- building phase 1 make -r --no-print-directory -f ghc.mk phase=1 phase_1_builds make[1]: Nothing to be done for `phase_1_builds'. ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final install-strip make[1]: *** No rule to make target `install-strip'. Stop. make: *** [install-strip] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 7 08:29:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Jan 2015 08:29:10 -0000 Subject: [GHC] #1851: "make install-strip" should work In-Reply-To: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> References: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> Message-ID: <059.36c47b45981b28c8577dbd4a6dcfa388@haskell.org> #1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.4-rc1 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 gidyn): * cc: gidyn (added) * failure: None/Unknown => Building GHC failed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 7 10:14:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Jan 2015 10:14:18 -0000 Subject: [GHC] #8326: Place heap checks common in case alternatives before the case In-Reply-To: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> References: <048.ea9ba5e4eb4f979285dd8d72b9c4bf7b@haskell.org> Message-ID: <063.6e49a86dc1e7a1edeb1ee8a4f8108a45@haskell.org> #8326: Place heap checks common in case alternatives before the case -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: 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: #1498 | Blocking: 8317 | Differential Revisions: Phab:D343 -------------------------------------+------------------------------------- Changes (by jstolarek): * owner: jstolarek => Comment: I'm unable to make further progress on this ticket. Sorry. I'm unassigning this ticket - perhaps someone else can take over. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 7 10:16:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Jan 2015 10:16:12 -0000 Subject: [GHC] #8308: Resurrect ticky code for counting constructor arity In-Reply-To: <048.881ed81a50f663ce5516d17888eb822c@haskell.org> References: <048.881ed81a50f663ce5516d17888eb822c@haskell.org> Message-ID: <063.a64fdaa80b36a1a21aa743922b912c97@haskell.org> #8308: Resurrect ticky code for counting constructor arity -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: mlen Type: task | Status: new Priority: normal | Milestone: Component: Profiling | Version: 7.7 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jstolarek): Sounds great. Can you create a Phab revision for your work so that I and other developers can review it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 7 10:39:18 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Jan 2015 10:39:18 -0000 Subject: [GHC] #9963: GHCi panic with --print-libdir flag Message-ID: <048.13b0eeab4e2fcb75c1a05f4a5ea3e375@haskell.org> #9963: GHCi panic with --print-libdir flag -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Driver | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: GHCi crash Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Reported on GHC devs: {{{ $ ghc-stage2 --print-libdir /dane/projekty/ghc/build/inplace/lib $ ghc-stage2 --interactive --print-libdir ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20141222 for x86_64-unknown-linux): ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.9.20141222 for x86_64-unknown-linux): v_unsafeGlobalDynFlags: not initialised Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Does not happen with GHC 7.8.x. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 7 10:41:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Jan 2015 10:41:31 -0000 Subject: [GHC] #9111: base should export Typeable instances of its promoted data constructors In-Reply-To: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> References: <047.f7d0482a575b1fb727f82e2157f5b02d@haskell.org> Message-ID: <062.e7aea3775e39876dbf802f21fe2d9400@haskell.org> #9111: base should export Typeable instances of its promoted data constructors -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.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: | libraries/base/tests/T9111 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * milestone: => 7.10.1 Comment: Replying to [comment:23 crockeea]: > Is this going to make 7.10? Afaics, this landed in GHC HEAD long before GHC 7.10 was frozen, so it's already part of GHC 7.10.1RC; if you're missing some `Typeable` instances, please tell us -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 7 10:43:37 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Jan 2015 10:43:37 -0000 Subject: [GHC] #8486: cannot derive new-typeable instances for promoted data types taking parameters In-Reply-To: <045.96a24a313436daca2fe26743eac0900c@haskell.org> References: <045.96a24a313436daca2fe26743eac0900c@haskell.org> Message-ID: <060.87c463d33ff0cc1c2978088973626229@haskell.org> #8486: cannot derive new-typeable instances for promoted data types taking parameters -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: 5682 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * milestone: => 7.8.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 7 13:55:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Jan 2015 13:55:38 -0000 Subject: [GHC] #9938: GHC's link step needs to be told which packages to link In-Reply-To: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> References: <046.d5e03a3504491fde407beb1d28307afd@haskell.org> Message-ID: <061.05e1080b708d02881b4c89d3df8b5e7c@haskell.org> #9938: GHC's link step needs to be told which packages to link -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"471891cb774a58769018ed5df2120d15bddffd28/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="471891cb774a58769018ed5df2120d15bddffd28" Mark T9938 as expect_broken again It's failing reliable for me (as I think it should) and Edward. See Trac #9938. Reverts commit 633814f5 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 7 16:31:33 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Jan 2015 16:31:33 -0000 Subject: [GHC] #9953: Pattern synonyms don't work with GADTs In-Reply-To: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> References: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> Message-ID: <061.a6ca3af7257a01539197e20a13856675@haskell.org> #9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): In email Gergo showed the following example: {{{ data T1 a where MkT1 :: a -> T1 (Maybe a) -- Inferred type pattern P1 :: (t ~ Maybe a) => a -> T t pattern P1 x <- MkT x -- Inferred type pattern P2 :: a -> [Maybe a] pattern P2 x <- [Just x] }}} When real data constructors are concerned, the types {{{ T1 :: a -> T1 (Maybe a) T1 :: (t ~ Maybe a) => a -> T t }}} are absolutely equivalent. '''But the two types are not equivalent for pattern synonyms.''' * When you match against `P1` can match a value of type `T ty`, for any `ty`; and you get evidence for `t ~ Maybe a`. * But when you match against `P2` you can ''only'' match a value of type `T (Maybe ty)`; and you get no equality evidence. The difference is manifest in the different inferred types for `P1` and `P2`. '''Principle''': you should be able to tell the behaviour of a pattern synonym whose implementation is hidden, just from its type. So the types of `P1` and `P2` are really different. The same principle should apply to explicit, user-supplied type signatures. So if you say {{{ pattern P1 :: a -> T (Maybe a) }}} it should typecheck all right, but you can then only pattern match on values of type `T (Maybe ty)`. In short, if you want GADT-like behaviour for a pattern synonym, you can get it ''only'' by giving explicit equality constraints in the signature, and not by having a complex result type (as you can do for real data constructors). I had missed this point entirely in my earlier comments -- thank you Gergo for pointing it out. Are we agreed on that? Then we can return to the implementation! But I think the user manual deserves a careful look, to make sure that it articulates these points. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 7 17:02:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Jan 2015 17:02:23 -0000 Subject: [GHC] #9953: Pattern synonyms don't work with GADTs In-Reply-To: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> References: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> Message-ID: <061.d993bdaeb0cf909b260a20058a426e03@haskell.org> #9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | PatternSynonyms 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:9 simonpj]: > In short, if you want GADT-like behaviour for a pattern synonym, you can get it ''only'' by giving explicit equality constraints in the signature, and not by having a complex result type (as you can do for real data constructors). Yech. This means that declaring a pattern synonym for a GADT data constructor requires writing the type differently than the idiomatic way to do it for data constructors. I think a second '''principle''' might be this: The type signature for a pattern should mean the same thing that it would for a data constructor. It strikes me that this problem is precisely the same as the required vs. produced distinction. In your `P2`, `t ~ Maybe a` is a requirement; in your `P1`, it's provided. I don't have a better concrete suggestion at the moment, sadly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 7 19:44:40 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Jan 2015 19:44:40 -0000 Subject: [GHC] #9960: Performance problem with TrieMap In-Reply-To: <046.1187d3cef9f049417e374209ab74c339@haskell.org> References: <046.1187d3cef9f049417e374209ab74c339@haskell.org> Message-ID: <061.c96d8c7053cd231595670a95cc3cbae8@haskell.org> #9960: Performance problem with TrieMap -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: Phab:D606 -------------------------------------+------------------------------------- Comment (by ezyang): I had a maybe too clever idea. We need equality over Types, etc; and this equality has to be modulo de Bruijn numbering. In the current proposed design, we bake `CmEnv` into the generic "empty, singleton, many" structure. This isn't great, because what about keys we don't need CmEnv? This got me thinking: maybe we're looking at it wrong: the key in question should be `data ClosedType = ClosedType CmEnv Type`, and we define a TrieMap over *this*. Now, when we define TrieMap instances, we don't have to synthesize an `emptyCME` to pass to the helper functions: we have all the information we need. To make a recursive call, we construct a new `ClosedType` with the updated CME and then call lookup on that. We can even define a plain old `Eq` instance on `ClosedType` respecting de Bruijn indices. `Singleton k v` now automatically stores the `CmEnv`; and we can make some helper functions which default to an `emptyCME`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 7 19:50:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Jan 2015 19:50:21 -0000 Subject: [GHC] #9964: GHC crash with NOINLINE and weird IO stuff Message-ID: <045.9a8dda45bf1bf3aa22c69d27e354c51f@haskell.org> #9964: GHC crash with NOINLINE and weird IO stuff -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs {-# LANGUAGE UnboxedTuples #-} module Crash where import GHC.Base crash :: IO Int crash = IO (\s -> let {-# NOINLINE s' #-} s' = s in (# s', 1::Int #)) }}} This compiles under 7.6.3, but both 7.8.3 and head choke: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): StgCmmEnv: variable not found s{v sLw} [lid] local binds for: Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 7 20:17:49 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Jan 2015 20:17:49 -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.5d41005bd561238f7a70f6574981c326@haskell.org> #9964: GHC crash with NOINLINE and weird IO stuff -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by dfeuer: Old description: > {{{#!hs > {-# LANGUAGE UnboxedTuples #-} > module Crash where > > import GHC.Base > > crash :: IO Int > crash = IO (\s -> > let > {-# NOINLINE s' #-} > s' = s > in (# s', 1::Int #)) > }}} > > This compiles under 7.6.3, but both 7.8.3 and head choke: > > {{{ > ghc: panic! (the 'impossible' happened) > (GHC version 7.8.3 for x86_64-unknown-linux): > StgCmmEnv: variable not found > s{v sLw} [lid] > local binds for: > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > }}} New description: {{{#!hs {-# LANGUAGE UnboxedTuples #-} module Crash where import GHC.Base crash :: IO () crash = IO (\s -> let {-# NOINLINE s' #-} s' = s in (# s', () #)) }}} This compiles under 7.6.3, but both 7.8.3 and head choke: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): StgCmmEnv: variable not found s{v sLw} [lid] local binds for: Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 7 20:47:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Jan 2015 20:47:02 -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.63cd18d6a6bf971754773e1e174b078f@haskell.org> #9964: GHC crash with NOINLINE and weird IO stuff -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dfeuer): Note that the same thing happens with `ST` instead of `IO`, or in fact with a bare function of type `State# a -> (# State# a, () #)`. It is not affected by optimization level. The `NOINLINE` is essential, as is using something that handles a `State#` token?substituting another unboxed type like `Int#` in its place does not cause this problem. Using `undefined` or `s` instead of `s'` in the return value makes the problem go away. Here's the tail end of `-v3 -dverbose-core2core`: {{{ ==================== CorePrep ==================== Result size of CorePrep = {terms: 12, types: 17, coercions: 3} a_rHJ :: GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType, Unf=OtherCon []] a_rHJ = \ (s_sJW [Occ=Once] :: GHC.Prim.State# GHC.Prim.RealWorld) -> case s_sJW of s'_sJX [InlPrag=NOINLINE] { __DEFAULT -> (# s'_sJX, GHC.Tuple.() #) } Crash.crash :: GHC.Types.IO () [GblId, Arity=1, Caf=NoCafRefs, Str=DmdType, Unf=OtherCon []] Crash.crash = (\ (eta_B1 [Occ=Once, OS=OneShot] :: GHC.Prim.State# GHC.Prim.RealWorld) -> a_rHJ eta_B1) `cast` (Sym (GHC.Types.NTCo:IO[0] <()>_R) :: (GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #)) ~# GHC.Types.IO ()) *** Stg2Stg: *** CodeOutput: *** New CodeGen: *** CPSZ: *** CPSZ: *** Deleting temp files: Warning: deleting non-existent /tmp/ghc3661_0/ghc3661_3.c Warning: deleting non-existent /tmp/ghc3661_0/ghc3661_1.s *** Deleting temp dirs: ghc: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-linux): StgCmmEnv: variable not found s{v sJW} [lid] local binds for: Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 7 21:27:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Jan 2015 21:27:44 -0000 Subject: [GHC] #9953: Pattern synonyms don't work with GADTs In-Reply-To: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> References: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> Message-ID: <061.0a05d80551e1b006a0e7c3781e3f6892@haskell.org> #9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): No, it's quite different to the produced/required distinction. The produced/required distinction is for things like matching against `(Just 34)`, which required `(Num a, Eq a)` to perform the match. And my point is that we '''cannot''' say that the type signature for a pattern should mean the same thing that it would for a data constructor; the type signatures for `P1` and `P2` make this clear. It may be sad but it's absolutely ineluctable. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 7 22:24:22 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 07 Jan 2015 22:24:22 -0000 Subject: [GHC] #9960: Performance problem with TrieMap In-Reply-To: <046.1187d3cef9f049417e374209ab74c339@haskell.org> References: <046.1187d3cef9f049417e374209ab74c339@haskell.org> Message-ID: <061.70efa6c9e6ba6755a28c974fe565bc5f@haskell.org> #9960: Performance problem with TrieMap -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: Phab:D606 -------------------------------------+------------------------------------- Comment (by simonpj): I think that's a cool idea. Maybe not `ClosedType` (it really isn't closed). Maybe `DeBruijnType`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 8 00:02:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Jan 2015 00:02:03 -0000 Subject: [GHC] #9965: getChanContents BlockedIndefinitelyOnMVar on 7.10 RC1 Message-ID: <048.6b5c6098010f0774bb9a0a6fd07b5609@haskell.org> #9965: getChanContents BlockedIndefinitelyOnMVar on 7.10 RC1 -------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: | Version: 7.10.1-rc1 libraries/base | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- All of the stanzas work on 7.8.3, but the middle one works incorrectly on 7.10: {{{#!hs module Main where import Control.Concurrent.Chan import Control.Monad main = do io <- newChan let inp = [0] :: [Int] mapM_ (writeChan io) inp {- -- WORKS: outp <- getChanContents io if 0 == head outp then putStrLn "OK" else error $ "Smoke test failed" -} -- BROKEN ON 7.10 (BlockedIndefinitelyOnMVar): outp <- getChanContents io if and (zipWith (==) inp outp) then putStrLn "OK" else error $ "Smoke test failed" {- -- WORKS: forM_ inp $ \xIn-> do xOut <- readChan io unless (xIn == xOut) $ error $ "Smoke test failed" -} }}} I first noticed the behavior in a Chan-like library I wrote, whose internals are completely different from Chan, but where the getChanContents is a copy-paste from Chan. So I assume it has something to do with `unsafeInterleaveIO`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 8 00:45:22 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Jan 2015 00:45:22 -0000 Subject: [GHC] #9960: Performance problem with TrieMap In-Reply-To: <046.1187d3cef9f049417e374209ab74c339@haskell.org> References: <046.1187d3cef9f049417e374209ab74c339@haskell.org> Message-ID: <061.b288718a805e9eac5943683bb2f37d6c@haskell.org> #9960: Performance problem with TrieMap -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: Phab:D606 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"197f4e5aa3443c39e3ec2e53f8e595326ddaa524/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="197f4e5aa3443c39e3ec2e53f8e595326ddaa524" Generalize TrieMap compression to GenMap. I still haven't applied the optimization to anything besides TypeMap. Summary: Signed-off-by: Edward Z. Yang Depends On: D606 Reviewers: simonpj, austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D607 GHC Trac Issues: #9960 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 8 00:45:22 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Jan 2015 00:45:22 -0000 Subject: [GHC] #9960: Performance problem with TrieMap In-Reply-To: <046.1187d3cef9f049417e374209ab74c339@haskell.org> References: <046.1187d3cef9f049417e374209ab74c339@haskell.org> Message-ID: <061.dbc8341015aaac2bc640cc7bd8444b3a@haskell.org> #9960: Performance problem with TrieMap -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: Phab:D606 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"da64ab530512c36acd17c1dbcd3b5fcc681d128b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="da64ab530512c36acd17c1dbcd3b5fcc681d128b" Compress TypeMap TrieMap leaves with singleton constructor. Suppose we have a handful H of entries in a TrieMap, each with a very large key, size K. If you fold over such a TrieMap you'd expect time O(H). That would certainly be true of an association list! But with TrieMap we actually have to navigate down a long singleton structure to get to the elements, so it takes time O(K*H). The point of a TrieMap is that you need to navigate to the point where only one key remains, and then things should be fast. This is a starting point: we can improve the patch by generalizing the singleton constructor so it applies to CoercionMap and CoreMap; I'll do this in a later commit. Summary: Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D606 GHC Trac Issues: #9960 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 8 03:50:41 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Jan 2015 03:50:41 -0000 Subject: [GHC] #9966: Allow switching to different monads in GHCi Message-ID: <049.c31f432824116ee4ae1fbc03fc7aa6ed@haskell.org> #9966: Allow switching to different monads in GHCi -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.11 Component: GHCi | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- GHCi can evaluate individual `IO` actions, e.g. {{{ ghci> writeFile "foo.txt" "bar" ghci> readFile "foo.txt" bar }}} but, as far as I know, this doesn't extend to other monads. Instead you have to compose an entire computation and then run it with the standard eliminators, e.g. {{{ ghci> evalState 0 (put 1 >> get) 1 }}} It would be quite nice if we could tell GHCi to temporarily jump into a different top-level monad, e.g. {{{ -- we start in IO as usual ghci> :monad runState 0 -- now we're in `State Int` with the initial state set to 0 ghci> put 1 -- we can evaluate individual State actions without the ceremony of `runState`, -- and having to track the updated state ourselves between actions ghci> get 1 ghci> :monad IO -- now we're back in IO }}} I'm not sure how feasible this is (it seems tricky), but it would provide a very nice UX for GHCi in the context of larger Haskell applications. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 8 04:58:15 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Jan 2015 04:58:15 -0000 Subject: [GHC] #9966: Allow switching to different monads in GHCi In-Reply-To: <049.c31f432824116ee4ae1fbc03fc7aa6ed@haskell.org> References: <049.c31f432824116ee4ae1fbc03fc7aa6ed@haskell.org> Message-ID: <064.50a9a6b2aad381605baf631af2dbba9e@haskell.org> #9966: Allow switching to different monads in GHCi -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: GHCi | 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 carter): that might be a good Userland patch in https://github.com/chrisdone/ghci- ng or https://hackage.haskell.org/package/ghci-ng -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 8 11:45:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Jan 2015 11:45:06 -0000 Subject: [GHC] #9967: Pattern synonym type signature documentation out of date Message-ID: <047.726f64c50cec4a46c6ffe22f4a27027a@haskell.org> #9967: Pattern synonym type signature documentation out of date -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.10.1-rc1 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Section 7.3.9.3 of the 7.10.1 RC1 user's guide uses the old pattern synonym type syntax for `ExNumPat`. I'd fix it myself, but I'm not 100% sure I'd do it correctly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 8 11:53:13 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Jan 2015 11:53:13 -0000 Subject: [GHC] #9953: Pattern synonyms don't work with GADTs In-Reply-To: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> References: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> Message-ID: <061.440c5a21643b44d536f66a3b2d263db7@haskell.org> #9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Here's the example in play: {{{ data T1 a where MkT1 :: a -> T1 (Maybe a) -- Inferred type pattern P1 :: (t ~ Maybe a) => a -> T t pattern P1 x <- MkT x -- Inferred type pattern P2 :: a -> [Maybe a] pattern P2 x <- [Just x] }}} Couldn't we write these type signatures as {{{ pattern P1 :: (t ~ Maybe a) => () => a -> T t pattern P2 :: () => (t ~ Maybe a) => a -> [t] }}} ? And, I disagree with Simon's conclusion that we cannot have pattern type signatures mean the same as data constructor signatures. We could decide than any non-uniformity in the result type of a pattern signature means a provided equality, just like a GADT. Then, the syntax of the type for `P2` would have to change to something else -- after all, `P2` is not the synonym of any valid data constructor. As we're thinking about this, it strikes me that there is some relationship between the current debate and the distinction between GADTs and data families. For example: {{{ data G a where MkGInt :: G Int data family H a data instance H Int where MkHInt :: H Int }}} `MkGInt` is a GADT constructor that provides an equality when matching. `MkHInt`, on the other hand, '''requires''' the equality when matching. Yet both have the same type signature. So, something a little confusing is going on here. Do pattern synonyms work properly with data families? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 8 12:16:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Jan 2015 12:16:27 -0000 Subject: [GHC] #9953: Pattern synonyms don't work with GADTs In-Reply-To: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> References: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> Message-ID: <061.b3b81ee8654cd0349dd2c0b51e097023@haskell.org> #9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | PatternSynonyms 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 Richard, you are proposing that you can write `P1`'s type signature just like `T1`'s. Fair enough, I can see some merit; indeed it was my initial position. But then you '''must''' write `P2`'s type signature in some other way. What other way do you propose?? Since we already ''have'' two different ways to write the signature, we are at liberty to decide that those two different ways define two different behaviours; and that is what I am proposing. Yes, we could invent a third way, but that introduces a whole new raft of complications. (E.g. can you use that third way in a GADT declaration? For an ordinary function? etc) I'm totally open to considering alternative. But until we have one, let's get on with implementing the proposal we have. That is often illuminating; and if we come up with a better idea meanwhile we can retro- fit it easily enough. For data families, I think it should all work fine. But indeed we should check. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 8 12:17:30 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Jan 2015 12:17:30 -0000 Subject: [GHC] #9967: Pattern synonym type signature documentation out of date In-Reply-To: <047.726f64c50cec4a46c6ffe22f4a27027a@haskell.org> References: <047.726f64c50cec4a46c6ffe22f4a27027a@haskell.org> Message-ID: <062.7df4a9c64a1e511c292d258b9f0cdf1e@haskell.org> #9967: Pattern synonym type signature documentation out of date -------------------------------------+------------------------------------- Reporter: goldfire | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Documentation | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | PatternSynonyms Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * keywords: => PatternSynonyms * owner: => cactus -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 8 14:03:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Jan 2015 14:03:05 -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.0cf296ce21f0cbbc67e5e383ff8274da@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: -------------------------------------+------------------------------------- Changes (by YitzGale): * cc: YitzGale (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 8 17:28:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Jan 2015 17:28:00 -0000 Subject: [GHC] #9966: Allow switching to different monads in GHCi In-Reply-To: <049.c31f432824116ee4ae1fbc03fc7aa6ed@haskell.org> References: <049.c31f432824116ee4ae1fbc03fc7aa6ed@haskell.org> Message-ID: <064.071a78be83574d5005956bdfb673d6ff@haskell.org> #9966: Allow switching to different monads in GHCi -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: GHCi | 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 monoidal): Duplicate of #4316? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 8 18:46:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Jan 2015 18:46:38 -0000 Subject: [GHC] #4316: Interactive "do" notation in GHCi In-Reply-To: <044.bcb097c9c29d1eda57c965914e3510cd@haskell.org> References: <044.bcb097c9c29d1eda57c965914e3510cd@haskell.org> Message-ID: <059.49860b0c56c869990e6249e94f424de7@haskell.org> #4316: Interactive "do" notation in GHCi -------------------------------------+------------------------------------- Reporter: mitar | Owner: Type: feature request | Status: new Priority: low | Milestone: 7.12.1 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: 4459 | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gridaphobe): * cc: gridaphobe, hvr (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 8 18:50:14 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Jan 2015 18:50:14 -0000 Subject: [GHC] #9966: Allow switching to different monads in GHCi In-Reply-To: <049.c31f432824116ee4ae1fbc03fc7aa6ed@haskell.org> References: <049.c31f432824116ee4ae1fbc03fc7aa6ed@haskell.org> Message-ID: <064.40681f5d26c56166a45781467b5709f0@haskell.org> #9966: Allow switching to different monads in GHCi -------------------------------------+------------------------------------- Reporter: gridaphobe | Owner: Type: feature request | Status: closed Priority: low | Milestone: Component: GHCi | Version: 7.11 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #4316 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gridaphobe): * status: new => closed * resolution: => duplicate * related: => #4316 Comment: good points both, i'll close this as a duplicate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 8 19:39:55 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Jan 2015 19:39:55 -0000 Subject: [GHC] #9968: DeriveAnyClass fails on multi-parameter type classes Message-ID: <047.651a00b270696920750ca655201f4d2f@haskell.org> #9968: DeriveAnyClass fails on multi-parameter type classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When I say {{{ {-# LANGUAGE DeriveAnyClass, MultiParamTypeClasses #-} module Bug where class C a b data X deriving (C Int) }}} and load that into GHCi, I see this: {{{ *Main> :load "/Users/rae/temp/DeriveAny.hs" [1 of 1] Compiling Bug ( /Users/rae/temp/DeriveAny.hs, interpreted ) Var/Type length mismatch: [b_a2YW] [] Var/Type length mismatch: [b_a2YW] [] Ok, modules loaded: Bug. *Bug> :info C class C a b -- Defined at /Users/rae/temp/DeriveAny.hs:5:1 instance C X -- Defined at /Users/rae/temp/DeriveAny.hs:7:13 }}} It seems my `Int` parameter to `C` is being dropped. I don't believe I have a debug build in this example, so that debugging output is shipping. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 8 20:55:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Jan 2015 20:55:06 -0000 Subject: [GHC] #5821: SPECIALISE fails with a cryptic warning In-Reply-To: <041.0c42da3432a831cfdfec52f79b870abb@haskell.org> References: <041.0c42da3432a831cfdfec52f79b870abb@haskell.org> Message-ID: <056.3f97218360590e884a007b515cd73584@haskell.org> #5821: SPECIALISE fails with a cryptic warning -------------------------------------+------------------------------------- Reporter: rl | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.5 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 ezyang): * owner: => ezyang * milestone: 7.12.1 => 7.10.1 Comment: I think we can nail this for 7.10. I'll attempt a patch. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 8 21:02:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Jan 2015 21:02:29 -0000 Subject: [GHC] #5821: SPECIALISE fails with a cryptic warning In-Reply-To: <041.0c42da3432a831cfdfec52f79b870abb@haskell.org> References: <041.0c42da3432a831cfdfec52f79b870abb@haskell.org> Message-ID: <056.56221c96f25118bb02f39c880fe576ff@haskell.org> #5821: SPECIALISE fails with a cryptic warning -------------------------------------+------------------------------------- Reporter: rl | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.5 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: -------------------------------------+------------------------------------- Description changed by ezyang: Old description: > Example: > > {{{ > type family T a > type instance T Int = Bool > > foo :: Num a => a -> T a > foo = undefined > > {-# SPECIALISE foo :: Int -> Bool #-} > }}} > > GHC produces this warning: > > {{{ > RULE left-hand side too complicated to desugar > case cobox of _ { GHC.Types.Eq# cobox -> > (foo @ Int $dNum) > `cast` ( -> cobox :: (Int -> T Int) ~# (Int -> Bool)) > } > }}} > > Given that rewrite rules don't reliably work in the presence of type > families, I somewhat suspect that GHC won't be able to generate a > sensible specialisation here but it should produce a better diagnostic. New description: Example: {{{ {-# LANGUAGE TypeFamilies #-} module A where type family T a type instance T Int = Bool foo :: Num a => a -> T a foo = undefined {-# SPECIALISE foo :: Int -> Bool #-} }}} GHC produces this warning: {{{ RULE left-hand side too complicated to desugar case cobox of _ { GHC.Types.Eq# cobox -> (foo @ Int $dNum) `cast` ( -> cobox :: (Int -> T Int) ~# (Int -> Bool)) } }}} Given that rewrite rules don't reliably work in the presence of type families, I somewhat suspect that GHC won't be able to generate a sensible specialisation here but it should produce a better diagnostic. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 8 21:11:04 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Jan 2015 21:11:04 -0000 Subject: [GHC] #9969: panic in T7562 Message-ID: <046.b47a47bfae003dbfaadfc46f5f4c563e@haskell.org> #9969: panic in T7562 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: T7562 | Blocked By: Blocking: | Related Tickets: #7562 Differential Revisions: | -------------------------------------+------------------------------------- Various people observe this test failure: {{{ =====> T7562(normal) 869 of 4389 [0, 0, 0] cd ./typecheck/should_compile && '/home/jojo/build/haskell/ghc- validate/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -fno-warn-tabs -fno-ghci- history -c T7562.hs -fno-warn-incomplete-patterns >T7562.comp.stderr 2>&1 Compile failed (status 256) errors were: T7562.hs:3:14: Warning: UNPACK pragma lacks '!' on the first argument of ?Pair2? In the definition of data constructor ?Pair2? In the data declaration for ?Pair2? ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20150108 for x86_64-unknown-linux): toIfaceBang Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} According to my logs, this was caused by changeset:9564bb8c84cbc0397a414e946cc8c28801f0fbe7/ghc -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 8 21:12:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Jan 2015 21:12:00 -0000 Subject: [GHC] #5821: SPECIALISE fails with a cryptic warning In-Reply-To: <041.0c42da3432a831cfdfec52f79b870abb@haskell.org> References: <041.0c42da3432a831cfdfec52f79b870abb@haskell.org> Message-ID: <056.151eda3ba0b358b3fd9cb65fdabd148e@haskell.org> #5821: SPECIALISE fails with a cryptic warning -------------------------------------+------------------------------------- Reporter: rl | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.5 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: Phab:D610 -------------------------------------+------------------------------------- Changes (by ezyang): * differential: => Phab:D610 Comment: The ideal resolution is to teach the RULE engine how to deal with type families, but until then I've just augmented the error message with a little note. It might even be possible to look at type and realize that type families are involved (and maybe even suggest a better type) but that seems way more involved than just fixing it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 8 21:12:17 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Jan 2015 21:12:17 -0000 Subject: [GHC] #5821: SPECIALISE fails with a cryptic warning In-Reply-To: <041.0c42da3432a831cfdfec52f79b870abb@haskell.org> References: <041.0c42da3432a831cfdfec52f79b870abb@haskell.org> Message-ID: <056.118a26874ecaa6c676beb71562552f63@haskell.org> #5821: SPECIALISE fails with a cryptic warning -------------------------------------+------------------------------------- Reporter: rl | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.5 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: Phab:D610 -------------------------------------+------------------------------------- Changes (by ezyang): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 8 22:06:30 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Jan 2015 22:06:30 -0000 Subject: [GHC] #9960: Performance problem with TrieMap In-Reply-To: <046.1187d3cef9f049417e374209ab74c339@haskell.org> References: <046.1187d3cef9f049417e374209ab74c339@haskell.org> Message-ID: <061.1a0458ebe0e168b7b11b0f49ec1a1e8f@haskell.org> #9960: Performance problem with TrieMap -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: Phab:D606 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"ccef01465366e11978fdad1bf28aeac2edde36c2/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ccef01465366e11978fdad1bf28aeac2edde36c2" Add 'DeBruijn' constructor, which generalizes "key modulo alpha-renaming." Summary: We need equality over Types, etc; and this equality has to be modulo alpha renaming. Previously, we baked CmEnv into the generic "empty, singleton, many" structure. This isn't great, really GenMap should be more generic than that. The insight: we've defined the key wrong: the key should be *equipped* with the alpha-renaming information (CmEnv) and a TrieMap queried with this. This is what the DeBruijn constructor does. Now, when we define TrieMap instances, we don't have to synthesize an emptyCME to pass to the helper functions: we have all the information we need. To make a recursive call, we construct a new DeBruijn with the updated CME and then call lookupTM on that. We can even define a plain old Eq instance on DeBruijn respecting alpha-renaming. There are number of other good knock-on effects. This patch does add a bit of boxing and unboxing, but nothing the optimizer shouldn't be able to eliminate. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D608 GHC Trac Issues: #9960 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 8 22:06:30 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 08 Jan 2015 22:06:30 -0000 Subject: [GHC] #9960: Performance problem with TrieMap In-Reply-To: <046.1187d3cef9f049417e374209ab74c339@haskell.org> References: <046.1187d3cef9f049417e374209ab74c339@haskell.org> Message-ID: <061.09c6ee0c63a7b4cfae619af535da2270@haskell.org> #9960: Performance problem with TrieMap -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: Phab:D606 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"0bef02e49fb2907989127d77ae61ed48ba87ae18/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="0bef02e49fb2907989127d77ae61ed48ba87ae18" Apply GenMap to CoreMap and CoercionMap. Summary: The biggest chore is the Eq (DeBrujin a) instances (all the more a chore because we already have an implementation of them, but a CmEnv is not an RnEnv2), but otherwise a fairly mechanical transformation. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D609 GHC Trac Issues: #9960 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 01:24:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 01:24:00 -0000 Subject: [GHC] #9970: Export more types in GHC.RTS.Flags Message-ID: <050.a5b7a1426f78715d4c9bb9384727144d@haskell.org> #9970: Export more types in GHC.RTS.Flags -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: feature | Milestone: request | Version: 7.10.1-rc1 Priority: normal | Operating System: Unknown/Multiple Component: | Type of failure: Other libraries/base | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- There are some ADTs in {{{GHC.RTS.Flags}}} that have arguments whose types are not exported. These types are: * {{{GiveGCStats}}} (found in {{{GCFlags}}}) * {{{DoCostCentres}}} (found in {{{CCFlags}}}) * {{{DoHeapProfile}}} (found in {{{ProfFlags}}}) * {{{DoTrace}}} (found in {{{TraceFlags}}}) This makes it pretty difficult to do anything useful with them, since they can't be pattern-matched. In addition, there are some unexported type synonyms: * {{{type Time = Word64}}} * {{{type Nat = #{type unsigned int} }}} (likely a {{{Word32}}}) The Haddock docs for {{{GHC.RTS.Flags}}} don't give much of an indication of what {{{Time}}} and {{{Nat}}} are, and since they're already documented in [https://phabricator.haskell.org/diffusion/GHC/browse/master/libraries/base/GHC/RTS/Flags.hsc;0bef02e49fb2907989127d77ae61ed48ba87ae18$50-54 the source], they should probably be exported. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 01:28:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 01:28:59 -0000 Subject: [GHC] #9970: Export more types in GHC.RTS.Flags In-Reply-To: <050.a5b7a1426f78715d4c9bb9384727144d@haskell.org> References: <050.a5b7a1426f78715d4c9bb9384727144d@haskell.org> Message-ID: <065.f021b61a8cec5452fc7486f61cf92fab@haskell.org> #9970: Export more types in GHC.RTS.Flags -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by ezyang): * milestone: => 7.10.1 Comment: Let's try to fix this for 7.10. Can someone contribute a patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 08:46:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 08:46:30 -0000 Subject: [GHC] #9971: GHC 7.10 dies with "out of memory" Message-ID: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> #9971: GHC 7.10 dies with "out of memory" -------------------------------------+------------------------------------- Reporter: albertov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- I'm trying to build my [https://github.com/meteogrid/sigym4-geometry library] with `cabal 1.22` and `ghc-7.10.0.20141222` but it ultimately crashes with `ghc: out of memory (requested 2097152 bytes)`. The VM I've used to build it has 8gb of RAM. The same library compiles fine with `ghc 7.8.3` so I guess it is a GHC bug. Unfortunately I'm not able to reduce it to a simple case or relate it to a previous bug. The build log can be seen at [https://travis- ci.org/meteogrid/sigym4-geometry/builds/46370766 travis-ci] and the source code is freely available so it should be easy to reproduce -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 08:54:40 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 08:54:40 -0000 Subject: [GHC] #9904: ghc: out of memory, requested 1048576 bytes on openbsd In-Reply-To: <045.d32cbdc44e8af12b00d61e76d86031a6@haskell.org> References: <045.d32cbdc44e8af12b00d61e76d86031a6@haskell.org> Message-ID: <060.3214b6e41780006bebd9a5575b170ff3@haskell.org> #9904: ghc: out of memory, requested 1048576 bytes on openbsd -----------------------------+------------------------------------------- Reporter: vu3rdd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: fixed | Keywords: cabal-install Operating System: OpenBSD | Architecture: Unknown/Multiple Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -----------------------------+------------------------------------------- Changes (by vu3rdd): * status: new => closed * resolution: => fixed Comment: OK, I solved the problem by taking cue from what others porting programs to OpenBSD have written. OpenBSD defaults limits listed in /etc/login.conf is pretty conservative. So, I increased the datasize: ... values to infinity. After that cabal installed the 1.22.0.0 just fine. It upgraded from 1.16.0.x to 1.22.0.0. I will also try compiling a newer version of ghc. I am closing the ticket. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 10:07:24 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 10:07:24 -0000 Subject: [GHC] #9969: panic in T7562 In-Reply-To: <046.b47a47bfae003dbfaadfc46f5f4c563e@haskell.org> References: <046.b47a47bfae003dbfaadfc46f5f4c563e@haskell.org> Message-ID: <061.4f431779c283c55dbd1c43cd3ef45cf4@haskell.org> #9969: panic in T7562 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: T7562 Blocked By: | Blocking: Related Tickets: #7562 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"327ce1d336c8fbdb068be900a187f96d1c60b851/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="327ce1d336c8fbdb068be900a187f96d1c60b851" Return a [HsImplBang] from dataConImplBangs even with NoDataConRep This fixes Trac #9969, a new crash in T7562 that I somehow missed when fiddling with HsBang }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 10:09:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 10:09:05 -0000 Subject: [GHC] #9969: panic in T7562 In-Reply-To: <046.b47a47bfae003dbfaadfc46f5f4c563e@haskell.org> References: <046.b47a47bfae003dbfaadfc46f5f4c563e@haskell.org> Message-ID: <061.8d8a590aba053635bc9f10088fc4b187@haskell.org> #9969: panic in T7562 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: T7562 Blocked By: | Blocking: Related Tickets: #7562 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Fixed, apologies. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 10:34:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 10:34:01 -0000 Subject: [GHC] #5129: "evaluate" optimized away In-Reply-To: <043.215a28fb6b8d99f7d854d81f8accbd88@haskell.org> References: <043.215a28fb6b8d99f7d854d81f8accbd88@haskell.org> Message-ID: <058.624060675a9281e9d31cbcf17d2d0c8d@haskell.org> #5129: "evaluate" optimized away -------------------------------------+------------------------------------- Reporter: dons | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: fixed | Keywords: seq, Operating System: Unknown/Multiple | evaluate Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): A later note, in the light of [https://www.haskell.org/pipermail/ghc- devs/2015-January/007900.html this email thread]. Looking at the Haddock documentation for `evaluate`, Roman said: we seem to have three possible implementations for `evaluate`: {{{ 1) evaluate x = return $! x 2) evaluate x = (return $! x) >>= return 3) evaluate x = \s -> seq# x s }}} Now (1) is too strict: `(evaluate (error "urk") True)` should yield `True`. And, contrary to my claim in the email thread, (2) suffers from comment:2 above: inlining can mean that the argument to `evaluate` never gets evaluated. Consider, under (2) {{{ evaluate = \x -> (return $! x) >>= return = \x. \s. case return $! x s of (s1, r) -> return r s1 = \x s. x `seq` case (s,x) of (s1, r) -> return r s1 = \x s. x `seq` (s,x) = \x s. case x of _ -> (s,x) }}} Now consider the call in comment:2: {{{ evalutate poss_err >> assertFailure "foo"` = (inline >>) \s -> case evaluate poss_err of (s1, _) -> assertFailure "foo" s1 = (inline evaluate) \s -> case (case x of _ -> (s,x)) of (s1, _) -> assertFailure "foo" s1 = (case of case) case x of _ -> assertFailure "foo" s1 }}} and now, as explained in comment:2, since `assertFailure` diverges, GHC feel free to discard the case on `x`. Using a primop `seq# :: a -> State# -> (State#, a)` means that the I/O options that follows, which consumes the state that comes out of the `seq#` simply can't start until the `seq#` has executed. And that is what we want for `evaluate`. So only (3) will do. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 10:50:19 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 10:50:19 -0000 Subject: [GHC] #9968: DeriveAnyClass fails on multi-parameter type classes In-Reply-To: <047.651a00b270696920750ca655201f4d2f@haskell.org> References: <047.651a00b270696920750ca655201f4d2f@haskell.org> Message-ID: <062.e81d246c779eb57d8f20cc6d695a7e46@haskell.org> #9968: DeriveAnyClass fails on multi-parameter type classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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: => dreixel * priority: normal => highest Comment: Pedro this looks like your territory. Might you look? It's an outright bug. Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 11:32:54 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 11:32:54 -0000 Subject: [GHC] #9967: Pattern synonym type signature documentation out of date In-Reply-To: <047.726f64c50cec4a46c6ffe22f4a27027a@haskell.org> References: <047.726f64c50cec4a46c6ffe22f4a27027a@haskell.org> Message-ID: <062.7b0a94ebd13f1da404b33b54195dbab0@haskell.org> #9967: Pattern synonym type signature documentation out of date -------------------------------------+------------------------------------- Reporter: goldfire | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Documentation | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | PatternSynonyms Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Dr. ERDI Gergo ): In [changeset:"68a5a784e71b7535aa7d739bf1b003e96267a021/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="68a5a784e71b7535aa7d739bf1b003e96267a021" Update syntax of pattern synonym type signature in documentation (fixes #9967) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 11:32:54 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 11:32:54 -0000 Subject: [GHC] #9900: Support pattern synonyms in GHCi In-Reply-To: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> References: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> Message-ID: <060.6ea18368ff63fd1da6099ae190ff8b52@haskell.org> #9900: Support pattern synonyms in GHCi -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | PatternSynonyms Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: 9915 | Test Case: Related Tickets: #8749, #7253 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Dr. ERDI Gergo ): In [changeset:"6f818e083c8390b0c039bcebb6ec21b336d4173b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="6f818e083c8390b0c039bcebb6ec21b336d4173b" Pattern synonyms do work in GHCi now (see #9900) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 11:33:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 11:33:32 -0000 Subject: [GHC] #9900: Support pattern synonyms in GHCi In-Reply-To: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> References: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> Message-ID: <060.e6bab252e162ee9165b6496189e11dec@haskell.org> #9900: Support pattern synonyms in GHCi -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | PatternSynonyms Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: 9915 | Test Case: Related Tickets: #8749, #7253 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by cactus): Please make sure both of the above two commits are cherry-picked into 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 11:37:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 11:37:21 -0000 Subject: [GHC] #9967: Pattern synonym type signature documentation out of date In-Reply-To: <047.726f64c50cec4a46c6ffe22f4a27027a@haskell.org> References: <047.726f64c50cec4a46c6ffe22f4a27027a@haskell.org> Message-ID: <062.422edf3beddff21e4a1de330b0440614@haskell.org> #9967: Pattern synonym type signature documentation out of date -------------------------------------+------------------------------------- Reporter: goldfire | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: 7.10.1 Component: Documentation | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | PatternSynonyms Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by cactus): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 12:22:42 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 12:22:42 -0000 Subject: [GHC] #3676: realToFrac doesn't sanely convert between floating types In-Reply-To: <046.c71a4f69a48e7e64e18a56e29c643e03@haskell.org> References: <046.c71a4f69a48e7e64e18a56e29c643e03@haskell.org> Message-ID: <061.4d98813722187128ce1cc0b880868c61@haskell.org> #3676: realToFrac doesn't sanely convert between floating types -------------------------------------+------------------------------------- Reporter: draconx | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: ? Component: Core Libraries | Version: 6.12.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: None/Unknown | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by lelf): * cc: me@?, core-libraries-committee@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 12:27:36 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 12:27:36 -0000 Subject: [GHC] #9972: t7861 gives unexpected result (deferred type error) Message-ID: <044.d1ea2174b0e8d9d01e9a33e6a91be2f8@haskell.org> #9972: t7861 gives unexpected result (deferred type error) -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I'm not sure why `validate` does not trip on this, but the test case does not look obviously disabled to me, so I thought I'd just report it so at least it doesn't get unnoticed. GHC 7.8: {{{ "Hello" t7861: t7861.hs:11:5: Couldn't match type ?a? with ?[a]? ?a? is a rigid type variable bound by the type signature for f :: A a -> a at t7861.hs:10:6 Expected type: A a -> a Actual type: A a -> [a] Relevant bindings include f :: A a -> a (bound at t7861.hs:11:1) In the expression: doA In an equation for ?f?: f = doA (deferred type error) }}} On GHC 7.10 the result is (both with and without optimization) {{{ "Hello" "Bad" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 12:36:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 12:36:31 -0000 Subject: [GHC] #9953: Pattern synonyms don't work with GADTs In-Reply-To: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> References: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> Message-ID: <061.aaceae59ad56502776093b5c7c8b8c95@haskell.org> #9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by cactus): I have no idea what the proposal is anymore... which I find a bit worrying, given I am supposed to implement it. Right now, on `master` as of `6f818e08`, this is the behaviour you get: {{{ {-# LANGUAGE GADTs, KindSignatures, PatternSynonyms #-} module ShouldCompile where data X b where Y :: [a] -> X (Maybe a) pattern C1 :: [a] -> X (Maybe a) pattern C1 x <- Y x pattern C2 x <- Y x pattern C3 :: (t ~ Maybe a) => [a] -> X t pattern C3 x <- Y x }}} with this setup, you get {{{ ?? :i C1 pattern C1 :: [a] -> X (Maybe a) -- Defined at T9953-3.hs:8:9 ?? :i C2 pattern C2 :: t ~ Maybe a => [a] -> X t -- Defined at T9953-3.hs:10:9 ?? :i C3 pattern C3 :: t ~ Maybe a => [a] -> X t -- Defined at T9953-3.hs:13:9 }}} Isn't this exactly the behaviour specified by Simon's latest comment? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 12:50:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 12:50:10 -0000 Subject: [GHC] #9953: Pattern synonyms don't work with GADTs In-Reply-To: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> References: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> Message-ID: <061.6ecd462e236a6c8caad46b51cb06c683@haskell.org> #9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Correct. The original ticket description says "Without fixing it, GADT- style pattern signatures are all but useless", and the conclusion of the discussion is that we can't use GADT-style pattern signatures! So yes, all that remains is to review the user manual to ensure that it makes this point explicit. I don't think we need any implementation changes. (Contrary to my initial supposition.) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 12:59:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 12:59:07 -0000 Subject: [GHC] #9972: t7861 gives unexpected result (deferred type error) In-Reply-To: <044.d1ea2174b0e8d9d01e9a33e6a91be2f8@haskell.org> References: <044.d1ea2174b0e8d9d01e9a33e6a91be2f8@haskell.org> Message-ID: <059.d6615711690ea9f903fd5412f3af13fc@haskell.org> #9972: t7861 gives unexpected result (deferred type error) -------------------------------------+------------------------------------- Reporter: luite | 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: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"678df4c2930c4aef61b083edb0f5c4d8c8914a76/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="678df4c2930c4aef61b083edb0f5c4d8c8914a76" Fix up test for T7861 Fixes Trac #9972 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 13:00:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 13:00:03 -0000 Subject: [GHC] #9972: t7861 gives unexpected result (deferred type error) In-Reply-To: <044.d1ea2174b0e8d9d01e9a33e6a91be2f8@haskell.org> References: <044.d1ea2174b0e8d9d01e9a33e6a91be2f8@haskell.org> Message-ID: <059.f3923751f48bd817a5239b4cfa90e0cc@haskell.org> #9972: t7861 gives unexpected result (deferred type error) -------------------------------------+------------------------------------- Reporter: luite | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 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): * status: new => closed * resolution: => fixed Comment: Ah yes, thanks -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 13:11:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 13:11:35 -0000 Subject: [GHC] #5129: "evaluate" optimized away In-Reply-To: <043.215a28fb6b8d99f7d854d81f8accbd88@haskell.org> References: <043.215a28fb6b8d99f7d854d81f8accbd88@haskell.org> Message-ID: <058.479842d8b07295bc8e086fb8564b87e7@haskell.org> #5129: "evaluate" optimized away -------------------------------------+------------------------------------- Reporter: dons | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: fixed | Keywords: seq, Operating System: Unknown/Multiple | evaluate Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Feuerbach): Thanks Simon. I'll try to digest what you've written, and based on my understanding I'll write a better documentation for evaluate that would explain the issue. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 13:16:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 13:16:11 -0000 Subject: [GHC] #9821: DeriveAnyClass support for higher-kinded classes + some more comments In-Reply-To: <046.bafe3d4d92de807a1dcd92a0f60cb2fa@haskell.org> References: <046.bafe3d4d92de807a1dcd92a0f60cb2fa@haskell.org> Message-ID: <061.608a2eb90c7db3bb80f1d11fe6c10684@haskell.org> #9821: DeriveAnyClass support for higher-kinded classes + some more comments -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: 7.10.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: #5462, #9968 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by dreixel): * related: #5462 => #5462, #9968 * milestone: 7.12.1 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 13:16:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 13:16:53 -0000 Subject: [GHC] #9968: DeriveAnyClass fails on multi-parameter type classes In-Reply-To: <047.651a00b270696920750ca655201f4d2f@haskell.org> References: <047.651a00b270696920750ca655201f4d2f@haskell.org> Message-ID: <062.5a7a4f4454af0149ebda9bea169289f7@haskell.org> #9968: DeriveAnyClass fails on multi-parameter type classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9821 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by dreixel): * related: => #9821 Comment: Yes, this is probably related to #9821. I can look into it next week. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 13:45:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 13:45:59 -0000 Subject: [GHC] #9973: Erroneous Redundant constraint warning Message-ID: <044.674169bc1e677ad2fbf8ec9023f2c25c@haskell.org> #9973: Erroneous Redundant constraint warning -------------------------------------+------------------------------------- Reporter: alanz | 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: | -------------------------------------+------------------------------------- Using version 4425ab99d6410839fa7567950b0a4696b0a3d70f with D538 applied, If the attached source file is loaded as is into ghci it generates the following warning for line 5, but otherwise loads fine {{{ /home/alanz/mysrc/github/alanz/HaRe/Bug2.hs:5:18: Warning: Redundant constraint: SYB.Data t In the type signature for: duplicateDecl :: SYB.Data t => [GHC.LHsBind GHC.Name] -> t -> GHC.Name -> GHC.Name -> IO [GHC.LHsBind GHC.Name] }}} If the constraint is commented out, it results in an error {{{ /home/alanz/mysrc/github/alanz/HaRe/Bug2.hs:26:16: No instance for (SYB.Data t) arising from a use of ?definingSigsNames? Possible fix: add (SYB.Data t) to the context of the type signature for: duplicateDecl :: [GHC.LHsBind GHC.Name] -> t -> GHC.Name -> GHC.Name -> IO [GHC.LHsBind GHC.Name] In the expression: definingSigsNames [n] sigs In an equation for ?typeSig?: typeSig = definingSigsNames [n] sigs In an equation for ?duplicateDecl?: duplicateDecl decls sigs n newFunName = do { let sspan = ...; newSpan <- case typeSig of { [] -> return sspan _ -> ... }; let rowOffset = ...; .... } where typeSig = definingSigsNames [n] sigs Failed, modules loaded: none. }}} This behaviour goes away if the following lines are commented out {{{#!hs let rowOffset = case typeSig of [] -> 2 _ -> 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 14:20:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 14:20:02 -0000 Subject: [GHC] #9934: Typo in GHC.RTS.Flags In-Reply-To: <050.0ec040db1f00688d5b940ce1d03caaea@haskell.org> References: <050.0ec040db1f00688d5b940ce1d03caaea@haskell.org> Message-ID: <065.3d3b6a5d3f5b379bee944e862cd9bd5d@haskell.org> #9934: Typo in GHC.RTS.Flags -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: libraries/base | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #5364 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * status: merge => closed * resolution: => fixed Comment: merged with 224a48ebc1e4f6fb373884a6ae1de81b11a3f383 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 14:28:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 14:28:39 -0000 Subject: [GHC] #9967: Pattern synonym type signature documentation out of date In-Reply-To: <047.726f64c50cec4a46c6ffe22f4a27027a@haskell.org> References: <047.726f64c50cec4a46c6ffe22f4a27027a@haskell.org> Message-ID: <062.5974ac9b93a4e2386065d80afc8413e6@haskell.org> #9967: Pattern synonym type signature documentation out of date -------------------------------------+------------------------------------- Reporter: goldfire | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Documentation | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | PatternSynonyms Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * status: merge => closed * resolution: => fixed Comment: merged with 44815ddbf4f682067c50704dd8920b0e56d8238c -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 14:31:18 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 14:31:18 -0000 Subject: [GHC] #9875: ld -l:filename.dylib does not appear to be portable In-Reply-To: <045.5761a7e104bd5de24e048bce5dd70a34@haskell.org> References: <045.5761a7e104bd5de24e048bce5dd70a34@haskell.org> Message-ID: <060.332bdbd616344ed79df3065a2803324c@haskell.org> #9875: ld -l:filename.dylib does not appear to be portable -------------------------------+------------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: Unknown/Multiple Type of failure: GHCi crash | Test Case: T2276_ghci Blocked By: | Blocking: 9845 Related Tickets: | Differential Revisions: Phab:D579 -------------------------------+------------------------------------------- Changes (by hvr): * status: merge => closed * resolution: => fixed Comment: merged with ee20cbf547e8d7651f94ce7516f088dabc872a3e -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 15:22:52 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 15:22:52 -0000 Subject: [GHC] #9900: Support pattern synonyms in GHCi In-Reply-To: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> References: <045.62d6509e4b0cfc58e8f6254c0f951369@haskell.org> Message-ID: <060.7fe48afac4cfba68ce756a3fea18bd28@haskell.org> #9900: Support pattern synonyms in GHCi -------------------------------------+------------------------------------- Reporter: cactus | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: GHCi | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | PatternSynonyms Type of failure: GHC rejects | Architecture: valid program | Unknown/Multiple Blocked By: 9915 | Test Case: Related Tickets: #8749, #7253 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * status: merge => closed * resolution: => fixed Comment: merged with 1f59f9a218d85ca1e8a13b3fdf6f4ed0d6fcb7e7 and 14c198b41ded6a172a52ec02a39f0933f6676f47 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 15:47:03 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 15:47:03 -0000 Subject: [GHC] #9889: Pattern synonym does not work in top-level pattern bind In-Reply-To: <047.fe6568ce87d5703b3811c455881d3231@haskell.org> References: <047.fe6568ce87d5703b3811c455881d3231@haskell.org> Message-ID: <062.1cfba3c22b5d51ed000f8c3259f4b029@haskell.org> #9889: Pattern synonym does not work in top-level pattern bind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: cactus Type: bug | Status: patch Priority: normal | Milestone: Component: Compiler (Type | Version: 7.9 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"5830fc449af6b2c0ef5be409fd3457114ae938ca/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="5830fc449af6b2c0ef5be409fd3457114ae938ca" Pattern synonym names need to be in scope before renaming bindings (#9889) I did a bit of refactoring at the same time, needless to say }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 16:43:56 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 16:43:56 -0000 Subject: [GHC] #9973: Erroneous Redundant constraint warning In-Reply-To: <044.674169bc1e677ad2fbf8ec9023f2c25c@haskell.org> References: <044.674169bc1e677ad2fbf8ec9023f2c25c@haskell.org> Message-ID: <059.abd1c11cd42d65d3baf882f474c629e2@haskell.org> #9973: Erroneous Redundant constraint warning -------------------------------------+------------------------------------- Reporter: alanz | 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: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"dd3e1dd7f8d81e2585a7d63c06c1a1501810fcaa/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="dd3e1dd7f8d81e2585a7d63c06c1a1501810fcaa" Fix Trac #9973 (buglet in -fwarn-redundant-constraints) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 17:11:19 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 17:11:19 -0000 Subject: [GHC] #9973: Erroneous Redundant constraint warning In-Reply-To: <044.674169bc1e677ad2fbf8ec9023f2c25c@haskell.org> References: <044.674169bc1e677ad2fbf8ec9023f2c25c@haskell.org> Message-ID: <059.8ce33cecf7d8fd80c11134f2b1756433@haskell.org> #9973: Erroneous Redundant constraint warning -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | 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: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Excellent! Thank you for finding this. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 18:57:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 18:57:59 -0000 Subject: [GHC] #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code In-Reply-To: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> References: <046.9a4e1bc549a42d7dea911589e68836d0@haskell.org> Message-ID: <061.3526a94aa64ddb71c6fc78a1af8d95f5@haskell.org> #9439: LlvmCodegen: Overzealous mangler incorrectly transforms user code -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.8.4 Component: Compiler (LLVM) | 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: 9268 | Differential Revisions: Phab:D150 -------------------------------------+------------------------------------- Changes (by rwbarton): * status: closed => merge Comment: As reported by someone on #ghc, the actual fix 5895f2b8ffba72a8393e9f712461e6e5ed7ceced was never merged, only the subsequent bbd031134a571c1020945b2548e3fc4795b5047a. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 19:14:40 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 19:14:40 -0000 Subject: [GHC] #9974: Allow more general structural recursion without UndecidableInstances Message-ID: <045.b388614289e2dfd61f708eef2be07eb0@haskell.org> #9974: Allow more general structural recursion without UndecidableInstances -------------------------------------+------------------------------------- Reporter: dfeuer | 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: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I bet this is a duplicate, but I couldn't find it. A simple example from the `HList` package: {{{#!hs type family HRevApp (l1 :: [k]) (l2 :: [k]) :: [k] type instance HRevApp '[] l = l type instance HRevApp (e ': l) l' = HRevApp l (e ': l') }}} GHC 7.8.3 and 7.11 both complain about the second instance if `UndecidableInstances` is turned off, because the application is no smaller than the index head. Moreover, the same error occurs when the type family is closed. However, GHC already knows how to separate term-level definitions into recursive groups; applying this same analysis to the type family above would reveal that `HRevApp` is structurally recursive, and therefore decidable. It is key, in this case, that the instance for `[]` is visible from the instance declaration for `e ': l`, so such an analysis could only be done in module dependency order for open type families. Side note: there is a (nasty) workaround available for the problem in this case: {{{#!hs type family HRevApp' (l1 :: [k]) (l1' :: [k]) (l2 :: [k]) :: [k] type instance HRevApp' t '[] l = l type instance HRevApp' (e ': l) (e' ': l') l'' = HRevApp' l l' (e ': l'') type HRevApp l1 l2 = HRevApp' l1 l1 l2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 20:10:48 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 20:10:48 -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.a1838712d0740341d4b1aa1de59b4dc9@haskell.org> #9964: GHC crash with NOINLINE and weird IO stuff -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: => 7.10.1 Comment: rwbarton suggests setting a 7.10.1 milestone for this. Obviously if the problem turns out to be a deep one we can push it back. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 21:31:12 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 21:31:12 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.44b699f6a48df7eb0fc1d746aa3203b5@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | TypeFamilies, Injective Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #4259 | Test Case: | Blocking: | Differential Revisions: Phab:D202 -------------------------------------+------------------------------------- Comment (by jberryman): I'm very late to the discussion, so this is probably not helpful at all, but I wanted to mention my interest. I've only had use for better type inference with (conceptually) closed, recursive type families. What I think I want is something like proposal C from the wiki, or the head- injectivity proposal where "possibly-partial information about the result might allow us to deduce possibly-partial information about the arguments." And as a naive user I want injectivity to be inferred for closed type families, and don't find the arguments against it in the wiki convincing. Intuitively there doesn't seem to be much difference between the level of logic required to infer things about types with closed type synonym families, vs the sort of inference the typechecker does elsewhere (again, as a naive user who doesn't care about the trickiness of implementing such a scheme). My impression is that this is what many people assumed would be the point of closed type families; for what I've had in mind closed type families make only a cosmetic improvement. Anyway most of my interest came from my work on https://github.com/jberryman/shapely-data which embarrassingly seems to dependent quite a lot on #1241, so it (and below) needs GHC 7.6. You can ignore the example that follows or consider it if it's helpful: {{{#!hs {-# LANGUAGE TypeOperators #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE UndecidableInstances #-} -- for nested Type family: Reversed (Tail t) :> Head t {-# LANGUAGE FunctionalDependencies #-} -- | A class for the exponent laws with the 'Normal' form @abc@ in the exponent -- place. See the instance documentation for concrete types and examples. class Exponent abc where fanin :: (abc :=>-> x) -> (abc -> x) unfanin :: (abc -> x) -> (abc :=>-> x) -- | The algebraic normal form 'Exponent' @abc@ distributed over the single -- base variable @x at . type family abc :=>-> x -- | x? = x type instance () :=>-> x = x -- | x???? = (x?)? type instance (a,bs) :=>-> x = a -> bs :=>-> x instance Exponent () where fanin = const unfanin f = f () instance (Exponent bs)=> Exponent (a,bs) where fanin f = uncurry (fanin . f) unfanin f = unfanin . curry f class Homogeneous a as | as -> a where -- An n-ary @codiag at . genericRepeat :: a -> as instance Homogeneous a () where genericRepeat _ = () instance (Homogeneous a as)=> Homogeneous a (a,as) where genericRepeat a = (a,genericRepeat a) }}} So the following two type-check fine: {{{#!hs a = (3 ==) $ (\(x,(y,(z,())))-> x+y+z) $ genericRepeat 1 b = (3 ==) $ fanin (\x y z-> x+y+z) (genericRepeat 1 :: (Int,(Int,(Int,())))) }}} But this doesn't: {{{#!hs c = (3 ==) $ fanin (\x y z-> x+y+z) $ genericRepeat 1 }}} ...failing with {{{ Couldn't match expected type `a1 -> a1 -> a1 -> a1' with actual type `abc0 :=>-> a0' The type variables `a0', `abc0', `a1' are ambiguous Possible fix: add a type signature that fixes these type variable(s) The lambda expression `\ x y z -> x + y + z' has three arguments, but its type `abc0 :=>-> a0' has none In the first argument of `fanin', namely `(\ x y z -> x + y + z)' In the expression: fanin (\ x y z -> x + y + z) }}} That library is probably going in the garbage bin at this point, but in general this is the sort of thing I think I'd like to be able to do with type families eventually. And I haven't gotten to dig into y'all's singletons work yet, so it might be that that's the sort of thing I'm looking for and my use of type families and classes in shapely-data is ill-considered. Thanks for your work on this! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 21:38:41 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 21:38:41 -0000 Subject: [GHC] #8634: Relax functional dependency coherence check ("liberal coverage condition") In-Reply-To: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> References: <046.6a92b0362e063a98cb21cd9875fc18ba@haskell.org> Message-ID: <061.50f58735124fa55e55259dd7b493c13e@haskell.org> #8634: Relax functional dependency coherence check ("liberal coverage condition") -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: feature request | 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: #1241, #2247, | Blocking: #8356, #9103, #9227 | Differential Revisions: Phab:D69 -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: 7.10.1 => 7.12.1 Comment: This is fairly obviously not going to happen in a feature freeze. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 21:41:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 21:41:27 -0000 Subject: [GHC] #8440: Get rid of the remaining static flags In-Reply-To: <052.744af3e10192bedb98c0b515d9a6cc6d@haskell.org> References: <052.744af3e10192bedb98c0b515d9a6cc6d@haskell.org> Message-ID: <067.3b18daf2c390324e2178f1614cd8a8a7@haskell.org> #8440: Get rid of the remaining static flags -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: Type: task | Status: new Priority: high | Milestone: 7.12.1 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 dfeuer): * milestone: 7.10.1 => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 21:44:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 21:44:01 -0000 Subject: [GHC] #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page In-Reply-To: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> References: <052.69f389ede5e82026cc5c1d8ff164657e@haskell.org> Message-ID: <067.9ac44f996d4b6012abf85850af8b0ff1@haskell.org> #9314: Each object file in a static archive file (.a) is loaded into its own mmap()ed page -------------------------------------+------------------------------------- Reporter: kazu-yamamoto | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by dfeuer): * milestone: 7.10.1 => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 22:36:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 22:36:26 -0000 Subject: [GHC] #9960: Performance problem with TrieMap In-Reply-To: <046.1187d3cef9f049417e374209ab74c339@haskell.org> References: <046.1187d3cef9f049417e374209ab74c339@haskell.org> Message-ID: <061.28f94133e7f35d0443a064f9a7159254@haskell.org> #9960: Performance problem with TrieMap -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: Phab:D606 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"c4e1ccb2fe6ca7a3100653aadd83f83722669e79/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c4e1ccb2fe6ca7a3100653aadd83f83722669e79" Miscellaneous improvements to TrieMap, from D608 code review. Summary: - Add SPECIALIZE pragmas for the lkG/xtG/mapG/fdG family of functions - Rename wrapEmptyXX to just emptyXX - New deBruijnize function for initializing DeBruijn elements - Some extra documentation Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D611 GHC Trac Issues: #9960 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 9 22:36:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 09 Jan 2015 22:36:26 -0000 Subject: [GHC] #9960: Performance problem with TrieMap In-Reply-To: <046.1187d3cef9f049417e374209ab74c339@haskell.org> References: <046.1187d3cef9f049417e374209ab74c339@haskell.org> Message-ID: <061.0632ff0d777b34b6ec2ec35c8a03bee8@haskell.org> #9960: Performance problem with TrieMap -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: Phab:D606 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"944329accebc86cc5ec989cd6b3c267d32fb6f26/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="944329accebc86cc5ec989cd6b3c267d32fb6f26" Newtype CoreMap and TypeMap so their keys are user-friendly. Summary: Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D612 GHC Trac Issues: #9960 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 10 05:32:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Jan 2015 05:32:45 -0000 Subject: [GHC] #9889: Pattern synonym does not work in top-level pattern bind In-Reply-To: <047.fe6568ce87d5703b3811c455881d3231@haskell.org> References: <047.fe6568ce87d5703b3811c455881d3231@haskell.org> Message-ID: <062.edbcc6fd9273fe056dd4aa903754f255@haskell.org> #9889: Pattern synonym does not work in top-level pattern bind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.9 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by cactus): * status: patch => merge * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 10 10:45:20 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Jan 2015 10:45:20 -0000 Subject: [GHC] #6018: Injective type families In-Reply-To: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> References: <046.462d73259c074dd38ac6b92850bd9f5c@haskell.org> Message-ID: <061.712f1c0f70088ed905114e7b329c7c8a@haskell.org> #6018: Injective type families -------------------------------------+------------------------------------- Reporter: lunaris | Owner: jstolarek Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Unknown/Multiple | TypeFamilies, Injective Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #4259 | Test Case: | Blocking: | Differential Revisions: Phab:D202 -------------------------------------+------------------------------------- Comment (by jstolarek): Replying to [comment:103 jberryman]: > I've only had use for better type inference with (conceptually) closed, recursive type families Calling type families from an injective type family will not be allowed (including recursion). The reason is that I don't see a way of verifying injectivity when type families are involved. > What I think I want is something like proposal C from the wiki At the moment I am implementing proposals A and B. C is something to think about in the future, as it is not trivial. > And as a naive user I want injectivity to be inferred for closed type families, and don't find the arguments against it in the wiki convincing. Yes, I suppose that focus of the wiki discussion is a bit off. I think we could infer injectivity of type A for closed type families. But I don't think we should try to infer injectivity of type B because the algorithm is exponential - see [comment:64 comment 64]. That's the major reason for doing this. (Numbers in that comment were computed for type C injectivity, but type B is also exponential.) {{{#!hs -- | The algebraic normal form 'Exponent' @abc@ distributed over the single -- base variable @x at . type family abc :=>-> x -- | x? = x type instance () :=>-> x = x -- | x???? = (x?)? type instance (a,bs) :=>-> x = a -> bs :=>-> x }}} I don't think `:=>->` type family is injective: both `() :=>-> (Int -> Int)` and `(Int,()) :=>-> Int` reduce to `Int -> Int`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 10 10:53:00 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 10 Jan 2015 10:53:00 -0000 Subject: [GHC] #9961: compile-time performance regression compiling genprimcode In-Reply-To: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> References: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> Message-ID: <057.c790a4e26de96e31c2e92e5a23a5ec40@haskell.org> #9961: compile-time performance regression compiling genprimcode -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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 scpmw): Sorry for late reaction, somehow missed the mail. `lintAnnots` should only do something with `-dannot-lint` enabled. It will then be *very* expensive, because it runs every Core pass twice, and diff'ing Core can be almost arbitrarily costly. That being said, without `-dannot-lint` we should really have `lintAnnots pname pass guts = pass guts`. Not quite sure though how we get that much individual allocation on it, I'll investigate. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 11 09:07:12 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Jan 2015 09:07:12 -0000 Subject: [GHC] #9975: RecordWildCards and PatternSynonyms cause impossible bug Message-ID: <049.b13d47e06dcb55d0cee4cf36751dfd3f@haskell.org> #9975: RecordWildCards and PatternSynonyms cause impossible bug -------------------------------------+------------------------------------- Reporter: gamegoblin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: MacOS X RecordWildCards PatternSynonyms | Type of failure: Compile-time Architecture: x86_64 | crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When using RecordWildCards with PatternSynonyms, I have found a way to cause this bug: $ /usr/local/bin/ghc-7.10.0.20141222 test.hs [1 of 1] Compiling Main ( test.hs, test.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20141222 for x86_64-apple-darwin): find_tycon Test [Test defined at test.hs:6:9, Test parent:Test defined at test.hs:4:13] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Here is the full code that causes it: {{{#!hs {-# LANGUAGE RecordWildCards #-} {-# LANGUAGE PatternSynonyms #-} data Test = Test { x :: Int } pattern Test wat = Test { x = wat } }}} If you remove RecordWildCards, the bug does not happen. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 11 11:26:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Jan 2015 11:26:29 -0000 Subject: [GHC] #9975: RecordWildCards and PatternSynonyms cause impossible bug In-Reply-To: <049.b13d47e06dcb55d0cee4cf36751dfd3f@haskell.org> References: <049.b13d47e06dcb55d0cee4cf36751dfd3f@haskell.org> Message-ID: <064.8fda6dd58cb54baa39c8ae73d343865a@haskell.org> #9975: RecordWildCards and PatternSynonyms cause impossible bug -------------------------------------+------------------------------------- Reporter: gamegoblin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: MacOS X | RecordWildCards PatternSynonyms Type of failure: Compile-time | Architecture: x86_64 crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gamegoblin): * version: 7.8.4 => 7.10.1-rc1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 11 13:39:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Jan 2015 13:39:17 -0000 Subject: [GHC] #8082: Ordering of assembly blocks affects performance In-Reply-To: <048.a1c9fecabf21ad13e9b6872825272ba6@haskell.org> References: <048.a1c9fecabf21ad13e9b6872825272ba6@haskell.org> Message-ID: <063.8e89f3c3a90e3fa870986b57ef467687@haskell.org> #8082: Ordering of assembly blocks affects performance -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (NCG) | Version: 7.6.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: None/Unknown | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gidyn, simonmar (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 11 13:39:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Jan 2015 13:39:56 -0000 Subject: [GHC] #8279: bad alignment in code gen yields substantial perf issue In-Reply-To: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> References: <045.3fa2c6fed8a76bf664b09b6a4e78beae@haskell.org> Message-ID: <060.8a2f0f396587fcc9983bc4328c9813a5@haskell.org> #8279: bad alignment in code gen yields substantial perf issue -------------------------------------+------------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.7 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #8082 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * cc: gideon@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 11 13:54:49 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Jan 2015 13:54:49 -0000 Subject: [GHC] #9976: Ignore newlines in code diffs on Phab Message-ID: <047.8a70901b5a5669f0afb215416c9a9006@haskell.org> #9976: Ignore newlines in code diffs on Phab -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.8.4 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: | -------------------------------------+------------------------------------- Doing code reviews in Phab is great. However, the way that the lint feature works encourages patchers to split lines as they means that more attention is drawn to split lines than perhaps should be. As a concrete example, I'm reading Phab:D538 this morning, and looking at line 402 of !DsArrows. Alan has added a new field to a data structure and needed to insert a `_` to make the code remain well typed... but this forced a line split to avoid a lint error. Now, I have to check if there are any changes in the second half of the line manually, because the character-diff highlighting fails after the line split. Is there a way to improve this behavior? I can think of two approaches: * (Better option) Teach the character-diff highlighting feature to look across linebreaks. * (Worse option) Encourage patchers ''not'' to make new line breaks until their final commit. Suppress lint problems about line breaks by request. This is, of course, minor, but it would certainly be nice! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 11 18:46:17 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Jan 2015 18:46:17 -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.98e95b15a74cfb63c5c7df6c2be59f08@haskell.org> #9958: System.IO.Error: Fix a documentation link to Control.Exception.Exception -------------------------------------+------------------------------------- Reporter: mineo | Owner: Type: bug | Status: patch Priority: normal | Milestone: Component: libraries/base | 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 mineo): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 11 21:08:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Jan 2015 21:08:19 -0000 Subject: [GHC] #9975: RecordWildcards and PatternSynonyms cause impossible bug (was: RecordWildCards and PatternSynonyms cause impossible bug) In-Reply-To: <049.b13d47e06dcb55d0cee4cf36751dfd3f@haskell.org> References: <049.b13d47e06dcb55d0cee4cf36751dfd3f@haskell.org> Message-ID: <064.62bfd3e553b7b0e761ad291b6a81739e@haskell.org> #9975: RecordWildcards and PatternSynonyms cause impossible bug -------------------------------------+------------------------------------- Reporter: gamegoblin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: MacOS X | RecordWildcards PatternSynonyms Type of failure: Compile-time | Architecture: x86_64 crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gamegoblin): * keywords: RecordWildCards PatternSynonyms => RecordWildcards PatternSynonyms Old description: > When using RecordWildCards with PatternSynonyms, I have found a way to > cause this bug: > > $ /usr/local/bin/ghc-7.10.0.20141222 test.hs > [1 of 1] Compiling Main ( test.hs, test.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 7.10.0.20141222 for x86_64-apple-darwin): > find_tycon > Test > [Test defined at test.hs:6:9, > Test parent:Test defined at test.hs:4:13] > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > Here is the full code that causes it: > > {{{#!hs > {-# LANGUAGE RecordWildCards #-} > {-# LANGUAGE PatternSynonyms #-} > data Test = Test { x :: Int } > pattern Test wat = Test { x = wat } > }}} > > If you remove RecordWildCards, the bug does not happen. New description: When using RecordWildcards with PatternSynonyms, I have found a way to cause this bug: $ /usr/local/bin/ghc-7.10.0.20141222 test.hs [1 of 1] Compiling Main ( test.hs, test.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20141222 for x86_64-apple-darwin): find_tycon Test [Test defined at test.hs:6:9, Test parent:Test defined at test.hs:4:13] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Here is the full code that causes it: {{{#!hs {-# LANGUAGE RecordWildCards #-} {-# LANGUAGE PatternSynonyms #-} data Test = Test { x :: Int } pattern Test wat = Test { x = wat } }}} If you remove RecordWildCards, the bug does not happen. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 11 23:17:19 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 11 Jan 2015 23:17:19 -0000 Subject: [GHC] #9961: compile-time performance regression compiling genprimcode In-Reply-To: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> References: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> Message-ID: <057.d1c9cc9446cd578eb375bd6787df8eb6@haskell.org> #9961: compile-time performance regression compiling genprimcode -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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 scpmw): `lintAnnots` is definitely not the villain here: It doesn't change performance if I simply short-cut it out. All cost then lands in `Core2Core`. Reason is that `FloatOut` floats out the bodies of `doCorePass` past the cost-centre annotations. This is because the bodies are partially applied functions (so `exprIsHNF` is set), which makes floating treat it like a constructor application. I'm pretty sure that's wrong, and ezyang's tick semantics seem to agree. At this point I'm still trying to understand how this got introduced (most likely my fault in some way). If my diagnosis is right, we'll probably need a new version of `exprIsHNF` or `mkTick`. In any case, while this definitely needs to be fixed, it's not the cause for this slow-down. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 12 09:09:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Jan 2015 09:09:41 -0000 Subject: [GHC] #7398: RULES don't apply to a newtype constructor In-Reply-To: <046.1bb2e495c45c32508f69b7364d934e7b@haskell.org> References: <046.1bb2e495c45c32508f69b7364d934e7b@haskell.org> Message-ID: <061.f1fcd71bf998adef27b55bea3dce3dfc@haskell.org> #7398: RULES don't apply to a newtype constructor -------------------------------------+------------------------------------- Reporter: shachaf | Owner: 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: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #6082 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by liyang): * cc: ghc.haskell.org@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 12 10:06:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Jan 2015 10:06:30 -0000 Subject: [GHC] #9386: GHCi cannot load .so in ./ In-Reply-To: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> References: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> Message-ID: <062.2bdafabb2b3819aee79652e73bcefc7b@haskell.org> #9386: GHCi cannot load .so in ./ -------------------------------------+------------------------------------- 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: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D593 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: => Phab:D593 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 12 10:35:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Jan 2015 10:35:15 -0000 Subject: [GHC] #9971: GHC 7.10 dies with "out of memory" In-Reply-To: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> References: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> Message-ID: <062.40bdd5cf43bcaaea3bb8df7d006192f0@haskell.org> #9971: GHC 7.10 dies with "out of memory" -------------------------------------+------------------------------------- Reporter: albertov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Comment (by albertov): I've narrowed the problem to a specific source file and a specific commit. Since [https://github.com/meteogrid/sigym4-geometry/commit/2b00e8f5052cc392724659079535b453034f1d9a#diff-4 these changes] where made to the `Types.hs` module GHC 7.10 starts consuming all available RAM until the OS kills it when trying to compile it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 12 10:40:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Jan 2015 10:40:53 -0000 Subject: [GHC] #9971: GHC 7.10 dies with "out of memory" In-Reply-To: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> References: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> Message-ID: <062.a44af3e6253127f88e206c8f7c3c9c25@haskell.org> #9971: GHC 7.10 dies with "out of memory" -------------------------------------+------------------------------------- Reporter: albertov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Comment (by nomeata): You added `UndecidableInstances` there. This means: ?My typeclass instances may not be terminating, so when GHC runs into an infinite loop here, it?s my fault.? I did not yet check whether this is the problem, but in a way, you voided the warranty here. Can you reproduce the problem without `UndecidableInstances`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 12 10:50:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Jan 2015 10:50:15 -0000 Subject: [GHC] #9971: GHC 7.10 dies with "out of memory" In-Reply-To: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> References: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> Message-ID: <062.194bcd6d71b8d9837711b677dfc1ad91@haskell.org> #9971: GHC 7.10 dies with "out of memory" -------------------------------------+------------------------------------- Reporter: albertov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Comment (by albertov): Replying to [comment:2 nomeata]: > You added `UndecidableInstances` there. This means: ?My typeclass instances may not be terminating, so when GHC runs into an infinite loop here, it?s my fault.? I did not yet check whether this is the problem, but in a way, you voided the warranty here. Can you reproduce the problem without `UndecidableInstances`? The problem occurs without `UndecidableInstances` too since `Types.hs` is not using it at all. I've used `UndecidableInstances` on another module (`Arbitrary.hs`) but it doesn't get a chance to get compiled since it depends on `Types.hs` which is the problematic module. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 12 11:43:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Jan 2015 11:43:52 -0000 Subject: [GHC] #9971: GHC 7.10 dies with "out of memory" In-Reply-To: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> References: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> Message-ID: <062.5cf94e50b26c3a7bc6c70d0a35c5ccab@haskell.org> #9971: GHC 7.10 dies with "out of memory" -------------------------------------+------------------------------------- Reporter: albertov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Comment (by nomeata): Sorry, could have seen that. It was worth a shot, though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 12 12:12:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Jan 2015 12:12:06 -0000 Subject: [GHC] #9977: Nicer imports Message-ID: <045.95372b208ceb242d2c3dcf27f2958596@haskell.org> #9977: Nicer imports -------------------------------------+------------------------------------- Reporter: tolysz | Owner: Type: feature | Status: new request | Milestone: Priority: lowest | Version: 7.11 Component: Compiler | Operating System: Unknown/Multiple (Parser) | Type of failure: None/Unknown Keywords: imports | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hi, I wonder if we could have {{{#!hs import Data A B (ba, bb, bc) C as C C1 as C1 (ca,cb,cc) D qualified E as E qualified F as F qualified (fa, fb, fc) Libs.Other -- Data.E qualified as E -- both valid -- Data.F qualified as F (fa, fb, fc) }}} to desugar to {{{#!hs import Data.A import Data.B (ba, bb, bc) import Data.C as C import qualified Data.D import qualified Data.E as E import qualified Data.F as F (fa, fb, fc) import Libs.Other }}} so we could make syntax more dry? What it does if there is indentation it uses previous levels as prefix -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 12 15:19:54 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Jan 2015 15:19:54 -0000 Subject: [GHC] #9961: compile-time performance regression compiling genprimcode In-Reply-To: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> References: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> Message-ID: <057.62733e890eb4f295152410b16d820e8e@haskell.org> #9961: compile-time performance regression compiling genprimcode -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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 thoughtpolice): * priority: normal => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 12 15:24:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Jan 2015 15:24:24 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.a2eabfd7b31301a55f8badcbce39de97@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Linux | Segmentation fault, segfault, long Type of failure: Runtime crash | input Blocked By: 4258 | Architecture: x86_64 Related Tickets: | (amd64) | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * priority: highest => high Comment: Not release-blocking -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 12 15:25:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Jan 2015 15:25:47 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.9850953fc9cdffed651d5d90176b106a@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: ghcirun004 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * priority: highest => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 12 15:25:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Jan 2015 15:25:47 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.5c1c990c8b23cfc009f4a5e4333c0fc1@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: ghcirun004 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * priority: highest => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 12 15:28:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Jan 2015 15:28:15 -0000 Subject: [GHC] #9968: DeriveAnyClass fails on multi-parameter type classes In-Reply-To: <047.651a00b270696920750ca655201f4d2f@haskell.org> References: <047.651a00b270696920750ca655201f4d2f@haskell.org> Message-ID: <062.ededffbfd656af44ad3c9389363544d0@haskell.org> #9968: DeriveAnyClass fails on multi-parameter type classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9821 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * priority: highest => high -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 12 15:56:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Jan 2015 15:56:58 -0000 Subject: [GHC] #9386: GHCi cannot load .so in ./ In-Reply-To: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> References: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> Message-ID: <062.227785f44f8a930d48b27f1647b0f734@haskell.org> #9386: GHCi cannot load .so in ./ -------------------------------------+------------------------------------- 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: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D593 -------------------------------------+------------------------------------- Comment (by Reid Barton ): In [changeset:"fe0d289de466b0c34a04350c6f7c096d9a588ad0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fe0d289de466b0c34a04350c6f7c096d9a588ad0" inplace: Don't add empty component to LD_LIBRARY_PATH when it is empty Summary: Avoids a confusing inconsistency when testing #9386 (about ghci finding .so files in .). Test Plan: validate Reviewers: austin Reviewed By: austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D593 GHC Trac Issues: #9386 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 12 16:15:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Jan 2015 16:15:52 -0000 Subject: [GHC] #9974: Allow more general structural recursion without UndecidableInstances In-Reply-To: <045.b388614289e2dfd61f708eef2be07eb0@haskell.org> References: <045.b388614289e2dfd61f708eef2be07eb0@haskell.org> Message-ID: <060.ec462ade65606286cf52f3404d9c3ba5@haskell.org> #9974: Allow more general structural recursion without UndecidableInstances -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.11 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 goldfire): * cc: eir@? (added) Comment: Yes, I definitely think GHC's termination checker could be beefed up. I believe one challenge here is that repeated variables are allowed on the left-hand sides, which causes havoc with a straightforward check for structural recursion (I believe). But I only barely know what I'm talking about here, so it may be much simpler than I think. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 12 17:28:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Jan 2015 17:28:46 -0000 Subject: [GHC] #9961: compile-time performance regression compiling genprimcode In-Reply-To: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> References: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> Message-ID: <057.d729a536f5c5ca057d59b27d44a3843f@haskell.org> #9961: compile-time performance regression compiling genprimcode -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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 scpmw): Turns out that this might have been my fault anyway. Background here is that CSE needs to strip ticks from expressions fairly often, and `stripTicks` was not particularly efficient at it. The attached patch should restore acceptable performance. I also added a performance test - this is fairly easy to reproduce. (For the cost-centre issue mentioned above, see Phabricator D616). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 12 17:51:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Jan 2015 17:51:21 -0000 Subject: [GHC] #9977: Nicer imports In-Reply-To: <045.95372b208ceb242d2c3dcf27f2958596@haskell.org> References: <045.95372b208ceb242d2c3dcf27f2958596@haskell.org> Message-ID: <060.dfdd33325554e8616389558b8ca01cbd@haskell.org> #9977: Nicer imports -------------------------------------+------------------------------------- Reporter: tolysz | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.11 (Parser) | Keywords: imports Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): In your example, how would you distinguish whether or not you intend to import the module `Data`? Or more realistically, how do I import both `Data.ByteString` and `Data.ByteString.Lazy` without repeating `ByteString`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 12 18:00:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Jan 2015 18:00:48 -0000 Subject: [GHC] #9977: Nicer imports In-Reply-To: <045.95372b208ceb242d2c3dcf27f2958596@haskell.org> References: <045.95372b208ceb242d2c3dcf27f2958596@haskell.org> Message-ID: <060.212140dc5d3f2dc251bdf38599446fc0@haskell.org> #9977: Nicer imports -------------------------------------+------------------------------------- Reporter: tolysz | Owner: Type: feature request | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.11 (Parser) | Keywords: imports Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by tolysz): {{{#!hs import Data.ByteString @ Lazy import Data.ByteString {@, Lazy} import Data.ByteString {@, Lazy} }}} You got me, there needs to be a symbol for indicating current node, and not sure which would be the best one `@` here is just an example. Curly brackets to de-sugaring to indentation would help as well :) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 12 22:57:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Jan 2015 22:57:12 -0000 Subject: [GHC] #9961: compile-time performance regression compiling genprimcode In-Reply-To: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> References: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> Message-ID: <057.813e2c7668625bda758de0aa33d4fc9a@haskell.org> #9961: compile-time performance regression compiling genprimcode -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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 hvr): How is attachment:fix-9961.patch related to Phab:D616? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 12 22:58:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Jan 2015 22:58:34 -0000 Subject: [GHC] #9961: compile-time performance regression compiling genprimcode In-Reply-To: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> References: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> Message-ID: <057.1945aeb677cb06b0010210663c0ba21b@haskell.org> #9961: compile-time performance regression compiling genprimcode -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: patch Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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 hvr): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 12 23:38:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 12 Jan 2015 23:38:52 -0000 Subject: [GHC] #9961: compile-time performance regression compiling genprimcode In-Reply-To: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> References: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> Message-ID: <057.553aa2373bc9c57c186ecc757d20d5e3@haskell.org> #9961: compile-time performance regression compiling genprimcode -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: patch Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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 scpmw): Phab:D616 fixes that cost-centre profiling erroneously attributed all cost to `lintAnnots` instead of `CSE`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 01:50:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 01:50:11 -0000 Subject: [GHC] #9971: GHC 7.10 dies with "out of memory" In-Reply-To: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> References: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> Message-ID: <062.f5e8dafcd9dc003d226909eba2644ba5@haskell.org> #9971: GHC 7.10 dies with "out of memory" -------------------------------------+------------------------------------- Reporter: albertov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Comment (by carter): @albertov: could you attach a transcript of building that file with ghc -v3? (that will show us where the build is getting stuck hopefully) Also: what optimization level /other flags are you giving ghc -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 01:52:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 01:52:24 -0000 Subject: [GHC] #9971: GHC 7.10 dies with "out of memory" In-Reply-To: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> References: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> Message-ID: <062.18565ed423bde16b96702894a568ebe9@haskell.org> #9971: GHC 7.10 dies with "out of memory" -------------------------------------+------------------------------------- Reporter: albertov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Comment (by carter): hrmm, it also looks like your cabal file hard sets the -O2 flag. could you try building with -O1 or -O0 instead? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 06:04:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 06:04:26 -0000 Subject: [GHC] #9978: DEBUG is always replaced as 1 when CPP pragma is on Message-ID: <046.1e158369b154425aa800b189096e6147@haskell.org> #9978: DEBUG is always replaced as 1 when CPP pragma is on -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Trying to compile the following code: {{{ {-# LANGUAGE CPP #-} data Level = DEBUG }}} results in error: {{{ Test.hs:2:14: Illegal literal in type (use DataKinds to enable): 1 }}} which is of course an error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 08:40:29 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 08:40:29 -0000 Subject: [GHC] #9971: GHC 7.10 dies with "out of memory" In-Reply-To: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> References: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> Message-ID: <062.5bdd4c165cfd877b4a05a43380f4231d@haskell.org> #9971: GHC 7.10 dies with "out of memory" -------------------------------------+------------------------------------- Reporter: albertov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Comment (by albertov): I've created a [https://github.com/meteogrid/sigym4-geometry/tree/ghc-9971 new branch] in my library to track this down from the first revision that causes the problem (2b00e8f5052cc392). I've removed the `-O2` flag from the `test` section of the .cabal file (the library section didn't have it) and configured with: `cabal configure --disable-optimization --ghc- options="-v3" --enable-tests -w /usr/local/bin/ghc-7.10.0.20141222`. The output of the configure step is: {{{ Resolving dependencies... Configuring sigym4-geometry-0.1.0.2... Glasgow Haskell Compiler, Version 7.10.0.20141222, stage 2 booted by GHC version 7.8.3 Using binary package database: /usr/local/lib/ghc-7.10.0.20141222/package.conf.d/package.cache Using binary package database: /home/alberto/.ghc/x86_64-linux-7.10.0.20141222/package.conf.d/package.cache wired-in package ghc-prim mapped to ghc- prim-0.3.1.0-ef8d733e55253d54bc20910b190b4671 wired-in package integer-gmp mapped to integer- gmp-1.0.0.0-1c365c75fd598ef8737ed7c605ee03d2 wired-in package base mapped to base-4.8.0.0-e29e6aeb808f5a1814cb5be39ea4f618 wired-in package rts mapped to builtin_rts wired-in package template-haskell mapped to template- haskell-2.10.0.0-4568f09ac38ddc61b7786e2a3f416f4b wired-in package ghc mapped to ghc-7.10.0.20141222-6718a8ae216097cfa2a99e476432dc11 wired-in package dph-seq not found. wired-in package dph-par not found. Hsc static flags: Created temporary directory: /tmp/ghc20749_0 *** C Compiler: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -x c /tmp/20700.c -o /tmp/ghc20749_0/ghc20749_1.s -Wimplicit -S '-D__GLASGOW_HASKELL__=710' -include /usr/local/lib/ghc-7.10.0.20141222/include/ghcversion.h -I/usr/local/lib/ghc-7.10.0.20141222/base_469rOtLAqwTGFEOGWxSUiQ/include -I/usr/local/lib/ghc-7.10.0.20141222/integ_21cuTlnn00eFNd4GMrxOMi/include -I/usr/local/lib/ghc-7.10.0.20141222/include *** Assembler: /usr/bin/gcc -fno-stack-protector -DTABLES_NEXT_TO_CODE -x assembler -c /tmp/ghc20749_0/ghc20749_1.s -o /tmp/20700.o *** Deleting temp files: Deleting: /tmp/ghc20749_0/ghc20749_1.s *** Deleting temp dirs: Deleting: /tmp/ghc20749_0 }}} The executed `cabal build > build.log 2>&1`and waited for the OS to kill ghc. I've attached the resulting build.log file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 08:42:27 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 08:42:27 -0000 Subject: [GHC] #9971: GHC 7.10 dies with "out of memory" In-Reply-To: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> References: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> Message-ID: <062.12b2a0aeeeb1b7317fdf227fb3d6670a@haskell.org> #9971: GHC 7.10 dies with "out of memory" -------------------------------------+------------------------------------- Reporter: albertov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Comment (by albertov): I'm going to try to narrow it down further by removing code from `Types.hs` until it compiles fine and then adding back the problematic part. Hopefully it this strategy works out.. I'll report back anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 09:12:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 09:12:20 -0000 Subject: [GHC] #9971: GHC 7.10 dies with "out of memory" In-Reply-To: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> References: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> Message-ID: <062.335f12b9d605a2bce269e3b9c5086456@haskell.org> #9971: GHC 7.10 dies with "out of memory" -------------------------------------+------------------------------------- Reporter: albertov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Comment (by albertov): Interesting... I've managed to sidestep the bug by changing unboxed vectors to boxed vectors (from the `vector` package). [https://github.com/meteogrid/sigym4-geometry/compare/ghc-9971?expand=1#diff-0 These] are the changes I've made. So it seems related somehow to the use of unboxed vectors. Hopefully this helps. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 09:16:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 09:16:13 -0000 Subject: [GHC] #9971: GHC 7.10 dies with "out of memory" In-Reply-To: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> References: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> Message-ID: <062.bde1179ccd5d732cbdb03f74685f4402@haskell.org> #9971: GHC 7.10 dies with "out of memory" -------------------------------------+------------------------------------- Reporter: albertov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Comment (by albertov): Damn, ignore my previous comments regarding unboxed vectors. I've unconfigured my build by accident by deleting the dist directory and it was 7.8.3 building it :( Sorry for the noise. I'll rinse and repeat and hopefully provide some useful information. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 09:25:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 09:25:46 -0000 Subject: [GHC] #9971: GHC 7.10 dies with "out of memory" In-Reply-To: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> References: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> Message-ID: <062.79b603b4dbf9e483fbe3a1d51dbb0615@haskell.org> #9971: GHC 7.10 dies with "out of memory" -------------------------------------+------------------------------------- Reporter: albertov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Comment (by albertov): Ok, now for real. It seems the culprit is the code generated by `derivingUnbox "Point"`. The changes that sidestep the bug are [https://github.com/meteogrid/sigym4-geometry/compare/ghc-9971?expand=1#diff-0 these]. I've reconfigured with `cabal configure --disable-optimization --ghc- options="-ddump-splices" --enable-tests -w /usr/local/bin/ghc-7.10.0.20141222`, added back the `derivingUnbox` part (which now I'm positive that it's the real culprit) and I'm attaching the build output with the generated TH code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 09:34:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 09:34:04 -0000 Subject: [GHC] #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family In-Reply-To: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> References: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> Message-ID: <060.9f5555e970a3d15f8027ddae0cc2004c@haskell.org> #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family -------------------------------------+------------------------------------- Reporter: qnikst | 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 oleg): I too have tried to induce unsoundness with overlapping instances and concluded it is unlikely -- although there is plenty of strange and incoherent behavior one can observe. The straightforward attempt to pack an existential in one type class environment and unpack it in another module (where a more specialized instance is introduced) does not work because the existential is packed with the corresponding dictionary. When it is unpacked, the packed dictionary is used -- regardless how many new instances become available. Without type families, a type variable always stood for some ground type, at least potentially. When we assert a constraint C a on the type variable a, that constraint will not be dropped or discarded. It will be explicitly passed around, until it is resolved (or cannot be resolved -- in which case an error is reported). That is why it is safe to do instance selection for unground types: if we have {{{ class C a where foo :: a -> Int instance C [a] where foo = length test3 x = foo [x] }}} the inferred type for test3 :: t -> Int has no constraints. We resolved C [t] for the unground type t. If t had other constraints, they will be preserved. With type functions, we are no longer sure what the type variable represents. It can be a non-reduced type-function application. So a type variable now stands not for a value (ground type) but for an expression. And that could be a problem. For example: {{{ type family TT a -- no instances newtype D a = D{unD:: [TT a]} test4 (x::a) = foo (unD (undefined:: D a)) test5 (x::a) = foo (unD (D []:: D a)) }}} The code type-checks and test5 () even runs, returning 0. So, although T a has no instances, we have successfully ignored that fact. That trick would not have worked with only type classes; if we add a constraint we can't cast it away, and the type checker will demand sooner or later the constraint be satisfied. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 09:47:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 09:47:28 -0000 Subject: [GHC] #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family In-Reply-To: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> References: <045.8b42c360bfa608017b9b2986029ca51e@haskell.org> Message-ID: <060.33dfd952f80c0562a8dc8b7ef43b09bd@haskell.org> #9918: GHC chooses an instance between two overlapping, but cannot resolve a clause within the similar closed type family -------------------------------------+------------------------------------- Reporter: qnikst | 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): GHC has always permitted types that are uninhabited (except by bottom); consider {{{ data Void -- No constructors }}} So I don't see why `(undefined :: TT a)` should be a problem. I certainly don't see a problem with `test4` or `test5`. Your instance of `C [a]` does not require `C a`, and so of course we can compute the length of a list `[TT a]` without knowing anything about the type `TT a`. That's just parametricity. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 11:03:31 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 11:03:31 -0000 Subject: [GHC] #9979: Performance regression GHC 7.8.4 to GHC HEAD Message-ID: <044.73ef7dd92c5e21de402bf2a850f099ad@haskell.org> #9979: Performance regression GHC 7.8.4 to GHC HEAD -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Keywords: regression | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Testing with HEAD 023439980f6ef6ec051f676279ed2be5f031efe6 Baseline: GHC 7.8.4 {{{ ghc-config 7.8.4 cabal unpack haskell-src-exts cd haskell-src-exts-1.16.0.1/ cabal install --dependencies-only time (cabal clean && cabal build) real 2m38.696s user 5m17.256s sys 3m44.732s }}} Test : GHC HEAD {{{ ghc-config 7.11.20150112 cabal install --dependencies-only time (cabal clean && cabal build) real 3m35.027s user 6m45.664s sys 5m15.220s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 11:10:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 11:10:11 -0000 Subject: [GHC] #9979: Performance regression GHC 7.8.4 to GHC HEAD In-Reply-To: <044.73ef7dd92c5e21de402bf2a850f099ad@haskell.org> References: <044.73ef7dd92c5e21de402bf2a850f099ad@haskell.org> Message-ID: <059.e929f10e6ba120ddeedf22e97dc6d2ea@haskell.org> #9979: Performance regression GHC 7.8.4 to GHC HEAD -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): It would be helpful if someone felt able to characterise this more. For example: * Do the two invocations of `cabal install` compile exactly the same number of modules, each containing exactly the same code? * Which modules take longer to compile? Or does everything take a little longer? Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 12:04:55 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 12:04:55 -0000 Subject: [GHC] #9980: MUSCLES BUILDING Message-ID: <051.02739ec67ecc4fc285544fadf4a327d5@haskell.org> #9980: MUSCLES BUILDING -------------------------------------+------------------------------------- Reporter: | Owner: ChesterDicus | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: MAXX TEST | Type of failure: None/Unknown 300 | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- You'll receive anonymous part one hundred percent no questions asked refund but wait there's more you can start right away because I'm going to download [http://www.x4facts.com/before-buying-maxx-test-300-read-it- first/ MAXX TEST 300] everything from my website to your computer don't worry this issuer easy if you can open your email you can do this but I'll personally walk you through this step-by-step on the next page you're about to get instant access tithe complete package I know you were closer . http://www.x4facts.com/before-buying-maxx-test-300-read-it-first/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 12:06:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 12:06:35 -0000 Subject: [GHC] #9981: MALE SUPPLEMENT Message-ID: <051.3b492eb4546baa872d2675c2a09e7cfb@haskell.org> #9981: MALE SUPPLEMENT -------------------------------------+------------------------------------- Reporter: | Owner: ChesterDicus | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: MAXX TEST | Type of failure: None/Unknown 300 | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- You ever have been before to having the body in the life the you deserve and desire you?re going to wake up just a few days from now it's your muscles fall in vascular you're going to have to conserve energy party at [http://www.x4facts.com/before-buying-maxx-test-300-read-it-first/ MAXX TEST 300] the gym because you can feel that this is already working picture yourself just a few weeks from now strong confident Norris respected forth first time a match in the feeling you're going to have when even the hottest girls heads turn your way every single day it's time to make this happen click . http://www.x4facts.com/before-buying-maxx-test-300-read-it-first/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 12:08:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 12:08:48 -0000 Subject: [GHC] #9982: MALE SUPPLEMENT Message-ID: <051.8ef19e3071120a8830aedaece40c16aa@haskell.org> #9982: MALE SUPPLEMENT -------------------------------------+------------------------------------- Reporter: | Owner: ChesterDicus | Status: new Type: bug | Milestone: Priority: highest | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: MAXX TEST | Type of failure: None/Unknown 300 | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I get started remember what you've been doing up until now has not worked but now you know why this will work I promise getting ripped up in record [http://www.x4facts.com/before-buying-maxx-test-300-read-it-first/ MAXX TEST 300] time like more real users you're about to see is at your fingertips they managed to get them currently deployed United States Marine Corps and I want to you today most MaxMaramixed messages to his quick efficient easy you can't beat it easy within the first six weeks I noticed. http://www.x4facts.com/before-buying-maxx-test-300-read-it-first/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 12:09:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 12:09:43 -0000 Subject: [GHC] #9983: BODY MAXIMIZE Message-ID: <051.80a97ba9fa4adce8356e5bf0b996a5e5@haskell.org> #9983: BODY MAXIMIZE -------------------------------------+------------------------------------- Reporter: | Owner: ChesterDicus | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: MAXX TEST | Type of failure: None/Unknown 300 | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- You count the muscle in high school I was those this can you get a very good for cracked jokes Kong string beans be in stock but that there is a certain reason [http://www.x4facts.com/before-buying-maxx-test-300-read- it-first/ MAXX TEST 300] that snowball Muscle Maximize I double bass quite America traffic is bigger and French is steadily increasing thanks in forever went through my kids and things just seem to be getting better so far for me if you work for you you are at a fork in the road with the decision to make the road you're on relief Russia week after week doing all of the unproven things you know . http://www.x4facts.com/before-buying-maxx-test-300-read-it-first/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 12:10:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 12:10:46 -0000 Subject: [GHC] #9984: MUSCLES MAXIMIZE Message-ID: <051.611eaf0cf0bb6bbf49b69a082987b326@haskell.org> #9984: MUSCLES MAXIMIZE -------------------------------------+------------------------------------- Reporter: | Owner: ChesterDicus | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: MAXX TEST | Type of failure: None/Unknown 300 | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I don't work only the people that actually know you lift weights will jokingly grab your arms a compliment you to be nice well all the hot girls continue to [http://www.x4facts.com/before-buying-maxx-test-300-read-it- first/ MAXX TEST 300] walk by Union take up with Oak Lawn sick you'll watch the best years of your life fly by without ever experiencing double take some girls in genuine compliments about your physique or you can choose the other road the road have change this role represents a decision to take control of your life and will prove to yourself family and friends that you will not accept just being average your body is the first thing to change right away. http://www.x4facts.com/before-buying-maxx-test-300-read-it-first/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 12:11:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 12:11:40 -0000 Subject: [GHC] #9985: BODY BUILDING Message-ID: <051.0f56610acb86510201b44b16ccc8f9f4@haskell.org> #9985: BODY BUILDING -------------------------------------+------------------------------------- Reporter: | Owner: ChesterDicus | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: MAXX TEST | Type of failure: None/Unknown 300 | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- You start getting genuine compliments from people about your new rock solid muscle you're finally coffin take your shirt off because you know girls like what they see from there doors will begin to open for you in all [http://www.x4facts.com/before-buying-maxx-test-300-read-it-first/ MAXX TEST 300] areas of your life that you never knew existed because %uh van love the confidence power and respected you've gained in yourself but everything starts with your decision to make that change today opportunities like this do not come along every day do not let this one slip between your fingers because like all great opportunities it will be gone before you know it sees this one . http://www.x4facts.com/before-buying-maxx-test-300-read-it-first/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 12:14:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 12:14:02 -0000 Subject: [GHC] #9986: MUSCLES IMPROVEMENT Message-ID: <051.27d1d6d0e8f761225ecbfaf250a4741a@haskell.org> #9986: MUSCLES IMPROVEMENT -------------------------------------+------------------------------------- Reporter: | Owner: ChesterDicus | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: MAXX TEST | Type of failure: None/Unknown 300 | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- You candor for yourself to prevent it so what happens in this is something interesting a lot of people we're going to talk about prostate as I said before [http://www.x4facts.com/before-buying-maxx-test-300-read-it-first/ MAXX TEST 300] but people take saw palmetto for that but you can also take a for hair loss as well so what happens you have an enzyme on your scalp and when testosterone comes in contact with this enzyme 5 alpha reeducates if arms DHT in this particular subject is what are topic is what causes your hair to fall out if you remove that and our prevent that from happening the HD print that performing then technically . http://www.x4facts.com/before-buying-maxx-test-300-read-it-first/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 12:14:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 12:14:28 -0000 Subject: [GHC] #9987: MALE SUPPLEMENT Message-ID: <051.f3f3cf1dd4f39717e98bc13e8de60708@haskell.org> #9987: MALE SUPPLEMENT -------------------------------------+------------------------------------- Reporter: | Owner: ChesterDicus | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: MAXX TEST | Type of failure: None/Unknown 300 | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Only about95 percent only about a large amount ninety-five percent are genetic that's what that cause the hair loss aging lifestyle nutritional deficiencies as [http://www.x4facts.com/before-buying-maxx-test-300-read- it-first/ MAXX TEST 300] and not enough protein not enough think and not enough iron in the diet some other causes are emotional stress pregnancy and medications high blood pressure can cause hair loss and I blood pressure medications especially can cause a hair loss and deliberate or the Staten drugs are horrible for that just because the circulation and some other things but we're tonnage into the specifics on what causes hair loss and different things. http://www.x4facts.com/before-buying-maxx-test-300-read-it-first/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 12:15:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 12:15:24 -0000 Subject: [GHC] #9988: BODY BUILD UP Message-ID: <051.5156b3f793a5a2867d098b964aa273a0@haskell.org> #9988: BODY BUILD UP -------------------------------------+------------------------------------- Reporter: | Owner: ChesterDicus | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: MAXX TEST | Type of failure: None/Unknown 300 | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Those are three main topics for mental about roses going to talk about infertility gird high [http://www.x4facts.com/before-buying-maxx-test-300 -read-it-first/ MAXX TEST 300] blood pressure and diabetes and or something is going to be one of our common things today because he's a pretty good example majority of man today unfortunately so hair loss eighty percent of people experienced some type of hair loss and over seven billion dollars a year spent on hair loss prevention hair loss products like Knoxville things like that but usually . http://www.x4facts.com/before-buying-maxx-test-300-read-it-first/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 12:15:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 12:15:37 -0000 Subject: [GHC] #9989: MALE SUPPLEMENT Message-ID: <051.632279d9c91fbf067addfbe154c56825@haskell.org> #9989: MALE SUPPLEMENT -------------------------------------+------------------------------------- Reporter: | Owner: ChesterDicus | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: MAXX TEST | Type of failure: None/Unknown 300 | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Now let's get started on your new body your new future and your new life right now click [http://www.x4facts.com/before-buying-maxx-test-300-read- it-first/ MAXX TEST 300] the Add to Cart button below and I'll see you on the other side this this home well thanks for coming to I'm a doctor John DeWitt and we're going to talk about men's health today we're going to cover a variety of subjects happen talk about baldness which is unfortunate but experience by a large number people prostate health as well as erectile dysfunction . http://www.x4facts.com/before-buying-maxx-test-300-read-it-first/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 13:33:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 13:33:02 -0000 Subject: [GHC] #9979: Performance regression GHC 7.8.4 to GHC HEAD In-Reply-To: <044.73ef7dd92c5e21de402bf2a850f099ad@haskell.org> References: <044.73ef7dd92c5e21de402bf2a850f099ad@haskell.org> Message-ID: <059.a17975212af405a3a7c06004bf3b47b0@haskell.org> #9979: Performance regression GHC 7.8.4 to GHC HEAD -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): Maybe another example to investigate is `cabal install text`, which went from 30 secs on GHC 7.4 to 90 secs on GHC 7.10: {{{ attoparsec-0.10.4.0 GHC-7.10.0.20141227 text-1.2.0.4 # 92668ms attoparsec-0.10.4.0 GHC-7.8.4 text-1.2.0.4 # 65736ms attoparsec-0.10.4.0 GHC-7.6.3 text-1.2.0.4 # 27520ms attoparsec-0.10.4.0 GHC-7.4.2 text-1.2.0.4 # 31303ms }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 14:03:46 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 14:03:46 -0000 Subject: [GHC] #9980: TcS monad is too heavy Message-ID: <046.9f2f16945c1ea3d5dff728997ee3b117@haskell.org> #9980: TcS monad is too heavy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The typehcecker's constraint-solving monad, `TcS`, is simply built on top of `TcM`, but it doesn't use most of `TcM`'s facilities. That was fine while `TcS` was only called from the typechecker, but now (as part of [wiki:PatternMatchCheck fixing pattern-match overlap checking]) we invoke it from the desugarer. It seems quite wrong to construct a vast, and unnecessary `TcM` context just to invoke `TcS`. Better: make `TcS` into its own monad, with its own `TcSLclEnv`, built on `IOEnv` like the others. Main objection: the plugins mechanism exposes `unsafeTcPluginTcM`, which would become unavailable. But it it used? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 14:04:09 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 14:04:09 -0000 Subject: [GHC] #9980: TcS monad is too heavy In-Reply-To: <046.9f2f16945c1ea3d5dff728997ee3b117@haskell.org> References: <046.9f2f16945c1ea3d5dff728997ee3b117@haskell.org> Message-ID: <061.ba22c0fea3b1f6315f0c00b2977bffc7@haskell.org> #9980: TcS monad is too heavy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: > The typehcecker's constraint-solving monad, `TcS`, is simply built on top > of `TcM`, but it doesn't use most of `TcM`'s facilities. That was fine > while `TcS` was only called from the typechecker, but now (as part of > [wiki:PatternMatchCheck fixing pattern-match overlap checking]) we invoke > it from the desugarer. > > It seems quite wrong to construct a vast, and unnecessary `TcM` context > just to invoke `TcS`. > > Better: make `TcS` into its own monad, with its own `TcSLclEnv`, built on > `IOEnv` like the others. > > Main objection: the plugins mechanism exposes `unsafeTcPluginTcM`, which > would become unavailable. But it it used? New description: The typechecker's constraint-solving monad, `TcS`, is simply built on top of `TcM`, but it doesn't use most of `TcM`'s facilities. That was fine while `TcS` was only called from the typechecker, but now (as part of [wiki:PatternMatchCheck fixing pattern-match overlap checking]) we invoke it from the desugarer. It seems quite wrong to construct a vast, and unnecessary `TcM` context just to invoke `TcS`. Better: make `TcS` into its own monad, with its own `TcSLclEnv`, built on `IOEnv` like the others. Main objection: the plugins mechanism exposes `unsafeTcPluginTcM`, which would become unavailable. But it it used? -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 14:04:29 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 14:04:29 -0000 Subject: [GHC] #9980: TcS monad is too heavy In-Reply-To: <046.9f2f16945c1ea3d5dff728997ee3b117@haskell.org> References: <046.9f2f16945c1ea3d5dff728997ee3b117@haskell.org> Message-ID: <061.b480b3f7573c22ca47ed1a586279c9a2@haskell.org> #9980: TcS monad is too heavy -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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): Iavor: any comments about the `unsafeTcPluginTcM` thing? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 16:09:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 16:09:51 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.3d994911fd863a73d1a0ef3bd213cedd@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------- Reporter: GregWeber | Owner: Type: feature request | Status: patch Priority: normal | Milestone: 7.10.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:D518 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"07ace5c221adbb1675413a0fac300a9f7913c234/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="07ace5c221adbb1675413a0fac300a9f7913c234" add -th-file which generates a th.hs file Summary: see Trac #8624 similar functionality is now available with -ddump-to-file -ddump-splices However, users are already accustomed to -ddump-splices having a particular format, and this format is not completely valid code The goal of -th-file is to dump valid Haskell code Additionally, the convention of -ddump-to-file is to name the file after the flag, so the file is .dump-splices Given that the goal of the new flag is to generate valid Haskell, The extension should be .hs Additionally, -ddump-to-file effects all other dump flags Test Plan: look at the output of using the -th-file flag and compare it to the output of using -ddump-to-file and -ddump-splices I want to add test cases, but just need some pointers on getting started there Reviewers: thomie, goldfire, simonpj, austin Reviewed By: simonpj, austin Subscribers: thomie, carter Differential Revision: https://phabricator.haskell.org/D518 GHC Trac Issues: #8624 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 16:09:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 16:09:51 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.db459afa4bd3e0570882202e34bb5e0b@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | facundo.dominguez Priority: normal | Status: patch Component: Compiler | Milestone: 7.10.1 Resolution: | Version: 7.9 Operating System: Unknown/Multiple | Keywords: Type of failure: GHCi crash | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D586 | Phab:D587 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"7637810a93441d29bc84bbeeeced0615bbb9d9e4/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7637810a93441d29bc84bbeeeced0615bbb9d9e4" Trac #9878: Have StaticPointers support dynamic loading. Summary: A mutex is used to protect the SPT. unsafeLookupStaticPtr and staticPtrKeys in GHC.StaticPtr are made monadic. SPT entries are removed in a destructor function of modules. Authored-by: Facundo Dom?nguez Authored-by: Alexander Vershilov Test Plan: ./validate Reviewers: austin, simonpj, hvr Subscribers: carter, thomie, qnikst, mboes Differential Revision: https://phabricator.haskell.org/D587 GHC Trac Issues: #9878 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 16:09:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 16:09:51 -0000 Subject: [GHC] #9922: Partial type signatures + extensions panic In-Reply-To: <047.bcb93dee275eec47e30ed9673a9b0d12@haskell.org> References: <047.bcb93dee275eec47e30ed9673a9b0d12@haskell.org> Message-ID: <062.97a4af0efe2282d2bd835bf87bc62105@haskell.org> #9922: Partial type signatures + extensions panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: thomasw Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.9 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Phab:D595 Related Tickets: | -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"c9532f810a82c6395bc08fb77f2a895a50da86b5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c9532f810a82c6395bc08fb77f2a895a50da86b5" Fix panics of PartialTypeSignatures combined with extensions Summary: Disallow wildcards in stand-alone deriving instances (StandaloneDeriving), default signatures (DefaultSignatures) and instances signatures (InstanceSigs). Test Plan: validate Reviewers: austin Reviewed By: austin Subscribers: carter, thomie, monoidal Differential Revision: https://phabricator.haskell.org/D595 GHC Trac Issues: #9922 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 18:15:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 18:15:25 -0000 Subject: [GHC] #9981: Potential typechecker regression in GHC 7.10.1RC Message-ID: <042.c047cab9d166b1747ff4913537189070@haskell.org> #9981: Potential typechecker regression in GHC 7.10.1RC -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 (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 snippet (extracted from hackage:index-core) is accepted by GHCs prior to GHC 7.10: {{{#!hs {-# LANGUAGE Rank2Types, TypeOperators #-} module Foo where type a :-> b = forall i . a i -> b i class IFunctor f where fmapI :: (a :-> b) -> (f a :-> f b) class (IFunctor m) => IMonad m where returnI :: a :-> m a bindI :: (a :-> m b) -> (m a :-> m b) (?>=) :: (IMonad m) => m a i -> (a :-> m b) -> m b i (?>=) = flip bindI }}} {{{ $ ghci-7.8.4 -Wall Foo.hs GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling Control.IMonad.Core ( Foo.hs, interpreted ) Ok, modules loaded: Control.IMonad.Core. ?:2> :browse type (:->) (a :: * -> *) (b :: * -> *) = forall i. a i -> b i class IFunctor (f :: (* -> *) -> * -> *) where fmapI :: (a :-> b) -> f a :-> f b class IFunctor m => IMonad (m :: (* -> *) -> * -> *) where returnI :: a i -> m a i bindI :: (a :-> m b) -> m a :-> m b (?>=) :: IMonad m => m a i -> (a :-> m b) -> m b i }}} vs. {{{ $ ghci-7.10.0.20141227 -Wall Foo.hs GHCi, version 7.10.0.20141227: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Control.IMonad.Core ( Foo.hs, interpreted ) Foo.hs:15:14: Couldn't match type ?a i0 -> m b i0? with ?forall i1. a i1 -> m b i1? Expected type: (a i0 -> m b i0) -> m a i -> m b i Actual type: a :-> m b -> m a i -> m b i Relevant bindings include (?>=) :: m a i -> a :-> m b -> m b i (bound at Foo.hs:15:1) In the first argument of ?flip?, namely ?bindI? In the expression: flip bindI Failed, modules loaded: none. ?:2> }}} I'm not sure though whether that module was valid to begin with... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 19:53:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 19:53:02 -0000 Subject: [GHC] #9982: cross building integer-gmp is running target program on build host Message-ID: <046.8a1ffc42fb5fbbea8ac62e5a7db86511@haskell.org> #9982: cross building integer-gmp is running target program on build host -------------------------------------+------------------------------------- Reporter: newsham | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.4 System | Operating System: Linux Keywords: | Type of failure: Building GHC Architecture: | failed Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I am trying to build ghc-7.8.4 as a cross compiler. After stage1 finishes and it tries to build libraries it detects that it can link against an existing -gmp and gmp.h (which is what I intended) and starts building the libraries/integer-gmp package against it. During the build it builds the inplace/lib/bin/mkGmpDerivedConstants binary for the target (genode) and then runs it on the build host (ubuntu linux), which leads to failure. The error emitted during the build is: "cp" -p libraries/integer- gmp/mkGmpDerivedConstants/dist/build/tmp/mkGmpDerivedConstants inplace/lib/bin/mkGmpDerivedConstants "rm" -f inplace/lib/mkGmpDerivedConstants echo '#!/bin/bash' >> inplace/lib/mkGmpDerivedConstants echo 'executablename="/u1/home/newsham/src/genode/ghc-7.8.4/inplace/lib/bin/mkGmpDerivedConstants"' >> inplace/lib/mkGmpDerivedConstants echo 'datadir="/u1/home/newsham/src/genode/ghc-7.8.4/inplace/lib"' >> inplace/lib/mkGmpDerivedConstants echo 'bindir="/u1/home/newsham/src/genode/ghc-7.8.4/inplace/bin"' >> inplace/lib/mkGmpDerivedConstants echo 'topdir="/u1/home/newsham/src/genode/ghc-7.8.4/inplace/lib"' >> inplace/lib/mkGmpDerivedConstants echo 'pgmgcc="/u1/home/newsham/src/genode/ghc-7.8.4/wrapper-gcc"' >> inplace/lib/mkGmpDerivedConstants echo 'export LD_LIBRARY_PATH=":$LD_LIBRARY_PATH"' >> inplace/lib/mkGmpDerivedConstants echo 'exec "$executablename" ${1+"$@"}' >> inplace/lib/mkGmpDerivedConstants chmod +x inplace/lib/mkGmpDerivedConstants inplace/lib/mkGmpDerivedConstants > libraries/integer- gmp/mkGmpDerivedConstants/dist/GmpDerivedConstants.h inplace/lib/mkGmpDerivedConstants: line 8: /u1/home/newsham/src/genode/ghc-7.8.4/inplace/lib/bin/mkGmpDerivedConstants: No such file or directory make[1]: *** [libraries/integer- gmp/mkGmpDerivedConstants/dist/GmpDerivedConstants.h] Error 127 make[1]: *** Deleting file `libraries/integer- gmp/mkGmpDerivedConstants/dist/GmpDerivedConstants.h' make: *** [all] Error 2 my build environment is large and complex so I'm not providing all details here, but I will be happy to provide any supporting material needed, on request. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 20:17:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 20:17:41 -0000 Subject: [GHC] #9213: Maybe important CPP warnings on ghcautoconf.h from cpphs In-Reply-To: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> References: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> Message-ID: <057.edd352b0141b8575281d12b975fbc1cd@haskell.org> #9213: Maybe important CPP warnings on ghcautoconf.h from cpphs -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: 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 asr): I realised Alex is including the file {{{ghcconfig.h}}} which generates the warning when using cpphs. An example using the file https://github.com/simonmar/alex/blob/master/examples/Tokens.x: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.4 $ alex --version Alex version 3.1.4, (c) 2003 Chris Dornan and Simon Marlow $ cpphs --version cpphs 1.18.6 $ alex Tokens.x $ ghc -pgmPcpphs -optP--cpp Tokens.hs Warning: trailing characters after #if directive in file /usr/local/stow/ghc-7.8.4-bin/lib/ghc-7.8.4/include/ghcautoconf.h at line 383 col 1: AC_APPLE_UNIVERSAL_BUILD [1 of 1] Compiling Main ( Tokens.hs, Tokens.o ) Linking Tokens ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 20:27:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 20:27:48 -0000 Subject: [GHC] #9213: Maybe important CPP warnings on ghcautoconf.h from cpphs In-Reply-To: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> References: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> Message-ID: <057.b2ae3cd6a09199598701ef744b47bbe3@haskell.org> #9213: Maybe important CPP warnings on ghcautoconf.h from cpphs -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 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): * version: 7.8.4 => 7.10.1-rc1 Comment: And using GHC 7.10.1 RC1, I got an additional warning: {{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.0.20141222 $ ghc -pgmPcpphs -optP--cpp Tokens.hs Warning: Can't find file "/usr/local/stow/ghc-7.10.0.20141222-bin/lib/ghc-7.10.0.20141222/include/ghcversion.h" in directories . /usr/local/stow/ghc-7.10.0.20141222-bin/lib/ghc-7.10.0.20141222/base_469rOtLAqwTGFEOGWxSUiQ/include /usr/local/stow/ghc-7.10.0.20141222-bin/lib/ghc-7.10.0.20141222/integ_21cuTlnn00eFNd4GMrxOMi/include /usr/local/stow/ghc-7.10.0.20141222-bin/lib/ghc-7.10.0.20141222/include Asked for by: Tokens.hs at line 1 col 1 Warning: trailing characters after #if directive in file /usr/local/stow/ghc-7.10.0.20141222-bin/lib/ghc-7.10.0.20141222/include/ghcautoconf.h at line 379 col 1: AC_APPLE_UNIVERSAL_BUILD }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 20:31:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 20:31:47 -0000 Subject: [GHC] #9213: Maybe important CPP warnings on ghcautoconf.h from cpphs In-Reply-To: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> References: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> Message-ID: <057.08716a9e3c9dd888965ea93057b1f516@haskell.org> #9213: Maybe important CPP warnings on ghcautoconf.h from cpphs -------------------------------------+------------------------------------- Reporter: asr | 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: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by asr): * status: infoneeded => new -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 20:33:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 20:33:21 -0000 Subject: [GHC] #9983: configure script invokes ghc with LDFLAGS during cross-builds Message-ID: <046.b6e30fde76aad3b0396b4bd16d470332@haskell.org> #9983: configure script invokes ghc with LDFLAGS during cross-builds -------------------------------------+------------------------------------- Reporter: newsham | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.4 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Building GHC Architecture: | failed Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When building ghc, the aclocal.m4 settings direct "configure" to use the provided LDFLAGS as GHC_LDFLAGS, which are later used to invoke the host's GHC: https://github.com/ghc/ghc/blob/ghc-7.8/aclocal.m4#L1820 This is undesirable when performing a cross-build, in which case the LDFLAGS are used to specify the flags for use when linking for the target and not when linking on the build host. rwbarton at freenode believes that the normal CFLAGS, LDFLAGS, LIBS, etc. should never have an affect on the build host behavior. Either this policy needs to be enforced or a separate set of flags needs to be introduced to allow setting the target flags separately from the build host flags. To reproduce, "./configure LDFLAGS=bogus" and observe the failure in ghc- pwd, which is used on the build host. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 20:56:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 20:56:35 -0000 Subject: [GHC] #9983: configure script invokes ghc with LDFLAGS during cross-builds In-Reply-To: <046.b6e30fde76aad3b0396b4bd16d470332@haskell.org> References: <046.b6e30fde76aad3b0396b4bd16d470332@haskell.org> Message-ID: <061.d220d2f989593658a93febb29e5c30e9@haskell.org> #9983: configure script invokes ghc with LDFLAGS during cross-builds -------------------------------------+------------------------------------- Reporter: newsham | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.4 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 newsham): Besides using LDFLAGS for ghc, configure seems to expect to use the following settings for building binaries on the build host that can be run on the build host: CC, CFLAGS, CPPFLAGS, LDFLAGS, LIBS. Defining any of these to target-appropriate settings causes configure to fail early with: checking whether the C compiler works... no or configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. This includes builds in which --host and --build and --target were all specified where --target is a different value, and --host and --build are the same values. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 21:30:28 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 21:30:28 -0000 Subject: [GHC] #9982: cross building integer-gmp is running target program on build host In-Reply-To: <046.8a1ffc42fb5fbbea8ac62e5a7db86511@haskell.org> References: <046.8a1ffc42fb5fbbea8ac62e5a7db86511@haskell.org> Message-ID: <061.057a7efae64fe9e063c389b70ee5b8cf@haskell.org> #9982: cross building integer-gmp is running target program on build host -------------------------------------+------------------------------------- Reporter: newsham | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by newsham): by the way, the error says the file does not exist, but it actually does (the error is probably coming from ld.so failing to load link deps?): $ file /u1/home/newsham/src/genode/ghc-7.8.4/inplace/lib/bin/mkGmpDerivedConstants /u1/home/newsham/src/genode/ghc-7.8.4/inplace/lib/bin/mkGmpDerivedConstants: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped objdump reveals that it is linked against my target (genode) and not the build host (linux): $ objdump -p /u1/home/newsham/src/genode/ghc-7.8.4/inplace/lib/bin/mkGmpDerivedConstants|grep libc.lib NEEDED /u1/home/newsham/src/genode/novaBox/var/libcache/libc/libc.lib.so -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 23:00:02 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 23:00:02 -0000 Subject: [GHC] #9890: RTS -qa option is helpful but under-documented In-Reply-To: <049.126a2e59b04d15cfa71935d2118594d3@haskell.org> References: <049.126a2e59b04d15cfa71935d2118594d3@haskell.org> Message-ID: <064.23c57e5ab841b6c81faea2ac8187ff06@haskell.org> #9890: RTS -qa option is helpful but under-documented -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: simonmar Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Marlow ): In [changeset:"2a103c7d763c22dc9b0562dac1184ffb950da5ce/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2a103c7d763c22dc9b0562dac1184ffb950da5ce" Improve documentation for -N and -qa (#9890) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 13 23:08:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 13 Jan 2015 23:08:13 -0000 Subject: [GHC] #9389: Full Test Suite Failures In-Reply-To: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> References: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> Message-ID: <057.dd342419e66edfed3fcf7a7089365aa7@haskell.org> #9389: Full Test Suite Failures -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: #9286,#8756,#7876,#7877 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jrp): This week, again with the {{{perf}} BuilfFlavour, 18 fewer failures. {{{ OVERALL SUMMARY for test run started at Tue Jan 13 21:20:19 2015 GMT 0:35:49 spent to go through 4393 total tests, which gave rise to 17970 test cases, of which 3594 were skipped 328 had missing libraries 13787 expected passes 139 expected failures 0 caused framework failures 0 unexpected passes 116 unexpected failures 6 unexpected stat failures Unexpected failures: ../../libraries/base/tests enum01 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) ../../libraries/base/tests enum01 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum02 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) ../../libraries/base/tests enum02 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum03 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) ../../libraries/base/tests enum03 [bad stdout or stderr] (ghci) ../../libraries/base/tests topHandler01 [bad exit code] (threaded1,threaded2,profthreaded) ../../libraries/base/tests topHandler01 [bad stdout or stderr] (ghci) ../../libraries/process/tests process011 [bad exit code] (threaded1,threaded2,profthreaded) ../../libraries/process/tests process011 [bad stdout or stderr] (ghci) ../../libraries/unix/tests signals002 [bad stdout] (threaded1,threaded2,profthreaded) ../../libraries/unix/tests signals002 [bad stdout or stderr] (ghci) cabal/sigcabal01 sigcabal01 [bad stderr] (normal) codeGen/should_run CgStaticPointers [bad stdout or stderr] (ghci) concurrent/should_run allocLimit4 [bad exit code] (ghci) concurrent/should_run conc012 [bad exit code] (ghci) concurrent/should_run conc059 [bad stderr] (threaded1,threaded2) deSugar/should_run DsStaticPointers [bad stdout or stderr] (ghci) deSugar/should_run dsrun014 [bad exit code] (ghci) driver/objc objc-hi [bad profile] (profthreaded) driver/objc objc-hi [bad heap profile] (profasm) driver/objc objcpp-hi [bad profile] (profthreaded) driver/objc objcpp-hi [bad heap profile] (profasm) driver/recomp001 recomp001 [bad stderr] (normal) driver/retc001 retc001 [bad stderr] (normal) ghci/scripts ghci024 [bad stdout] (normal) numeric/should_run add2 [bad exit code] (ghci) numeric/should_run mul2 [bad exit code] (ghci) numeric/should_run quotRem2 [bad exit code] (ghci) parser/should_run readRun004 [bad exit code] (ghci) profiling/should_run T2552 [bad profile] (profasm,profthreaded) profiling/should_run callstack001 [bad stdout] (prof) profiling/should_run ioprof [bad profile] (profasm,profthreaded) profiling/should_run prof-doc-fib [bad profile] (profasm,profthreaded,prof) profiling/should_run scc001 [bad profile] (prof) quasiquotation/qq007 qq007 [exit code non-0] (profasm) quasiquotation/qq008 qq008 [exit code non-0] (profasm) rts GcStaticPointers [bad stdout or stderr] (ghci) rts ListStaticPointers [bad stdout or stderr] (ghci) rts T7919 [bad exit code] (optasm,dyn) rts T7919 [exit code non-0] (profasm,profthreaded) rts T9078 [exit code non-0] (profasm) rts derefnull [bad profile] (profasm,profthreaded) rts divbyzero [bad profile] (profasm,profthreaded) rts overflow1 [bad profile] (profasm,profthreaded) rts overflow2 [bad profile] (profasm,profthreaded) rts overflow3 [bad profile] (profasm,profthreaded) simplCore/should_compile T5550 [exit code non-0] (profasm) th TH_StaticPointers [bad stdout or stderr] (ghci) typecheck/should_run T3500a [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) typecheck/should_run T3500a [bad stdout or stderr] (ghci) typecheck/should_run T5751 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) typecheck/should_run T5751 [bad stdout or stderr] (ghci) typecheck/should_run T7126 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) typecheck/should_run T7126 [bad stdout or stderr] (ghci) typecheck/should_run tcrun045 [stderr mismatch] (normal) Unexpected stat failures: perf/compiler T1969 [stat not good enough] (normal) perf/compiler T5642 [stat not good enough] (normal) perf/compiler T783 [stat not good enough] (normal) perf/compiler T9675 [stat not good enough] (optasm) perf/should_run T9203 [stat too good] (normal) simplCore/should_compile T7702 [stat too good] (profasm) }}} and a {{{validate}} leads to a couple of regressions: {{{ OVERALL SUMMARY for test run started at Tue Jan 13 22:36:23 2015 GMT 0:05:53 spent to go through 4393 total tests, which gave rise to 14198 test cases, of which 10151 were skipped 52 had missing libraries 3920 expected passes 71 expected failures 0 caused framework failures 0 unexpected passes 3 unexpected failures 1 unexpected stat failures Unexpected failures: cabal/sigcabal01 sigcabal01 [bad stderr] (normal) driver/retc001 retc001 [bad stderr] (normal) ghci.debugger/scripts print021 [bad exit code] (ghci) Unexpected stat failures: perf/compiler T9675 [stat not good enough] (optasm) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 14 07:33:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Jan 2015 07:33:38 -0000 Subject: [GHC] #4426: Simplify the rules for implicit quantification In-Reply-To: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> References: <046.cc2650d075f9bec123108fe76360a0e2@haskell.org> Message-ID: <061.087f4bb3553d7b54643f746948a8c77e@haskell.org> #4426: Simplify the rules for implicit quantification -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: highest | Milestone: 7.12.1 Component: Compiler | Version: 6.12.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #7880 | Blocking: | Differential Revisions: Phab:D211 -------------------------------------+------------------------------------- Changes (by liyang): * cc: ghc.haskell.org@? (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 14 08:08:34 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Jan 2015 08:08:34 -0000 Subject: [GHC] #9984: Show, Read, Eq, Ord instances for Control.Applicative.Const Message-ID: <047.7a7db28e5b833e16fdee3e82a3a1513d@haskell.org> #9984: Show, Read, Eq, Ord instances for Control.Applicative.Const -------------------------------------+------------------------------------- Reporter: fumieval | Owner: Type: feature | Status: new request | Milestone: Priority: low | Version: 7.8.4 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: | -------------------------------------+------------------------------------- As mentioned in https://www.haskell.org/pipermail/libraries/2013-October/021531.html, the following instances can be derived clearly: * `Show a => Show (Const a b)` * `Read a => Read (Const a b)` * `Eq a => Eq (Const a b)` * `Ord a => Ord (Const a b)` The absence of these instances makes debugging harder. I suggest handcrafted Show/Read instances for neat representation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 14 09:18:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Jan 2015 09:18:15 -0000 Subject: [GHC] #9971: GHC 7.10 dies with "out of memory" In-Reply-To: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> References: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> Message-ID: <062.cc0c7cd3ccb53c0fba6c9c950c53d015@haskell.org> #9971: GHC 7.10 dies with "out of memory" -------------------------------------+------------------------------------- Reporter: albertov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Comment (by albertov): I've just attached a simple project that reproduces the bug. The module is essentially this: {{{ {-# LANGUAGE TemplateHaskell , MultiParamTypeClasses , TypeFamilies #-} module Demo9971 where import qualified Data.Vector.Unboxed as U import Data.Vector.Unboxed.Deriving (derivingUnbox) type Vertex v = v Double newtype Point v = Point {_pVertex:: Vertex v} class U.Unbox (Vertex v) => VectorSpace v where derivingUnbox "Point" [t| VectorSpace v => Point v -> Vertex v |] [| \(Point v) -> v |] [| \v -> Point v|] }}} To reproduce just create a sandbox, install dependencies and build. GHC will begin to consume all memory until it is killed when building `Demo9971.hs` -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 14 09:40:36 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Jan 2015 09:40:36 -0000 Subject: [GHC] #9985: GHC panic with ViewPatterns and GADTs in a proc pattern Message-ID: <046.07950479d3070a5d4d8ef6d54073760e@haskell.org> #9985: GHC panic with ViewPatterns and GADTs in a proc pattern -------------------------------------+------------------------------------- Reporter: Rafbill | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The following code causes a ghc panic with versions 7.8.4 and 7.9. {{{#!hs module A where {-# LANGUAGE GADTs, ViewPatterns, PatternSynonyms, DataKinds, Arrows, TypeOperators, TypeFamilies, UndecidableInstances #-} import Control.Arrow data Nat = Z | S Nat data Vec n a where VNil :: Vec Z a VCons :: a -> Vec n a -> Vec (S n) a viewVNil :: Vec Z a -> () viewVNil VNil = () viewVCons :: Vec (S n) a -> (a, Vec n a) viewVCons (VCons a as) = (a, as) pattern (:>) :: a -> Vec n a -> Vec (S n) a pattern a :> as <- (viewVCons -> (a, as)) pattern VNil' <- (viewVNil -> ()) type family n + m where n + Z = n n + S m = S (n + m) type family P2 n where P2 Z = S Z P2 (S n) = P2 n + P2 n class A n where a :: Arrow b => b (Vec (P2 n) a) a instance A Z where a = proc (a :> VNil) -> returnA -< a }}} If the pattern (a :> VNil) is changed to (a :> _) or (a :> VNil'), the code compiles. GADTs pattern are not allowed to appear in proc patterns, but view patterns seems to be able to bypass this restriction, #9953, and the check on subpatterns. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 14 09:42:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Jan 2015 09:42:00 -0000 Subject: [GHC] #9984: Show, Read, Eq, Ord instances for Control.Applicative.Const In-Reply-To: <047.7a7db28e5b833e16fdee3e82a3a1513d@haskell.org> References: <047.7a7db28e5b833e16fdee3e82a3a1513d@haskell.org> Message-ID: <062.f159d11ef958bda99273ba38a60d56c6@haskell.org> #9984: Show, Read, Eq, Ord instances for Control.Applicative.Const -------------------------------------+------------------------------------- Reporter: fumieval | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: libraries/base | 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 ekmett): We determined in response to a similar earlier ticket that such instances should just be added where they are obvious and can be added unambiguously, so I don't see any issue at all with adding these. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 14 10:29:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Jan 2015 10:29:17 -0000 Subject: [GHC] #9984: Show, Read, Eq, Ord instances for Control.Applicative.Const In-Reply-To: <047.7a7db28e5b833e16fdee3e82a3a1513d@haskell.org> References: <047.7a7db28e5b833e16fdee3e82a3a1513d@haskell.org> Message-ID: <062.b23d23b10df2712c79e75b13bd9db78c@haskell.org> #9984: Show, Read, Eq, Ord instances for Control.Applicative.Const -------------------------------------+------------------------------------- Reporter: fumieval | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: libraries/base | 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 hvr): fumieval, I'd either need a patch w/ your proper email-address (including a real-name) otherwise we can't properly attribute the patch to you... You can use either `git format-patch -1` for that or, if you want, you can also submit the patch to our wiki:Phabricator instance. Edward, is this GHC 7.10.1 material? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 14 10:32:46 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Jan 2015 10:32:46 -0000 Subject: [GHC] #9890: RTS -qa option is helpful but under-documented In-Reply-To: <049.126a2e59b04d15cfa71935d2118594d3@haskell.org> References: <049.126a2e59b04d15cfa71935d2118594d3@haskell.org> Message-ID: <064.242ab0dc931d6ea8aee7fb3fb443d2b8@haskell.org> #9890: RTS -qa option is helpful but under-documented -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: simonmar Type: task | Status: merge Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 14 11:50:56 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Jan 2015 11:50:56 -0000 Subject: [GHC] #9984: Show, Read, Eq, Ord instances for Control.Applicative.Const In-Reply-To: <047.7a7db28e5b833e16fdee3e82a3a1513d@haskell.org> References: <047.7a7db28e5b833e16fdee3e82a3a1513d@haskell.org> Message-ID: <062.9bd61073f2c1e56aee9bb3c04605d0a0@haskell.org> #9984: Show, Read, Eq, Ord instances for Control.Applicative.Const -------------------------------------+------------------------------------- Reporter: fumieval | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: libraries/base | 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 fumieval): I apologize for my clumsiness. I've just uploaded an appropriate one. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 14 12:45:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Jan 2015 12:45:27 -0000 Subject: [GHC] #9984: Show, Read, Eq, Ord instances for Control.Applicative.Const In-Reply-To: <047.7a7db28e5b833e16fdee3e82a3a1513d@haskell.org> References: <047.7a7db28e5b833e16fdee3e82a3a1513d@haskell.org> Message-ID: <062.ca56e87b8072f4314aa4722edca6e249@haskell.org> #9984: Show, Read, Eq, Ord instances for Control.Applicative.Const -------------------------------------+------------------------------------- Reporter: fumieval | Owner: Type: feature request | Status: patch Priority: low | Milestone: 7.10.1 Component: libraries/base | 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: Phab:D619 -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch * differential: => Phab:D619 * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 14 13:09:01 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Jan 2015 13:09:01 -0000 Subject: [GHC] #9986: lhs -> hs fallout Message-ID: <048.e784fa1ea545a332610bea9ec0b7617f@haskell.org> #9986: lhs -> hs fallout -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: | Version: 7.9 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It looks that during .lhs -> .hs switch the comments were not updated. Grepping for ".lhs" reveals 117 lines where .lhs files are referenced: {{{ basicTypes/OccName.hs:154:-- see also: Note [Data Constructor Naming] in DataCon.lhs basicTypes/BasicTypes.hs:447:-- instance. See Note [Safe Haskell isSafeOverlap] (in `InstEnv.lhs`) for a basicTypes/BasicTypes.hs:874: Note [Expanding variables] in Rules.lhs. basicTypes/Id.hs:579:-- See Note [Specialisations and RULES in IdInfo] in IdInfo.lhs basicTypes/Id.hs:689: -- Another good example is in fill_in in PrelPack.lhs. We should be able to basicTypes/DataCon.hs:407: -- See also Note [Data-con worker strictness] in MkId.lhs basicTypes/MkId.hs:1194: See DsUtils.lhs Note [Desugaring seq (1)] and (2) and (3) basicTypes/Var.hs:340:-- Ids, because Id.lhs uses 'mkGlobalId' etc with different types basicTypes/IdInfo.hs:423:-- CafInfo is used to build Static Reference Tables (see simplStg/SRT.lhs). cmm/CmmBuildInfoTables.hs:201:-- Adapted from simpleStg/SRT.lhs, which expects Id's. cmm/cmm-notes:98:SMRep.lhs cmm/cmm-notes:123:CodeGen.lhs cmm/cmm-notes:124:CgBindery.lhs cmm/cmm-notes:126:CgCase.lhs cmm/cmm-notes:127:CgClosure.lhs cmm/cmm-notes:128:CgCon.lhs cmm/cmm-notes:129:CgExpr.lhs cmm/cmm-notes:130:CgLetNoEscape.lhs cmm/cmm-notes:132:CgHeapery.lhs cmm/cmm-notes:135:CgMonad.lhs cmm/cmm-notes:139:CgStackery.lhs cmm/cmm-notes:140:CgTailCall.lhs cmm/cmm-notes:143:ClosureInfo.lhs codeGen/StgCmmBind.hs:744: -- CgConTbls.lhs with a description generated from the data constructor codeGen/StgCmmExpr.hs:704:-- stgSyn/CoreToStg.lhs). Consider this: coreSyn/CorePrep.hs:111:9. Replace (lazy e) by e. See Note [lazyId magic] in MkId.lhs coreSyn/CoreUtils.hs:803:~~~~~~~~~~~~~~~~~~ in CoreUnfold.lhs coreSyn/CoreSyn.hs:245:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs coreSyn/CoreSyn.hs:268:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs coreSyn/CoreSyn.hs:274:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs coreSyn/CoreSyn.hs:289:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs coreSyn/CoreSyn.hs:438:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs coreSyn/CoreSyn.hs:764: -- See Note [Extra args in rule matching] in Rules.lhs coreSyn/CoreSyn.hs:921: -- (see MkId.lhs, calls to mkCompulsoryUnfolding). coreSyn/CoreSyn.hs:1100:-- See Note [Expanding variables] in Rules.lhs coreSyn/CoreSyn.hs:1256:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs coreSyn/CoreSyn.hs:1445:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs coreSyn/CoreArity.hs:612:See Note [Dictionary-like types] in TcType.lhs for why we use coreSyn/CoreFVs.hs:294: -- See Note [Finding rule RHS free vars] in OccAnal.lhs coreSyn/CoreFVs.hs:393:-- This actually happened in the defn of errorIO in IOBase.lhs: deSugar/DsExpr.hs:479: T (recConErr t1 "M.lhs/230/op1") deSugar/DsExpr.hs:481: (recConErr t1 "M.lhs/230/op3") deSugar/DsExpr.hs:486: M.lhs, line 230: missing field op1 was evaluated deSugar/DsExpr.hs:531: other -> recUpdError "M.lhs/230" deSugar/DsForeign.hs:673: -- codeGen/CodeGen.lhs; however, stginit functions have a negative impact deSugar/Check.hs:56: @Match.lhs@ to generate code) deSugar/Check.hs:631:tidy_eqn does more or less the same thing as @tidy@ in @Match.lhs@; ghci/ByteCodeGen.hs:1157: -- the DataCon. See DataCon.lhs for details. ghci/Linker.hs:1109: -- compiler/ghci/Linker.lhs + rts/Linker.c link the ghc.mk:243:# Generate supporting stuff for prelude/PrimOp.lhs hsSyn/HsDecls.hs:371: (DefMeth is defined in Class.lhs) hsSyn/Convert.hs:884: -- Convert.lhs, hence panic iface/IfaceType.hs:467:-- See equivalent function in TypeRep.lhs iface/LoadIface.hs:197: -- compiling Float.lhs, which mentions Float of course main/HscMain.hs:356: -- - filter out the .hs/.lhs source filename if we have one main/TidyPgm.hs:1266: -- split (see Note [Worker-wrapper for bottoming functions] in WorkWrap.lhs main/GHC.hs:1182:{- ToDo: Move the primary logic here to compiler/main/Packages.lhs main/DriverPhases.hs:52: literate pre-processor | .lhs | - | - main/Finder.hs:307:-- not a reexport (this invariant is upheld by @Packages.lhs@) and (2) main/DriverPipeline.hs:827: -- libraries/hpc/tests/function/subdir/tough2.lhs main/DriverPipeline.hs:1687: -- compiler/nativeGen/AsmCodeGen.lhs for another instance main/HscTypes.hs:1066: -- See Note [Overall plumbing for rules] in Rules.lhs main/HscTypes.hs:2704:This stuff is in here, rather than (say) in Linker.lhs, because the Linker.lhs nativeGen/PPC/CodeGen.hs:893: nonvolatile registers differs (see MachRegs.lhs). nativeGen/PIC.hs:748:-- (See PprMach.lhs) nativeGen/RegAlloc/Graph/TrivColorable.hs:73:32% of total compile time and 42% of total alloc when compiling SHA1.lhs from darcs. nativeGen/RegAlloc/Graph/TrivColorable.hs:81:the most efficient variant tried. Benchmark compiling 10-times SHA1.lhs follows. parser/cutils.h:9:// Out-of-line string functions, see PrimPacked.lhs prelude/TysPrim.hs:333:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs prelude/TysPrim.hs:531:defined in \tr{TysWiredIn.lhs}, not here. prelude/PrimOp.hs:188:is done with plain ccalls now (see PrelNumExtra.lhs). prelude/PrimOp.hs:486:@primOpIsCheap@, as used in \tr{SimplUtils.lhs}. For now (HACK prelude/PrelRules.hs:1006: -- See Note [Integer division constant folding] in libraries/base/GHC/Real.lhs prelude/PrelRules.hs:1137:-- See Note [magicDictId magic] in `basicTypes/MkId.lhs` rename/RnPat.hs:238: -- before going on to the RHSes (see RnSource.lhs). rename/RnEnv.hs:1374: -- See Note [Binders in Template Haskell] in Convert.lhs rename/RnExpr.hs:316:wired-in. See the Note about the NameSorts in Name.lhs. simplCore/SimplUtils.hs:1491: poly_id = transferPolyIdInfo var tvs_here $ -- Note [transferPolyIdInfo] in Id.lhs simplCore/SimplUtils.hs:1624:was like this (base/Foreign/C/Err/Error.lhs): simplCore/OccurAnal.hs:286:recursive functions] in Simplify.lhs simplCore/FloatIn.hs:86:SetLevels.lhs module, which tags things with their level numbers. simplCore/SetLevels.hs:830: -- See Note [Computing one-shot info] in Demand.lhs simplCore/SetLevels.hs:1053: mk_poly_bndr bndr uniq = transferPolyIdInfo bndr abs_vars $ -- Note [transferPolyIdInfo] in Id.lhs simplCore/SimplCore.hs:299: -- Reason: see Note [Shadowing] in SpecConstr.lhs simplCore/SimplCore.hs:634: -- See Note [Overall plumbing for rules] in Rules.lhs simplCore/Simplify.hs:55:the simplifier is in SimplCore.lhs. simplCore/Simplify.hs:2161: -- See Note [Data-con worker strictness] in MkId.lhs simplCore/Simplify.hs:2630:The Ord instance of Maybe in PrelMaybe.lhs, for example, took several extra simplStg/UnariseStg.hs:66: where -- See Note [Nullary unboxed tuple] in Type.lhs specialise/SpecConstr.hs:1839: -- See Note [Matching lets] in Rule.lhs specialise/SpecConstr.hs:1845:{- Disabled; see Note [Matching cases] in Rule.lhs stgSyn/CoreToStg.hs:92:-- constructing SRTs (see SRT.lhs). stgSyn/CoreToStg.hs:444: -- See Note [Nullary unboxed tuple] in Type.lhs stranal/DmdAnal.hs:1089:-- See Note [Trimming a demand to a type] in Demand.lhs typecheck/TcForeign.hs:137: -- See Note [Expanding newtypes] in TyCon.lhs typecheck/FamInst.hs:327:-- in FamInstEnv.lhs typecheck/TcExpr.hs:1321:Note [Converting strings] in Convert.lhs typecheck/TcType.hs:259:It's knot-tied back to Var.lhs. There is no reason in principle typecheck/TcType.hs:260:why Var.lhs shouldn't actually have the definition, but it "belongs" here. typecheck/TcEvidence.hs:138: [TcCoercion] -- See [CoAxiom Index] in Coercion.lhs typecheck/TcPat.hs:679:As explained by [Wrappers for data instance tycons] in MkIds.lhs, the typecheck/TcInteract.hs:1524:To achieve this required some refactoring of FunDeps.lhs (nicer typecheck/TcTyClsDecls.hs:1490: -- See Note [GADT record selectors] in MkId.lhs types/Kind.hs:218:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs types/Kind.hs:234:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs types/CoAxiom.hs:231:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs types/TyCon.hs:162:See also Note [Wrappers for data instance tycons] in MkId.lhs types/TyCon.hs:349:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs types/TypeRep.hs:98:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs types/Coercion.hs:126:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs types/Coercion.hs:203:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs types/Coercion.hs:945:-- of Coercion and the Note [Refl invariant] in types/TypeRep.lhs. types/Type.hs:606:interfaces. Notably this plays a role in tcTySigs in TcBinds.lhs. types/Type.hs:819:-- See Note [GHC Formalism] in coreSyn/CoreLint.lhs types/Type.hs:1324:-- See Note [Kind Constraint and kind *] in Kinds.lhs types/Unify.hs:235:-- thing to do. C.f. Note [Matching variable types] in Rules.lhs utils/Binary.hs:476:-- yes, we need Binary Integer and Binary Rational in basicTypes/Literal.lhs }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 14 14:00:56 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Jan 2015 14:00:56 -0000 Subject: [GHC] #9890: RTS -qa option is helpful but under-documented In-Reply-To: <049.126a2e59b04d15cfa71935d2118594d3@haskell.org> References: <049.126a2e59b04d15cfa71935d2118594d3@haskell.org> Message-ID: <064.6114d5233abd5bce62e970650a27036c@haskell.org> #9890: RTS -qa option is helpful but under-documented -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: simonmar Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * status: merge => closed * resolution: => fixed Comment: merged to 7.10 with bb56695b98b20d0e28a30b360265e2b147cc2f24 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 14 15:26:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Jan 2015 15:26:24 -0000 Subject: [GHC] #9986: lhs -> hs fallout In-Reply-To: <048.e784fa1ea545a332610bea9ec0b7617f@haskell.org> References: <048.e784fa1ea545a332610bea9ec0b7617f@haskell.org> Message-ID: <063.539a54b729bcd7e52898d1ed0199e7c8@haskell.org> #9986: lhs -> hs fallout -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Documentation | 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: -------------------------------------+------------------------------------- Comment (by simonpj): Excellent thanks. Might anyone make a patch? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 14 15:32:10 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Jan 2015 15:32:10 -0000 Subject: [GHC] #9985: GHC panic with ViewPatterns and GADTs in a proc pattern In-Reply-To: <046.07950479d3070a5d4d8ef6d54073760e@haskell.org> References: <046.07950479d3070a5d4d8ef6d54073760e@haskell.org> Message-ID: <061.caf160b61fa047ee3a4f45c89ac5f08f@haskell.org> #9985: GHC panic with ViewPatterns and GADTs in a proc pattern -------------------------------------+------------------------------------- Reporter: Rafbill | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * cc: ross (added) Comment: Ross, any views? Other open tickets on arrows are #7828, #5267, #5777, #5333, #344. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 14 15:44:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Jan 2015 15:44:59 -0000 Subject: [GHC] #9981: Potential typechecker regression in GHC 7.10.1RC In-Reply-To: <042.c047cab9d166b1747ff4913537189070@haskell.org> References: <042.c047cab9d166b1747ff4913537189070@haskell.org> Message-ID: <057.9e1715aeb8690e50bb378afadb195fe2@haskell.org> #9981: Potential typechecker regression in GHC 7.10.1RC -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.10.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: | -------------------------------------+------------------------------------- Comment (by hvr): ...so ... is this a regression or an improvement? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 14 16:08:29 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Jan 2015 16:08:29 -0000 Subject: [GHC] #5821: SPECIALISE fails with a cryptic warning In-Reply-To: <041.0c42da3432a831cfdfec52f79b870abb@haskell.org> References: <041.0c42da3432a831cfdfec52f79b870abb@haskell.org> Message-ID: <056.eeb76fc72b2aa41d0ab59caf4cb1629a@haskell.org> #5821: SPECIALISE fails with a cryptic warning -------------------------------------+------------------------------------- Reporter: rl | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.5 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: Phab:D610 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"788413297eaddfa259d2ab76459a916a62d2604c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="788413297eaddfa259d2ab76459a916a62d2604c" Refactor handling of SPECIALISE pragmas (Trac #5821) The provoking cause was Trac #5821, which concerned type families, but in fixing it I did the usual round of tidying up and docmenting. The main comment is now Note [Handling SPECIALISE pragmas] in TcBinds. It is "wrinkle 2" that fixes #5821. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 14 16:44:06 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Jan 2015 16:44:06 -0000 Subject: [GHC] #9984: Show, Read, Eq, Ord instances for Control.Applicative.Const In-Reply-To: <047.7a7db28e5b833e16fdee3e82a3a1513d@haskell.org> References: <047.7a7db28e5b833e16fdee3e82a3a1513d@haskell.org> Message-ID: <062.2d5e5392eb9e3773543185e9ac547492@haskell.org> #9984: Show, Read, Eq, Ord instances for Control.Applicative.Const -------------------------------------+------------------------------------- Reporter: fumieval | Owner: Type: feature request | Status: patch Priority: low | Milestone: 7.10.1 Component: libraries/base | 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: Phab:D619 -------------------------------------+------------------------------------- Comment (by ekmett): I'd have no objection to including it in 7.10.1. The fact that these instances are missing is actually rather surprising to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 14 17:11:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Jan 2015 17:11:16 -0000 Subject: [GHC] #5908: Issues with RebindableSyntax In-Reply-To: <050.fd8d444d8850dc174295eaf061b6ddf3@haskell.org> References: <050.fd8d444d8850dc174295eaf061b6ddf3@haskell.org> Message-ID: <065.c71a8ad02a3b21c729255d08c5583428@haskell.org> #5908: Issues with RebindableSyntax ----------------------------------------------+---------------------------- Reporter: scooty-puff | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.1 Component: Compiler | Version: 7.0.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects valid program | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | rebindable/T5821 | Blocking: ----------------------------------------------+---------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c823b73cb2ca8e2392e2a4c48286879cc7baa51c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c823b73cb2ca8e2392e2a4c48286879cc7baa51c" Test Trac #5821 And rename the wrongly named rebindable/T5821 to T5908 (Trac #5908) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 14 17:11:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Jan 2015 17:11:16 -0000 Subject: [GHC] #5821: SPECIALISE fails with a cryptic warning In-Reply-To: <041.0c42da3432a831cfdfec52f79b870abb@haskell.org> References: <041.0c42da3432a831cfdfec52f79b870abb@haskell.org> Message-ID: <056.f5ac3769e28a93b4db2626314ef9b341@haskell.org> #5821: SPECIALISE fails with a cryptic warning -------------------------------------+------------------------------------- Reporter: rl | Owner: ezyang Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.5 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: Phab:D610 -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"c823b73cb2ca8e2392e2a4c48286879cc7baa51c/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c823b73cb2ca8e2392e2a4c48286879cc7baa51c" Test Trac #5821 And rename the wrongly named rebindable/T5821 to T5908 (Trac #5908) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 14 17:11:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Jan 2015 17:11:42 -0000 Subject: [GHC] #5908: Issues with RebindableSyntax In-Reply-To: <050.fd8d444d8850dc174295eaf061b6ddf3@haskell.org> References: <050.fd8d444d8850dc174295eaf061b6ddf3@haskell.org> Message-ID: <065.9473c5a1e096d31e03357a15d6872ea8@haskell.org> #5908: Issues with RebindableSyntax -------------------------------------+------------------------------------- Reporter: scooty-puff | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.6.1 Component: Compiler | Version: 7.0.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | rebindable/T5908 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * testcase: rebindable/T5821 => rebindable/T5908 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 14 17:12:27 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Jan 2015 17:12:27 -0000 Subject: [GHC] #5821: SPECIALISE fails with a cryptic warning In-Reply-To: <041.0c42da3432a831cfdfec52f79b870abb@haskell.org> References: <041.0c42da3432a831cfdfec52f79b870abb@haskell.org> Message-ID: <056.937582ffaa76d7d361f7c2783212a984@haskell.org> #5821: SPECIALISE fails with a cryptic warning -------------------------------------+------------------------------------- Reporter: rl | Owner: ezyang Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.5 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect | Unknown/Multiple warning at compile-time | Test Case: Blocked By: | simplCore/should_compile/T5821 Related Tickets: | Blocking: | Differential Revisions: Phab:D610 -------------------------------------+------------------------------------- Changes (by simonpj): * status: patch => closed * testcase: => simplCore/should_compile/T5821 * resolution: => fixed Comment: Right, I've fixed this properly now. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 14 19:50:53 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Jan 2015 19:50:53 -0000 Subject: [GHC] #9984: Show, Read, Eq, Ord instances for Control.Applicative.Const In-Reply-To: <047.7a7db28e5b833e16fdee3e82a3a1513d@haskell.org> References: <047.7a7db28e5b833e16fdee3e82a3a1513d@haskell.org> Message-ID: <062.a04791489e3c96e23224bd32c128e5d7@haskell.org> #9984: Show, Read, Eq, Ord instances for Control.Applicative.Const -------------------------------------+------------------------------------- Reporter: fumieval | Owner: Type: feature request | Status: patch Priority: low | Milestone: 7.10.1 Component: libraries/base | 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: Phab:D619 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"c71fb84b8c9ec9c1e279df8c75ceb8a537801aa1/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c71fb84b8c9ec9c1e279df8c75ceb8a537801aa1" Add Eq, Ord, Show, and Read instances for Const As suggested in https://www.haskell.org/pipermail/libraries/2013-October/021531.html this adds the following instances - `Show a => Show (Const a b)` - `Read a => Read (Const a b)` - `Eq a => Eq (Const a b)` - `Ord a => Ord (Const a b)` The Read/Show instances are defined in such a way as if `Const` was defined without record-syntax (i.e. as `newtype Const a b = Const a`) Addresses #9984 Reviewed By: ekmett Differential Revision: https://phabricator.haskell.org/D619 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 14 20:05:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Jan 2015 20:05:42 -0000 Subject: [GHC] #9984: Show, Read, Eq, Ord instances for Control.Applicative.Const In-Reply-To: <047.7a7db28e5b833e16fdee3e82a3a1513d@haskell.org> References: <047.7a7db28e5b833e16fdee3e82a3a1513d@haskell.org> Message-ID: <062.5c2f4f5b82cf134cb5c5517e9e7bf0e9@haskell.org> #9984: Show, Read, Eq, Ord instances for Control.Applicative.Const -------------------------------------+------------------------------------- Reporter: fumieval | Owner: Type: feature request | Status: closed Priority: low | Milestone: 7.10.1 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: Phab:D619 -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => closed * resolution: => fixed Comment: also applied to 7.10 with [aaca7bdf/ghc] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 14 20:10:19 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Jan 2015 20:10:19 -0000 Subject: [GHC] #9981: Potential typechecker regression in GHC 7.10.1RC In-Reply-To: <042.c047cab9d166b1747ff4913537189070@haskell.org> References: <042.c047cab9d166b1747ff4913537189070@haskell.org> Message-ID: <057.d3b1a292d492aedc824e9b0d730e4979@haskell.org> #9981: Potential typechecker regression in GHC 7.10.1RC -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.10.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: | -------------------------------------+------------------------------------- Comment (by ekmett): It seems to me that `flip` shouldn't work there because it requires binding a polytype to a variable. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 14 21:04:58 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Jan 2015 21:04:58 -0000 Subject: [GHC] #9389: Full Test Suite Failures In-Reply-To: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> References: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> Message-ID: <057.88c0fbc7f306266f8b7579abb65540b5@haskell.org> #9389: Full Test Suite Failures -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: #9286,#8756,#7876,#7877 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jrp): And here are some more detailed diagnostics from the {{{perf}}} BuildFlavour {{{ =====> sigcabal01(normal) 95 of 4394 [0, 0, 0] cd ./cabal/sigcabal01 && $MAKE -s --no-print-directory sigcabal01 CLEANUP=1 sigcabal01.run.stdout 2>sigcabal01.run.stderr Actual stderr output differs from expected: --- ./cabal/sigcabal01/sigcabal01.stderr 2014-12-03 23:14:05.000000000 +0000 +++ ./cabal/sigcabal01/sigcabal01.run.stderr 2015-01-14 20:45:55.000000000 +0000 @@ -1,2 +1,4 @@ Setup: Missing signature implementations for these modules: Map +/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/libHSp_LUw0YzhH9mm7VMqZOQq5o8.a-51161/libHSp_LUw0YzhH9mm7VMqZOQq5o8.a(Map.o) has no symbols +/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ranlib: file: dist/build/libHSp_HXXcYbYUHJg90CX6clNHdD.a-51218/libHSp_HXXcYbYUHJg90CX6clNHdD.a(Map.o) has no symbols Main: Prelude.undefined *** unexpected failure for sigcabal01(normal) }}} (retc001 and print021 pass today) {{{ =====> topHandler01(ghci) 4165 of 4394 [0, 0, 0] cd ../../libraries/base/tests && '/Volumes/LaCie/Users/jrp/Projects/haskell/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-warn-tabs -fno-ghci-history topHandler01.hs --interactive -v0 -ignore-dot-ghci +RTS -I0.1 -RTS topHandler01.interp.stdout 2>topHandler01.interp.stderr Actual stderr output differs from expected: --- /dev/null 2015-01-14 20:55:02.000000000 +0000 +++ ../../libraries/base/tests/topHandler01.run.stderr 2015-01-14 20:55:07.000000000 +0000 @@ -0,0 +1 @@ +Interrupted. *** unexpected failure for topHandler01(ghci) =====> topHandler01(threaded1) 4165 of 4394 [0, 1, 0] cd ../../libraries/base/tests && '/Volumes/LaCie/Users/jrp/Projects/haskell/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-warn-tabs -fno-ghci-history -o topHandler01 topHandler01.hs -threaded -debug >topHandler01.comp.stderr 2>&1 cd ../../libraries/base/tests && ./topHandler01 topHandler01.run.stdout 2>topHandler01.run.stderr Wrong exit code (expected 0 , actual 130 ) Stdout: Success: caught UserInterrupt Stderr: *** unexpected failure for topHandler01(threaded1) =====> topHandler01(threaded2) 4165 of 4394 [0, 2, 0] cd ../../libraries/base/tests && '/Volumes/LaCie/Users/jrp/Projects/haskell/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-warn-tabs -fno-ghci-history -o topHandler01 topHandler01.hs -O -threaded -eventlog >topHandler01.comp.stderr 2>&1 cd ../../libraries/base/tests && ./topHandler01 +RTS -N2 -ls -RTS topHandler01.run.stdout 2>topHandler01.run.stderr Wrong exit code (expected 0 , actual 130 ) Stdout: Success: caught UserInterrupt Stderr: *** unexpected failure for topHandler01(threaded2) }}} {{{ =====> T7126(normal) 4061 of 4394 [0, 0, 0] cd ./typecheck/should_run && '/Volumes/LaCie/Users/jrp/Projects/haskell/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-warn-tabs -fno-ghci-history -o T7126 T7126.hs >T7126.comp.stderr 2>&1 Compile failed (status 256) errors were: [1 of 1] Compiling Main ( T7126.hs, T7126.o ) T7126.hs:27:10: Could not deduce (Class1 a) arising from the superclasses of an instance declaration from the context: Class3 a bound by the instance declaration at T7126.hs:27:10-29 Possible fix: add (Class1 a) to the context of the instance declaration In the instance declaration for ?Class2 a? *** unexpected failure for T7126(normal) }}} {{{ =====> T5751(normal) 4063 of 4394 [0, 0, 0] cd ./typecheck/should_run && '/Volumes/LaCie/Users/jrp/Projects/haskell/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-warn-tabs -fno-ghci-history -o T5751 T5751.hs >T5751.comp.stderr 2>&1 Compile failed (status 256) errors were: T5751.hs:1:79: Warning: -XOverlappingInstances is deprecated: instead use per-instance pragmas OVERLAPPING/OVERLAPPABLE/OVERLAPS [1 of 1] Compiling Main ( T5751.hs, T5751.o ) T5751.hs:28:10: Could not deduce (XMLGenerator m) arising from the superclasses of an instance declaration from the context: MonadRender m bound by the instance declaration at T5751.hs:28:10-35 Possible fix: add (XMLGenerator m) to the context of the instance declaration In the instance declaration for ?Widgets m? *** unexpected failure for T5751(normal) }}} {{{ =====> T3500a(normal) 4052 of 4394 [0, 0, 0] cd ./typecheck/should_run && '/Volumes/LaCie/Users/jrp/Projects/haskell/ghc/inplace/bin/ghc-stage2' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user-package- db -rtsopts -fno-warn-tabs -fno-ghci-history -o T3500a T3500a.hs >T3500a.comp.stderr 2>&1 Compile failed (status 256) errors were: [1 of 1] Compiling Main ( T3500a.hs, T3500a.o ) T3500a.hs:11:10: Constraint is no smaller than the instance head in the constraint: C (F a) (Use UndecidableInstances to permit this) In the instance declaration for ?C (a, b)? *** unexpected failure for T3500a(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 14 22:48:37 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 14 Jan 2015 22:48:37 -0000 Subject: [GHC] #9987: GHC refuses to compile a file that starts with a Byte Order Mark (BOM) Message-ID: <047.e7f60a33859d3c90bb19400309efd40e@haskell.org> #9987: GHC refuses to compile a file that starts with a Byte Order Mark (BOM) -------------------------------------+------------------------------------- Reporter: Henk-Jan | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Windows Architecture: | Type of failure: GHC rejects Unknown/Multiple | valid program Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Trying to compile a file that starts with a Byte Order Mark (BOM) results in the message like: Camels.hs:1:1: lexical error at character '\65279' No compilation is done. Note that, if a file is saved as UTF-8, Notepad adds this BOM to the beginning of the file. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 15 06:46:12 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Jan 2015 06:46:12 -0000 Subject: [GHC] #9988: Remove fun_id, is_infix from FunBind, as they are now in Match Message-ID: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> #9988: Remove fun_id, is_infix from FunBind, as they are now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- One of the changes Phab:D538 introduced is to add m_fun_id_infix to Match {{{#!hs data Match id body = Match { m_fun_id_infix :: (Maybe (Located id,Bool)), -- fun_id and fun_infix for functions with multiple equations -- only present for a RdrName. See note [fun_id in Match] m_pats :: [LPat id], -- The patterns m_type :: (Maybe (LHsType id)), -- A type signature for the result of the match -- Nothing after typechecking m_grhss :: (GRHSs id body) } deriving (Typeable) }}} This was done to track the individual locations and fixity of the fun_id for each of the defining equations for a function when there are more than one. For example, the function (&&&) is defined with some prefix and some infix equations below. {{{#!hs (&&& ) [] [] = [] xs &&& [] = xs ( &&& ) [] ys = ys }}} This means that the fun_id / is_infix is now superfluous in the FunBind. This has not been removed as a potentially risky change just before 7.10 RC2, and so must be done after. This ticket captures that task. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 15 06:48:05 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Jan 2015 06:48:05 -0000 Subject: [GHC] #9988: Remove fun_id, is_infix from FunBind, as they are now in Match In-Reply-To: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> References: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> Message-ID: <059.af23a1862892772267f3e65741843227@haskell.org> #9988: Remove fun_id, is_infix from FunBind, as they are now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 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 alanz): * owner: => alanz -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 15 06:48:07 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Jan 2015 06:48:07 -0000 Subject: [GHC] #9987: GHC refuses to compile a file that starts with a Byte Order Mark (BOM) In-Reply-To: <047.e7f60a33859d3c90bb19400309efd40e@haskell.org> References: <047.e7f60a33859d3c90bb19400309efd40e@haskell.org> Message-ID: <062.c2980107f218a6e515d4684516bdedec@haskell.org> #9987: GHC refuses to compile a file that starts with a Byte Order Mark (BOM) -------------------------------------+------------------------------------- Reporter: Henk-Jan | Owner: Type: feature request | Status: new Priority: high | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * type: bug => feature request Comment: This is definitely not a bug on GHC's part, but rather on Notepad's. BOMs cause many problems when used in UTF8 and are highly discouraged, so it should come to no surprise that GHC complains about it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 15 06:52:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Jan 2015 06:52:24 -0000 Subject: [GHC] #9987: GHC refuses to compile a file that starts with a Byte Order Mark (BOM) In-Reply-To: <047.e7f60a33859d3c90bb19400309efd40e@haskell.org> References: <047.e7f60a33859d3c90bb19400309efd40e@haskell.org> Message-ID: <062.dde11c282bda58f42db545a258e88677@haskell.org> #9987: GHC refuses to compile a file that starts with a Byte Order Mark (BOM) -------------------------------------+------------------------------------- Reporter: Henk-Jan | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * priority: high => low -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 15 07:28:26 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Jan 2015 07:28:26 -0000 Subject: [GHC] #9988: Remove fun_id, is_infix from FunBind, as they are now in Match In-Reply-To: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> References: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> Message-ID: <059.22b3af9f0b834338e6ec0e1d264b0b55@haskell.org> #9988: Remove fun_id, is_infix from FunBind, as they are now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 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 alanz: Old description: > One of the changes Phab:D538 introduced is to add m_fun_id_infix to Match > > {{{#!hs > data Match id body > = Match { > m_fun_id_infix :: (Maybe (Located id,Bool)), > -- fun_id and fun_infix for functions with multiple equations > -- only present for a RdrName. See note [fun_id in Match] > m_pats :: [LPat id], -- The patterns > m_type :: (Maybe (LHsType id)), > -- A type signature for the result of > the match > -- Nothing after typechecking > m_grhss :: (GRHSs id body) > } deriving (Typeable) > }}} > > This was done to track the individual locations and fixity of the fun_id > for each of the defining equations for a function when there are more > than one. > > For example, the function (&&&) is defined with some prefix and some > infix equations below. > > {{{#!hs > > (&&& ) [] [] = [] > xs &&& [] = xs > ( &&& ) [] ys = ys > }}} > > This means that the fun_id / is_infix is now superfluous in the FunBind. > This has not been removed as a potentially risky change just before 7.10 > RC2, and so must be done after. > > This ticket captures that task. New description: One of the changes Phab:D538 introduced is to add m_fun_id_infix to Match {{{#!hs data Match id body = Match { m_fun_id_infix :: (Maybe (Located id,Bool)), -- fun_id and fun_infix for functions with multiple equations -- only present for a RdrName. See note [fun_id in Match] m_pats :: [LPat id], -- The patterns m_type :: (Maybe (LHsType id)), -- A type signature for the result of the match -- Nothing after typechecking m_grhss :: (GRHSs id body) } deriving (Typeable) }}} This was done to track the individual locations and fixity of the fun_id for each of the defining equations for a function when there are more than one. For example, the function (&&&) is defined with some prefix and some infix equations below. {{{#!hs (&&& ) [] [] = [] xs &&& [] = xs ( &&& ) [] ys = ys }}} This means that the fun_id / is_infix is now superfluous in the FunBind. This has not been removed as a potentially risky change just before 7.10 RC2, and so must be done after. This ticket captures that task, which includes processing these fields through the renamer and beyond. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From jan.stolarek at p.lodz.pl Thu Jan 15 08:45:47 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Thu, 15 Jan 2015 09:45:47 +0100 Subject: Ping Message-ID: <201501150945.47438.jan.stolarek@p.lodz.pl> Just pinging the list to see if it still exists From ghc-devs at haskell.org Thu Jan 15 13:45:14 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Jan 2015 13:45:14 -0000 Subject: [GHC] #9213: Maybe important CPP warnings on ghcautoconf.h from cpphs In-Reply-To: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> References: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> Message-ID: <057.c6489de17c58fa2025476896b5debcce@haskell.org> #9213: Maybe important CPP warnings on ghcautoconf.h from cpphs -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 15 14:17:43 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Jan 2015 14:17:43 -0000 Subject: [GHC] #9988: Remove fun_id, is_infix from FunBind, as they are now in Match In-Reply-To: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> References: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> Message-ID: <059.84015891fa56b903df028741c27d7da8@haskell.org> #9988: Remove fun_id, is_infix from FunBind, as they are now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 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): Actually I'm not sure it'd be a good idea to remove it. It's quite convenient to have the function name in the `FunBind`. But I think we '''can''' (and should) remove `fun_infix` from `FunBind`. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 15 15:36:27 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Jan 2015 15:36:27 -0000 Subject: [GHC] #9989: GHCI is slow for precompiled code Message-ID: <046.94b9207f80786e5d4d2d3451b686df6a@haskell.org> #9989: GHCI is slow for precompiled code -------------------------------------+------------------------------------- Reporter: remdezx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Keywords: | Operating System: Linux Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Hello! We found that loading compiled and optimised `accelerate` code into ghci works much much slower than code run directly. (I'm marking it as a ghc-api bug, because I noticed this behavior while using it) Here is the example: {{{#!hs module Main where import Data.Array.Accelerate as A import Data.Array.Accelerate.CUDA as C import Data.Time.Clock (diffUTCTime, getCurrentTime) main :: IO () main = do start <- getCurrentTime print $ C.run $ A.maximum $ A.map (+1) $ A.use (fromList (Z:.1000000) [1..1000000] :: Vector Double) end <- getCurrentTime print $ diffUTCTime end start }}} When I compile it and run $ ghc -O2 Main.hs -threaded [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... $ ./Main Array (Z) [1000001.0] 0.162204s It takes `0.16 s` to finish When I compile it and load into ghci: $ ghc -O2 -dynamic -c Main.hs $ ghci 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. Prelude> :l Main Ok, modules loaded: Main. Prelude Main> main Loading package transformers-0.3.0.0 ... linking ... done. 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 binary-0.7.1.0 ... linking ... done. Loading package pretty-1.1.1.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 unix-2.7.0.1 ... linking ... done. Loading package directory-1.2.1.0 ... linking ... done. Loading package process-1.2.0.0 ... linking ... done. Loading package stm-2.4.4 ... linking ... done. Loading package SafeSemaphore-0.10.1 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package fclabels-2.0.2.2 ... linking ... done. Loading package text-1.1.1.3 ... linking ... done. Loading package hashable-1.2.3.1 ... linking ... done. Loading package primitive-0.5.4.0 ... linking ... done. Loading package vector-0.10.12.2 ... linking ... done. Loading package hashtables-1.2.0.1 ... linking ... done. Loading package unordered-containers-0.2.5.1 ... linking ... done. Loading package accelerate-0.15.0.0 ... linking ... done. Loading package byteable-0.1.1 ... linking ... done. Loading package cryptohash-0.11.6 ... linking ... done. Loading package cuda-0.6.5.1 ... linking ... done. Loading package exception-transformers-0.3.0.4 ... linking ... done. Loading package exception-mtl-0.3.0.5 ... linking ... done. Loading package old-time-1.1.0.2 ... linking ... done. Loading package polyparse-1.11 ... linking ... done. Loading package cpphs-1.18.6 ... linking ... done. Loading package haskell-src-exts-1.16.0.1 ... linking ... done. Loading package syb-0.4.4 ... linking ... done. Loading package th-lift-0.7 ... linking ... done. Loading package safe-0.3.8 ... linking ... done. Loading package th-expand-syns-0.3.0.4 ... linking ... done. Loading package th-reify-many-0.1.2 ... linking ... done. Loading package th-orphans-0.8.3 ... linking ... done. Loading package haskell-src-meta-0.6.0.8 ... linking ... done. Loading package srcloc-0.4.1 ... linking ... done. Loading package mainland-pretty-0.2.7 ... linking ... done. Loading package symbol-0.2.4 ... linking ... done. Loading package language-c-quote-0.8.0 ... linking ... done. Loading package accelerate-cuda-0.15.0.0 ... linking ... done. Array (Z) [1000001.0] 0.256128s It takes `0.26 s` to finish. On other computer, using `criterion`, we observed even a `50x` difference. Why is it working so slow, isn't ghci just to load function and simply call it? Here is how execution time changes for different matrix sizes. For comparison we have also measured time of interpreted code (without precompiling). {{{ size | compiled | precompiled | interpreted ---------+-----------+--------------+------------ 100 | 0.054076s | 0.082686s | 0.151857s 1000 | 0.054509s | 0.08305s | 0.135452s 10000 | 0.055405s | 0.08469s | 0.12632s 100000 | 0.057768s | 0.093011s | 0.155359s 1000000 | 0.089811s | 0.251359s | 0.202022s 10000000 | 0.397642s | 1.400603s | 0.898547s }}} We believe that problem lies on the side of `ghci` rather than `accelerate`, how could we confirm this? Moreover and even more important is there any workaround for it, if we need this precompiled code running fast in production environment? Any guidance will be appreciated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 15 21:15:47 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 15 Jan 2015 21:15:47 -0000 Subject: [GHC] #9990: Top level module identifiers shadow imported identifiers Message-ID: <045.c11e3cc3f47fed8ec0b130c48936b6a9@haskell.org> #9990: Top level module identifiers shadow imported identifiers -------------------------------------+------------------------------------- Reporter: drb226 | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Let's try this out as a language pragma and see if we like it? Artificial example: {{{#!hs {-# LANGUAGE TopLevelShadowsImports #-} import Data.Monoid (<>) = mappend main = putStrLn ("Hello" <> " " <> "World") }}} Current behavior: error: ambiguous occurrence of (<>) Desired behavior: uses top-level definition of (<>), prints "hello world" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 00:27:01 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 00:27:01 -0000 Subject: [GHC] #9991: runghc shows the value produced by main when its type is a non-() Show instance Message-ID: <046.b9f38b4c270b0f9b3352ad5f26fb4a6f@haskell.org> #9991: runghc shows the value produced by main when its type is a non-() Show instance -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When running a program like this: {{{#!hs main :: IO Int main = return 5 }}} With `runghc`, it'll print a value, which is contrary to expected behavior and to compiled program behavior: {{{ $ runghc Main.hs 5 $ ghc Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... $ ./Main $ }}} This is the same as `ghci`'s behavior with an IO action, so presumably `runghc` is taking a shortcut here. But a program should behave the same way in both cases. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 00:27:35 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 00:27:35 -0000 Subject: [GHC] #9992: Constructor specialization requires eta expansion Message-ID: <046.7d51856d1ca88f0c21c0c3b5ed5c7fc3@haskell.org> #9992: Constructor specialization requires eta expansion -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple performance | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I recently encountered a slightly tricky performance issue[1] in `bytestring`'s `Builder` implementation which required explicit eta expansion in order for GHC to perform ConstrSpec. We have {{{#!hs data BufferRange = BufferRange {-# UNPACK #-} !(Ptr Word8) -- First byte of range {-# UNPACK #-} !(Ptr Word8) -- First byte /after/ range data BuildSignal a = ... -- Just a vanilla ADT type BuildStep a = BufferRange -> IO (BuildSignal a) }}} We end up with Core (full version https://gist.github.com/bgamari/091e3dac9c45ee9accf1#file-slow-hs-L1) that looks like this, {{{#!hs Main.$wa :: GHC.Prim.Word# -> GHC.Prim.Int# -> forall r_aKUt. Data.ByteString.Builder.Internal.BuildStep r_aKUt -> Data.ByteString.Builder.Internal.BuildStep r_aKUt Main.$wa = \ (ww_s10YU :: GHC.Prim.Word#) (ww1_s10YY :: GHC.Prim.Int#) (@ r_aKUt) (w_s10YR :: Data.ByteString.Builder.Internal.BuildStep r_aKUt) -> case ww1_s10YY of wild_XE { __DEFAULT -> ( \ (eta1_X1Q :: Data.ByteString.Builder.Internal.BufferRange) -> case eta1_X1Q of BufferRange a b -> -- A bunch of code eventually ending in a recursive call to $wa ) 0 -> w_s10YR } }}} If `w_s10YR` is eta-expanded GHC will run ConstrSpec, eliminating the fields of `BufferRange` to be unpacked between iterations of `$wa` and substantially improving performance. In [1] we had to manually eta-expand the empty case to ensure that this would happen. It would be great if GHC would identify cases like this. [1] https://github.com/haskell/bytestring/pull/40 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 00:34:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 00:34:27 -0000 Subject: [GHC] #9993: PostfixOperators doesn't work for types Message-ID: <046.c7aa45b49c7f5a6d1b339ea2f860b5ae@haskell.org> #9993: PostfixOperators doesn't work for types -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- `PostfixOperators` is a useful extension on the value level that defines `(x OP)` to mean `((OP) x)` for an infix operator `OP`, rather than `(\y -> (OP) x y)`. This could be even more useful on the type level, where lambdas are unavailable (so sections don't exist at all) but postfix operators could still exist. This is already a common pseudocode idiom in some cases, e.g. `(r ->)` instead of `((->) r)`. Is there a particular syntactic reason to disallow it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 00:47:06 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 00:47:06 -0000 Subject: [GHC] #9994: Provide option to show current module in ghci prompt without listing imported modules. Message-ID: <046.e91d33e47164959a7e2636f93ef934a2@haskell.org> #9994: Provide option to show current module in ghci prompt without listing imported modules. -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: GHCi | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- GHCi allows for `%s` in the prompt, which is replaced by the currently loaded module followed by all imported modules. However, my `.ghci` imports about a hundred modules, making the prompt way too long when I use `%s`. It would be useful to have an option for showing just the current module, and not all the imported modules. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 01:05:06 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 01:05:06 -0000 Subject: [GHC] #9995: :info enhancements Message-ID: <046.2fdc2e62d570cea4f69a1c002298abe9@haskell.org> #9995: :info enhancements -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: GHCi | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- `:info` is a very useful ghci command, but there are several improvements that could be made: * It would be useful if `:i` showed not only which module a name is defined in, but which module(s) it was imported from in the current session. * A variant of `:i` that just prints a definition, rather than a definition and all instances, would be useful in many cases. E.g. `:i Show` prints the definition of `Show`, but then it prints so many instances that the definition is scrolled way off the screen. * `:i ->` is a parse error; it should behave like `:i (->)`, the way it works for other type-level operators. * hvr had some more suggestions: "finding out which package a module belongs to", "and what module an 'as'-alias is associated with". (Currently I think modules are out of `:info`'s scope, but perhaps it would be a useful addition.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 01:23:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 01:23:05 -0000 Subject: [GHC] #9996: Support symbols in GHCi tab completion Message-ID: <046.22bb07e462ddbba0f2716d525f66f3af@haskell.org> #9996: Support symbols in GHCi tab completion -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: GHCi | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Right now, when typing e.g. `>` followed by two tabs, GHCi shows every name in scope rather than just names beginning with `>`. It even lists operators as possible completions, but ignores it when you type the beginning of an operator's name. It would be better if it could actually complete every option it shows as a possible completion. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 08:52:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 08:52:07 -0000 Subject: [GHC] #9992: Constructor specialization requires eta expansion In-Reply-To: <046.7d51856d1ca88f0c21c0c3b5ed5c7fc3@haskell.org> References: <046.7d51856d1ca88f0c21c0c3b5ed5c7fc3@haskell.org> Message-ID: <061.05acc21e50bc49a8682e25fedb50f075@haskell.org> #9992: Constructor specialization requires eta expansion -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: Runtime | Architecture: performance bug | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by tibbe): * cc: tibbe (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 08:56:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 08:56:25 -0000 Subject: [GHC] #9993: PostfixOperators doesn't work for types In-Reply-To: <046.c7aa45b49c7f5a6d1b339ea2f860b5ae@haskell.org> References: <046.c7aa45b49c7f5a6d1b339ea2f860b5ae@haskell.org> Message-ID: <061.30ecfe5ca0bd4a24def5262c246cd7dd@haskell.org> #9993: PostfixOperators doesn't work for types -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Sounds reasonable to me, if someone wants to have a go at messing with the parser. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 09:07:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 09:07:05 -0000 Subject: [GHC] #9995: :info enhancements In-Reply-To: <046.2fdc2e62d570cea4f69a1c002298abe9@haskell.org> References: <046.2fdc2e62d570cea4f69a1c002298abe9@haskell.org> Message-ID: <061.4fb4d3ea26419d9f5ed189f8ddc1fe5c@haskell.org> #9995: :info enhancements -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | 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: -------------------------------------+------------------------------------- Old description: > `:info` is a very useful ghci command, but there are several improvements > that could be made: > > * It would be useful if `:i` showed not only which module a name is > defined in, but which module(s) it was imported from in the current > session. > * A variant of `:i` that just prints a definition, rather than a > definition and all instances, would be useful in many cases. E.g. `:i > Show` prints the definition of `Show`, but then it prints so many > instances that the definition is scrolled way off the screen. > * `:i ->` is a parse error; it should behave like `:i (->)`, the way it > works for other type-level operators. > * hvr had some more suggestions: "finding out which package a module > belongs to", "and what module an 'as'-alias is associated with". > (Currently I think modules are out of `:info`'s scope, but perhaps it > would be a useful addition.) New description: `:info` is a very useful ghci command, but there are several improvements that could be made: 1. It would be useful if `:i` showed not only which module a name is defined in, but which module(s) it was imported from in the current session. 2. A variant of `:i` that just prints a definition, rather than a definition and all instances, would be useful in many cases. E.g. `:i Show` prints the definition of `Show`, but then it prints so many instances that the definition is scrolled way off the screen. 3. `:i ->` is a parse error; it should behave like `:i (->)`, the way it works for other type-level operators. 4. hvr had some more suggestions: "finding out which package a module belongs to", "and what module an 'as'-alias is associated with". (Currently I think modules are out of `:info`'s scope, but perhaps it would be a useful addition.) -- Comment (by simonpj): Sounds good to me. 1. I think this is pretty easy; this info is kept in the `GlobalRdrEnv`. Someone would have to figure out what to say if something was in scope in several different ways. 2. Even easier; but now you have to specify what the user should say to get the two different behaviours. Perhaps `:info` for the terse behaviour and `:info!` to add the instances? (Though that would be a change.) Oh, now I look I see that `:info!` is already used for something to do with instances. So maybe `:info`, `:info!`, and `:info!!`? Or we could drop instances altogether from `:info`, and instead have a new command `:instances T`. 3. Sounds plausible. "Just" a parser issue. 4. This is really `:info` for ''modules'', isn't it? So perhaps it's a variant of `:browse` (which tells you stuff about modules)? Anyway, if anyone wants to work on the specification, get agreement, and work on implementation, I can advise. Nothing technically difficult here I think. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 12:31:16 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 12:31:16 -0000 Subject: [GHC] #9992: Constructor specialization requires eta expansion In-Reply-To: <046.7d51856d1ca88f0c21c0c3b5ed5c7fc3@haskell.org> References: <046.7d51856d1ca88f0c21c0c3b5ed5c7fc3@haskell.org> Message-ID: <061.e7f07760ddc73d718abb06e4581f7c55@haskell.org> #9992: Constructor specialization requires eta expansion -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: Runtime | Architecture: performance bug | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Ah, very interesting. I'll investigate -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 12:56:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 12:56:05 -0000 Subject: [GHC] #9997: "A module cannot import itself"-regression Message-ID: <042.eedf75d34d2e0795db14860994a31b1b@haskell.org> #9997: "A module cannot import itself"-regression -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Keywords: regression | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following module could be compiled with GHC 7.8.4 and older, but fails with GHC 7.10: {{{#!hs {-# LANGUAGE PackageImports #-} module Control.DeepSeq where import "deepseq" Control.DeepSeq }}} {{{ $ ghci -Wall DeepSeq.hs GHCi, version 7.10.0.20141227: http://www.haskell.org/ghc/ :? for help [1 of 1] Compiling Control.DeepSeq ( DeepSeq.hs, interpreted ) DeepSeq.hs:5:1: A module cannot import itself: Control.DeepSeq Failed, modules loaded: none. ?:2> }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 13:00:19 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 13:00:19 -0000 Subject: [GHC] #9990: Top level module identifiers shadow imported identifiers In-Reply-To: <045.c11e3cc3f47fed8ec0b130c48936b6a9@haskell.org> References: <045.c11e3cc3f47fed8ec0b130c48936b6a9@haskell.org> Message-ID: <060.2e619372529698887d248df81cfdc2a8@haskell.org> #9990: Top level module identifiers shadow imported identifiers -------------------------------------+------------------------------------- Reporter: drb226 | 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: -------------------------------------+------------------------------------- Comment (by hvr): Even when such a pragma is active, I'd expect the shadow-warnings to be emitted -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 13:05:38 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 13:05:38 -0000 Subject: [GHC] #9997: "A module cannot import itself"-regression In-Reply-To: <042.eedf75d34d2e0795db14860994a31b1b@haskell.org> References: <042.eedf75d34d2e0795db14860994a31b1b@haskell.org> Message-ID: <057.62cb99f1e5b74a386ee3b229cbe10b18@haskell.org> #9997: "A module cannot import itself"-regression -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: regression 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: => simonpj Comment: This seems to be an unintended side-effect of edd233acc19d269385c1a870829e0916a3df8e88 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 13:05:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 13:05:59 -0000 Subject: [GHC] #9997: "A module cannot import itself"-regression In-Reply-To: <042.eedf75d34d2e0795db14860994a31b1b@haskell.org> References: <042.eedf75d34d2e0795db14860994a31b1b@haskell.org> Message-ID: <057.9f2ca746d220d5ba553aabad97f53513@haskell.org> #9997: "A module cannot import itself"-regression -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9032 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * related: => #9032 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 13:20:44 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 13:20:44 -0000 Subject: [GHC] #9998: GHC binary package seems to be corrupt Message-ID: <055.8a47209bfa8688095052fa4ce47eb579@haskell.org> #9998: GHC binary package seems to be corrupt -------------------------------------+------------------------------------- Reporter: | Owner: mark_christiaens | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Package | Operating System: Linux system | Type of failure: Installing GHC Keywords: | failed Architecture: x86_64 | Blocked By: (amd64) | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Installed https://www.haskell.org/ghc/dist/7.8.4/ghc-7.8.4-x86_64-unknown- linux-deb7.tar.bz2 Did ghc-pkg check Got: ghc-pkg check There are problems in package haskell-src-exts-1.16.0.1: Warning: library-dirs: /home/developer/.cabal/lib/x86_64-linux-ghc-7.8.4 /haskell-src-exts-1.16.0.1 doesn't exist or isn't a directory Warning: haddock-interfaces: /home/developer/.cabal/share/doc/x86_64 -linux-ghc-7.8.4/haskell-src-exts-1.16.0.1/html/haskell-src-exts.haddock doesn't exist or isn't a file Warning: haddock-html: /home/developer/.cabal/share/doc/x86_64-linux- ghc-7.8.4/haskell-src-exts-1.16.0.1/html doesn't exist or isn't a directory import-dirs: /home/developer/.cabal/lib/x86_64-linux-ghc-7.8.4/haskell- src-exts-1.16.0.1 doesn't exist or isn't a directory cannot find any of ["Language/Haskell/Exts.hi","Language/Haskell/Exts.p_hi","Language/Haskell/Exts.dyn_hi"] cannot find any of ["Language/Haskell/Exts/Lexer.hi","Language/Haskell/Exts/Lexer.p_hi","Language/Haskell/Exts/Lexer.dyn_hi"] cannot find any of ["Language/Haskell/Exts/Parser.hi","Language/Haskell/Exts/Parser.p_hi","Language/Haskell/Exts/Parser.dyn_hi"] cannot find any of ["Language/Haskell/Exts/Pretty.hi","Language/Haskell/Exts/Pretty.p_hi","Language/Haskell/Exts/Pretty.dyn_hi"] cannot find any of ["Language/Haskell/Exts/Syntax.hi","Language/Haskell/Exts/Syntax.p_hi","Language/Haskell/Exts/Syntax.dyn_hi"] cannot find any of ["Language/Haskell/Exts/Extension.hi","Language/Haskell/Exts/Extension.p_hi","Language/Haskell/Exts/Extension.dyn_hi"] cannot find any of ["Language/Haskell/Exts/Build.hi","Language/Haskell/Exts/Build.p_hi","Language/Haskell/Exts/Build.dyn_hi"] cannot find any of ["Language/Haskell/Exts/Fixity.hi","Language/Haskell/Exts/Fixity.p_hi","Language/Haskell/Exts/Fixity.dyn_hi"] cannot find any of ["Language/Haskell/Exts/Comments.hi","Language/Haskell/Exts/Comments.p_hi","Language/Haskell/Exts/Comments.dyn_hi"] cannot find any of ["Language/Haskell/Exts/SrcLoc.hi","Language/Haskell/Exts/SrcLoc.p_hi","Language/Haskell/Exts/SrcLoc.dyn_hi"] cannot find any of ["Language/Haskell/Exts/Annotated.hi","Language/Haskell/Exts/Annotated.p_hi","Language/Haskell/Exts/Annotated.dyn_hi"] cannot find any of ["Language/Haskell/Exts/Annotated/Syntax.hi","Language/Haskell/Exts/Annotated/Syntax.p_hi","Language/Haskell/Exts/Annotated/Syntax.dyn_hi"] cannot find any of ["Language/Haskell/Exts/Annotated/Fixity.hi","Language/Haskell/Exts/Annotated/Fixity.p_hi","Language/Haskell/Exts/Annotated/Fixity.dyn_hi"] cannot find any of ["Language/Haskell/Exts/Annotated/Build.hi","Language/Haskell/Exts/Annotated/Build.p_hi","Language/Haskell/Exts/Annotated/Build.dyn_hi"] cannot find any of ["Language/Haskell/Exts/Annotated/ExactPrint.hi","Language/Haskell/Exts/Annotated/ExactPrint.p_hi","Language/Haskell/Exts/Annotated/ExactPrint.dyn_hi"] cannot find any of ["Language/Haskell/Exts/Annotated/Simplify.hi","Language/Haskell/Exts/Annotated/Simplify.p_hi","Language/Haskell/Exts/Annotated/Simplify.dyn_hi"] cannot find any of ["Language/Haskell/Exts/ExtScheme.hi","Language/Haskell/Exts/ExtScheme.p_hi","Language/Haskell/Exts/ExtScheme.dyn_hi"] cannot find any of ["Language/Haskell/Exts/ParseMonad.hi","Language/Haskell/Exts/ParseMonad.p_hi","Language/Haskell/Exts/ParseMonad.dyn_hi"] cannot find any of ["Language/Haskell/Exts/ParseSyntax.hi","Language/Haskell/Exts/ParseSyntax.p_hi","Language/Haskell/Exts/ParseSyntax.dyn_hi"] cannot find any of ["Language/Haskell/Exts/InternalLexer.hi","Language/Haskell/Exts/InternalLexer.p_hi","Language/Haskell/Exts/InternalLexer.dyn_hi"] cannot find any of ["Language/Haskell/Exts/ParseUtils.hi","Language/Haskell/Exts/ParseUtils.p_hi","Language/Haskell/Exts/ParseUtils.dyn_hi"] cannot find any of ["Language/Haskell/Exts/InternalParser.hi","Language/Haskell/Exts/InternalParser.p_hi","Language/Haskell/Exts/InternalParser.dyn_hi"] cannot find any of ["libHShaskell-src-exts-1.16.0.1.a","libHShaskell- src-exts-1.16.0.1.p_a","libHShaskell-src-exts-1.16.0.1-ghc7.8.4.so ","libHShaskell-src-exts-1.16.0.1-ghc7.8.4.dylib","HShaskell-src- exts-1.16.0.1-ghc7.8.4.dll"] on library path There are problems in package aeson-0.8.0.2: Warning: library-dirs: /home/developer/.cabal/lib/x86_64-linux- ghc-7.8.4/aeson-0.8.0.2 doesn't exist or isn't a directory ... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 14:17:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 14:17:30 -0000 Subject: [GHC] #9997: "A module cannot import itself"-regression In-Reply-To: <042.eedf75d34d2e0795db14860994a31b1b@haskell.org> References: <042.eedf75d34d2e0795db14860994a31b1b@haskell.org> Message-ID: <057.4f57d4becbec495524171ef8398dc79d@haskell.org> #9997: "A module cannot import itself"-regression -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9032 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"fb7c311711c8851d0de1e40231150ad999ae9c2b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fb7c311711c8851d0de1e40231150ad999ae9c2b" Repsect the package name when checking for self-import Fixes Trac #9997. In doing this I tripped across the specialness of "this" in PackageImports. The magic constant (fsLit "this") is scattered across the compiler and ought to be put in one place. But where? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 14:17:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 14:17:30 -0000 Subject: [GHC] #9971: GHC 7.10 dies with "out of memory" In-Reply-To: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> References: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> Message-ID: <062.f1388a2a93e97477e484350d75e7203f@haskell.org> #9971: GHC 7.10 dies with "out of memory" -------------------------------------+------------------------------------- Reporter: albertov | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | 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: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"854e7b8efdd7fe5fcba77e1e049e8a835f03b16a/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="854e7b8efdd7fe5fcba77e1e049e8a835f03b16a" Fix a terrible bug in the canonicaliser which led to an infinite loop This fixes Trac #9971 Merge into the 7.10 branch }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 14:33:05 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 14:33:05 -0000 Subject: [GHC] #9213: Maybe important CPP warnings on ghcautoconf.h from cpphs In-Reply-To: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> References: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> Message-ID: <057.3f946226b3ac28f6559eb031dd3eda6a@haskell.org> #9213: Maybe important CPP warnings on ghcautoconf.h from cpphs -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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 asr): A minimal example (using cpp 1.18.6 and GHC 7.10.1 RC1): {{{ $ cat Main.hs {-# LANGUAGE CPP #-} module Main where -- Used for example by Alex 3.1.4 and GHC source code. #include "ghcconfig.h" main :: IO () main = putStrLn "Hello, World!" }}} {{{ $ ghc -pgmP cpphs -optP --cpp Main.hs ... Warning: trailing characters after #if directive in file /usr/local/stow/ghc-7.10.0.20141222-bin/lib/ghc-7.10.0.20141222/include/ghcautoconf.h at line 379 col 1: AC_APPLE_UNIVERSAL_BUILD }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 14:34:12 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 14:34:12 -0000 Subject: [GHC] #9987: GHC refuses to compile a file that starts with a Byte Order Mark (BOM) In-Reply-To: <047.e7f60a33859d3c90bb19400309efd40e@haskell.org> References: <047.e7f60a33859d3c90bb19400309efd40e@haskell.org> Message-ID: <062.8de84dd53134dc8083e88c5eb70cc5aa@haskell.org> #9987: GHC refuses to compile a file that starts with a Byte Order Mark (BOM) -------------------------------------+------------------------------------- Reporter: Henk-Jan | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Henk-Jan): When I remove the BOM by saving the file in ANSI coding (using Notepad), I get the following message from GHC: Camels.hs:152:56: lexical error in string/character literal (UTF-8 decoding error) This is because of an o-umlaut in the comments. The file can be found at: https://raw.githubusercontent.com/wxHaskell/wxHaskell/master/samples/contrib/Camels.hs (Geany states that the file is in CP1252 code and displays it correctly) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 15:11:52 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 15:11:52 -0000 Subject: [GHC] #9997: "A module cannot import itself"-regression In-Reply-To: <042.eedf75d34d2e0795db14860994a31b1b@haskell.org> References: <042.eedf75d34d2e0795db14860994a31b1b@haskell.org> Message-ID: <057.474bde51891d09dbf175b65670dd23a2@haskell.org> #9997: "A module cannot import itself"-regression -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: merge Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: regression Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9032 | module/T9997T | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => module/T9997T Comment: I believe I have fixed this. Merge to 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 15:12:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 15:12:59 -0000 Subject: [GHC] #9971: GHC 7.10 dies with "out of memory" In-Reply-To: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> References: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> Message-ID: <062.5b8074f39e12a70b5eb1c644d083825d@haskell.org> #9971: GHC 7.10 dies with "out of memory" -------------------------------------+------------------------------------- Reporter: albertov | Owner: Type: bug | Status: merge Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | typecheck/should_compile/T9971 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * priority: normal => highest * status: new => merge * testcase: => typecheck/should_compile/T9971 * milestone: => 7.10.1 Comment: A very fine bug thank you! Fixed. Merge to 7.10 branch Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 15:42:43 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 15:42:43 -0000 Subject: [GHC] #9997: "A module cannot import itself"-regression In-Reply-To: <042.eedf75d34d2e0795db14860994a31b1b@haskell.org> References: <042.eedf75d34d2e0795db14860994a31b1b@haskell.org> Message-ID: <057.cd68ad4505b85e8aba8d8c9c1c7c0f1c@haskell.org> #9997: "A module cannot import itself"-regression -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: fixed | Keywords: regression Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9032 | module/T9997 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * status: merge => closed * testcase: module/T9997T => module/T9997 * resolution: => fixed Comment: merged to ghc-7.10 with b5789dfc0720b1b67d3fdc3c9a77f19011a828d5 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 15:49:16 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 15:49:16 -0000 Subject: [GHC] #9998: GHC binary package seems to be corrupt In-Reply-To: <055.8a47209bfa8688095052fa4ce47eb579@haskell.org> References: <055.8a47209bfa8688095052fa4ce47eb579@haskell.org> Message-ID: <070.0e2afa28b7c6293ea8b3dfb5468ffc79@haskell.org> #9998: GHC binary package seems to be corrupt -------------------------------------+------------------------------------- Reporter: mark_christiaens | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Package system | Version: 7.8.4 Resolution: invalid | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Installing GHC | (amd64) failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by mark_christiaens): * status: new => closed * resolution: => invalid Comment: Was a case of file system corruption. Closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 15:54:56 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 15:54:56 -0000 Subject: [GHC] #9987: GHC refuses to compile a file that starts with a Byte Order Mark (BOM) In-Reply-To: <047.e7f60a33859d3c90bb19400309efd40e@haskell.org> References: <047.e7f60a33859d3c90bb19400309efd40e@haskell.org> Message-ID: <062.93cc9bd76384576134be203cb1469945@haskell.org> #9987: GHC refuses to compile a file that starts with a Byte Order Mark (BOM) -------------------------------------+------------------------------------- Reporter: Henk-Jan | Owner: Type: feature request | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): Currently, GHC's lexer assumes its input to be ASCII or UTF8 (for which a BOM is rather pointless -- as an UTF8 stream doesn't allow for different byteorders). The CP1252 (same with ISO-8859-1 btw) encoding, however, is only compatible for the lowest 128 code-points. I believe the usual recommendation is to use Notepad++ which allows to write UTF8 w/o that gratuitous BOM. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 16:14:47 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 16:14:47 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.4aa38a712da93fe063b30dddd1682d93@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | facundo.dominguez Priority: normal | Status: patch Component: Compiler | Milestone: 7.10.1 Resolution: | Version: 7.9 Operating System: Unknown/Multiple | Keywords: Type of failure: GHCi crash | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D586 | Phab:D587 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"fffbf0627c2c2ee4bc49f9d26a226b39a066945e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="fffbf0627c2c2ee4bc49f9d26a226b39a066945e" Trac #9878: Make the static form illegal in interpreted mode. Summary: The entries of the static pointers table are expected to exist as object code. Thus we have ghci complain with an intelligible error message if the static form is used in interpreted mode. It also includes a fix to keysHashTable in Hash.c which could cause a crash. The iteration of the hashtable internals was incorrect. This patch has the function keysHashTable imitate the iteration in freeHashTable. Finally, we submit here some minor edits to comments and GHC.StaticPtr.StaticPtrInfo field names. Authored-by: Alexander Vershilov Test Plan: ./validate Reviewers: simonpj, hvr, austin Reviewed By: austin Subscribers: carter, thomie, qnikst, mboes Differential Revision: https://phabricator.haskell.org/D586 GHC Trac Issues: #9878 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 16:37:12 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 16:37:12 -0000 Subject: [GHC] #9971: GHC 7.10 dies with "out of memory" In-Reply-To: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> References: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> Message-ID: <062.56a4baf29702b5b262220b79fa86d8fc@haskell.org> #9971: GHC 7.10 dies with "out of memory" -------------------------------------+------------------------------------- Reporter: albertov | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | typecheck/should_compile/T9971 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * status: merge => closed * resolution: => fixed Comment: merged to ghc-7.10 with c9ab42f84531f71056cfdf686cf548481b0af389 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 17:28:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 17:28:26 -0000 Subject: [GHC] #9999: Typeable deriving behavior different between data families and associated data types Message-ID: <046.44b8bb2c22fb6d02dbcfd1b37ce4a93e@haskell.org> #9999: Typeable deriving behavior different between data families and associated data types -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- With `AutoDeriveTypeable`, data families get a `Typeable` instance, but associated data types in a class don't (and even standalone deriving doesn't work for them). {{{ ?> data family Foo a ?> typeRep (Proxy :: Proxy Foo) Foo ?> class K a where { data Bar a } ?> typeRep (Proxy :: Proxy Bar) :6:1: No instance for (Typeable Bar) arising from a use of ?typeRep? In the expression: typeRep (Proxy :: Proxy Bar) In an equation for ?it?: it = typeRep (Proxy :: Proxy Bar) ?> deriving instance Typeable Bar :7:1: Can't make a derived instance of ?Typeable Bar?: Deriving Typeable is not allowed for family instances; derive Typeable for ?Bar? alone In the stand-alone deriving instance for ?Typeable Bar? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 17:28:53 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 17:28:53 -0000 Subject: [GHC] #10000: Derived DataKinds Typeable instance collision leads to SafeHaskell violation Message-ID: <046.120f07f07b9d942740b385414a81932e@haskell.org> #10000: Derived DataKinds Typeable instance collision leads to SafeHaskell violation -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The derived `Typeable` instances for a kind (with `DataKinds`) is equal to the instance of a type with the same name: {{{ ?> data T = T ?> typeRep (Proxy :: Proxy T) == typeRep (Proxy :: Proxy 'T) True }}} This can be used to violate `SafeHaskell` easily: {{{#!hs {-# LANGUAGE AutoDeriveTypeable, DataKinds, TypeFamilies, RankNTypes #-} module Unsafe where import Data.Typeable data T = T data family F p newtype instance F (Proxy T) = ID (forall a. a -> a) newtype instance F (Proxy 'T) = UC (forall a b. a -> b) uc :: a -> b uc = case cast (ID id) of Just (UC f) -> f }}} {{{ $ ghc -XSafe Unsafe.hs -e "uc 'a' :: Int" 97 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 17:31:32 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 17:31:32 -0000 Subject: [GHC] #9999: Typeable deriving behavior different between data families and associated data types In-Reply-To: <046.44b8bb2c22fb6d02dbcfd1b37ce4a93e@haskell.org> References: <046.44b8bb2c22fb6d02dbcfd1b37ce4a93e@haskell.org> Message-ID: <061.3ae56e7b6fe808c84bacea2d7090d7dd@haskell.org> #9999: Typeable deriving behavior different between data families and associated data types -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Milestone: 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): * cc: dreixel (added) Comment: Pedro, any comments? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 17:55:37 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 17:55:37 -0000 Subject: [GHC] #9971: GHC 7.10 dies with "out of memory" In-Reply-To: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> References: <047.9137db8388490c6feaa95adc377c8a14@haskell.org> Message-ID: <062.1047acb74eddfaaff47f366bc265c9e2@haskell.org> #9971: GHC 7.10 dies with "out of memory" -------------------------------------+------------------------------------- Reporter: albertov | Owner: Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | typecheck/should_compile/T9971 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by albertov): My library is building properly now with c9ab42f84531f71056cfdf686cf548481b0af389 (albeit with a handful of new warnings I'll proceed to fix) Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 18:52:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 18:52:02 -0000 Subject: [GHC] #10000: Derived DataKinds Typeable instance collision leads to SafeHaskell violation In-Reply-To: <046.120f07f07b9d942740b385414a81932e@haskell.org> References: <046.120f07f07b9d942740b385414a81932e@haskell.org> Message-ID: <061.adba50b51b897ac395f7c4e34f39574c@haskell.org> #10000: Derived DataKinds Typeable instance collision leads to SafeHaskell violation -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Milestone: 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 monoidal): Duplicate of #9858? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 18:55:55 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 18:55:55 -0000 Subject: [GHC] #10000: Derived DataKinds Typeable instance collision leads to SafeHaskell violation In-Reply-To: <046.120f07f07b9d942740b385414a81932e@haskell.org> References: <046.120f07f07b9d942740b385414a81932e@haskell.org> Message-ID: <061.8c4b508dac0c2b7defa69bc03afde643@haskell.org> #10000: Derived DataKinds Typeable instance collision leads to SafeHaskell violation -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by shachaf): * status: new => closed * resolution: => duplicate Comment: Looks like it. And I was so pleased about finding it, too. :-( -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 19:04:55 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 19:04:55 -0000 Subject: [GHC] #9858: Typeable instance for datatype and its promoted constructor is the same In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.42c66a8026c71fbad6a89acf498abaf9@haskell.org> #9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel 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: -------------------------------------+------------------------------------- Comment (by int-e): This bug means that lambdabot cannot enable {{{DataKinds}}} (see #10000 for how to implement {{{unsafeCoerce}}} using this.) I would really like to see this fixed in 7.10.1. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 19:10:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 19:10:27 -0000 Subject: [GHC] #9858: Typeable instance for datatype and its promoted constructor is the same In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.9ee9dc7d702b27c0bff1939324b989a7@haskell.org> #9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel 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: -------------------------------------+------------------------------------- Comment (by int-e): One way of fixing this would be to prepend a prime (or some other non- capital letter character) to {{{name_fs}}} in {{{TcGenDeriv.gen_Typeable_binds}}} if the given {{{tycon::TyCon}}} is a promoted data constructur. Is this sufficient or are there other ways in which having distinct type constructors with identical {{{tyConName}}} could cause the compiler to go wrong? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 19:16:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 19:16:58 -0000 Subject: [GHC] #9858: Typeable instance for datatype and its promoted constructor is the same In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.109be6004d1b4e8e19ab4bc36b14f725@haskell.org> #9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.10.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: -------------------------------------+------------------------------------- Changes (by int-e): * cc: int-e (added) * priority: normal => high * milestone: 7.12.1 => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 19:58:54 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 19:58:54 -0000 Subject: [GHC] #9858: Typeable instance for datatype and its promoted constructor is the same In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.e4e7b2e9b8ab25a5f616d80c52a1491c@haskell.org> #9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by dreixel): Replying to [comment:5 int-e]: > One way of fixing this would be to prepend a prime (or some other non- capital letter character) to {{{name_fs}}} in {{{TcGenDeriv.gen_Typeable_binds}}} if the given {{{tycon::TyCon}}} is a promoted data constructur. > > Is this sufficient (...) I believe so. It should be a really simple fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 22:40:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 22:40:26 -0000 Subject: [GHC] #9858: Typeable instance for datatype and its promoted constructor is the same In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.2ce23a7f50c037d8396d15e10c990037@haskell.org> #9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by simonpj): Pedro when do you think you might get to this? Thanks See also #10000 Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 16 22:41:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 16 Jan 2015 22:41:11 -0000 Subject: [GHC] #10000: Derived DataKinds Typeable instance collision leads to SafeHaskell violation In-Reply-To: <046.120f07f07b9d942740b385414a81932e@haskell.org> References: <046.120f07f07b9d942740b385414a81932e@haskell.org> Message-ID: <061.1012f01339b0aaa5ef34bc8bdff10c2d@haskell.org> #10000: Derived DataKinds Typeable instance collision leads to SafeHaskell violation -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: duplicate | 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): We've hit 10,000 tickets! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 17 01:04:04 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Jan 2015 01:04:04 -0000 Subject: [GHC] #9986: lhs -> hs fallout In-Reply-To: <048.e784fa1ea545a332610bea9ec0b7617f@haskell.org> References: <048.e784fa1ea545a332610bea9ec0b7617f@haskell.org> Message-ID: <063.180e329e8be24c74106ffca893af4691@haskell.org> #9986: lhs -> hs fallout -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | Status: patch Priority: normal | Milestone: Component: Documentation | 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: D621 -------------------------------------+------------------------------------- Changes (by rodlogic): * status: new => patch * differential: => D621 Comment: Patch can be found here: https://phabricator.haskell.org/D621 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 17 01:11:10 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Jan 2015 01:11:10 -0000 Subject: [GHC] #9858: Typeable instance for datatype and its promoted constructor is the same In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.7db039cfe6de7fcfd9a288a709e86321@haskell.org> #9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:7 dreixel]: > Replying to [comment:5 int-e]: > > One way of fixing this would be to prepend a prime (or some other non- capital letter character) to {{{name_fs}}} in {{{TcGenDeriv.gen_Typeable_binds}}} if the given {{{tycon::TyCon}}} is a promoted data constructur. > > > > Is this sufficient (...) > > I believe so. It should be a really simple fix. Nope, here is a version based simply on using different promoted kinds (that are not visible in the Typeable instance). Also works to modify Shachaf's unsafeCoerce from #10000. {{{ {-# LANGUAGE DataKinds #-} {-# LANGUAGE AutoDeriveTypeable #-} import Data.Typeable data A t = A main = print $ typeRep (Proxy :: Proxy (A :: Bool -> *)) == typeRep (Proxy :: Proxy (A :: Ordering -> *)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 17 01:12:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Jan 2015 01:12:01 -0000 Subject: [GHC] #9858: Typeable instance for datatype and its promoted constructor is the same In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.b032df324508127c2455cb20cde27b48@haskell.org> #9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.10.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: -------------------------------------+------------------------------------- Changes (by oerjan): * cc: oerjan (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 17 01:26:25 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Jan 2015 01:26:25 -0000 Subject: [GHC] #9858: Typeable instance for datatype and its promoted constructor is the same In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.458b61cd6a8b96204d5f19ca0cfb50be@haskell.org> #9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by oerjan): For what it's worth, they don't have to be promoted kinds, * and Constraint also work. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 17 08:37:29 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Jan 2015 08:37:29 -0000 Subject: [GHC] #10000: Derived DataKinds Typeable instance collision leads to SafeHaskell violation In-Reply-To: <046.120f07f07b9d942740b385414a81932e@haskell.org> References: <046.120f07f07b9d942740b385414a81932e@haskell.org> Message-ID: <061.8180e143405a99998949c4327dc1a511@haskell.org> #10000: Derived DataKinds Typeable instance collision leads to SafeHaskell violation -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: duplicate | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): Too bad this turned out to be a duplicate, I was hoping for #10000 to be a more memorable ticket :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 17 09:31:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Jan 2015 09:31:01 -0000 Subject: [GHC] #9858: Typeable instance for datatype and its promoted constructor is the same In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.cd2db6f627ce8ab9fff60ba47e28fa4c@haskell.org> #9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by dreixel): Replying to [comment:9 oerjan]: > Replying to [comment:7 dreixel]: > > Replying to [comment:5 int-e]: > > > One way of fixing this would be to prepend a prime (or some other non-capital letter character) to {{{name_fs}}} in {{{TcGenDeriv.gen_Typeable_binds}}} if the given {{{tycon::TyCon}}} is a promoted data constructur. > > > > > > Is this sufficient (...) > > > > I believe so. It should be a really simple fix. > > Nope, here is a version based simply on using different promoted kinds (that are not visible in the Typeable instance). Also works to modify Shachaf's unsafeCoerce from #10000. > > {{{ > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE AutoDeriveTypeable #-} > > import Data.Typeable > > data A t = A > > main = print $ typeRep (Proxy :: Proxy (A :: Bool -> *)) > == typeRep (Proxy :: Proxy (A :: Ordering -> *)) > > }}} I think this example highlights a different limitation of Typeable, along the lines of #7897. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 17 09:43:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Jan 2015 09:43:42 -0000 Subject: [GHC] #9858: Typeable instance for datatype and its promoted constructor is the same In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.15587d3b64d10246918c633c1837eb6d@haskell.org> #9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:12 dreixel]: > I think this example highlights a different limitation of Typeable, along the lines of #7897. But #7897 doesn't break Safe Haskell like these examples do. And I think there is a common feature of the ones here: Typeable breaks because a typerep doesn't include the kind of the type. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 17 13:47:13 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Jan 2015 13:47:13 -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.f2ab9f6ff63743084a43c4a63ed2c650@haskell.org> #9920: Segfault in arm binary with llvm 3.5 -------------------------------------+------------------------------- Reporter: erikd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: arm Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------- Changes (by juhpetersen): * cc: juhpetersen (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 17 20:44:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Jan 2015 20:44:15 -0000 Subject: [GHC] #8406: Invalid object in isRetainer() or Segfault In-Reply-To: <047.cda95cb1752355077595406288b06592@haskell.org> References: <047.cda95cb1752355077595406288b06592@haskell.org> Message-ID: <062.3ff1dffda42958fe20fde28a8180c93b@haskell.org> #8406: Invalid object in isRetainer() or Segfault -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Runtime System | Version: 7.8.3 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 JamesM): * status: closed => new * version: 7.6.3 => 7.8.3 * resolution: worksforme => Old description: > When compiling with > -rtsopts -threaded -prof -fprof-auto -caf-all > > and running with > -N4 -hr > > I get a "Segmentation fault" every time. > > If I run with -N4 -qg1 -hr, I either get a segfault or > internal error: Invalid object in isRetainer(): 40 > > When the segfault happens, it happens quickly. If the segfault doesn't > happen, the program runs for about 5 seconds and I get "invalid object" > error (always 40). > > Without -hr, I have never gotten a segfault. New description: When compiling with -rtsopts -threaded -prof -fprof-auto -caf-all and running with -N4 -hr I get a "Segmentation fault" every time. If I run with -N4 -qg1 -hr, I either get a segfault or internal error: Invalid object in isRetainer(): 40 When the segfault happens, it happens quickly. If the segfault doesn't happen, the program runs for about 5 seconds and I get "invalid object" error (always 40). Without -hr, I have never gotten a segfault. Edit (1/2015): This is still occurring under multiple threads in ghc 7.8.3. GHC options: -Wall -prof -fprof-auto -threaded -rtsopts Runtime Options: -N4 -hr -L1000 -- Comment: This is still occurring for me. However, it is only problematic when using multiple threads changing from -N4 to -N1 removes the issue: par-simulator: internal error: Invalid object in isRetainer(): 39 (GHC version 7.8.3 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Abort trap: 6 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 17 22:27:48 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Jan 2015 22:27:48 -0000 Subject: =?utf-8?b?UmU6IFtHSENdICM3ODcwOiBDb21waWxhdGlv4oCLbiBlcnJvcnMg?= =?utf-8?q?break_the_complexity_encapsulat=E2=80=8Bion_on_DSLs=2C?= =?utf-8?q?_impairs_success_in_industry?= In-Reply-To: <048.de52b4bfe321c3b82b9c52c180790492@haskell.org> References: <048.de52b4bfe321c3b82b9c52c180790492@haskell.org> Message-ID: <063.c94ce7d150c3eb5411e03bccb9c331a3@haskell.org> #7870: Compilatio?n errors break the complexity encapsulat?ion on DSLs, impairs success in industry -------------------------------------+------------------------------------- Reporter: agocorona | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.7 checker) | Keywords: DSL, Resolution: | Error, Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by snoyberg): * cc: snoyberg (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 17 23:29:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 17 Jan 2015 23:29:28 -0000 Subject: [GHC] #10001: GHC crash trying to build a project within Nix-shell Message-ID: <047.a911662f59d5386fa0d95515f4c6d044@haskell.org> #10001: GHC crash trying to build a project within Nix-shell -------------------------------------+------------------------------------- Reporter: wolftune | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: 9825 Differential Revisions: | -------------------------------------+------------------------------------- {{{ : ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): Loading temp shared object failed: /run/user/1000/ghc19915_0/ghc19915_20.so: failed to map segment from shared object Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [20 of 99] Compiling Settings.StaticFiles ( Settings/StaticFiles.hs, dist/build/Settings/StaticFiles.o ) : ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): Loading temp shared object failed: /run/user/1000/ghc19915_0/ghc19915_21.so: failed to map segment from shared object }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 18 03:23:07 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Jan 2015 03:23:07 -0000 Subject: [GHC] #10002: Invalid ghcversion.h file in GHC 7.10.1 RC1 Message-ID: <042.3ff8fa1b9c06892328a6233041f5e97b@haskell.org> #10002: Invalid ghcversion.h file in GHC 7.10.1 RC1 -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Using cpphs 1.18.7, I got the following error with GHC 7.10.1 RC1: {{{ $ cat Main.hs {-# LANGUAGE CPP #-} module Main where main :: IO () main = putStrLn "Hello, World!" }}} {{{ $ ghc -pgmP cpphs -optP --cpp Main.hs ... /usr/local/stow/ghc-7.10.1.RC1/lib/ghc-7.10.0.20141222/include/ghcversion.h:12:30: parse error on input ?\\? }}} By replacing {{{\\}}} by {{{\}}} in ghcversion.h, the issue is fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 18 12:17:28 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Jan 2015 12:17:28 -0000 Subject: [GHC] #9384: setNumCapabilities call breaks eventlog events In-Reply-To: <045.20a8519e305e1ec14c5a72f8498ddcb2@haskell.org> References: <045.20a8519e305e1ec14c5a72f8498ddcb2@haskell.org> Message-ID: <060.0327f8506244714fb15f4d7477f119d2@haskell.org> #9384: setNumCapabilities call breaks eventlog events -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Profiling | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D592 -------------------------------------+------------------------------------- Comment (by Sergei Trofimovich ): In [changeset:"2edb4a7bd5b892ddfac75d0b549d6682a0be5c02/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="2edb4a7bd5b892ddfac75d0b549d6682a0be5c02" Trac #9384: fix increasing capabilites number for eventlog. Event log had inconcistent support for increacing capabilies number, as header were not inserted in capability buffer. It resulted in a ghc-events crash (see #9384). This commit fixes this issue by inserting required header when number of capabilies grows. Reviewers: simonmar, Mikolaj, trofi, austin Reviewed By: Mikolaj, trofi, austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D592 GHC Trac Issues: #9384 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 18 12:20:41 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Jan 2015 12:20:41 -0000 Subject: [GHC] #9384: setNumCapabilities call breaks eventlog events In-Reply-To: <045.20a8519e305e1ec14c5a72f8498ddcb2@haskell.org> References: <045.20a8519e305e1ec14c5a72f8498ddcb2@haskell.org> Message-ID: <060.70c97eb7646f10b6d397999e0fdd2d94@haskell.org> #9384: setNumCapabilities call breaks eventlog events -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.1 Component: Profiling | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D592 -------------------------------------+------------------------------------- Changes (by slyfox): * status: patch => merge Comment: Tested manually on sample attached: works fine with threadscope-0.2.6 \o/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 18 19:12:14 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Jan 2015 19:12:14 -0000 Subject: [GHC] #9277: GHCi panic: Loading temp shared object failed: Symbol not found In-Reply-To: <045.813f344587210915a54c6a71c5a099a3@haskell.org> References: <045.813f344587210915a54c6a71c5a099a3@haskell.org> Message-ID: <060.e348a776a5dd762b92febf98fc22a5d6@haskell.org> #9277: GHCi panic: Loading temp shared object failed: Symbol not found -------------------------------------+------------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: panic, Operating System: MacOS X | dynamic linking Type of failure: GHCi crash | Architecture: x86_64 Blocked By: | (amd64) Related Tickets: #8935, #9034, | Test Case: #9074, #9278 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by George): * cc: george (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 18 19:15:25 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 18 Jan 2015 19:15:25 -0000 Subject: [GHC] #9277: GHCi panic: Loading temp shared object failed: Symbol not found In-Reply-To: <045.813f344587210915a54c6a71c5a099a3@haskell.org> References: <045.813f344587210915a54c6a71c5a099a3@haskell.org> Message-ID: <060.702756efd5aad60f98f8689543d6cae4@haskell.org> #9277: GHCi panic: Loading temp shared object failed: Symbol not found -------------------------------------+------------------------------------- Reporter: mietek | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.2 Resolution: | Keywords: panic, Operating System: MacOS X | dynamic linking Type of failure: GHCi crash | Architecture: x86_64 Blocked By: | (amd64) Related Tickets: #8935, #9034, | Test Case: #9074, #9278 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by George): I am seeing this on 7.10.1 RC1 when calling main: ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20141222 for x86_64-apple-darwin): Loading temp shared object failed: dlopen(/var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/ghc40460_0/ghc40460_6.dylib, 5): Symbol not found: _dataozu00S6JfeF9UMKB9yah5AkcN_DataziListziOrdered_minus_closure Referenced from: /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/ghc40460_0/ghc40460_6.dylib Expected in: flat namespace in /var/folders/9b/rh4y2gy92hgdb6ktv4df1jv00000gn/T/ghc40460_0/ghc40460_6.dylib -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 10:02:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 10:02:56 -0000 Subject: [GHC] #9986: lhs -> hs fallout In-Reply-To: <048.e784fa1ea545a332610bea9ec0b7617f@haskell.org> References: <048.e784fa1ea545a332610bea9ec0b7617f@haskell.org> Message-ID: <063.b159576ae453161989765daee086983f@haskell.org> #9986: lhs -> hs fallout -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: Type: task | thoughtpolice Priority: normal | Status: patch Component: Documentation | Milestone: Resolution: | Version: 7.9 Operating System: Unknown/Multiple | Keywords: Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: D621 -------------------------------------+------------------------------------- Changes (by simonpj): * owner: => thoughtpolice Comment: Austin, could you land this please? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 10:04:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 10:04:30 -0000 Subject: [GHC] #9858: Typeable instance for datatype and its promoted constructor is the same In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.9bd7b5db2102d11e2dc672eb94c19f56@haskell.org> #9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by simonpj): Pedro: how do you suggest we proceed with this? It seems quite urgent if you can use it to write `unsafeCoerce`. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 10:20:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 10:20:33 -0000 Subject: [GHC] #9858: Typeable instance for datatype and its promoted constructor is the same In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.3206f938ece5794d16913eaccec3be5d@haskell.org> #9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.10.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: -------------------------------------+------------------------------------- Changes (by shachaf): * cc: shachaf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 10:35:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 10:35:29 -0000 Subject: [GHC] #9858: Typeable instance for datatype and its promoted constructor is the same In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.9a5e3a77ae7197c6ee7b591679e74bb0@haskell.org> #9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:14 simonpj]: > Pedro: how do you suggest we proceed with this? It seems quite urgent if you can use it to write `unsafeCoerce`. > > Simon If I may comment too, I think the ''long-term'' solution for these bugs cannot be anything less than including kind information in typereps, at least for type constructors of polymorphic kind. However that may be too hard to get done in the short term, in which case one possibility might be to somehow disallow `PolyKinds`, or possibly `Typeable` instances for polykinds, in Safe Haskell. Note that exploiting this doesn't require any explicit extensions mentioning kinds, `Typeable` or deriving, this was my last version (works in GHCi 7.8.3): {{{ {-# LANGUAGE TypeFamilies #-} import Data.Typeable type E = (:~:) data family F p a b newtype instance F a b (Proxy (Proxy :: * -> *)) = ID (a -> a) newtype instance F a b (Proxy (Proxy :: (* -> *) -> *)) = UC (a -> b) -- Needed to prevent faulty inlining in GHCi. Maybe expand further if it -- breaks at higher optimization levels. munge = id ecast :: E p q -> f p -> f q ecast Refl = id supercast :: F a b (Proxy (Proxy :: * -> *)) -> F a b (Proxy (Proxy :: (* -> *) -> *)) supercast = case cast e of Just e' -> munge ecast e' where e = Refl e :: E (Proxy (Proxy :: * -> *)) (Proxy (Proxy :: * -> *)) 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 Mon Jan 19 10:52:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 10:52:07 -0000 Subject: [GHC] #9999: Typeable deriving behavior different between data families and associated data types In-Reply-To: <046.44b8bb2c22fb6d02dbcfd1b37ce4a93e@haskell.org> References: <046.44b8bb2c22fb6d02dbcfd1b37ce4a93e@haskell.org> Message-ID: <061.b53e8733d07e2fd6226c82e907f9bbc8@haskell.org> #9999: Typeable deriving behavior different between data families and associated data types -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Milestone: 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 dreixel): With HEAD, the standalone deriving clause works. But `AutoDeriveTypeable` is indeed not working as it should here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 11:08:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 11:08:59 -0000 Subject: [GHC] #9992: Constructor specialization requires eta expansion In-Reply-To: <046.7d51856d1ca88f0c21c0c3b5ed5c7fc3@haskell.org> References: <046.7d51856d1ca88f0c21c0c3b5ed5c7fc3@haskell.org> Message-ID: <061.dbad93a5becfd9ba8972ab148769418d@haskell.org> #9992: Constructor specialization requires eta expansion -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | performance Type of failure: Runtime | Architecture: performance bug | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"ff4733f4e0355085002a1f9053ba2276e92d2cb6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="ff4733f4e0355085002a1f9053ba2276e92d2cb6" Update bytestring submodule This pulls in - https://github.com/haskell/bytestring/pull/40 (which is related to #9992) - https://github.com/haskell/bytestring/pull/38 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 11:10:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 11:10:48 -0000 Subject: [GHC] #10002: Invalid ghcversion.h file in GHC 7.10.1 RC1 In-Reply-To: <042.3ff8fa1b9c06892328a6233041f5e97b@haskell.org> References: <042.3ff8fa1b9c06892328a6233041f5e97b@haskell.org> Message-ID: <057.217bb67dfe608062c2b190653905e9f6@haskell.org> #10002: Invalid ghcversion.h file in GHC 7.10.1 RC1 -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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 hvr): what was the exact content of the `ghcversion.h` file? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 11:14:00 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 11:14:00 -0000 Subject: [GHC] #10002: Invalid ghcversion.h file in GHC 7.10.1 RC1 In-Reply-To: <042.3ff8fa1b9c06892328a6233041f5e97b@haskell.org> References: <042.3ff8fa1b9c06892328a6233041f5e97b@haskell.org> Message-ID: <057.ee9e9cfa2bfcacafa8ef56e785723350@haskell.org> #10002: Invalid ghcversion.h file in GHC 7.10.1 RC1 -------------------------------------+------------------------------------- Reporter: asr | Owner: hvr Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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 * priority: normal => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 11:21:40 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 11:21:40 -0000 Subject: [GHC] #10002: Invalid ghcversion.h file in GHC 7.10.1 RC1 In-Reply-To: <042.3ff8fa1b9c06892328a6233041f5e97b@haskell.org> References: <042.3ff8fa1b9c06892328a6233041f5e97b@haskell.org> Message-ID: <057.bfca57889353dcaa7a1d9a6fe72ded66@haskell.org> #10002: Invalid ghcversion.h file in GHC 7.10.1 RC1 -------------------------------------+------------------------------------- Reporter: asr | Owner: hvr Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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:"1289048eaf31915b9335c6f7e0b7b64625ab0ed5/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1289048eaf31915b9335c6f7e0b7b64625ab0ed5" Fix bad '... \\' escape in ghcversion.h generation Today I learned about the peculiarities of escaping within single-quotes: Turns out, echo 'foo \\' emits foo \\ rather than escaping the '\'. Curiously, if you need to escape a ' within single-quotes, here's how to do it echo 'foo '\'' bar' which will emit foo ' bar This fixes #10002 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 11:23:35 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 11:23:35 -0000 Subject: [GHC] #10002: Invalid ghcversion.h file in GHC 7.10.1 RC1 In-Reply-To: <042.3ff8fa1b9c06892328a6233041f5e97b@haskell.org> References: <042.3ff8fa1b9c06892328a6233041f5e97b@haskell.org> Message-ID: <057.8384491d1dc73d41b2cef4a7949307a0@haskell.org> #10002: Invalid ghcversion.h file in GHC 7.10.1 RC1 -------------------------------------+------------------------------------- Reporter: asr | Owner: hvr Type: bug | Status: merge Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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 Jan 19 11:48:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 11:48:24 -0000 Subject: [GHC] #9999: Typeable deriving behavior different between data families and associated data types In-Reply-To: <046.44b8bb2c22fb6d02dbcfd1b37ce4a93e@haskell.org> References: <046.44b8bb2c22fb6d02dbcfd1b37ce4a93e@haskell.org> Message-ID: <061.aa7491b66fe422381d7c6f9c7e97b5a1@haskell.org> #9999: Typeable deriving behavior different between data families and associated data types -------------------------------------+------------------------------------- Reporter: shachaf | Owner: Type: bug | Status: new Priority: normal | Milestone: 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): Aha. Might you feel able to fix it? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 11:58:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 11:58:18 -0000 Subject: [GHC] #9953: Pattern synonyms don't work with GADTs In-Reply-To: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> References: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> Message-ID: <061.347dd582b57642922c56b7c92b2a5855@haskell.org> #9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | PatternSynonyms 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:"8e774ba1c0fb38a1e01d156734c8a1acf0b1e59b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="8e774ba1c0fb38a1e01d156734c8a1acf0b1e59b" Improve documentation of pattern synonyms, to reflect conclusion of Trac #9953 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 11:58:18 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 11:58:18 -0000 Subject: [GHC] #9867: PatternSynonyms + ScopedTypeVariables triggers an internal error In-Reply-To: <046.5cdd1cb9d606767d1869bca60906658f@haskell.org> References: <046.5cdd1cb9d606767d1869bca60906658f@haskell.org> Message-ID: <061.dce3dacd56bde2653f2aa3098d5c2846@haskell.org> #9867: PatternSynonyms + ScopedTypeVariables triggers an internal error -------------------------------------+------------------------------------- Reporter: antalsz | Owner: cactus Type: bug | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"4cfd235d4d52ce6e6c48013b2d5dcb347b978c24/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="4cfd235d4d52ce6e6c48013b2d5dcb347b978c24" Test Trac #9867 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 12:15:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 12:15:52 -0000 Subject: [GHC] #9999: Typeable deriving behavior different between data families and associated data types In-Reply-To: <046.44b8bb2c22fb6d02dbcfd1b37ce4a93e@haskell.org> References: <046.44b8bb2c22fb6d02dbcfd1b37ce4a93e@haskell.org> Message-ID: <061.3abcd6d7772194ad42cabe89b7f3584e@haskell.org> #9999: Typeable deriving behavior different between data families and associated data types -------------------------------------+------------------------------------- Reporter: shachaf | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: 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 dreixel): * owner: => dreixel -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 12:37:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 12:37:27 -0000 Subject: [GHC] #10002: Invalid ghcversion.h file in GHC 7.10.1 RC1 In-Reply-To: <042.3ff8fa1b9c06892328a6233041f5e97b@haskell.org> References: <042.3ff8fa1b9c06892328a6233041f5e97b@haskell.org> Message-ID: <057.914c6afc419c9d76fbe816bcb2f69277@haskell.org> #10002: Invalid ghcversion.h file in GHC 7.10.1 RC1 -------------------------------------+------------------------------------- Reporter: asr | Owner: hvr Type: bug | Status: merge Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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 asr): Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 12:55:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 12:55:06 -0000 Subject: [GHC] #9945: export list for System.Posix.Internals breaking the build on Windows In-Reply-To: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> References: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> Message-ID: <061.cfa39af986ba8404aa2efa7bbf72670c@haskell.org> #9945: export list for System.Posix.Internals breaking the build on Windows -------------------------------------+------------------------------------- Reporter: MartinF | Owner: Type: bug | thoughtpolice Priority: normal | Status: new Component: Build System | Milestone: 7.12.1 Resolution: | Version: 7.11 Operating System: Windows | Keywords: Type of failure: Building GHC | Architecture: failed | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9852 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"e1a458101a5233068f4d50fdfcfa473b5c8fdd11/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="e1a458101a5233068f4d50fdfcfa473b5c8fdd11" Revert "Fix undefined GHC.Real export with integer-simple" This reverts commit 228902aa4a3350a9c99e421c0c989c7de794b7b6. This commit is dependent on d6e7f5dc9db7e382ce34d649f85505176a451a04, which broke the build on Windows (issue #9945). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 12:55:06 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 12:55:06 -0000 Subject: [GHC] #9945: export list for System.Posix.Internals breaking the build on Windows In-Reply-To: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> References: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> Message-ID: <061.70d649b65a7ea008c614657f132cb021@haskell.org> #9945: export list for System.Posix.Internals breaking the build on Windows -------------------------------------+------------------------------------- Reporter: MartinF | Owner: Type: bug | thoughtpolice Priority: normal | Status: new Component: Build System | Milestone: 7.12.1 Resolution: | Version: 7.11 Operating System: Windows | Keywords: Type of failure: Building GHC | Architecture: failed | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9852 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"f006ed7965a0fa918d720cc387b33cb8e7083854/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f006ed7965a0fa918d720cc387b33cb8e7083854" Revert "Add export lists to some modules." This reverts commit d6e7f5dc9db7e382ce34d649f85505176a451a04. This commit broke the build on Windows due to CPP weirdness (#9945). }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 13:15:05 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 13:15:05 -0000 Subject: [GHC] #9945: export list for System.Posix.Internals breaking the build on Windows In-Reply-To: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> References: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> Message-ID: <061.7d1c1788ef3a4b1605f3468df12808e5@haskell.org> #9945: export list for System.Posix.Internals breaking the build on Windows -------------------------------------+------------------------------------- Reporter: MartinF | Owner: Type: bug | thoughtpolice Priority: normal | Status: closed Component: Build System | Milestone: 7.12.1 Resolution: fixed | Version: 7.11 Operating System: Windows | Keywords: Type of failure: Building GHC | Architecture: failed | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9852 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: I've reverted the offending commits in the mean time. We'll need a more principled solution to this later on anyway if we want to reintroduce them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 13:15:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 13:15:29 -0000 Subject: [GHC] #10002: Invalid ghcversion.h file in GHC 7.10.1 RC1 In-Reply-To: <042.3ff8fa1b9c06892328a6233041f5e97b@haskell.org> References: <042.3ff8fa1b9c06892328a6233041f5e97b@haskell.org> Message-ID: <057.c9bffbadefe18279a72470d1d671409c@haskell.org> #10002: Invalid ghcversion.h file in GHC 7.10.1 RC1 -------------------------------------+------------------------------------- Reporter: asr | Owner: hvr Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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 Comment: Merged into ghc-7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 13:15:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 13:15:38 -0000 Subject: [GHC] #9243: Recompilation avoidance doesn't work for -fno-code/-fwrite-interface In-Reply-To: <045.eb0d37b8e28f9b0d21ba7b721e124a6b@haskell.org> References: <045.eb0d37b8e28f9b0d21ba7b721e124a6b@haskell.org> Message-ID: <060.dfcb33d8a5632883dd8d20ed68a4fad9@haskell.org> #9243: Recompilation avoidance doesn't work for -fno-code/-fwrite-interface -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.9 Resolution: fixed | Keywords: backpack Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D596 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged into ghc-7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 13:17:15 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 13:17:15 -0000 Subject: [GHC] #10003: integer-gmp2 tries to be GMP 4.x compatible but uses functions from GMP 5.x Message-ID: <046.8c38a2755dbd0195fbd11b9263841f8b@haskell.org> #10003: integer-gmp2 tries to be GMP 4.x compatible but uses functions from GMP 5.x -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries | Version: 7.11 (other) | Operating System: Solaris Keywords: | Type of failure: Building GHC Architecture: sparc | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- Hello, recent HEAD is using integer-gmp2 wrapper around GMP library. This tries to be compatible with and use only functionality of GMP 4.x, but still it also uses some functions from GMP 5.x which makes this incompatible with GMP 4.x. The issue is for example shown on Solaris/SPARC platform where the OS provided library is GMP 4.3.2 and linking of stage2 binaries fails with: {{{ Undefined first referenced symbol in file __gmpn_andn_n /home/karel/src/ghc-sparc-reg_ncg-head-2015-01-17/libraries /integer-gmp2/dist- install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a(Type.o) __gmpn_and_n /home/karel/src/ghc-sparc-reg_ncg-head-2015-01-17/libraries /integer-gmp2/dist- install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a(Type.o) __gmpn_ior_n /home/karel/src/ghc-sparc-reg_ncg-head-2015-01-17/libraries /integer-gmp2/dist- install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a(Type.o) __gmpn_xor_n /home/karel/src/ghc-sparc-reg_ncg-head-2015-01-17/libraries /integer-gmp2/dist- install/build/libHSinteg_21cuTlnn00eFNd4GMrxOMi.a(Type.o) ld: fatal: symbol referencing errors. No output written to ghc/stage2/build/tmp/ghc-stage2 }}} the unresolve symbols are from GMP 5.x. GMP 4.x does not provide them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 13:24:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 13:24:14 -0000 Subject: [GHC] #10002: Invalid ghcversion.h file in GHC 7.10.1 RC1 In-Reply-To: <042.3ff8fa1b9c06892328a6233041f5e97b@haskell.org> References: <042.3ff8fa1b9c06892328a6233041f5e97b@haskell.org> Message-ID: <057.7900520bb30a8570e8e90eb3ba4f92dc@haskell.org> #10002: Invalid ghcversion.h file in GHC 7.10.1 RC1 -------------------------------------+------------------------------------- Reporter: asr | Owner: hvr Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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 hvr): (merged via 42aad2834e634aee50254e0a67685ef129286d50) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 13:41:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 13:41:39 -0000 Subject: [GHC] #9999: Typeable deriving behavior different between data families and associated data types In-Reply-To: <046.44b8bb2c22fb6d02dbcfd1b37ce4a93e@haskell.org> References: <046.44b8bb2c22fb6d02dbcfd1b37ce4a93e@haskell.org> Message-ID: <061.473cb84f1761eef95c0db130c72b5762@haskell.org> #9999: Typeable deriving behavior different between data families and associated data types -------------------------------------+------------------------------------- Reporter: shachaf | Owner: dreixel Type: bug | Status: new Priority: normal | Milestone: 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 Jose Pedro Magalhaes ): In [changeset:"d839493991e508160d416311ba47b7a7e2d62aae/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d839493991e508160d416311ba47b7a7e2d62aae" Make AutoDeriveTypeable work for associated datatypes (fix #9999) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 13:56:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 13:56:53 -0000 Subject: [GHC] #10003: integer-gmp2 tries to be GMP 4.x compatible but uses functions from GMP 5.x In-Reply-To: <046.8c38a2755dbd0195fbd11b9263841f8b@haskell.org> References: <046.8c38a2755dbd0195fbd11b9263841f8b@haskell.org> Message-ID: <061.26bbdecb26faf50855660c97de656c69@haskell.org> #10003: integer-gmp2 tries to be GMP 4.x compatible but uses functions from GMP 5.x -------------------------------------+------------------------------------- Reporter: kgardas | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: libraries | Version: 7.10.1-rc1 (other) | Keywords: Resolution: | Architecture: sparc Operating System: Solaris | Test Case: Type of failure: Building GHC | Blocking: failed | Differential Revisions: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by hvr): * owner: => hvr * version: 7.11 => 7.10.1-rc1 * milestone: => 7.10.1 Comment: With GMP 5.0.0, the following new functions were added relative to GMP 4.x, so we need some compatibility layer to support GMP 4.x ---- == FEATURES * New mpz function: mpz_powm_sec for side-channel quiet modexp computations. * New mpn functions: mpn_sqr, mpn_and_n, mpn_ior_n, mpn_xor_n, mpn_nand_n, mpn_nior_n, mpn_xnor_n, mpn_andn_n, mpn_iorn_n, mpn_com, mpn_neg, mpn_copyi, mpn_copyd, mpn_zero. * The function mpn_tdiv_qr now allows certain argument overlap. * Support for fat binaries for 64-bit x86 processors has been added. * A new type, mp_bitcnt_t for bignum bit counts, has been introduced. * Support for Windows64 through mingw64 has been added. * The cofactors of mpz_gcdext and mpn_gcdext are now more strictly normalised, returning to how GMP 4.2 worked. (Note that also release 4.3.2 has this change.) ---- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 13:57:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 13:57:27 -0000 Subject: [GHC] #9999: Typeable deriving behavior different between data families and associated data types In-Reply-To: <046.44b8bb2c22fb6d02dbcfd1b37ce4a93e@haskell.org> References: <046.44b8bb2c22fb6d02dbcfd1b37ce4a93e@haskell.org> Message-ID: <061.f1c6856e78972115ee29ef2d5163af59@haskell.org> #9999: Typeable deriving behavior different between data families and associated data types -------------------------------------+------------------------------------- Reporter: shachaf | Owner: dreixel Type: bug | Status: merge Priority: normal | Milestone: 7.10.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 thoughtpolice): * status: new => merge * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 13:57:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 13:57:53 -0000 Subject: [GHC] #9961: compile-time performance regression compiling genprimcode In-Reply-To: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> References: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> Message-ID: <057.921e770ed3912b80e686125bd166872d@haskell.org> #9961: compile-time performance regression compiling genprimcode -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: patch Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 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 Austin Seipp ): In [changeset:"55199a97c020761ff4bfdc06da0042e43bede697/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="55199a97c020761ff4bfdc06da0042e43bede697" Split stripTicks into expression editing and tick collection As with stripTicksTop, this is because we often need the stripped expression but not the ticks (at least not right away). This makes a big difference for CSE, see #9961. Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 13:59:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 13:59:47 -0000 Subject: [GHC] #9889: Pattern synonym does not work in top-level pattern bind In-Reply-To: <047.fe6568ce87d5703b3811c455881d3231@haskell.org> References: <047.fe6568ce87d5703b3811c455881d3231@haskell.org> Message-ID: <062.369a62f0e3c37af13c0b4700a69bdff5@haskell.org> #9889: Pattern synonym does not work in top-level pattern bind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.9 checker) | Keywords: Resolution: fixed | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential 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 Mon Jan 19 13:59:51 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 13:59:51 -0000 Subject: [GHC] #9384: setNumCapabilities call breaks eventlog events In-Reply-To: <045.20a8519e305e1ec14c5a72f8498ddcb2@haskell.org> References: <045.20a8519e305e1ec14c5a72f8498ddcb2@haskell.org> Message-ID: <060.9a573d550479455b2f3753de689c4322@haskell.org> #9384: setNumCapabilities call breaks eventlog events -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Profiling | Version: 7.8.3 Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D592 -------------------------------------+------------------------------------- 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 Mon Jan 19 13:59:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 13:59:52 -0000 Subject: [GHC] #8624: -ddump-splices-file In-Reply-To: <048.f5eead94409241401357105f8bb65a4f@haskell.org> References: <048.f5eead94409241401357105f8bb65a4f@haskell.org> Message-ID: <063.c2bee8d571e7795aa7e09b3cddf65bf6@haskell.org> #8624: -ddump-splices-file -------------------------------------+------------------------------------- Reporter: GregWeber | Owner: Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.6.3 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:D518 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 13:59:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 13:59:59 -0000 Subject: [GHC] #9922: Partial type signatures + extensions panic In-Reply-To: <047.bcb93dee275eec47e30ed9673a9b0d12@haskell.org> References: <047.bcb93dee275eec47e30ed9673a9b0d12@haskell.org> Message-ID: <062.1a48b47eca3ef95a8dd6cf22218d713d@haskell.org> #9922: Partial type signatures + extensions panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: thomasw Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.9 checker) | Keywords: Resolution: fixed | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Compile-time | Test Case: crash | Blocking: Blocked By: | Differential Revisions: Phab:D595 Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 14:02:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 14:02:17 -0000 Subject: [GHC] #9878: Static pointers in GHCi cause panic In-Reply-To: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> References: <047.a0b4c5e0dee3f65cf24b644a915474ce@haskell.org> Message-ID: <062.ddcc51088245fe89594e8df80cfdc03f@haskell.org> #9878: Static pointers in GHCi cause panic -------------------------------------+------------------------------------- Reporter: monoidal | Owner: Type: bug | facundo.dominguez Priority: normal | Status: closed Component: Compiler | Milestone: 7.10.1 Resolution: fixed | Version: 7.9 Operating System: Unknown/Multiple | Keywords: Type of failure: GHCi crash | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: Phab:D586 | Phab:D587 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Merged to `ghc-7.10`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 14:02:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 14:02:29 -0000 Subject: [GHC] #9999: Typeable deriving behavior different between data families and associated data types In-Reply-To: <046.44b8bb2c22fb6d02dbcfd1b37ce4a93e@haskell.org> References: <046.44b8bb2c22fb6d02dbcfd1b37ce4a93e@haskell.org> Message-ID: <061.57405f3e87445e93cbf8c885e6102b2c@haskell.org> #9999: Typeable deriving behavior different between data families and associated data types -------------------------------------+------------------------------------- Reporter: shachaf | Owner: dreixel Type: bug | Status: closed Priority: normal | Milestone: 7.10.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 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 Mon Jan 19 14:21:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 14:21:21 -0000 Subject: [GHC] #9957: Document -fwarn-unticked-promoted-constructors in release notes In-Reply-To: <049.140c9348cb257489c7a06e29a9d4d013@haskell.org> References: <049.140c9348cb257489c7a06e29a9d4d013@haskell.org> Message-ID: <064.a3c1093ad403562f02ecedd9ee19f3fe@haskell.org> #9957: Document -fwarn-unticked-promoted-constructors in release notes -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Documentation | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed Comment: Fixed in the GHC 7.10 branch (4baf8d2aa09bb72ff8ba32335ddf235f5a644717). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 14:22:22 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 14:22:22 -0000 Subject: [GHC] #9957: Document -fwarn-unticked-promoted-constructors in release notes In-Reply-To: <049.140c9348cb257489c7a06e29a9d4d013@haskell.org> References: <049.140c9348cb257489c7a06e29a9d4d013@haskell.org> Message-ID: <064.1d5595f9ffa745904857717b6006a9c9@haskell.org> #9957: Document -fwarn-unticked-promoted-constructors in release notes -------------------------------------+------------------------------------- Reporter: adamgundry | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Documentation | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Documentation | Unknown/Multiple bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"cb65bdbca83f43d72dd2fc6ecd1897e734454d33/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="cb65bdbca83f43d72dd2fc6ecd1897e734454d33" Doc fix (follow up to #9957) Signed-off-by: Austin Seipp }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 14:51:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 14:51:21 -0000 Subject: [GHC] #7298: Test 2228 fails with dynamic-by-default In-Reply-To: <044.34213a5738911dce009c62eab496ee22@haskell.org> References: <044.34213a5738911dce009c62eab496ee22@haskell.org> Message-ID: <059.29550ab25c9f9c433670af4981a2596e@haskell.org> #7298: Test 2228 fails with dynamic-by-default -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: GHCi | Version: 7.6.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 thoughtpolice): * cc: hvr (added) * status: new => closed * resolution: => wontfix Comment: Closing, since we're moving away from dynamic by default anyway. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 14:51:28 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 14:51:28 -0000 Subject: [GHC] #7298: Test 2228 fails with dynamic-by-default In-Reply-To: <044.34213a5738911dce009c62eab496ee22@haskell.org> References: <044.34213a5738911dce009c62eab496ee22@haskell.org> Message-ID: <059.a353e4f8cd1039260fe98ac96aa41234@haskell.org> #7298: Test 2228 fails with dynamic-by-default -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: closed Priority: high | Milestone: Component: GHCi | Version: 7.6.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 thoughtpolice): * milestone: 7.10.1 => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 14:51:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 14:51:57 -0000 Subject: [GHC] #7320: GHC crashes when building on 32-bit Linux in a Linode In-Reply-To: <043.0168db82b571fa620930b74d5d40cf16@haskell.org> References: <043.0168db82b571fa620930b74d5d40cf16@haskell.org> Message-ID: <058.b87cc6b3088f64290b084691cbb307e7@haskell.org> #7320: GHC crashes when building on 32-bit Linux in a Linode ---------------------------------------+----------------------------------- Reporter: benl | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.6.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86 Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------------+----------------------------------- Changes (by thoughtpolice): * priority: high => normal * milestone: 7.10.1 => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 14:54:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 14:54:17 -0000 Subject: [GHC] Batch modify: #7919, #8131, #8974, #9007, #314, #781, #4144, #4505, #5987, #7325, #7411, #7521, #7567, #7679, #8228, #5910, #9631 Message-ID: <20150119145417.70E503A2FF@ghc.haskell.org> Batch modification to #7919, #8131, #8974, #9007, #314, #781, #4144, #4505, #5987, #7325, #7411, #7521, #7567, #7679, #8228, #5910, #9631 by thoughtpolice: milestone to 7.12.1 Comment: Moving to 7.12.1 -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 15:01:13 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 15:01:13 -0000 Subject: [GHC] #9836: Facility to mitigate double-breakage due to Data.Version.versionTag Deprecation In-Reply-To: <042.f26aa5502ae18a92677b97b72d2d86fd@haskell.org> References: <042.f26aa5502ae18a92677b97b72d2d86fd@haskell.org> Message-ID: <057.56a249341f0310f9fe517e51054e832e@haskell.org> #9836: Facility to mitigate double-breakage due to Data.Version.versionTag Deprecation -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: task | Status: infoneeded Priority: high | Milestone: 7.10.1 Component: libraries/base | Version: Resolution: | Keywords: Operating System: Unknown/Multiple | Data.Version Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #2496 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): see 5b8fa46ca37caa9ec83b217a697628135da34506 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 15:02:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 15:02:25 -0000 Subject: [GHC] #9836: Facility to mitigate double-breakage due to Data.Version.versionTag Deprecation In-Reply-To: <042.f26aa5502ae18a92677b97b72d2d86fd@haskell.org> References: <042.f26aa5502ae18a92677b97b72d2d86fd@haskell.org> Message-ID: <057.37c3546494473bf37ee3fe22f0f275a6@haskell.org> #9836: Facility to mitigate double-breakage due to Data.Version.versionTag Deprecation -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: feature request | Status: closed Priority: high | Milestone: 7.10.1 Component: libraries/base | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Data.Version Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: #2496 | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * status: infoneeded => closed * type: task => feature request * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 15:06:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 15:06:11 -0000 Subject: [GHC] #9981: Potential typechecker regression in GHC 7.10.1RC In-Reply-To: <042.c047cab9d166b1747ff4913537189070@haskell.org> References: <042.c047cab9d166b1747ff4913537189070@haskell.org> Message-ID: <057.c5f71224b023c8dfcad2a8ecdac56cb3@haskell.org> #9981: Potential typechecker regression in GHC 7.10.1RC -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: highest | Milestone: 7.10.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: | -------------------------------------+------------------------------------- Comment (by simonpj): This definitely should not work; it requires impredicative polymoprhism which GHC does not properly support. The error message is bad, and I'll try to fix that, but I don't think it's urgent for 7.10. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 15:06:39 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 15:06:39 -0000 Subject: [GHC] #9981: Potential typechecker regression in GHC 7.10.1RC In-Reply-To: <042.c047cab9d166b1747ff4913537189070@haskell.org> References: <042.c047cab9d166b1747ff4913537189070@haskell.org> Message-ID: <057.51351bff895ea09e9cd071c801e01848@haskell.org> #9981: Potential typechecker regression in GHC 7.10.1RC -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: 7.10.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: | -------------------------------------+------------------------------------- Changes (by simonpj): * priority: highest => normal -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 15:11:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 15:11:29 -0000 Subject: [GHC] #9858: Typeable instance for datatype and its promoted constructor is the same In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.726868c5abb1c80709111286acc806e0@haskell.org> #9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.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: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * priority: high => highest -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 15:14:07 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 15:14:07 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.bd1fc2f50197462157f8c8bd8a096d58@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: arm Operating System: Unknown/Multiple | Test Case: Type of failure: Incorrect result | Blocking: at runtime | Differential Revisions: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Changes (by thoughtpolice): * priority: highest => high Comment: Moving down in priority since this hasn't seen any updates; @bgamari, think you could look into this maybe? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 15:18:29 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 15:18:29 -0000 Subject: [GHC] #9856: Test suite regressions due to integer-gmp2 In-Reply-To: <046.46e84cf4a8b5d1f50db00f57d7053a13@haskell.org> References: <046.46e84cf4a8b5d1f50db00f57d7053a13@haskell.org> Message-ID: <061.6a2839561f22ac49dd97cac16ccf0205@haskell.org> #9856: Test suite regressions due to integer-gmp2 -------------------------------------+------------------------------------- Reporter: nomeata | 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: prof-doc- Related Tickets: | fib linker_unload | Blocking: | Differential Revisions: Phab:D82 -------------------------------------+------------------------------------- Comment (by simonpj): Simon Marlow say: this is not a bug; it's a bug in the test. But it's not easy to fix. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 15:18:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 15:18:56 -0000 Subject: [GHC] #9856: Test suite regressions due to integer-gmp2 In-Reply-To: <046.46e84cf4a8b5d1f50db00f57d7053a13@haskell.org> References: <046.46e84cf4a8b5d1f50db00f57d7053a13@haskell.org> Message-ID: <061.6d3d938cd5fa39c1f6eeda5c2d4b4ab1@haskell.org> #9856: Test suite regressions due to integer-gmp2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Test Suite | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: prof-doc- Related Tickets: | fib linker_unload | Blocking: | Differential Revisions: Phab:D82 -------------------------------------+------------------------------------- Changes (by simonmar): * owner: => simonmar * component: Compiler => Test Suite * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 15:25:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 15:25:31 -0000 Subject: [GHC] #9945: export list for System.Posix.Internals breaking the build on Windows In-Reply-To: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> References: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> Message-ID: <061.742d51c5de4f6954ca6cc4ce6dbbae85@haskell.org> #9945: export list for System.Posix.Internals breaking the build on Windows -------------------------------------+------------------------------------- Reporter: MartinF | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #9852 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * owner: thoughtpolice => * status: closed => new * resolution: fixed => Comment: Whoops, closed in error - there's still a problem here obviously. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 15:26:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 15:26:48 -0000 Subject: [GHC] #9945: export list for System.Posix.Internals breaking the build on Windows In-Reply-To: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> References: <046.de9aafe108e71fe89d058ef5eea5b0ac@haskell.org> Message-ID: <061.cb490411fc2bd54f176f64a3b5e11446@haskell.org> #9945: export list for System.Posix.Internals breaking the build on Windows -------------------------------------+------------------------------------- Reporter: MartinF | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: #9852 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): So the underlying issue is that of these overlapping #defines. See comment:6. It'd be great if someone could actually fix the underlying problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 15:53:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 15:53:23 -0000 Subject: [GHC] #9989: GHCI is slow for precompiled code In-Reply-To: <046.94b9207f80786e5d4d2d3451b686df6a@haskell.org> References: <046.94b9207f80786e5d4d2d3451b686df6a@haskell.org> Message-ID: <061.f759d1c36b360d20aed0ec614e8ce629@haskell.org> #9989: GHCI is slow for precompiled code -------------------------------------+------------------------------------- Reporter: remdezx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 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 simonpj): Does the same thing happen if you tell Accelerate to generate code for a CPU rather than a GPU? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 15:54:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 15:54:45 -0000 Subject: [GHC] #9989: GHCI is slow for precompiled code In-Reply-To: <046.94b9207f80786e5d4d2d3451b686df6a@haskell.org> References: <046.94b9207f80786e5d4d2d3451b686df6a@haskell.org> Message-ID: <061.d2c89540a449db047b1398cfe774787e@haskell.org> #9989: GHCI is slow for precompiled code -------------------------------------+------------------------------------- Reporter: remdezx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Hello! We found that loading compiled and optimised `accelerate` code > into ghci works much much slower than code run directly. > > (I'm marking it as a ghc-api bug, because I noticed this behavior while > using it) > > Here is the example: > {{{#!hs > module Main where > > import Data.Array.Accelerate as A > import Data.Array.Accelerate.CUDA as C > import Data.Time.Clock (diffUTCTime, getCurrentTime) > > main :: IO () > main = do > start <- getCurrentTime > print $ C.run $ A.maximum $ A.map (+1) $ A.use (fromList (Z:.1000000) > [1..1000000] :: Vector Double) > end <- getCurrentTime > print $ diffUTCTime end start > }}} > > When I compile it and run > > $ ghc -O2 Main.hs -threaded > [1 of 1] Compiling Main ( Main.hs, Main.o ) > Linking Main ... > $ ./Main > Array (Z) [1000001.0] > 0.162204s > > It takes `0.16 s` to finish > When I compile it and load into ghci: > > $ ghc -O2 -dynamic -c Main.hs > $ ghci > 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. > Prelude> :l Main > Ok, modules loaded: Main. > Prelude Main> main > Loading package transformers-0.3.0.0 ... linking ... done. > 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 binary-0.7.1.0 ... linking ... done. > Loading package pretty-1.1.1.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 unix-2.7.0.1 ... linking ... done. > Loading package directory-1.2.1.0 ... linking ... done. > Loading package process-1.2.0.0 ... linking ... done. > Loading package stm-2.4.4 ... linking ... done. > Loading package SafeSemaphore-0.10.1 ... linking ... done. > Loading package mtl-2.1.3.1 ... linking ... done. > Loading package template-haskell ... linking ... done. > Loading package fclabels-2.0.2.2 ... linking ... done. > Loading package text-1.1.1.3 ... linking ... done. > Loading package hashable-1.2.3.1 ... linking ... done. > Loading package primitive-0.5.4.0 ... linking ... done. > Loading package vector-0.10.12.2 ... linking ... done. > Loading package hashtables-1.2.0.1 ... linking ... done. > Loading package unordered-containers-0.2.5.1 ... linking ... done. > Loading package accelerate-0.15.0.0 ... linking ... done. > Loading package byteable-0.1.1 ... linking ... done. > Loading package cryptohash-0.11.6 ... linking ... done. > Loading package cuda-0.6.5.1 ... linking ... done. > Loading package exception-transformers-0.3.0.4 ... linking ... done. > Loading package exception-mtl-0.3.0.5 ... linking ... done. > Loading package old-time-1.1.0.2 ... linking ... done. > Loading package polyparse-1.11 ... linking ... done. > Loading package cpphs-1.18.6 ... linking ... done. > Loading package haskell-src-exts-1.16.0.1 ... linking ... done. > Loading package syb-0.4.4 ... linking ... done. > Loading package th-lift-0.7 ... linking ... done. > Loading package safe-0.3.8 ... linking ... done. > Loading package th-expand-syns-0.3.0.4 ... linking ... done. > Loading package th-reify-many-0.1.2 ... linking ... done. > Loading package th-orphans-0.8.3 ... linking ... done. > Loading package haskell-src-meta-0.6.0.8 ... linking ... done. > Loading package srcloc-0.4.1 ... linking ... done. > Loading package mainland-pretty-0.2.7 ... linking ... done. > Loading package symbol-0.2.4 ... linking ... done. > Loading package language-c-quote-0.8.0 ... linking ... done. > Loading package accelerate-cuda-0.15.0.0 ... linking ... done. > Array (Z) [1000001.0] > 0.256128s > > It takes `0.26 s` to finish. On other computer, using `criterion`, we > observed even a `50x` difference. > > Why is it working so slow, isn't ghci just to load function and simply > call it? > > Here is how execution time changes for different matrix sizes. For > comparison we have also measured time of interpreted code (without > precompiling). > > {{{ > size | compiled | precompiled | interpreted > ---------+-----------+--------------+------------ > 100 | 0.054076s | 0.082686s | 0.151857s > 1000 | 0.054509s | 0.08305s | 0.135452s > 10000 | 0.055405s | 0.08469s | 0.12632s > 100000 | 0.057768s | 0.093011s | 0.155359s > 1000000 | 0.089811s | 0.251359s | 0.202022s > 10000000 | 0.397642s | 1.400603s | 0.898547s > }}} > > We believe that problem lies on the side of `ghci` rather than > `accelerate`, how could we confirm this? > > Moreover and even more important is there any workaround for it, if we > need this precompiled code running fast in production environment? > > Any guidance will be appreciated. New description: Hello! We found that loading compiled and optimised `accelerate` code into ghci works much much slower than code run directly. (I'm marking it as a ghc-api bug, because I noticed this behavior while using it) Here is the example: {{{#!hs module Main where import Data.Array.Accelerate as A import Data.Array.Accelerate.CUDA as C import Data.Time.Clock (diffUTCTime, getCurrentTime) main :: IO () main = do start <- getCurrentTime print $ C.run $ A.maximum $ A.map (+1) $ A.use (fromList (Z:.1000000) [1..1000000] :: Vector Double) end <- getCurrentTime print $ diffUTCTime end start }}} When I compile it and run {{ $ ghc -O2 Main.hs -threaded [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... $ ./Main Array (Z) [1000001.0] 0.162204s }} It takes `0.16 s` to finish When I compile it and load into ghci: {{{ $ ghc -O2 -dynamic -c Main.hs $ ghci 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. Prelude> :l Main Ok, modules loaded: Main. Prelude Main> main Loading package transformers-0.3.0.0 ... linking ... done. 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 binary-0.7.1.0 ... linking ... done. Loading package pretty-1.1.1.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 unix-2.7.0.1 ... linking ... done. Loading package directory-1.2.1.0 ... linking ... done. Loading package process-1.2.0.0 ... linking ... done. Loading package stm-2.4.4 ... linking ... done. Loading package SafeSemaphore-0.10.1 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package fclabels-2.0.2.2 ... linking ... done. Loading package text-1.1.1.3 ... linking ... done. Loading package hashable-1.2.3.1 ... linking ... done. Loading package primitive-0.5.4.0 ... linking ... done. Loading package vector-0.10.12.2 ... linking ... done. Loading package hashtables-1.2.0.1 ... linking ... done. Loading package unordered-containers-0.2.5.1 ... linking ... done. Loading package accelerate-0.15.0.0 ... linking ... done. Loading package byteable-0.1.1 ... linking ... done. Loading package cryptohash-0.11.6 ... linking ... done. Loading package cuda-0.6.5.1 ... linking ... done. Loading package exception-transformers-0.3.0.4 ... linking ... done. Loading package exception-mtl-0.3.0.5 ... linking ... done. Loading package old-time-1.1.0.2 ... linking ... done. Loading package polyparse-1.11 ... linking ... done. Loading package cpphs-1.18.6 ... linking ... done. Loading package haskell-src-exts-1.16.0.1 ... linking ... done. Loading package syb-0.4.4 ... linking ... done. Loading package th-lift-0.7 ... linking ... done. Loading package safe-0.3.8 ... linking ... done. Loading package th-expand-syns-0.3.0.4 ... linking ... done. Loading package th-reify-many-0.1.2 ... linking ... done. Loading package th-orphans-0.8.3 ... linking ... done. Loading package haskell-src-meta-0.6.0.8 ... linking ... done. Loading package srcloc-0.4.1 ... linking ... done. Loading package mainland-pretty-0.2.7 ... linking ... done. Loading package symbol-0.2.4 ... linking ... done. Loading package language-c-quote-0.8.0 ... linking ... done. Loading package accelerate-cuda-0.15.0.0 ... linking ... done. Array (Z) [1000001.0] 0.256128s }}} It takes `0.26 s` to finish. On other computer, using `criterion`, we observed even a `50x` difference. Why is it working so slow, isn't ghci just to load function and simply call it? Here is how execution time changes for different matrix sizes. For comparison we have also measured time of interpreted code (without precompiling). {{{ size | compiled | precompiled | interpreted ---------+-----------+--------------+------------ 100 | 0.054076s | 0.082686s | 0.151857s 1000 | 0.054509s | 0.08305s | 0.135452s 10000 | 0.055405s | 0.08469s | 0.12632s 100000 | 0.057768s | 0.093011s | 0.155359s 1000000 | 0.089811s | 0.251359s | 0.202022s 10000000 | 0.397642s | 1.400603s | 0.898547s }}} We believe that problem lies on the side of `ghci` rather than `accelerate`, how could we confirm this? Moreover and even more important is there any workaround for it, if we need this precompiled code running fast in production environment? Any guidance will be appreciated. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 15:55:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 15:55:04 -0000 Subject: [GHC] #9858: Typeable instance for datatype and its promoted constructor is the same In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.fb35c0c277c55ddce1676249589ef4b9@haskell.org> #9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by dreixel): Here's the current definition of `TypeRep`: {{{ data TypeRep = TypeRep {-# UNPACK #-} !Fingerprint TyCon [TypeRep] data TyCon = TyCon { tyConHash :: {-# UNPACK #-} !Fingerprint, tyConPackage :: String, tyConModule :: String, tyConName :: String } }}} Could we perhaps add a `tyConKind :: TypeRep` to `TyCon`, and make sure that it is used when computing the hash? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 15:55:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 15:55:14 -0000 Subject: [GHC] #9989: GHCI is slow for precompiled code In-Reply-To: <046.94b9207f80786e5d4d2d3451b686df6a@haskell.org> References: <046.94b9207f80786e5d4d2d3451b686df6a@haskell.org> Message-ID: <061.edda2e46d379a27f610764ea15e2c2fe@haskell.org> #9989: GHCI is slow for precompiled code -------------------------------------+------------------------------------- Reporter: remdezx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Hello! We found that loading compiled and optimised `accelerate` code > into ghci works much much slower than code run directly. > > (I'm marking it as a ghc-api bug, because I noticed this behavior while > using it) > > Here is the example: > {{{#!hs > module Main where > > import Data.Array.Accelerate as A > import Data.Array.Accelerate.CUDA as C > import Data.Time.Clock (diffUTCTime, getCurrentTime) > > main :: IO () > main = do > start <- getCurrentTime > print $ C.run $ A.maximum $ A.map (+1) $ A.use (fromList (Z:.1000000) > [1..1000000] :: Vector Double) > end <- getCurrentTime > print $ diffUTCTime end start > }}} > > When I compile it and run > {{ > $ ghc -O2 Main.hs -threaded > [1 of 1] Compiling Main ( Main.hs, Main.o ) > Linking Main ... > $ ./Main > Array (Z) [1000001.0] > 0.162204s > }} > It takes `0.16 s` to finish > When I compile it and load into ghci: > {{{ > $ ghc -O2 -dynamic -c Main.hs > $ ghci > 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. > Prelude> :l Main > Ok, modules loaded: Main. > Prelude Main> main > Loading package transformers-0.3.0.0 ... linking ... done. > 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 binary-0.7.1.0 ... linking ... done. > Loading package pretty-1.1.1.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 unix-2.7.0.1 ... linking ... done. > Loading package directory-1.2.1.0 ... linking ... done. > Loading package process-1.2.0.0 ... linking ... done. > Loading package stm-2.4.4 ... linking ... done. > Loading package SafeSemaphore-0.10.1 ... linking ... done. > Loading package mtl-2.1.3.1 ... linking ... done. > Loading package template-haskell ... linking ... done. > Loading package fclabels-2.0.2.2 ... linking ... done. > Loading package text-1.1.1.3 ... linking ... done. > Loading package hashable-1.2.3.1 ... linking ... done. > Loading package primitive-0.5.4.0 ... linking ... done. > Loading package vector-0.10.12.2 ... linking ... done. > Loading package hashtables-1.2.0.1 ... linking ... done. > Loading package unordered-containers-0.2.5.1 ... linking ... done. > Loading package accelerate-0.15.0.0 ... linking ... done. > Loading package byteable-0.1.1 ... linking ... done. > Loading package cryptohash-0.11.6 ... linking ... done. > Loading package cuda-0.6.5.1 ... linking ... done. > Loading package exception-transformers-0.3.0.4 ... linking ... done. > Loading package exception-mtl-0.3.0.5 ... linking ... done. > Loading package old-time-1.1.0.2 ... linking ... done. > Loading package polyparse-1.11 ... linking ... done. > Loading package cpphs-1.18.6 ... linking ... done. > Loading package haskell-src-exts-1.16.0.1 ... linking ... done. > Loading package syb-0.4.4 ... linking ... done. > Loading package th-lift-0.7 ... linking ... done. > Loading package safe-0.3.8 ... linking ... done. > Loading package th-expand-syns-0.3.0.4 ... linking ... done. > Loading package th-reify-many-0.1.2 ... linking ... done. > Loading package th-orphans-0.8.3 ... linking ... done. > Loading package haskell-src-meta-0.6.0.8 ... linking ... done. > Loading package srcloc-0.4.1 ... linking ... done. > Loading package mainland-pretty-0.2.7 ... linking ... done. > Loading package symbol-0.2.4 ... linking ... done. > Loading package language-c-quote-0.8.0 ... linking ... done. > Loading package accelerate-cuda-0.15.0.0 ... linking ... done. > Array (Z) [1000001.0] > 0.256128s > }}} > It takes `0.26 s` to finish. On other computer, using `criterion`, we > observed even a `50x` difference. > > Why is it working so slow, isn't ghci just to load function and simply > call it? > > Here is how execution time changes for different matrix sizes. For > comparison we have also measured time of interpreted code (without > precompiling). > > {{{ > size | compiled | precompiled | interpreted > ---------+-----------+--------------+------------ > 100 | 0.054076s | 0.082686s | 0.151857s > 1000 | 0.054509s | 0.08305s | 0.135452s > 10000 | 0.055405s | 0.08469s | 0.12632s > 100000 | 0.057768s | 0.093011s | 0.155359s > 1000000 | 0.089811s | 0.251359s | 0.202022s > 10000000 | 0.397642s | 1.400603s | 0.898547s > }}} > > We believe that problem lies on the side of `ghci` rather than > `accelerate`, how could we confirm this? > > Moreover and even more important is there any workaround for it, if we > need this precompiled code running fast in production environment? > > Any guidance will be appreciated. New description: Hello! We found that loading compiled and optimised `accelerate` code into ghci works much much slower than code run directly. (I'm marking it as a ghc-api bug, because I noticed this behavior while using it) Here is the example: {{{#!hs module Main where import Data.Array.Accelerate as A import Data.Array.Accelerate.CUDA as C import Data.Time.Clock (diffUTCTime, getCurrentTime) main :: IO () main = do start <- getCurrentTime print $ C.run $ A.maximum $ A.map (+1) $ A.use (fromList (Z:.1000000) [1..1000000] :: Vector Double) end <- getCurrentTime print $ diffUTCTime end start }}} When I compile it and run {{{ $ ghc -O2 Main.hs -threaded [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main ... $ ./Main Array (Z) [1000001.0] 0.162204s }}} It takes `0.16 s` to finish When I compile it and load into ghci: {{{ $ ghc -O2 -dynamic -c Main.hs $ ghci 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. Prelude> :l Main Ok, modules loaded: Main. Prelude Main> main Loading package transformers-0.3.0.0 ... linking ... done. 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 binary-0.7.1.0 ... linking ... done. Loading package pretty-1.1.1.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 unix-2.7.0.1 ... linking ... done. Loading package directory-1.2.1.0 ... linking ... done. Loading package process-1.2.0.0 ... linking ... done. Loading package stm-2.4.4 ... linking ... done. Loading package SafeSemaphore-0.10.1 ... linking ... done. Loading package mtl-2.1.3.1 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package fclabels-2.0.2.2 ... linking ... done. Loading package text-1.1.1.3 ... linking ... done. Loading package hashable-1.2.3.1 ... linking ... done. Loading package primitive-0.5.4.0 ... linking ... done. Loading package vector-0.10.12.2 ... linking ... done. Loading package hashtables-1.2.0.1 ... linking ... done. Loading package unordered-containers-0.2.5.1 ... linking ... done. Loading package accelerate-0.15.0.0 ... linking ... done. Loading package byteable-0.1.1 ... linking ... done. Loading package cryptohash-0.11.6 ... linking ... done. Loading package cuda-0.6.5.1 ... linking ... done. Loading package exception-transformers-0.3.0.4 ... linking ... done. Loading package exception-mtl-0.3.0.5 ... linking ... done. Loading package old-time-1.1.0.2 ... linking ... done. Loading package polyparse-1.11 ... linking ... done. Loading package cpphs-1.18.6 ... linking ... done. Loading package haskell-src-exts-1.16.0.1 ... linking ... done. Loading package syb-0.4.4 ... linking ... done. Loading package th-lift-0.7 ... linking ... done. Loading package safe-0.3.8 ... linking ... done. Loading package th-expand-syns-0.3.0.4 ... linking ... done. Loading package th-reify-many-0.1.2 ... linking ... done. Loading package th-orphans-0.8.3 ... linking ... done. Loading package haskell-src-meta-0.6.0.8 ... linking ... done. Loading package srcloc-0.4.1 ... linking ... done. Loading package mainland-pretty-0.2.7 ... linking ... done. Loading package symbol-0.2.4 ... linking ... done. Loading package language-c-quote-0.8.0 ... linking ... done. Loading package accelerate-cuda-0.15.0.0 ... linking ... done. Array (Z) [1000001.0] 0.256128s }}} It takes `0.26 s` to finish. On other computer, using `criterion`, we observed even a `50x` difference. Why is it working so slow, isn't ghci just to load function and simply call it? Here is how execution time changes for different matrix sizes. For comparison we have also measured time of interpreted code (without precompiling). {{{ size | compiled | precompiled | interpreted ---------+-----------+--------------+------------ 100 | 0.054076s | 0.082686s | 0.151857s 1000 | 0.054509s | 0.08305s | 0.135452s 10000 | 0.055405s | 0.08469s | 0.12632s 100000 | 0.057768s | 0.093011s | 0.155359s 1000000 | 0.089811s | 0.251359s | 0.202022s 10000000 | 0.397642s | 1.400603s | 0.898547s }}} We believe that problem lies on the side of `ghci` rather than `accelerate`, how could we confirm this? Moreover and even more important is there any workaround for it, if we need this precompiled code running fast in production environment? Any guidance will be appreciated. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 15:58:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 15:58:42 -0000 Subject: [GHC] #9867: PatternSynonyms + ScopedTypeVariables triggers an internal error In-Reply-To: <046.5cdd1cb9d606767d1869bca60906658f@haskell.org> References: <046.5cdd1cb9d606767d1869bca60906658f@haskell.org> Message-ID: <061.1b32c58ca948c2273d74386711a6826c@haskell.org> #9867: PatternSynonyms + ScopedTypeVariables triggers an internal error -------------------------------------+------------------------------------- Reporter: antalsz | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | patsyn/should_compile/T9867 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge * testcase: => patsyn/should_compile/T9867 Comment: Fixed by {{{ commit 3ea40e38a7ae03c05cb79485fb04a3f00c632793 Author: Simon Peyton Jones Date: Mon Jan 19 09:06:21 2015 +0000 Fix the 'builder' code for pattern synonyms with type signatures See Note [Type signatures and the builder expression] for the details compiler/typecheck/TcPatSyn.hs | 144 ++++++++++++++++++++++------------------ 1 file changed, 79 insertions(+), 65 deletions(-) }}} and follow up wibble {{{ commit 9a1458266b8fa349c9fb58889825d899a762fa27 Author: Simon Peyton Jones Date: Mon Jan 19 10:20:39 2015 +0000 Add missing argument in Match, a merge bug (apologies) compiler/typecheck/TcPatSyn.hs | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) }}} We could consider merging this to 7.10. It isn't huge, but let's do it if it's easy. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 15:59:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 15:59:53 -0000 Subject: [GHC] #9953: Pattern synonyms don't work with GADTs In-Reply-To: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> References: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> Message-ID: <061.5c991c814d46d3ce31606299199842b4@haskell.org> #9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: cactus Type: bug | Status: merge Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => merge Comment: OK I fixed the user manual myself. Let's merge the change into 7.10 (assuming that the prior stuff about pattern signatures is in, which I think it is). Simoin -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 16:23:41 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 16:23:41 -0000 Subject: [GHC] #10004: rec {} causes "head:empty list" exception Message-ID: <044.6292d003c0954df796402481444e8d4b@haskell.org> #10004: rec {} causes "head:empty list" exception -------------------------------------+------------------------------------- Reporter: alanz | 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: | -------------------------------------+------------------------------------- Using GHC HEAD 7.11.20150116 (and before) Trying to load the following into ghci {{{#!hs {-# LANGUAGE RecursiveDo #-} bar :: IO () bar = do rec {} return () }}} results in {{{ > :load "/home/alanz/mysrc/github/alanz/ghc- exactprint/tests/examples/Foo.hs" [1 of 1] Compiling Main ( /home/alanz/mysrc/github/alanz/ghc- exactprint/tests/examples/Foo.hs, interpreted ) *** Exception: Prelude.head: empty list > }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 16:44:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 16:44:21 -0000 Subject: [GHC] #9999: Typeable deriving behavior different between data families and associated data types In-Reply-To: <046.44b8bb2c22fb6d02dbcfd1b37ce4a93e@haskell.org> References: <046.44b8bb2c22fb6d02dbcfd1b37ce4a93e@haskell.org> Message-ID: <061.474b323793040e635ac29da0287b8d10@haskell.org> #9999: Typeable deriving behavior different between data families and associated data types -------------------------------------+------------------------------------- Reporter: shachaf | Owner: dreixel Type: bug | Status: closed Priority: normal | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"d3c08ca0c4f83aaed6bd25785a03c0fb52438ba6/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="d3c08ca0c4f83aaed6bd25785a03c0fb52438ba6" Tidy up fix to Trac #9999 Minor refactoring only }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 16:55:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 16:55:55 -0000 Subject: [GHC] #9989: GHCI is slow for precompiled code In-Reply-To: <046.94b9207f80786e5d4d2d3451b686df6a@haskell.org> References: <046.94b9207f80786e5d4d2d3451b686df6a@haskell.org> Message-ID: <061.78a7d5da42e3d693d5abf0a60690830b@haskell.org> #9989: GHCI is slow for precompiled code -------------------------------------+------------------------------------- Reporter: remdezx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 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 remdezx): Yes, it is still slower when it is run on CPU. When I change `import Data.Array.Accelerate.Interpreter as C` to `import Data.Array.Accelerate.CUDA as C` compiled code for matrix size `10000` executes `0.007s` and precompiled and run under ghci is `0.035s` (5x slower). For `1000000` matrix size execution times are `0.57s` (compiled) vs `0.90s` (precompiled). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 17:22:42 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 17:22:42 -0000 Subject: [GHC] #9989: GHCI is slow for precompiled code In-Reply-To: <046.94b9207f80786e5d4d2d3451b686df6a@haskell.org> References: <046.94b9207f80786e5d4d2d3451b686df6a@haskell.org> Message-ID: <061.3b12f1af24cf3904dfc7b39304089754@haskell.org> #9989: GHCI is slow for precompiled code -------------------------------------+------------------------------------- Reporter: remdezx | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHC API | Version: 7.8.3 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 simonpj): OK that's helpful because it removes the dependency on GPU hardware -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 18:47:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 18:47:25 -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.d17cc291f3666b937b741c44fd894dc8@haskell.org> #9965: getChanContents BlockedIndefinitelyOnMVar on 7.10 RC1 -------------------------------------+------------------------------------- Reporter: jberryman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1-rc1 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 jberryman): Adding another `unsafeInterleaveIO` seems to solve this, but I don't really understand why: {{{#!haskell getChanContents :: Chan a -> IO [a] getChanContents ch = unsafeInterleaveIO (do x <- unsafeInterleaveIO $ readChan ch -- <------ unsafeInterleaveIO xs <- getChanContents ch return (x:xs) ) }}} I'll attach the output of `ghc --make -O2 -fforce-recomp -ddump-to-file -ddump-simpl -dsuppress-module-prefixes -dsuppress-uniques Main.hs` for both 7.8 and 7.10, using both the old version of `getChanContents` and the new version above. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 18:48:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 18:48:24 -0000 Subject: [GHC] #9955: ghc-stage1 compiles with bootstrapping ghc package, not the built one In-Reply-To: <045.2e2f0948ac1cf3246cb798d3962e4df0@haskell.org> References: <045.2e2f0948ac1cf3246cb798d3962e4df0@haskell.org> Message-ID: <060.6a6b968e3de2a7fa324dd2672176e49c@haskell.org> #9955: ghc-stage1 compiles with bootstrapping ghc package, not the built one -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: Build System | Version: 7.11 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: Phab:D603 -------------------------------------+------------------------------------- Comment (by Edward Z. Yang ): In [changeset:"1f1595195443700b7c2708fa903969fa2f0a927b/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="1f1595195443700b7c2708fa903969fa2f0a927b" Respect package visibility when deciding wired in packages. Summary: Previously, we would consider ALL versions of a wired-in package, no matter if they were exposed or not, and pick the latest version. This patch is a minor refinement on the behavior: now we try to pick the wired in package from just the list of exposed packages, and if there are no candidates fall back on the full list. This means that if you do: -hide-all-packages -package wired-in-OLD-VERSION it will actually work by default (whereas previously you needed to *explicitly* -ignore-package the newer version). This is especially useful for the 'ghc' package. Fixes #9955. Signed-off-by: Edward Z. Yang Test Plan: validate Reviewers: simonpj, austin Reviewed By: austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D603 GHC Trac Issues: #9955 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 19:24:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 19:24:58 -0000 Subject: [GHC] #10005: Operations on string literals won't be inlined Message-ID: <048.79330f90aa6689947b213892c4dfd806@haskell.org> #10005: Operations on string literals won't be inlined -------------------------------------+------------------------------------- Reporter: fread2281 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- An example is attached, GHC won't optimize {{{ head "stringliteral" }}} into {{{ 's' }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 19:38:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 19:38:53 -0000 Subject: [GHC] #9955: ghc-stage1 compiles with bootstrapping ghc package, not the built one In-Reply-To: <045.2e2f0948ac1cf3246cb798d3962e4df0@haskell.org> References: <045.2e2f0948ac1cf3246cb798d3962e4df0@haskell.org> Message-ID: <060.b70e2b2b7def7ff00d64ade711686e0a@haskell.org> #9955: ghc-stage1 compiles with bootstrapping ghc package, not the built one -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: merge Priority: high | Milestone: 7.10.1 Component: Build System | Version: 7.11 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: Phab:D603 -------------------------------------+------------------------------------- Changes (by ezyang): * status: patch => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 20:31:16 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 20:31:16 -0000 Subject: =?utf-8?q?=5BGHC=5D_=2310006=3A_Add_baseline_ellipsis_as_unicode?= =?utf-8?b?IGFsdGVybmF0aXZlIHRvIMKrLi7Cuw==?= Message-ID: <045.85f8084d7488f7960b150b416bd80d83@haskell.org> #10006: Add baseline ellipsis as unicode alternative to ?..? -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple (Parser) | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- While the current unicode syntax is overall very pleasing to the eye, writing the ellipsis as two periods (?..?) sticks out quite noticably. I would welcome it if the horizontal ellipsis (U+2026, ???) would be allowed in places where ?..? can be written. I noticed that there was an old discussion on the mailing list which indicated that originally there was a unicode replacement for ?..?, namely the midline ellipsis, which wasn?t considered a good choice and was removed from the syntax. The regular ellipsis would have the advantage that it is one of the more common ?fancy? characters and mapped by default in the X server compose definitions; as such it?s rather well-accepted and sees use even on IRC and in blogs. So user?s would potentially benefit from the regular ellipsis, much more so than the more exotic midline ellipsis. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 20:32:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 20:32:23 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2310006=3A_Add_baseline_ellipsis_as_u?= =?utf-8?q?nicode_alternative_to_=C2=AB=2E=2E=C2=BB?= In-Reply-To: <045.85f8084d7488f7960b150b416bd80d83@haskell.org> References: <045.85f8084d7488f7960b150b416bd80d83@haskell.org> Message-ID: <060.20f7517b8c8849042f5a052a83536064@haskell.org> #10006: Add baseline ellipsis as unicode alternative to ?..? -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by zardoz: Old description: > While the current unicode syntax is overall very pleasing to the eye, > writing the ellipsis as two periods (?..?) sticks out quite noticably. I > would welcome it if the horizontal ellipsis (U+2026, ???) would be > allowed in places where ?..? can be written. > > I noticed that there was an old discussion on the mailing list which > indicated that originally there was a unicode replacement for ?..?, > namely the midline ellipsis, which wasn?t considered a good choice and > was removed from the syntax. The regular ellipsis would have the > advantage that it is one of the more common ?fancy? characters and mapped > by default in the X server compose definitions; as such it?s rather well- > accepted and sees use even on IRC and in blogs. So user?s would > potentially benefit from the regular ellipsis, much more so than the more > exotic midline ellipsis. New description: While the current unicode syntax is overall very pleasing to the eye, writing the ellipsis as two periods (?..?) sticks out quite noticably. I would welcome it if the horizontal ellipsis (U+2026, ???) would be allowed in places where ?..? can be written. I noticed that there was an old discussion on the mailing list which indicated that originally there was a unicode replacement for ?..?, namely the midline ellipsis, which wasn?t considered a good choice and was removed from the syntax. The regular ellipsis would have the advantage that it is one of the more common ?fancy? characters and mapped by default in the X server compose definitions; as such it?s rather well-accepted and sees use even on IRC and in blogs. So users would potentially benefit from the regular ellipsis, much more so than the more exotic midline ellipsis. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 21:12:23 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 21:12:23 -0000 Subject: [GHC] #9901: Error message: f is applied to two arguments, but its type has only two (sic) In-Reply-To: <045.20460e93a0bca4214189c85bc9425d02@haskell.org> References: <045.20460e93a0bca4214189c85bc9425d02@haskell.org> Message-ID: <060.42120d11911c691e29a49fb52e3f9d97@haskell.org> #9901: Error message: f is applied to two arguments, but its type has only two (sic) -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: new 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: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by zardoz): Sorry, I lost track of this. I?ve attached a program which will reproduce this message on GHC 7.8.4. It doesn?t seem to relate to a forgotten do. It?s triggered by the wrong type annotation to the value of ?preview?. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 22:07:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 22:07:34 -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.cf320c18b852715bb1fa864dde898f81@haskell.org> #9049: Expose srcLoc from the assertion architecture to allow better error messages -------------------------------------+------------------------------------- Reporter: nh2 | Owner: gridaphobe Type: feature request | Status: patch 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: | Blocking: | Differential Revisions: Phab:D578 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"c024af131b9e2538486eb605ba8af6a8d10fe76d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="c024af131b9e2538486eb605ba8af6a8d10fe76d" Expose source locations via Implicit Parameters of type GHC.Location.Location Summary: IPs with this type will always be solved for the current source location. If another IP of the same type is in scope, the two locations will be appended, creating a call-stack. The Location type is kept abstract so users cannot create them, but a Location can be turned into a list of SrcLocs, which correspond to individual locations in a program. Each SrcLoc contains a package/module/file name and start/end lines and columns. The only thing missing from the SrcLoc in my opinion is the name of the top-level definition it inhabits. I suspect that would also be useful, but it's not clear to me how to extract the current top-level binder from within the constraint solver. (Surely I'm just missing something here?) I made the (perhaps controversial) decision to have GHC completely ignore the names of Location IPs, meaning that in the following code: bar :: (?myloc :: Location) => String bar = foo foo :: (?loc :: Location) => String foo = show ?loc if I call `bar`, the resulting call-stack will include locations for 1. the use of `?loc` inside `foo`, 2. `foo`s call-site inside `bar`, and 3. `bar`s call-site, wherever that may be. This makes Location IPs very special indeed, and I'm happy to change it if the dissonance is too great. I've also left out any changes to base to make use of Location IPs, since there were some concerns about a snowball effect. I think it would be reasonable to mark this as an experimental feature for now (it is!), and defer using it in base until we have more experience with it. It is, after all, quite easy to define your own version of `error`, `undefined`, etc. that use Location IPs. Test Plan: validate, new test-case is testsuite/tests/typecheck/should_run/IPLocation.hs Reviewers: austin, hvr, simonpj Reviewed By: simonpj Subscribers: simonmar, rodlogic, carter, thomie Differential Revision: https://phabricator.haskell.org/D578 GHC Trac Issues: #9049 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 22:13:27 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 22:13:27 -0000 Subject: [GHC] #10007: Fix misattribution of Cost Centre profiles to lintAnnots Message-ID: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> #10007: Fix misattribution of Cost Centre profiles to lintAnnots -------------------------------------+------------------------------------- Reporter: | Owner: scpmw thoughtpolice | Status: new Type: bug | Milestone: 7.10.1 Priority: high | Version: 7.10.1-rc1 Component: Profiling | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #9961 Blocking: | Differential Revisions: Phab:D616 | -------------------------------------+------------------------------------- Split off from #9961 - the profiling results while debugging erroneously reported that most cost centre profiles were a result of `lintAnnots`, as opposed to `CSE`. This is a bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 22:13:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 22:13:59 -0000 Subject: [GHC] #9961: compile-time performance regression compiling genprimcode In-Reply-To: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> References: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> Message-ID: <057.0d62bcb6fbc145d41deac91d82a6157c@haskell.org> #9961: compile-time performance regression compiling genprimcode -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: patch Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10007 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * related: => #10007 Comment: I've split off a separate ticket for Phab:D616 - #10007. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 22:14:17 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 22:14:17 -0000 Subject: [GHC] #9961: compile-time performance regression compiling genprimcode In-Reply-To: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> References: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> Message-ID: <057.491db9ef1d72867e83ab97d7b0d7167e@haskell.org> #9961: compile-time performance regression compiling genprimcode -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: patch Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10007 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): I've split off a separate ticket for Phab:D616 - #10007. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 22:54:11 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 22:54:11 -0000 Subject: [GHC] #9901: Error message: f is applied to two arguments, but its type has only two (sic) In-Reply-To: <045.20460e93a0bca4214189c85bc9425d02@haskell.org> References: <045.20460e93a0bca4214189c85bc9425d02@haskell.org> Message-ID: <060.a0ceb9ab12b8fc03e844068a1372eed9@haskell.org> #9901: Error message: f is applied to two arguments, but its type has only two (sic) -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: new 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: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Can you offer an example that does not depend on `lens` with its zillions of dependencies? Usually you can just write down the types of the imports, thus: {{{ preview :: preview = error "urk" }}} Also is the `UnicodeSyntax` significant. Thakns -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 19 23:58:38 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 19 Jan 2015 23:58:38 -0000 Subject: [GHC] #9858: Typeable instance for datatype and its promoted constructor is the same In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.ce5552128919fa2ac8046e09d8b1b394@haskell.org> #9858: Typeable instance for datatype and its promoted constructor is the same -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by goldfire): I see two different issues at work here: 1. If we have `data A = A`, then (typeRep (Proxy :: Proxy A)) and (typeRep (Proxy :: Proxy 'A)) are equal. This is not a problem with kinds, but a problem with namespaces. To me, the salient difference between `A` and `'A` is not that their kinds are different, but that they represent totally different entities. Fixing this issue is simple, either by adding some namespace information to `TyCon` or putting some marker in the `tyConName` string. 2. If we have `data B x` (no constructors), then `B :: forall k. k -> *`. The types `(B :: Bool -> *)` and `(B :: Ordering -> *)` are actually, in Core, `B Bool` and `B Ordering` -- in Core, kind arguments are explicit. Thus, the `TypeRep` for `B :: Bool -> *` could feasibly be `TypeRep []`. The change here isn't to the structure of `TyCon`, but instead mandating that all kind arguments are explicit in `TypeRep`s, just like they are in Core. Indeed, it surprises me that this isn't already the case! I believe that making kind arguments explicit in `TypeRep`s will be a simplification. Personally, it seems adding kind information to `TypeRep` is not the best approach here. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 02:50:39 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 02:50:39 -0000 Subject: [GHC] #9948: Recommend class constraint instead of instance constraint In-Reply-To: <047.c66907ef09dd5fcc438f73ae7f72ae2e@haskell.org> References: <047.c66907ef09dd5fcc438f73ae7f72ae2e@haskell.org> Message-ID: <062.8b0a9dc6acb1e2027aae90e82fd2784e@haskell.org> #9948: Recommend class constraint instead of instance constraint -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by crockeea): > * Implementing this would be ''more'' work for GHC, I believe. When GHC is trying to satisfy the `Foo a` constraint that arises from the use of `foo`, it then naturally looks for `Foo` instances. It finds a matching one, and then proceeds to try to satisfy the instance's constraints. This process can continue arbitrarily deeply. To report the error requested would require, at the end, looking at the set of unsolved constraints and then trying to find some instance that covers them all. There might be more efficient/effective ways to do this (say, remember precisely the constraints that arise directly from constrained function usages), but it would be more work for GHC, regardless. I'm suggesting that if `foo` is a method of class `Foo`, then GHC simply says `cannot deduce (Foo a)`. There's no need to match instances at all. This is already the behavior in the absence of instances, i.e. if I define `class Foo a` with method `foo` and no instances, and then write a function `f` that uses `foo`, GHC recommends a `Foo a` constraint. However, if i define instances as in my question, GHC starts recommending constraints from the matching *instance* instead. > > As a smaller point (but which confused me at first), the original post uses the term "superclass" in a way different to the way I use it: I've always understood "superclass" to refer to constraints on a class definition, such as the `Bar a` in `class Bar a => Fuggle a`. Above, it seems the term "superclass" refers to an instance head. Please correct if I'm wrong. By "superclass", I meant "class". Right now GHC proposes constraints from a matching instance head, which is more work and results in a mess. I would prefer if GHC, when I use `foo`, simply recommends the class (containing `foo`) constraint `Foo a`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 07:16:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 07:16:00 -0000 Subject: [GHC] #8095: TypeFamilies painfully slow In-Reply-To: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> References: <050.29bdc4d704aaf05e461a59330593e649@haskell.org> Message-ID: <065.31239fc64bb9c63ac1097d06773d9ad9@haskell.org> #8095: TypeFamilies painfully slow -------------------------------------+------------------------------------- Reporter: MikeIzbicki | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.6.3 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Compile-time | Test Case: performance bug | Blocking: Blocked By: | Differential Revisions: Related Tickets: 5321 | -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 07:16:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 07:16:43 -0000 Subject: [GHC] #7788: Recursive type family causes <> In-Reply-To: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> References: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> Message-ID: <061.984430de7590734a0f2b7886d8c09cc4@haskell.org> #7788: Recursive type family causes <> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.6.2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Changes (by jstolarek): * cc: jstolarek (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 09:08:25 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 09:08:25 -0000 Subject: [GHC] #10008: Error Message-ID: <050.64adf27478413fb644b7b46a3d55c36e@haskell.org> #10008: Error -------------------------------------+------------------------------------- Reporter: | Owner: amadeusxnet | Status: new Type: bug | Milestone: Priority: normal | Version: 7.4.1 Component: Compiler | Operating System: Linux Keywords: | Type of failure: Building GHC Architecture: arm | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for arm-unknown-linux): Cant do annotations without GHCi {Data/Vector/Fusion/Stream/Monadic.hs:104:19-33} base:GHC.Exts.ForceSpecConstr{d raqj} I'm using a Raspberry Pi. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 09:20:45 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 09:20:45 -0000 Subject: [GHC] #10008: Error In-Reply-To: <050.64adf27478413fb644b7b46a3d55c36e@haskell.org> References: <050.64adf27478413fb644b7b46a3d55c36e@haskell.org> Message-ID: <065.1ad459a146b51dffd7174d423b97b4eb@haskell.org> #10008: Error ----------------------------------------+-------------------------------- Reporter: amadeusxnet | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+-------------------------------- Comment (by jstolarek): We need to see your code. Could you attach it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 09:23:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 09:23:37 -0000 Subject: [GHC] #10008: Error In-Reply-To: <050.64adf27478413fb644b7b46a3d55c36e@haskell.org> References: <050.64adf27478413fb644b7b46a3d55c36e@haskell.org> Message-ID: <065.08be7e3551dee51d2e6cfe6c126c4c96@haskell.org> #10008: Error ----------------------------------------+--------------------------------- Reporter: amadeusxnet | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+--------------------------------- Changes (by monoidal): * status: new => closed * resolution: => duplicate Comment: This should be fixed in newer version (#9683), try upgrading GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 09:25:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 09:25:40 -0000 Subject: [GHC] #9968: DeriveAnyClass fails on multi-parameter type classes In-Reply-To: <047.651a00b270696920750ca655201f4d2f@haskell.org> References: <047.651a00b270696920750ca655201f4d2f@haskell.org> Message-ID: <062.2b88056f2a12ee7445e1cbf05cab6ebb@haskell.org> #9968: DeriveAnyClass fails on multi-parameter type classes -------------------------------------+------------------------------------- Reporter: goldfire | Owner: dreixel Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9821 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by dreixel): Simon, could you give me some help with this? I was hoping it would be easy to just reuse the infrastructure for newtype deriving here. Should I follow the structure of the `EarlyDerivSpec` generated by the first branch of `mkNewTypeEqn`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 11:32:24 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 11:32:24 -0000 Subject: [GHC] #10008: Error In-Reply-To: <050.64adf27478413fb644b7b46a3d55c36e@haskell.org> References: <050.64adf27478413fb644b7b46a3d55c36e@haskell.org> Message-ID: <065.c60eca281917a770163c3973859a5c7c@haskell.org> #10008: Error ----------------------------------------+--------------------------------- Reporter: amadeusxnet | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+--------------------------------- Comment (by nomeata): I?d say the real fix is #4268 (which makes this a warning instead of a panic), but finding a compiler with GHCi support is also good :-) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 11:45:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 11:45:52 -0000 Subject: [GHC] #10008: Error In-Reply-To: <050.64adf27478413fb644b7b46a3d55c36e@haskell.org> References: <050.64adf27478413fb644b7b46a3d55c36e@haskell.org> Message-ID: <065.a88085e80dfac8458623a88b6b6ec99c@haskell.org> #10008: Error ----------------------------------------+--------------------------------- Reporter: amadeusxnet | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: arm Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------------+--------------------------------- Comment (by amadeusxnet): I'm a little confused about the Haskell stuffs. So lets hope I'll get this to work :) Right now I'm trying to install the newest stable Haskell-Platform! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 12:47:00 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 12:47:00 -0000 Subject: [GHC] #8292: linker_unload test doesn't work on Windows In-Reply-To: <045.e7a16237251b40a3053a3840cf0c1a14@haskell.org> References: <045.e7a16237251b40a3053a3840cf0c1a14@haskell.org> Message-ID: <060.01a6d52b144abdc83ec3db17bae6c298@haskell.org> #8292: linker_unload test doesn't work on Windows -------------------------------------+------------------------------------- Reporter: ezyang | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.7 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | linker_unload | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonmar): I think this might now work on Windows, but someone needs to check: rGHC6108d95a73f93d486223064ad72bf6bedc116cbd -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 12:47:57 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 12:47:57 -0000 Subject: [GHC] #9856: Test suite regressions due to integer-gmp2 In-Reply-To: <046.46e84cf4a8b5d1f50db00f57d7053a13@haskell.org> References: <046.46e84cf4a8b5d1f50db00f57d7053a13@haskell.org> Message-ID: <061.b05ae4498521f3ee3016bb69e422a2ac@haskell.org> #9856: Test suite regressions due to integer-gmp2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Test Suite | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: prof-doc- Related Tickets: | fib linker_unload | Blocking: | Differential Revisions: Phab:D82 -------------------------------------+------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Should now work: rGHC6108d95a73f93d486223064ad72bf6bedc116cbd -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 12:53:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 12:53:05 -0000 Subject: [GHC] #9856: Test suite regressions due to integer-gmp2 In-Reply-To: <046.46e84cf4a8b5d1f50db00f57d7053a13@haskell.org> References: <046.46e84cf4a8b5d1f50db00f57d7053a13@haskell.org> Message-ID: <061.fb3b6524f67aeaa717dfb6577edf152b@haskell.org> #9856: Test suite regressions due to integer-gmp2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Test Suite | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: prof-doc- Related Tickets: | fib linker_unload | Blocking: | Differential Revisions: Phab:D82 -------------------------------------+------------------------------------- Comment (by hvr): is this to be merged into 7.10? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 12:55:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 12:55:43 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2310006=3A_Add_baseline_ellipsis_as_u?= =?utf-8?q?nicode_alternative_to_=C2=AB=2E=2E=C2=BB?= In-Reply-To: <045.85f8084d7488f7960b150b416bd80d83@haskell.org> References: <045.85f8084d7488f7960b150b416bd80d83@haskell.org> Message-ID: <060.63a0a57fa6bfa7cccf886075079352b2@haskell.org> #10006: Add baseline ellipsis as unicode alternative to ?..? -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (Parser) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #3894 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * related: => #3894 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 15:04:21 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 15:04:21 -0000 Subject: [GHC] #9948: Recommend class constraint instead of instance constraint In-Reply-To: <047.c66907ef09dd5fcc438f73ae7f72ae2e@haskell.org> References: <047.c66907ef09dd5fcc438f73ae7f72ae2e@haskell.org> Message-ID: <062.2522b4ec698b987b449104426710de56@haskell.org> #9948: Recommend class constraint instead of instance constraint -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:4 crockeea]: > I'm suggesting that if `foo` is a method of class `Foo`, then GHC simply says `cannot deduce (Foo a)`. There's no need to match instances at all. However, we would, of course, still like to find an instance where possible. Just determining if an instance exists requires looking up instances for `Foo`, and then perhaps recurring on any constraints to those instances. At the end of a chain of instance constraints, we might end up with some constraint, say `Bar Int a`, that is unsatisfiable. Only then do we know that no instance matches the original constraint. To report a missing `Foo a` constraint at this point, we would need to somehow the need for `Bar Int a` came from a desire for `Foo a`. Keeping track of this is the "more work" I was talking about. Nowhere near impossible, but strictly harder than what happens currently. In any case, I think the discussion about how hard this feature is to implement detracts from the debate we should be having: what is really the desired behavior, regardless of implementation challenge. (To be clear, the implementation is not particularly challenging here, I think -- just not completely trivial.) And, regardless of implementation issues, I prefer the current behavior over the new one proposed in this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 15:15:59 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 15:15:59 -0000 Subject: [GHC] #9948: Recommend class constraint instead of instance constraint In-Reply-To: <047.c66907ef09dd5fcc438f73ae7f72ae2e@haskell.org> References: <047.c66907ef09dd5fcc438f73ae7f72ae2e@haskell.org> Message-ID: <062.cb144f7697090fcf2cf1e32f4c71765f@haskell.org> #9948: Recommend class constraint instead of instance constraint -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by crockeea): Replying to [comment:5 goldfire]: > However, we would, of course, still like to find an instance where possible. I see your point. So it's good that GHC looks at instances and tries to find a RHS match. If he constraints are also satisfied, then no errors should be reported. The case I'm talking about is when there is a matching instance [on the RHS], but the instance constraints are not satisfied. {{{ data T a class Foo b where foo :: b -> Int instance (Integral a) => Foo (T a) f :: T a -> Int f = foo }}} I don't like that GHC behaves differently in the presence of a matching instance vs when there are no matching instances. One workaround for what I'm suggesting (that I find myself frequently using) is to comment out all instances of the class. Then GHC just says `no instance for `Foo a` arising from the use of `foo`` instead of recommending constraints from the matching instance. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 16:02:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 16:02:58 -0000 Subject: [GHC] #9856: Test suite regressions due to integer-gmp2 In-Reply-To: <046.46e84cf4a8b5d1f50db00f57d7053a13@haskell.org> References: <046.46e84cf4a8b5d1f50db00f57d7053a13@haskell.org> Message-ID: <061.ff0e7aa6a74eeb89f87c58b0a27f583e@haskell.org> #9856: Test suite regressions due to integer-gmp2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Test Suite | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: prof-doc- Related Tickets: | fib linker_unload | Blocking: | Differential Revisions: Phab:D82 -------------------------------------+------------------------------------- Comment (by simonmar): Yes please! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 16:40:04 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 16:40:04 -0000 Subject: [GHC] #10009: type inference regression when faking injective type families Message-ID: <045.3dd09f45a408c20b5f0ae041319c4a61@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- ghc-7.10.0.20141222 does not accept the program unless I uncomment the type signature (a :: a). ghc-7.8 accepts it as-is. {{{#!hs {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE TypeFamilies #-} class (UnF (F a) ~ a, Show a) => C a where type F a f :: F a -> a type family UnF a g :: forall a. C a => a -> String g _ = show a where a = f (undefined :: F a) -- :: a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 19:27:49 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 19:27:49 -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.912543e83ba6935f0160c0a8a0c25b3f@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.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: | -------------------------------------+------------------------------------- Changes (by dfeuer): * priority: normal => high * failure: None/Unknown => GHC rejects valid program * component: Compiler => Compiler (Type checker) * milestone: => 7.10.1 Comment: Setting high priority because this is (apparently) a regression. If the powers that be think it should be this way, then they can of course close the ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 19:35:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 19:35:10 -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.0cb04d486d4fa7d82e4d94f508b66c5c@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: worksforme | 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 dfeuer): * status: new => closed * resolution: => worksforme Comment: I just tested with 7.11.20150103 and I couldn't reproduce the problem. I tried {{{ where a = f (undefined :: F a) :: a where a :: a = f (undefined :: F a) --and also where a :: a a = f (undefined :: F a) }}} so unless there's some code missing from this example, it's been fixed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 19:38:58 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 19:38:58 -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.fbd893cf2b2d8c32838c1a32fa644834@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.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: | -------------------------------------+------------------------------------- Changes (by rwbarton): * status: closed => new * resolution: worksforme => Comment: Did you try the original program in the ticket? I get an error with 7.11.20150112. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 19:43:56 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 19:43:56 -0000 Subject: [GHC] #10010: LLVM/optimized code for sqrt incorrect for negative values Message-ID: <044.d19bdbb75724dc36db07410233c6837c@haskell.org> #10010: LLVM/optimized code for sqrt incorrect for negative values -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 (LLVM) | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The LLVM sqrt intrinsic is undefined below values of -0.0 See http://llvm.org/docs/LangRef.html#llvm-sqrt-intrinsic In some versions of LLVM it returns 0.0 in this case, but in newer versions the return value is undefined. This causes the result of Haskell's sqrt to vary at negative values based on the codegen and optimization flags chosen. {{{ main = print (sqrt (-7 :: Double)) }}} {{{ $ ghc -O -fllvm Sqrt.hs [1 of 1] Compiling Main ( Sqrt.hs, Sqrt.o ) Linking Sqrt ... $ ./Sqrt 0.0 $ ghc -O Sqrt.hs [1 of 1] Compiling Main ( Sqrt.hs, Sqrt.o ) Linking Sqrt ... $ ./Sqrt NaN }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 20:18:43 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 20:18:43 -0000 Subject: [GHC] #9990: Top level module identifiers shadow imported identifiers In-Reply-To: <045.c11e3cc3f47fed8ec0b130c48936b6a9@haskell.org> References: <045.c11e3cc3f47fed8ec0b130c48936b6a9@haskell.org> Message-ID: <060.59a7c7066e62b00c4ddd32698d5338f7@haskell.org> #9990: Top level module identifiers shadow imported identifiers -------------------------------------+------------------------------------- Reporter: drb226 | 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: -------------------------------------+------------------------------------- Comment (by alexey_r): Slight extension suggestion: include explicitly imported identifiers together with top-level identifiers. So: 1. if an identifier is imported both explicitly and implicitly, there is no ambiguity; 2. if an identifier is imported explicitly and defined at top-level, there is an ambiguity. Identifiers brought into scope by a `(..)` aren't considered explicitly imported for this purpose (otherwise extending a module could silently change meaning of an identifier). As a side effect, many uses of `hiding` would be no longer necessary. Of course, the pragma's name would have to be changed. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 20:27:20 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 20:27: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.886754c0d0a3c2885f6d7a9a041606e1@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.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: | -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:3 rwbarton]: > Did you try the original program in the ticket? I get an error with 7.11.20150112. I misread; sorry! I thought the problem was when it was uncommented. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 20:47:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 20:47:30 -0000 Subject: [GHC] #9926: Restore INSTALL file in src dist In-Reply-To: <047.2ac1500d1611590565c97bb128aecaed@haskell.org> References: <047.2ac1500d1611590565c97bb128aecaed@haskell.org> Message-ID: <062.60805b446d041a40567ecd32ba9c5fb4@haskell.org> #9926: Restore INSTALL file in src dist -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Documentation | Version: 7.10.1-rc1 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 thoughtpolice): I actually don't recall this. `git log --follow -- INSTALL` in the root doesn't tell me anything; nonetheless, we could add something I suppose, just adding a new `INSTALL` file to the root directory should do the trick. Would anyone like to try? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 20:58:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 20:58:44 -0000 Subject: [GHC] #9990: Top level module identifiers shadow imported identifiers In-Reply-To: <045.c11e3cc3f47fed8ec0b130c48936b6a9@haskell.org> References: <045.c11e3cc3f47fed8ec0b130c48936b6a9@haskell.org> Message-ID: <060.ca2dc8a2763d1177ccd76e533f209fff@haskell.org> #9990: Top level module identifiers shadow imported identifiers -------------------------------------+------------------------------------- Reporter: drb226 | 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: -------------------------------------+------------------------------------- Comment (by drb226): Another idea is to make a per-binding pragma. {{{#!hs import Data.Monoid {-# SHADOWS (<>) #-} (<>) = mappend main = putStrLn ("Hello" <> " " <> "World") }}} This technique avoids unintended shadowing, intentionally resolves ambiguity by shadowing imports, and shouldn't need to set off the regular shadow warnings. This same technique could also be used to annotate imports: {{{#!hs import Foo {-# SHADOWS foo, Bar(..) #-} import OtherFoo }}} Just throwing that idea out there. Unlike `hiding`, the SHADOWS pragma could check to make sure that the replacement actually exists. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 21:10:37 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 21:10:37 -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.6959c73f8b0170de997acd1dc813b4ed@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.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: | -------------------------------------+------------------------------------- Comment (by simonpj): This is a bug. Excellent but report, thank you Adam. Happily I've fixed it. I'm tied up the next day or two, but I'll commit by Thurs night. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 22:30:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 22:30:34 -0000 Subject: [GHC] #9990: Top level module identifiers shadow imported identifiers In-Reply-To: <045.c11e3cc3f47fed8ec0b130c48936b6a9@haskell.org> References: <045.c11e3cc3f47fed8ec0b130c48936b6a9@haskell.org> Message-ID: <060.8cefc731385c933f58daeb3975ac2249@haskell.org> #9990: Top level module identifiers shadow imported identifiers -------------------------------------+------------------------------------- Reporter: drb226 | 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: -------------------------------------+------------------------------------- Comment (by alexey_r): I've added an example of the problem with `(..)` in my comment above; so far as I can see, it applies to `SHADOWS` as well. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 23:09:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 23:09:52 -0000 Subject: [GHC] #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults In-Reply-To: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> References: <044.e54e5ecad8d095611a80bfdfe4263626@haskell.org> Message-ID: <059.ca0c9db85800e62d5c39640cede9c445@haskell.org> #8974: 64 bit windows executable built with ghc-7.9.20140405+LLVM segfaults -------------------------------------+------------------------------------- Reporter: awson | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.12.1 Component: Compiler (LLVM) | Version: 7.9 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: Runtime crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): Do we know exactly why Windows doesn't like 64-bit offsets? Presumably it has some support for this, no? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 23:20:16 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 23:20:16 -0000 Subject: [GHC] #9990: Top level module identifiers shadow imported identifiers In-Reply-To: <045.c11e3cc3f47fed8ec0b130c48936b6a9@haskell.org> References: <045.c11e3cc3f47fed8ec0b130c48936b6a9@haskell.org> Message-ID: <060.ced9ad96322964fa7d98bee2c3856af5@haskell.org> #9990: Top level module identifiers shadow imported identifiers -------------------------------------+------------------------------------- Reporter: drb226 | 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: -------------------------------------+------------------------------------- Comment (by htebalaka): I wrote a proposal for the explicitly imported identifiers case here [1], which was discussed here [2]. #9702 is also relevant. [1] https://www.haskell.org/haskellwiki/PermissiveImportsProposal [2] https://www.haskell.org/pipermail/glasgow-haskell- users/2014-October/025306.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 20 23:56:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 20 Jan 2015 23:56:41 -0000 Subject: [GHC] #10011: The Data instance for Ratio violates internal invariants. Message-ID: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> #10011: The Data instance for Ratio violates internal invariants. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core | Version: 7.10.1-rc1 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I found this when Simon was cleaning up unused dependencies in {{{ https://phabricator.haskell.org/rGHCc409b6f30373535b6eed92e55d4695688d32be9e#10730 }}} The Data instance for Ratio just uses the raw `(:%)` constructor and doesn't check that the result is reduced to normal form. It strikes me that the fix is to add back the Integral constraint on the Data instance and to use `(%)` rather than `(:%)` in the `gfoldl` and `gunfold` code. This restores the invariant and matches the behavior of "virtual constructors" we've used to patch up such problems elsewhere. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 21 00:00:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Jan 2015 00:00:03 -0000 Subject: [GHC] #10011: The Data instance for Ratio violates internal invariants. In-Reply-To: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> References: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> Message-ID: <060.da551da38fa5df519b6fb539e3488df0@haskell.org> #10011: The Data instance for Ratio violates internal invariants. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: Component: Core Libraries | Version: 7.10.1-rc1 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 ekmett: Old description: > I found this when Simon was cleaning up unused dependencies in > > {{{ > https://phabricator.haskell.org/rGHCc409b6f30373535b6eed92e55d4695688d32be9e#10730 > }}} > > The Data instance for Ratio just uses the raw `(:%)` constructor and > doesn't check that the result is reduced to normal form. > > It strikes me that the fix is to add back the Integral constraint on the > Data instance and to use `(%)` rather than `(:%)` in the `gfoldl` and > `gunfold` code. > > This restores the invariant and matches the behavior of "virtual > constructors" we've used to patch up such problems elsewhere. New description: I found this when Simon was cleaning up unused dependencies in https://phabricator.haskell.org/rGHCc409b6f30373535b6eed92e55d4695688d32be9e#10730 The Data instance for Ratio just uses the raw `(:%)` constructor and doesn't check that the result is reduced to normal form. It strikes me that the fix is to add back the Integral constraint on the Data instance and to use `(%)` rather than `(:%)` in the `gfoldl` and `gunfold` code. This restores the invariant and matches the behavior of "virtual constructors" we've used to patch up such problems elsewhere. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 21 00:00:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Jan 2015 00:00:42 -0000 Subject: [GHC] #10011: The Data instance for Ratio violates internal invariants. In-Reply-To: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> References: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> Message-ID: <060.3d6bdbd7bd0c4b51e1899242f0936762@haskell.org> #10011: The Data instance for Ratio violates internal invariants. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.10.1-rc1 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): * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 21 00:01:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Jan 2015 00:01:28 -0000 Subject: [GHC] #10011: The Data instance for Ratio violates internal invariants. In-Reply-To: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> References: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> Message-ID: <060.1f6437ad73df34d5f51536828bff7801@haskell.org> #10011: The Data instance for Ratio violates internal invariants. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.10.1-rc1 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 ekmett): * failure: None/Unknown => Incorrect result at runtime -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 21 05:32:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Jan 2015 05:32:02 -0000 Subject: [GHC] #8131: T7571 with WAY=llvm fails, but not WAY=optllvm In-Reply-To: <052.22eb4f882263987206e929bacae5db28@haskell.org> References: <052.22eb4f882263987206e929bacae5db28@haskell.org> Message-ID: <067.8c2e707325522cb596cd6e1d61356c1d@haskell.org> #8131: T7571 with WAY=llvm fails, but not WAY=optllvm -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: rwbarton Type: bug | Status: infoneeded 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: | llvm/should_compile/T8131 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by bgamari): I've rebased and cleaned up these patches and opened D624 to propose them for merge. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 21 07:24:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Jan 2015 07:24:57 -0000 Subject: [GHC] #10011: The Data instance for Ratio violates internal invariants. In-Reply-To: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> References: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> Message-ID: <060.c3c5ea02f5aef9211021d3077e24d798@haskell.org> #10011: The Data instance for Ratio violates internal invariants. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.10.1-rc1 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: Phab:D625 -------------------------------------+------------------------------------- Changes (by hvr): * status: new => patch * differential: => Phab:D625 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 21 08:16:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Jan 2015 08:16:42 -0000 Subject: [GHC] #8131: T7571 with WAY=llvm fails, but not WAY=optllvm In-Reply-To: <052.22eb4f882263987206e929bacae5db28@haskell.org> References: <052.22eb4f882263987206e929bacae5db28@haskell.org> Message-ID: <067.de5dbb7d3a232f6f4fa5c6f8c1e856f1@haskell.org> #8131: T7571 with WAY=llvm fails, but not WAY=optllvm -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: rwbarton Type: bug | Status: infoneeded 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: | llvm/should_compile/T8131 | Blocking: | Differential Revisions: Phab:D624 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: => Phab:D624 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 21 12:18:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Jan 2015 12:18:13 -0000 Subject: [GHC] #9975: RecordWildcards and PatternSynonyms cause impossible bug In-Reply-To: <049.b13d47e06dcb55d0cee4cf36751dfd3f@haskell.org> References: <049.b13d47e06dcb55d0cee4cf36751dfd3f@haskell.org> Message-ID: <064.1d8949d2dbc0ce5044cdd81a9721bd24@haskell.org> #9975: RecordWildcards and PatternSynonyms cause impossible bug -------------------------------------+------------------------------------- Reporter: gamegoblin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | RecordWildcards PatternSynonyms Type of failure: Compile-time | Architecture: x86_64 crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * cc: cactus (added) * os: MacOS X => Unknown/Multiple * milestone: => 7.10.1 Old description: > When using RecordWildcards with PatternSynonyms, I have found a way to > cause this bug: > > $ /usr/local/bin/ghc-7.10.0.20141222 test.hs > [1 of 1] Compiling Main ( test.hs, test.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 7.10.0.20141222 for x86_64-apple-darwin): > find_tycon > Test > [Test defined at test.hs:6:9, > Test parent:Test defined at test.hs:4:13] > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug > > Here is the full code that causes it: > > {{{#!hs > {-# LANGUAGE RecordWildCards #-} > {-# LANGUAGE PatternSynonyms #-} > data Test = Test { x :: Int } > pattern Test wat = Test { x = wat } > }}} > > If you remove RecordWildCards, the bug does not happen. New description: When using RecordWildcards with PatternSynonyms, I have found a way to cause this bug: {{{ $ /usr/local/bin/ghc-7.10.0.20141222 test.hs [1 of 1] Compiling Main ( test.hs, test.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.20141222 for x86_64-apple-darwin): find_tycon Test [Test defined at test.hs:6:9, Test parent:Test defined at test.hs:4:13] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Here is the full code that causes it: {{{#!hs {-# LANGUAGE RecordWildCards #-} {-# LANGUAGE PatternSynonyms #-} data Test = Test { x :: Int } pattern Test wat = Test { x = wat } }}} If you remove `RecordWildCards`, the bug does not happen. -- Comment: Maybe this was fixed already, as I can't reproduce it anymore with a current `ghc-7.10` snapshot: {{{ $ ghc-7.10.0.20150119 -c test.hs test.hs:4:1: Multiple declarations of ?Test? Declared at: test.hs:3:13 test.hs:4:1 }}} It may be worth bisecting to find out which commit fixed it, unless cactus happens to know already which commit fixed it... -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 21 13:00:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Jan 2015 13:00:31 -0000 Subject: [GHC] #9975: RecordWildcards and PatternSynonyms cause impossible bug In-Reply-To: <049.b13d47e06dcb55d0cee4cf36751dfd3f@haskell.org> References: <049.b13d47e06dcb55d0cee4cf36751dfd3f@haskell.org> Message-ID: <064.0848ed6fbe7d7ad4ac101fdddd0002a2@haskell.org> #9975: RecordWildcards and PatternSynonyms cause impossible bug -------------------------------------+------------------------------------- Reporter: gamegoblin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | RecordWildcards PatternSynonyms Type of failure: Compile-time | Architecture: x86_64 crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by cactus): Is 7.10.1-rc1 properly tagged in Git? I can't seem to find the exact commit corresponding to it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 21 13:37:49 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Jan 2015 13:37:49 -0000 Subject: [GHC] #9975: RecordWildcards and PatternSynonyms cause impossible bug In-Reply-To: <049.b13d47e06dcb55d0cee4cf36751dfd3f@haskell.org> References: <049.b13d47e06dcb55d0cee4cf36751dfd3f@haskell.org> Message-ID: <064.ed5c0d0b97a9638519f613ddc279fb5b@haskell.org> #9975: RecordWildcards and PatternSynonyms cause impossible bug -------------------------------------+------------------------------------- Reporter: gamegoblin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | RecordWildcards PatternSynonyms Type of failure: Compile-time | Architecture: x86_64 crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): cactus, it's not tagged (RCs weren't tagged in the past either), but luckily `ghc --info` nowadays spits out the commit id (and it's contained in the src tarball), so it's: {{{ $ tar xOf ghc-7.10.0.20141222-src.tar.xz --wildcards '*/GIT_COMMIT_ID' a8c556dfca3eca5277615cc2bf9d6c8f1f143c9a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 21 18:30:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Jan 2015 18:30:00 -0000 Subject: [GHC] #10011: The Data instance for Ratio violates internal invariants. In-Reply-To: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> References: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> Message-ID: <060.10eb8c03bb3f6584f59f32a624457366@haskell.org> #10011: The Data instance for Ratio violates internal invariants. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: bug | Status: patch Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.10.1-rc1 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: Phab:D625 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"79b0d0e633af8302d2dd907663a4a231cd889b67/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="79b0d0e633af8302d2dd907663a4a231cd889b67" Restore invariant in `Data (Ratio a)` instance The Data instance for `Ratio` just uses the raw `:%` constructor and doesn't check that the result is reduced to normal form. The fix is to add back the `Integral` constraint on the Data instance (which was dropped in c409b6f30373535) and to use `%` rather than `:%` in the `gfoldl` and `gunfold` implementation. This restores the invariant and matches the behavior of "virtual constructors" we've used to patch up such problems elsewhere. This addresses #10011 Reviewed By: ekmett, austin Differential Revision: https://phabricator.haskell.org/D625 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 21 18:33:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Jan 2015 18:33:16 -0000 Subject: [GHC] #10011: The Data instance for Ratio violates internal invariants. In-Reply-To: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> References: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> Message-ID: <060.e55749eec49f2f4fb41083a861feef76@haskell.org> #10011: The Data instance for Ratio violates internal invariants. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | 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: Phab:D625 -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => closed * resolution: => fixed Comment: merged to ghc-7.10 via dde5561b77b5b5703ddcd43fd8917a12f9d207e5 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 21 19:01:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Jan 2015 19:01:03 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.53185609d66a19cac880eb41d5f878cc@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: arm Operating System: Unknown/Multiple | Test Case: Type of failure: Incorrect result | Blocking: at runtime | Differential Revisions: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by amurrayc): I tried again with the 7.10 rc candidate (7.10.0.20141222) with LLVM 3.4 and got the same error as comment:36. Should this be a new ticket? The original problem seems solved in the simulator build by compiling with 3.4. I left some more details a while back on the list https://www.haskell.org/pipermail/ghc-devs/2014-October/006521.html The error occurs while compiling `libraries/integer- simple/GHC/Integer/Type.hs`. I don't really speak ARM assembly but the error appears to be in the `doubleFromPositive` section. I note that the label LCPI102_0 refers to a point near the beginning of the file and that from http://infocenter.arm.com/help/topic/com.arm.doc.dui0489c/Bcfcdfdd.html it seems that the label in a vldr instruction needs to point somewhere within 1KB of the current instruction. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 21 19:32:46 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Jan 2015 19:32:46 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.05e1d1c2917cc803ba568cd5b72b9c5b@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: arm Operating System: Unknown/Multiple | Test Case: Type of failure: Incorrect result | Blocking: at runtime | Differential Revisions: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by rwbarton): Could you run ghc with `-keep-tmp-files` and attach both the pre- and post-mangling assembly files? (IIRC, these have extensions `.ll_s` and `.s` respectively.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 21 21:13:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Jan 2015 21:13:00 -0000 Subject: [GHC] #10011: The Data instance for Ratio violates internal invariants. In-Reply-To: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> References: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> Message-ID: <060.d9f0ce902bf844879fa6878468c69b0c@haskell.org> #10011: The Data instance for Ratio violates internal invariants. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | 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: Phab:D625 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"22c4d60b0665a15535c0ec9fe0b8e65d2c948e7d/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="22c4d60b0665a15535c0ec9fe0b8e65d2c948e7d" Revert "Restore invariant in `Data (Ratio a)` instance" This reverts commit 79b0d0e633af8302d2dd907663a4a231cd889b67 due to Compile failed (status 256) errors were: [1 of 2] Compiling A ( A.hs, A.o ) [2 of 2] Compiling Main ( T4491.hs, T4491.o ) T4491.hs:19:11: Illegal data constructor name: ???%??? When splicing a TH expression: (GHC.Real.%) 11 2 In the splice: $(dataToExpQ (const Nothing) (5.5 :: Rational)) *** unexpected failure for T4491(normal) Therefore re-opening #10011 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 21 21:14:36 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 21 Jan 2015 21:14:36 -0000 Subject: [GHC] #10011: The Data instance for Ratio violates internal invariants. In-Reply-To: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> References: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> Message-ID: <060.35545b15070fa385363304d3eb3e9861@haskell.org> #10011: The Data instance for Ratio violates internal invariants. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.10.1-rc1 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: Phab:D625 -------------------------------------+------------------------------------- Changes (by hvr): * owner: ekmett => * status: closed => new * resolution: fixed => -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 22 03:35:04 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Jan 2015 03:35:04 -0000 Subject: [GHC] #10012: Cheap-to-compute values aren't pushed into case branches inducing unnecessary register pressure Message-ID: <046.d81887f1f82ecca81477b67bf0ea3214@haskell.org> #10012: Cheap-to-compute values aren't pushed into case branches inducing unnecessary register pressure -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Runtime Unknown/Multiple | performance bug Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- When characterizing bytestring's `Builder` interface[1] I noticed that some benchmarks involving repeated appends (e.g. `Host endian/1MB of Word8 in chunks of 16`) perform inexplicably much worse than others. A glance at the assembly revealed that a large number of `Word8`s are being evaluated and saved to registers, only to be later stored. E.g., ```#!asm # First we evaluate a number of Word8s, saving them in registers movzbl %bl,%ebx leaq 1(%r14),%rcx movzbl %cl,%ecx leaq 2(%r14),%rdx movzbl %dl,%edx leaq 3(%r14),%rsi movzbl %sil,%esi leaq 4(%r14),%r9 movzbl %r9b,%r9d leaq 5(%r14),%r10 movzbl %r10b,%r10d ... # Eventually we run out of registers and start spilling to the stack movq %rax,64(%rsp) leaq 7(%r14),%rax movzbl %al,%eax movq %rbx,72(%rsp) ... # Only after evaluating all of the needed words do we actually consume # them movq %rax,-152(%r12) movq 72(%rsp),%rax movq %rax,-144(%r12) movq 80(%rsp),%rax movq %rax,-136(%r12) movq 88(%rsp),%rax movq %rax,-128(%r12) ... movq %rsi,-56(%r12) movq %r9,-48(%r12) movq %r10,-40(%r12) movq %r11,-32(%r12) movq %r14,-24(%r12) ``` This is due to the fact that the `Word`s are bound outside of a case analysis and GHC is reluctant to push them inside of the branches. The float-in pass will only float a binding into a case if the value is "small" and at least one branch doesn't use the binding. Unfortunately the case expression in question has only two branches. This is demonstrated in the attached testcase. [1] https://github.com/kolmodin/binary/pull/65 [2] https://www.haskell.org/pipermail/ghc-devs/2015-January/007997.html -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 22 03:47:17 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Jan 2015 03:47:17 -0000 Subject: [GHC] #10012: Cheap-to-compute values aren't pushed into case branches inducing unnecessary register pressure In-Reply-To: <046.d81887f1f82ecca81477b67bf0ea3214@haskell.org> References: <046.d81887f1f82ecca81477b67bf0ea3214@haskell.org> Message-ID: <061.fb802304feb37a8c1e010f72c46acb34@haskell.org> #10012: Cheap-to-compute values aren't pushed into case branches inducing unnecessary register pressure -------------------------------------+------------------------------------- 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: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > When characterizing bytestring's `Builder` interface[1] I noticed that > some benchmarks involving repeated appends (e.g. `Host endian/1MB of > Word8 in chunks of 16`) perform inexplicably much worse than others. A > glance at the assembly revealed that a large number of `Word8`s are being > evaluated and saved to registers, only to be later stored. E.g., > > ```#!asm > # First we evaluate a number of Word8s, saving them in registers > movzbl %bl,%ebx > leaq 1(%r14),%rcx > movzbl %cl,%ecx > leaq 2(%r14),%rdx > movzbl %dl,%edx > leaq 3(%r14),%rsi > movzbl %sil,%esi > leaq 4(%r14),%r9 > movzbl %r9b,%r9d > leaq 5(%r14),%r10 > movzbl %r10b,%r10d > ... > # Eventually we run out of registers and start spilling to the stack > movq %rax,64(%rsp) > leaq 7(%r14),%rax > movzbl %al,%eax > movq %rbx,72(%rsp) > ... > > # Only after evaluating all of the needed words do we actually consume > # them > movq %rax,-152(%r12) > movq 72(%rsp),%rax > movq %rax,-144(%r12) > movq 80(%rsp),%rax > movq %rax,-136(%r12) > movq 88(%rsp),%rax > movq %rax,-128(%r12) > ... > movq %rsi,-56(%r12) > movq %r9,-48(%r12) > movq %r10,-40(%r12) > movq %r11,-32(%r12) > movq %r14,-24(%r12) > > ``` > > This is due to the fact that the `Word`s are bound outside of a case > analysis and GHC is reluctant to push them inside of the branches. The > float-in pass will only float a binding into a case if the value is > "small" and at least one branch doesn't use the binding. Unfortunately > the case expression in question has only two branches. > > This is demonstrated in the attached testcase. > > [1] https://github.com/kolmodin/binary/pull/65 > [2] https://www.haskell.org/pipermail/ghc-devs/2015-January/007997.html New description: When characterizing bytestring's `Builder` interface[1] I noticed that some benchmarks involving repeated appends (e.g. `Host endian/1MB of Word8 in chunks of 16`) perform inexplicably much worse than others. A glance at the assembly revealed that a large number of `Word8`s are being evaluated and saved to registers, only to be later stored. E.g., ``` # First we evaluate a number of Word8s, saving them in registers movzbl %bl,%ebx leaq 1(%r14),%rcx movzbl %cl,%ecx leaq 2(%r14),%rdx movzbl %dl,%edx leaq 3(%r14),%rsi movzbl %sil,%esi leaq 4(%r14),%r9 movzbl %r9b,%r9d leaq 5(%r14),%r10 movzbl %r10b,%r10d ... # Eventually we run out of registers and start spilling to the stack movq %rax,64(%rsp) leaq 7(%r14),%rax movzbl %al,%eax movq %rbx,72(%rsp) ... # Only after evaluating all of the needed words do we actually consume # them movq %rax,-152(%r12) movq 72(%rsp),%rax movq %rax,-144(%r12) movq 80(%rsp),%rax movq %rax,-136(%r12) movq 88(%rsp),%rax movq %rax,-128(%r12) ... movq %rsi,-56(%r12) movq %r9,-48(%r12) movq %r10,-40(%r12) movq %r11,-32(%r12) movq %r14,-24(%r12) ``` This is due to the fact that the `Word`s are bound outside of a case analysis and GHC is reluctant to push them inside of the branches. The float-in pass will only float a binding into a case if the value is "small" and at least one branch doesn't use the binding. Unfortunately the case expression in question has only two branches. This is demonstrated in the attached testcase. [1] https://github.com/kolmodin/binary/pull/65 [2] https://www.haskell.org/pipermail/ghc-devs/2015-January/007997.html -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 22 03:48:47 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Jan 2015 03:48:47 -0000 Subject: [GHC] #10012: Cheap-to-compute values aren't pushed into case branches inducing unnecessary register pressure In-Reply-To: <046.d81887f1f82ecca81477b67bf0ea3214@haskell.org> References: <046.d81887f1f82ecca81477b67bf0ea3214@haskell.org> Message-ID: <061.af38d5591ffd510d71227476f9277349@haskell.org> #10012: Cheap-to-compute values aren't pushed into case branches inducing unnecessary register pressure -------------------------------------+------------------------------------- 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: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > When characterizing bytestring's `Builder` interface[1] I noticed that > some benchmarks involving repeated appends (e.g. `Host endian/1MB of > Word8 in chunks of 16`) perform inexplicably much worse than others. A > glance at the assembly revealed that a large number of `Word8`s are being > evaluated and saved to registers, only to be later stored. E.g., > > ``` > # First we evaluate a number of Word8s, saving them in registers > movzbl %bl,%ebx > leaq 1(%r14),%rcx > movzbl %cl,%ecx > leaq 2(%r14),%rdx > movzbl %dl,%edx > leaq 3(%r14),%rsi > movzbl %sil,%esi > leaq 4(%r14),%r9 > movzbl %r9b,%r9d > leaq 5(%r14),%r10 > movzbl %r10b,%r10d > ... > # Eventually we run out of registers and start spilling to the stack > movq %rax,64(%rsp) > leaq 7(%r14),%rax > movzbl %al,%eax > movq %rbx,72(%rsp) > ... > > # Only after evaluating all of the needed words do we actually consume > # them > movq %rax,-152(%r12) > movq 72(%rsp),%rax > movq %rax,-144(%r12) > movq 80(%rsp),%rax > movq %rax,-136(%r12) > movq 88(%rsp),%rax > movq %rax,-128(%r12) > ... > movq %rsi,-56(%r12) > movq %r9,-48(%r12) > movq %r10,-40(%r12) > movq %r11,-32(%r12) > movq %r14,-24(%r12) > > ``` > > This is due to the fact that the `Word`s are bound outside of a case > analysis and GHC is reluctant to push them inside of the branches. The > float-in pass will only float a binding into a case if the value is > "small" and at least one branch doesn't use the binding. Unfortunately > the case expression in question has only two branches. > > This is demonstrated in the attached testcase. > > [1] https://github.com/kolmodin/binary/pull/65 > [2] https://www.haskell.org/pipermail/ghc-devs/2015-January/007997.html New description: When characterizing bytestring's `Builder` interface[1] I noticed that some benchmarks involving repeated appends (e.g. `Host endian/1MB of Word8 in chunks of 16`) perform inexplicably much worse than others. A glance at the assembly revealed that a large number of `Word8`s are being evaluated and saved to registers, only to be later stored. E.g., {{{#asm # First we evaluate a number of Word8s, saving them in registers movzbl %bl,%ebx leaq 1(%r14),%rcx movzbl %cl,%ecx leaq 2(%r14),%rdx movzbl %dl,%edx leaq 3(%r14),%rsi movzbl %sil,%esi leaq 4(%r14),%r9 movzbl %r9b,%r9d leaq 5(%r14),%r10 movzbl %r10b,%r10d ... # Eventually we run out of registers and start spilling to the stack movq %rax,64(%rsp) leaq 7(%r14),%rax movzbl %al,%eax movq %rbx,72(%rsp) ... # Only after evaluating all of the needed words do we actually consume # them movq %rax,-152(%r12) movq 72(%rsp),%rax movq %rax,-144(%r12) movq 80(%rsp),%rax movq %rax,-136(%r12) movq 88(%rsp),%rax movq %rax,-128(%r12) ... movq %rsi,-56(%r12) movq %r9,-48(%r12) movq %r10,-40(%r12) movq %r11,-32(%r12) movq %r14,-24(%r12) }}} This is due to the fact that the `Word`s are bound outside of a case analysis and GHC is reluctant to push them inside of the branches. The float-in pass will only float a binding into a case if the value is "small" and at least one branch doesn't use the binding. Unfortunately the case expression in question has only two branches. This is demonstrated in the attached testcase. [1] https://github.com/kolmodin/binary/pull/65 [2] https://www.haskell.org/pipermail/ghc-devs/2015-January/007997.html -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 22 03:49:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Jan 2015 03:49:10 -0000 Subject: [GHC] #10012: Cheap-to-compute values aren't pushed into case branches inducing unnecessary register pressure In-Reply-To: <046.d81887f1f82ecca81477b67bf0ea3214@haskell.org> References: <046.d81887f1f82ecca81477b67bf0ea3214@haskell.org> Message-ID: <061.006ed0d3f5a2d1d16563b3eec134e9a9@haskell.org> #10012: Cheap-to-compute values aren't pushed into case branches inducing unnecessary register pressure -------------------------------------+------------------------------------- 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: | Differential Revisions: -------------------------------------+------------------------------------- Description changed by bgamari: Old description: > When characterizing bytestring's `Builder` interface[1] I noticed that > some benchmarks involving repeated appends (e.g. `Host endian/1MB of > Word8 in chunks of 16`) perform inexplicably much worse than others. A > glance at the assembly revealed that a large number of `Word8`s are being > evaluated and saved to registers, only to be later stored. E.g., > > {{{#asm > # First we evaluate a number of Word8s, saving them in registers > movzbl %bl,%ebx > leaq 1(%r14),%rcx > movzbl %cl,%ecx > leaq 2(%r14),%rdx > movzbl %dl,%edx > leaq 3(%r14),%rsi > movzbl %sil,%esi > leaq 4(%r14),%r9 > movzbl %r9b,%r9d > leaq 5(%r14),%r10 > movzbl %r10b,%r10d > ... > # Eventually we run out of registers and start spilling to the stack > movq %rax,64(%rsp) > leaq 7(%r14),%rax > movzbl %al,%eax > movq %rbx,72(%rsp) > ... > > # Only after evaluating all of the needed words do we actually consume > # them > movq %rax,-152(%r12) > movq 72(%rsp),%rax > movq %rax,-144(%r12) > movq 80(%rsp),%rax > movq %rax,-136(%r12) > movq 88(%rsp),%rax > movq %rax,-128(%r12) > ... > movq %rsi,-56(%r12) > movq %r9,-48(%r12) > movq %r10,-40(%r12) > movq %r11,-32(%r12) > movq %r14,-24(%r12) > }}} > > This is due to the fact that the `Word`s are bound outside of a case > analysis and GHC is reluctant to push them inside of the branches. The > float-in pass will only float a binding into a case if the value is > "small" and at least one branch doesn't use the binding. Unfortunately > the case expression in question has only two branches. > > This is demonstrated in the attached testcase. > > [1] https://github.com/kolmodin/binary/pull/65 > [2] https://www.haskell.org/pipermail/ghc-devs/2015-January/007997.html New description: When characterizing bytestring's `Builder` interface[1] I noticed that some benchmarks involving repeated appends (e.g. `Host endian/1MB of Word8 in chunks of 16`) perform inexplicably much worse than others. A glance at the assembly revealed that a large number of `Word8`s are being evaluated and saved to registers, only to be later stored. E.g., {{{#!asm # First we evaluate a number of Word8s, saving them in registers movzbl %bl,%ebx leaq 1(%r14),%rcx movzbl %cl,%ecx leaq 2(%r14),%rdx movzbl %dl,%edx leaq 3(%r14),%rsi movzbl %sil,%esi leaq 4(%r14),%r9 movzbl %r9b,%r9d leaq 5(%r14),%r10 movzbl %r10b,%r10d ... # Eventually we run out of registers and start spilling to the stack movq %rax,64(%rsp) leaq 7(%r14),%rax movzbl %al,%eax movq %rbx,72(%rsp) ... # Only after evaluating all of the needed words do we actually consume # them movq %rax,-152(%r12) movq 72(%rsp),%rax movq %rax,-144(%r12) movq 80(%rsp),%rax movq %rax,-136(%r12) movq 88(%rsp),%rax movq %rax,-128(%r12) ... movq %rsi,-56(%r12) movq %r9,-48(%r12) movq %r10,-40(%r12) movq %r11,-32(%r12) movq %r14,-24(%r12) }}} This is due to the fact that the `Word`s are bound outside of a case analysis and GHC is reluctant to push them inside of the branches. The float-in pass will only float a binding into a case if the value is "small" and at least one branch doesn't use the binding. Unfortunately the case expression in question has only two branches. This is demonstrated in the attached testcase. [1] https://github.com/kolmodin/binary/pull/65 [2] https://www.haskell.org/pipermail/ghc-devs/2015-January/007997.html -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 22 09:41:21 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Jan 2015 09:41:21 -0000 Subject: [GHC] #9975: RecordWildcards and PatternSynonyms cause impossible bug In-Reply-To: <049.b13d47e06dcb55d0cee4cf36751dfd3f@haskell.org> References: <049.b13d47e06dcb55d0cee4cf36751dfd3f@haskell.org> Message-ID: <064.672aaa4fe4d7b3f7ea63ba4e1cb873d4@haskell.org> #9975: RecordWildcards and PatternSynonyms cause impossible bug -------------------------------------+------------------------------------- Reporter: gamegoblin | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | RecordWildcards PatternSynonyms Type of failure: Compile-time | Architecture: x86_64 crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"3992a6e2d0fa2f046baaf14c264d21acf9540c83/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3992a6e2d0fa2f046baaf14c264d21acf9540c83" Test Trac #9975 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 22 09:51:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Jan 2015 09:51:08 -0000 Subject: [GHC] #10012: Cheap-to-compute values aren't pushed into case branches inducing unnecessary register pressure In-Reply-To: <046.d81887f1f82ecca81477b67bf0ea3214@haskell.org> References: <046.d81887f1f82ecca81477b67bf0ea3214@haskell.org> Message-ID: <061.afb8cb8072d462c4c1868a4c48b9e76b@haskell.org> #10012: Cheap-to-compute values aren't pushed into case branches inducing unnecessary register pressure -------------------------------------+------------------------------------- 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: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Here's some more dialogue between Ben and me: > I think you are talking about code like this: {{{ let t1=e1; t2=e2; ...; tn=en in if ... then do { write r1a t1; ...; write rna tn } else do { write r1b t1; ...; write rnb tn } }}} > What you would prefer is to *duplicate* the ti=ei bindings, and sink them really close to their consumers. (NB: That can sometimes *increase* register pressure if ei have lots of free variables.) > > Correct? Correct. > Question: the ti=ei bindings are used in both branches of the conditional. Did they begin duplicated, and became shared by CSE? Or did they start shared? If the latter, it becomes delicate indeed: duplicating work to (hopefully) improve (but possible worsen) register pressure seems dodgy. Unfortunately they started shared. This code is sadly a bit difficult to optimize. The case analysis in question examines whether there is enough room in a buffer to accomoate the requested data to be written; the bindings being shared are the values to be written to the buffer. If there is room in the buffer then we perform the write immediately; otherwise we return a closure so that the user can continue writing into a new buffer. This situation affects performance in a rather unfortunate way: in principle we should be able to perform better the more data we statically know needs to be written. Unfortunately, as it stands now, the more data we write, the more performance suffers due to register pressure -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 22 10:29:50 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Jan 2015 10:29:50 -0000 Subject: [GHC] #9856: Test suite regressions due to integer-gmp2 In-Reply-To: <046.46e84cf4a8b5d1f50db00f57d7053a13@haskell.org> References: <046.46e84cf4a8b5d1f50db00f57d7053a13@haskell.org> Message-ID: <061.c53f2ac67dc47f14c83ac31111faa94b@haskell.org> #9856: Test suite regressions due to integer-gmp2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Test Suite | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: prof-doc- Related Tickets: | fib linker_unload | Blocking: | Differential Revisions: Phab:D82 -------------------------------------+------------------------------------- Changes (by nomeata): * owner: simonmar => * status: closed => new * resolution: fixed => Comment: Unfortunately, it did not fix it on my build machine: {{{ Stdout: Stderr: linker_unload: /data1/ghc-builder/logs/ghc-tmp-REV/libraries/integer-gmp2 /dist-install/build/libHSinteg_6zeGtnFHpaVBJ80QaL9uVu.a: unknown symbol `__gmpn_rshift' linker_unload: resolveObjs failed make[3]: *** [linker_unload] Fehler 1 *** unexpected failure for linker_unload(normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 22 10:56:51 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Jan 2015 10:56:51 -0000 Subject: [GHC] #9975: RecordWildcards and PatternSynonyms cause impossible bug In-Reply-To: <049.b13d47e06dcb55d0cee4cf36751dfd3f@haskell.org> References: <049.b13d47e06dcb55d0cee4cf36751dfd3f@haskell.org> Message-ID: <064.06113de4b9ef319391ea137829a1dd95@haskell.org> #9975: RecordWildcards and PatternSynonyms cause impossible bug -------------------------------------+------------------------------------- Reporter: gamegoblin | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | RecordWildcards PatternSynonyms Type of failure: Compile-time | Architecture: x86_64 crash | (amd64) Blocked By: | Test Case: Related Tickets: | patsyn/should_compile/T9975a,b | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * testcase: => patsyn/should_compile/T9975a,b * resolution: => fixed Comment: I'm not sure what fixed it, but I'm content to let sleeping dogs lie. I've added a regression test though. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 22 11:39:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Jan 2015 11:39:29 -0000 Subject: [GHC] #9856: Test suite regressions due to integer-gmp2 In-Reply-To: <046.46e84cf4a8b5d1f50db00f57d7053a13@haskell.org> References: <046.46e84cf4a8b5d1f50db00f57d7053a13@haskell.org> Message-ID: <061.e485a0e06daf43c5a90ad2b5a76c0661@haskell.org> #9856: Test suite regressions due to integer-gmp2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: merge Priority: normal | Milestone: 7.10.1 Component: Test Suite | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: prof-doc- Related Tickets: | fib linker_unload | Blocking: | Differential Revisions: Phab:D82 -------------------------------------+------------------------------------- Changes (by nomeata): * status: new => merge Comment: Sorry, got confused and were looking at an old log. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 22 13:04:19 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Jan 2015 13:04:19 -0000 Subject: [GHC] #9858: Typeable instances should be kind-aware (was: Typeable instance for datatype and its promoted constructor is the same) In-Reply-To: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> References: <046.ac4644068004277d3020f08b407cc0cb@haskell.org> Message-ID: <061.fb37ef302e527431dbc4e82a288ff4cc@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by simonpj): Richard is spot on. For (1), really `A` and `'A` are entirely different, and should not compare as equal. That is probably easy to fix, by changing the fingerprint we generate for `'A`. For (2), yes absolultely, just as `Maybe Int` and `Maybe Bool` should have non-equal `TypeRep`s, so should `B 'Ordering` and `B 'Bool`. The fact that is's a kind application isn't important. The ''reason'' that bug (2) happens is, I think, that the `Typeable` instance of `B` is generated by an instance declaration: {{{ instance Typeable B where typeRep# _ = ...the TyCon for B.... }}} This instance declaration is treated as ''source code'', and source code does implicit kind instantiation. So we actually get {{{ dfun :: forall k. Typeable (B k) dfun = /\k. MkTypeableDict (...TyCon for B....) }}} We don't want this! Instead we want to treat `(B 'Bool)` just like `Maybe Bool`, using the application instance (in `Data.Typeable.Internals`), which looks roughly like this: {{{ instance (Typeable s, Typeable a) => Typeable (s a) where -- See Note [The apparent incoherence of Typable] typeRep# _ = typeRep a `mkAppTy` typeRep b }}} We would like this to be done for ''kind'' applications as well as ''type'' applications. So we need two changes * For type constructors, we need an instance that truly matches on `B` not on `B k` * We need to decompose kind applications as we do type applications. To me it seems clear that we should move to treating `Typeable` more like we treat `Coercible`, i.e. as a built-in type class that the constraint solver knows how to solve, rather than as something handed with source- level instance declarations. That would imply: * There would be no `Typeable` instances in the instance environment (which itself would be a modest saving). * Either 1. every data type constructor automatically has a `Typeable` instance (which I favour), or 1. we'd need a tiresome separate mechanism (a flag in the `TyCon`) to say whether it does or does not have a `Typeable` instance. Note that this path might ultimately allow us to have a `TypeRep` for a polymorphic type, which we can't do right now. What do people feel about (1) vs (2)? Why would we ever want a type ''not'' to be `Typeable`? Note that the code-size overhead is modest: a single top-level definition of a record defining the `TyCon`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 22 13:36:38 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Jan 2015 13:36:38 -0000 Subject: [GHC] #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess In-Reply-To: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> References: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> Message-ID: <059.46b476d537ab1637846b3099738a44f3@haskell.org> #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.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: #9377 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by edsko): Guys, I'm not sure that we deal with this entirely correctly still. Sadly, I have no test case other than to tell you that I was just compiling a project with 7.10 and I got: {{{ ghc-stage2: ioManagerWakeup: write: Bad file descriptor }}} :-/ -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 22 13:52:26 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Jan 2015 13:52:26 -0000 Subject: [GHC] #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess In-Reply-To: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> References: <044.6ceec8e11436607dc61cafb5fc8ba3a5@haskell.org> Message-ID: <059.81457f6282e087cc9dc4feb42c72d7e6@haskell.org> #9284: shutdownCapability sometimes loops indefinitely on OSX after forkProcess -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.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: #9377 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonmar): @edsko: head on over to #9722 with that. There is possibly a nondeterministic bug in the shutdown code that was introduced with the latest fix, but we haven't been able to get a reproducible enough test case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 22 13:53:23 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Jan 2015 13:53:23 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.2697dd2ac4570f74dabc00ff607ea793@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: ghcirun004 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by edsko): * cc: edsko (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 22 13:54:47 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Jan 2015 13:54:47 -0000 Subject: [GHC] #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor In-Reply-To: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> References: <045.2ac77d27a9a71df853ff4839dd3c18d0@haskell.org> Message-ID: <060.081d13c94385a8352105d3d46f0628bb@haskell.org> #9722: ghcirun004 intermittently fails with ghc: ioManagerWakeup: write: Bad file descriptor -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: GHCi | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: ghcirun004 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by edsko): Just FYI, I just saw this while using 7.10 to compile my project. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 22 14:02:36 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Jan 2015 14:02:36 -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.2f672dcc600c822f998cb78dd06d67d0@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by goldfire): I vote for Simon's option 1 -- just make runtime type identification a feature of GHC Haskell, exposed through the `Typeable` interface. This will take a small amount of work to engineer, but I think the end state will be simpler than what we have now, and likely more efficient. I will point out one drawback: I believe users will be confused about the need for `Typeable` constraints. After all, if ''every'' type is `Typeable`, then why include the constraint? We cognoscenti know that the `Typeable` constraint is just implicitly passing the runtime witness, but we'll have to be careful to explain this to those who think that class constraints are all about logical statements, not implicit type-determined parameters. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 22 14:30:07 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Jan 2015 14:30:07 -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.03220f04b287ab0b98ae468362453a88@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by crockeea): Replying to [comment:21 goldfire]: > I will point out one drawback: I believe users will be confused about the need for `Typeable` constraints. After all, if ''every'' type is `Typeable`, then why include the constraint? We cognoscenti know that the `Typeable` constraint is just implicitly passing the runtime witness, but we'll have to be careful to explain this to those who think that class constraints are all about logical statements, not implicit type-determined parameters. After using Haskell for several years, that ''still'' trips me up. If you are able to make everything `Typeable`, might there be a way to make the `Typeable` constraint implicit, at least when it's needed? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 22 16:20:20 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Jan 2015 16:20:20 -0000 Subject: [GHC] #10013: GHC 7.8.4 panics while building "vty" library test suite Message-ID: <045.685a7537da4fa30800a5361f16e8fb5a@haskell.org> #10013: GHC 7.8.4 panics while building "vty" library test suite -------------------------------------+------------------------------------- Reporter: simons | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Linux Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{ Linking dist/build/verify-attribute-opsStub/verify-attribute-opsStub ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): Don't understand library name verify-attribute-ops }}} A complete build log is available at http://hydra.nixos.org/build/18786125/log/raw. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 22 16:43:13 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Jan 2015 16:43:13 -0000 Subject: [GHC] #10013: GHC 7.8.4 panics while building "vty" library test suite In-Reply-To: <045.685a7537da4fa30800a5361f16e8fb5a@haskell.org> References: <045.685a7537da4fa30800a5361f16e8fb5a@haskell.org> Message-ID: <060.d05340e8df676df8587537c1ec125186@haskell.org> #10013: GHC 7.8.4 panics while building "vty" library test suite -------------------------------------+------------------------------------- Reporter: simons | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: duplicate | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: https://ghc.haskell.org/trac/ghc/ticket/9625| -------------------------------------+------------------------------------- Changes (by simons): * status: new => closed * resolution: => duplicate * related: => https://ghc.haskell.org/trac/ghc/ticket/9625 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 22 21:05:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Jan 2015 21:05:08 -0000 Subject: [GHC] #8796: -ddump-splices prints to error stream In-Reply-To: <048.8c2bd8579518c0499fec07b9017bf6e1@haskell.org> References: <048.8c2bd8579518c0499fec07b9017bf6e1@haskell.org> Message-ID: <063.6df06396d273028921858ce8a3dfc870@haskell.org> #8796: -ddump-splices prints to error stream -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: qnikst Type: bug | Status: new Priority: normal | 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:627 -------------------------------------+------------------------------------- Changes (by qnikst): * owner: => qnikst * differential: => Phab:627 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 22 21:17:06 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Jan 2015 21:17:06 -0000 Subject: [GHC] #10014: Data.Array.Base.elems needlessly calls bounds. Message-ID: <045.0294d47a72574992ce1409b67b846198@haskell.org> #10014: Data.Array.Base.elems needlessly calls bounds. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Core | Operating System: Unknown/Multiple Libraries | Type of failure: Runtime Keywords: | performance bug Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{ elems arr = case bounds arr of (_l, _u) -> [unsafeAt arr i | i <- [0 .. numElements arr - 1]] }}} It never uses the result. I'd propose simplifying it to {{{ elems arr = [unsafeAt arr i | i <- [0 .. numElements arr - 1]] }}} It appears at some point someone optimized it to use the `unsafeAt`, but never removed the bounds check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 22 21:35:42 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Jan 2015 21:35:42 -0000 Subject: [GHC] #10011: The Data instance for Ratio violates internal invariants. In-Reply-To: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> References: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> Message-ID: <060.cb10b93dc61d2eabefa61523af91306a@haskell.org> #10011: The Data instance for Ratio violates internal invariants. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.10.1-rc1 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: Phab:D625 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"3df429e29b6fabda12af71091ba4ad1360f49b44/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="3df429e29b6fabda12af71091ba4ad1360f49b44" Restore invariant in `Data (Ratio a)` instance (2nd attempt, this time leaving the `Constr` using `":%"`) The Data instance for `Ratio` just uses the raw `:%` constructor and doesn't check that the result is reduced to normal form. The fix is to add back the `Integral` constraint on the Data instance (which was dropped in c409b6f30373535) and to use `%` rather than `:%` in the `gfoldl` and `gunfold` implementation. This restores the invariant and matches the behavior of "virtual constructors" we've used to patch up such problems elsewhere. This addresses #10011 Reviewed By: ekmett, austin Differential Revision: https://phabricator.haskell.org/D625 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 22 22:18:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Jan 2015 22:18:48 -0000 Subject: [GHC] #9389: Full Test Suite Failures In-Reply-To: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> References: <042.38f06884e0da53a793f9dd734d87a005@haskell.org> Message-ID: <057.7dbb089ff51257b94ba0a5e74b31fd89@haskell.org> #9389: Full Test Suite Failures -------------------------------------+------------------------------------- Reporter: jrp | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Test Suite | Version: 7.8.3 Resolution: | Keywords: Operating System: MacOS X | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: #9286,#8756,#7876,#7877 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by jrp): Today's results ({{{perf}}} BuildFlavour): {{{ OVERALL SUMMARY for test run started at Thu Jan 22 19:36:52 2015 GMT 0:34:34 spent to go through 4405 total tests, which gave rise to 18011 test cases, of which 3603 were skipped 328 had missing libraries 13819 expected passes 139 expected failures 0 caused framework failures 0 unexpected passes 116 unexpected failures 6 unexpected stat failures Unexpected failures: ../../libraries/base/tests enum01 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) ../../libraries/base/tests enum01 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum02 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) ../../libraries/base/tests enum02 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum03 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) ../../libraries/base/tests enum03 [bad stdout or stderr] (ghci) ../../libraries/base/tests topHandler01 [bad exit code] (threaded1) ../../libraries/base/tests topHandler01 [bad stdout or stderr] (ghci) ../../libraries/process/tests process011 [bad exit code] (threaded1,threaded2,profthreaded) ../../libraries/process/tests process011 [bad stdout or stderr] (ghci) ../../libraries/unix/tests signals002 [bad stdout] (threaded1,threaded2,profthreaded) ../../libraries/unix/tests signals002 [bad stdout or stderr] (ghci) annotations/should_run annrun01 [bad stdout or stderr] (ghci) cabal/sigcabal01 sigcabal01 [bad stderr] (normal) codeGen/should_run CgStaticPointers [bad stdout or stderr] (ghci) concurrent/should_run T5611 [bad stdout] (profasm) concurrent/should_run allocLimit4 [bad exit code] (ghci) concurrent/should_run conc012 [bad exit code] (ghci) concurrent/should_run conc059 [bad stderr] (threaded1,threaded2) deSugar/should_run DsStaticPointers [bad stdout or stderr] (ghci) deSugar/should_run dsrun014 [bad exit code] (ghci) driver/objc objc-hi [bad profile] (profthreaded) driver/objc objc-hi [bad heap profile] (profasm) driver/objc objcpp-hi [bad profile] (profthreaded) driver/objc objcpp-hi [bad heap profile] (profasm) driver/retc001 retc001 [bad stderr] (normal) ghci/scripts ghci024 [bad stdout] (normal) numeric/should_run add2 [bad exit code] (ghci) numeric/should_run mul2 [bad exit code] (ghci) numeric/should_run quotRem2 [bad exit code] (ghci) parser/should_run readRun004 [bad exit code] (ghci) profiling/should_run T2552 [bad profile] (profasm,profthreaded) profiling/should_run callstack001 [bad stdout] (prof) profiling/should_run ioprof [bad profile] (profasm,profthreaded) profiling/should_run prof-doc-fib [bad profile] (profasm,profthreaded,prof) profiling/should_run scc001 [bad profile] (prof) quasiquotation/qq007 qq007 [exit code non-0] (profasm) quasiquotation/qq008 qq008 [exit code non-0] (profasm) rts GcStaticPointers [bad stdout or stderr] (ghci) rts ListStaticPointers [bad stdout or stderr] (ghci) rts T7919 [bad exit code] (optasm,dyn) rts T7919 [exit code non-0] (profasm,profthreaded) rts T9078 [exit code non-0] (profasm) rts derefnull [bad profile] (profasm,profthreaded) rts divbyzero [bad profile] (profasm,profthreaded) rts linker_unload [bad exit code] (normal) rts overflow1 [bad profile] (profasm,profthreaded) rts overflow2 [bad profile] (profasm,profthreaded) rts overflow3 [bad profile] (profasm,profthreaded) simplCore/should_compile T5550 [exit code non-0] (profasm) th TH_StaticPointers [bad stdout or stderr] (ghci) typecheck/should_run T3500a [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) typecheck/should_run T3500a [bad stdout or stderr] (ghci) typecheck/should_run T5751 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) typecheck/should_run T5751 [bad stdout or stderr] (ghci) typecheck/should_run T7126 [exit code non-0] (normal,hpc,optasm,profasm,threaded1,threaded2,dyn,profthreaded) typecheck/should_run T7126 [bad stdout or stderr] (ghci) typecheck/should_run tcrun045 [stderr mismatch] (normal) Unexpected stat failures: perf/compiler T1969 [stat not good enough] (normal) perf/compiler T5642 [stat not good enough] (normal) perf/compiler T783 [stat not good enough] (normal) perf/compiler T9675 [stat not good enough] (optasm) perf/should_run T9203 [stat too good] (normal) simplCore/should_compile T7702 [stat too good] (profasm) }}} and {{{validate --slow}}} gives: {{{ OVERALL SUMMARY for test run started at Thu Jan 22 21:16:02 2015 GMT 0:25:08 spent to go through 4405 total tests, which gave rise to 14234 test cases, of which 2726 were skipped 267 had missing libraries 11018 expected passes 149 expected failures 0 caused framework failures 0 unexpected passes 74 unexpected failures 0 unexpected stat failures Unexpected failures: ../../libraries/base/tests enum01 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) ../../libraries/base/tests enum01 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum02 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) ../../libraries/base/tests enum02 [bad stdout or stderr] (ghci) ../../libraries/base/tests enum03 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) ../../libraries/base/tests enum03 [bad stdout or stderr] (ghci) ../../libraries/base/tests topHandler01 [bad exit code] (threaded1) ../../libraries/base/tests topHandler01 [bad stdout or stderr] (ghci) ../../libraries/base/tests topHandler03 [bad exit code] (ghci) ../../libraries/process/tests process011 [bad exit code] (threaded1,threaded2) ../../libraries/process/tests process011 [bad stdout or stderr] (ghci) ../../libraries/unix/tests signals002 [bad stdout] (threaded1,threaded2) ../../libraries/unix/tests signals002 [bad stdout or stderr] (ghci) cabal/sigcabal01 sigcabal01 [bad stderr] (normal) codeGen/should_run CgStaticPointers [bad stdout or stderr] (ghci) concurrent/should_run allocLimit4 [bad exit code] (ghci) concurrent/should_run conc012 [bad exit code] (ghci) concurrent/should_run conc059 [bad stderr] (threaded1,threaded2) deSugar/should_run DsStaticPointers [bad stdout or stderr] (ghci) deSugar/should_run dsrun014 [bad exit code] (ghci) driver/retc001 retc001 [bad exit code] (normal) driver/retc002 retc002 [bad exit code] (normal) ghci/scripts ghci024 [bad stdout] (normal) numeric/should_run add2 [bad exit code] (ghci) numeric/should_run mul2 [bad exit code] (ghci) numeric/should_run quotRem2 [bad exit code] (ghci) parser/should_run readRun004 [bad exit code] (ghci) rts GcStaticPointers [bad stdout or stderr] (ghci) rts ListStaticPointers [bad stdout or stderr] (ghci) rts T7919 [bad exit code] (optasm,threaded2,dyn) rts linker_unload [bad exit code] (normal) th TH_StaticPointers [bad stdout or stderr] (ghci) typecheck/should_run T3500a [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run T3500a [bad stdout or stderr] (ghci) typecheck/should_run T5751 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run T5751 [bad stdout or stderr] (ghci) typecheck/should_run T7126 [exit code non-0] (normal,hpc,optasm,threaded1,threaded2,dyn) typecheck/should_run T7126 [bad stdout or stderr] (ghci) typecheck/should_run tcrun045 [stderr mismatch] (normal) }}} whereas {{{validate --fast}}} paints a rosier picture: {{{ OVERALL SUMMARY for test run started at Thu Jan 22 22:10:03 2015 GMT 0:06:07 spent to go through 4405 total tests, which gave rise to 14230 test cases, of which 10172 were skipped 52 had missing libraries 3932 expected passes 71 expected failures 0 caused framework failures 0 unexpected passes 3 unexpected failures 0 unexpected stat failures Unexpected failures: cabal/sigcabal01 sigcabal01 [bad stderr] (normal) driver/retc001 retc001 [bad stderr] (normal) rts linker_unload [bad exit code] (normal) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 22 22:21:35 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Jan 2015 22:21:35 -0000 Subject: [GHC] #10014: Data.Array.Base.elems needlessly calls bounds. In-Reply-To: <045.0294d47a72574992ce1409b67b846198@haskell.org> References: <045.0294d47a72574992ce1409b67b846198@haskell.org> Message-ID: <060.4e270bfbc9079e47a052cfe8b1c3d42f@haskell.org> #10014: Data.Array.Base.elems needlessly calls bounds. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | 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: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hvr): Replying to [ticket:10014 ekmett]: > It appears at some point someone optimized it to use the `unsafeAt`, but never removed the bounds check. that happened here: https://git.haskell.org/packages/array.git/commitdiff/0c4b7d714dd82072ea95c5973dc7160428b93235 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 22 23:12:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 22 Jan 2015 23:12:54 -0000 Subject: [GHC] #10011: The Data instance for Ratio violates internal invariants. In-Reply-To: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> References: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> Message-ID: <060.d0585faf1787f4c8033a5264d8820aad@haskell.org> #10011: The Data instance for Ratio violates internal invariants. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.10.1-rc1 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: Phab:D625 -------------------------------------+------------------------------------- Comment (by simonpj): So is this done now? Do we need a regression test? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 23 00:13:47 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Jan 2015 00:13:47 -0000 Subject: [GHC] #10011: The Data instance for Ratio violates internal invariants. In-Reply-To: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> References: <045.47434706ea6538b2b181a57a7e77b292@haskell.org> Message-ID: <060.5adca75edc2e478d4872b26f78567a28@haskell.org> #10011: The Data instance for Ratio violates internal invariants. -------------------------------------+------------------------------------- Reporter: ekmett | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.10.1-rc1 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: Phab:D625 -------------------------------------+------------------------------------- Comment (by ekmett): This work scoped in this ticket is done, but you are right, we should definitely add a regression test to ensure this doesn't backslide in the future. Along the way we found a much less critical, but related issue (ok, really, feature request), which I'll file a separate ticket for -- with an eye towards fixing it on a longer time horizon: I'd eventually like to fix up the "virtual" data constructor we talk about in the Data instance to use `(%)`, since we're using a virtual constructor here, and that would let `gshow` and the like do the right thing, but when we tried that as part of this patch, the fact that `dataToExpQ` currently filters out things that are illegal constructors caused a test failure. Fixing _that_ is a big enough issue to punt to 7.12. Fixing that right might also let us fix things like dataToExpQ for things like Maps, Sets, and other containers that also have to use the virtual constructor model to preserve internal invariants, which would be a pretty big boon to heavy users of template haskell. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 23 02:08:31 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Jan 2015 02:08:31 -0000 Subject: [GHC] #10015: Give the DLL loader awareness of rpaths Message-ID: <047.87a2d7da531533923ef75de3db489dab@haskell.org> #10015: Give the DLL loader awareness of rpaths -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: MacOS X Keywords: | Type of failure: None/Unknown Architecture: x86_64 | Blocked By: (amd64) | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This is nix-related. I'm trying to build with the nix version of libiconv instead of system libiconv, and to facilitate this I'm running package builds in a sandbox. If I try to compile a module using TemplateHaskell, say {{{#!hs module Main where main :: IO () main = putStrLn $([|"Hello, world!"|]) }}} I get this from ghc --make: [1 of 1] Compiling Main ( main.hs, main.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... : can't load .so/.DLL for: libiconv.dylib (dlopen(libiconv.dylib, 9): no suitable image found. Did find: /usr/lib/libiconv.dylib: stat() failed with errno=1) When of course I'd rather it just try to dlopen /nix/store /lsvxsyw9w17d2rix740akjxyxcacgi3k-libiconv-41/lib/libiconv.dylib, the one it was built with. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 23 10:08:09 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Jan 2015 10:08:09 -0000 Subject: [GHC] #9949: zipWith too strict in second argument in GHC-7.10.0 In-Reply-To: <046.a512e03368163c43178326fd94163813@haskell.org> References: <046.a512e03368163c43178326fd94163813@haskell.org> Message-ID: <061.606cd8413e08ce7a55b0fb2a494dc712@haskell.org> #9949: zipWith too strict in second argument in GHC-7.10.0 -------------------------------------+------------------------------------- Reporter: Lemming | Owner: ekmett Type: bug | Status: patch Priority: highest | Milestone: 7.10.1 Component: Core Libraries | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9495 | Blocking: | Differential Revisions: Phab:D602 -------------------------------------+------------------------------------- Comment (by Herbert Valerio Riedel ): In [changeset:"f44bbc83bab62f9a2d25e69d87c2b4af25318d52/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="f44bbc83bab62f9a2d25e69d87c2b4af25318d52" Revert zipWith strictification (re #9949) Also remove foldr2/right rule to avoid possibly introducing bottoms with rules. This effectively reverts most of 488e95b433d4f7568aa89622c729e64aa3b6520d Reviewed By: nomeata Differential Revision: https://phabricator.haskell.org/D602 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 23 10:11:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Jan 2015 10:11:10 -0000 Subject: [GHC] #9949: zipWith too strict in second argument in GHC-7.10.0 In-Reply-To: <046.a512e03368163c43178326fd94163813@haskell.org> References: <046.a512e03368163c43178326fd94163813@haskell.org> Message-ID: <061.07e975582ee629eb1882f6080ae4d355@haskell.org> #9949: zipWith too strict in second argument in GHC-7.10.0 -------------------------------------+------------------------------------- Reporter: Lemming | Owner: ekmett Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Core Libraries | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime crash | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9495 | Blocking: | Differential Revisions: Phab:D602 -------------------------------------+------------------------------------- Changes (by hvr): * status: patch => closed * resolution: => fixed Comment: merged to ghc-7.10 via 19ad227fbfa23f64f7422751b9559b4ac44d5081 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 23 12:56:47 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Jan 2015 12:56:47 -0000 Subject: [GHC] #9953: Pattern synonyms don't work with GADTs In-Reply-To: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> References: <046.f514a3e84b371ad4090779bf78d62314@haskell.org> Message-ID: <061.176fb22e84087109c6c710be3775dd38@haskell.org> #9953: Pattern synonyms don't work with GADTs -------------------------------------+------------------------------------- Reporter: simonpj | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.10.1-rc1 checker) | Keywords: Resolution: fixed | PatternSynonyms 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 Comment: Merged to `ghc-7.10` (via 53af4bb5cd4531f0615a2a60b6d213495261e41a). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 23 12:57:10 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Jan 2015 12:57:10 -0000 Subject: [GHC] #9856: Test suite regressions due to integer-gmp2 In-Reply-To: <046.46e84cf4a8b5d1f50db00f57d7053a13@haskell.org> References: <046.46e84cf4a8b5d1f50db00f57d7053a13@haskell.org> Message-ID: <061.77e0586e38034ce7628e30f479e40789@haskell.org> #9856: Test suite regressions due to integer-gmp2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Test Suite | Version: 7.9 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: prof-doc- Related Tickets: | fib linker_unload | Blocking: | Differential Revisions: Phab:D82 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10` (via 7f9704f49525e0e0ec556f5d003914e66b11e437). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 23 12:57:37 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Jan 2015 12:57:37 -0000 Subject: [GHC] #9955: ghc-stage1 compiles with bootstrapping ghc package, not the built one In-Reply-To: <045.2e2f0948ac1cf3246cb798d3962e4df0@haskell.org> References: <045.2e2f0948ac1cf3246cb798d3962e4df0@haskell.org> Message-ID: <060.a054d375f0dcb85f51f0597045cead38@haskell.org> #9955: ghc-stage1 compiles with bootstrapping ghc package, not the built one -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: closed Priority: high | Milestone: 7.10.1 Component: Build System | Version: 7.11 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: Phab:D603 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed Comment: Merged to `ghc-7.10` (via 57df7b312c408338401140474f5afc6951d49cf9). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 23 14:21:00 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Jan 2015 14:21:00 -0000 Subject: [GHC] #10016: UNPACK support for existentials Message-ID: <046.c8a66a042094ff097eced717a1d59a97@haskell.org> #10016: UNPACK support for existentials -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Consider {{{ data Foo = forall a. Show a => Foo !a !a data Bar = Bar {-# UNPACK #-} !Foo }}} The UNPACK pragma should really be able to unpack the `Foo` field, so that (implementation-wise) it would be as if you'd declared `Bar` thus: {{{ data Bar = forall a. Show a => Bar !a !a }}} But currently we get {{{ Ignoring unusable UNPACK pragma on the first argument of ?Bar? }}} Suggested by Nicholas Clarke [https://www.haskell.org/pipermail/glasgow- haskell-users/2015-January/025590.html here]. Vaguely related tickets: #7647, #9214. But unlike those ones, this one looks quite feasible to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 23 14:50:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Jan 2015 14:50:27 -0000 Subject: [GHC] #8796: -ddump-splices prints to error stream In-Reply-To: <048.8c2bd8579518c0499fec07b9017bf6e1@haskell.org> References: <048.8c2bd8579518c0499fec07b9017bf6e1@haskell.org> Message-ID: <063.ca331844554f9c498f7179287bc1e4f6@haskell.org> #8796: -ddump-splices prints to error stream -------------------------------------+------------------------------------- Reporter: jstolarek | Owner: qnikst Type: bug | Status: new Priority: normal | Milestone: 7.12.1 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:D627 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: Phab:627 => Phab:D627 * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 23 15:11:33 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Jan 2015 15:11:33 -0000 Subject: [GHC] #9625: ghc: panic using --enable-executable-dynamic In-Reply-To: <051.41ace47270d90cc9e836ab3706638147@haskell.org> References: <051.41ace47270d90cc9e836ab3706638147@haskell.org> Message-ID: <066.337e284c44c1212b8b69b80641df27ea@haskell.org> #9625: ghc: panic using --enable-executable-dynamic -------------------------------------+------------------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Luke): I'm seeing this on 7.8.4 as well when compiling vty package. {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): Don't understand library name verify-attribute-ops }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 23 17:25:21 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Jan 2015 17:25:21 -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.d67a0044de3c8e3e8c2bcfa829b378e2@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.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: | -------------------------------------+------------------------------------- Comment (by simonpj): I was wrong. I have not fixed it, only a simpler version of it. So I'm not going to get this done this week after all. Austin: go ahead and make RC2, don't wait for this. * It affects very little code; * It can always be fixed by adding a type signature I believe that `HList` is the main affected library. What I don't know is whether it affects the ''library itself'' or ''clients of the library''. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 23 18:05:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Jan 2015 18:05:58 -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.9db547d35bcbfc5a1e6de4938fb53acd@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.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: | -------------------------------------+------------------------------------- Comment (by aavogt): It affects both: the library has a number of definitions that don't compile with 7.10RC1 right now. It affects how clients can put library functions together. For example the library defines: {{{ -- possible type signatures: -- hUntagSelf :: HList '[Tagged x x, Tagged y y] -> HList '[x,y] -- hTagSelf :: HList '[x,y] -> HList '[Tagged x x, Tagged y y] -- hZipTIP :: TIP '[Tagged x x] -> TIP '[Tagged y y] -- -> TIP '[Tagged (x,y) (x,y)] hZipTIP (TIP x) (TIP y) = TIP (hTagSelf (hZipList (hUntagSelf x) (hUntagSelf y))) }}} If I figure out where to annotate to get rid of the 7.10RC1 type error: {{{ Data/HList/TIP.hs:251:1: Warning: Could not deduce (TagR a0 ~ TagR a) from the context (HZipList x y a, TagUntag a, TagUntag x, TagUntag y) bound by the inferred type for ?hZipTIP?: (HZipList x y a, TagUntag a, TagUntag x, TagUntag y) => TIP (TagR x) -> TIP (TagR y) -> TIP (TagR a) at Data/HList/TIP.hs:251:1-81 NB: ?TagR? is a type function, and may not be injective The type variable ?a0? is ambiguous Expected type: TIP (TagR x) -> TIP (TagR y) -> TIP (TagR a) Actual type: TIP (TagR x0) -> TIP (TagR y0) -> TIP (TagR a0) When checking that ?hZipTIP? has the inferred type hZipTIP :: forall (a :: [*]) (x :: [*]) (y :: [*]). (HZipList x y a, TagUntag a, TagUntag x, TagUntag y) => TIP (TagR x) -> TIP (TagR y) -> TIP (TagR a) Probable cause: the inferred type is ambiguous Data/HList/TIP.hs:251:1: Warning: Could not deduce (HZipList x0 y0 a0) from the context (HZipList x y a, TagUntag a, TagUntag x, TagUntag y) bound by the inferred type for ?hZipTIP?: (HZipList x y a, TagUntag a, TagUntag x, TagUntag y) => TIP (TagR x) -> TIP (TagR y) -> TIP (TagR a) at Data/HList/TIP.hs:251:1-81 The type variables ?a0?, ?x0?, ?y0? are ambiguous When checking that ?hZipTIP? has the inferred type hZipTIP :: forall (a :: [*]) (x :: [*]) (y :: [*]). (HZipList x y a, TagUntag a, TagUntag x, TagUntag y) => TIP (TagR x) -> TIP (TagR y) -> TIP (TagR a) Probable cause: the inferred type is ambiguous }}} clients probably want to define functions like this too, and requiring a type annotation here probably doubles the amount of code that has to be written. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 23 18:05:58 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Jan 2015 18:05:58 -0000 Subject: [GHC] #9867: PatternSynonyms + ScopedTypeVariables triggers an internal error In-Reply-To: <046.5cdd1cb9d606767d1869bca60906658f@haskell.org> References: <046.5cdd1cb9d606767d1869bca60906658f@haskell.org> Message-ID: <061.db934c4523095af1d76e7ecf5d19fa3f@haskell.org> #9867: PatternSynonyms + ScopedTypeVariables triggers an internal error -------------------------------------+------------------------------------- Reporter: antalsz | Owner: cactus Type: bug | Status: closed Priority: normal | Milestone: 7.12.1 Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: fixed | PatternSynonyms Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | patsyn/should_compile/T9867 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.12.1 Comment: I don't think this can be easily merged to `ghc-7.10` because I think it's dependent on 32973bf3c2f6fe00e01b44a63ac1904080466938, which I'm not keen on merging. So I'm going to drop this one to 7.12 instead. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 23 18:06:57 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Jan 2015 18:06:57 -0000 Subject: [GHC] #9961: compile-time performance regression compiling genprimcode In-Reply-To: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> References: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> Message-ID: <057.519d50916d096a225a6dbffe7cb50471@haskell.org> #9961: compile-time performance regression compiling genprimcode -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: patch Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10007 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thoughtpolice): Merged to `ghc-7.10` (via 174082ffeb69b2f9df19e7af7b63a331dd074145). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 23 18:27:02 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Jan 2015 18:27: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.fb993d7c56ee1b669a16ada8a8abea9c@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.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: | -------------------------------------+------------------------------------- Comment (by aavogt): for what it's worth, ghc-7.10RC1 handles FDs correctly (see http://stackoverflow.com/questions/24110410/type-families-get-stuck-where- the-equivalent-type-using-functional-dependencies), as well as MPTCs+TFs so long as f doesn't use the TFs directly: {{{ class (b ~ GetB a, a ~ GetA b, Show a) => C b a where type GetB a type GetA b f :: b -> a -- f :: GetB a -> a -- but not this one! g :: forall a b. C b a => a -> String g _ = show a where a = f (undefined :: GetB a) -- :: a }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 23 19:11:16 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Jan 2015 19:11:16 -0000 Subject: [GHC] #10015: Give the DLL loader awareness of rpaths In-Reply-To: <047.87a2d7da531533923ef75de3db489dab@haskell.org> References: <047.87a2d7da531533923ef75de3db489dab@haskell.org> Message-ID: <062.5692374a44f0affafa8b7624f2a6c138@haskell.org> #10015: Give the DLL loader awareness of rpaths -------------------------------------+------------------------------------- Reporter: joelteon | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: fixed | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: None/Unknown | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by joelteon): * status: new => closed * resolution: => fixed Comment: Heh, this is my silly mistake. After looking at Linker.hs, I found that the first place the loader searches is in extra-lib-dirs, so I added the libiconv directory to that for base. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 23 19:16:07 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Jan 2015 19:16:07 -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.90fb35bec93093f3e5c16cae3e744187@haskell.org> #9929: New alias handling not compatible with LLVM 3.4 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 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: -------------------------------------+------------------------------------- Comment (by George): From the link at the start of the crash it seems that the compile error is: Error: can't resolve `.rodata' ... Just wanted to add this so people can easily know if they are encountering this error. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 23 19:17:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Jan 2015 19:17:11 -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.5a4900dc05822b905f8742f4e385782b@haskell.org> #9929: New alias handling not compatible with LLVM 3.4 -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 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 George): * cc: george (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 23 20:03:06 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Jan 2015 20:03:06 -0000 Subject: [GHC] #9125: int-to-float conversion broken on ARM In-Reply-To: <046.674440465a685280d146765ea38d0bfb@haskell.org> References: <046.674440465a685280d146765ea38d0bfb@haskell.org> Message-ID: <061.9811371f849e15074a5c83eba9c5f1ad@haskell.org> #9125: int-to-float conversion broken on ARM -------------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.8.3 (CodeGen) | Keywords: Resolution: | Architecture: arm Operating System: Unknown/Multiple | Test Case: Type of failure: Incorrect result | Blocking: at runtime | Differential Revisions: Blocked By: | Related Tickets: | -------------------------------------+------------------------------------- Comment (by Ansible): FWIW, installed arch today on a banana pi, and installed ghc with pacman. The problem does not occur there. {{{ [root at lemaker bananapi]# pacman -Q llvm llvm 3.5.1-1 [root at lemaker bananapi]# ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 23 20:06:22 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Jan 2015 20:06:22 -0000 Subject: [GHC] #8896: ghci fails on Arm - "Illegal instruction" In-Reply-To: <046.fb8d64e3cc86b4720678b35ed92e64a3@haskell.org> References: <046.fb8d64e3cc86b4720678b35ed92e64a3@haskell.org> Message-ID: <061.0450371d6dac28d7c160fd7318383bc2@haskell.org> #8896: ghci fails on Arm - "Illegal instruction" -------------------------------+------------------------------------- Reporter: Ansible | Owner: Type: bug | Status: infoneeded Priority: normal | Milestone: Component: GHCi | Version: 7.8.1-rc2 Resolution: | Keywords: arm ghci Operating System: Linux | Architecture: arm Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+------------------------------------- Comment (by Ansible): Installed today on a banana pi running arch. Ghci works there. Maybe its the version of llvm. {{{ [root at lemaker bananapi]# pacman -Q llvm llvm 3.5.1-1 [root at lemaker bananapi]# ghc --version The Glorious Glasgow Haskell Compilation System, version 7.8.2 [root at lemaker bananapi]# 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. Prelude> 1 + 1 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 23 20:47:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Jan 2015 20:47:27 -0000 Subject: [GHC] #9863: Provide PowerPC 64 bit native code generator In-Reply-To: <047.abf3d61d6edeed38824d04625109fece@haskell.org> References: <047.abf3d61d6edeed38824d04625109fece@haskell.org> Message-ID: <062.e8683006c4ed942e2a2d7c5da175b449@haskell.org> #9863: Provide PowerPC 64 bit native code generator ------------------------------------+------------------------------------ Reporter: trommler | Owner: trommler Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.8.3 Resolution: | Keywords: Operating System: Linux | Architecture: powerpc64 Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D629 ------------------------------------+------------------------------------ Changes (by trommler): * status: new => patch * differential: => Phab:D629 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 23 20:58:47 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 23 Jan 2015 20:58:47 -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.243365b520e0a251ebc9ee65413d9ea2@haskell.org> #10009: type inference regression when faking injective type families -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.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: | -------------------------------------+------------------------------------- Comment (by simonpj): Well I'm sorry but Austin is cutting RC2 today and I can't fix this late- reported regression in time. I will try to get it done before the final release comes out. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 24 13:40:34 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Jan 2015 13:40:34 -0000 Subject: [GHC] #10017: signal handlers are invoked multiple times when the threaded rts is used Message-ID: <045.98c8a4b2b498781adefd9fa189c04668@haskell.org> #10017: signal handlers are invoked multiple times when the threaded rts is used -------------------------------------+------------------------------------- Reporter: redneb | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.1-rc1 System | Operating System: Linux Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: #9423 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When you install a custom signal handler and the threaded rts is being used, then the signal handler will be invoked multiple times. Here's a program that the demonstrates this: {{{#!hs import Control.Concurrent import System.Posix.Signals main :: IO () main = do _ <- flip (installHandler sig) Nothing $ Catch $ putStrLn $ "Received signal " ++ show sig raiseSignal sig threadDelay 100000 where sig = sigUSR2 }}} If you compile this with the `-threaded` flag and then run it with say `+RTS -N4` then it produces the following output: {{{ Received signal 12 Received signal 12 Received signal 12 Received signal 12 Received signal 12 }}} In general the signal handler is invoked `n_capabilities+1` times. This also happens with all other signals. This regression was introduced by f9f89b7884ccc8ee5047cf4fffdf2b36df6832df (which was later [changeset:4748f5936fe72d96edfa17b153dbfd84f2c4c053 reverted] but then [changeset:7e658bc14e2dd6baf208deebbdab9e1285ce4c72 re- added]), a commit addressing #9423. The cause of the problem is [source:/rts/posix/Signals.c at f44bbc83bab62f9a2d25e69d87c2b4af25318d52#L256 this] loop. I don't understand why we need to write an event about the signal received in the per capability control pipe introduced by the aforementioned commit. Aren't these control pipes supposed only to be used to shutdown the capabilities (which happens [source:/rts/posix/Signals.c at f44bbc83bab62f9a2d25e69d87c2b4af25318d52#L183 here])? Removing the loop seems to solve the issue, but I don't know if it makes #9423 reappear. I cannot test this on a Mac OS X right now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 24 14:19:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Jan 2015 14:19:43 -0000 Subject: [GHC] #9557: Deriving instances is slow In-Reply-To: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> References: <048.4125fec548f18fcd48da9989fc1ebc4e@haskell.org> Message-ID: <063.f7d4c6f9e111c35b73db3d68505f6cf6@haskell.org> #9557: Deriving instances is slow -------------------------------------+------------------------------------- Reporter: Feuerbach | 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: #8731 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by edsko): * cc: edsko (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 24 18:23:45 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Jan 2015 18:23:45 -0000 Subject: [GHC] #7788: Recursive type family causes <> In-Reply-To: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> References: <046.ea3ef9ceaabda348ee27e147f6e7ebb3@haskell.org> Message-ID: <061.b3416950d35b60e490ab1f967f57f621@haskell.org> #7788: Recursive type family causes <> -------------------------------------+------------------------------------- Reporter: shachaf | Owner: simonpj Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler (Type | Version: 7.6.2 checker) | Keywords: Resolution: | Architecture: Operating System: Unknown/Multiple | Unknown/Multiple Type of failure: Incorrect result | Test Case: at runtime | Blocking: Blocked By: | Differential Revisions: Related Tickets: | -------------------------------------+------------------------------------- Comment (by int-e): Replying to [comment:6 goldfire]: > But, with 7.10, the following doesn't: > > {{{ > type family F a where > F a = F a > > id2 :: F a -> F a > id2 x = x > }}} > > This is slightly disturbing because `id2` is merely a specialization of `id`. I think this is wrong: `id2` does not have a type at all, and therefore does not specialize `id`. The same is true for the original example. If one looks at the code generated by ghc-7.8.3, it tries to produce a witness for {{{F (Fix Id)}}} being a type, and `foo` checks that witness (which fails, producing the observed {{{<>}}}) before producing `undefined`: {{{ -- core, with some non-essential parts omitted cobox_rVz :: Main.F (Main.Fix Main.Id) ~ GHC.Prim.Any cobox_rVz = cobox_rVz foo :: Main.Proxy (Main.F (Main.Fix Main.Id)) -> () foo = case cobox_rVz of GHC.Types.Eq# _ -> undefined }}} That said it's unfortunate that GHC 7.10 loops rather than erroring out for these examples. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 24 20:39:43 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Jan 2015 20:39:43 -0000 Subject: [GHC] #10017: signal handlers are invoked multiple times when the threaded rts is used In-Reply-To: <045.98c8a4b2b498781adefd9fa189c04668@haskell.org> References: <045.98c8a4b2b498781adefd9fa189c04668@haskell.org> Message-ID: <060.57b30786f3abe2c89d2771b536c30733@haskell.org> #10017: signal handlers are invoked multiple times when the threaded rts is used -------------------------------------+------------------------------------- Reporter: redneb | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Runtime System | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9423 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonmar): * cc: thoughtpolice (added) * priority: normal => highest * milestone: => 7.10.1 Comment: Yikes. Austin: this looks like a release blocker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 24 23:43:21 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 24 Jan 2015 23:43:21 -0000 Subject: [GHC] #10018: Cannot define custom fixity for infix data constructors in GHCi Message-ID: <050.b73ae7970094272181854c9a26f7e4d3@haskell.org> #10018: Cannot define custom fixity for infix data constructors in GHCi -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: GHCi | Operating System: Unknown/Multiple Keywords: | Type of failure: Incorrect result Architecture: | at runtime Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When compiling from a module, declaring a custom fixity for an infix data constructor is valid: {{{#!hs module DataFixity where data Infix a b = a :@: b infixl 4 :@: }}} And GHCi recognizes this: {{{ $ ghci DataFixity.hs GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. [1 of 1] Compiling DataFixity ( DataFixity.hs, interpreted ) Ok, modules loaded: DataFixity. ?> :i :@: data Infix a b = a :@: b -- Defined at DataFixity.hs:3:18 infixl 4 :@: }}} However, one cannot do this entirely in GHCi: {{{ $ ghci GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. ?> data Infix a b = a :@: b; infixl 4 :@: ?> :i (:@:) data Infix a b = a :@: b -- Defined at :2:18 }}} GHCi simply assumes {{{:@:}}} has the default infix precedence. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 25 04:18:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Jan 2015 04:18:22 -0000 Subject: [GHC] #10019: GHCi cannot reify a custom data constructor with Template Haskell on the first attempt Message-ID: <050.8ec6823346e7fe6fc27e65a4900502d1@haskell.org> #10019: GHCi cannot reify a custom data constructor with Template Haskell on the first attempt -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Template | Operating System: Unknown/Multiple Haskell | Type of failure: GHC rejects Keywords: | valid program Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I've uncovered an unusual bug with Template Haskell inside of GHCi. To duplicate it, load GHCi, create a data type, then attempt to reify one of its constructors. It will fail the first time, but succeed the second time. {{{ $ ghci -XTemplateHaskell GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. ?> import Language.Haskell.TH ?> data Option a = Some a | None ?> $(reify 'Some >>= stringE . show) Failed to load interface for ?Ghci1? no package matching ?interactive? was found ?> $(reify 'Some >>= stringE . show) Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. "DataConI Ghci1.Some (ForallT [PlainTV a_1627392303] [] (AppT (AppT ArrowT (VarT a_1627392303)) (AppT (ConT Ghci1.Option) (VarT a_1627392303)))) Ghci1.Option (Fixity 9 InfixL)" }}} Curiously, this doesn't happen when you reify a data constructor in {{{base}}}, such as {{{Just}}}: {{{ $ ghci -XTemplateHaskell GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. ?> import Language.Haskell.TH ?> $(reify 'Just >>= stringE . show) Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package pretty-1.1.1.1 ... linking ... done. Loading package template-haskell ... linking ... done. "DataConI Data.Maybe.Just (ForallT [PlainTV a_1627398816] [] (AppT (AppT ArrowT (VarT a_1627398816)) (AppT (ConT Data.Maybe.Maybe) (VarT a_1627398816)))) Data.Maybe.Maybe (Fixity 9 InfixL)" }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 25 17:53:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Jan 2015 17:53:18 -0000 Subject: [GHC] #1851: "make install-strip" should work In-Reply-To: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> References: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> Message-ID: <059.f785f80c49f330a770a2e9d56536959c@haskell.org> #1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by gidyn): * version: 7.8.4-rc1 => 7.9 * milestone: => 7.10.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sun Jan 25 17:53:39 2015 From: ghc-devs at haskell.org (GHC) Date: Sun, 25 Jan 2015 17:53:39 -0000 Subject: [GHC] #1851: "make install-strip" should work In-Reply-To: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> References: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> Message-ID: <059.b248769edd0fc76dbd6b8c54138700fe@haskell.org> #1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.9 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by gidyn): Still a problem in 7.10.1 RC1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 00:01:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 00:01: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.ec0f9ff9f07fac501506866c3130962f@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by Ptharien's Flame): If I may interject from the outside (so to speak), I think the best way to explain Simon's proposition (1) is in terms of parametricity, in a manner akin to the widely-expounded-upon use of monadic effects in Haskell. Adding a `Typeable` constraint is just like surrounding a type with `IO`: it allows more operations, while simultaneously marking the code as not- quite-pure in a specific way. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 02:55:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 02:55:26 -0000 Subject: [GHC] #10020: GHC 7.10 rejects nullary type class with associated data Message-ID: <050.7fe5de35678625902ef8dada7748ae56@haskell.org> #10020: GHC 7.10 rejects nullary type class with associated data -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: bug | Milestone: Priority: normal | Version: 7.10.1-rc1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: GHC rejects Architecture: | valid program Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In GHC 7.8.4, the following code is legal: {{{#!hs {-# LANGUAGE NullaryTypeClasses, TypeFamilies #-} module NullaryData where class NullaryClass where data NullaryData }}} In GHC 7.10, {{{NullaryTypeClasses}}} was [https://ghc.haskell.org/trac/ghc/ticket/8993 deprecated] in favor of {{{MultiParamTypeClasses}}}. However, running this code on GHC 7.10-rc1: {{{#!hs {-# LANGUAGE MultiParamTypeClasses, TypeFamilies #-} module NullaryData where class NullaryClass where data NullaryData }}} results in this error: {{{ NullaryData.hs:4:1: The associated type ?NullaryData? mentions none of the type or kind variables of the class ?NullaryClass? In the class declaration for ?NullaryClass? }}} It's probably related to [https://ghc.haskell.org/trac/ghc/ticket/9167 this earlier bugfix]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 04:06:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 04:06:58 -0000 Subject: [GHC] #9948: Recommend class constraint instead of instance constraint In-Reply-To: <047.c66907ef09dd5fcc438f73ae7f72ae2e@haskell.org> References: <047.c66907ef09dd5fcc438f73ae7f72ae2e@haskell.org> Message-ID: <062.4d67486c951a0fbdfae1eac34c029e2a@haskell.org> #9948: Recommend class constraint instead of instance constraint -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I can see why you might want this behavior in some cases, but would you really want {{{ isPalindrome :: [a] -> Bool isPalindrome xs = xs == reverse xs }}} to suggest adding an `Eq [a]` constraint (that's not even valid Haskell 98!), or some function to dump a data structure to suggest adding a `Show [(Int, Maybe a)]` constraint? Whatever constraint GHC suggests, it won't be the appropriate one in every situation. The current behavior is the most obvious one to me (the suggested constraint is the same one that appears in the type that GHC would infer in the absence of a type signature). I'm also a bit confused by the workaround that you mentioned; if you know that `Foo` is the class containing `foo` (which you must to comment out its instances) then don't you already know what constraint to add? Is it very difficult in your use cases to work out what the parameter to the class should be? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 04:11:33 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 04:11:33 -0000 Subject: [GHC] #9386: GHCi cannot load .so in ./ In-Reply-To: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> References: <047.6d829b9ae97b1073447115aeba1e6bb7@haskell.org> Message-ID: <062.06e19a5abadf3db55b2c7b2bc8fbeb9f@haskell.org> #9386: GHCi cannot load .so in ./ -------------------------------------+------------------------------------- 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: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: Phab:D593 -------------------------------------+------------------------------------- Comment (by rwbarton): I did some experiments with `gcc ... libfoo.so`, and it looked for `libfoo.so` in the current directory only, so I guess `ghc` and `ghci` ought to do the same. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 04:21:30 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 04:21:30 -0000 Subject: [GHC] #9982: cross building integer-gmp is running target program on build host In-Reply-To: <046.8a1ffc42fb5fbbea8ac62e5a7db86511@haskell.org> References: <046.8a1ffc42fb5fbbea8ac62e5a7db86511@haskell.org> Message-ID: <061.b91428d9db1381c2da29ad68309f2e07@haskell.org> #9982: cross building integer-gmp is running target program on build host -------------------------------------+------------------------------------- Reporter: newsham | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Building GHC | Unknown/Multiple failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): I really don't understand why we don't use autoconf for these constants. On the bright side, integer-gmp2 doesn't seem to require anything like this (yet?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 04:40:54 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 04:40:54 -0000 Subject: [GHC] #9625: ghc: panic using --enable-executable-dynamic In-Reply-To: <051.41ace47270d90cc9e836ab3706638147@haskell.org> References: <051.41ace47270d90cc9e836ab3706638147@haskell.org> Message-ID: <066.0940849a50621401b0eeff6442b7023c@haskell.org> #9625: ghc: panic using --enable-executable-dynamic -------------------------------------+------------------------------------- Reporter: CoreyOConnor | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Package system | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): So Cabal is building and registering (inplace) a package `bar` with the field `hs-libraries: bar` and a corresponding shared library `libbar- ghc7.8.3.so`: {{{ rwbarton at morphism:/tmp/foo$ ghc-pkg -f dist/package.conf.inplace describe bar name: bar version: 0.1.0.0 id: bar-0.1.0.0-inplace license: AllRightsReserved copyright: maintainer: stability: homepage: package-url: synopsis: description: category: author: exposed: True exposed-modules: Test hidden-modules: trusted: False import-dirs: /tmp/foo/dist/build library-dirs: /tmp/foo/dist/build hs-libraries: bar extra-libraries: extra-ghci-libraries: include-dirs: includes: depends: Cabal-1.18.1.3-4452332f737ff7dce6018eada45af877 base-4.7.0.1-1a55ebc8256b39ccbff004d48b3eb834 foo-0.1.0.0-inplace hugs-options: cc-options: ld-options: framework-dirs: frameworks: haddock-interfaces: /tmp/foo/dist/doc/html/bar/bar.haddock haddock-html: /tmp/foo/dist/doc/html/bar pkgroot: "/tmp/foo/dist" }}} However, Haskell libraries usually have `hs-libraries` with names like `HSbar`. In b30015e78db99d79cdb48c6c810e3fd49573c5cd GHC started to enforce this, since it applies different rules for finding the shared library base name for `hs-libraries` depending on whether they start with `HS` or with `C`. As far as I can tell this is only used by `rts`, specifically in its dependency on libffi. I have to say I don't understand why libffi can't simply be an `extra-libraries` dependency, something to do with library search paths perhaps? Is there any other reason for the convention that Haskell library names start with `HS`? Is this convention documented anywhere? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 04:46:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 04:46:58 -0000 Subject: [GHC] #9948: Recommend class constraint instead of instance constraint In-Reply-To: <047.c66907ef09dd5fcc438f73ae7f72ae2e@haskell.org> References: <047.c66907ef09dd5fcc438f73ae7f72ae2e@haskell.org> Message-ID: <062.e722c53e9386a0bfd7d59825924bad15@haskell.org> #9948: Recommend class constraint instead of instance constraint -------------------------------------+------------------------------------- Reporter: crockeea | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by crockeea): Replying to [comment:7 rwbarton]: > I can see why you might want this behavior in some cases, but would you really want > > {{{ > isPalindrome :: [a] -> Bool > isPalindrome xs = xs == reverse xs > }}} > > to suggest adding an `Eq [a]` constraint (that's not even valid Haskell 98!), or some function to dump a data structure to suggest adding a `Show [(Int, Maybe a)]` constraint? I see your point on these examples. How's the feature request for GHC mind-reading coming along? > I'm also a bit confused by the workaround that you mentioned; if you know that `Foo` is the class containing `foo` (which you must to comment out its instances) then don't you already know what constraint to add? Is it very difficult in your use cases to work out what the parameter to the class should be? Yes, it should be pretty obvious which constraint I need. The only minor point I could make is that it isn't always immediately clear if the function you are using is top-level or a method. The only way to resolve that is to look at some documentation. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 04:58:58 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 04:58:58 -0000 Subject: [GHC] #10005: Operations on string literals won't be inlined In-Reply-To: <048.79330f90aa6689947b213892c4dfd806@haskell.org> References: <048.79330f90aa6689947b213892c4dfd806@haskell.org> Message-ID: <063.47ea9b2467b9ae5b3892178af24c6283@haskell.org> #10005: Operations on string literals won't be inlined -------------------------------------+------------------------------------- Reporter: fread2281 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 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): Your definition of `head'` is wrong of course, but that's not the issue. I have good news and bad news. * Your program (with the definition of `head'` fixed) does optimize properly in HEAD. (I assume due to ticket:9400#comment:9.) It also optimizes properly without the `INLINE` pragma. * However, if you use the real `Prelude.head`, then rules fire that turn `test = head "foo"` into {{{ test = GHC.CString.unpackFoldrCString# @ Char "foo"# (\ (x_arw :: Char) _ [Occ=Dead] -> x_arw) (GHC.List.badHead @ Char) }}} and that is more or less a dead end. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 05:28:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 05:28:37 -0000 Subject: [GHC] #9392: "\n" is displayed weirdly in error messages In-Reply-To: <051.15cb74515fdf07a3c96c327bd3bd01ac@haskell.org> References: <051.15cb74515fdf07a3c96c327bd3bd01ac@haskell.org> Message-ID: <066.999cd2d189e5b757ba1035e303517db2@haskell.org> #9392: "\n" is displayed weirdly in error messages -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 Resolution: | Keywords: newcomer Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9681 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): The formatting is intentional, see #4436. It would be nice to use the original syntax, though (and set the "original syntax" of a quasiquoter to use the multiline thing). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 12:02:46 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 12:02:46 -0000 Subject: [GHC] #9901: Error message: f is applied to two arguments, but its type has only two (sic) In-Reply-To: <045.20460e93a0bca4214189c85bc9425d02@haskell.org> References: <045.20460e93a0bca4214189c85bc9425d02@haskell.org> Message-ID: <060.32fc7bb58c517d5e67d9b55a550f99db@haskell.org> #9901: Error message: f is applied to two arguments, but its type has only two (sic) -------------------------------------+------------------------------------- Reporter: zardoz | Owner: Type: bug | Status: new 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: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by zardoz): I?ve updated the attachment. Hopefully this should go through with just ?base? installed. I?m out of my depth on the language pragmas. I added them as requested by GHC when mocking the respective types. The error message seems to be the same as before. This program yields me: {{{ test.hs:22:17: Couldn't match type ?Either String Int? with ?Maybe a0? Expected type: Either a1 [Char] -> Either String Int Actual type: Either a1 [Char] -> Maybe a0 The function ?preview? is applied to two arguments, but its type ?Getting (Data.Monoid.First a0) s0 a0 -> Either a1 [Char] -> Maybe a0? has only two In the second argument of ?($)?, namely ?(preview _Left (Right "abc") :: Either String Int)? In the expression: print $ (preview _Left (Right "abc") :: Either String Int) Failed, modules loaded: none. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 12:09:25 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 12:09:25 -0000 Subject: [GHC] #1851: "make install-strip" should work In-Reply-To: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> References: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> Message-ID: <059.2f917b168ee8f1a8a54477726d341d1b@haskell.org> #1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Build System | Version: 7.10.1-rc1 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 gidyn): * version: 7.9 => 7.10.1-rc1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 13:05:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 13:05:53 -0000 Subject: [GHC] #10005: Operations on string literals won't be inlined In-Reply-To: <048.79330f90aa6689947b213892c4dfd806@haskell.org> References: <048.79330f90aa6689947b213892c4dfd806@haskell.org> Message-ID: <063.d12600e90e3713159f4a25fabc0f24c8@haskell.org> #10005: Operations on string literals won't be inlined -------------------------------------+------------------------------------- Reporter: fread2281 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 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): We wanted literal strings to be good producers, so that `map f "wubble"` would work without generating and then pattern matching on the intermediate string. That is why `"foo"` desugars to {{{ build (unpackFoldrCString# "foo"#) }}} This seems reasonable. Now `head` has this rule: {{{ "head/build" forall (g::forall b.(a->b->b)->b->b) . head (build g) = g (\x _ -> x) badHead }}} (goal: make `head` a good consumer), and that rule fires on `head "foo"` giving the result in comment:1. It is a bit stupid, but I don't see an immediate way out. One alternative would be to kill off the `head/build` rule. After all, most `fold/build` rules save an entire traversal of the list whereas this one saves the allocation and pattern match on a single cons cell. So the win is much smaller. If someone would like to * Switch off RULES `head/build` and `head/augment` (in `GHC.List`) * See what performance difference, if any, happens in `nofib` * Track down any increases that would be a splendid thing. More radical would be to nuke the entire `unpackFoldrCString` ideaa, so that literal strings are not good producers. But I think that would probably be bad. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 14:20:37 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 14:20:37 -0000 Subject: [GHC] #10021: Add "Error:" prefix for error-messages Message-ID: <043.cd50774548df3d55e921eb94882437a4@haskell.org> #10021: Add "Error:" prefix for error-messages -------------------------------------+------------------------------------- Reporter: k-bx | Owner: Type: feature | Status: new request | Milestone: 7.12.1 Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Similar to what we have for "Warning:". E.g., we have: {{{ ? cat test.hs main = putStrLn "Hello!" ? ghc --make -fforce-recomp -Wall ./test.hs [1 of 1] Compiling Main ( test.hs, test.o ) test.hs:1:1: Warning: Top-level binding with no type signature: main :: IO () Linking test ... ? cat test2.hs main = foo ? ghc --make -fforce-recomp -Wall ./test2.hs [1 of 1] Compiling Main ( test2.hs, test2.o ) test2.hs:1:8: Not in scope: ?foo? }}} And I propose having: {{{ ? cat test2.hs main = foo ? ghc --make -fforce-recomp -Wall ./test2.hs [1 of 1] Compiling Main ( test2.hs, test2.o ) test2.hs:1:8: Error: Not in scope: ?foo? }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 15:29:53 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 15:29:53 -0000 Subject: [GHC] #7602: Threaded RTS performing badly on recent OS X (10.8?) In-Reply-To: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> References: <047.d4c76195d3e5b80e244f99bd757e13e7@haskell.org> Message-ID: <062.a7f41df03e4926c46d2f89109c3595b9@haskell.org> #7602: Threaded RTS performing badly on recent OS X (10.8?) -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | thoughtpolice Priority: high | Status: new Component: Runtime System | Milestone: 7.12.1 Resolution: | Version: Operating System: MacOS X | Keywords: thread- Type of failure: Runtime | local state, TLS clang performance bug | Architecture: x86_64 Blocked By: 7678 | (amd64) Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * milestone: 7.10.1 => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 15:30:04 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 15:30:04 -0000 Subject: [GHC] #7273: Binary size increase in nofib/grep between 7.6.1 and HEAD In-Reply-To: <047.56a3d4f639e4f19c232c77ec82adbeca@haskell.org> References: <047.56a3d4f639e4f19c232c77ec82adbeca@haskell.org> Message-ID: <062.2837eaa4d2876d6722cec1d0e43257fc@haskell.org> #7273: Binary size increase in nofib/grep between 7.6.1 and HEAD -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.6.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 thoughtpolice): * milestone: 7.10.1 => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 15:30:56 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 15:30:56 -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.ed437c15dc7f9f82ffc6b262c0c9e622@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 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * differential: => Phab:D8 * milestone: 7.10.1 => 7.12.1 Comment: See the related (but old) patch: Phab:D8. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 15:33:48 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 15:33:48 -0000 Subject: [GHC] #9961: compile-time performance regression compiling genprimcode In-Reply-To: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> References: <042.b2569cb9174f7effc73a94ef731e9acc@haskell.org> Message-ID: <057.f79707da84e98f70d90bb50ed37eab2d@haskell.org> #9961: compile-time performance regression compiling genprimcode -------------------------------------+------------------------------------- Reporter: hvr | Owner: simonpj Type: bug | Status: closed Priority: highest | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10007 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: patch => closed * resolution: => fixed Comment: Forgot to close this; tested as fixed in the GHC 7.10 branch: {{{ $ ../../inplace/bin/ghc-stage2 -Rghc-timing -O -c ParserM.hs <> $ ../../inplace/bin/ghc-stage2 -Rghc-timing -O -c Lexer.hs <> }}} The `lintAnnots` stuff is taken care of in #10007 like I commented earlier. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 15:34:12 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 15:34:12 -0000 Subject: [GHC] #1851: "make install-strip" should work In-Reply-To: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> References: <044.55b2dd35d7abad74f0ebfed90c4f828d@haskell.org> Message-ID: <059.c636c6f33e81993ad1b9d638667a564e@haskell.org> #1851: "make install-strip" should work -------------------------------------+------------------------------------- Reporter: igloo | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.10.1-rc1 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 thoughtpolice): * milestone: 7.10.1 => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 15:39:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 15:39:31 -0000 Subject: [GHC] #10022: Clean up GHC.RTS.Flags Message-ID: <052.5f42b7b89367d2d1404df9b2172515f5@haskell.org> #10022: Clean up GHC.RTS.Flags -------------------------------------+------------------------------------- Reporter: | Owner: thoughtpolice | Status: new Type: bug | Milestone: 7.12.1 Priority: normal | Version: 7.10.1-rc1 Component: | Operating System: Unknown/Multiple libraries/base | Type of failure: None/Unknown Keywords: | Blocked By: Architecture: | Related Tickets: #9970 Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- There's some cleanup to do for `GHC.RTS.Flags`, based on the comments in https://ghc.haskell.org/trac/ghc/ticket/5364#comment:11 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 15:40:02 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 15:40:02 -0000 Subject: [GHC] #5364: Access RTS flag values from inside Haskell programs In-Reply-To: <045.dac6fe30423f96742744c66f751179f8@haskell.org> References: <045.dac6fe30423f96742744c66f751179f8@haskell.org> Message-ID: <060.7bdb03594df62730509220d058487f37@haskell.org> #5364: Access RTS flag values from inside Haskell programs -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ekmett Type: feature request | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #10022 | Blocking: | Differential Revisions: Phab:D306 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: new => closed * resolution: => fixed * related: => #10022 Comment: Yes, we should make those cleanups. I've filed another ticket: #10022. However, this ticket is (in general) worth closing. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 15:41:14 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 15:41:14 -0000 Subject: [GHC] #9928: Wrong information about the version of the time library in the release notes of various versions of GHC In-Reply-To: <042.da80f41221c9fccf24e54a1fbfd2424e@haskell.org> References: <042.da80f41221c9fccf24e54a1fbfd2424e@haskell.org> Message-ID: <057.dad7c4194525a6b4c9d3ef6b12526f45@haskell.org> #9928: Wrong information about the version of the time library in the release notes of various versions of GHC -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Documentation | Version: 7.10.1-rc1 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: new => closed * resolution: => fixed Comment: This should hopefully be fixed in the 7.10.1 RC2 release notes (synchronized with `time-1.5.0.1`). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 15:41:36 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 15:41:36 -0000 Subject: [GHC] Batch modify: #9674, #9921, #9970 Message-ID: <20150126154136.291563A2FF@ghc.haskell.org> Batch modification to #9674, #9921, #9970 by thoughtpolice: milestone to 7.12.1 Comment: Moving to 7.12.1 milestone. -- Tickets URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 15:46:20 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 15:46:20 -0000 Subject: [GHC] #9928: Wrong information about the version of the time library in the release notes of various versions of GHC In-Reply-To: <042.da80f41221c9fccf24e54a1fbfd2424e@haskell.org> References: <042.da80f41221c9fccf24e54a1fbfd2424e@haskell.org> Message-ID: <057.890f2937d14f45bf0331df417d272f6e@haskell.org> #9928: Wrong information about the version of the time library in the release notes of various versions of GHC -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Documentation | Version: 7.10.1-rc1 Resolution: fixed | 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: > The information about the version of the time library is wrong in the > release notes of > [https://downloads.haskell.org/~ghc/7.10.1-rc1/docs/html/users_guide/release-7-10-1.html > GHC 7.10.1], > [https://downloads.haskell.org/~ghc/7.8.1/docs/html/users_guide/release-7-8-1.html > GHC 7.8.3] and > [https://downloads.haskell.org/~ghc/7.6.1/docs/html/users_guide/release-7-6-1.html > GHC 7.6.1]. New description: The information about the version of the time library is wrong in the release notes of [https://downloads.haskell.org/~ghc/7.10.1-rc1/docs/html/users_guide/release-7-10-1.html GHC 7.10.1 RC1], [https://downloads.haskell.org/~ghc/7.8.1/docs/html/users_guide/release-7-8-1.html GHC 7.8.3] and [https://downloads.haskell.org/~ghc/7.6.1/docs/html/users_guide/release-7-6-1.html GHC 7.6.1]. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 15:54:24 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 15:54:24 -0000 Subject: [GHC] #10023: Relax Monad constraint in traceM and traceShowM to Applicative Message-ID: <050.7023a64f597b119154f3ec65be43878d@haskell.org> #10023: Relax Monad constraint in traceM and traceShowM to Applicative -------------------------------------+------------------------------------- Reporter: | Owner: RyanGlScott | Status: new Type: feature | Milestone: request | Version: 7.10.1-rc1 Priority: normal | Operating System: Unknown/Multiple Component: | Type of failure: Other libraries/base | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Now that {{{Applicative}}} is a superclass of {{{Monad}}} in GHC 7.10, the current type signatures of {{{traceM}}} and {{{traceShowM}}} from {{{Debug.Trace}}} are too constricted: {{{#!hs traceM :: Monad m => String -> m () traceM string = trace string $ return () traceShowM :: (Show a, Monad m) => a -> m () traceShowM = traceM . show }}} These can be equivalently defined with {{{Applicative}}}: {{{#!hs traceM :: Applicative m => String -> m () traceM string = trace string $ pure () traceShowM :: (Show a, Applicative m) => a -> m () traceShowM = traceM . show }}} However, the {{{M}}} suffixes probably won't make sense after changing the type signatures, so it might be wise to create new {{{traceA}}} and {{{traceShowA}}} functions and deprecate {{{traceM}}} and {{{traceShowM}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 17:06:59 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 17:06:59 -0000 Subject: [GHC] #10023: Relax Monad constraint in traceM and traceShowM to Applicative In-Reply-To: <050.7023a64f597b119154f3ec65be43878d@haskell.org> References: <050.7023a64f597b119154f3ec65be43878d@haskell.org> Message-ID: <065.e1a400847cb4df18c5047f380639d131@haskell.org> #10023: Relax Monad constraint in traceM and traceShowM to Applicative -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): We've adopted the practice of generalizing the existing fooM Combinators in base where possible as part of 7.10 but not giving a new set of fooA names to avoid namespace pollution, needless constraints and a complex deprecation cycle. It seemed the lesser of evils was to generalize the M suffix than ask literally everyone to retool. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 17:25:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 17:25:26 -0000 Subject: [GHC] #10023: Relax Monad constraint in traceM and traceShowM to Applicative In-Reply-To: <050.7023a64f597b119154f3ec65be43878d@haskell.org> References: <050.7023a64f597b119154f3ec65be43878d@haskell.org> Message-ID: <065.7709161bb9256ffa699a697bb5c28243@haskell.org> #10023: Relax Monad constraint in traceM and traceShowM to Applicative -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by RyanGlScott): I can live without the names {{{traceA}}}/{{{traceShowA}}}, but it would be nice to generalize the type signatures in the same vein as {{{when}}}/{{{unless}}}/{{{guard}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 17:42:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 17:42:43 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.6c1d929e0b8e39dc5e41bf55cc078fd5@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | thoughtpolice Priority: normal | Status: new Component: Compiler | Milestone: 7.12.1 Resolution: | Version: 7.0.3 Operating System: Unknown/Multiple | Keywords: Type of failure: Runtime | Architecture: performance bug | Unknown/Multiple Blocked By: | Test Case: Related Tickets: 5877 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by nomeata): I just put two 15000-element unboxed vector of Word16 in a module, using `fromList [...]` and compile time is annoying, and the runtime overhear is (possibly unjustified) worrying me. Having a way to have a literal form of such an array (which then hopefully is put into the program as-is) would be nice. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 19:28:47 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 19:28:47 -0000 Subject: [GHC] #10023: Relax Monad constraint in traceM and traceShowM to Applicative In-Reply-To: <050.7023a64f597b119154f3ec65be43878d@haskell.org> References: <050.7023a64f597b119154f3ec65be43878d@haskell.org> Message-ID: <065.80ef2c4643c50c5ab70cf3ff6f0d9ebc@haskell.org> #10023: Relax Monad constraint in traceM and traceShowM to Applicative -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by ekmett): No problem here with generalizing the types. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 19:41:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 19:41:26 -0000 Subject: [GHC] #10023: Relax Monad constraint in traceM and traceShowM to Applicative In-Reply-To: <050.7023a64f597b119154f3ec65be43878d@haskell.org> References: <050.7023a64f597b119154f3ec65be43878d@haskell.org> Message-ID: <065.f4f491bb388b3d02f5424169c98432f1@haskell.org> #10023: Relax Monad constraint in traceM and traceShowM to Applicative -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: libraries/base | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * milestone: => 7.12.1 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 19:42:52 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 19:42:52 -0000 Subject: [GHC] #9987: GHC refuses to compile a file that starts with a Byte Order Mark (BOM) In-Reply-To: <047.e7f60a33859d3c90bb19400309efd40e@haskell.org> References: <047.e7f60a33859d3c90bb19400309efd40e@haskell.org> Message-ID: <062.a6de68b04fa55723fb69eb309130cfcc@haskell.org> #9987: GHC refuses to compile a file that starts with a Byte Order Mark (BOM) -------------------------------------+------------------------------------- Reporter: Henk-Jan | Owner: Type: feature request | Status: new Priority: low | Milestone: ? Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: GHC rejects | Unknown/Multiple valid program | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hvr): * milestone: => ? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 19:44:43 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 19:44:43 -0000 Subject: [GHC] #9988: Remove fun_id, is_infix from FunBind, as they are now in Match In-Reply-To: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> References: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> Message-ID: <059.b52696eabdebe2ee5d53a7f257687ec1@haskell.org> #9988: Remove fun_id, is_infix from FunBind, as they are now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1-rc1 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): * milestone: => 7.12.1 Comment: I assume this one's targetted for GHC 7.12.1 (rather than GHC 7.10.2?) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 19:52:55 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 19:52:55 -0000 Subject: [GHC] #9988: Remove fun_id, is_infix from FunBind, as they are now in Match In-Reply-To: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> References: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> Message-ID: <059.3d589d889ab65d285de27d70d8089b8d@haskell.org> #9988: Remove fun_id, is_infix from FunBind, as they are now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1-rc1 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 alanz): Yes, but I have just realised I may need this functionality, ghc- exactprint may be able to generate output from RenamedSource, which makes HaRe integration easier. If I got it done soon could it hit 7.10.2? I am currently putting a workaround into ghc-exactprint, so it is not critical, but would be cleaner. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 19:58:08 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 19:58:08 -0000 Subject: [GHC] #10024: This bug tracker: Can not create filter `x contains y && x contains z` Message-ID: <048.3541aa422624d97a483d8bb4b09c8824@haskell.org> #10024: This bug tracker: Can not create filter `x contains y && x contains z` -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Keywords: trac | Operating System: Unknown/Multiple filter and | Type of failure: None/Unknown Architecture: Other | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- To Reproduce: - Start ticket search - Create filter "description" and set phrase to "foo" - Click the button "And" again, choose "description", set phrase to "bar" - The filter now is set to {{{description contains foo || description contains bar}}}, instead of the expected {{{s/||/&&/}}}. Note that setting phrase to "foo bar" seems to search for "foo bar", not {{{fold (||) . words}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 20:33:57 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 20:33:57 -0000 Subject: [GHC] #10025: Tracker: "My Tickets" does not work Message-ID: <048.640c096e55aadc51bd5349a38c756f3a@haskell.org> #10025: Tracker: "My Tickets" does not work -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: hvr Type: bug | Status: new Priority: high | Milestone: Component: Trac & Git | Version: Keywords: trac my | Operating System: Unknown/Multiple tickets filter | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I have non-zero set of tickets here, yet search returns empty list. No filters other than author=lspitzner. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 20:38:03 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 20:38:03 -0000 Subject: [GHC] #10026: wiki formatting doc does not mention language option Message-ID: <048.ac2aa181d221a581209e7b02b7b58bf4@haskell.org> #10026: wiki formatting doc does not mention language option -------------------------------------+------------------------------------- Reporter: lspitzner | 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: | -------------------------------------+------------------------------------- #!hs is not mentioned on https://ghc.haskell.org/trac/ghc/wiki/WikiFormatting#PreformattedText -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 20:45:50 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 20:45:50 -0000 Subject: [GHC] #10027: Importing constructor of associated data type fails Message-ID: <048.077c953371a360576ad660349e5d3261@haskell.org> #10027: Importing constructor of associated data type fails -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple constructor import associated | Type of failure: None/Unknown data type | Blocked By: Architecture: | Related Tickets: Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I will base my description on the code you find when searching for "instance PersistEntity" on http://www.yesodweb.com/book/persistent. In summary, the code looks like {{{#!hs instance PersistEntity Person where ... data EntityField Person typ where PersonId :: EntityField Person PersonId PersonName :: EntityField Person String PersonAge :: EntityField Person Int ... }}} This code is generated from TH (see above). I have not tested if it matters that it is generated. A first step could be to test if manually replacing the TH part yields different results. The problem is: When i add this code in one module, do ''not'' create an export list for that module, and try to import the constructors explicitly (i.e. with a list) in a different module, it does not work. I read and tried to follow the description on https://wiki.haskell.org/GHC/Type_families, chapter 4.3. == Testcase 1 == (not really expected to work; still intersting error message) {{{#!hs import MyModuleContainingInstancePerson ( PersonId ) }}} ghc says {{{ ?PersonId? is a data constructor of ?EntityField? To import it use ?import? MyModuleContainingInstancePerson( EntityField( VersionVersion ) ) or ?import? MyModuleContainingInstancePerson( EntityField(..) ) }}} == Testcase 2 == (no export list in {{{MyModuleContainingInstancePerson}}}) {{{#!hs import MyModuleContainingInstancePerson ( EntityField(..) ) }}} ghc says {{{ Module ?MyModuleContainingInstancePerson? does not export ?EntityField(..)? }}} == Testcase 3 == But ''when i do provide'' an export list in {{{MyModuleContainingInstancePerson}}}, like {{{#!hs module MyModuleContainingInstancePerson ( Person(..), EntityField(..) ) where .. }}} Testcase 2 suddenly works. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 20:48:34 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 20:48:34 -0000 Subject: [GHC] #10025: Tracker: "My Tickets" does not work In-Reply-To: <048.640c096e55aadc51bd5349a38c756f3a@haskell.org> References: <048.640c096e55aadc51bd5349a38c756f3a@haskell.org> Message-ID: <063.905a96a13e7f88d7b159a3bdceaa3d99@haskell.org> #10025: Tracker: "My Tickets" does not work -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: hvr Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: Resolution: | Keywords: trac my Operating System: Unknown/Multiple | tickets filter Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by lspitzner): * priority: high => normal Comment: ah, reporter /= owner. my bad. still a somewhat understandable misunderstanding? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 21:01:21 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 21:01:21 -0000 Subject: [GHC] #6079: SEH exception handler not implemented on Win64 In-Reply-To: <044.31bc28f566675131a5a949cb43e64371@haskell.org> References: <044.31bc28f566675131a5a949cb43e64371@haskell.org> Message-ID: <059.c5f4b2739d2ca30b7b77736fe54fef7d@haskell.org> #6079: SEH exception handler not implemented on Win64 -------------------------------------+------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: None/Unknown | (amd64) Blocked By: | Test Case: derefnull, Related Tickets: | divbyzero | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: simonmar (added) * owner: => Phyx- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 21:07:26 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 21:07:26 -0000 Subject: [GHC] #10028: GHC Panic (The Impossible Happened) Message-ID: <052.bc0cde29811087a01e898dddf6805532@haskell.org> #10028: GHC Panic (The Impossible Happened) -------------------------------------+------------------------------------- Reporter: | Owner: archaephyrryx | Status: new Type: bug | Milestone: Priority: normal | Version: 7.4.1 Component: Compiler | Operating System: Unknown/Multiple Keywords: | Type of failure: Compile-time panic,impossible,irrefutable | crash Architecture: x86_64 | Blocked By: (amd64) | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Error message: {{{ ghc: panic! (the 'impossible' happened) (GHC version 7.4.1 for x86_64-unknown-linux): compiler/rename/RnPat.lhs:535:39-79: Irrefutable pattern failed for pattern gres@(gre : _) }}} Cause: Importing a Module containing a record-syntax defined datatype, hiding one of the record fields, causes the use of the language pragma RecordWildCards to make GHC encounter a fatal error. A minimal reproduction case is attached to this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 22:45:45 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 22:45:45 -0000 Subject: [GHC] #6079: SEH exception handler not implemented on Win64 In-Reply-To: <044.31bc28f566675131a5a949cb43e64371@haskell.org> References: <044.31bc28f566675131a5a949cb43e64371@haskell.org> Message-ID: <059.47891efb99c8ffe0619dc2e2055a56b7@haskell.org> #6079: SEH exception handler not implemented on Win64 -------------------------------------+------------------------------------- Reporter: igloo | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.5 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 Type of failure: None/Unknown | (amd64) Blocked By: | Test Case: derefnull, Related Tickets: | divbyzero | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Phyx-): Summary of what's changed and how It affects the GHC side of things: on x86 SEH handling was done via the stack. On a thread FS[0] would always point to the SEH linked list. It was also prone to buffer overflows and made it hard to share error handlers. on x64 it was cleaned up a bit and the EH information is now stored in the the PE headers in tables. instead of an EH covering an entire thread until popped, you know have to explicitly specify the rva (relative virtual address) of the region to which the EH should apply. Microsoft compilers calculate this information at compile time from the !__try, !__catch and !__except1 symbols and this information is statically added to the PE file. GCC's implementation works by dynamically manipulating the table (using '''RtlAddFunctionTable''' and related functions). It's implemented in MingW64 from version 4.6.2 (current version of msys2 ships with newer version so should be fine) and is based on GAS's implementation http://code.google.com/p/propgcc/source/browse/binutils/gas/config/obj- coff-seh.h The only way to use this is inline assembly in gcc: BEGIN_CATCH and END_CATCH theoretically become: >long CALLBACK !__hs_exception_handler(EXCEPTION_POINTERS *exception_data); >#define BEGIN_CATCH asm (".l_start:\n" \ > "\t.seh_handler !__C_specific_handler, @except\n" \ > "\t.seh_handlerdata\n" \ > "\t.long 1\n" \ > "\t.rva .l_start, .l_end, !__hs_exception_handler, .l_end\n" \ > "\t.text" \ > ); > #define END_CATCH asm ("nop\n" \ > "\t.l_end:\n" \ > "\tnop\n" \ > ); everything between the .l_start and .l_end label is covered by the function !__hs_exception_handler. {{{ The interesting part here is the line "\t.rva .l_startw, .l_endw, _gnu_exception_handler ,.l_endw\n". The first rva is the start-address of the first instruction within try-block, the next is the end-address of the try-block (be aware that it needs to +1 after end of last instruction in try-block). The third rva is the handler to be called, and the fourth is the address of the finally-block. }}} (NOTE: the \t are only for indenting if viewing the dissassembly generated from gcc with -S) --- Implementation wise, a few things make it difficult: 1) the function real_main() in RtsMain is decorated with !__noreturn!__, this makes GCC perform dead code elimination and remove the END_CATCH, the linker will then refuse to link as the .l_end label will be missing. Instead moving the BEGIN_CATCH and END_CATCH blocks inside the real_main to appropriate positions allows it all to work. --- I have the changes implemented but the handler is not being called for some reason. I will figure out what's wrong and create a patch. I'm concerned that when linking, the .l_end label is put in a position that does not cover the user code, in which case this implementation would probably get more complex -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 23:11:09 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 23:11:09 -0000 Subject: [GHC] #9935: Can't compile rts/StgCRun.c for aarch64-linux In-Reply-To: <044.200c17fd365ff41cdf84e3ad7b9ecbc2@haskell.org> References: <044.200c17fd365ff41cdf84e3ad7b9ecbc2@haskell.org> Message-ID: <059.41d2721b46d95e5cd05edc72cddc279b@haskell.org> #9935: Can't compile rts/StgCRun.c for aarch64-linux ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: D599 ----------------------------------------+---------------------------------- Comment (by Erik de Castro Lopo ): In [changeset:"b9063703301f0d902b4bb2eb28ac27e9bc050ea0/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="b9063703301f0d902b4bb2eb28ac27e9bc050ea0" RTS : Fix StgRun for aarch64-linux (#9935). Summary: The GCC assembler doesn't seem to recognise the 'fp' and 'lr' register names which are aliases for 'x29' and 'x30' respectively. Depends on D598. Test Plan: validate Reviewers: lukexi, bgamari, austin Reviewed By: austin Subscribers: carter, thomie Differential Revision: https://phabricator.haskell.org/D599 GHC Trac Issues: #9935 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Mon Jan 26 23:24:31 2015 From: ghc-devs at haskell.org (GHC) Date: Mon, 26 Jan 2015 23:24:31 -0000 Subject: [GHC] #9935: Can't compile rts/StgCRun.c for aarch64-linux In-Reply-To: <044.200c17fd365ff41cdf84e3ad7b9ecbc2@haskell.org> References: <044.200c17fd365ff41cdf84e3ad7b9ecbc2@haskell.org> Message-ID: <059.6e5843d6f8621302ad84cece8bd75e68@haskell.org> #9935: Can't compile rts/StgCRun.c for aarch64-linux ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.11 Resolution: | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: D599 ----------------------------------------+---------------------------------- Changes (by erikd): * status: new => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 04:31:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 04:31:54 -0000 Subject: [GHC] #10029: unit-tests: internal error: evacuate(static): strange closure type 62744 Message-ID: <050.3e189618a175273ea644d5072d51372c@haskell.org> #10029: unit-tests: internal error: evacuate(static): strange closure type 62744 -------------------------------------+------------------------------------- Reporter: | Owner: juhpetersen | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Linux Keywords: | Type of failure: Compile-time Architecture: arm | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The syb-0.4.1 testsuite fails on ARMv7 Linux (Fedora 22 devel) with ghc-7.8.4: {{{ + ./Setup test Running 1 test suites... Test suite unit-tests: RUNNING... Cases: 29 Tried: 0 Errors: 0 Failures: 0 Cases: 29 Tried: 1 Errors: 0 Failures: 0 Cases: 29 Tried: 2 Errors: 0 Failures: 0 Cases: 29 Tried: 3 Errors: 0 Failures: 0 Cases: 29 Tried: 4 Errors: 0 Failures: 0 Cases: 29 Tried: 5 Errors: 0 Failures: 0 Cases: 29 Tried: 6 Errors: 0 Failures: 0 Cases: 29 Tried: 7 Errors: 0 Failures: 0 Cases: 29 Tried: 8 Errors: 0 Failures: 0 Cases: 29 Tried: 9 Errors: 0 Failures: 0 Cases: 29 Tried: 10 Errors: 0 Failures: 0 Cases: 29 Tried: 11 Errors: 0 Failures: 0 Cases: 29 Tried: 12 Errors: 0 Failures: 0 Cases: 29 Tried: 13 Errors: 0 Failures: 0 Cases: 29 Tried: 14 Errors: 0 Failures: 0 Cases: 29 Tried: 15 Errors: 0 Failures: 0 Cases: 29 Tried: 16 Errors: 0 Failures: 0 Cases: 29 Tried: 17 Errors: 0 Failures: 0 Cases: 29 Tried: 18 Errors: 0 Failures: 0unit-tests: internal error: evacuate(static): strange closure type 62744 (GHC version 7.8.4 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Test suite unit-tests: FAIL Test suite logged to: dist/test/syb-0.4.1-unit-tests.log 0 of 1 test suites (0 of 1 test cases) passed. }}} Let me know if I can provide any more details. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 07:06:53 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 07:06:53 -0000 Subject: [GHC] #10030: packageName for GHC.Generics.Datatype Message-ID: <045.ce2f6e41c41ec92e31efde332462bf2a@haskell.org> #10030: packageName for GHC.Generics.Datatype -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 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: | -------------------------------------+------------------------------------- Seems it's perfectly ok to have the data type of the same name in the same module, but different packages. Yet used in the same module: {{{ {-# LANGUAGE PackageImports #-} {-# LANGUAGE RankNTypes #-} module Data.Foo where import "void" Data.Void as A import Data.Void as B foo :: A.Void -> a foo = absurd bar :: B.Void -> a bar x = x () }}} {{{ {-# LANGUAGE RankNTypes #-} module Data.Void where type Void = forall a b. a -> b }}} https://gist.github.com/phadej/8b628d579ddf6958d937 motivated by: http://stackoverflow.com/questions/28159068/packagename- with-ghc-generics I'd propose to change `Datatype` class to be: {{{ class Datatype d where -- | The name of the datatype (unqualified) datatypeName :: t d (f :: * -> *) a -> [Char] -- | The fully-qualified name of the module where the type is declared moduleName :: t d (f :: * -> *) a -> [Char] -- | The package name of the module where the type is declared packageName :: t d (f :: * -> *) a -> [Char] -- | Marks if the datatype is actually a newtype isNewtype :: t d (f :: * -> *) a -> Bool isNewtype _ = False }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 08:17:40 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 08:17:40 -0000 Subject: [GHC] #10031: coerce can cause compiler to loop Message-ID: <044.15e9c8486a47b37508189b87e9fa66ab@haskell.org> #10031: coerce can cause compiler to loop -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: Compile-time (amd64) | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- This program causes GHC to loop at compile time {{{ {-# LANGUAGE ScopedTypeVariables #-} import Data.Coerce coerce' :: Coercible b a => a -> b coerce' = coerce (\x -> x :: b) :: forall a b. Coercible b a => a -> b }}} I encountered this trying to use a similar construction in https://github.com/glguy/profunctors/blob/coerce/src/Data/Profunctor/Unsafe.hs I'm not absolutely certain about what aspect of this snippet is looping the compiler, but it's pretty small. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 08:18:13 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 08:18:13 -0000 Subject: [GHC] #10030: packageName for GHC.Generics.Datatype In-Reply-To: <045.ce2f6e41c41ec92e31efde332462bf2a@haskell.org> References: <045.ce2f6e41c41ec92e31efde332462bf2a@haskell.org> Message-ID: <060.a5dad0c7436fd2bd1ae21dd0fcd4db93@haskell.org> #10030: packageName for GHC.Generics.Datatype -------------------------------------+------------------------------------- Reporter: phadej | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | 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 dreixel): * version: 7.8.4 => 7.11 Comment: Sounds perfectly reasonable and straightforward to me. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 08:46:51 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 08:46:51 -0000 Subject: [GHC] #10031: coerce can cause compiler to loop In-Reply-To: <044.15e9c8486a47b37508189b87e9fa66ab@haskell.org> References: <044.15e9c8486a47b37508189b87e9fa66ab@haskell.org> Message-ID: <059.b0f5fc8e343cbca2bc1a6fd3946e7fd3@haskell.org> #10031: coerce can cause compiler to loop -------------------------------------+------------------------------------- Reporter: glguy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 nomeata): * cc: goldfiere (added) Comment: JFTR, this does not loop with 7.8.4, so it is likely related to the Coercible solver rewrite. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 09:19:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 09:19:50 -0000 Subject: [GHC] #10030: packageName for GHC.Generics.Datatype In-Reply-To: <045.ce2f6e41c41ec92e31efde332462bf2a@haskell.org> References: <045.ce2f6e41c41ec92e31efde332462bf2a@haskell.org> Message-ID: <060.4788913b6b52615d22a8f7bbbb083daa@haskell.org> #10030: packageName for GHC.Generics.Datatype -------------------------------------+------------------------------------- Reporter: phadej | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | 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 simonpj): * owner: => dreixel Comment: I don't understand this ticket. Some code is given, but no wrong behaviour is explained. What happens that shouldn't happen? Pedro, Generics is your bailiwick: can you fix? Is it serious? Or just a little glitch? Could you write `unsafeCoerce`? What milestone for fixing? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 09:20:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 09:20:33 -0000 Subject: [GHC] #10031: coerce can cause compiler to loop In-Reply-To: <044.15e9c8486a47b37508189b87e9fa66ab@haskell.org> References: <044.15e9c8486a47b37508189b87e9fa66ab@haskell.org> Message-ID: <059.91f3bac3876a69bdc4ca4a66460e7ea4@haskell.org> #10031: coerce can cause compiler to loop -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 simonpj): * owner: => goldfire Comment: Richard, might you look at this? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 09:24:11 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 09:24:11 -0000 Subject: [GHC] #10030: packageName for GHC.Generics.Datatype In-Reply-To: <045.ce2f6e41c41ec92e31efde332462bf2a@haskell.org> References: <045.ce2f6e41c41ec92e31efde332462bf2a@haskell.org> Message-ID: <060.fe1215308cebc8d7c38bfc1167bc9b1b@haskell.org> #10030: packageName for GHC.Generics.Datatype -------------------------------------+------------------------------------- Reporter: phadej | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | 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 dreixel): It's just about adding more meta-information to the `GHC.Generics.Datatype` class, which currently does not tell you which package the datatype is coming from. It's not a bug, it's a feature request. I can implement it, but it can also be a nice little project for anyone wishing to start working with GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 09:25:33 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 09:25:33 -0000 Subject: [GHC] #10028: GHC Panic (The Impossible Happened) In-Reply-To: <052.bc0cde29811087a01e898dddf6805532@haskell.org> References: <052.bc0cde29811087a01e898dddf6805532@haskell.org> Message-ID: <067.961a3b6d07b0475d49d4f8b5e45b971c@haskell.org> #10028: GHC Panic (The Impossible Happened) -------------------------------------+------------------------------------- Reporter: archaephyrryx | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.4.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | panic,impossible,irrefutable Type of failure: Compile-time | Architecture: x86_64 crash | (amd64) Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: Thanks for reporting. Happily it was fixed in 7.6, and works in 7.8 and HEAD too. So I'll close it as fixed. (We aren't going to make another release of 7.4) Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 09:26:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 09:26:10 -0000 Subject: [GHC] #10030: packageName for GHC.Generics.Datatype In-Reply-To: <045.ce2f6e41c41ec92e31efde332462bf2a@haskell.org> References: <045.ce2f6e41c41ec92e31efde332462bf2a@haskell.org> Message-ID: <060.2591ec1528fc8113a163efb07253cd27@haskell.org> #10030: packageName for GHC.Generics.Datatype -------------------------------------+------------------------------------- Reporter: phadej | Owner: dreixel Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | 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 phadej): I could take a look on this myself. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 10:01:35 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 10:01:35 -0000 Subject: [GHC] #10027: Importing constructor of associated data type fails In-Reply-To: <048.077c953371a360576ad660349e5d3261@haskell.org> References: <048.077c953371a360576ad660349e5d3261@haskell.org> Message-ID: <063.d6917e5aa67025c61a35171a860ac85c@haskell.org> #10027: Importing constructor of associated data type fails -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | constructor import associated data Type of failure: None/Unknown | type Blocked By: | Architecture: Related Tickets: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Very good point. The same happens with this simpler test case: {{{ module A where data family D a module B where import A data Foo = Foo data instance D Foo = DCon module C where import B( D( DCon ) ) -- This import is rejected }}} Compilation of `C` fails because the `import` is rejected. It's rejected because (GHC considers that) `B` really doesn't export `D`: the family `D` is defined in module `A`. So module `B` exports only `Foo(Foo)` and the data constructor `DCon`, but not the data family `D`. Alas, that means that there is simply no way to import `DCon` explicitly. Not very clever, but that's the way it is. This does seem wrong. The issue is: what is exported if you omit an explicit export list, and just say `module M where ...`? The [https://www.haskell.org/onlinereport/haskell2010/haskellch5.html#x11-1000005.2 Haskell Report] says "If the export list is omitted, all values, types and classes defined in the module are exported, but not those that are imported". But it was written without thinking of type families. So I suppose we could agree that, for the purposes of an omitted export list, a `data instance` is considered as defining the data family too, so that the data family is exported as well as the data constructors. Otherwise there is literally no way to import the data constructor by name. And really it is odd to have data constructors in scope without their type constructor also being in scope. An alterantive would be to extend the use of `-XExplicitNamespaces` (see [https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/syntax- extns.html#explicit-namespaces user manual]) to allow an import to specify data constructor. Thus {{{ import B( datacon DCon ) }}} That could become tiresome for data types with lots of constructors. Any opinions? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 10:08:42 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 10:08:42 -0000 Subject: [GHC] #9988: Remove fun_id, is_infix from FunBind, as they are now in Match In-Reply-To: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> References: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> Message-ID: <059.d428d37f962b86c62fe36de80414ec84@haskell.org> #9988: Remove fun_id, is_infix from FunBind, as they are now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1-rc1 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): 7.10 is in RC2. We can't keep modifying it otherwise we will never get it out. I suppose that if you have strong reason to believe that you are not introducing new bugs, and having it in is going to transform your life for the better, then you can make the case. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 10:13:06 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 10:13:06 -0000 Subject: [GHC] #5218: Add unpackCStringLen# to create Strings from string literals In-Reply-To: <044.69091f2248f564745af8f69c26fefc28@haskell.org> References: <044.69091f2248f564745af8f69c26fefc28@haskell.org> Message-ID: <059.99aec3962905fd0ca3914e2485ff411c@haskell.org> #5218: Add unpackCStringLen# to create Strings from string literals -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: feature request | thoughtpolice Priority: normal | Status: new Component: Compiler | Milestone: 7.12.1 Resolution: | Version: 7.0.3 Operating System: Unknown/Multiple | Keywords: Type of failure: Runtime | Architecture: performance bug | Unknown/Multiple Blocked By: | Test Case: Related Tickets: 5877 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): I'm all for it. Does anyone feel motivated to actually work on this ticket? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 11:21:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 11:21:41 -0000 Subject: [GHC] #10021: Add "Error:" prefix for error-messages In-Reply-To: <043.cd50774548df3d55e921eb94882437a4@haskell.org> References: <043.cd50774548df3d55e921eb94882437a4@haskell.org> Message-ID: <058.b3c7875c8a690214958f6f028306ed7f@haskell.org> #10021: Add "Error:" prefix for error-messages -------------------------------------+------------------------------------- Reporter: k-bx | Owner: 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 simonpj): You don't motivate the change. Could you update the Description to explain why this would be a good change to make. Are there any disadvantages? Presuambly ever `should_fail` test in GHC's regression suite, and every other library's regression suite, would need to be updated, which would be a nuisance. If there's a consensus in favour, I'm happy for this to happen. It should also be easy to implement. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 11:24:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 11:24:41 -0000 Subject: [GHC] #10031: coerce can cause compiler to loop In-Reply-To: <044.15e9c8486a47b37508189b87e9fa66ab@haskell.org> References: <044.15e9c8486a47b37508189b87e9fa66ab@haskell.org> Message-ID: <059.5e3967e2b41d02492a9cad2d90608812@haskell.org> #10031: coerce can cause compiler to loop -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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): Confirmed with GHC HEAD. Here is the repeating tail of `-ddump-tc-trace` (not sure if it is useful) {{{ updWorkList WL {Eqs = [G] cobox_am7 :: Coercible b_am6[sk] a_am5[sk] (CTyEqCan)} Start solver pipeline { work item = [G] cobox_am7 :: Coercible b_am6[sk] a_am5[sk] (CTyEqCan) inerts = Equalities: [G] cobox_amr :: Coercible b_amq[sk] a_amp[sk] (CTyEqCan) Type-function equalities: Dictionaries: Irreds: Insolubles = {} Solved dicts runStage canonicalization { workitem = [G] cobox_am7 :: Coercible b_am6[sk] a_am5[sk] (CTyEqCan) canEqTyVar b_am6[sk] a_am5[sk] Not-swapped flattenTyVar1 a_am5[sk] * canEqTyVar flat LHS b_am6[sk] b_am6[sk] a_am5[sk] Not-swapped a_am5[sk] end stage canonicalization } runStage interact with inerts { workitem = [G] cobox_am7 :: Coercible b_am6[sk] a_am5[sk] (CTyEqCan) Can't solve tyvar equality LHS: b_am6[sk] :: * RHS: a_am5[sk] :: * TcLevel = 3 Kick out, tv = b_am6[sk] n-kicked = 1 n-kept fun-eqs = 0 WL {Eqs = [G] cobox_amr :: Coercible b_amq[sk] a_amp[sk] (CTyEqCan)} end stage interact with inerts } 1832[U:3] Kept as inert (1 kicked out): [G] cobox_am7 :: Coercible b_am6[sk] a_am5[sk] End solver pipeline (discharged) } inerts = Equalities: [G] cobox_am7 :: Coercible b_am6[sk] a_am5[sk] (CTyEqCan) Type-function equalities: Dictionaries: Irreds: Insolubles = {} Solved dicts updWorkList WL {Eqs = [G] cobox_amr :: Coercible b_amq[sk] a_amp[sk] (CTyEqCan)} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 11:32:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 11:32: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.32b395b7d886744844fb167e6cf4c461@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by simonpj): Folks, we need an interim solution for 7.10. A full fix sounds as if it'll take a little longer. But I'm anxious about releasing 7.10 with the ability to write `unsafeCoerce` in Safe Haskell. One drastic remedy: do not derive `Typeable` for polykinded type constructors. That would be easy to implement, and would certainly fix it. But it's a bit drastic. Any other offers? We need to do this in the next two weeks. Better still would be to fix it properly of course. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 12:45:44 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 12:45:44 -0000 Subject: [GHC] #10032: --with-system-libffi not working on Solaris Message-ID: <046.5141c8639bf6744efaba9be368d440ce@haskell.org> #10032: --with-system-libffi not working on Solaris -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.11 System | Operating System: Solaris Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hello, an attempt to configure ghc-7.10.1-rc2 with: {{{ $ ./configure --with-gmp-includes=/usr/include/gmp/ --with-gmp- libraries=/usr/lib/ --with-system-libffi --with-ffi- includes=/usr/lib/libffi-3.0.9/include/ --with-ffi-libraries=/usr/lib/ }}} results in kind of broken distribution, since gmake test_bindist fails with: {{{ bindisttest/"install dir"/bin/runghc bindisttest/HelloWorld > bindisttest/output diff -U 1 bindisttest/output bindisttest/expected_output No differences encountered bindisttest/"install dir"/bin/ghc --make bindisttest/HelloWorld [1 of 1] Compiling Main ( bindisttest/HelloWorld.lhs, bindisttest/HelloWorld.o ) Linking bindisttest/HelloWorld ... bindisttest/HelloWorld > bindisttest/output diff -U 1 bindisttest/output bindisttest/expected_output No differences encountered bindisttest/"install dir"/bin/ghc-pkg check --no-user-package-db There are problems in package rts-1.0: library-dirs: @FFILibDir@ is a relative path which makes no sense (as there is nothing for it to be relative to). You can make paths relative to the package database itself by using ${pkgroot}. include-dirs: @FFIIncludeDir@ is a relative path which makes no sense (as there is nothing for it to be relative to). You can make paths relative to the package database itself by using ${pkgroot}. The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. rts-1.0 ghc-7.10.0.20150123 haskeline-0.7.2.0 terminfo-0.4.0.1 xhtml-3000.2.1 transformers-0.4.2.0 hoopl-3.10.0.2 bin-package-db-0.0.0.0 Cabal-1.22.1.0 binary-0.7.3.0 template-haskell-2.10.0.0 pretty-1.1.2.0 hpc-0.6.0.2 process-1.2.2.0 directory-1.2.2.0 unix-2.7.1.0 time-1.5.0.1 containers-0.5.6.2 bytestring-0.10.6.0 deepseq-1.4.0.0 array-0.5.0.1 filepath-1.3.1.0 base-4.8.0.0 integer-gmp-1.0.0.0 ghc-prim-0.3.1.0 gmake[1]: *** [test_bindist] Error 1 gmake: *** [test_bindist] Error 2 }}} Honestly speaking I must add that even gmake binary-dist was not without issue since this expected ffi headers to be located in rts/dist/build directory but they were obviously not there. I've copied them manually and then binary-dist was able to run. I'm not sure if this is Solaris specific issue or if this also affects other Unix(-like) OSes. I mark that for 7.11 (HEAD) since I'm not sure I'll have a time to address this issue for 7.10.1-rc3/fcs. The workaround is easy, just let ghc use its own copy of ffi library and not the system provided one. In the long term however, having ghc using system provided one is better. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 14:34:50 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 14:34: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.d2d0a551ae4d8305181fabc20eb12855@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by dreixel): Replying to [comment:24 simonpj]: > One drastic remedy: do not derive `Typeable` for polykinded type constructors. That would be easy to implement, and would certainly fix it. But it's a bit drastic. Isn't that very drastic? So a data constructor that is declared with `PolyKinds` on, but can be used without it (such as `Proxy`), won't be allowed to have a `Typeable` instance at all? Or would we allow a (orphan) `Typeable` instance to be derived in a module that does not have `PolyKinds` on? Even if so, I'm afraid this might have important ramifications, also given that SYB requires `Typeable`... How about just marking `Typeable` instances for polykinded type constructors as Unsafe (if that's possible)? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 16:22:05 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 16:22:05 -0000 Subject: [GHC] #10027: Importing constructor of associated data type fails In-Reply-To: <048.077c953371a360576ad660349e5d3261@haskell.org> References: <048.077c953371a360576ad660349e5d3261@haskell.org> Message-ID: <063.eb24dde202f60806c94975c9dcecd895@haskell.org> #10027: Importing constructor of associated data type fails -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | constructor import associated data Type of failure: None/Unknown | type Blocked By: | Architecture: Related Tickets: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Don't we already have a herald for data constructors? I thought it was spelled `pattern`. I'm not being cheeky -- I seem to recall a proposal (current status/location unknown to me -- do you know?) to allow direct export/import of data constructors without their types via the `pattern` herald. That would seem to cover this case nicely, and this could be a motivating example for that proposal. With the `pattern` proposal implemented, I have only mild support for Simon's suggestion of exporting the data family along with any data instances. Would this carry over to type families too (I vote: no)? What if a module declares a constructor-less data instance? Does that by itself provoke re-export of the data family? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 16:30:15 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 16:30:15 -0000 Subject: [GHC] #10027: Importing constructor of associated data type fails In-Reply-To: <048.077c953371a360576ad660349e5d3261@haskell.org> References: <048.077c953371a360576ad660349e5d3261@haskell.org> Message-ID: <063.d75d2626955028af0252224095559ad4@haskell.org> #10027: Importing constructor of associated data type fails -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | constructor import associated data Type of failure: None/Unknown | type Blocked By: | Architecture: Related Tickets: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by carter): I think i was hit by a related problem this fall, though I was treating it as a possible haddock problem rather than GHC problem. https://github.com/haskell/haddock/issues/332, might that be related? The visibility of the data family constructors etc wrt how haddock displays does tie into this ticket i believe. Thoughts? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 16:36:07 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 16:36:07 -0000 Subject: [GHC] #10031: coerce can cause compiler to loop In-Reply-To: <044.15e9c8486a47b37508189b87e9fa66ab@haskell.org> References: <044.15e9c8486a47b37508189b87e9fa66ab@haskell.org> Message-ID: <059.ef61597a973ecb7546f3b10623371480@haskell.org> #10031: coerce can cause compiler to loop -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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 goldfire): Thanks to glguy for such a nice, tiny test case and to Joachim (nomeata) for the dump. I'm able to solve this without testing! Just add a critical missing `not` in the bowels of `kick_out`. Will validate and push shortly. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 17:08:30 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 17:08:30 -0000 Subject: [GHC] #10021: Add "Error:" prefix for error-messages In-Reply-To: <043.cd50774548df3d55e921eb94882437a4@haskell.org> References: <043.cd50774548df3d55e921eb94882437a4@haskell.org> Message-ID: <058.cf4196d3701e36495aaceb246896bee3@haskell.org> #10021: Add "Error:" prefix for error-messages -------------------------------------+------------------------------------- Reporter: k-bx | Owner: 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: -------------------------------------+------------------------------------- Description changed by k-bx: Old description: > Similar to what we have for "Warning:". > > E.g., we have: > > {{{ > ? cat test.hs > main = putStrLn "Hello!" > ? ghc --make -fforce-recomp -Wall ./test.hs > [1 of 1] Compiling Main ( test.hs, test.o ) > > test.hs:1:1: Warning: > Top-level binding with no type signature: main :: IO () > Linking test ... > ? cat test2.hs > main = foo > ? ghc --make -fforce-recomp -Wall ./test2.hs > [1 of 1] Compiling Main ( test2.hs, test2.o ) > > test2.hs:1:8: Not in scope: ?foo? > }}} > > And I propose having: > > {{{ > ? cat test2.hs > main = foo > ? ghc --make -fforce-recomp -Wall ./test2.hs > [1 of 1] Compiling Main ( test2.hs, test2.o ) > > test2.hs:1:8: Error: Not in scope: ?foo? > }}} New description: Similar to what we have for "Warning:". E.g., we have: {{{ ? cat test.hs main = putStrLn "Hello!" ? ghc --make -fforce-recomp -Wall ./test.hs [1 of 1] Compiling Main ( test.hs, test.o ) test.hs:1:1: Warning: Top-level binding with no type signature: main :: IO () Linking test ... ? cat test2.hs main = foo ? ghc --make -fforce-recomp -Wall ./test2.hs [1 of 1] Compiling Main ( test2.hs, test2.o ) test2.hs:1:8: Not in scope: ?foo? }}} And I propose having: {{{ ? cat test2.hs main = foo ? ghc --make -fforce-recomp -Wall ./test2.hs [1 of 1] Compiling Main ( test2.hs, test2.o ) test2.hs:1:8: Error: Not in scope: ?foo? }}} == Motivation == Main motivation point right now is that there's a ticket #9219 (parallel build's output of errors doesn't occur at the end of output), due to which, error-reporting of your program might get lost somewhere in the middle of a build-log. As another example, if your program has a lot of warnings, and you build it with multiple cores, you almost always get an error lost somewhere in the middle of warnings and it's almost impossible to find. So, this feature's main purpose is to ease navigation in textual output of ghc in order to find errors quickly, not being tied to output ordering. == Disadvantages == Many regression tests might need a fix. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 17:09:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 17:09:34 -0000 Subject: [GHC] #10031: coerce can cause compiler to loop In-Reply-To: <044.15e9c8486a47b37508189b87e9fa66ab@haskell.org> References: <044.15e9c8486a47b37508189b87e9fa66ab@haskell.org> Message-ID: <059.a0cec6ccce62822d91a2f0eb4cb54579@haskell.org> #10031: coerce can cause compiler to loop -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: Phab:D630 -------------------------------------+------------------------------------- Changes (by goldfire): * differential: => Phab:D630 Comment: Just using Phab to validate... I don't think this needs external eyes to review. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 17:14:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 17:14:38 -0000 Subject: [GHC] #10021: Add "Error:" prefix for error-messages In-Reply-To: <043.cd50774548df3d55e921eb94882437a4@haskell.org> References: <043.cd50774548df3d55e921eb94882437a4@haskell.org> Message-ID: <058.e49152a13e27415231f0f2aa3d7ea03b@haskell.org> #10021: Add "Error:" prefix for error-messages -------------------------------------+------------------------------------- Reporter: k-bx | Owner: 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 k-bx): @simonpj added motivation and disadvantages sections. Waiting for more input on mailing list for now and started digging into ghc ecosystem (e.g. was fighting few `sh validate` errors). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 17:21:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 17:21:41 -0000 Subject: [GHC] #10033: Can't push to `wip/...` branches because of pre-commit check Message-ID: <047.b5a5fb2b14296aa7dfc2b8e58a6a2c93@haskell.org> #10033: Can't push to `wip/...` branches because of pre-commit check -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- I made some edits on my `wip/rae` branch and tried to push to the remote `wip/rae` branch. But I see this: {{{ 11:42:05 ~/Documents/Programming/ghc-cur> git push -u origin wip/rae --force Counting objects: 5, done. Delta compression using up to 2 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (5/5), 580 bytes | 0 bytes/s, done. Total 5 (delta 4), reused 0 (delta 0) remote: performing tab-check... remote: Error: you may not add a line containing a tab to these tab-free files: remote: testsuite/tests/rename/should_fail/Makefile To ssh://git at git.haskell.org/ghc.git ! [remote rejected] wip/rae -> wip/rae (pre-receive hook declined) error: failed to push some refs to 'ssh://git at git.haskell.org/ghc.git' }}} There are two problems here: 1. I didn't change `testsuite/tests/rename/should_fail/Makefile`! 2. `Makefile`s like having tabs in them. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 17:46:19 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 17:46:19 -0000 Subject: [GHC] #10030: packageName for GHC.Generics.Datatype In-Reply-To: <045.ce2f6e41c41ec92e31efde332462bf2a@haskell.org> References: <045.ce2f6e41c41ec92e31efde332462bf2a@haskell.org> Message-ID: <060.9a204980b8ab057377e7364c14938322@haskell.org> #10030: packageName for GHC.Generics.Datatype -------------------------------------+------------------------------------- Reporter: phadej | Owner: dreixel Type: feature request | Status: patch Priority: normal | Milestone: Component: libraries/base | 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:D631 -------------------------------------+------------------------------------- Changes (by phadej): * status: new => patch * differential: => Phab:D631 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 17:56:18 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 17:56:18 -0000 Subject: [GHC] #10034: Regression in mapM_ performance Message-ID: <045.b2f20563c81747821afdf8039fd29472@haskell.org> #10034: Regression in mapM_ performance -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core | Version: 7.10.1-rc2 Libraries | Operating System: Unknown/Multiple Keywords: | Type of failure: Runtime Architecture: | performance bug Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: Phab:D632 | -------------------------------------+------------------------------------- The current `mapM_` is sometimes worse than the version in 7.8.3. This can be fixed easily by eta-expansion, matching `mapM`. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 17:56:26 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 17:56: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.b96aa902e97e26e51adee7ec51d323f3@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by int-e): Replying to [comment:25 dreixel]: > How about just marking `Typeable` instances for polykinded type constructors as Unsafe (if that's possible)? Given how notoriously hard it is to control exports of instances, that won't be enough. To make things worse, the offending instance used here (for {{{Proxy}}}) is derived in {{{Data.Typeable.Internal}}}, which is marked {{{Trustworthy}}}. So conscientious users of safe Haskell would not be able to trust the base package anymore, rendering safe Haskell all but useless. I guess the right way to leverage safe Haskell is to mark {{{Data.Typeable}}} as unsafe, and explain the situation in a big comment. It would still be a pain to track uses of {{{Data.Typeable}}} in {{{Trustworthy}}} modules of other libraries (say, lens and its dependencies). I'm afraid there is no good interim solution here. I favor spj's suggestion, but #9111 suggests that some people actually use {{{Typeable}}} for {{{Proxy}}}. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 18:34:38 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 18:34:38 -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.6cb6e817ab3f5393289238e531d4b24f@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by crockeea): To echo @dreixel: What exactly *is* SPJ's suggestion? Is it to not *automatically* derive `Typeable` instances for poly-kinded type constructors, or is to disallow standalone-derived instances as well? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 19:03:32 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 19:03:32 -0000 Subject: [GHC] #10032: binary distributions not working --with-system-libffi (was: --with-system-libffi not working on Solaris) In-Reply-To: <046.5141c8639bf6744efaba9be368d440ce@haskell.org> References: <046.5141c8639bf6744efaba9be368d440ce@haskell.org> Message-ID: <061.f407f069c9cd012a69bd496a7c9a069e@haskell.org> #10032: binary distributions not working --with-system-libffi -------------------------------------+------------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | 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 trommler): * os: Solaris => Unknown/Multiple Comment: You are right, this is not a Solaris only issue. Building a binary distribution with system libffi has never worked on Linux either. At the time I implemented system libffi support I tried to support binary distributions too but gave up half way through because it was not important for Linux distribution providers. I don't think it is difficult to do. Give me a shout if you need help. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 19:16:10 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 19:16:10 -0000 Subject: [GHC] #10035: Harbormaster doesn't post to Differential on success Message-ID: <047.651e63f29ee488b1428e2fffc73c9399@haskell.org> #10035: Harbormaster doesn't post to Differential on success -------------------------------------+------------------------------------- Reporter: goldfire | Owner: 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: | -------------------------------------+------------------------------------- I recently posted a small diff to Phab to get a validate running (Phab:D630, if you must know). Harbormaster happily went and validated, but it never told me that it succeeded! Harbormaster's logs show the success, but I was waiting for an email (generated by activity on my diff, not sent directly from Harbormaster). If others think that this might be nice behavior, could we make this the default, the Harbormaster posts to Differential on success or failure? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 19:16:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 19:16:34 -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.a16d8f9257866e94c9ebbd09586fb06e@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:27 crockeea]: > To echo @dreixel: What exactly *is* SPJ's suggestion? Is it to not *automatically* derive `Typeable` instances for poly-kinded type constructors, or is to disallow standalone-derived instances as well? Presumably it would be safe to allow a *single* standalone derivation in the same module that defines the type, as long as it's of actual monomorphic kind. That way, at least `Proxy` could still have a `* -> *` instance, which might be the one that is used the most in practice? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 19:16:52 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 19:16:52 -0000 Subject: [GHC] #10031: coerce can cause compiler to loop In-Reply-To: <044.15e9c8486a47b37508189b87e9fa66ab@haskell.org> References: <044.15e9c8486a47b37508189b87e9fa66ab@haskell.org> Message-ID: <059.1c5b22b7dbd8c5d49fa22006c712c9e7@haskell.org> #10031: coerce can cause compiler to loop -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.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: Phab:D630 -------------------------------------+------------------------------------- Comment (by Richard Eisenberg ): In [changeset:"cecf036fa10830a5e9861d1e6a2f8c22059fb4bb/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="cecf036fa10830a5e9861d1e6a2f8c22059fb4bb" Fix #10031 by inverting a critical test in kick_out. Summary: The documentation (Note [The flattening story] in TcFlatten) was correct; it's just the implementation that was not. Test in typecheck/should_compile/T10031 Test Plan: validate Reviewers: austin Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D630 GHC Trac Issues: #10031 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 19:18:34 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 19:18:34 -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.40b36e4d177f03a1518d66a8374d7beb@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by oerjan): In fact, a single automatically derived instance (presumably defaulting as much as possible to `*`) should also be safe. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 19:18:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 19:18:41 -0000 Subject: [GHC] #10035: Harbormaster doesn't post to Differential on success In-Reply-To: <047.651e63f29ee488b1428e2fffc73c9399@haskell.org> References: <047.651e63f29ee488b1428e2fffc73c9399@haskell.org> Message-ID: <062.0765e46b8e8d701d40df893ac9b8803a@haskell.org> #10035: Harbormaster doesn't post to Differential on success -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Trac & Git | Version: 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): +1, I was surprised that Harbormaster doesn't do this already (probably influenced by my experience with another CI system). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 19:18:47 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 19:18:47 -0000 Subject: [GHC] #10031: coerce can cause compiler to loop In-Reply-To: <044.15e9c8486a47b37508189b87e9fa66ab@haskell.org> References: <044.15e9c8486a47b37508189b87e9fa66ab@haskell.org> Message-ID: <059.b9bd023a5a324a30e045cff6a6001814@haskell.org> #10031: coerce can cause compiler to loop -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: merge Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | typecheck/should_compile/T10031 Related Tickets: | Blocking: | Differential Revisions: Phab:D630 -------------------------------------+------------------------------------- Changes (by goldfire): * status: new => merge * testcase: => typecheck/should_compile/T10031 Comment: Please merge for 7.10.1. This is a clear error and should be dead simple to merge. Thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 20:58:54 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 20:58:54 -0000 Subject: [GHC] #9122: Make Lint check for bad uses of `unsafeCoerce` In-Reply-To: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> References: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> Message-ID: <061.c65962864e188fa79efbad58b12e2cba@haskell.org> #9122: Make Lint check for bad uses of `unsafeCoerce` -------------------------------------+------------------------------------- Reporter: simonpj | Owner: qnikst Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 qnikst): * owner: => qnikst -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 21:41:41 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 21:41:41 -0000 Subject: [GHC] #10036: Update Cabal before final 7.10 release Message-ID: <045.30bd56cc85f6bc5bb45606c0ed8642f0@haskell.org> #10036: Update Cabal before final 7.10 release -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: libraries | Version: 7.10.1-rc2 (other) | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- It will be good to get this fix into the released version of Cabal, so that 7.10-built cabal installs do the right thing when operating older versions of GHC. https://github.com/haskell/cabal/pull/2391 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Tue Jan 27 21:41:48 2015 From: ghc-devs at haskell.org (GHC) Date: Tue, 27 Jan 2015 21:41:48 -0000 Subject: [GHC] #10036: Update Cabal before final 7.10 release In-Reply-To: <045.30bd56cc85f6bc5bb45606c0ed8642f0@haskell.org> References: <045.30bd56cc85f6bc5bb45606c0ed8642f0@haskell.org> Message-ID: <060.6891dcdd3655953424a934bb74a8007d@haskell.org> #10036: Update Cabal before final 7.10 release -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: patch Priority: high | Milestone: 7.10.1 Component: libraries | Version: 7.10.1-rc2 (other) | 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 ezyang): * status: new => patch -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 09:03:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 09:03:03 -0000 Subject: [GHC] #10027: Importing constructor of associated data type fails In-Reply-To: <048.077c953371a360576ad660349e5d3261@haskell.org> References: <048.077c953371a360576ad660349e5d3261@haskell.org> Message-ID: <063.1c50a8d5e34951b90b3ba283ea891dec@haskell.org> #10027: Importing constructor of associated data type fails -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | constructor import associated data Type of failure: None/Unknown | type Blocked By: | Architecture: Related Tickets: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by simonpj): Re comment:2, yes, you are right, I'd forgotten that. The remaining infelicity is that if the data type has 200 constructors, you'll have to say {{{ import M( pattern C1, pattern C2, ..., pattern C200 ) }}} rather than {{{ import M( T(..) ) }}} But perhaps this will happen so seldom that we don't care. Partly it's a question of matching is it ''surprising'' that you module B above does not export D? Or would it be surprising if it ''did'' export it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 09:26:13 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 09:26:13 -0000 Subject: [GHC] #10034: Regression in mapM_ performance In-Reply-To: <045.b2f20563c81747821afdf8039fd29472@haskell.org> References: <045.b2f20563c81747821afdf8039fd29472@haskell.org> Message-ID: <060.46d0d23293cd1e5e0bc28a7e72de5c54@haskell.org> #10034: Regression in mapM_ performance -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.10.1-rc2 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:D632 -------------------------------------+------------------------------------- Comment (by simonpj): Can you offer a reproducible test case, and timing or allocation data? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 10:20:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 10:20:23 -0000 Subject: [GHC] #4505: Segmentation fault on long input (list of pairs) In-Reply-To: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> References: <046.2dc545b3c32e7b8eef61780dd9491ae5@haskell.org> Message-ID: <061.a85f9c4252c9dacde13cb4af4863d9ae@haskell.org> #4505: Segmentation fault on long input (list of pairs) -------------------------------------+------------------------------------- Reporter: cathper | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.1 Resolution: | Keywords: Operating System: Linux | Segmentation fault, segfault, long Type of failure: Runtime crash | input Blocked By: 4258 | Architecture: x86_64 Related Tickets: | (amd64) | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by merijn): * cc: merijn (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 10:42:35 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 10:42:35 -0000 Subject: [GHC] #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows In-Reply-To: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> References: <051.9bd9875fb01e6198fe81abe3cec3e53a@haskell.org> Message-ID: <066.02bd3afedcedd08b00e6f03d5147ed66@haskell.org> #9907: "Unknown PEi386 section name `.text$printf'" error in GHCi on Windows ---------------------------------+----------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.3 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------+----------------------------------------- Comment (by kdmadej): I've encountered a similar error while working on windows myself. Checked with the attached example and it also crashes. Is there a chance this matter will get looked into? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 10:58:39 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 10:58:39 -0000 Subject: [GHC] #10021: Add "Error:" prefix for error-messages In-Reply-To: <043.cd50774548df3d55e921eb94882437a4@haskell.org> References: <043.cd50774548df3d55e921eb94882437a4@haskell.org> Message-ID: <058.52e6ffbcb1ecab444ff3468ab58665d1@haskell.org> #10021: Add "Error:" prefix for error-messages -------------------------------------+------------------------------------- Reporter: k-bx | Owner: 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: -------------------------------------+------------------------------------- Description changed by simonpj: Old description: > Similar to what we have for "Warning:". > > E.g., we have: > > {{{ > ? cat test.hs > main = putStrLn "Hello!" > ? ghc --make -fforce-recomp -Wall ./test.hs > [1 of 1] Compiling Main ( test.hs, test.o ) > > test.hs:1:1: Warning: > Top-level binding with no type signature: main :: IO () > Linking test ... > ? cat test2.hs > main = foo > ? ghc --make -fforce-recomp -Wall ./test2.hs > [1 of 1] Compiling Main ( test2.hs, test2.o ) > > test2.hs:1:8: Not in scope: ?foo? > }}} > > And I propose having: > > {{{ > ? cat test2.hs > main = foo > ? ghc --make -fforce-recomp -Wall ./test2.hs > [1 of 1] Compiling Main ( test2.hs, test2.o ) > > test2.hs:1:8: Error: Not in scope: ?foo? > }}} > > == Motivation == > > Main motivation point right now is that there's a ticket #9219 (parallel > build's output of errors doesn't occur at the end of output), due to > which, error-reporting of your program might get lost somewhere in the > middle of a build-log. As another example, if your program has a lot of > warnings, and you build it with multiple cores, you almost always get an > error lost somewhere in the middle of warnings and it's almost impossible > to find. > > So, this feature's main purpose is to ease navigation in textual output > of ghc in order to find errors quickly, not being tied to output > ordering. > > == Disadvantages == > > Many regression tests might need a fix. New description: Similar to what we have for "Warning:". E.g., we have: {{{ ? cat test.hs main = putStrLn "Hello!" ? ghc --make -fforce-recomp -Wall ./test.hs [1 of 1] Compiling Main ( test.hs, test.o ) test.hs:1:1: Warning: Top-level binding with no type signature: main :: IO () Linking test ... ? cat test2.hs main = foo ? ghc --make -fforce-recomp -Wall ./test2.hs [1 of 1] Compiling Main ( test2.hs, test2.o ) test2.hs:1:8: Not in scope: ?foo? }}} And I propose having: {{{ ? cat test2.hs main = foo ? ghc --make -fforce-recomp -Wall ./test2.hs [1 of 1] Compiling Main ( test2.hs, test2.o ) test2.hs:1:8: Error: Not in scope: ?foo? }}} This proposal only affects error messages produced by GHC itself. For example, the behaviour of the `error` function is unaffected. == Motivation == Main motivation point right now is that there's a ticket #9219 (parallel build's output of errors doesn't occur at the end of output), due to which, error-reporting of your program might get lost somewhere in the middle of a build-log. As another example, if your program has a lot of warnings, and you build it with multiple cores, you almost always get an error lost somewhere in the middle of warnings and it's almost impossible to find. So, this feature's main purpose is to ease navigation in textual output of ghc in order to find errors quickly, not being tied to output ordering. == Disadvantages == Many regression tests might need a fix. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 11:14:05 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 11:14:05 -0000 Subject: [GHC] #10021: Add "Error:" prefix for error-messages In-Reply-To: <043.cd50774548df3d55e921eb94882437a4@haskell.org> References: <043.cd50774548df3d55e921eb94882437a4@haskell.org> Message-ID: <058.cc11e921271d88cd179c3f84620ba7dd@haskell.org> #10021: Add "Error:" prefix for error-messages -------------------------------------+------------------------------------- Reporter: k-bx | Owner: 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 hvr): I'd like to propose to change the case of `Error` and `Warning` to lower case to match the convention as used by the most popular C/C++-compilers these days. For reference, this is what `gcc` currently does: {{{ $ gcc -Wall -c foo.c foo.c: In function ?main?: foo.c:2:1: warning: control reaches end of non-void function [-Wreturn- type] int main() { } ^ }}} {{{ $ gcc -Wall -Werror -c foo.c foo.c: In function ?main?: foo.c:2:1: error: control reaches end of non-void function [-Werror =return-type] int main() { } ^ cc1: all warnings being treated as errors }}} and here's what `clang` does: {{{ $ clang-3.5 -Wall -c foo.c foo.c:2:18: warning: unused variable 'x' [-Wunused-variable] int main() { int x = 0; } ^ 1 warning generated. }}} {{{ $ clang-3.5 -Wall -Werror -c foo.c foo.c:2:18: error: unused variable 'x' [-Werror,-Wunused-variable] int main() { int x = 0; } ^ 1 error generated. }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 11:14:07 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 11:14:07 -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.9669f1dedc638db90e14ab89a9eb6ec5@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by simonpj): Yes, SPJ's drastic suggestion is: you polykinded type constructor cannot be an instance of `Typeable`, by `deriving`, or `AutoDeriveTypable`, or standalone deriving. Period. Here's an alternative proposal. * `....deriving( Typeable )` (and `AutoDeriveTypeable`) on a polykinded tycon will fail (with a helpful message) * But instead you can give any number of mono-kinded standalone instances {{{ deriving instance Typeable (Proxy :: (* -> *) -> *) }}} Comments on the proposal * It's still not ideal because you can never declare "enough" instances and if you declare an extra one at some use site, it might conflict with someone else's. * It requires some modification to GHC, which current rejects such standalone deriving instances, precisely because they are not fully polymorphic. * And the kinds would have to be included in the fingerprint of the `TyCon` generated by the standalone derived instance. But that seems ok as a holding position. The "right" solution is, I think, at the bottom of comment:20. But NB that solution will mean that all these standalone derived instances would become illegal, so there is a backward compatibility cost. The drastic solution does not have this problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 11:20:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 11:20:59 -0000 Subject: [GHC] #10037: Several profiling tests give different results optimised vs. unoptimised Message-ID: <047.efcb9e013309246f2cfca887b5137899@haskell.org> #10037: Several profiling tests give different results optimised vs. unoptimised -------------------------------------+------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Profiling | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Most of the differences are relatively harmless (mostly CAF attribution), but it would be nice to get this right. In the meantime I'll mark them expect_broken and point to this ticket. The following tests in `tests/profiling/should_run` are affected: {{{ scc001 T2552 ioprof callstack001 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 11:43:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 11:43:15 -0000 Subject: [GHC] #10021: Add "Error:" prefix for compile-time error messages (was: Add "Error:" prefix for error-messages) In-Reply-To: <043.cd50774548df3d55e921eb94882437a4@haskell.org> References: <043.cd50774548df3d55e921eb94882437a4@haskell.org> Message-ID: <058.b81bfde86a9b3a0baa8664dd7580b78d@haskell.org> #10021: Add "Error:" prefix for compile-time error messages -------------------------------------+------------------------------------- Reporter: k-bx | Owner: 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: -------------------------------------+------------------------------------- Description changed by k-bx: Old description: > Similar to what we have for "Warning:". > > E.g., we have: > > {{{ > ? cat test.hs > main = putStrLn "Hello!" > ? ghc --make -fforce-recomp -Wall ./test.hs > [1 of 1] Compiling Main ( test.hs, test.o ) > > test.hs:1:1: Warning: > Top-level binding with no type signature: main :: IO () > Linking test ... > ? cat test2.hs > main = foo > ? ghc --make -fforce-recomp -Wall ./test2.hs > [1 of 1] Compiling Main ( test2.hs, test2.o ) > > test2.hs:1:8: Not in scope: ?foo? > }}} > > And I propose having: > > {{{ > ? cat test2.hs > main = foo > ? ghc --make -fforce-recomp -Wall ./test2.hs > [1 of 1] Compiling Main ( test2.hs, test2.o ) > > test2.hs:1:8: Error: Not in scope: ?foo? > }}} > > This proposal only affects error messages produced by GHC itself. For > example, the behaviour of the `error` function is unaffected. > > == Motivation == > > Main motivation point right now is that there's a ticket #9219 (parallel > build's output of errors doesn't occur at the end of output), due to > which, error-reporting of your program might get lost somewhere in the > middle of a build-log. As another example, if your program has a lot of > warnings, and you build it with multiple cores, you almost always get an > error lost somewhere in the middle of warnings and it's almost impossible > to find. > > So, this feature's main purpose is to ease navigation in textual output > of ghc in order to find errors quickly, not being tied to output > ordering. > > == Disadvantages == > > Many regression tests might need a fix. New description: The proposal is to modify GHC compile-time output for error-messages, by adding a prefix, similar to what we currently have for warnings. An example of a warning message (see `Warning:` prefix): {{{ ? cat test.hs main = putStrLn "Hello!" ? ghc --make -fforce-recomp -Wall ./test.hs [1 of 1] Compiling Main ( test.hs, test.o ) test.hs:1:1: Warning: Top-level binding with no type signature: main :: IO () Linking test ... }}} An example of current output for an error: {{{ ? cat test2.hs main = foo ? ghc --make -fforce-recomp -Wall ./test2.hs [1 of 1] Compiling Main ( test2.hs, test2.o ) test2.hs:1:8: Not in scope: ?foo? }}} The proposal is to change it to become: {{{ ? cat test2.hs main = foo ? ghc --make -fforce-recomp -Wall ./test2.hs [1 of 1] Compiling Main ( test2.hs, test2.o ) test2.hs:1:8: Error: Not in scope: ?foo? }}} This proposal only affects error messages produced by GHC itself. For example, the behaviour of the `error` function is unaffected. == Motivation == Main motivation point right now is that there's a ticket #9219 (parallel build's output of errors doesn't occur at the end of output), due to which, error-reporting of your program might get lost somewhere in the middle of a build-log. As another example, if your program has a lot of warnings, and you build it with multiple cores, you almost always get an error lost somewhere in the middle of warnings and it's almost impossible to find. So, this feature's main purpose is to ease navigation in textual output of ghc in order to find errors quickly, not being tied to output ordering. == Disadvantages == Many regression tests might need a fix. == Additional consideration == @hvr proposed that during work on this bug we could make GHC output more consistent with other compiler's (GCC and clang) by also lower-casing "Error" and "Warning" prefixes. This might be potentially useful for existing tools that work on top of compiler output for finding errors/warning, and GHC's output will become "more valid" for them. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 11:43:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 11:43:42 -0000 Subject: [GHC] #10007: Fix misattribution of Cost Centre profiles to lintAnnots In-Reply-To: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> References: <052.018bee922f3a1f3c0286b790702cf38d@haskell.org> Message-ID: <067.a77661cd83a182a0f78c0f2dacee65e4@haskell.org> #10007: Fix misattribution of Cost Centre profiles to lintAnnots -------------------------------------+------------------------------------- Reporter: thoughtpolice | Owner: scpmw Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Profiling | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9961 | Differential Revisions: Phab:D616 | Phab:D636 -------------------------------------+------------------------------------- Changes (by simonmar): * differential: Phab:D616 => Phab:D616 Phab:D636 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 11:45:23 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 11:45:23 -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.db3a61f8887df9f0f12dceb2e832e1a2@haskell.org> #10021: Add "Error:" prefix for compile-time error messages -------------------------------------+------------------------------------- Reporter: k-bx | Owner: 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 k-bx): @hvr while Emacs compilation highliter (the one that lets you navigate through errors after `M-x compile`) is smart enough to understand current GHC output, I would say that lower-casing might be useful for other similar tools that work on top of compiler's output and are hard-coded for GCC/clang lower-cased "error" and "warning", so +1 from me on this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 11:55:56 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 11:55:56 -0000 Subject: [GHC] #10029: unit-tests: internal error: evacuate(static): strange closure type 62744 In-Reply-To: <050.3e189618a175273ea644d5072d51372c@haskell.org> References: <050.3e189618a175273ea644d5072d51372c@haskell.org> Message-ID: <065.032c036ecd3493546dc95b76ba361841@haskell.org> #10029: unit-tests: internal error: evacuate(static): strange closure type 62744 ---------------------------------------+-------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------------+-------------------------------- Comment (by juhpetersen): Similar error seems to happen with zip-archive (0.2.3.5). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 12:11:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 12:11:25 -0000 Subject: [GHC] #9213: Maybe important CPP warnings on ghcautoconf.h (was: Maybe important CPP warnings on ghcautoconf.h from cpphs) In-Reply-To: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> References: <042.40c8fe49091f5227ff0b9eb0ac8fb5d0@haskell.org> Message-ID: <057.41565cf7f014afe1b523999ee33b7c93@haskell.org> #9213: Maybe important CPP warnings on ghcautoconf.h -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.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: -------------------------------------+------------------------------------- Changes (by asr): * version: 7.10.1-rc1 => 7.10.1-rc2 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 12:23:00 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 12:23:00 -0000 Subject: [GHC] #10027: Importing constructor of associated data type fails In-Reply-To: <048.077c953371a360576ad660349e5d3261@haskell.org> References: <048.077c953371a360576ad660349e5d3261@haskell.org> Message-ID: <063.a0edc35bf9e46644035cc816e48ed23a@haskell.org> #10027: Importing constructor of associated data type fails -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | constructor import associated data Type of failure: None/Unknown | type Blocked By: | Architecture: Related Tickets: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Personally, I would find it surprising if module B ''did'' export D. I don't consider writing an instance of a thing as something that will add the thing to an implicit export list. I'm OK with being surprised in this way for the sake of practicality, but I would find it surprising. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 12:27:12 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 12:27:12 -0000 Subject: [GHC] #9928: Wrong information about the previous version of the time library in GHC 7.10.1 RC2 release notes (was: Wrong information about the version of the time library in the release notes of various versions of GHC) In-Reply-To: <042.da80f41221c9fccf24e54a1fbfd2424e@haskell.org> References: <042.da80f41221c9fccf24e54a1fbfd2424e@haskell.org> Message-ID: <057.8e24d62b3fdcd7d9ab54f692e014cc9f@haskell.org> #9928: Wrong information about the previous version of the time library in GHC 7.10.1 RC2 release notes -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Documentation | 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: -------------------------------------+------------------------------------- Changes (by asr): * status: closed => new * version: 7.10.1-rc1 => 7.10.1-rc2 * resolution: fixed => Old description: > The information about the version of the time library is wrong in the > release notes of > [https://downloads.haskell.org/~ghc/7.10.1-rc1/docs/html/users_guide/release-7-10-1.html > GHC 7.10.1 RC1], > [https://downloads.haskell.org/~ghc/7.8.1/docs/html/users_guide/release-7-8-1.html > GHC 7.8.3] and > [https://downloads.haskell.org/~ghc/7.6.1/docs/html/users_guide/release-7-6-1.html > GHC 7.6.1]. New description: From https://downloads.haskell.org/~ghc/7.10.1-rc2/docs/users_guide.pdf: Version number ... (was 1.4.1) The right information is: Version number ... (was 1.4.2) (Note also that the information about the (previous) version of the time library is wrong in the release notes of [https://downloads.haskell.org/~ghc/7.8.1/docs/html/users_guide/release-7-8-1.html GHC 7.8.3] and [https://downloads.haskell.org/~ghc/7.6.1/docs/html/users_guide/release-7-6-1.html GHC 7.6.1]). -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 12:31:45 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 12:31:45 -0000 Subject: [GHC] #9928: Wrong information about the previous version of the time library in GHC 7.10.1 RC2 release notes In-Reply-To: <042.da80f41221c9fccf24e54a1fbfd2424e@haskell.org> References: <042.da80f41221c9fccf24e54a1fbfd2424e@haskell.org> Message-ID: <057.4e4b87364f8dfcbf412986922203d0b3@haskell.org> #9928: Wrong information about the previous version of the time library in GHC 7.10.1 RC2 release notes -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Documentation | 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 asr): Replying to [comment:1 thoughtpolice]: > This should hopefully be fixed in the 7.10.1 RC2 release notes (synchronized with `time-1.5.0.1`). It wasn't. I changed the description to emphasise the issue in GHC 7.10.1 RC2. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 12:54:49 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 12:54:49 -0000 Subject: [GHC] #10038: Missing information about some libraries in the GHC 7.10.1 RC2 release notes Message-ID: <042.2351aa32b11f999d614978d597e46a77@haskell.org> #10038: Missing information about some libraries in the GHC 7.10.1 RC2 release notes -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: | Version: 7.10.1-rc2 Documentation | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- GHC 7.10.1.RC2 is shipped with the following libraries: haskeline-0.7.2.0, pretty-1.1.2.0, terminfo-0.4.0.1, transformers-0.4.2.0 and xhtml-3000.2.1. In Section 1.5.3 of https://downloads.haskell.org/~ghc/7.10.1-rc2/docs/users_guide.pdf there isn't information about these libraries. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 13:19:55 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 13:19:55 -0000 Subject: [GHC] #9122: Make Lint check for bad uses of `unsafeCoerce` In-Reply-To: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> References: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> Message-ID: <061.2306392023e5aca72e685736790398c5@haskell.org> #9122: Make Lint check for bad uses of `unsafeCoerce` -------------------------------------+------------------------------------- Reporter: simonpj | Owner: qnikst Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 goldfire): I'm helping qnikst out with this, but I have a question. Say someone writes {{{ unsafeCoerce# (3 :: Int) :: Int# }}} According to the original feature request, this should be a Core Lint error. However, is it an error earlier in the GHC pipeline? In 7.8.3, this compiles just fine, though it falls over rather completely when run. (No surprise there!) If it's ''not'' an error earlier, this would seem to violate the principle that Core Lint should just be checking for GHC bugs, not user silliness. So, is it necessary to check for such silliness in the typechecker now, too? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 13:46:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 13:46:02 -0000 Subject: [GHC] #9122: Make Lint check for bad uses of `unsafeCoerce` In-Reply-To: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> References: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> Message-ID: <061.6d17325f16ff75f2b5c3f949788f93a8@haskell.org> #9122: Make Lint check for bad uses of `unsafeCoerce` -------------------------------------+------------------------------------- Reporter: simonpj | Owner: qnikst Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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 simonpj): I don't know how to reason about what might be "an error at some particular stage of the pipeline". ANY use of `unsafeCoerce` might make a program seg-fault. So at best these checks are going to smoke out uses that are more than usually likely to cause this behaviour. It's all very squishy. Ask a more specific question and I'll try to help. S -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 13:51:28 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 13:51:28 -0000 Subject: [GHC] #10039: Make Const (Control.Applicative) kind polymorphic in its second argument Message-ID: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> #10039: Make Const (Control.Applicative) kind polymorphic in its second argument -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: feature | Milestone: request | Version: 7.8.4 Priority: normal | Operating System: Unknown/Multiple Component: | Type of failure: None/Unknown libraries/base | Blocked By: Keywords: | Related Tickets: Architecture: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Is there any reason why `Const` isn't kind polymorphic? {{{#!hs newtype Const a (b :: k) = Const { getConst :: a } deriving (Generic, Generic1) }}} An example where I need it is for [[http://wiki.ocharles.org.uk/Name%20Binding%20in%20EDSLs|interpreting typed PHOAS]], the following fails to compile complaining that `The first argument of ?PTerm? should have kind ?Ty -> *?, but ?Const Char? has kind ?* -> *?`: {{{#!hs {-# LANGUAGE DataKinds, KindSignatures, GADTs, RankNTypes, PolyKinds #-} import Control.Applicative data Ty = TyBool | TyArr Ty Ty data PTerm :: (Ty -> *) -> Ty -> * where Var :: v t -> PTerm v t Tru :: PTerm v 'TyBool Fals :: PTerm v 'TyBool App :: PTerm v ('TyArr t1 t2) -> PTerm v t1 -> PTerm v t2 Abs :: (v t1 -> PTerm v t2) -> PTerm v ('TyArr t1 t2) newtype Term t = Term (forall v. PTerm v t) showT :: Term t -> String showT (Term pterm) = show' 'a' pterm where show' :: Char -> PTerm (Const Char) t -> String show' _ (Var (Const c)) = [c] show' _ Tru = "True" show' _ Fals = "False" show' s (App x y) = "(" ++ show' s x ++ ") " ++ show' s y show' s (Abs f) = [s] ++ ". " ++ show' (succ s) (f (Const s)) }}} but it compiles if one defines a bespoke form of `Const` with kind `* -> Ty -> *` (or the more general suggestion at the beginning of the ticket), I implemented all the related instances from `Control.Applicative` and the compiled without a hitch. Relevant discussion: a [[http://stackoverflow.com/questions/2023052/haskell-specifying-kind-in- data-declaration|question on StackOverflow]] that predates the `PolyKinds` extension effectively wants to define `type Const' (a :: * -> *) = Const Integer a` which would be possible if it were kind polymorphic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 13:53:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 13:53:25 -0000 Subject: [GHC] #10039: Make Const (Control.Applicative) kind polymorphic in its second argument In-Reply-To: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> References: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> Message-ID: <066.2b5af420affa774b73f54597a730f4db@haskell.org> #10039: Make Const (Control.Applicative) kind polymorphic in its second argument -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: libraries/base | 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): A good question for the Core Libraries Committee -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 13:53:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 13:53:38 -0000 Subject: [GHC] #10039: Make Const (Control.Applicative) kind polymorphic in its second argument In-Reply-To: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> References: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> Message-ID: <066.253b532df006543487dc05829c257c78@haskell.org> #10039: Make Const (Control.Applicative) kind polymorphic in its second argument -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | 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): * cc: core-libraries-committee@? (added) * owner: => ekmett * component: libraries/base => Core Libraries -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 13:54:20 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 13:54:20 -0000 Subject: [GHC] #10040: Add hint on typed-hole error message Message-ID: <046.d6ed159d7a55e19a5744bc39409823df@haskell.org> #10040: Add hint on typed-hole error message -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- If you write {{{ f flag = _flag + 4 }}} it's possible that you didn't intend a typed hole; you just mis-typed `_flag`. So I propose to add hint to the error message saying that {{{ Found hole ?_flag? with type: t Where: ...blah blah... Or perhaps ?_flag? is mis-spelled, or not in scope Relevant bindings include it :: t (bound at :9:1) }}} The third line is the new one. See [https://www.haskell.org/pipermail/glasgow-haskell- users/2015-January/025599.html this email trail]. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 14:00:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 14:00:47 -0000 Subject: [GHC] #10039: Make Const (Control.Applicative) kind polymorphic in its second argument In-Reply-To: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> References: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> Message-ID: <066.293339650dd165ff71616b23fe6c3780@haskell.org> #10039: Make Const (Control.Applicative) kind polymorphic in its second argument -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 Iceland_jack): Another example of a kind polymorphic `Const` is in the paper [[http://www .andres-loeh.de/TrueSumsOfProducts/TrueSumsOfProducts.pdf|True Sums of Products]] by Edsko de Vries and Andres L?h, defined in section '''2. Preliminaries''': {{{#!hs newtype I (a :: *) = I { unI :: a } newtype K (a :: *) (b :: k) = K { unK :: a } }}} noting: These are similar to their definitions in the standard libraries (called `Identity` and `Constant`, respectively), but the definition of `K` makes use of GHC's `PolyKinds` extension and is ''kind polymorphic''; we will need this generality. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 14:11:57 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 14:11:57 -0000 Subject: [GHC] #10039: Make Const (Control.Applicative) kind polymorphic in its second argument In-Reply-To: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> References: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> Message-ID: <066.161f5343617cc78cd3953d4390ab9f27@haskell.org> #10039: Make Const (Control.Applicative) kind polymorphic in its second argument -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 Iceland_jack: Old description: > Is there any reason why `Const` isn't kind polymorphic? > > {{{#!hs > newtype Const a (b :: k) = Const { getConst :: a } > deriving (Generic, Generic1) > }}} > > An example where I need it is for > [[http://wiki.ocharles.org.uk/Name%20Binding%20in%20EDSLs|interpreting > typed PHOAS]], the following fails to compile complaining that `The first > argument of ?PTerm? should have kind ?Ty -> *?, but ?Const Char? has kind > ?* -> *?`: > > {{{#!hs > {-# LANGUAGE DataKinds, KindSignatures, GADTs, RankNTypes, PolyKinds #-} > > import Control.Applicative > > data Ty = TyBool | TyArr Ty Ty > > data PTerm :: (Ty -> *) -> Ty -> * where > Var :: v t -> PTerm v t > Tru :: PTerm v 'TyBool > Fals :: PTerm v 'TyBool > App :: PTerm v ('TyArr t1 t2) -> PTerm v t1 -> PTerm v t2 > Abs :: (v t1 -> PTerm v t2) -> PTerm v ('TyArr t1 t2) > > newtype Term t = Term (forall v. PTerm v t) > > showT :: Term t -> String > showT (Term pterm) = show' 'a' pterm > where > show' :: Char -> PTerm (Const Char) t -> String > show' _ (Var (Const c)) = [c] > show' _ Tru = "True" > show' _ Fals = "False" > show' s (App x y) = "(" ++ show' s x ++ ") " ++ show' s y > show' s (Abs f) = [s] ++ ". " ++ show' (succ s) (f (Const s)) > }}} > > but it compiles if one defines a bespoke form of `Const` with kind `* -> > Ty -> *` (or the more general suggestion at the beginning of the ticket), > I implemented all the related instances from `Control.Applicative` and > the compiled without a hitch. Relevant discussion: a > [[http://stackoverflow.com/questions/2023052/haskell-specifying-kind-in- > data-declaration|question on StackOverflow]] that predates the > `PolyKinds` extension effectively wants to define `type Const' (a :: * -> > *) = Const Integer a` which would be possible if it were kind > polymorphic. New description: Is there any reason why `Const` isn't kind polymorphic? {{{#!hs newtype Const a (b :: k) = Const { getConst :: a } deriving (Generic, Generic1) }}} An example where I need it is for [[http://wiki.ocharles.org.uk/Name%20Binding%20in%20EDSLs|interpreting typed PHOAS]], the following fails to compile complaining that `The first argument of ?PTerm? should have kind ?Ty -> *?, but ?Const Char? has kind ?* -> *?`: {{{#!hs {-# LANGUAGE DataKinds, KindSignatures, GADTs, RankNTypes, PolyKinds #-} import Control.Applicative data Ty = TyBool | TyArr Ty Ty data PTerm :: (Ty -> *) -> Ty -> * where Var :: v t -> PTerm v t Tru :: PTerm v 'TyBool Fals :: PTerm v 'TyBool App :: PTerm v ('TyArr t1 t2) -> PTerm v t1 -> PTerm v t2 Abs :: (v t1 -> PTerm v t2) -> PTerm v ('TyArr t1 t2) newtype Term t = Term (forall v. PTerm v t) showT :: Term t -> String showT (Term pterm) = show' 'a' pterm where show' :: Char -> PTerm (Const Char) t -> String show' _ (Var (Const c)) = [c] show' _ Tru = "True" show' _ Fals = "False" show' s (App x y) = "(" ++ show' s x ++ ") " ++ show' s y show' s (Abs f) = [s] ++ ". " ++ show' (succ s) (f (Const s)) }}} but it compiles if one defines a bespoke form of `Const` with kind `* -> Ty -> *` (or the more general suggestion at the beginning of the ticket), I implemented all the related instances from `Control.Applicative` and it compiled without a hitch. Relevant discussion: a [[http://stackoverflow.com/questions/2023052/haskell-specifying-kind-in- data-declaration|question on StackOverflow]] that predates the `PolyKinds` extension effectively wants to define `type Const' (a :: * -> *) = Const Integer a` which would be possible if it were kind polymorphic. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 14:15:47 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 14:15:47 -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.88f63e8f2a88a0f3e281e08824ca94d0@haskell.org> #10021: Add "Error:" prefix for compile-time error messages -------------------------------------+------------------------------------- Reporter: k-bx | Owner: 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: -------------------------------------+------------------------------------- Changes (by spl): * cc: sean.leather@? (added) Old description: > The proposal is to modify GHC compile-time output for error-messages, by > adding a prefix, similar to what we currently have for warnings. > > An example of a warning message (see `Warning:` prefix): > > {{{ > ? cat test.hs > main = putStrLn "Hello!" > ? ghc --make -fforce-recomp -Wall ./test.hs > [1 of 1] Compiling Main ( test.hs, test.o ) > > test.hs:1:1: Warning: > Top-level binding with no type signature: main :: IO () > Linking test ... > }}} > > An example of current output for an error: > > {{{ > ? cat test2.hs > main = foo > ? ghc --make -fforce-recomp -Wall ./test2.hs > [1 of 1] Compiling Main ( test2.hs, test2.o ) > > test2.hs:1:8: Not in scope: ?foo? > }}} > > The proposal is to change it to become: > > {{{ > ? cat test2.hs > main = foo > ? ghc --make -fforce-recomp -Wall ./test2.hs > [1 of 1] Compiling Main ( test2.hs, test2.o ) > > test2.hs:1:8: Error: Not in scope: ?foo? > }}} > > This proposal only affects error messages produced by GHC itself. For > example, the behaviour of the `error` function is unaffected. > > == Motivation == > > Main motivation point right now is that there's a ticket #9219 (parallel > build's output of errors doesn't occur at the end of output), due to > which, error-reporting of your program might get lost somewhere in the > middle of a build-log. As another example, if your program has a lot of > warnings, and you build it with multiple cores, you almost always get an > error lost somewhere in the middle of warnings and it's almost impossible > to find. > > So, this feature's main purpose is to ease navigation in textual output > of ghc in order to find errors quickly, not being tied to output > ordering. > > == Disadvantages == > > Many regression tests might need a fix. > > == Additional consideration == > > @hvr proposed that during work on this bug we could make GHC output more > consistent with other compiler's (GCC and clang) by also lower-casing > "Error" and "Warning" prefixes. > > This might be potentially useful for existing tools that work on top of > compiler output for finding errors/warning, and GHC's output will become > "more valid" for them. New description: We propose adding the prefix `Error:` to compile-time error messages produced by GHC. An example of a warning message (see `Warning:` prefix): {{{ ? cat test.hs main = putStrLn "Hello!" ? ghc --make -fforce-recomp -Wall ./test.hs [1 of 1] Compiling Main ( test.hs, test.o ) test.hs:1:1: Warning: Top-level binding with no type signature: main :: IO () Linking test ... }}} An example of a current error message: {{{ ? cat test2.hs main = foo ? ghc --make -fforce-recomp -Wall ./test2.hs [1 of 1] Compiling Main ( test2.hs, test2.o ) test2.hs:1:8: Not in scope: ?foo? }}} The proposal is to change the error message to become: {{{ ? cat test2.hs main = foo ? ghc --make -fforce-recomp -Wall ./test2.hs [1 of 1] Compiling Main ( test2.hs, test2.o ) test2.hs:1:8: Error: Not in scope: ?foo? }}} This change affects only the error messages produced by GHC when compiling. It does not change runtime error reporting, e.g. with the `error` function. == Motivation == We wish to make compile-time error messages easier for humans and computers to identify. For example, when running a long parallel build, it can be easy to miss an error message (see #9219 for an example). With a known string such as `Error:`, we can use search functionality in a terminal window or text editor (when viewing the build log) or use a command-line tool such as `grep` (when streaming and filtering the build log) to quickly find errors. As a secondary motivation, adding `Error:` for error messages brings a nice symmetry to the current use of `Warning:` for warning messages. == Disadvantages == The output of many regression tests will need to be updated for the new error message format. == Additional consideration == @hvr proposed that during work on this bug we could make GHC output more consistent with other compiler's (GCC and clang) by also lower-casing "Error" and "Warning" prefixes. This might be potentially useful for existing tools that work on top of compiler output for finding errors/warning, and GHC's output will become "more valid" for them. -- Comment: I modified the ticket description in an attempt to be more clear about the proposal and to expand the motivation. P.S. I'm heavily in favor of this. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 14:19:03 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 14:19:03 -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.20f4de3b20cbd8101fe00ce35edade99@haskell.org> #10021: Add "Error:" prefix for compile-time error messages -------------------------------------+------------------------------------- Reporter: k-bx | Owner: 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: -------------------------------------+------------------------------------- Description changed by spl: Old description: > We propose adding the prefix `Error:` to compile-time error messages > produced by GHC. > > An example of a warning message (see `Warning:` prefix): > > {{{ > ? cat test.hs > main = putStrLn "Hello!" > ? ghc --make -fforce-recomp -Wall ./test.hs > [1 of 1] Compiling Main ( test.hs, test.o ) > > test.hs:1:1: Warning: > Top-level binding with no type signature: main :: IO () > Linking test ... > }}} > > An example of a current error message: > > {{{ > ? cat test2.hs > main = foo > ? ghc --make -fforce-recomp -Wall ./test2.hs > [1 of 1] Compiling Main ( test2.hs, test2.o ) > > test2.hs:1:8: Not in scope: ?foo? > }}} > > The proposal is to change the error message to become: > > {{{ > ? cat test2.hs > main = foo > ? ghc --make -fforce-recomp -Wall ./test2.hs > [1 of 1] Compiling Main ( test2.hs, test2.o ) > > test2.hs:1:8: Error: Not in scope: ?foo? > }}} > > This change affects only the error messages produced by GHC when > compiling. It does not change runtime error reporting, e.g. with the > `error` function. > > == Motivation == > > We wish to make compile-time error messages easier for humans and > computers to identify. For example, when running a long parallel build, > it can be easy to miss an error message (see #9219 for an example). With > a known string such as `Error:`, we can use search functionality in a > terminal window or text editor (when viewing the build log) or use a > command-line tool such as `grep` (when streaming and filtering the build > log) to quickly find errors. > > As a secondary motivation, adding `Error:` for error messages brings a > nice symmetry to the current use of `Warning:` for warning messages. > > == Disadvantages == > > The output of many regression tests will need to be updated for the new > error message format. > > == Additional consideration == > > @hvr proposed that during work on this bug we could make GHC output more > consistent with other compiler's (GCC and clang) by also lower-casing > "Error" and "Warning" prefixes. > > This might be potentially useful for existing tools that work on top of > compiler output for finding errors/warning, and GHC's output will become > "more valid" for them. New description: We propose adding the prefix `Error:` to compile-time error messages produced by GHC. An example of a warning message (see `Warning:` prefix): {{{ ? cat test.hs main = putStrLn "Hello!" ? ghc --make -fforce-recomp -Wall ./test.hs [1 of 1] Compiling Main ( test.hs, test.o ) test.hs:1:1: Warning: Top-level binding with no type signature: main :: IO () Linking test ... }}} An example of a current error message: {{{ ? cat test2.hs main = foo ? ghc --make -fforce-recomp -Wall ./test2.hs [1 of 1] Compiling Main ( test2.hs, test2.o ) test2.hs:1:8: Not in scope: ?foo? }}} The proposal is to change the error message to become: {{{ ? cat test2.hs main = foo ? ghc --make -fforce-recomp -Wall ./test2.hs [1 of 1] Compiling Main ( test2.hs, test2.o ) test2.hs:1:8: Error: Not in scope: ?foo? }}} This change affects only the error messages produced by GHC when compiling. It does not change runtime error reporting, e.g. with the `error` function. == Motivation == We wish to make compile-time error messages easier for humans and computers to identify. For example, when running a long parallel build, it can be easy to miss an error message (see #9219 for an example). With a known string such as `Error:`, we can use search functionality in a terminal window or text editor (when viewing the build log) or use a command-line tool such as `grep` (when streaming and filtering the build log) to quickly find errors. As a secondary motivation, adding `Error:` for error messages brings a nice symmetry to the current use of `Warning:` for warning messages. == Disadvantages == The output of many regression tests will need to be updated for the new error message format. == Additional consideration == @hvr [comment:5 suggested] that during work on this bug we could make GHC output more consistent with other compilers (GCC and clang) by using lowercase `error:` and `warning:` prefixes. This might be potentially useful for existing tools that work on top of compiler output for finding errors/warning, and GHC's output will become "more valid" for them. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 14:31:21 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 14:31:21 -0000 Subject: [GHC] #9122: Make Lint check for bad uses of `unsafeCoerce` In-Reply-To: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> References: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> Message-ID: <061.cf4951ade701617dc0d7b8a7a3b67a1d@haskell.org> #9122: Make Lint check for bad uses of `unsafeCoerce` -------------------------------------+------------------------------------- Reporter: simonpj | Owner: qnikst Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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:637 -------------------------------------+------------------------------------- Changes (by qnikst): * differential: => Phab:637 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 14:32:43 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 14:32:43 -0000 Subject: [GHC] #10040: Add hint on typed-hole error message In-Reply-To: <046.d6ed159d7a55e19a5744bc39409823df@haskell.org> References: <046.d6ed159d7a55e19a5744bc39409823df@haskell.org> Message-ID: <061.ec73b41f249458b9f479dcbc5dce00ea@haskell.org> #10040: Add hint on typed-hole error message -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: 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 Simon Peyton Jones ): In [changeset:"276da7929c187f007c198a38e88bdad91866e500/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="276da7929c187f007c198a38e88bdad91866e500" Improve error message on typed holes, and user manual (Tradc #10040) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 14:32:50 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 14:32:50 -0000 Subject: [GHC] #9122: Make Lint check for bad uses of `unsafeCoerce` In-Reply-To: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> References: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> Message-ID: <061.32c62402f180cd00e859bda1d9465184@haskell.org> #9122: Make Lint check for bad uses of `unsafeCoerce` -------------------------------------+------------------------------------- Reporter: simonpj | Owner: qnikst Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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:637 -------------------------------------+------------------------------------- Comment (by qnikst): Replying to [comment:9 simonpj]: > I don't know how to reason about what might be "an error at some particular stage of the pipeline". > > ANY use of `unsafeCoerce` might make a program seg-fault. So at best these checks are going to smoke out uses that are more than usually likely to cause this behaviour. It's all very squishy. Ask a more specific question and I'll try to help. > > S I think that Richard means that this check may be useful also in a typechecker, as lint will help from problems introduced by ghc, but doesn't prevent from incorrect programs to be written and accepted by typechecker. So idea was also perform this check in typechecker. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 14:33:44 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 14:33:44 -0000 Subject: [GHC] #9122: Make Lint check for bad uses of `unsafeCoerce` In-Reply-To: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> References: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> Message-ID: <061.aa0f0a79e997cb089591971ac20bb573@haskell.org> #9122: Make Lint check for bad uses of `unsafeCoerce` -------------------------------------+------------------------------------- Reporter: simonpj | Owner: qnikst Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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:D637 -------------------------------------+------------------------------------- Changes (by qnikst): * differential: Phab:637 => Phab:D637 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 14:35:42 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 14:35:42 -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.dcaff58d81660458af85f45092b39f52@haskell.org> #10021: Add "Error:" prefix for compile-time error messages -------------------------------------+------------------------------------- Reporter: k-bx | Owner: 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 k-bx): One more thing to consider. Current severities are: {{{ data Severity = SevOutput | SevDump | SevInteractive | SevInfo | SevWarning | SevError | SevFatal }}} For severity `SevFatal`, would it make sense to output `fatal: `, stick to `error: `, or just keep it as it is right now? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 14:40:51 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 14:40:51 -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.0eac9e6880ae77378f8667551a463573@haskell.org> #10021: Add "Error:" prefix for compile-time error messages -------------------------------------+------------------------------------- Reporter: k-bx | Owner: 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 simonpj): Yes, it's horrible that these seven (''seven''!) levels of severity are declared in a data type with no comment whatsoever to indicate what the author had in mind. One can guess from the names but it still seems like a huge omission. I have no opinion about `fatal` vs `error` for `SevFatal`. I'm inclined to the former, since it reflects the underlying truth. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 14:41:24 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 14:41:24 -0000 Subject: [GHC] #10040: Add hint on typed-hole error message In-Reply-To: <046.d6ed159d7a55e19a5744bc39409823df@haskell.org> References: <046.d6ed159d7a55e19a5744bc39409823df@haskell.org> Message-ID: <061.2b6f89e830f590a6f028cbe626406edc@haskell.org> #10040: Add hint on typed-hole error message -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: 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 simonpj): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 14:43:48 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 14:43: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.0478dfa56e824178445d1dd64f3e6a2e@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by simonpj): See also [wiki:Typeable#Kind-polymorphism the Typeable page] -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 15:28:49 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 15:28:49 -0000 Subject: [GHC] #10029: unit-tests: internal error: evacuate(static): strange closure type 62744 In-Reply-To: <050.3e189618a175273ea644d5072d51372c@haskell.org> References: <050.3e189618a175273ea644d5072d51372c@haskell.org> Message-ID: <065.e39e15d05f34c431ebe8f2763889c86b@haskell.org> #10029: unit-tests: internal error: evacuate(static): strange closure type 62744 ---------------------------------------+-------------------------------- Reporter: juhpetersen | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Linux | Architecture: arm Type of failure: Compile-time crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ---------------------------------------+-------------------------------- Comment (by juhpetersen): and network-conduit -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 15:30:31 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 15:30:31 -0000 Subject: [GHC] #10017: signal handlers are invoked multiple times when the threaded rts is used In-Reply-To: <045.98c8a4b2b498781adefd9fa189c04668@haskell.org> References: <045.98c8a4b2b498781adefd9fa189c04668@haskell.org> Message-ID: <060.08336fe652fbca9325f4c05831561df2@haskell.org> #10017: signal handlers are invoked multiple times when the threaded rts is used -------------------------------------+------------------------------------- Reporter: redneb | Owner: simonmar Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Runtime System | Version: 7.10.1-rc1 Resolution: | Keywords: Operating System: Linux | Architecture: Type of failure: Incorrect result | Unknown/Multiple at runtime | Test Case: Blocked By: | Blocking: Related Tickets: #9423 | Differential Revisions: -------------------------------------+------------------------------------- Comment (by AndreasVoellmy): I'm still getting up to speed, but it looks like that offending loop in `generic_handler` should just be removed. We have to signal to all the control pipes in `ioManagerDie()` (to solve the issue that led to that commit), but not in `generic_handler` (it seems). I'll look into it a bit more to check my understand and run some tests. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 15:38:16 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 15:38:16 -0000 Subject: =?utf-8?q?=5BGHC=5D_=2310041=3A_Instance_signatures_=28InstanceS?= =?utf-8?b?aWdzKSBkb24ndCBhY2NlcHQgJ1tdIDo6IFvEuF0=?= Message-ID: <051.17cdf568af8bd340be21eb52390309ae@haskell.org> #10041: Instance signatures (InstanceSigs) don't accept '[] :: [?] -------------------------------------+------------------------------------- Reporter: | Owner: Iceland_jack | Status: new Type: bug | Milestone: Priority: low | Version: 7.8.3 Component: Compiler | Operating System: Linux (Type checker) | Type of failure: GHC rejects Keywords: | valid program Architecture: x86 | Blocked By: Test Case: | Related Tickets: #9582 #9833 Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- The following doesn't compile with 7.8.3: {{{#!hs {-# LANGUAGE PolyKinds, TypeFamilies, DataKinds #-} {-# LANGUAGE TypeOperators, GADTs, InstanceSigs #-} data family Sing (a :: ?) data instance Sing (xs :: [k]) where SNil :: Sing '[] class SingI (a :: ?) where sing :: Sing a instance SingI '[] where sing :: Sing '[] sing = SNil }}} and the error message suggests the very type provided (`Sing '[]`): {{{#!hs /tmp/Error.hs:11:11: Method signature does not match class; it should be sing :: Sing '[] In the instance declaration for ?SingI '[]? Failed, modules loaded: none. }}} Creating a local variable with the same type signature works fine: {{{#!hs instance SingI '[] where sing = tmp where tmp :: Sing '[] tmp = SNil }}} This is '''not''' a problem for other data kinds such as `Bool` though: {{{#!hs data instance Sing (xs :: Bool) where STrue :: Sing True SFalse :: Sing False instance SingI True where sing :: Sing True sing = STrue instance SingI False where sing :: Sing False sing = SFalse }}} This resembles #9582 but I don't believe it is the same error, it has possibly been fixed i 7.10 but unfortunately I don't have a more recent version of GHC to check. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 15:40:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 15:40:15 -0000 Subject: [GHC] #9122: Make Lint check for bad uses of `unsafeCoerce` In-Reply-To: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> References: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> Message-ID: <061.97c160f789fc6528d79f8fa3e6a2884b@haskell.org> #9122: Make Lint check for bad uses of `unsafeCoerce` -------------------------------------+------------------------------------- Reporter: simonpj | Owner: qnikst Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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:D637 -------------------------------------+------------------------------------- Comment (by goldfire): Should the type-checker reject `unsafeCoerce# (3 :: Int) :: Int#`? If not, the proposed change would mean that `-dcore-lint` would show an error even when GHC is not at fault. Or, another (opposite) way to ask the question: Should a program containing that chunk, but compiled ''without'' `-dcore- lint`, be accepted? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 15:42:02 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 15:42:02 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2310041=3A_Instance_signatures_=28Ins?= =?utf-8?b?dGFuY2VTaWdzKSBkb24ndCBhY2NlcHQgJ1tdIDo6IFvEuF0=?= In-Reply-To: <051.17cdf568af8bd340be21eb52390309ae@haskell.org> References: <051.17cdf568af8bd340be21eb52390309ae@haskell.org> Message-ID: <066.ebf0ff213558b3649e24ae017e47d87b@haskell.org> #10041: Instance signatures (InstanceSigs) don't accept '[] :: [?] -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: | Architecture: x86 Operating System: Linux | Test Case: Type of failure: GHC rejects | Blocking: valid program | Differential Revisions: Blocked By: | Related Tickets: #9582 #9833 | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > The following doesn't compile with 7.8.3: > > {{{#!hs > {-# LANGUAGE PolyKinds, TypeFamilies, DataKinds #-} > {-# LANGUAGE TypeOperators, GADTs, InstanceSigs #-} > > data family Sing (a :: ?) > data instance Sing (xs :: [k]) where > SNil :: Sing '[] > > class SingI (a :: ?) where > sing :: Sing a > > instance SingI '[] where > sing :: Sing '[] > sing = SNil > }}} > > and the error message suggests the very type provided (`Sing '[]`): > > {{{#!hs > /tmp/Error.hs:11:11: > Method signature does not match class; it should be > sing :: Sing '[] > In the instance declaration for ?SingI '[]? > Failed, modules loaded: none. > }}} > > Creating a local variable with the same type signature works fine: > > {{{#!hs > instance SingI '[] where > sing = tmp where > tmp :: Sing '[] > tmp = SNil > }}} > > This is '''not''' a problem for other data kinds such as `Bool` though: > > {{{#!hs > data instance Sing (xs :: Bool) where > STrue :: Sing True > SFalse :: Sing False > > instance SingI True where > sing :: Sing True > sing = STrue > > instance SingI False where > sing :: Sing False > sing = SFalse > }}} > > This resembles #9582 but I don't believe it is the same error, it has > possibly been fixed i 7.10 but unfortunately I don't have a more recent > version of GHC to check. New description: The following doesn't compile with 7.8.3: {{{#!hs {-# LANGUAGE PolyKinds, TypeFamilies, DataKinds #-} {-# LANGUAGE TypeOperators, GADTs, InstanceSigs #-} data family Sing (a :: k) data instance Sing (xs :: [k]) where SNil :: Sing '[] class SingI (a :: ?) where sing :: Sing a instance SingI '[] where sing :: Sing '[] sing = SNil }}} and the error message suggests the very type provided (`Sing '[]`): {{{#!hs /tmp/Error.hs:11:11: Method signature does not match class; it should be sing :: Sing '[] In the instance declaration for ?SingI '[]? Failed, modules loaded: none. }}} Creating a local variable with the same type signature works fine: {{{#!hs instance SingI '[] where sing = tmp where tmp :: Sing '[] tmp = SNil }}} This is '''not''' a problem for other data kinds such as `Bool` though: {{{#!hs data instance Sing (xs :: Bool) where STrue :: Sing True SFalse :: Sing False instance SingI True where sing :: Sing True sing = STrue instance SingI False where sing :: Sing False sing = SFalse }}} This resembles #9582 but I don't believe it is the same error, it has possibly been fixed i 7.10 but unfortunately I don't have a more recent version of GHC to check. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 15:44:26 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 15:44:26 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2310041=3A_Instance_signatures_=28Ins?= =?utf-8?b?dGFuY2VTaWdzKSBkb24ndCBhY2NlcHQgJ1tdIDo6IFvEuF0=?= In-Reply-To: <051.17cdf568af8bd340be21eb52390309ae@haskell.org> References: <051.17cdf568af8bd340be21eb52390309ae@haskell.org> Message-ID: <066.7d9232a3e860c85451a33940ef9f4dd9@haskell.org> #10041: Instance signatures (InstanceSigs) don't accept '[] :: [?] -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: | Architecture: x86 Operating System: Linux | Test Case: Type of failure: GHC rejects | Blocking: valid program | Differential Revisions: Blocked By: | Related Tickets: #9582 #9833 | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > The following doesn't compile with 7.8.3: > > {{{#!hs > {-# LANGUAGE PolyKinds, TypeFamilies, DataKinds #-} > {-# LANGUAGE TypeOperators, GADTs, InstanceSigs #-} > > data family Sing (a :: k) > data instance Sing (xs :: [k]) where > SNil :: Sing '[] > > class SingI (a :: ?) where > sing :: Sing a > > instance SingI '[] where > sing :: Sing '[] > sing = SNil > }}} > > and the error message suggests the very type provided (`Sing '[]`): > > {{{#!hs > /tmp/Error.hs:11:11: > Method signature does not match class; it should be > sing :: Sing '[] > In the instance declaration for ?SingI '[]? > Failed, modules loaded: none. > }}} > > Creating a local variable with the same type signature works fine: > > {{{#!hs > instance SingI '[] where > sing = tmp where > tmp :: Sing '[] > tmp = SNil > }}} > > This is '''not''' a problem for other data kinds such as `Bool` though: > > {{{#!hs > data instance Sing (xs :: Bool) where > STrue :: Sing True > SFalse :: Sing False > > instance SingI True where > sing :: Sing True > sing = STrue > > instance SingI False where > sing :: Sing False > sing = SFalse > }}} > > This resembles #9582 but I don't believe it is the same error, it has > possibly been fixed i 7.10 but unfortunately I don't have a more recent > version of GHC to check. New description: The following doesn't compile with 7.8.3: {{{#!hs {-# LANGUAGE PolyKinds, TypeFamilies, DataKinds #-} {-# LANGUAGE TypeOperators, GADTs, InstanceSigs #-} data family Sing (a :: k) data instance Sing (xs :: [k]) where SNil :: Sing '[] class SingI (a :: ?) where sing :: Sing a instance SingI '[] where sing :: Sing '[] sing = SNil }}} and the error message suggests the very type provided (`Sing '[]`): {{{#!hs /tmp/Error.hs:11:11: Method signature does not match class; it should be sing :: Sing '[] In the instance declaration for ?SingI '[]? Failed, modules loaded: none. }}} Creating a local variable with the same type signature works fine: {{{#!hs instance SingI '[] where sing = tmp where tmp :: Sing '[] tmp = SNil }}} This is '''not''' a problem for other data kinds such as `Bool` though: {{{#!hs data instance Sing (xs :: Bool) where STrue :: Sing True SFalse :: Sing False instance SingI True where sing :: Sing True sing = STrue instance SingI False where sing :: Sing False sing = SFalse }}} This resembles #9582 but I don't believe it is the same error, it has possibly been fixed i 7.10 but unfortunately I don't have a more recent version of GHC to check. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 15:47:34 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 15:47:34 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2310041=3A_Instance_signatures_=28Ins?= =?utf-8?b?dGFuY2VTaWdzKSBkb24ndCBhY2NlcHQgJ1tdIDo6IFvEuF0=?= In-Reply-To: <051.17cdf568af8bd340be21eb52390309ae@haskell.org> References: <051.17cdf568af8bd340be21eb52390309ae@haskell.org> Message-ID: <066.c78da57fe3d19566d5811256f224fadd@haskell.org> #10041: Instance signatures (InstanceSigs) don't accept '[] :: [?] -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: | Architecture: x86 Operating System: Linux | Test Case: Type of failure: GHC rejects | Blocking: valid program | Differential Revisions: Blocked By: | Related Tickets: #9582 #9833 | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > The following doesn't compile with 7.8.3: > > {{{#!hs > {-# LANGUAGE PolyKinds, TypeFamilies, DataKinds #-} > {-# LANGUAGE TypeOperators, GADTs, InstanceSigs #-} > > data family Sing (a :: k) > data instance Sing (xs :: [k]) where > SNil :: Sing '[] > > class SingI (a :: ?) where > sing :: Sing a > > instance SingI '[] where > sing :: Sing '[] > sing = SNil > }}} > > and the error message suggests the very type provided (`Sing '[]`): > > {{{#!hs > /tmp/Error.hs:11:11: > Method signature does not match class; it should be > sing :: Sing '[] > In the instance declaration for ?SingI '[]? > Failed, modules loaded: none. > }}} > > Creating a local variable with the same type signature works fine: > > {{{#!hs > instance SingI '[] where > sing = tmp where > tmp :: Sing '[] > tmp = SNil > }}} > > This is '''not''' a problem for other data kinds such as `Bool` though: > > {{{#!hs > data instance Sing (xs :: Bool) where > STrue :: Sing True > SFalse :: Sing False > > instance SingI True where > sing :: Sing True > sing = STrue > > instance SingI False where > sing :: Sing False > sing = SFalse > }}} > > This resembles #9582 but I don't believe it is the same error, it has > possibly been fixed i 7.10 but unfortunately I don't have a more recent > version of GHC to check. New description: The following doesn't compile with 7.8.3: {{{#!hs {-# LANGUAGE PolyKinds, TypeFamilies, DataKinds #-} {-# LANGUAGE TypeOperators, GADTs, InstanceSigs #-} data family Sing (a :: k) data instance Sing (xs :: [k]) where SNil :: Sing '[] class SingI (a :: ?) where sing :: Sing a instance SingI '[] where sing :: Sing '[] sing = SNil }}} and the error message suggests the very type provided (`Sing '[]`): {{{#!hs /tmp/Error.hs:11:11: Method signature does not match class; it should be sing :: Sing '[] In the instance declaration for ?SingI '[]? Failed, modules loaded: none. }}} Creating a local variable with the same type signature works fine: {{{#!hs instance SingI '[] where sing = tmp where tmp :: Sing '[] tmp = SNil }}} This does '''not''' appear to be a problem for other data kinds such as `'True :: Bool` or `'False :: Bool` though: {{{#!hs data instance Sing (xs :: Bool) where STrue :: Sing True SFalse :: Sing False instance SingI True where sing :: Sing True sing = STrue instance SingI False where sing :: Sing False sing = SFalse }}} This resembles #9582 but I don't believe it is the same error, it has possibly been fixed in 7.10 but unfortunately I don't have a more recent version of GHC to check. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 15:50:38 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 15:50:38 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2310041=3A_Instance_signatures_=28Ins?= =?utf-8?b?dGFuY2VTaWdzKSBkb24ndCBhY2NlcHQgJ1tdIDo6IFvEuF0=?= In-Reply-To: <051.17cdf568af8bd340be21eb52390309ae@haskell.org> References: <051.17cdf568af8bd340be21eb52390309ae@haskell.org> Message-ID: <066.1bfa29a012b8eaa2bb6c9043e2898f62@haskell.org> #10041: Instance signatures (InstanceSigs) don't accept '[] :: [?] -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: | Architecture: x86 Operating System: Linux | Test Case: Type of failure: GHC rejects | Blocking: valid program | Differential Revisions: Blocked By: | Related Tickets: #9582 #9833 | -------------------------------------+------------------------------------- Description changed by Iceland_jack: Old description: > The following doesn't compile with 7.8.3: > > {{{#!hs > {-# LANGUAGE PolyKinds, TypeFamilies, DataKinds #-} > {-# LANGUAGE TypeOperators, GADTs, InstanceSigs #-} > > data family Sing (a :: k) > data instance Sing (xs :: [k]) where > SNil :: Sing '[] > > class SingI (a :: ?) where > sing :: Sing a > > instance SingI '[] where > sing :: Sing '[] > sing = SNil > }}} > > and the error message suggests the very type provided (`Sing '[]`): > > {{{#!hs > /tmp/Error.hs:11:11: > Method signature does not match class; it should be > sing :: Sing '[] > In the instance declaration for ?SingI '[]? > Failed, modules loaded: none. > }}} > > Creating a local variable with the same type signature works fine: > > {{{#!hs > instance SingI '[] where > sing = tmp where > tmp :: Sing '[] > tmp = SNil > }}} > > This does '''not''' appear to be a problem for other data kinds such as > `'True :: Bool` or `'False :: Bool` though: > > {{{#!hs > data instance Sing (xs :: Bool) where > STrue :: Sing True > SFalse :: Sing False > > instance SingI True where > sing :: Sing True > sing = STrue > > instance SingI False where > sing :: Sing False > sing = SFalse > }}} > > This resembles #9582 but I don't believe it is the same error, it has > possibly been fixed in 7.10 but unfortunately I don't have a more recent > version of GHC to check. New description: The following doesn't compile with 7.8.3: {{{#!hs {-# LANGUAGE PolyKinds, TypeFamilies, DataKinds #-} {-# LANGUAGE TypeOperators, GADTs, InstanceSigs #-} data family Sing (a :: k) data instance Sing (xs :: [k]) where SNil :: Sing '[] class SingI (a :: ?) where sing :: Sing a instance SingI '[] where sing :: Sing '[] sing = SNil }}} and the error message suggests the very type provided (`Sing '[]`): {{{#!hs /tmp/Error.hs:11:11: Method signature does not match class; it should be sing :: Sing '[] In the instance declaration for ?SingI '[]? Failed, modules loaded: none. }}} Creating a local variable with the same type signature works fine: {{{#!hs instance SingI '[] where sing = tmp where tmp :: Sing '[] tmp = SNil }}} This does '''not''' appear to be a problem for other types of kind `Bool` such as `'True` or `'False` though: {{{#!hs data instance Sing (xs :: Bool) where STrue :: Sing True SFalse :: Sing False instance SingI True where sing :: Sing True sing = STrue instance SingI False where sing :: Sing False sing = SFalse }}} This resembles #9582 but I don't believe it is the same error, it has possibly been fixed in 7.10 but unfortunately I don't have a more recent version of GHC to check. -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 16:04:41 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 16:04:41 -0000 Subject: =?utf-8?q?Re=3A_=5BGHC=5D_=2310041=3A_Instance_signatures_=28Ins?= =?utf-8?b?dGFuY2VTaWdzKSBkb24ndCBhY2NlcHQgJ1tdIDo6IFvEuF0=?= In-Reply-To: <051.17cdf568af8bd340be21eb52390309ae@haskell.org> References: <051.17cdf568af8bd340be21eb52390309ae@haskell.org> Message-ID: <066.e11eb0afbfb7ee5da0fbafde8d56887f@haskell.org> #10041: Instance signatures (InstanceSigs) don't accept '[] :: [?] -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Keywords: Resolution: | Architecture: x86 Operating System: Linux | Test Case: Type of failure: GHC rejects | Blocking: valid program | Differential Revisions: Blocked By: | Related Tickets: #9582 #9833 | -------------------------------------+------------------------------------- Comment (by goldfire): Ick. The problem boils down to the fact that type signatures are meant to be self-standing -- that is, a type signature is understood in a vacuum, without looking around. Let's look here: {{{ instance SingI '[] where sing :: Sing '[] sing = SNil }}} I'll rewrite with all kind variables made explicit. (By the way, you'll get more sensible error messages with `-fprint-explicit-kinds`.) {{{ instance SingI k1 ('[] k1) where sing :: forall k2. Sing k2 ('[] k2) sing k2(?) = SNil k2 }}} We can see here why the instance signature is rejected. When GHC sees a signature `Sing '[]`, it chooses a fresh kind variable, doesn't find anything constraining that kind variable, and thus generalizes over it. But that's not what you want! You want `k1`. GHC doesn't know this. Let's look at your working example, again with explicit kinds: {{{ instance SingI k1 ('[] k1) where sing k1 = tmp k1 where -- NB: it *must* be k1 tmp :: forall k2. Sing k2 ('[] k2) tmp k2 = SNil k2 }}} Here, we have no problem, because GHC generalizes `tmp` and then instantiates it at the right kind. It has no such flexibility with a direct signature. So the fix, I believe, would be to match the instance signature ''before'' it is generalized. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 16:48:08 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 16:48:08 -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.7e0b63f797c8851d3e60fffba6190e6c@haskell.org> #10021: Add "Error:" prefix for compile-time error messages -------------------------------------+------------------------------------- Reporter: k-bx | Owner: 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 spl): Having not looked at the code, I'm not even sure how output, dump, and interactive (to say the least) are cases of severity. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 17:17:45 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 17:17: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.1072b964cfc51a464b9f9b0b78cbc71d@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:30 simonpj]: > * And the kinds would have to be included in the fingerprint of the `TyCon` generated by the standalone derived instance. Once you have the mechanism for getting a kind representation to put in the fingerprint, how much harder is it to just make it work polymorphically while you're at it? I'm not a GHC developer by any means, but I still had the hunch that this could be a main stumbling block to getting the proper solution working. > The "right" solution is, I think, at the bottom of comment:20. But NB that solution will mean that all these standalone derived instances would become illegal, so there is a backward compatibility cost. The drastic solution does not have this problem. If *all* types later become `Typeable` automatically, then wouldn't it be safe and backward compatible to just ignore the explicit instances with a redundancy warning? (I've occasionally been thinking that multiple derived instances for the same type and class should often be safely compatible with each other. If made by the same mechanism, they're guaranteed to have the same code, after all. Although I guess standalone deriving with explicit restricted type signature could complicate that.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 17:52:46 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 17:52:46 -0000 Subject: [GHC] #10039: Make Const (Control.Applicative) kind polymorphic in its second argument In-Reply-To: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> References: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> Message-ID: <066.091bebf25c27a04791ada27f8c8ad19d@haskell.org> #10039: Make Const (Control.Applicative) kind polymorphic in its second argument -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 ekmett): I, for one, would support this. We already have packages out there that have to define their own kind- polymorphic `Const`, e.g. `vinyl`. http://hackage.haskell.org/package/vinyl-0.5.1/docs/Data-Vinyl- Functor.html#t:Const -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 18:47:17 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 18:47:17 -0000 Subject: [GHC] #10031: coerce can cause compiler to loop In-Reply-To: <044.15e9c8486a47b37508189b87e9fa66ab@haskell.org> References: <044.15e9c8486a47b37508189b87e9fa66ab@haskell.org> Message-ID: <059.e29dcb00ee35c65747b2440ca2d29798@haskell.org> #10031: coerce can cause compiler to loop -------------------------------------+------------------------------------- Reporter: glguy | Owner: goldfire Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.10.1-rc1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: x86_64 Type of failure: Compile-time | (amd64) crash | Test Case: Blocked By: | typecheck/should_compile/T10031 Related Tickets: | Blocking: | Differential Revisions: Phab:D630 -------------------------------------+------------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged to `ghc-7.10` (via 2387369c498f631bd3f4be2d6efe71773353acc5). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 18:48:04 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 18:48:04 -0000 Subject: [GHC] #9935: Can't compile rts/StgCRun.c for aarch64-linux In-Reply-To: <044.200c17fd365ff41cdf84e3ad7b9ecbc2@haskell.org> References: <044.200c17fd365ff41cdf84e3ad7b9ecbc2@haskell.org> Message-ID: <059.97bd21469db80e0553e9abf6a8c0f990@haskell.org> #9935: Can't compile rts/StgCRun.c for aarch64-linux ----------------------------------------+---------------------------------- Reporter: erikd | Owner: erikd Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Compiler | Version: 7.11 Resolution: fixed | Keywords: Operating System: Linux | Architecture: aarch64 Type of failure: Building GHC failed | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: D599 ----------------------------------------+---------------------------------- Changes (by thoughtpolice): * status: merge => closed * resolution: => fixed * milestone: => 7.10.1 Comment: Merged to `ghc-7.10` (via 5f2af6646067a6a66afa450c42482b5723172593). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 18:56:15 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 18:56:15 -0000 Subject: [GHC] #10038: Missing information about some libraries in the GHC 7.10.1 RC2 release notes In-Reply-To: <042.2351aa32b11f999d614978d597e46a77@haskell.org> References: <042.2351aa32b11f999d614978d597e46a77@haskell.org> Message-ID: <057.bd70576df55a1afd937c6af7d15ae7a3@haskell.org> #10038: Missing information about some libraries in the GHC 7.10.1 RC2 release notes -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Documentation | 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 thoughtpolice): Ah, these simply aren't mentioned in the release notes like the other libraries. I suppose it would be good form to list them since we export them publicly now (re #8919). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 18:58:25 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 18:58:25 -0000 Subject: [GHC] #9928: Wrong information about the previous version of the time library in GHC 7.10.1 RC2 release notes In-Reply-To: <042.da80f41221c9fccf24e54a1fbfd2424e@haskell.org> References: <042.da80f41221c9fccf24e54a1fbfd2424e@haskell.org> Message-ID: <057.c8fa0c6fd6ae0b8cceda4ef177d99da8@haskell.org> #9928: Wrong information about the previous version of the time library in GHC 7.10.1 RC2 release notes -------------------------------------+------------------------------------- Reporter: asr | Owner: Type: bug | Status: closed Priority: normal | Milestone: 7.10.1 Component: Documentation | Version: 7.10.1-rc2 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: new => closed * resolution: => fixed Comment: Fixed via e25e78f6731248873f7aa899e6f3d69c1078727d. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 19:39:59 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 19:39:59 -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.8610894400f865156454e78010b174f7@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by oerjan): I see in the wiki page that the idea of putting kind arguments in TypeReps is hitting severe type system problems. I had another idea, which I didn't bother to bring up before since [comment:19 goldfire]'s idea looked much prettier. And now that I tried actually writing up a proof of concept, it looks even more monstrous :/ But anyway, here it is, sort of working, but with some obvious drawbacks: {{{ {-# LANGUAGE PolyKinds #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE ScopedTypeVariables #-} import Data.Proxy newtype TTypeRep a = TT String deriving Show newtype KKindRep a = KK String deriving Show class Kindable' (a :: k -> *) where kindRep :: KKindRep a class Kindable' (Proxy :: k -> *) => Typeable' (a :: k) where typeRep :: TTypeRep a instance Kindable' (Proxy :: * -> *) where kindRep = KK "*" instance (Kindable' (Proxy :: k1 -> *), Kindable' (Proxy :: k2 -> *)) => Kindable' (Proxy :: (k1 -> k2) -> *) where kindRep = KK $ '(' : k1 ++ " -> " ++ k2 ++ ")" where KK k1 = kindRep :: KKindRep (Proxy :: k1 -> *) KK k2 = kindRep :: KKindRep (Proxy :: k2 -> *) instance Kindable' (Proxy :: k -> *) => Typeable' (Proxy :: k -> *) where typeRep = TT $ "Proxy :: " ++ k where KK k = kindRep :: KKindRep (Proxy :: (k -> *) -> *) main = do print (kindRep :: KKindRep (Proxy :: (* -> * -> *) -> *)) print (typeRep :: TTypeRep (Proxy :: (* -> * -> *) -> *)) print (kindRep :: KKindRep (Proxy :: ((* -> *) -> *) -> *)) print (typeRep :: TTypeRep (Proxy :: ((* -> *) -> *) -> *)) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Wed Jan 28 21:37:05 2015 From: ghc-devs at haskell.org (GHC) Date: Wed, 28 Jan 2015 21:37: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.779367b995b6bcb957929e10bf6421c9@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by int-e): Replying to [comment:33 oerjan]: > But anyway, here it is, sort of working, but with some obvious drawbacks: One such drawback is that the `Kindable'` constraint is sort of infectious. One can using a type family for mapping kinds to types, which seems to overcome that particular shortcoming: {{{ type family KindRep (p :: k) data Star deriving Typeable type instance KindRep (Proxy :: * -> *) = Star type instance KindRep (Proxy :: (k -> k') -> *) = KindRep (Proxy :: k -> *) -> KindRep (Proxy :: k' -> *) -- some data kinds: () and [] type instance KindRep (Proxy :: () -> *) = () type instance KindRep (Proxy :: [k] -> *) = [KindRep (Proxy :: k -> *)] }}} One could then have {{{ instance Typeable (KindRep (Proxy :: k -> *)) => Typeable' (Proxy :: k -> *) }}} Here's some working code: http://lpaste.net/4263409010180358144 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 29 02:04:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Jan 2015 02:04:03 -0000 Subject: [GHC] #10042: progain 350 overview Message-ID: <045.b0862b822fe78fd7955edf624b09584f@haskell.org> #10042: progain 350 overview -------------------------------------+------------------------------------- Reporter: Holten | Owner: Type: bug | Status: new Priority: lowest | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- More power with the help of Progain 350 and [http://progain350-uk.com/progain-350-testinate-250/ Testinate 250] Do you belong also to the people who like to run quickly build muscle and burn calories at the same time want? Then do the Progain 350 experience when you did your workout sometimes insufficient condition, which prepares you to create your goal difficulty? No matter what you have learned so far about muscle building products, Progain 350 and Testinate 250 offer excellent help in training. Now there are no more excuses. Do you want to buy Progain 350? Additional or on the [http://progain350-uk.com/progain-350-testinate-250-ingredients-effect/ Progain 350 ingredients effect] experienced then read on. Progain 350 ingredients and the effect we have recorded in a detailed self-test. That intensive training needs to effectively build muscle, which is obvious to all of us. But the result is always the question why people still keep up with a similar physique in training highly varying lengths of time. Would you also like to effectively build muscle as others? Use Progain 350, so that a real rock is from you. Experience muscles of steel and a sexy body shape. To draw the attention of all girls guaranteed to be! Go from increased by 52% from structure to muscles. The compiled by the developers formulation is based on the effect of nitric oxide. During exercise, the body must be available enough. With Progain 350 you can do just that. The constituents nitrogen oxides are made available which make it conceivable to train and extremely easy to manage your fixed workouts. Fast fatigue and performance lows thing of the past. Start by same. Become quickly limp when running training? Have you set appropriate workouts, but they can still barely cope? Then you should use Progain 350 and feel like you can work out with a much longer time. With up to 41 percent more performance you can make a persistent and successful training and felt easier to reach your goal. Forget the training days when you did not want or condition. Win with 350 Progain now the necessary fighting spirit. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 29 06:21:08 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Jan 2015 06:21:08 -0000 Subject: [GHC] #2615: ghci doesn't play nice with linker scripts In-Reply-To: <051.bfa2cefd2ab537021a429fbc1fccdb5e@haskell.org> References: <051.bfa2cefd2ab537021a429fbc1fccdb5e@haskell.org> Message-ID: <066.4d011a6dc429c1fe142cec3bed3791d2@haskell.org> #2615: ghci doesn't play nice with linker scripts -------------------------------------+------------------------------------- Reporter: AlecBerryman | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.3 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: dlopen, Operating System: Linux | dynamic linking Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by Jinhui_Chen): * cc: hvr (added) * owner: hgolden => * status: closed => new * resolution: fixed => Comment: I recently encounter a problem which I think is related to this bug. This is illustrated by this Haskell program: {{{ import ObjLink import Foreign import Foreign.C.Types import Foreign.C.String foreign import ccall "setlocale" c_setlocale :: CInt -> CString -> IO CString main = do withCString "zh_CN.UTF-8" $ \lc -> c_setlocale 5 lc r <- loadDLL "/usr/lib/libc.so" putStrLn (show r) }}} which outputs: {{{ Just "/usr/lib/libc.so: \26080\25928\30340 ELF \22836" }}} The "\26080\25928\30340 ELF \22836" part is "???ELF?" in Chinese. I suspect the problem is caused by addDLL function, which expects dlopen to return "invalid ELF header", and that is not true on non-C/non-en locales. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 29 08:32:29 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Jan 2015 08:32:29 -0000 Subject: [GHC] #4879: Deprecate exports In-Reply-To: <049.ea1fa273b308c2a35269907288b50645@haskell.org> References: <049.ea1fa273b308c2a35269907288b50645@haskell.org> Message-ID: <064.cc16d699dca92d8de6c9175d0b44309e@haskell.org> #4879: Deprecate exports -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.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 Comment: raising priority again due to its importance for future `base`-work see also http://thread.gmane.org/gmane.comp.lang.haskell.libraries/23874/focus=23956 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 29 12:38:37 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Jan 2015 12:38:37 -0000 Subject: [GHC] #4879: Deprecate exports In-Reply-To: <049.ea1fa273b308c2a35269907288b50645@haskell.org> References: <049.ea1fa273b308c2a35269907288b50645@haskell.org> Message-ID: <064.ab51e498518472bf4ddce25cd5d98a79@haskell.org> #4879: Deprecate exports -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.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:D638 -------------------------------------+------------------------------------- Changes (by hvr): * differential: => Phab:D638 Comment: forward-ported the patch to current HEAD and submitted to Phab: -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 29 13:02:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Jan 2015 13:02:39 -0000 Subject: [GHC] #4879: Deprecate exports In-Reply-To: <049.ea1fa273b308c2a35269907288b50645@haskell.org> References: <049.ea1fa273b308c2a35269907288b50645@haskell.org> Message-ID: <064.85b3443ca9ddcf435297dd313bf90135@haskell.org> #4879: Deprecate exports -------------------------------------+------------------------------------- Reporter: basvandijk | Owner: Type: feature request | Status: new Priority: high | Milestone: 7.12.1 Component: Compiler | Version: 7.0.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:D638 -------------------------------------+------------------------------------- Comment (by hvr): for the record, the patch still seems to work: {{{#!hs module M1 ({-# DEPRECATED sort "dont use me" #-}, sort) where import Data.List (sort) }}} {{{#!hs import M1 (sort) main :: IO () main = print (sort "asdasd") }}} {{{ $ ../inplace/bin/ghc-stage2 -Wall --make M2.hs [1 of 2] Compiling M1 ( M1.hs, M1.o ) [2 of 2] Compiling Main ( M2.hs, M2.o ) M2.hs:4:15: Warning: In the use of ?sort? (imported from M1, but defined in base-4.8.0.0:Data.OldList): Deprecated: "dont use me" Linking M2 ... }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 29 13:03:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Jan 2015 13:03:00 -0000 Subject: [GHC] #10043: runtime fails in threaded way on SPARC (bus error -> unaligned access to data) Message-ID: <046.71d97f17298f6703a7e75e75a742ac80@haskell.org> #10043: runtime fails in threaded way on SPARC (bus error -> unaligned access to data) -----------------------------------+---------------------------------- Reporter: kgardas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Solaris Architecture: sparc | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -----------------------------------+---------------------------------- Hello, it looks like runtime has changed between 7.8 and 7.10 in a way it no longer works well on SPARC. Tested on SPARC/Solaris 2.11. Both compilers compiled as their are w/o any changes so both unregisterised. On 7.8 testblockalloc runs well, on 7.10.1-rc2 it fails in threaded way with "Bus error" {{{ karel at niagara:~/src/ghc-7.10.0.20150123/testsuite/tests/rts$ ./testblockalloc +RTS -I0 Bus Error (core dumped) }}} When run in debugger it points to assignment of 0 to tso->alloc_limit: {{{ karel at niagara:~/src/ghc-7.10.0.20150123/testsuite/tests/rts$ gdb ./testblockalloc GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.11"... set ar(gdb) set args +RTS -I0 (gdb) r Starting program: /home/karel/src/ghc-7.10.0.20150123/testsuite/tests/rts/testblockalloc +RTS -I0 warning: Lowest section in /lib/librt.so.1 is .dynamic at 00000074 warning: Lowest section in /lib/libdl.so.1 is .dynamic at 00000074 warning: Lowest section in /lib/libpthread.so.1 is .dynamic at 00000074 Program received signal SIGSEGV, Segmentation fault. 0x006b62d4 in createThread (cap=0x821ec0, size=256) at rts/Threads.c:113 113 tso->alloc_limit = 0; (gdb) }}} usually bus error is generated by unaligned access to data. I'll have a look at it, but any idea is of course highly appreciated. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 29 13:11:03 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Jan 2015 13:11:03 -0000 Subject: [GHC] #10039: Make Const (Control.Applicative) kind polymorphic in its second argument In-Reply-To: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> References: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> Message-ID: <066.ab4c895985e6fc461729422cda0b11ae@haskell.org> #10039: Make Const (Control.Applicative) kind polymorphic in its second argument -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 Iceland_jack): I wonder if other data types would benefit from kind polymorphism -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 29 13:26:53 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Jan 2015 13:26:53 -0000 Subject: [GHC] #10039: Make Const (Control.Applicative) kind polymorphic in its second argument In-Reply-To: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> References: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> Message-ID: <066.a7900aac6be3d0ddc2ed95355beaf515@haskell.org> #10039: Make Const (Control.Applicative) kind polymorphic in its second argument -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 ekmett): To my knowledge all of the others that take a phantom argument (like `Proxy`, `Proxy#`, etc.) which can be already are kind polymorphic. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 29 13:33:43 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Jan 2015 13:33:43 -0000 Subject: [GHC] #10039: Make Const (Control.Applicative) kind polymorphic in its second argument In-Reply-To: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> References: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> Message-ID: <066.fb26097ce8db65eeded7d64a320da847@haskell.org> #10039: Make Const (Control.Applicative) kind polymorphic in its second argument -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 ekmett): This may change if we decided to bring more of the "non-transformers" that sit in `transformers` into `base`, e.g. `Product` and `Sum` for functors can generalize {{{ Product :: (k -> *) -> (k -> *) -> k -> * Sum :: (k -> *) -> (k -> *) -> k -> * }}} and the generalizations are quite useful. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 29 14:46:47 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Jan 2015 14:46:47 -0000 Subject: [GHC] #9851: Hoopl library in GHC hides runWithFuel / version number clash In-Reply-To: <053.a80518c51ae2062a4e162a281daf017f@haskell.org> References: <053.a80518c51ae2062a4e162a281daf017f@haskell.org> Message-ID: <068.a9c63c4e873c63986c575246fe8a8a30@haskell.org> #9851: Hoopl library in GHC hides runWithFuel / version number clash -------------------------------------+------------------------------------- Reporter: AndreasVoellmy | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries/hoopl | Version: 7.8.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Other | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #8315 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by armelm): I've just added a patch to apply to the Hoopl repository. It simply re- export ''runWithFuel''. '''Nota:''' I'm new to Haskell so I don't know (or understand) why ''runWithFuel'' isn't exported especially as it has already been re- exported once in the past as we can see in ''changelog.md'': {{{ ## 3.8.7.4 - Re-export runWithFuel as per Justin Bailey }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 29 14:54:54 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Jan 2015 14:54:54 -0000 Subject: [GHC] #10039: Make Const (Control.Applicative) kind polymorphic in its second argument In-Reply-To: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> References: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> Message-ID: <066.852e85bbc103806305eb3cadf2a54b72@haskell.org> #10039: Make Const (Control.Applicative) kind polymorphic in its second argument -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 Iceland_jack): That would be great, other types like `Data.Functor.Compose.Compose` and `Data.Functor.Reverse.Reverse` could also be generalised (Vinyl does this with [[http://hackage.haskell.org/package/vinyl-0.5.1/docs/Data-Vinyl- Functor.html#t:Compose|Compose]]): {{{#!hs newtype Compose (f :: j -> *) (g :: k -> j) (a :: k) = Compose { getCompose :: f (g a) } newtype Reverse (f :: k -> *) (a :: k) = Reverse { getReverse :: f a } }}} A more general `Compose` is definitely useful for composing dictionaries constraints (`Compose Dict Eq`, [[http://www.reddit.com/r/haskell/comments/2qwqf2/generate_list_of_dicts_from_type_level_list/|discussion]]), non-empty vectors: {{{#!hs data Exists :: (k -> *) -> * where Never :: p x -> Exists p more :: Compose (Vector Char) Suc (Suc Zero) more = Compose (Cons 'H' (Cons 'S' Nil)) type NonEmpty a = Exists (Compose (Vector a) Suc) oh :: NonEmpty Char oh = Never more }}} working with typed lists and such (I also ran into [[http://lpaste.net/edit/75980|this]]). It's not clear to me that a generalised `Reverse` would be worth it. I wonder if any of this will break code though. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 29 15:57:25 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Jan 2015 15:57:25 -0000 Subject: [GHC] #10039: Make Const (Control.Applicative) kind polymorphic in its second argument In-Reply-To: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> References: <051.e8daf73d81c353970f587c5857f9575b@haskell.org> Message-ID: <066.845d61e5f471abe976c36ce12f5fc24f@haskell.org> #10039: Make Const (Control.Applicative) kind polymorphic in its second argument -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: ekmett Type: feature request | Status: new Priority: normal | Milestone: Component: Core Libraries | 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 ekmett): Most of the Data.Functor.* suite is amenable to this treatment, yes. I've been programming with rather excessively generalized kinds on a large chunk of code for a couple of years now with surprisingly few problems. However, as we don't currently have those instances in `base` this is definitely a concern for future `base` efforts, not so much for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 29 16:46:07 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Jan 2015 16:46:07 -0000 Subject: [GHC] #2615: ghci doesn't play nice with linker scripts In-Reply-To: <051.bfa2cefd2ab537021a429fbc1fccdb5e@haskell.org> References: <051.bfa2cefd2ab537021a429fbc1fccdb5e@haskell.org> Message-ID: <066.35a168f8a475cf5a5d8844fd42a18ff8@haskell.org> #2615: ghci doesn't play nice with linker scripts -------------------------------------+------------------------------------- Reporter: AlecBerryman | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.3 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: dlopen, Operating System: Linux | dynamic linking Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hgolden): I suspect that the problem is caused by the error message being in a different language. I wonder if it is possible to add code to the patch to change the locale momentarily while in AddDLL and revert it before returning? If this can be done, then the error message would be in the language we are expecting and the result should be to look for the true shared library by scanning the linker script. Of course, this assumes that the linker script is still in English. (I don't know if this is the case.) If the linker script is in a different language, then the problem becomes much harder to solve without identifying the language and selecting the appropriate strings to use in the regular expressions. Jinhui, please attach the text of /usr/lib/libc.so on your test system so we can see what language it is in. Thanks. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 29 18:14:28 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Jan 2015 18:14: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.b09266e7bb1283bd30ba6144e7ae735b@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.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: -------------------------------------+------------------------------------- Changes (by lelf): * cc: lelf (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 29 19:02:48 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Jan 2015 19:02:48 -0000 Subject: [GHC] #10027: Importing constructor of associated data type fails In-Reply-To: <048.077c953371a360576ad660349e5d3261@haskell.org> References: <048.077c953371a360576ad660349e5d3261@haskell.org> Message-ID: <063.5de2df44fc073133197394905fa93667@haskell.org> #10027: Importing constructor of associated data type fails -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | constructor import associated data Type of failure: None/Unknown | type Blocked By: | Architecture: Related Tickets: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by lspitzner): The case without an export-list feels special-casy, but if i am not mistaken the problem is not restricted to it: It is impossible to explicitly export data constructors without exporting the data family as well: {{{#!hs module A where data family D a module B ( D ( DCon ) -- cannot not export D ) where import A data Foo = Foo data instance D Foo = DCon }}} To me, the core of the issue seems to be that "D(DCon)" refers to __both__ ''D'' and ''D.DCon''. Would it not make sense to weaken this? E.g. replace the relevant section in report2010:5.2 with: > * The form ''T'' names the type but not the constructors or field names. > * The form ''T(c1,?,cn)'', names the sum of: > a) the type, but only if it is declared locally, > b) the mentioned constructors or field names, which may be an empty list > * The abbreviated form ''T(..)'' names the same as ''T(c1,?,cn)'' where ''c1,?,cn'' is the full list of constructors/field names currently in scope (qualified or not) (i sneaked the "which may be an empty list" fix in; this seems to match what is implemented) This approach would next need to define how importing is handled, as "declared locally" does not make sense on import-side. I would propose to give it "grab all you can" semantics, i.e. > ''import B ( D ( DCon ) )'' imports ''DCon'', and ''D'' if it is exported by ''B''. Examples for the export: {{{#!hs module B ( D ( DCon ) -- only D.DCon ) module B ( D -- re-export the data family , D ( DCon ) -- D.DCon ) }}} With this, the no-export-list case becomes trivial. How high would the risk of this breaking existing code be? Are there other disadvantages? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 29 19:17:00 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Jan 2015 19:17:00 -0000 Subject: [GHC] #10044: Wrong line number reported with CPP and line beginning with # Message-ID: <047.a0bfc7b37bebfe567d7611d66867f0e2@haskell.org> #10044: Wrong line number reported with CPP and line beginning with # -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- If I compile {{{ {-# LANGUAGE CPP #-} module Bug where {- # hi there! -} * }}} I'm told of a parse error for the `*` on line 10. But that `*` is line 9! The problem is that, with `CPP` on, the line number counter gets confused if a line begins with a #, perhaps after whitespace. I actually hit this and was confused in real code. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 29 19:31:10 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Jan 2015 19:31:10 -0000 Subject: [GHC] #10044: Wrong line number reported with CPP and line beginning with # In-Reply-To: <047.a0bfc7b37bebfe567d7611d66867f0e2@haskell.org> References: <047.a0bfc7b37bebfe567d7611d66867f0e2@haskell.org> Message-ID: <062.d54335fd83ee4e0e4def53ccb32e16e5@haskell.org> #10044: Wrong line number reported with CPP and line beginning with # -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: low | 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 rwbarton): Looks like a bug in clang's C preprocessor (I get the expected behavior with gcc's): {{{ rwbarton at morphism:/tmp$ clang -E -x assembler-with-cpp Bug.hs # 1 "Bug.hs" # 1 "" 1 # 1 "Bug.hs" 2 {-# LANGUAGE CPP #-} module Bug where {- # hi there! -} * }}} Why did it add a blank line after `# hi there!`? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 29 20:11:24 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Jan 2015 20:11: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.398f42e0bf2d8d8c28a2af931697ed14@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.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: -------------------------------------+------------------------------------- Changes (by dfeuer): * cc: dfeuer (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 29 20:57:39 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Jan 2015 20:57:39 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.3dd72eff87a47d90da427614db9a97fd@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9621 | Blocking: | Differential Revisions: Phab:D209 -------------------------------------+------------------------------------- Comment (by George): The description at the top says "An in-depth design-document is in the works." Was that done? If so, is there a link to it? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 29 21:18:31 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Jan 2015 21:18:31 -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.1c9177fe6531313f43c6e5d4997c7fb5@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by ekmett): As a data point, disabling Typeable for polykinded code would actually break production code for me in a ways I don't see how to fix. Code out there just switched from manual deriving of these instances pre 7.8 for a few particular cases, to the derived ones for 7.8+, but if you take away the derived instances and don't let folks write them by hand that case falls into a gap, where there is now no way to get even back to the 7.6 level of support. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Thu Jan 29 21:57:14 2015 From: ghc-devs at haskell.org (GHC) Date: Thu, 29 Jan 2015 21:57:14 -0000 Subject: [GHC] #9586: Implement Traversable/Foldable-Burning-Bridges Proposal In-Reply-To: <042.e53740211d75489f68d7145493cd4f24@haskell.org> References: <042.e53740211d75489f68d7145493cd4f24@haskell.org> Message-ID: <057.96fd962e0811d2e79a4f0cf270a0231e@haskell.org> #9586: Implement Traversable/Foldable-Burning-Bridges Proposal -------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: closed Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9621 | Blocking: | Differential Revisions: Phab:D209 -------------------------------------+------------------------------------- Comment (by ekmett): https://wiki.haskell.org/Foldable_Traversable_In_Prelude is the page we're grooming for that purpose. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 30 01:54:43 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Jan 2015 01:54:43 -0000 Subject: [GHC] #2615: ghci doesn't play nice with linker scripts In-Reply-To: <051.bfa2cefd2ab537021a429fbc1fccdb5e@haskell.org> References: <051.bfa2cefd2ab537021a429fbc1fccdb5e@haskell.org> Message-ID: <066.fe0802ed48de393429c8db05bf552ec0@haskell.org> #2615: ghci doesn't play nice with linker scripts -------------------------------------+------------------------------------- Reporter: AlecBerryman | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.3 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: dlopen, Operating System: Linux | dynamic linking Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by Jinhui_Chen): Yes, the libc.so is in English. And you are right, I have tried to change the locale momentarily, and it works. {{{ olc <- withCString "C" $ \lc -> c_setlocale 5 lc r <- loadDLL "/usr/lib/libc.so" putStrLn (show r) c_setlocale 5 olc }}} 5 is for LC_MESSAGES. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 30 05:09:25 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Jan 2015 05:09:25 -0000 Subject: [GHC] #10045: type holes related ghc panic Message-ID: <044.57d9744c8f6fba48e5e1df568418a60d@haskell.org> #10045: type holes related ghc panic -------------------------------------+------------------------------------- Reporter: pacak | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Compile-time Unknown/Multiple | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- {{{ sample.hs:9:13: Couldn't match expected type ?t? with actual type ?()? ?t? is untouchable inside the constraints () bound by the inferred type of foo :: Meta -> t1 at sample.hs:(6,1)-(9,17)ghc: panic! (the 'impossible' happened) (GHC version 7.10.0.0 for x86_64-unknown-linux): No skolem info: t_avJ[sk] Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug sample.hs: module Blah where newtype Meta = Meta () foo (Meta ws1) = let copy :: _ copy w from = copy w 1 in copy ws1 1 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 30 08:44:39 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Jan 2015 08:44:39 -0000 Subject: [GHC] #9122: Make Lint check for bad uses of `unsafeCoerce` In-Reply-To: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> References: <046.08df0fe057a2d5e890843657bcc38111@haskell.org> Message-ID: <061.8fc4fa3d864cc203e33afa3293ae18c1@haskell.org> #9122: Make Lint check for bad uses of `unsafeCoerce` -------------------------------------+------------------------------------- Reporter: simonpj | Owner: qnikst Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 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:D637 -------------------------------------+------------------------------------- Comment (by qnikst): I want to clarify following questions about required semantics: 1. Coercion between unboxed types of different sizes Do we want to check _real_ (word aligned size of values) or _active_ (i.e. number of significant bytes)? (On Phab I assumed latter). But what about UnboxedTuples it seems that checking active size is not totally correct there? 2. Coercion between unboxed ints and floats. I see one usecase for such coercions, for example we have an array of floats, or unboxed tuple, and we want to calculate checksum, then we want to treat that array as an array of other base type. What should we do around unboxed tuples in this check? (On Phab I disabled check for unboxed tuples) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 30 12:07:27 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Jan 2015 12:07: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.ea9a25f3aa53ab6a6dbe267041780d70@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by oerjan): Replying to [comment:34 int-e]: > One such drawback is that the `Kindable'` constraint is sort of infectious. One can using a type family for mapping kinds to types, which seems to overcome that particular shortcoming: This is already better, but also: Wouldn't this type family become redundant if we had Richard's identification of types and kinds? Assuming this also means you can have classes with only kind parameters, you could possibly get rid of the need for all the `Proxy`s and `UndecidableInstances` as well? At which point this starts to seem a lot prettier. Since I didn't give much comments in my previous version, the main ideas were: 1. Including the kind of a type in its `TTypeRep` already at construction may not have the typing problems that the wiki page describes for a "polymorphic typerep" with separately applied kindrep arguments. 2. You can construct representations for kinds already in current GHC code, although there's boilerplate because you cannot use kinds as "naked" parameters. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 30 12:48:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Jan 2015 12:48:15 -0000 Subject: [GHC] #10027: Importing constructor of associated data type fails In-Reply-To: <048.077c953371a360576ad660349e5d3261@haskell.org> References: <048.077c953371a360576ad660349e5d3261@haskell.org> Message-ID: <063.6a682dd5e2dcd83c91a898efe6bcef5c@haskell.org> #10027: Importing constructor of associated data type fails -------------------------------------+------------------------------------- Reporter: lspitzner | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | constructor import associated data Type of failure: None/Unknown | type Blocked By: | Architecture: Related Tickets: | Unknown/Multiple | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by goldfire): Replying to [comment:6 lspitzner]: > How high would the risk of this breaking existing code be? I think it's quite high. I believe it's common practice to define datatypes in a package-internal module and then re-export them in a package-visible module. (Indeed, I do this in several of my released packages!) With the change as proposed, those types would not be re- exported, leading to chaos. But it seems that you can always import/export data constructors using the `pattern` herald in an import/export list. It seems the remaining bit is to come up with a syntax to use in case there are ''lots'' of constructors and writing out each one is annoying. Or have I missed something? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 30 17:50:11 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Jan 2015 17:50:11 -0000 Subject: [GHC] #10046: Linker script patch in rts/Linker.c doesn't work for (non-C or non-en..) locales Message-ID: <046.8d9180bf5eb50fbc94b5b6fcc0a45647@haskell.org> #10046: Linker script patch in rts/Linker.c doesn't work for (non-C or non-en..) locales -------------------------------------+------------------------------------- Reporter: hgolden | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime | Version: 7.8.4 System | Operating System: Unknown/Multiple Keywords: linker | Type of failure: Incorrect result script | at runtime Architecture: | Blocked By: Unknown/Multiple | Related Tickets: 2615, 9237 Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Please see ticket:2615#comment:40 and replies. This error only occurs on systems where linker scripts are used. The linker script patch (as it has evolved) assumes that the error messages it will receive are in English. This would be true if the locale (LC_MESSAGES) is C or en (or one of the en variants). However, in other locales, the message will be in a different language. Unfortunately, the semantics of POSIX dlerror() specify that the error is returned as a pointer to a human-readable text string, rather than an error code. The string returned depends on the locale. The code could be made more robust by momentarily changing the locale (LC_MESSAGES) to C before calling dlerror() and reverting it to its previous value immediately after. This has been tested on a zh_CN.utf-8 (see ticket:2615#comment:42) and works. The only concern I have is in the case of multithreaded code that _might_ be affected if it is running while the locale is changed. I don't know enough to know if this is a real issue or not, nor do I know how to deal with it if necessary. Also see ticket:9237 for another corner case in the linker script code that should be dealt with at the same time. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 30 17:51:49 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Jan 2015 17:51:49 -0000 Subject: [GHC] #2615: ghci doesn't play nice with linker scripts In-Reply-To: <051.bfa2cefd2ab537021a429fbc1fccdb5e@haskell.org> References: <051.bfa2cefd2ab537021a429fbc1fccdb5e@haskell.org> Message-ID: <066.42113d176afe5f87436a47953f44f702@haskell.org> #2615: ghci doesn't play nice with linker scripts -------------------------------------+------------------------------------- Reporter: AlecBerryman | Owner: Type: bug | Status: new Priority: high | Milestone: 6.12.3 Component: GHCi | Version: 7.0.3 Resolution: | Keywords: dlopen, Operating System: Linux | dynamic linking Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by hgolden): I have opened a new ticket:10046, so I am closing this ticket again. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 30 17:52:43 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Jan 2015 17:52:43 -0000 Subject: [GHC] #2615: ghci doesn't play nice with linker scripts In-Reply-To: <051.bfa2cefd2ab537021a429fbc1fccdb5e@haskell.org> References: <051.bfa2cefd2ab537021a429fbc1fccdb5e@haskell.org> Message-ID: <066.7f1e916358935baf7824364360344d8a@haskell.org> #2615: ghci doesn't play nice with linker scripts -------------------------------------+------------------------------------- Reporter: AlecBerryman | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.12.3 Component: GHCi | Version: 7.0.3 Resolution: fixed | Keywords: dlopen, Operating System: Linux | dynamic linking Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hgolden): * status: new => closed * resolution: => fixed -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 30 17:57:37 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Jan 2015 17:57:37 -0000 Subject: [GHC] #9237: GHC not recognizing "-llibrary" form in implicit linker scripts In-Reply-To: <051.f95f4904e896de4fcf955563f575c874@haskell.org> References: <051.f95f4904e896de4fcf955563f575c874@haskell.org> Message-ID: <066.3d3040ced9c33e6ecbc22cfd4730a33e@haskell.org> #9237: GHC not recognizing "-llibrary" form in implicit linker scripts -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 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: | Blocking: Related Tickets: 2615, 10046 | Differential Revisions: -------------------------------------+------------------------------------- Changes (by hgolden): * cc: hgolden (added) * related: => 2615, 10046 -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 30 18:04:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Jan 2015 18:04:26 -0000 Subject: [GHC] #9237: GHC not recognizing INPUT(-llibrary) in linker scripts (was: GHC not recognizing "-llibrary" form in implicit linker scripts) In-Reply-To: <051.f95f4904e896de4fcf955563f575c874@haskell.org> References: <051.f95f4904e896de4fcf955563f575c874@haskell.org> Message-ID: <066.c60c843408bb7ed8cb23465887ba726a@haskell.org> #9237: GHC not recognizing INPUT(-llibrary) in linker scripts -------------------------------------+------------------------------------- Reporter: mmikolajczyk | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.12.1 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: | Blocking: Related Tickets: 2615, 10046 | Differential Revisions: -------------------------------------+------------------------------------- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 30 18:17:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Jan 2015 18:17:59 -0000 Subject: [GHC] #10046: Linker script patch in rts/Linker.c doesn't work for (non-C or non-en..) locales In-Reply-To: <046.8d9180bf5eb50fbc94b5b6fcc0a45647@haskell.org> References: <046.8d9180bf5eb50fbc94b5b6fcc0a45647@haskell.org> Message-ID: <061.9b9eb6e741f7075eda1762890f2e9ed0@haskell.org> #10046: Linker script patch in rts/Linker.c doesn't work for (non-C or non-en..) locales -------------------------------------+------------------------------------- Reporter: hgolden | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Runtime System | Version: 7.8.4 Resolution: | Keywords: linker Operating System: Unknown/Multiple | script Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: 2615, 9237 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by rwbarton): > The only concern I have is in the case of multithreaded code that _might_ be affected if it is running while the locale is changed. I don't know enough to know if this is a real issue or not, nor do I know how to deal with it if necessary. Yes, this is an issue with `setlocale`. POSIX has `uselocale` and related functions which allow setting the locale on a per-thread basis, though. `dlopen` can execute code from the shared library it loads (constructor functions), so as you say we should only modify the locale around the call to `dlerror`, which should be safe. Really the most correct thing to do would be to return both the localized error message and the `LC_MESSAGES=C` error message from `internal_dlopen`, and use the latter message to detect linker scripts, and present the former message to the user if we ultimately can't load the shared library. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 30 18:28:34 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Jan 2015 18:28:34 -0000 Subject: [GHC] #10047: inconsistency in name binding between splice and quasiquotation Message-ID: <047.467ed7feed46ef69006cfd30a0e1c7fb@haskell.org> #10047: inconsistency in name binding between splice and quasiquotation -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.8.4 Haskell | Operating System: Unknown/Multiple Keywords: | Type of failure: None/Unknown Architecture: | Blocked By: Unknown/Multiple | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Let me preface this by saying that this may not be a bug. If not then it would be nice if the documentation for Template Haskell could clarify what's going on here. My understanding of quasiquotation is that a quasiquote `[n|foo|]` is equivalent to a splice `$(quoteExp n "foo")`. However, that is not the case in all contexts. {{{ module Q where import Language.Haskell.TH import Language.Haskell.TH.Quote n = QuasiQuoter { quoteExp = dyn } }}} {{{ rwbarton at morphism:/tmp$ ghci -XTemplateHaskell -XQuasiQuotes Q 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 Q ( Q.hs, interpreted ) Q.hs:6:5: Warning: Fields of ?QuasiQuoter? not initialised: quotePat, quoteType, quoteDec In the expression: QuasiQuoter {quoteExp = dyn} In an equation for ?n?: n = QuasiQuoter {quoteExp = dyn} Ok, modules loaded: Q. *Q> :t [| $(dyn "foo") |] [| $(dyn "foo") |] :: ExpQ *Q> :t [| [n|foo|] |] Loading package pretty-1.1.1.1 ... linking ... done. Loading package array-0.5.0.0 ... linking ... done. Loading package deepseq-1.3.0.2 ... linking ... done. Loading package containers-0.5.5.1 ... linking ... done. Loading package template-haskell ... linking ... done. :1:7: Not in scope: ?foo? In the Template Haskell quotation [| [n|foo|] |] }}} Why do these behave differently? (Lastly, the link to the paper "Why It's Nice to be Quoted: Quasiquoting for Haskell" in the User's Guide at https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/template- haskell.html#th-quasiquotation is broken. Does this paper have a permanent home? In any case, I only skimmed it but it didn't seem to answer my question.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 30 19:40:43 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Jan 2015 19:40:43 -0000 Subject: [GHC] #10048: {-# UNPACK #-} support for size-indexed types Message-ID: <045.3007e0354ab047007432d2f1d345858f@haskell.org> #10048: {-# UNPACK #-} support for size-indexed types -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.11 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 don't know too much of the theory, but it seems to me that `{-# UNPACK #-}` should be able to work for something like this: {{{#!hs data Tup (l::[*]) where Nil :: HList '[] Cons :: e -> {-# UNPACK #-} !(HList l) -> HList (e ': l) }}} This is essentially just `HList` from the `HList` package but strict in the second `Cons` argument. What I would want is for `Tup '[a,b,c]` to be represented in just the same way as `(a,b,c)`. When possible, I'd want the getters/setters/lenses to be optimized to index into the unpacked structure rather than walking along it. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 30 19:57:46 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Jan 2015 19:57:46 -0000 Subject: [GHC] #10048: {-# UNPACK #-} support for size-indexed types In-Reply-To: <045.3007e0354ab047007432d2f1d345858f@haskell.org> References: <045.3007e0354ab047007432d2f1d345858f@haskell.org> Message-ID: <060.4954e6282242e01ed73edf0e9345e0a4@haskell.org> #10048: {-# UNPACK #-} support for size-indexed types -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | 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 rwbarton): How would we implement {{{ hlength :: HList l -> Int hlength Nil = 0 hlength (Cons _ xs) = 1 + hlength xs }}} then? (Bear in mind that we have no access to the type parameter `l` at runtime.) I think this sort of thing could only work with a type family rather than a GADT (and even then I haven't thought about whether it actually could work). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 30 20:08:15 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Jan 2015 20:08:15 -0000 Subject: [GHC] #10048: {-# UNPACK #-} support for size-indexed types In-Reply-To: <045.3007e0354ab047007432d2f1d345858f@haskell.org> References: <045.3007e0354ab047007432d2f1d345858f@haskell.org> Message-ID: <060.b49acaeb886e64f8c604c0e226c82057@haskell.org> #10048: {-# UNPACK #-} support for size-indexed types -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: Type: feature request | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.11 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 dfeuer): * status: new => closed * resolution: => invalid Comment: Replying to [comment:1 rwbarton]: > How would we implement > > {{{ > hlength :: HList l -> Int > hlength Nil = 0 > hlength (Cons _ xs) = 1 + hlength xs > }}} > > then? (Bear in mind that we have no access to the type parameter `l` at runtime.) > > I think this sort of thing could only work with a type family rather than a GADT (and even then I haven't thought about whether it actually could work). Ah, you make a very good point. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 30 20:43:26 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Jan 2015 20:43: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.ab14898ab02e99f8a464d293a7bc4f52@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:30 simonpj]: > The "right" solution is, I think, at the bottom of comment:20. But NB that solution will mean that all these standalone derived instances would become illegal, so there is a backward compatibility cost. The drastic solution does not have this problem. Wouldn't it be (sufficiently) correct to simply ignore all `Typeable` instance declarations (`deriving`, standalone `deriving`, and otherwise), issuing a warning to that effect, instead of rejecting them outright? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 30 21:40:52 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Jan 2015 21:40: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.cef2d23c0a0fda3d3ba9b6c8b3b72b4e@haskell.org> #9858: Typeable instances should be kind-aware -------------------------------------+------------------------------------- Reporter: dreixel | Owner: dreixel Type: bug | Status: new Priority: highest | Milestone: 7.10.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: -------------------------------------+------------------------------------- Comment (by int-e): Replying to [comment:26 int-e]: > I'm afraid there is no good interim solution here. I favor spj's suggestion, but #9111 suggests that some people actually use {{{Typeable}}} for {{{Proxy}}}. I've changed my mind about SPJ's idea. It's very late in the ghc-7.10 release cycle, and the design of the long-term solution is still in flux, so any ''drastic'' stop-gap measure bears a significant risk of breaking users' code twice. And there are quite a lot of users, not least because `Typeable` is poly-kinded (see also Edward's comment:37 which carries some weight). I'd rather see this bug documented and communicated prominently so that everybody who runs untrusted Haskell code knows about it, and take further measures to sandbox that code. (This is a good idea anyway; ghc, its RTS and the libraries are really too big to be trusted even with `SafeHaskell` enabled.) -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 30 22:21:59 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Jan 2015 22:21:59 -0000 Subject: [GHC] #10049: Lower level memcpy primop Message-ID: <049.7926ad1e5d4d0b6d73e54643d844bbc7@haskell.org> #10049: Lower level memcpy primop -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: feature | Status: new request | Milestone: Priority: normal | Version: 7.8.4 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'm doing some really low-level buffer stuff, and it would be quite helpful if there were lower-level memcpy primitives. I'm thinking something like: {{{#!hs copyBytes# :: Addr# -> Addr# -> Int# -> State# s -> State# s copyBytes dst src size _ = ... }}} I would expect it to compile, on x86, into "rep movsb", which is frequently optimal on Ivy Bridge and Haswell. The other memcpy primitives use Array# or MutableArray#, and it's not clear how, if all you have is an Addr#, how to get the corresponding Array# or MutableArray#. (Can you just cast?) It may be appropriate to have corresponding 16-bit and 32-bit operations; "rep movsw" and "rep movsd", respectively. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 30 22:25:14 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Jan 2015 22:25:14 -0000 Subject: [GHC] #10050: template haskell Ppr missing parentheses for SigT Message-ID: <045.8129f409277b7f81ed7d11236d6dd246@haskell.org> #10050: template haskell Ppr missing parentheses for SigT -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- {{{#!hs ppr (SigE (VarE (mkName "a")) (SigT (VarT (mkName "x")) (VarT (mkName "k")))) }}} prints as "a :: x :: k". Ghc can't parse that, so I think it should be printed as "a :: (x :: k)" -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 30 22:46:30 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Jan 2015 22:46:30 -0000 Subject: [GHC] #9805: Use TrieMaps to speed up type class instance lookup In-Reply-To: <045.621217884d547d5010b211251c8e4ea4@haskell.org> References: <045.621217884d547d5010b211251c8e4ea4@haskell.org> Message-ID: <060.b3016c5c330bf98e123cdfd1cfbd3473@haskell.org> #9805: Use TrieMaps to speed up type class instance lookup -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: task | 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: -------------------------------------+------------------------------------- Comment (by ezyang): So, here is an irritating problem with trying to deBruijn number template variables on the fly. First, let's establish that it is desirable for template variables to be deBruijn numbered in order of appearance. This is because if you have instanc heads `C a b` and `C b a` (`a` and `b` being template variable), it would be rather silly if we de Bruijinized these as `C 0 1` and `C 1 0`, when really they're the same. We don't know, a priori, what order the "template quantifiers" should be, so it would be great to defer this choice until we've explored the expression deeply enough to tell. The fly in the ointment is this: with template variables, environment extension happens when we ''encounter a template variable'' (as opposed to de Bruijn numbering lambda/foralls, where extension occurs when we ''encounter a lambda/forall''). So, if I am handling `C ????? a` (where `a` is a template variable), I do not know what the index of `a` will be until I have processed `?????` and determined how many template variables show up for the first time there. Accordingly, my lookup function must ''return'' the new template variable environment, in the same way the unifying match function returns the substitution. This is not completely terrible, since we already were going to need to return extra information on lookup for the unifying match, but it does mean we can't use any of the existing lookup/insert functions to manage template variables. C'est la vie? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 30 23:24:47 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Jan 2015 23:24:47 -0000 Subject: [GHC] #10050: template haskell Ppr missing parentheses for SigT In-Reply-To: <045.8129f409277b7f81ed7d11236d6dd246@haskell.org> References: <045.8129f409277b7f81ed7d11236d6dd246@haskell.org> Message-ID: <060.248e1fd9fb7641069c25281181a20f6f@haskell.org> #10050: template haskell Ppr missing parentheses for SigT -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: 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 adamse): The printing of `SigE` happens in [https://github.com/ghc/ghc/blob/master/libraries/template- haskell/Language/Haskell/TH/Ppr.hs#L172] and `SigT` happens in [https://github.com/ghc/ghc/blob/master/libraries /template-haskell/Language/Haskell/TH/Ppr.hs#L507]. If it is always correct to put parens around a `Type :: Kind` signature the fix could go in the latter place otherwise `pprExp` of `SigE` could inspect the second argument to `SigE` to see if it is a `SigT` and only then put parens around it. What would be the correct solution? -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Fri Jan 30 23:28:56 2015 From: ghc-devs at haskell.org (GHC) Date: Fri, 30 Jan 2015 23:28:56 -0000 Subject: [GHC] #10049: Lower level memcpy primop In-Reply-To: <049.7926ad1e5d4d0b6d73e54643d844bbc7@haskell.org> References: <049.7926ad1e5d4d0b6d73e54643d844bbc7@haskell.org> Message-ID: <064.d25a2534b1922cc22b5097127a1018b0@haskell.org> #10049: Lower level memcpy primop -------------------------------------+------------------------------------- Reporter: chadaustin | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by tibbe): That's indeed the only one we're missing. We have e.g. `copyAddrToByteArray#`. There's a separate ticket (and Phab entry) for the rep movsw. Austin was working on that. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 31 12:32:15 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Jan 2015 12:32:15 -0000 Subject: [GHC] #9988: Remove fun_id, is_infix from FunBind, as they are now in Match In-Reply-To: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> References: <044.a60b224ba7da7f43c70f7f0475934826@haskell.org> Message-ID: <059.cb88b372867624f392afaa4a4459c2ed@haskell.org> #9988: Remove fun_id, is_infix from FunBind, as they are now in Match -------------------------------------+------------------------------------- Reporter: alanz | Owner: alanz Type: task | Status: new Priority: normal | Milestone: 7.12.1 Component: Compiler | Version: 7.10.1-rc1 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 alanz): Phab:D639 refers, which does not close this ticket, but is just the first step toward it. I strongly believe I am not introducing new bugs as it is a simple addition to rnMatch' with pure code that only sets a variable that is ignored in the rest of the compilation process, being introduced specifically for API Annotations. In terms of motivation, the current HaRe model is to do analysis on the RenamedSource, then transform the ParsedSource. Having funcction id locations available in all Match variants is vital. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 31 15:08:01 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Jan 2015 15:08:01 -0000 Subject: [GHC] #10051: panic - the 'impossible' happened Message-ID: <046.81c18ed44b1067fab64df95400149350@haskell.org> #10051: panic - the 'impossible' happened -------------------------------------+------------------------------------- Reporter: jpw1991 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: x86_64 | Type of failure: GHCi crash (amd64) | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Hi there, I'm new to Haskell and I'm loving it so far. I finished a learning project in Haskell and it works fine on Linux. I'm bringing it over to Windows and I got the following error while running it: C:\Repositories\HaskellPong>ghci Main.hs -LC:\SDL\lib -lSDL2 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. Loading object (static archive) C:\SDL\lib\libSDL2.a ... ghc.exe: Unknown PEi386 section name `.rdata$.refptr.DUMMYAUD_bootstrap' (while processing: C:\SDL\lib\ libSDL2.a) ghc.exe: panic! (the 'impossible' happened) (GHC version 7.8.3 for x86_64-unknown-mingw32): loadArchive "C:\\SDL\\lib\\libSDL2.a": failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug The repository is public, so you can go and get it from here: https://jwoodss at bitbucket.org/jwoodss/haskellpong.git -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 31 15:08:56 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Jan 2015 15:08:56 -0000 Subject: [GHC] #10051: panic - the 'impossible' happened In-Reply-To: <046.81c18ed44b1067fab64df95400149350@haskell.org> References: <046.81c18ed44b1067fab64df95400149350@haskell.org> Message-ID: <061.0e5e010bdf8fd0a32c01644a459cd46c@haskell.org> #10051: panic - the 'impossible' happened -------------------------------+----------------------------------------- Reporter: jpw1991 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Changes (by jpw1991): * os: Unknown/Multiple => Windows -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 31 17:38:27 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Jan 2015 17:38:27 -0000 Subject: [GHC] #10052: Panic (something to do with floatExpr?) Message-ID: <044.712619dfc86074dec5613c292886ee1f@haskell.org> #10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- Loading {{{ main = let (x :: String) = "hello" in putStrLn x }}} using a very simple driver for the GHC API (see T145.hs) causes a ghc panic: {{{ [1 of 1] Compiling Main ( T145-input.hs, interpreted ) T145: T145: panic! (the 'impossible' happened) (GHC version 7.10.0.20150128 for x86_64-apple-darwin): floatExpr tick <
> Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} This panic is arising in our test case for #8333, so it may be related to that bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 31 17:40:22 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Jan 2015 17:40:22 -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.8c0faa01ae1155944abb9d9fd6c5efd3@haskell.org> #10052: Panic (something to do with floatExpr?) -------------------------------------+------------------------------------- Reporter: edsko | 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 edsko): Call the driver with {{{ # ./T145 ./T145-input.hs -XScopedTypeVariables -O }}} to cause the panic (no panic happens if you don't specify -O). -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 31 17:57:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Jan 2015 17:57:26 -0000 Subject: [GHC] #10053: problem in ghci calling main after loading compiled code Message-ID: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> #10053: problem in ghci calling main after loading compiled code -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.10.1-rc2 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: | -------------------------------------+------------------------------------- ghci GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help Prelude> :load rsa Ok, modules loaded: Main. Prelude Main> :show modules Main ( rsa.hs, rsa.o ) Prelude Main> main Too late for parseStaticFlags: call it before runGhc or runGhcT *** Exception: ExitFailure 1 Prelude Main> note, there is no failure if I load interpreted code -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 31 18:18:18 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Jan 2015 18:18:18 -0000 Subject: [GHC] #10053: problem in ghci calling main after loading compiled code In-Reply-To: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> References: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> Message-ID: <060.ac970547a83e6b88fe81d435b312aaf8@haskell.org> #10053: problem in ghci calling main after loading compiled code -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 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: -------------------------------------+------------------------------------- Description changed by George: Old description: > ghci > GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help > Prelude> :load rsa > Ok, modules loaded: Main. > Prelude Main> :show modules > Main ( rsa.hs, rsa.o ) > Prelude Main> main > Too late for parseStaticFlags: call it before runGhc or runGhcT > *** Exception: ExitFailure 1 > Prelude Main> > > note, there is no failure if I load interpreted code New description: ghci GHCi, version 7.10.0.20150123: http://www.haskell.org/ghc/ :? for help Prelude> :load rsa Ok, modules loaded: Main. Prelude Main> :show modules Main ( rsa.hs, rsa.o ) Prelude Main> main Too late for parseStaticFlags: call it before runGhc or runGhcT Exception: ExitFailure 1 Prelude Main> note, there is no failure if I load interpreted code -- -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 31 18:22:24 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Jan 2015 18:22:24 -0000 Subject: [GHC] #10053: Too late for parseStaticFlags, error in ghci calling main after loading compiled code (was: problem in ghci calling main after loading compiled code) In-Reply-To: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> References: <045.7defde488a4af19895968f8c8b9b5f95@haskell.org> Message-ID: <060.359c250c66d8c6c3e6e2b2eeee92646b@haskell.org> #10053: Too late for parseStaticFlags, error in ghci calling main after loading compiled code -------------------------------------+------------------------------------- Reporter: George | Owner: Type: bug | Status: new Priority: normal | Milestone: 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 Sat Jan 31 20:25:42 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Jan 2015 20:25:42 -0000 Subject: [GHC] #10051: panic - the 'impossible' happened In-Reply-To: <046.81c18ed44b1067fab64df95400149350@haskell.org> References: <046.81c18ed44b1067fab64df95400149350@haskell.org> Message-ID: <061.c7c4b90490a76d8d48d482ca040a249c@haskell.org> #10051: panic - the 'impossible' happened -------------------------------+----------------------------------------- Reporter: jpw1991 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 7.8.4 Resolution: | Keywords: Operating System: Windows | Architecture: x86_64 (amd64) Type of failure: GHCi crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------+----------------------------------------- Comment (by archblob): This looks like the same problem reported in #7103. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 31 21:32:26 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Jan 2015 21:32:26 -0000 Subject: [GHC] #10043: runtime fails in threaded way on SPARC (bus error -> unaligned access to data) In-Reply-To: <046.71d97f17298f6703a7e75e75a742ac80@haskell.org> References: <046.71d97f17298f6703a7e75e75a742ac80@haskell.org> Message-ID: <061.ad26b2425f6df21d1e9080d1b3c33dd5@haskell.org> #10043: runtime fails in threaded way on SPARC (bus error -> unaligned access to data) ----------------------------------+------------------------------------- Reporter: kgardas | Owner: kgardas Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Solaris | Architecture: sparc Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: ----------------------------------+------------------------------------- Changes (by kgardas): * owner: => kgardas -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 31 23:00:55 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Jan 2015 23:00:55 -0000 Subject: [GHC] #10054: Misleading error message from unsaturated type family application Message-ID: <046.3310f47d666fed735a640a4960a77ce9@haskell.org> #10054: Misleading error message from unsaturated type family application -------------------------------------+------------------------------------- Reporter: sherman | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 (Type checker) | Operating System: MacOS X Keywords: type | Type of failure: Incorrect families, constraint kinds | warning at compile-time Architecture: x86_64 | Blocked By: (amd64) | Related Tickets: Test Case: | Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- This program {{{#!hs {-# LANGUAGE GADTs, ConstraintKinds, KindSignatures #-} {-# LANGUAGE TypeFamilies #-} import GHC.Exts (Constraint) data Foo :: (* -> Constraint) -> * -> * where MkFoo :: c a => Foo c a type family Ap (f :: * -> Constraint) (x :: *) :: Constraint where Ap f x = f x test :: Ap Show a => Foo (Ap Show) a test = MkFoo }}} yields the following error message: {{{ [1 of 1] Compiling Main ( Test.hs, interpreted ) Test.hs:13:8: Could not deduce (Ap Show a) arising from a use of ?MkFoo? from the context (Ap Show a) bound by the type signature for test :: (Ap Show a) => Foo (Ap Show) a at Test.hs:12:9-36 Relevant bindings include test :: Foo (Ap Show) a (bound at Test.hs:13:1) In the expression: MkFoo In an equation for ?test?: test = MkFoo Failed, modules loaded: none. }}} I have a hypothesis as to why this error occurs. Because the application of {{{Ap}}} in {{{Ap Show a}}} is fully applied in the context, it reduces to the constraint {{{Show a}}}. However, when error messages describe the typeclass context, they don't reduce type synonyms or type families. However, the {{{Ap Show a}}} that cannot be deduced, despite appearing like a saturated application of {{{Ap}}}, must not be due to the fact that the {{{Ap Show}}} in the argument to the {{{Foo}}} type constructor is partially applied. If the definition of {{{Ap}}} is eta-reduced, the program in fact successfully typechecks. Or, if the result type of {{{test}}} is instead specified as {{{Foo Show a}}}, the program successfully typechecks. If the type variable {{{a}}} is specialized to a concrete type with a {{{Show}}} instance such as {{{Int}}}, the misleading error message still occurs, with {{{Int}}} substituted for {{{a}}}. I am wondering if there might be some way to report the error in a way that brings attention to the fact that the compiler cannot figure out what {{{Ap Show a}}} ''is'' as the constraint that cannot be deduced. -- Ticket URL: GHC The Glasgow Haskell Compiler From ghc-devs at haskell.org Sat Jan 31 23:43:53 2015 From: ghc-devs at haskell.org (GHC) Date: Sat, 31 Jan 2015 23:43:53 -0000 Subject: [GHC] #10017: signal handlers are invoked multiple times when the threaded rts is used In-Reply-To: <045.98c8a4b2b498781adefd9fa189c04668@haskell.org> References: <045.98c8a4b2b498781adefd9fa189c04668@haskell.org> Message-ID: <060.e85afdfdd3f9c1eee7f245ad3575f678@haskell.org> #10017: signal handlers are invoked multiple times when the threaded rts is used -------------------------------------+------------------------------------- Reporter: redneb | Owner: Type: bug | AndreasVoellmy Priority: highest | Status: new Component: Runtime System | Milestone: 7.10.1 Resolution: | Version: 7.10.1-rc1 Operating System: Linux | Keywords: Type of failure: Incorrect result | Architecture: at runtime | Unknown/Multiple Blocked By: | Test Case: Related Tickets: #9423 | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by AndreasVoellmy): * owner: simonmar => AndreasVoellmy -- Ticket URL: GHC The Glasgow Haskell Compiler